Abschlussbericht DFG-Schwerpunktprogramm 1040: Entwurf und ... · Überblick über das...

AbschlussberichtDFG-Schwerpunktprogramm 1040:

Entwurf und Entwurfsmethodik eingebetteter Systeme

Wolfgang RosenstielUniversität Tübingen

1997 – 2003

Überblick über das Schwerpunktprogramm

Das hier zusammenfassend vorgestellte von der DFG geförderte Schwerpunktprogramm “Ent-wurf und Entwurfsmethodik eingebetteter Systeme” hat vor allem die Methodik für den System-entwurf eingebetteter Systeme erforscht und weiter entwickelt, sowie bei konkreten Anwendun-gen exemplarisch eingesetzt.

Als eingebettete Systeme(engl.: embedded systems)bezeichnet man im Allgemeinen elek-tronische Systeme, die in größere Systeme oder Umgebungen integriert sind. Sie werden fürspezielle Anwendungen entworfen und können sowohl aus Mikrocontrollern, als auch aus denfür die jeweilige Anwendung entworfenen Hard- und Software-Komponenten bestehen.

Die Kombination von Methodenentwicklung mit exemplarischem Entwurf eingebetteter Sy-steme war ein besonderer Schwerpunkt dieses Schwerpunktprogramms. Der Entwurf eingebet-teter Systeme hat sich zu einem viel beachteten eigenständigen Forschungsgebiet entwickelt,dessen besondere Anforderungen sich aus der Optimierung des Zusammenwirkens heterogenerTeilsysteme ergeben. Dabei kam es in den durchgeführten Forschungsarbeiten nicht nur daraufan, dass das eingebettete System die gewünschte Funktion erfüllt, sondern dass darüber hinausvor allem Anforderungen bezüglich der gewünschten Leistung, der Kosten des Gesamtsystems,der Zuverlässigkeit, der Sicherheit, des Energieverbrauchs usw. erfüllt werden.

Ein wichtiger Punkt ist hierbei die Beherrschung der exponentiell wachsenden Komplexitätsolcher Systeme, deren Entwurf sich erheblich vom klassischen Software-Entwurf für Desktop-Anwendungen unterscheidet. Um derart komplexe eingebettete Systeme mit vertretbaren Kostenund in möglichst kurzer Zeit entwickeln zu können, wurden im SPP neue Methoden entwickelt,die es dem Entwickler ermöglichen, Entwurfsanforderungen in einer möglichst frühen Phasedes Entwurfs zu überprüfen, und die Entwurfskosten durch fortschrittliche Entwurfsmethodikenmöglichst gering zu halten.

Neben der technischen Entwicklung eingebetteter Systeme sei auch auf die enorme wirt-schaftliche Bedeutung hingewiesen. Immer stärker entscheidet der Elektronik- und Software-Anteil (also das eingebettete System) über die gesamte Wertschöpfung neuer Produkte. DerEinsatz neuer Methoden im Entwurf komplexer Eingebetteter Systeme ist somit wettbewerbs-entscheidend und kann für Betriebe in diesem Sektor überlebenswichtig sein.

Typische Beispiele für eingebettete Systeme sind im Telekommunikationsbereich, der indu-striellen Automation und Robotik, der Unterhaltungselektronik, der Luft- und Raumfahrt undinsbesondere der Automobilindustrie zu finden. Neben dem Trend zur Steigerung der Komplexi-tät eingebetteter Systeme, ist auch der Trend zu steigender Kommunikation zwischen den hete-rogenen Komponenten eingebetteter Systeme und die durch die Mobilität hervorgerufen Anfor-derungen, wie Miniaturisierung und geringer Stromverbrauch zu beobachten.

Im Schwerpunktprogramm “Eingebettete Systeme” sind 14 Projekte gefördert worden. Indiesem Zusammenhang entstanden mehr als 100 Publikationen und mehr als 20 Dissertationen.

Die beiliegende CD enthält eine Kurzbeschreibung der Projekte des SPP und deren wichtigsteErgebnisse. Die Reihenfolge entspricht der Reihenfolge der Vorträge beim Abschlusskolloquiumdes Schwerpunktprogramms, das im Rahmen eines Workshops bei der Robert Bosch GmbH inLeonberg im November 2003 veranstaltet wurde.

Exemplarisch sollen im Folgenden einige Ergebnisse herausgegriffen und kurz beschriebenwerden.

ii

Exemplarische Ergebnisse

Ein charakteristisches Merkmal eingebetteter Systemeist, dass sie speziell für eine Anwendung entworfen wur-den. Mit derDigital Versatile Architectureerarbeitete dieUniversität Leipzig eine Methodik, mit der eingebetteteSysteme genauso flexibel wie herkömmliche Computer-systeme eingesetzt werden können, ohne jedoch die ho-hen Kosten und Stromverbrauch dieser Systeme aufzuwei-sen. Dies wird dadurch erreicht, dass in den Systemen re-konfigurierbare Hardware eingesetzt wird. Die Konfigura-tionsdaten werden dabei über Accesspoints von dezentra-len Konfigurationsservern angefordert, wie folgende Ab-bildung schematisch zeigt. Um den Rechenaufwand imEingebetteten System möglichst gering zu halten, über-nehmen Accesspoints einen großen Teil, der zur Kommu-nikation mit Servern benötigten Funktionalität.

Institut für Informatik (Prof. Dr. U. Kebschull), Univer-sität Leipzig

bauen und sie so zu erweitern, dass sie unseren Ansprü-chen gerecht wird.Diese Technologie ist unter den Namen „Enterprise JavaBeans“ (EJB) bekannt. EJB baut auf der Java Technolo-gie der Firma SunTM auf. Java hat den Vorteil, dass einin dieser Sprache geschriebenes Programm auf den unter-schiedlichsten Systemen läuft, die Java unterstützen. Al-lerdings wird dieser Vorteil damit erkauft, dass man stetsetwas mehr an Prozessorleistung und Speicher benötigt.Für kleine eingebettete Systeme ist daher Java Unterstüt-zung aus Kostengründen nicht immer möglich. Wir habenallerdings eine Möglichkeit gefunden auch diese Gerätean unser System anzubinden. Dazu haben wir sogenann-te „Accesspoints“ in unser System integriert. Ein Access-point ist ein Computer, der sowohl Java beherrscht als auchmit dem einfachen Client kommunizieren kann. Beispiels-weise könnte der heimische Internet PC als Access Pointdienen. Das elektronische Notizbuch des Benutzers könn-te dann über eine einfache Infrarot Schnittstelle mit demPC kommunizieren und dieser reicht diese Anfragen dannzum Management System weiter. Access Points kann mansich also am besten als Vermittler zwischen eingebettetenSystem und Management Schicht vorstellen.

4. Ergebnisse�Erfahrungen

Wir haben mehrere einfache Prototypen entwickelt undmit ihnen unser System unter Laborbedingungen getestet.

Client Server

Thin Client(SH3 Board)

Access Point(Linux Box)

HTTPS Server

EJB Client EJB Server

opt.xml

res.xml

Eine Aufgabe der Tests war herauszufinden, wie das Sys-tem funktioniert, d.h. z.B. wie schnell es auf Anfragenreagiert. Als eingebettetes System diente dazu eine Expe-rimentierplatine mit einem Prozessor (SH3 von Hitachi)und einem FPGA (Virtex von Xilinx). Auf diesem Systemlief kein Java. Daher erfolgte die Kommunikation mit demManagement System über einen Access Point, in unseremFall einen PC. Die Kommunikation vom Experimentier-board zum PC erfolgte in HTTP, dem gleichen Protokoll,wie es auch im WWW verwendet wird. Der PC wieder-um reichte die Daten an das Management System weiter,welches durch einen EJB Server bereitgestellt wurde. Zieldes Experiments war, dass das eingebettete System Pro-grammcode anforderte, um das FPGA zu programmieren.Diese Anfrage erging an das Management System, wel-ches dann aus einer Datenbank die Code Komponente aus-wählte, die auf dem FPGA lauffähig war.

� Ergebnis: Die Zeit, die für Anfrage, Übertragung,verschiedene Initialisierungen und Datenbankabfra-gen benötigt wurde, lag bei ca. 1 Sekunde.

Ein anderes Experiment beschäftigte sich mit den Mög-lichkeiten der Energieeinsparung. Dazu programmiertenwir ein Testprogramm einmal für den Mikroprozessor undeinmal für das FPGA. Bei den anschließenden Probeläu-fen haben wir gemessen, wie groß die jeweiligen Rechen-zeiten sind und zum anderen den Stromverbrauch festge-stellt.

� Ergebnis: Im Experiment war das FPGA ca.2400mal schneller als der einfache Prozessor. Umden Stromverbrauch zu vergleichen haben wir er-rechnet, wieviel Energie (gemessen in Wattsekun-den) der Prozessor bzw. das FPGA pro „Rechen-schritt“ verbrauchen. Dabei mussten wir feststellen,dass das FPGA (1 � 10 � 8 Ws) trotz höherer Ge-schwindigkeit nur ca 1 � 1000 der Energie verbrauchtwie der Prozessor (1 � 10 � 5 Ws).

5. Fazit

Wir haben ein System aus Methoden entwickelt, die es er-möglichen können, zukünftige eingebettete Systeme ge-nau so leistungsfähig und flexibel zu gestalten wie es bis-her nur mit herkömmlicher Rechentechnik möglich ist.Unsere Labortests haben gezeigt, dass diese Metho-den prinzipiell funktionieren und daher erfolgverspre-chend sind. Zukünftige Arbeiten werden zum Ziel haben,dieses System weiter zu verbessern. Insbesondere wür-den wir uns auf Kooperationen mit Industriepartnernfreuen, um das System auch im praktischen Einsatz tes-ten zu können.

6. Weitere Informationen

Im Rahmen dieser Zusammenfassung konnte das Projektnatürlich nur kurz umrissen werden. Ausführliche Infor-mationen finden sich in unseren Veröffentlichungen:

Literatur

[1] NITSCH, LARA, KEBSCHULL: A Novel Design Technolo-gy for Next Generation Ubiquitous Computing Architectu-res. In: IPDPS RAW, Nice, 2003.

[2] LANGE, KEBSCHULL: Virtual Hardware Byte Code as aDesign Platform for Reconfigurable Embedded Systems. In:Proceedings of the Design Automation and Test in EuropeConference (DATE2003), München, 2003.

[3] NITSCH, KEBSCHULL: The Use of Runtime ConfigurationCapabilities for Networked Embedded Systems. In: Procee-dings of the Design Automation and Test in Europe Confe-rence (DATE2002), Paris, 2002.

[4] NITSCH, KEBSCHULL: Konzeption einer virtuellen, offe-nen, echtzeitfähigen Systemarchitektur. In: Workshop Mo-delltransformation und Werkzeugkopplung, Braunschweig,2001.

4

Beim Entwurf eingebetteter Systeme wird eine Evalu-ierung des Systems zu einem möglichst frühen Zeitpunktim Entwurfsprozess angestrebt. An der Universität Tübin-gen wurden zum Einen analytische Methoden entwickelt,mit denen die zeitlichen Eigenschaften von Software ineingebetteten Systemen analysiert werden können. Insbe-sondere können hiermit Schranken für denWorst-Caseer-mittelt werden. Eine andere Methodik ist die Validierungdurch Emulation, wodurch die Funktionalität von System-komponenten unter realen Bedingungen getestet werdenkann. Damit diese Methodik eine hohe Aussagekraft undAkzeptanz bei den Entwicklern erhält, sind im SPP lei-stungsstarke Werkzeuge – die EmulationsumgebungSpy-der – definiert und implementiert worden. Im Folgendensieht man ein Foto und das Blockschaltbild derSpyder-FPGA-Plattform.

Wilhelm Schickard Institut (Prof. Dr. W. Rosenstiel),Universität Tübingen

• Virtex-FPGA (XCV400-2000E)

• Konfiguration und Kommunikation über PCI-Bus

• Erweiterungsstecker mit bis zu 168Verbindungsmöglichkeiten

• On-board Speicher:• 2 x SDRAM: 4Mx32• 2 x SSRAM: 256Kx32

• Debugging• Mictor Logikanalysator Stecker• Chipscope ILA Kerne• 2 LEDs

Im Rahmen der Komponentenbasierten Entwicklungeingebetteter Systeme wurde ein eingebetteter Webserver( IAS-WebStack) eintwickelt. Passend zu diesem Webser-ver wurde eine kostengünstige Mikrocontrollerplattform,das IAS-WebBoard, realisiert, das hier abgebildet ist.

Institut für Automatisierungs- und Softwaretech-nik (Prof. Dr. P. Göhner), Universität Stuttgart

Ziel der Arbeiten der Universität Paderborn war es,das Betriebssystem und insbesondere das Kommmunika-tionssystem den Anforderungen der Anwendung entspre-chend anzupassen. Der Ansatz zeichnet sich dadurch aus,dass Betriebssystem und Kommunikationssystem aus ei-nem Baukasten kleinerer Objekte zusammensetzen. Da-bei werden nur die Elemente integriert, die wirklich be-

iii

nötigt werden. Aus unterschiedlichen Alternativen werdendie optimalen Lösungen ausgewählt, wie die folgende Ab-bildung zeigt.

Heinz Nixdorf Institut (Prof. Dr. F. Rammig), Universi-tät Paderborn

bedingungen des fertig konfigurierten Systems vor sei-ner Laufzeit zu überprüfen. Es werden Betriebsmittelbe-legungspläne erstellt und die Verzögerungs- und Latenz-zeiten der Kommunikation berechnet.

Im Projekt TEReCS wurden hierfür Verfahren undWerkzeuge entwickelt. Durch den Einsatz unseren Me-thoden wird die Zeit, die zur Erstellung eines ferti-gen Kommunikationssystems benötigt wird, erheblichreduziert. Die Wiederverwendung von Code aus ei-ner Bibliothek (DREAMS) und die Offline-Überprüfungvor dem endgültigenTargeting sind wichtige Beiträ-ge zur Verbesserung derTime-to-MarketEigenschaft beider Produktentwicklung für verteilte eingebettete Syste-me.

Bei diesem Ansatz hat sich herausgestellt, dass durchKonfigurierung von Software-Komponenten widersprüch-liche Zielsetzungen (z.B. zwischen Performanz und Fle-xibilität) hochgradig justierbar werden [2]. Gleichzeitigkonnte durch die Anwendung von Entwurfsprinzipien desHardwareentwurfs auf die Konfigurierung und den Aufbauder Bibliotheksplattform gezeigt werden, dass Betriebs-systeme als Vermittler zwischen Software und Hardwarenicht als statisch fest angesehen werden müssen, sondernsich vielmehr den Gegebenheiten anpassen können.

2. Problemstellung

Bei verteilten eingebetteten Systemen laufen auf je-dem Knoten unterschiedliche Prozesse. Diese benöti-gen dann unterschiedlichste Betriebssystemfunktionenund Hardware-Geräte. Oft werden solche verteilten Sy-steme aber auf der gleichen Hardwareplattform basie-rend implementiert. Zudem wird deshalb auch auf allenKnoten das gleiche monolithische Betriebssystem ein-gesetzt. Hier besteht eine Lücke zwischen der flexiblenProgrammierung der Prozesse und den mehr oder weni-ger statischen Betriebssystemkernen. Diese Lücke wirdmeist dadurch geschlossen, das Betriebsystem so all-gemeingültig wie möglich zu implementieren (virtuel-le Maschine). Die Dienste, die diese Betriebssystemezur Verfügung stellen, unterstützen möglichst alle un-terschiedlichen Anwendungsszenarien. Hieraus folgertjedoch, dass ein nicht unwesentlicher Teil des Betrieb-systems ungenutzt bleibt oder zumindest für konkreteAnwendungsfälle sehr ineffektiv ist.

Aus diesem Grund werden gerade Betriebssysteme füreingebettete Anwendungen flexibel und konfigurierbar an-geboten. Viele Merkmale und Fähigkeiten können para-metrisiert, hinzugefügt oder entfernt werden. Aber gera-de dieser Vorgang der Konfigurierung muss sehr oft ma-nuell vom Anwendungsprogrammierer geschehen. Jedochist es häufig schwierig für diesen zu entscheiden, welcheOptionen die besten sind oder überhaupt zu seinem An-wendungsfall passen. Der Betriebssystemprogrammiererkennt als Experte die Anwendungsfälle, für die die konfi-gurierbaren Optionen entwickelt wurden. Es war eine Auf-gabe dieses Projekts, das “Expertenwissen” formal zu er-fassen und es für eine automatische Konfigurierung zu nut-zen. Die Flexibilität und Konfigurierbarkeit des Betriebs-

HW Abstraction Layer (HAL)


Hardware

ApplicationApplicationApplicationApplicationApplicationApplicationApplicationApplicationApplicationApplication

Run-Time Platform or

Operating System


Application

Run-Time

Platform

Communication

System

Hardware

Standard:

Many applications are

developed for a static

operating system

Goal:

Optimal adapted

run-time platform

for each application

Abbildung 3. Herausforderung: von statischenBetriebssystemen hin zu hochgradig flexiblenund konfigurierbaren Laufzeitplattformen für ver-teilte eingebettete Systeme

systems soll für den Anwendungsprogrammierer transpa-rent sein.

Dazu wurden einige Werkzeuge entwickelt, mit de-nen es möglich ist, konfigurierbare Laufzeitplattformenfür verteilte eingebettete Systeme zu beschreiben, auto-matisch zu konfigurieren und bezüglich ihrer Realzeit-Eigenschaften zu analysieren.

3. Lösung

In TEReCS wird streng zwischen dem Wissen über dieAnwendung und dem Expertenwissen über die Konfigu-rationsoptionen des Betriebssystems unterschieden. DasWissen über die Anwendung wird als Anforderungsspezi-fikation angesehen. Diese Anforderungsspezifikation dientals Eingabe für den Konfigurationsprozess. Die Anfor-derungsspezifikation besteht im wesentlichen aus einerabstrakten Beschreibung der Anwendung und bestimm-ten einzuhaltenden Eigenschaften (Deadlines). Die An-wenungsbeschreibung spezifiziert dabei welche Betrieb-systemdienste welcher Prozess auf welchem Knoten wannaufruft. Außerdem wird in der Anforderungsspezifikationauch die Hardware-Plattform (CPU-Typen, Kommunika-tionsgeräte) und -Topologie definiert. Es wird eine festeVerteilung von Prozessen auf die Knoten im System vor-ausgesetzt. Insbesondere werden auch die Kommunikati-onsverbindungen zwischen den einzelnen Prozessen mitihren Eigenschaften spezifiziert.

Der komplette gültige Entwurfsraum des konfigurier-baren Betriebssystems wird mit Hilfe eines sogenanntenUND/ODER-Dienstabhängigkeitsgraphen in einer Wis-sensbasis spezifiziert [5]. Der Konfigurationsprozessvervollständigt dieses domänenspezifische Wissen un-ter Zuhilfenahme der Anforderungsspezifikation. Dabeiwird dann eine Konfiguration einer Laufzeitplattform au-tomatisch für ein konkretes verteiltes System erstellt.Diese Integration der Wissensbasen kann als Wissen-stransfer von der Anwendung hin zum Betriebssysteminterpretiert werden.

2

Eine große Klasse eingebetteter HW/SW Syste-me steht nicht nur mit zeitdiskreten Systemen, sondernauch mit kontinuierlichen Prozessen in der Umge-bung in Wechselwirkung, oder enthält selbst konti-nuierliche Teile. Die systematische Entwicklung undinsbesondere das Erfassen von Anforderungen an sol-che diskret-kontinuierliche oderhybride eingebetteteSysteme erfordert Beschreibungstechniken, die es er-lauben, die Wechselwirkung der diskreten und kon-tinuierlichen Aspekte eines Systems unmittelbar zubeschreiben und zu validieren. Sicherheitskritische An-wendungen, wie z.B. das Bremssystem eines Zuges in derAbbildung, erfordern darüber hinaus mathematisch fun-dierte Systembeschreibungen, die als Grundlage fürformale Verifikationsverfahren geeignet sind und im Rah-men des SPP erarbeitet wurden.

Institut für Informatik (Prof. Dr. M. Broy), TechnischeUniversität München

Die Arbeit am Institut für Technik der Informationsver-arbeitung an der Universität Karlsruhe beschäftigte sich

mit der Entwicklung einer durchgängigen Entwurfsmetho-dik für eingebettete Systeme. Die Methodik wurde in ei-ner umfangreichen Fallstudie getestet, bei der der gesamteEntwurfsweg für einen automatischen Probennehmer (Au-tosampler, siehe folgende Abbildung) für ein chemischesAnalysegerät erfolgreich verifiziert werden konnte.

Institut für Technik der Informationsverarbeitung (Prof.Dr. K. D. Müller-Glaser) Universität Karlsruhe

Gegenstand der Arbeit an der Technischen Universi-tät Ilmenau war der modellbasierte Entwurf der Hard-und Software für eingebettete Systeme, die bei innovati-ven Mehrkoordinatenantrieben zur Anwendung kommen.Hier werden Funktionen, die in konventionellen Lösungendurch mechanische Baugruppen ausgeführt werden, durcheingebettete Systeme übernommen. Dabei wurde beson-ders Augenmerk auf Fragen der Validierung und Verifi-kation gelegt. Die folgende Abbildung zeigt die schema-tische Darstellung eines planaren Mehrkoordinatenantrie-bes.

Theoretische und Technische Informatik (Prof. Dr. W.Fengler), Technische Universität Ilmenau

Die Abbildung unten zeigt ein elektrohydrauli-

iv

sches Bremssystem von Continental-Teves, das alsAnwendungsbeispiel für die an der Johann Wolf-gang Goethe-Universität Frankfurt/Main entwickeltenBewertungs- und Analyseverfahren dient. Ziel der Ar-beiten im SPP Projekts waren Bewertungsverfahren, umbestimmte Realisierungsvarianten eines Systems mitein-ander zu vergleichen und mit vertretbarem Zeitaufwandzu einer nahezu optimalen Lösung zu gelangen. Für ei-ne dynamische Bewertung wurde eine Bibliothek zurSimulation gemischt analog/digitaler Schaltungen mit Sy-stemC und ein Konzept zur Modellierung von Toleranzenentwickelt. Diese Arbeit fließt derzeit in die Standardisie-rung von SystemC-AMS ein.

Technische Informatik (Prof. Dr. K. Waldschmidt) Jo-hann Wolfgang Goethe - Universität Frankfurt am Main

Aufgrund von Produktionsschwankungen erfül-len nicht alle gefertigten Systeme die an sie gestelltenAnforderungen. Deshalb muss im Anschluss an die Ferti-gung ein Test durchgeführt werden, um fehlerhafte Teilevor ihrer Auslieferung zu identifizieren und auszusortie-ren. In diesem Projekt wurden Verfahren erforscht, umsolche Tests für analoge Systemkomponenten zu ent-werfen. Ausgangspunkt war dabei die Simulierbarkeitdes Problems am Rechner, um bereits zu einem frü-hen Zeitpunkt des Systementwurfs den Test vorbereitenzu können. Als Ergebnis liegen Verfahren für den prakti-schen Einsatz bereit, die den besonderen Anforderungenbeim Test analoger Komponenten genügen. Insbesonde-re können nun für schwer zugängliche Schaltungen ge-eignete Testmessungen zum Einsatz kommen, die einenzuverlässigen Schluss auf die Funktionstüchtigkeit er-lauben. Die Abbildung unten zeigt die Layoutskizze desGSM-Basisband-Chips von Infineon Technologies im Sie-mens S45 Handy, der analoge (umrandet) und digitaleKomponenten enthält.

Lehrstuhl für Entwurfsautomatisierung (Prof. Dr. K.Antreich), Fakultät für Elektrotechnik und Informations-technik, Technische Universität München

analoges System

20% der Fläche

80% der Kosten

GSM Basisba

Infineon Technol

Der Entwurf von eingebetteten Systemen mit ei-nem Produktionsvolumen mittlerer Stückzahl umfasstin Deutschland einen sehr großen Markt, der internatio-nal steigendem Wettbewerb ausgesetzt ist. Die Arbeitenam Lehrstuhl für Realzeit-Computersysteme der Techni-sche Universität München beschäftigten sich mit der Fra-ge, wie das enorme Optimierungspotenzial, das in derEntwurfsphase dieser Systeme steckt, genutzt wer-den kann. Dazu wurde ein Meta-Modell basierendesFramework entwickelt, dass insbesondere die Explora-tionsphase mit einer strukturierten und differenziertenMethodik unterstützt. Die Abbildung zeigt den vorge-schlagenen Entwurfsablauf.

Lehrstuhl für Realzeit- Computersysteme (Prof. Dr. G.Färber), Technische Universität München

KundePflichtenheft

erzeugt

Ingenieur

Reuse Anforderungen

Lastenheft

erstellt

System Anforderungen

Einsetzbare Komponenten AbhängigkeitenATLAS

schlägt vor zeigt

initialisiert

Ausgewählte Komponenten

verarbeitet

System Entwickler

liest

leitet ab

interagiert

bestimmt

Erfahrung

Der an der TU Braunschweig entwickelte Lösungsan-satz zur Verifikation von Systemperformanz basiert auf derKombination verschiedener Systemmodelle und Verfahren

v

zur Performanzanalyse, so dass Performanzaussagen auchfür komplexe, heterogene Systeme ermöglicht werden, fürdie keine einheitliche Lösung zur Verfügung steht. Hier-zu entstanden im Rahmen des SPP das SPI-Modell sowiedas Werkzeug SymTA/S (Abbildung).

Institut für Datentechnik und Kommunikationsnet-ze (Prof. Dr. R. Ernst), TU Braunschweig

Komplexe eingebettete Systeme wie mobile Kommu-nikationsgeräte, Industriesteuerungen, Medizintechnik,etc. sind von Natur aus meist heterogen. Innerhalb ei-ner Kooperation zwischen der Universität Erlangen,der TU Braunschweig, der ETH Zürich und der Prince-ton University ist das SPI-Modell entstanden, das in derLage ist derartige Systeme zu beschreiben. Das folgen-de Bild zeigt ein Beispiel einer solchen Beschreibung mitihrer Abbildung auf eine reale Architektur.

Lehrstuhl für Hardware- Software-Co-Design (Prof.Dr. J. Teich), Universität Erlangen-Nürnberg

P1

1C

P2

C2

P3

a P1

C1d

P2a

dC2

P2a

sC2

C1s

C1r

r C2

lat P2, 2

lat P2, 1

lat C1, 2

lat C1, 1

lat P1, 1

lat C2, 2

lat P3, 2

lat C2, 1

lat P3, 1

lat P1, 2

Die an der Universität Oldenburg im Rahmen desSPP objektorientierte Co-Simulation für eingebette-te Steuerungssysteme (OOCOSIM) verfolgte das Zielder Entwicklung einer objektorientierten Entwurfsme-thodik für eingebettete Realzeitsysteme. Das Hauptzielwar die Konzeption einer objektorientierten Entwurfsme-thodik für eingebettete Realzeitsysteme, die von der ab-strakten Spezifikation bis zur Implementierung des zuentwickelnden Systems reicht. Von besonderer Bedeu-tung war dabei die Möglichkeit der abstrakten Spezi-fikation, um auch komplexe Systeme beherrschbar zumachen.Die OOCOSIM-Methodik beginnt mit der ab-strakten Modellierung auf Systemebene. Die Abbildungzeigt ein Modell einer Lüfterregelung in der Modellie-rungssprache HRT-HOOD+.

Department für Informatik, Eingebettete Hardware-Software-Systeme (Prof. Dr. W. Nebel) Universität Olden-burg

R Beispiel 1

Direction=hw_to_sw

Protected=off

Type=Temperatur_T

Type=Kommando_T

Protected=off

Direction=sw_to_hw

SY Prozessorlüftungsregelung

IRQ-Number = 12

AlarmS

Starte

Period = 40 ms

Priority = 5

WCET = 1 ms

Period = 20 ms

Priority = 4

WCET = 2 ms

MO

MO

C

AS

ASR_BY_I T

Lüfter_Defekt

C ÜberwachungTemperatur

Kommando

Min_Interval=100ms

hole_temp

setze_temp

setze_komm

hole_komm

Priority_min = 0

Priority_max = 15

Priority_min = 4

Priority_max = 6

Melde

KühlerH

H Messe_Temp

Prüfe_LüfterH

Rg_Lüfter_Geschw

vi

Projekte des Schwerpunktprogramms1. Einleitung

2. Versatile Digital Architecture, Institut für Informatik,Universität Leipzig (Prof. Dr. U. Kebschull)

3. Entwurf und Bewertung eingebetteter Systeme, Wilhelm Schickard Institut, Universität Tübingen (Prof. Dr. W. Rosenstiel)

4. Komponentenbasierte Entwicklung eingebetteter Systeme, Institut für Automatisierungs- und Softwaretechnik, Universität Stuttgart (Prof. Dr. P. Göhner)

5. Entwurf konfigurierbarer, echtzeitfähiger Kommunikationssysteme, Heinz Nixdorf Institut, Universität Paderborn (Prof. Dr. F. Rammig)

6. BeQuest: Beschreibung und formale Qualitätssicherung für eingebettete Systeme, Institut für Informatik, Technische Universität München (Prof. Dr. M. Broy)

7. Durchgängige Entwurfsmethodik dezentraler Steuerungselemente für mechatronischeSysteme in der Automatisierungstechnik (DESSY), Institut für Technik der Informationsverarbeitung, Universität Karlsruhe (Prof. Dr. K. D. Müller-Glaser)

8. Entwurf eingebetteter paralleler Steuerungssysteme für integrierte multi-axiale Antriebssysteme, Theoretische und Technische Informatik, Technische UniversitätIlmenau (Prof. Dr. W. Fengler)

9. Bewertung und Analyse hybrider Systeme, Technische Informatik, Johann Wolfgang Goethe - Universität Frankfurt am Main (Prof. Dr. K. Waldschmidt)

10. Simulationsbasierter Testentwurf analoger integrierter Systemkomponenten, Lehrstuhl für Entwurfsautomatisierung, Technische Universität München (Prof. Dr. K. Antreich)

11. Template-basierte Entwicklung von eingebetteten Systemen, Lehrstuhl für Realzeit-Computersysteme, Technische Universität München (Prof. Dr. G. Färber)

12. Kombination von Sprachen und Berechnungsmodellen für die Synthese eingebetteter Systeme, Institut für Datentechnik und Kommunikationsnetze, TU Braunschweig (Prof. Dr. R. Ernst)

13. SPI-Workbench: Modelle und Verfahren zur Analyse, Synthese und Optimierung von gemischt reaktiv/transformativen eingebetteten Systemen, Lehrstuhl für Hardware-Software-Co-Design, Universität Erlangen-Nürnberg (Prof. Dr. J. Teich)

14. Objektorientierte Cosimulation eingebetteter Steuerungssysteme, Department für Informatik, Eingebettete Hardware-Software-Systeme, Universität Oldenburg (Prof. Dr. W. Nebel)

2

5

9

13

17

21

25

29

33

37

41

45

49

53

1

Einleitung

Das hier zusammenfassend vorgestellte von der DFG geförderte Schwerpunktprogramm “Ent-wurf und Entwurfsmethodik eingebetteter Systeme” hat vor allem die Methodik für den System-entwurf eingebetteter Systeme erforscht und weiter entwickelt, sowie bei konkreten Anwendun-gen exemplarisch eingesetzt.

Als eingebettete Systeme(engl.: embedded systems)bezeichnet man im Allgemeinen elek-tronische Systeme, die in größere Systeme oder Umgebungen integriert sind. Sie werden fürspezielle Anwendungen entworfen und können sowohl aus Mikrocontrollern, als auch aus denfür die jeweilige Anwendung entworfenen Hard- und Software-Komponenten bestehen.

AutomobilindustrieUnterhaltungselektronik

Robotik und AutomatisierungLuft− und RaumfahrtTelekommunikation

Abbildung 1: Beispiele für eingebettete Systeme

Die Kombination von Methodenentwicklung mit exemplarischem Entwurf eingebetteter Sy-steme war ein besonderer Schwerpunkt dieses Schwerpunktprogramms. Der Entwurf eingebet-teter Systeme hat sich zu einem viel beachteten eigenständigen Forschungsgebiet entwickelt,dessen besondere Anforderungen sich aus der Optimierung des Zusammenwirkens heterogenerTeilsysteme ergeben. Dabei kam es in den durchgeführten Forschungsarbeiten nicht nur daraufan, dass das eingebettete System die gewünschte Funktion erfüllt, sondern dass darüber hinausvor allem Anforderungen bezüglich der gewünschten Leistung, der Kosten des Gesamtsystems,der Zuverlässigkeit, der Sicherheit, des Energieverbrauchs usw. erfüllt werden.

Ein wichtiger Punkt ist hierbei die Beherrschung der exponentiell wachsenden Komplexitätsolcher Systeme, deren Entwurf sich erheblich vom klassischen Software-Entwurf für Desktop-Anwendungen unterscheidet. Um derart komplexe eingebettete Systeme mit vertretbaren Kostenund in möglichst kurzer Zeit entwickeln zu können, werden neue Methoden entwickelt, die esdem Entwickler ermöglichen, Entwurfsanforderungen in einer möglichst frühen Phase des Ent-wurfs zu überprüfen, und die Entwurfskosten durch fortschrittliche Entwurfsmethodiken mög-lichst gering zu halten.

2

Neben der technischen Entwicklung eingebetteter Systeme sei auch auf die enorme wirt-schaftliche Bedeutung hingewiesen. Immer stärker entscheidet der Elektronik- und Software-Anteil (also das eingebettete System) über die gesamte Wertschöpfung neuer Produkte (vgl.Abbildung 2). Der Einsatz neuer Methoden im Entwurf komplexer Eingebetteter Systeme istsomit wettbewerbsentscheidend und kann für Betriebe in diesem Sektor überlebenswichtig sein.Typische Beispiele für eingebettete Systeme sind im Telekommunikationsbereich, der industriel-

Abbildung 2: Der relative Anteil der Wertschöpfung in der Automobiltechnik (Quelle: BMWAG)

len Automation und Robotik, der Unterhaltungselektronik, der Luft- und Raumfahrt und insbe-sondere der Automobilindustrie zu finden (Abbildung 1). Neben dem Trend zur Steigerung derKomplexität eingebetteter Systeme, ist auch der Trend zu steigender Kommunikation zwischenden heterogenen Komponenten eingebetteter Systeme und die durch die Mobilität hervorgerufenAnforderungen, wie Miniaturisierung und geringer Stromverbrauch zu beobachten.

Automobil−Industrie

Halbleiter

Automatisierung

ElektronikEntwicklungs−Werkzeuge

Messtechnik, Sensoren

Abbildung 3: Industriepartner im Schwerpunktprogramm

Im Schwerpunktprogramm “Eingebettete Systeme” sind 14 Projekte gefördert worden. Indiesem Zusammenhang entstanden mehr als 100 Publikationen und mehr als 20 Dissertationen.

3

• ETH Zürich (Prof. Thiele)

• EPFL Lausanne (Prof. Vachoux)

• FhG-IIS EAS Dresden (Prof. Schwarz)

• NTNU Trondheim (Prof. Ytterdal)

• Lehrstuhl für Prozessleittechnik PLT, RWTH Aachen (Prof. Epple)

• Universidade do Amazonas, Faculdade de Tecnologia, Manaus, Brasilien(Dr. Lucena)

• Lehrstuhl für Automatisierungstechnik / Prozessinformatik, Bergische Uni-versität Wuppertal (Prof. Vogel-Heuser)

• Federal University of Rio Grande do Sul, Porte Alegre, Brasilien (Prof.Pereira)

• Lehrstuhl für Automaten und Systemtheorie, HU Berlin (Prof. Grohe)

• Fachgebiet für Automatisierungsanlagen und Prozessleittechnik, TU Il-menau (Prof. Sawodny)

• C-Lab Paderborn

• FZI Karlsruhe

• Distributed Systems Technology Centre (DSTC), Australia

• ESO (European Southern Observatory)

Abbildung 4: Kooperationen zu Hochschulinstituten außerhalb des Schwerpunktprogramms

Erheblich zum Erfolg des SPP haben zahlreiche Kooperationen mit Industriepartnern bei-getragen. Dabei waren wichtige Branchen aus den Bereichen Automobilindustrie, Automatisie-rung, Messtechnik und Sensoren, Halbleiter, Elektronik und Entwicklungswerkzeuge vertreten(Abbildung 3). Kooperationen gab es zusätzlich zu deutschen und internationalen Hochschul-und Forschungsinstituten außerhalb des Schwerpunktprogramms (Abbildung 4).

Auf der beiliegenden CD stellen die einzelnen Teilnehmer des Schwerpunktprogramms ih-re Projekte und wichtigsten Ergebnisse zusammenfassend vor. Die Reihenfolge entspricht derReihenfolge der Vorträge beim Abschlusskolloquium des Schwerpunktprogramms, das im Rah-men eines Workshops bei der Robert Bosch GmbH in Leonberg im November 2003 veranstaltetwurde.

4

Versatile Digital Architecture

Carsten NitschInstitut für Informatik (Prof. Dr. U. Kebschull)

Universität Leipzig

1. Einleitung

Vor über 40 Jahren galten Computer noch als etwas Be-sonderes. Riesige Rechenmonster, wie die UNIVAC füll-ten ganze Häuser mit lärmenden Lochkartenlesern, Re-lais, Fernschreibern und ähnlichem Equipment. Wer zudieser Zeit eine Rechenmaschine betrieb, brauchte vielPlatz und eine leistungsfähige Energieversorgung. Kaumjemand glaubte ernsthaft daran, dass die Welt mehr als ei-nige wenige dieser Wunderwerke benötigen wird. Heutewissen wir, dass diese Prognose wahrscheinlich der größ-te Irrtum der Zukunftsforschung war.

Computer sind aus unserem Alltag nicht mehr wegzu-denken. Sie sind in der Arbeitswelt wie auch in Privathaus-halten weit verbreitet. Ein stetiger Preisverfall sorgt da-für, dass die Rechentechnik zum Alltagsgut wird. Im Ge-gensatz zu bekannten Desktopcomputern (Mac, Worksta-tion, PC) verlief die größte technische Revolution jedochweitgehend unbemerkt. Schauen wir uns einmal in unsererWohnung um. Wie viele Mikroprozessoren besitzen wir?Sind es fünf, zehn oder etwa doch viel mehr? Den we-nigsten Menschen ist bewusst, dass in Mobiltelefonen, Di-gitalkameras, Videorecordern und Autos Computer „ver-steckt“ sind. In der Fachliteratur hat sich für diese inte-grierten Systeme der Begriff „Eingebettetes System“ eta-bliert. Wenn wir moderne eingebettete Systeme betrach-ten, so werden folgende Dinge deutlich:

Denken wir einmal kurz darüber nach, welche Wün-sche wir selbst an unsere Geräte, z.B. Mobiltelefone, ha-ben. Diese haben mittlerweile eine eingebaute Kamera,Mikrofon, Kopfhörer und ein schönes farbiges Display, al-so im Prinzip alles, was der Rechner zu hause oder derLaptop auch besitzt. Warum sollte das kleine mobile Ge-rät nicht genauso leistungsfähig gemacht werden wie deroft unhandliche Laptop und trotzdem viele Stunden miteiner Akkuladung funktionieren? Wunschziel ist also einGerät, welches so leistungsfähig und flexibel ist wie „nor-male“ Rechner, welches wir aber problemlos ständig beiuns haben können.

Anderseits müssen wir aber auch die Probleme derHersteller betrachten, welche diese Geräte entwickeln,produzieren und verkaufen müssen. Aus deren Sicht mussein eingebettetes System vor allem ein Kriterium erfüllen– es muß preiswert zu entwickeln und zu fertigen sein. Da-

her ergibt sich die Notwendigkeit eines „Baukastenprin-zips“. Der Entwickler verfügt über eine Sammlung aus-getesteter Teilkomponenten für Video, Audio oder Telefo-nie Hardware. Aus diesen kombiniert er an seinem Ent-wicklungsrechner das fertige System, welches am Ende ineinen Spezialchip „gegossen“ und in die Geräte eingebautwird.

Ziel unserer Arbeiten war, wichtige Methoden zu er-forschen, die dazu beitragen können die beschriebenenWünsche in der Zukunft Wirklichkeit werden zu lassenund einmal Computer zu ermöglichen, welche

• klein, und leistungsfähig sind,

• wenig Strom verbrauchen,

• flexibel an neue Aufgaben anpassbar und letztlich,

• preiswert herzustellen sind.

Aufgrund der hohen Komplexität des Aufgabenfeldes wares natürlich nicht möglich, die Problematik allumfassendzu untersuchen. Wir haben uns daher auf die Untersuchungder allgemeinen Architektur von eingebetteten Systemenund deren Anbindung an ein Netzwerk beschränkt, wiedies im Abschnitt 3 detailierter beschrieben wird.

2. Situation am Anfang des Schwerpunkt-projektes

Zu Beginn des Projektes war die Welt der eingebettetenSysteme weit von den Visionen entfernt, wie sie in der Ein-leitung beschrieben wurden. Es gab schon damals Mobil-telefone, Video Set-Top Boxen, elektronische Übersetzerund vieles mehr. Die Geräte waren durchaus leistungsfä-hig, allerdings jeweils auf einen bestimmten Zweck ein-geschränkt. Das Telefon war nur zum Telefonieren zu ge-brauchen, das elektronische Wörterbuch nur zum Überset-zen usw. Wer viele Funktionen benötigte, musste auch ent-sprechend viele Geräte mit sich herumtragen. Warum wardies so? Um die Problematik zu verstehen, müssen wirkurz analysieren, wo die besonderen Probleme liegen eineingebettetes System zu entwickeln.

• Leistungsfähigkeit und Stromverbrauch: Aus Er-fahrung wissen wir, dass die Leistungsfähigkeit vonDesktopcomputern vor allem dadurch gestiegen ist,dass die Prozessoren immer schneller wurden. Waren

5

„früher“ Taktfrequenzen von 20MHz State–of–the–Art, so sind wir mittlerweile im Gigahertz–Bereichangelangt. Dafür können heute die Maschinen auchin Echtzeit Videos bearbeiten, was vorher undenkbarwar. Allerdings bringen schnelle Prozessoren ein Pro-blem mit sich. Der Stromverbrauch dieser Chips istsehr hoch und es passiert oft, dass das gerade gekauf-te tolle Multimedia Notebook nach nur einer Stun-de wegen des leer gelaufenen Akkus aufgibt. Wieman sieht, ist es also nicht möglich, einfach schnel-le Prozessoren in mobile Geräte zu bauen. Dies giltschon für Notebooks und verschärft sich für einge-bettete Systeme mit wenig Platz für den Akku nochmehr. Um dem Energieproblem zu entkommen, wer-den daher eingebettete Systeme schon immer oft mitSpezialchips ausgerüstet. Diese können im Gegensatzzum „normalen“ Prozessor oftmals nur wenige spe-zielle Aufgaben lösen, dies jedoch sehr schnell undmit geringem Energieverbrauch.

• Flexibilität und Kosten: Wie eben beschrieben,brauchen mobile eingebettete Systeme Spezialhard-ware, um leistungsfähig zu sein und dennoch we-nig Energie zu verbrauchen. Allerdings lassen sichauf diesen Bausteinen nur eine begrenzte Men-ge an Funktionen unterbringen. Dies schränkt na-türlich die Benutzbarkeit des Gerätes ein. Wennein MP3 Player einen Chip besitzt, der die Musik-stücke nur abspielen kann, so ist es nicht möglich dasGerät auch als Recorder zu benutzten. Dazu müss-ten nämlich auch die dazu notwendigen Funktionenauf den Chip „gebrannt“ werden, was ihn natür-lich teurer macht. Wie man leicht sehen kann, ist esaus Kostengründen erst einmal nicht praktikabel je-de gewünschte Funktion im Chip bereitzustellen.Ein weiteres Problem besteht darin, dass sich klas-sische Chips, so genannte ASICs, nur bei ihrer Her-stellung programmieren lassen und später nicht mehrveränderbar sind.

Zu Beginn des Schwerpunktprogramms wurden die meis-ten eingebetteten Geräte mit den eben beschriebenenASICs bestückt. Dennoch gab es schon damals eine Al-ternative zum fest verdrahteten Chip. VerschiedeneHersteller boten so genannte FPGA Chips (Field Pro-grammable Gate Array) an. Im Unterschied zu denASICs kann man FPGAs immer wieder neu programmie-ren. Je nach Programmierung kann solch ein Chip dannzur Wiedergabe von Musik oder auch von Videos die-nen. Trotz dieser Programmierbarkeit ist er dabei jedochfast genauso stromsparend und schnell wie die klassi-schen ASICs.

An dieser Stelle wird klar, dass sich ein flexibles undstromsparendes Gerät realisieren lässt, wenn man es mitFPGAs oder anderer programmierbarer Hardware ausstat-tet. Obwohl diese Technik schon vor dem Schwerpunkt-programm existierte, wurde sie zu diesem Zwecke kaum

eingesetzt. Der Grund dafür war, dass es kaum Untersu-chungen der Methoden gab, auf welche Weise man dieFPGAs im Gerät des Anwenders geeignet programmierenkann. Im obigen Abschnitt wurde gezeigt, dass es nichtmachbar ist, eine sehr große Anzahl von Funktionen „amStück“ in einen Chip zu giessen. Dies gilt natürlich fürFPGAs genau so wie für ASICs, da auch die program-mierbaren Schaltkreise nur eine begrenzte Kapazität ha-ben und sich die Preise mit steigender Kapazität sehr starkerhöhen.

Wir haben daher im Schwerpunktprogramm nach Lö-sungen gesucht, wie man FPGAs nach Bedarf program-mieren kann. Ziel war es, eine Architektur zu finden, dieselbständig erkennt, welche Funktion sie ausführen muss(z.B. Musik abspielen), selbständig einen dafür geeigne-ten Programmcode für das FPGA findet und diesen insFPGA lädt, damit er anschließend benutzt werden kann.Selbstverständlich soll dies für den Benutzer weitgehendunbemerkt geschehen. Selbst wenn er verschiedenste Pro-gramme aufruft, also telefoniert, fotografiert oder Brie-fe schreibt, soll sich der Spezialchip in Form des FPGAständig blitzschnell umprogrammieren und somit stets alsleistungsfähiger, energiesparender aber anpassungsfähigerSchaltkreis arbeiten.

3. Unsere Arbeiten: Die Versatile Digital Ar-chitecture

Um die Probleme zu lösen, haben wir Methoden und Mo-delle für eine neuartige Generation von eingebetteten Sys-temen entwickelt. Wir nennen diese Architektur „VersatileDigital Architecture“ (VDA).

Um die oben beschriebene Methoden bereitzustellen,mussten wir folgende Hauptprobleme lösen:

1. Wie muss das eingebettete System aufgebaut sein?

2. Wie findet das eingebettete System die jeweils benö-tigten Programmkomponenten? Wie lassen sich fürdiesen Zweck Internet Technologien verwenden?

Der erste Schwerpunkt wird im folgenden Abschnitt„VDA Client“ beschrieben und beschäftigt sich mit demeingebetteten System selbst, welches der Benutzer bei sichhat, z.B. sein Mobiltelefon. Der zweite Schwerpunkt be-schreibt die Methoden, diesen Client in ein Netzwerk wiedas Internet zu integrieren. Es werden Methoden vor-gestellt, die den Client mit einem Management Systemvernetzen. Dieses besteht aus einer Vielzahl von Ser-vern. Diese Server sind leistungsfähige Rechner, ähnlichwie Webserver. Im Gegensatz zum Webserver ermög-licht das Management System aber die automatischeSuche nach oben beschriebenen Programmkomponen-ten.

6

3.1. VDA Client – Das eingebettete System

Rekonfigurierbare Hardware

CPUFlash

RAM

Netzwerk Interface

In der Abbildung ist schematisch dargestellt, aus welchenKomponenten unser Client aufgebaut ist. Neben den „nor-malen“ Bestandteilen eines jeden Computers wie Spei-cher und Prozessor ist der bereits beschriebene FPGAChip (hier Rekonfigurierbare Hardware) zu erkennen. DasFPGA ist das Herzstück unseres eingebetteten Systemsund die Voraussetzung für Geschwindigkeit und sparsa-men Stromverbrauch. Es gibt jedoch noch eine weiterewichtige Baugruppe, die Netzwerkschnittstelle. Dies kanneine Infrarot Schnittstelle sein, wie sie bereits in vielenMobiltelefonen verwendet wird. Möglich ist aber auch,moderne Funkanbindungen wie Bluetooth oder schnel-les Wireless LAN zu verwenden. Welche Technik kon-kret verwendet wird hängt hauptsächlich damit zusam-men, welchen Preis das Gerät haben darf. Allen gemein-sam ist aber ihr Zweck, nämlich der Datenaustausch mitden Servern des Management Systems. Wie dies geschiehtund auf welche Weise die unterschiedlichen Netzschnitt-stellen unterstützt werden, wird im Abschnitt „Manage-ment System“ beschrieben.

Wie funktioniert unser Client? Stellen wir uns vor, derBenutzer hat z.B. einen Web Browser geöffnet und besuchteine Seite, die multimediale Dienste anbietet. Vorstellbarist hier z.B. eine News Webseite, auf der auch Audio-kommentare oder Videosequenzen angeboten werden. DerAnbieter möchte diese Daten natürlich so bereit stellen,dass sie sich so schnell wie möglich herunterladen lassen.Zu diesem Zwecke existiert eine große Vielfalt an Kom-primierungs Technologien, die ständig verbessert werden.Sinnvollerweise benutzt der Anbieter die neueste Versiondieser Kompressionsverfahren. Allerdings muss das Sys-tem des Benutzers, der VDA Client, diese Daten auch ver-stehen können, um sie darzustellen. Er benötigt also nebenden Multimedia Inhalten selbst auch noch Programmcodefür den Prozessor und das FPGA. Aufgrund der Vielfaltvon verschiedenen Prozessoren und FPGAs kann es nunnicht die Aufgabe der Nachrichten Webseite sein, auchnoch all diese Programme bereitzustellen. Vielmehr lie-gen diese auf den Servern des Management Systems. DerClient stellt also eine Anfrage an das System, in dem er be-schreibt, welchen Programmcode er benötigt (z.B. Versi-on 4.1 der Komprimierungs Software) und teilt weiterhin

mit, welchen Prozessor, welchen FPGA Typ usw. er ent-hält. Das System sucht dann nach geeignetem Code undschickt diesen an den Client. Dieser kann ihn von nunan benutzen und z.B. den Film darstellen. Um nicht je-des mal das Management System kontaktieren zu müssen,besteht die Möglichkeit, den Programmcode lokal im Ge-rät zu speichern.

3.2. Das Management System

Client

Rekonfigurierbare Hardware

CPUFlash RAM

Netzwerk Interface

(1) Auswahl der Anwendung (2) Was wird gebraucht?

<options>

<application> <spectype>external</spectype> <url><http://myserver.com/application.xml></url> </application>

<architecture> <id>123456789</id> <cpu> <family>SuperH</family> <type>SH3</type> <clock>130Mhz</clock> </cpu <os> <name>vxworks</name> </os> </architecture>

</options>

XML Dokument

Embedded Management

(3) Komponenten-Suche(4) Konfiguration & Start

Bean

DirectoryServices

Internet

Um den Aufbau des Management Systems zu verstehen,muss man sich zuerst einmal vergegenwärtigen, welcheAnforderungen auf ein solches System zukommen. Esexistiert eine sehr große Anzahl verschiedener eingebette-ter Systeme. Auch wenn wir in der Definition des VDAClient festgelegt haben, dass ein solches System übereinen Prozessor, programmierbare Hardware, ein Netz-werkinterface usw. verfügen muss, haben wir aus praxis-bezogenen Gründen bewusst offengelassen, von welchenHerstellern die Chips sein sollen und welche konkretenTypen verwendet werden. Das Management System mussdaher in der Lage sein, eine sehr große Versionsvielfalt zuverwalten. Ein weiteres Problem erkennt man, wenn mansich die große Anzahl von eingebetteten Systemen vor Au-gen hält. Allein Mobiltelefone existieren zu vielen Millio-nen.

Aus diesen Gründen kann kein zentraler Server al-lein die Management Aufgaben übernehmen. Selbst diebesten Hochleistungscomputer wären damit überfordert.Vielmehr muss die Aufgabenflut an viele einzelne Ser-ver verteilt werden. Wichtig ist dabei, dass diese Vertei-lung gleichmäßig erfolgt. Wir verwenden daher für un-ser Management System ein dezentrales Topologie Mo-dell. Neben den eben beschriebenen Lastproblemen galtes aber noch weitere Anforderungen zu erfüllen. So mussdas System in der Lage sein, Fehler während der Über-tragung erkennen und korrigieren zu können. Es muss si-chergestellt werden, dass z.B. nur vertrauenswürdige Ser-ver angesprochen werden und dass keine „Hackermaschi-nen“mit gefälschten Adressen Viren statt Programme ver-teilen. Glücklicherweise existierten bereits Lösungen, diezumindest einen Teil der beschriebenen Probleme schongelöst haben. Um das Rad nicht neu erfinden zu müssen,haben wir uns entschieden, auf solch einer Lösung aufzu-

7

bauen und sie so zu erweitern, dass sie unseren Ansprü-chen gerecht wird.Diese Technologie ist unter den Namen „Enterprise JavaBeans“ (EJB) bekannt. EJB baut auf der Java Technolo-gie der Firma SunTM auf. Java hat den Vorteil, dass einin dieser Sprache geschriebenes Programm auf den unter-schiedlichsten Systemen läuft, die Java unterstützen. Al-lerdings wird dieser Vorteil damit erkauft, dass man stetsetwas mehr an Prozessorleistung und Speicher benötigt.Für kleine eingebettete Systeme ist daher Java Unterstüt-zung aus Kostengründen nicht immer möglich. Wir habenallerdings eine Möglichkeit gefunden auch diese Gerätean unser System anzubinden. Dazu haben wir sogenann-te „Accesspoints“ in unser System integriert. Ein Access-point ist ein Computer, der sowohl Java beherrscht als auchmit dem einfachen Client kommunizieren kann. Beispiels-weise könnte der heimische Internet PC als Access Pointdienen. Das elektronische Notizbuch des Benutzers könn-te dann über eine einfache Infrarot Schnittstelle mit demPC kommunizieren und dieser reicht diese Anfragen dannzum Management System weiter. Access Points kann mansich also am besten als Vermittler zwischen eingebettetenSystem und Management Schicht vorstellen.

4. Ergebnisse/Erfahrungen

Wir haben mehrere einfache Prototypen entwickelt undmit ihnen unser System unter Laborbedingungen getestet.

Client Server

Thin Client(SH3 Board)

Access Point(Linux Box)

HTTPS Server

EJB Client EJB Server

opt.xmlres.xml

Eine Aufgabe der Tests war herauszufinden, wie das Sys-tem funktioniert, d.h. z.B. wie schnell es auf Anfragenreagiert. Als eingebettetes System diente dazu eine Expe-rimentierplatine mit einem Prozessor (SH3 von Hitachi)und einem FPGA (Virtex von Xilinx). Auf diesem Systemlief kein Java. Daher erfolgte die Kommunikation mit demManagement System über einen Access Point, in unseremFall einen PC. Die Kommunikation vom Experimentier-board zum PC erfolgte in HTTP, dem gleichen Protokoll,wie es auch im WWW verwendet wird. Der PC wieder-um reichte die Daten an das Management System weiter,welches durch einen EJB Server bereitgestellt wurde. Zieldes Experiments war, dass das eingebettete System Pro-grammcode anforderte, um das FPGA zu programmieren.Diese Anfrage erging an das Management System, wel-ches dann aus einer Datenbank die Code Komponente aus-wählte, die auf dem FPGA lauffähig war.

• Ergebnis: Die Zeit, die für Anfrage, Übertragung,verschiedene Initialisierungen und Datenbankabfra-gen benötigt wurde, lag bei ca. 1 Sekunde.

Ein anderes Experiment beschäftigte sich mit den Mög-lichkeiten der Energieeinsparung. Dazu programmiertenwir ein Testprogramm einmal für den Mikroprozessor undeinmal für das FPGA. Bei den anschließenden Probeläu-fen haben wir gemessen, wie groß die jeweiligen Rechen-zeiten sind und zum anderen den Stromverbrauch festge-stellt.

• Ergebnis: Im Experiment war das FPGA ca.2400mal schneller als der einfache Prozessor. Umden Stromverbrauch zu vergleichen haben wir er-rechnet, wieviel Energie (gemessen in Wattsekun-den) der Prozessor bzw. das FPGA pro „Rechen-schritt“ verbrauchen. Dabei mussten wir feststellen,dass das FPGA (1 × 10−8 Ws) trotz höherer Ge-schwindigkeit nur ca 1/1000 der Energie verbrauchtwie der Prozessor (1×10−5 Ws).

5. Fazit

Wir haben ein System aus Methoden entwickelt, die es er-möglichen können, zukünftige eingebettete Systeme ge-nau so leistungsfähig und flexibel zu gestalten wie es bis-her nur mit herkömmlicher Rechentechnik möglich ist.Unsere Labortests haben gezeigt, dass diese Metho-den prinzipiell funktionieren und daher erfolgverspre-chend sind. Zukünftige Arbeiten werden zum Ziel haben,dieses System weiter zu verbessern. Insbesondere wür-den wir uns auf Kooperationen mit Industriepartnernfreuen, um das System auch im praktischen Einsatz tes-ten zu können.

6. Weitere Informationen

Im Rahmen dieser Zusammenfassung konnte das Projektnatürlich nur kurz umrissen werden. Ausführliche Infor-mationen finden sich in unseren Veröffentlichungen:

Literatur

[1] NITSCH, LARA, KEBSCHULL: A Novel Design Technolo-gy for Next Generation Ubiquitous Computing Architectu-res. In: IPDPS RAW, Nice, 2003.

[2] LANGE, KEBSCHULL: Virtual Hardware Byte Code as aDesign Platform for Reconfigurable Embedded Systems. In:Proceedings of the Design Automation and Test in EuropeConference (DATE2003), München, 2003.

[3] NITSCH, KEBSCHULL: The Use of Runtime ConfigurationCapabilities for Networked Embedded Systems. In: Procee-dings of the Design Automation and Test in Europe Confe-rence (DATE2002), Paris, 2002.

[4] NITSCH, KEBSCHULL: Konzeption einer virtuellen, offe-nen, echtzeitfähigen Systemarchitektur. In: Workshop Mo-delltransformation und Werkzeugkopplung, Braunschweig,2001.

8

Entwurf und Bewertung eingebetteter Systeme

Axel Siebenborn, Stephen SchmittWilhelm-Schickard Institut für Informatik (Prof. Dr. W. Rosenstiel)

Universität Tübingen

Zusammenfassung

Beim Entwurf eingebetteter Systeme wird eine Evalu-ierung des Systems zu einem möglichst frühen Zeitpunktim Entwurfsprozess angestrebt. Im Folgenden werden un-terschiedliche Methodiken vorgestellt, die eine Überprü-fung der an das System gestellten Anforderungen zu ei-nem frühen Zeitpunkt im Entwurfsablauf erlauben. ZumEinen werden analytische Methoden besprochen, mit de-nen die zeitlichen Eigenschaften von Software in einge-betteten Systemen analysiert werden können. Insbesonde-re können hiermit Schranken für denWorst-Caseermitteltwerden. Eine andere Methodik ist die Validierung durchEmulation, wodurch die Funktionalität von Systemkompo-nenten unter realen Bedingungen getestet werden kann.Hierzu wurde eine Emulationsumgebung entwickelt.

1. Einleitung

Eingebettete Systeme unterscheiden sich in verschiede-nen Bereichen von sogenannten Desktop-Systemen. Siesind Teil eines größeren Systems, in das sieeingebet-tet sind und mit dem sie unter mehr oder weniger stren-gen Zeitbedingungen interagieren. Die Evaluierung einessolchen Systems zu einem möglichst frühen Zeitpunktim Entwurfsprozess ist ein wesentlicher Faktor hinsicht-lich der Wirtschaftlichkeit eines Entwurfs. Zum Einenkönnen teure Redesignzyklen vermieden, und die Zeitbis zur Markteinführung eines Produkts (time to mar-ked) verkürzt werden. Zum Anderen kann eine frühzeiti-ge Evaluierung die Auswahl geeigneter Systemkomponen-ten vereinfachen und eine Überdimensionierung einzelnerKomponenten vermeiden. Im Besonderen müssen hier-bei aber die Zeitbedingungen betrachtet werden, da derenVerletzung zu Fehlfunktionen und Systemausfällen führenkann, was in sicherheitsrelevanten Bereichen schwerwie-gende Folgen nach sich ziehen kann. Hierbei sind heuri-stische Verfahren, wie Simulation nicht ausreichend, danur schwer alle möglichen Situationen – Eingabedaten desSystems – betrachtet werden können. Durch analytischeVerfahren können Grenzen für denWorst-Caseangegebenwerden, die für alle möglichen Kombinationen der Einga-bedaten Bestand haben und somit das Einhalten der Zeit-schranken garantieren. Diese analytisch bestimmten Gren-zen helfen eine Überdimensionierung des Systems zu ver-meiden.

Durch Emulation kann die Funktionalität von System-komponenten im System überprüft werden, ohne dass die-se bereits vorhanden sind. Der Vorteil gegenüber der Si-mulation liegt hier darin, dass keine Testvektoren gene-riert werden müssen.

Im folgenden Abschnitt wird auf die analytische Be-stimmung der zeitlichen Eigenschaften von Software ineingebetteten Systemen eingegangen. Hierbei wird zuerstdie Bestimmung derWorst-Case Execution Time(WCET)von Softwareteilen, die ohne Unterbrechung ausgeführtwerden betrachtet. Darauf folgend wird die Untersuchungdes Einflusses blockierender Kommunikation durch Kom-munikationsanalyse erläutert. Abschnitt 3 behandelt dieEmulation mit dem im Förderzeitraum entstandenen Emu-lationssystemSpyder .

2. Analytische Bestimmung der zeitlichenEigenschaften von Software in eingebette-ten Systemen

2.1. Statische Laufzeitanalyse

Eingebettete Systeme sind oft reaktive Systeme, dieInformationen in einem bestimmten Zeitraster bearbeitenund Ergebnisse zur Verfügung stellen müssen. AnalytischeLeistungsbewertung von Softwareimplementierungen aufeingebetteten Mikrocontrollern sind deshalb von essenzi-eller Bedeutung. DieStatische LaufzeitanalyseverknüpftInformationen über den möglichen Programmfluss mitInformationen über die Prozessorarchitektur, um darausworst-case-Laufzeitabschätzungen zu generieren. Hierbeisind im Allgemeinen zwei Teilaspekte zu betrachten.

• Eine genaue Modellierung der Eigenschaften des ein-gebetteten Prozessors.

• Die Ermittlung des Pfades im Programm, der zurlängsten Ausführungszeit führt.

Eigenschaften moderner Prozessoren wie Caches, Pi-pelines und Sprungvorhersage, tragen in hohem Maßezur Erhöhung der Verarbeitungsgeschwindigkeit bei. Die-se Eigenschaften müssen jedoch auch bei der Analyse be-rücksichtigt werden, um ausreichend genaue Ergebnissezu erzielen. Werden Prozessorarchitekturen mit Befehls-und Daten-Caches eingesetzt, so variieren die Laufzeitendurch einzelne Programmteile, je nachdem ob sie schonim schnellen Cache-Speicher vorhanden sind (Cache-Hit),oder noch aus dem langsamen Haupt-Speicher geladen

9

werden müssen (Cache-Miss). Bei der Statischen Lauf-zeitanalyse muss dementsprechend die Anzahl an Hits undMisses möglichst genau bestimmt werden.

Durch Pipelines und parallele Ausführungseinheitenwird eine überlappende Befehlsabarbeitung, bzw. paralle-le Befehlsverarbeitung erreicht. Bei der Analyse muss die-se mögliche Parallelität betrachtet werden. Hierbei müs-sen jedoch Datenabhängigkeiten zwischen Befehlen be-rücksichtigt werden, z.B. wenn der Operand eines Be-fehls von dem Ergebnis eines vorherigen Befehls abhängt.Durch Verzweigungen (Sprünge) wird diese überlappen-de Befehlsverarbeitung unterbrochen, weshalb in moder-nen Prozessoren Verfahren zur Vorhersage des Sprung-ziels eingesetzt werden. Ziel dieser Sprungvorhersage istdie richtige Vorhersage des Sprungziels in möglichst vie-len Fällen, um eine Unterbrechung der Pipeline zu ver-meiden. Bei der Laufzeitanalyse muss deshalb bestimmtwerden, in wievielen Fällen die Vorhersage der Sprung-vorhersage richtige und falsche Ergebnisse liefert, da sichdies auf die Laufzeit eines Programms auswirkt. Bei derBerücksichtigung all dieser Eigenschaften ist jeweils derWorst-Case, also der Fall zu betrachten, der zur maxima-len Ausführungszeit führt.

Abbildung 1. Steuerflussgraph eines Beispiel-programms

Abbildung 1 zeigt einen Flussgraphen für eine einfa-che Funktion auf der Basis des Maschinencodes auf dereinen Seite und die bei der Analyse zu betrachtenden Ei-genschaften des eingebetteten Prozessors auf der anderenSeite. Die Knoten des Graphen stellen die Basisblöcke, dieKanten die möglichen Programmpfade dar. Die Ausfüh-rungszeiten der Basisblöcke wird durchci und die Anzahlder Durchläufe durch die einzelnen Basisblöcke durchxi gekennzeichnet. Die Worst-Case-Ausführungszeit er-rechnet sich durch Aufsummieren aller Ausführungszei-ten beim Durchlaufen des Worst-Case-Ablaufpfades. Die-ser Algorithmus widerspiegelt sich in der Zielfunktion desganzzahligen linearen Optimierungsproblems.

twcet = max∑i

cixi (1)

Die Nebenbedingungen des Optimierungsproblems wer-den aus der Struktur des Flussgraphen gewonnen. Im Fallvon Schleifen sind weitere Nebenbedingungen nötig, diedie Anzahl der Schleifeniterationen begrenzen.

Wie bereits erwähnt wurde, unterscheidet sich die Aus-führungszeit eines Basisblocks erheblich, je nachdem obdie Befehle aus dem Cache oder aus dem Hauptspeichergeladen werden müssen. Dementsprechend muss die Ziel-funktion des Optimierungsproblems dahingehend erwei-tert werden, dass die unterschiedlichen Ausführungszeitenberücksichtigt werden:

twcet = max∑i(chit

i xhiti +cmiss

i xmissi ) (2)

Zur Lösung des Optimierungsproblems werden nun zu-sätzliche Nebenbedingungen benötigt, um die Anzahlder Cache-Hitsxhit

i und die Anzahl der Cache-Missesxmiss

i zu bestimmen. Diese werden aus zusätzlichen Gra-phen, dem Cache-Konfliktgraph (CCG) und demCache-Zustandsübergangsgraph, gewonnen. Detailsüber das Verfahren können den entstandenen Publika-tionen [1, 2, 3, 4] und der Dissertation mit dem Titel“Analytische Modellierung und Bewertung von Prozes-soren in eingebetteten Systemen” [5] entnommen wer-den.

In Abbildung 2 sind die Ergebnisse von Laufzeitmes-sung und WCET-Analyse für den Infineon C167 undverschiedene Benchmarkprogramme vergleichend dar-gestellt. Die Abschätzung ist in allen Fällen konservativ(Worst-Case-Bedingung) und der Fehler verhältnismä-ßig klein. Zum Vergleich ist in Abbildung 3 das Analyse-ergebnis für den PowerPC MPC750 dargestellt. Mit denneuen Verfahren für die Architekturmodellierung konn-ten auch für diesen relativ komplexen Prozessor guteAnalyseergebnisse erzielt werden.

0

2000

4000

6000

8000

10000

12000

14000

16000

check_data circle jfdctint line

Zyk

len Messung

Analyse

Abbildung 2. Vergleich zwischen Messung undAnalyse für den Siemens C167

In diesem Zusammenhang ist das prototypische Werk-zeug GROMIT entstanden. Prozessoreinstellungen könnenhierbei sehr einfach über eine graphische Oberfläche ein-gestellt werden und Worst-Case-Laufzeiten für Program-me auf diesen Prozessoren berechnet werden.

2.2. Kommunikationsanalyse bei parallelen Pro-zessen

Oft sollen eingebettete Systeme mehrere parallele Auf-gaben erfüllen, die dabei dennoch zu einander in Bezie-

10

0

5

10

15

20

25

30

35

jfdctint

linelinpack

matcnt

matcnt2

motion

piksrtsort

cycl

es/in

stru

ctio

n

Messung

Analyse

Abbildung 3. Vergleich zwischen Messung undAnalyse für den Motorola MPC750

hung stehen. Es herrscht also ein hoher Grad an Neben-läufigkeit. Zur Analyse nebenläufiger Prozesse, die sichin ihrem Lauzeitverhalten durch blockierende Kommu-nikation gegenseitig beeinflussen, wird ein neuer Ansatzzur Kommunikationsanalyse, mit dem im vorherigen Ab-schnitt beschriebenen Ansatz zur Bestimmung von Worst-Case-Laufzeiten von Software-Tasks verknüpft. Das be-schriebene Verfahren zur Bestimmung von Worst-Case-Laufzeiten ist nur auf einzelne Tasks anwendbar, die unter-brechungsfrei ausgeführt werden. Kommunikationen, diedie Ausführung blockieren, können hierbei nicht berück-sichtigt werden. Der in [6] beschriebene Ansatz, erlaubtdie Analyse von Systemen, bestehend aus parallelen Pro-zessen, wobei Kommunikationen die Ausführung der ein-zelnen Prozesse blockieren können. Für die Analyse wer-den die Kommunikationspunkte in den einzelnen Prozes-sen, sowie die Latenzzeiten zwischen den einzelnen Kom-munikationspunkten berücksichtigt. Zur Ermittlung dieserLatenzzeiten wird das bereits beschrieben Verfahren zurWCET-Analyse herangezogen. Das im Folgenden vorge-stellte Verfahren stellt dementsprechend eine Kombinationaus zwei Verfahren dar, die in unterschiedlichen Problem-domänen angesiedelt sind: Mit der statischen Laufzeitana-lyse werden minimale und maximale Laufzeiten für Code-Sequenzen mit Kontrollstrukturen, einschließlich Schlei-fen mit bekannten Grenzen analysiert. Für die Kommuni-kationsanalyse hingegen sind nur die Kommunikationenund das Laufzeitverhalten zwischen diesen Kommunikati-onspunkten interessant. Aus diesem Grund wird das Pro-blem in einem ersten Schritt in Teilprobleme für die ein-zelnen Bereiche zerlegt (Abbildung 4). Die Kommunikati-onsstruktur des Systems wird durch den Kommunikations-Abhängigkeits-Graph (KAG) dargestellt, wobei die Kom-munikationen die Knoten dieses Graphen repräsentieren.Kanten zwischen zwei Knoten im Graph existieren, wennim Kontroll-Fluss-Graph des Prozesses ein Pfad existiert,der die entsprechenden Kommunikationen verbindet, oh-ne jedoch weitere Kommunikationen miteinzuschließen.Auf Grundlage des KAG kann eine Bedingung formu-liert werden, die bei einseitig blockierender Kommunika-tionen erfüllt sein muss, um die beteiligten Prozesse zusynchronisieren. Es ist leicht einsehbar, dass eine Syn-

Kommunikations-Analyse

WCET-Analyse

Worst-caseZeit-Verhalten

KontrollflussKontrollfluss

KommunikationsKommunikations--strukturstruktur

?

ParalleleParallele ProzesseProzesse

ExecutionUnits

Register Instructionset

Pipeline

µC Architecture

Problem-aufteilung

F1 F2 F3

F5 F4

F1 F2 F3

F5 F4

Abbildung 4. Problemaufteilung auf die zweiBereiche Kommunikationanalyse und WCET-Analyse

chronisation nur dann stattfindet, wenn der blockierendeKommunikationspartner früher erreicht wird, als der nicht-blockierende Kommunikationspartner, so daß der Kom-munikationspunkt von den beteiligten Prozessen gleich-zeitig verlassen wird. Diese Bedingung lässt sich durchEinführung einer Schlupfvariablen als Gleichung darstel-len. Ziel dieser Betrachtung ist die Anzahl an Wartezyklenin den Empfangsknoten zu bestimmen. Ein negatives Er-gebnis bedeutet eine Verletzung der Synchronisationsbe-dingung und die betrachtete Kommunikation ist dement-sprechend kein Synchronisationspunkt.

Synchronisationspunkte setzen parallele Prozesse zeit-lich zueinander in Beziehung und erlauben so eine Be-stimmung derWorst-Case Response Time(WCRT) einessolchen Systems. Zur Bestimmung der Synchronisations-punkte wird ein lineares Gleichungssystem mit positivemLösungsraum gesucht. Kommunikationen, bei denen dieSynchronisationsbedingung nicht erfüllt ist, werden ausdem Gleichungssystem entfernt.

In aktuellen Arbeiten wird aufbauend auf den ermittel-ten Kommunikationspunkten eine Analyse durchgeführt,um Konflikte beim gemeinsamen Zugriff auf gemeinsamgenutzte Ressourcen zu erkennen [7].

3. EmulationsumgebungSpyder -System

Emulation ist eine effektive Methode, die Funktiona-lität eines Systems in seiner realen Umgebung zu testen.Der Vorteil gegenüber einer Simulation ist, dass keineTestvektoren generiert werden müssen. Damit diese Emu-lation eine hohe Aussagekraft und Akzeptanz bei denEntwicklern erhält, sind leistungsstarke Werkzeuge – dieEmulationsumgebungSpyder– definiert und implemen-tiert worden. DasSpyder -Emulationssystem besteht dabeiaus zwei Werkzeugen, welche von einem gemeinsamenBetriebssoftware-Paket in eine PC-basierte Entwicklungs-umgebung eingebunden werden. Im wesentlichen greiftdie Spyder-Betriebssoftware die Ausgangsprodukte vonState-of-the-Art-Entwicklungswerkzeugen für FPGA und

11

• Virtex-FPGA (XCV400-2000E)

• Konfiguration und Kommunikation über PCI-Bus

• Erweiterungsstecker mit bis zu 168Verbindungsmöglichkeiten

• On-board Speicher:• 2 x SDRAM: 4Mx32• 2 x SSRAM: 256Kx32

• Debugging• Mictor Logikanalysator Stecker• Chipscope ILA Kerne• 2 LEDs

Abbildung 5. Blockschaltbild und Foto des Spy-der -Virtex-Boards

Mikrocontroller auf und überträgt sie auf eine gemeinsameEmulationsplattform. Das Werkzeug Spyder-Core-P2 istdie zentrale Basis-Platine und dient der Emulation von ein-zelnen ASIC-Komponenten, der Emulation von Software-Komponenten sowie der abschließenden Systemintegra-tion aller Teilkomponenten eines eingebetteten Systems.Das Werkzeug Spyder-Virtex-X2e ist ein Hilfswerkzeugfür Spyder-Core-P2, welches insbesondere den Mikrocon-troller durch den Mikroprozessor des Entwicklungsrech-ners ersetzt. Die in diesem Teilprojekt durchgeführten Ar-beiten, führten zu mehreren Publikationen, unter anderemin [8, 9, 10, 11]. Eine detaillierte Abhandlung dieser Ent-wurfsmethodik und der Entwurfswerkzeuge ist in der Dis-sertation, “Architekturentwurf und Emulation eingebette-ter Systeme” [12] zu finden. Eine aktuelle Arbeit behan-delt die optimale Ressourcenausnutzung der Emulations-umgebung zur Behandlung komplexerer Hardwarekompo-nenten am Beispiel eines Mikrocontrollerkerns[18].

Die Emulationsumgebung fand großen Anklang beiHochschulinstituten und in der Industrie. Mehr als 50Boards sind sowohl in Forschung und Entwicklung, alsauch in der Lehre im Einsatz. Dies führte zu zahlrei-chen Kooperationen mit Industriepartnern und Hochschul-instituten innerhalb und außerhalb des Schwerpunktpro-gramms “Eingebettete Systeme”. In diesem Zusammen-hang ist das Spin-Off-UnternehmenX2E entstanden, dasdie Weiterentwicklung des Emulationssystems übernom-men hat.

Literatur

[1] HERGENHAN, A. und W. ROSENSTIEL: Static TimingAnalysis of Embedded Software on Modern Processor Ar-chitectures. In: Proceedings of the Date 2000 Conference,März 2000.

[2] HERGENHAN, A., A. SIEBENBORNund W. ROSENSTIEL:Studies on Static Timing Analysis Techniques for Modern

Processor Architectures. In: WIP-Proceedings of the 20thIEEE Real-Time Systems Symposium, 1999.

[3] HERGENHAN, A., A. SIEBENBORNund W. ROSENSTIEL:Studies on Different Modeling Aspects for Tight Calculati-ons of Worst Case Execution Time. In: WIP-Proceedings ofthe 21th IEEE Real-Time Systems Symposium, 2000.

[4] HERGENHAN, A., S. HOFMANN, D. SCHRÖDER undW. ROSENSTIEL: Modellierung, Analyse und Bewertungvon Systemarchitekturen intelligenter eingebetteter Syste-me der Automobilindustrie. In: Workshop AES2000, Januar2000.

[5] HERGENHAN, A.: Analytische Modellierung und Bewer-tung von Prozessoren in eingebetteten Systemen. Disserta-tion, Universität Tübingen, 2001.

[6] SIEBENBORN, A., O. BRINGMANN und W. ROSENSTIEL:Worst-Case Performance Analysis of Parallel, Communica-ting Software Processes. In: Proceedings of CODES, 2002.

[7] SIEBENBORN, A., O. BRINGMANN und W. ROSENSTIEL:Communication Analysis for System on Chip Design. In:Proceedings of the Design Automation and Test in EuropeConference (DATE), Paris, Februar 2004.

[8] WEISS, K., T. STECKSTOR, C. NITSCH, U. KEBSCHULL

und W. ROSENSTIEL: Performance Analysis of Rael-TimeOperating Systems by Emulation of an Embedded System.In: RSP’99, Clearwater, Florida, USA, Juni 1999.

[9] WEISS, K., T. STECKSTOR, G. KOCH und W. ROSEN-STIEL: Exploiting FPGA-Features during the Emulation ofa Fast Reactive Embedded System.In: IEEE Symposium onField Programmable Gate Array, Monterey,USA, 1999.

[10] WEISS, K., C. OETKER, I. KATCHAN, T. STECKSTORundW. ROSENSTIEL: Power Estimation Approach for SRAM-based FPGAs. In: IEEE Symposium on Field Programma-ble Gate Array, Monterey USA, 2000.

[11] NITSCH, C., K. WEISS, T. STECKSTOR und W. RO-SENSTIEL: Embedded System Architecture Design Basedon Real-Time Emulation. In: Rapid System PrototypingRSP2000, Paris, France, Juni 2000.

[12] WEISS, K.: Architekturentwurf und Emulation eingebette-ter Systeme. Dissertation, Universität Tübingen, 2000.

[13] WEISS, K., T. STECKSTOR und W. ROSENSTIEL: Ent-wurf und Entwurfsmethodik einer auf SH3-7709A undVxWorks basierten Multimedia-Platform für Automotive-Anwendungen. In: Workshop AES 2000, Karlsruhe, Janu-ar 2000.

[14] WEISS, K., T. STECKSTORund W. ROSENSTIEL: Emula-tion of a Fast Reactive Embedded System using a Real Ti-me Operating System. In: DATE99, München, März 1999.

[15] WEISS, K., A. HERGENHAN und W. ROSENSTIEL: Syste-matischer Entwurf und Test eingebetteter Systeme am Bei-spiel eines ATM-Diagnosesystems. In: Workshop zur Archi-tektur von Rechnersystemen (ARCS), Rostock, 1997.

[16] HERGENHAN, A., C. WEILER, K. WEISSund W. ROSEN-STIEL: Value-Added Services in Industrial Automation. In:Lecture Notes in Computer Science ; Vol. 1385. Springer-Verlag Berlin-Heidelberg, 1998.

[17] HERGENHAN, A., C. WEILER, K. WEISSund W. ROSEN-STIEL: Internet-basierte eingebettete Systeme der industri-ellen Automation. Automatisierungstechnik, 7, 1999.

[18] SCHMITT, S. und W. ROSENSTIEL: Verifikation of a Mi-crocontroller IP Core for System-on-a-Chip Designs UsingLow-Cost Prototyping Environments. In: DATE Confe-rence, Paris, France, Februar 2004.

12

Komponentenbasierte Entwicklung eingebetteter Systeme

Nasser Jazdi Institut für Automatisierungs- und Softwaretechnik (Prof. Dr.-Ing. Dr. h. c. P. Göhner)

Universität Stuttgart

Zusammenfassung Gegenstand des Projekts war die komponentenba-

sierte Softwareentwicklung für eingebettete Systeme. Dabei lag der Schwerpunkt auf der Methodik und der Festschreibung geeigneter Verfahren. Die Werkzeug-unterstützung sowie der Aufbau einer spezifisch auf eingebettete Systeme angepassten Komponentenbiblio-thek waren weitere Ziele dieser Forschungstätigkeit.

1. Einleitung Durch den anhaltenden Preisverfall und die Leistungs-

steigerung der Hardwarekomponenten, insbesondere bei Mikroprozessoren und Speichern, eröffnen sich ständig neue Einsatzmöglichkeiten für eingebettete Systeme. Da zunehmend auch neuartige Funktionen in die eingebet-teten Systeme integriert werden, steigt ihre Komplexität an [1]. Viele komplexe Funktionen werden zunehmend in Software realisiert, um im Bereich der Hardware mög-lichst kostengünstige Standardkomponenten einsetzen zu können. Die Wertschöpfung bei der Neuentwicklung von Produkten verlagert sich damit immer mehr in Richtung Software.

Während man in der Hardware zum überwiegenden Teil bereits auf bestehende Standardkomponenten zu-rückgreifen kann, ist dies in der Software bisher kaum gelungen. Zum einen wird die spezifische Funktionalität der Systeme in Form spezifischer Software realisiert, zum anderen gibt es im Gegensatz zur Hardwareent-wicklung keine allgemein anwendbaren komponenten-basierten Entwicklungsmodelle und -methoden. Die Software wird individuell entwickelt und oft von Hand optimiert, um den Speicherplatz optimal auszunutzen und die Bauteilkosten niedrig zu halten, die sich bei hohen Stückzahlen zu beachtlichen Beträgen summie-ren. Mit dieser Vorgehensweise wird man jedoch der rasch ansteigenden Komplexität der Software schon bald nicht mehr gewachsen sein [2].

2. Zielsetzung Ziel des Forschungsvorhabens war die Entwicklung

neuer Methoden und Verfahren für die komponentenba-sierte Softwareentwicklung für eingebettete Systeme. Dabei waren die speziellen Randbedingungen von ein-

gebetteten Systemen zu berücksichtigen. Die Software-komponenten mussten auf einem hohen Abstraktionsni-veau zur Verfügung gestellt werden, um eine individu-elle Anpassung der Software an die beschränkten Sys-temressourcen, wie Speicherplatz und Rechenleistung, zu ermöglichen. Die Forschungsarbeiten konzentrierten sich dabei auf folgende vier Themenschwerpunkte: • Komponentenbasierte Entwicklungsmethoden für

eingebettete Systeme • Werkzeugunterstützung für einen möglichst stark

automatisierten Entwicklungsablauf beim Einsatz von vorgefertigten Softwarekomponenten

• Erstellung einer Komponentenbibliothek • Entwicklung von Komponenten für die Diagnose

und Wartung eingebetteter Systeme In der Analysephase wurden zunächst die Eigen-

schaften eingebetteter Systeme untersucht und diese in zeit- und ereignisgesteuerte Systeme unterteilt. Darauf aufbauend wurden im Laufe des Projekts drei Ent-wurfsmethoden entwickelt, die auf die besonderen Randbedingungen von eingebetteten Systemen zuge-schnitten sind. Diese Entwurfsmethoden wurden in unterschiedlichen Berichten an die DFG, sowie in zahl-reichen Veröffentlichungen detailliert dargestellt. Sie werden im Folgenden kurz zusammengefasst.

3. Komponentenbasierte Entwicklung ereignisgesteuerter eingebetteter Systeme

Für ereignisgesteuerte eingebettete Systeme wurde ein Java-basiertes Konzept entwickelt, das auf der Java-Komponententechnologie JavaBeans aufsetzt. Der Fo-kus lag dabei auf ereignisgesteuerten, nicht sicherheits-kritischen Systemen. Der Grund für diese Einschrän-kung waren die spezifischen Merkmale der Program-miersprache Java.

Im Rahmen der Untersuchungen wurde festgestellt, dass die von JavaBeans verwendeten Kommunikati-onsmechanismen zwar ein sehr durchdachtes System für die Entwicklung von grafischen Benutzungsoberflächen darstellen, für Software von eingebetteten Systemen jedoch kaum geeignet sind. Aus diesem Grund wurde das JavaBeans-Kommunikationskonzept modifiziert und an die Anforderungen eingebetteter Systeme ange-passt [3].

13

event queue

connection handler

OnEvent Event

connection table

source componentevent

target componentmethod

event queue

connection handler

OnEvent Event

connection table

source componentevent

target componentmethod

Abbildung 1: Modifiziertes JavaBeans-Kommunikationsmodell

Im modifizierten JavaBeans-Kommunikationskonzept werden der Aufbau der Komponenten sowie deren mögliche Ein- und Ausgänge festgeschrieben. Außer-dem gibt es eine Systematik zur Beschreibung der Komponenten, sowie ein Hierarchisierungsschema. Die Ein- und Ausgänge werden in zwei Kategorien einge-teilt, in Signal- und Datenein- bzw. -ausgänge. Beim Aufbau der Komponenten erreicht man durch die Ver-wendung der Interface-Klasse eine Trennung von Schnittstellendefinitionen und Implementierungen, wodurch eine wichtige Grundvoraussetzung der kom-ponentenbasierten Softwareentwicklung erfüllt wird.

Component

3

2A

1 1

3

2 A

signal input

active data input

passive data input

signal output

active data output

passive data output

Component

3

2A

1 1

3

2 A

signal input

active data input

passive data input

signal output

active data output

passive data output

Abbildung 2: Aufbau der modifizierten JavaBeans-Komponenten

Mit diesem modifizierten Kommunikationskonzept

hat man ein Java-basiertes Komponentenmodell, welches auf die Belange eingebetteter Systeme ausge-richtet ist.

4. Komponentenbasierte Entwicklung zeitgesteuerter eingebetteter Systeme

Bei zeitgesteuerten Echtzeitsystemen werden alle Ak-tivitäten zu definierten Zeitpunkten angestoßen. Die Zustandsgrößen des technischen Systems werden zu festgelegten Zeitpunkten erfasst, alle Teilprogramme werden periodisch ausgeführt. Das Zeitverhalten des Systems ist daher deterministisch. Aus diesem Grund werden sicherheitskritische eingebettete Systeme zeitge-steuert realisiert.

In einem ersten Schritt wurden die Eigenschaften die-ser Systeme untersucht. Daraus wurden Anforderungen an die komponentenbasierte Softwareentwicklung ver-teilter eingebetteter Systeme, wie Determinismus, Kor-rektheit, Kompatibilität zwischen Komponenten und Werkzeugunterstützung, abgeleitet. Synchrone, zeitge-steuerte Ausführungsmodelle sind sehr gut geeignet, um diese Anforderungen zu erfüllen. Daher wurden die Realisierung von Software für eingebettete Systeme auf synchroner Basis, sowie zeitgesteuerte Architekturen für verteilte Systeme näher untersucht. Auf Grundlage des synchronen Ansatzes wurde ein Komponentenmodell für synchrone Softwarekomponenten definiert. Dieses besteht aus einem reaktiven Teil und einem Datenverar-beitungsteil. Das Verhalten der Komponente wird durch den reaktiven Teil bestimmt, der die Datenverarbeitung steuert und ein deterministisches Verhalten aufweist [4].

Verarbeitungs-Teil (C)

Datentyp-Definitionen



Datenverarbeitungs-Funktionen

Synchrone Softwarekomponente

Reaktiver Teil (ESTEREL)

Kontroll- undDatenvariablen

signal Input Signal output

Verarbeitungs-Teil (C)








Synchrone Softwarekomponente

Reaktiver Teil (ESTEREL)

Kontroll- undDatenvariablen

signal Input Signal outputSignal output

Abbildung 3: Aufbau von synchronen Softwarekomponenten

Für die komponentenbasierte Entwicklung unter Ver-

wendung dieser synchronen Komponenten wurde eine geeignete Methodik definiert. Der Softwareentwurf erfolgt auf Basis eines grafischen Entwurfsmodells. Dabei definiert der Applikationsentwickler Baugruppen als funktionale Einheiten. Diese Baugruppen werden schrittweise weiter verfeinert, bis sie sich durch die vorhandenen Komponenten realisieren lassen. Die Softwarekomponenten können dazu aus einer Biblio-thek ausgewählt, parametriert und durch Signale mitein-ander verbunden werden. Die Sicherheitseigenschaften des Systems können dann auf Basis dieses Modells mit Hilfe von Model Checking verifiziert werden.

Aus dem komponentenbasierten Entwurf kann durch automatische Codegenerierung direkt ein ablauffähiger Code erzeugt werden. Dieser repräsentiert die Kommu-nikationsverbindungen zwischen den Komponenten, die im Entwurf definiert wurden und integriert den bereits vorhandenen Code der Komponenten. Durch die auto-matische Codegenerierung wird die Wahrscheinlichkeit von Fehlern im Code deutlich herabgesetzt.

Aufgrund des zu Grunde liegenden zeitgesteuerten Kommunikationssystems und der synchronen Software-komponenten ist das Ausführungsmodell nicht nur im Werte-, sondern auch im Zeitbereich deterministisch.

14

Das Konzept eignet sich daher besonders für sicher-heitskritische Applikationen. Für dynamische Applika-tionen, bei denen das Verhalten der Umgebung des eingebetteten Systems nicht vollständig bekannt ist, sind synchrone Softwarekomponenten hingegen weniger geeignet.

5. Komponentenbasierte Entwicklung eingebetteter Systeme mit strukturierten Komponenten

Wie sich bereits im Zuge des JavaBeans-Konzeptes gezeigt hatte, sind Komponententechnologien aus der PC-Welt für den Einsatz in eingebetteten Systemen nur sehr bedingt geeignet. Daher wurde ein neuer Ansatz entwickelt, der den Komponenten-Gedanken in ange-passter Form auf eingebettete Systeme überträgt. Auf der Grundlage einer eigens ausgearbeiteten Methodik wird die eingebettete Software komponentenbasiert zerlegt. Die hieraus hervorgehenden Komponenten sind mehrfach verwendbar und helfen die Systemstruktur überschaubar zu halten. Die Modellierung der Kompo-nenten einschließlich ihrer Verknüpfung zur vollständi-gen Applikation erfolgt mit Hilfe Objekt-orientierter Ausdrucksmittel. Zur Implementierung werden jedoch herkömmliche strukturierte Programmiersprachen, wie z. B. C, benutzt. Auf diese Weise entstehen sehr leicht-gewichtige Komponenten, die als strukturierte Kompo-nenten bezeichnet werden. Sie können ohne Ressour-cen-intensive Laufzeitumgebungen oder virtuelle Ma-schinen verwendet werden und beanspruchen kein nen-nenswertes Mehr an Rechenleistung und Speicherplatz als herkömmliche Softwaremodule.

Die gesamte Methodik ist bewusst einfach gehalten, so dass sie auch ohne umfangreiche Codegenerierungs-werkzeuge anwendbar ist. Trotzdem stehen fortge-schrittene Objekt-orientierte Konzepte, wie Schnittstel-len, Polymorphie und Templates, für den komponenten-basierten Applikationsentwurf zur Verfügung. Der Auf-bau des entstehenden Quellcodes deckt sich exakt mit dem des Komponentenmodells, ist sehr übersichtlich und kann auch von nicht eingearbeiteten Entwicklern leicht nachvollzogen werden [5].

6. Ergebnisse

6.1 Java-basiertes Konzept Im Rahmen der Entwicklung einer Entwurfsmethodik

für ereignisgesteuerte eingebettete Systeme wurde das JavaBeans Komponentenmodell erweitert und an die Randbedingungen eingebetteter Systeme angepasst. Es wurde eine Komponentenbibliothek entwickelt, die 25 Komponenten zur Steuerung und Visualisierung von Prozessabläufen beinhaltet. Die Komponenten können in einem Editor graphisch miteinander verknüpft wer-den, woraus sich anschließend ein ausführbarer Code generieren lässt.

Boiler Aufbrühgerät

DruckmesserVentil

Behälter für Kaffeemehl mit Mahlgerät

Leitung

Boiler Aufbrühgerät

DruckmesserVentil

Behälter für Kaffeemehl mit Mahlgerät

Leitung

Abbildung 4:Komponentenbibliothek mit Visualisierungskomponenten

Um das Konzept zu evaluieren und abzurunden, wur-

den mehrere Industrieprojekte mit den Firmen Bosch GmbH, WMF AG und ads-tec GmbH durchgeführt.

6.2 Synchrone Softwarekomponenten Im Rahmen dieser Forschungsarbeiten ist eine Werk-

zeugumgebung für die komponentenbasierte Entwick-lung mit synchronen Softwarekomponenten entstanden. Die Werkzeugumgebung heißt ViPER, was für „Visual Programming Environment for Embedded Real-Time Systems“ steht. Das Werkzeug ermöglicht den Aufbau vollständiger Applikationen aus den Komponenten ohne eine einzige Zeile Code schreiben zu müssen. Aus dem graphischen Entwurfsmodell wird passend für die vor-liegende Mikrocontrollerplattform ein ausführbarer Code generiert. Die zugehörige Komponentenbibliothek umfasst derzeit 55 Komponenten [6].

Abbildung 5: Visual Programming Environment for Real-Time Systems (ViPER)

15

Das Konzept wurde in einem gemeinsamen Projekt

mit der DaimlerChrysler AG (Brake-by-Wire-Brems-system) eingesetzt und evaluiert.

6.3 Strukturierte Komponenten Im Rahmen dieser Arbeit wurde ein eingebetteter

Webserver namens IAS-WebStack realisiert. Er setzt sich aus 5 strukturierten Komponenten zusammen, die Treiber für Ethernet und Modem sowie die Kommuni-kationsprotokolle TCP/IP, HTTP und XML bereitstel-len. Insgesamt benötigen sie lediglich ca. 10 KB (ROM) und 5 KB (RAM) Speicher und eignen sich daher sehr gut für den Einsatz in eingebetteten Systemen. Passend zum IAS-WebStack wurde eine kostengünstige Mikro-controllerplattform, das IAS-WebBoard, realisiert.

Abbildung 6: IAS-WebBoard

Das IAS-WebBoard hat eine Größe von 10 x 8 cm und kostet ca. 150 €. Derzeit laufen Aktivitäten zur Grün-dung einer Firma (Spin-off) zur kommerziellen Ver-marktung des IAS-WebBoards und IAS-WebStack.

7. Resümee In der knapp 6 jährigen Laufzeit wurden alle Arbeits-

pakete aus dem Projektantrag erfolgreich bearbeitet und abgeschlossen. Es wurden drei Methoden zur kompo-nentenbasierten Entwicklung eingebetteter Systeme entwickelt.

Insgesamt wurden über 90 Studien- und Diplomar-beiten in den jeweiligen Themenbereichen durchgeführt. Zudem entstanden auf dem Gebiet der komponentenba-sierten Softwareentwicklung 6 Dissertationen. Die ent-wickelten Konzepte und Werkzeuge wurden in 34 Pub-likationen veröffentlicht. Außerdem sind die Ergebnisse dieses Projekts in verschiedene Lehrveranstaltungen des Instituts integriert worden.

8. Literatur [1] FLEISCH, WOLFGANG: Test Case Design for the

Validation of Component-Based Embedded Sys-

tems. In: 12th International IFIP WG10.3 / WG10.4 / WG10.5 Workshop on Distributed and Parallel Embedded Systems (DIPES 2000), Pader-born, Germany, 2000.

[2] DUJMOVIC, STJEPAN: An Understandable and Configurable Domain-Specific Framework for In-dustrial Automation Applications. In: 33rd Inter-national Conference on Technology of Object-Ori-ented Languages and Systems (TOOLS), Mont-Saint-Michel, Frankreich, 2000.

[3] JAZDI, NASSER: Component-Based and Distributed Web Application for Embedded Systems. In: Inter-national Conference on Intelligent Agents, Web Technology and Internet Commerce - IAW-TIC2001.

[4] GUNZERT, MICHAEL: Component-Based Develop-ment and Verification of Safety Critical Software for a Brake-By-Wire System with Synchronous Software Components. In: Proc. Int. Symposium on Parallel and Distributed Systems Engineering, Los Angeles, USA, 1999.

[5] EBERLE, STEPHAN, GÖHNER, PETER: Software-entwicklung für eingebettete Systeme mit struktu-rierten Komponenten. In: erscheint in atp, Ausgabe 02/04, 2004.

[6] LUCENA, VICENTE: A Domain Specific Classifi-cation Scheme for the Management of Industrial Automation Components. In: ASSE 2001 -Inter-national Symposium on Software Engineering, Buenos Aires, Argentinien, 2001.

[7] JOST, PASCAL: Identifikation von Softwarekompo-nenten in kleinen und mittleren Projekten. In: GMA-Kongress, Baden Baden, 2003.

16

TEReCS – Entwurf konfigurierbarer, echtzeitfähiger Kommunikationssysteme

Carsten BökeEntwurf Paralleler Systeme (Prof. Dr. rer. nat. Franz J. Rammig)

Heinz Nixdorf Institut, Universität Paderborn

Zusammenfassung

Im Projekt TEReCS wurden Software-Werkzeuge für dieautomatische Synthese von Laufzeitplattformen für verteil-te eingebettete Systeme entwickelt. Als Basis dient die kon-figurierbare Komponentenbibliothek DREAMS. Experten-wissen über deren Komponenten und deren Abhängigkei-ten wird durch einen Graphen spezifiziert. In Kombinati-on mit dem Anwendungsprofil und diesem “Expertenwis-sen” können Konfigurations- und Analyse-Werkzeuge dieLaufzeitplattform generieren und die Laufzeitplanung off-line bestimmen und so Aussagen über seine Echtzeitfähig-keit machen.

1. Einleitung

In technischen Systemen werden Mikroprozesso-ren eingesetzt, um diese unter Realzeitbedingungen zusteuern oder zu kontrollieren. Die Prozessoren wer-den mittels Kommunikationsnetzwerken miteinander ver-bunden. Eine besondere Herausforderung besteht darin,auch die Kommunikation zwischen den einzelnen Sy-stemprozessen unter Realzeitbedingungen durchführen zukönnen. Hierzu müssen die vorgegebenen zyklischen Pe-rioden, Zeitschranken und Antwortzeiten vom Kommuni-kationssystem eingehalten werden.

Ziel unserer Arbeiten war es, das Betriebsystem undinsbesondere das Kommunikationssystem den Anforde-rungen der Anwendung optimal anzupassen. Unser An-satz kennzeichnet sich dadurch aus, das Betriebssystemund Kommunikationssystem aus einem selbstentwickeltenBaukasten kleiner objektorientierter Klassen (DREAMS)zusammenzusetzen. Dabei werden nur die Elemente in-tegriert, die wirklich benötigt werden. Aus unterschied-lichen Alternativen werden die optimalen Lösungen aus-gewählt. Bei diesem Prozess wird eine konkrete Konfi-guration für eine Ausprägung des Betriebssystems ausdem kompletten Entwurfsraum aller möglichen syntheti-sierbaren Betriebssysteme (dieses Baukastensystems) aus-gewählt.

Es wurde eine Methodik entwickelt, Kommunikations-systeme für eingebettete verteilte Systeme zu synthetisie-ren und zu konfigurieren [1]. Grundlage sind dabei Dien-ste und ihre Abhängigkeiten untereinander und von vor-handener Hardware. Die Softwareplattform für ein verteil-tes Kommunikationssystem wird möglichst optimal an die

Time-Triggered Event

Scheduling

Medium1 trans+ prop

Methodology

Puppet-Configuration

Fine-granular and customisable real-time OS

Configuration

TEReCS

Analysis

Primitives

URSG

Abbildung 1. TEReCS beruht im wesentlichen aufden Konzepten der Konfigurierung und der Lauf-zeitplanung.

New Service

Synthesis

Specification

Selection

Allocation

Configuration

Validation

Generation

Primitives

Check Map

Resources

Implemen-tation

System’sCode

System’sCode

Definition of

Devices, CPUs, Media,

Services, SAPs, SRPs,

HAPs, HRPs, etc.

UniversalResource Service

Graph

CommunicationGraph

ResourceGraph

Hardware&

Topology

LibraryKnowledge Base

Code

for each

Service

Input of User:

Input ofExpert:

Abbildung 2. Methodik zur Nutzung einer Wis-sensbasis zur Konfigurierung von Laufzeitplatt-formen

Anwendung angepasst für jeden Knoten im System gene-riert. Basis ist das konfigurierbare und auf Objektebeneadaptierbare Real-Time Management System DREAMS,welches um Kommunikationsdienste (-objekte) für einge-bettete Systeme angereichert wurde.

17

Ein weiterer Schwerpunkt besteht darin, die Realzeit-bedingungen des fertig konfigurierten Systems vor sei-ner Laufzeit zu überprüfen. Es werden Betriebsmittelbe-legungspläne erstellt und die Verzögerungs- und Latenz-zeiten der Kommunikation berechnet.

Im Projekt TEReCS wurden hierfür Verfahren undWerkzeuge entwickelt. Durch den Einsatz unserer Me-thoden wird die Zeit, die zur Erstellung eines ferti-gen Kommunikationssystems benötigt wird, erheblichreduziert. Die Wiederverwendung von Code aus ei-ner Bibliothek (DREAMS) und die Offline-Überprüfungvor dem endgültigenTargeting sind wichtige Beiträ-ge zur Verbesserung derTime-to-MarketEigenschaft beider Produktentwicklung für verteilte eingebettete Syste-me.

Bei diesem Ansatz hat sich herausgestellt, dass durchKonfigurierung von Software-Komponenten widersprüch-liche Zielsetzungen (z.B. zwischen Performanz und Fle-xibilität) hochgradig justierbar werden [2]. Gleichzeitigkonnte durch die Anwendung von Entwurfsprinzipien desHardwareentwurfs auf die Konfigurierung und den Aufbauder Bibliotheksplattform gezeigt werden, dass Betriebs-systeme als Vermittler zwischen Software und Hardwarenicht als statisch fest angesehen werden müssen, sondernsich vielmehr den Gegebenheiten anpassen können.

2. Problemstellung

Bei verteilten eingebetteten Systemen laufen auf je-dem Knoten unterschiedliche Prozesse. Diese benöti-gen dann unterschiedlichste Betriebssystemfunktionenund Hardware-Geräte. Oft werden solche verteilten Sy-steme aber auf der gleichen Hardwareplattform basie-rend implementiert. Zudem wird deshalb auch auf allenKnoten das gleiche monolithische Betriebssystem ein-gesetzt. Hier besteht eine Lücke zwischen der flexiblenProgrammierung der Prozesse und den mehr oder weni-ger statischen Betriebssystemkernen. Diese Lücke wirdmeist dadurch geschlossen, das Betriebsystem so all-gemeingültig wie möglich zu implementieren (virtuel-le Maschine). Die Dienste, die diese Betriebssystemezur Verfügung stellen, unterstützen möglichst alle un-terschiedlichen Anwendungsszenarien. Hieraus folgertjedoch, dass ein nicht unwesentlicher Teil des Betrieb-systems ungenutzt bleibt oder zumindest für konkreteAnwendungsfälle sehr ineffektiv ist.

Aus diesem Grund werden gerade Betriebssysteme füreingebettete Anwendungen flexibel und konfigurierbar an-geboten. Viele Merkmale und Fähigkeiten können para-metrisiert, hinzugefügt oder entfernt werden. Aber gera-de dieser Vorgang der Konfigurierung muss sehr oft ma-nuell vom Anwendungsprogrammierer geschehen. Jedochist es häufig schwierig für diesen zu entscheiden, welcheOptionen die besten sind oder überhaupt zu seinem An-wendungsfall passen. Der Betriebssystemprogrammiererkennt als Experte die Anwendungsfälle, für die die konfi-gurierbaren Optionen entwickelt wurden. Es war eine Auf-gabe dieses Projekts, das “Expertenwissen” formal zu er-fassen und es für eine automatische Konfigurierung zu nut-



Hardware

ApplicationApplicationApplicationApplicationApplicationApplicationApplicationApplicationApplicationApplication

Run-Time Platform or

Operating System


Application

Run-Time

Platform

Communication

System

Hardware

Standard:

Many applications are

developed for a static

operating system

Goal:

Optimal adapted

run-time platform

for each application

Abbildung 3. Herausforderung: von statischenBetriebssystemen hin zu hochgradig flexiblenund konfigurierbaren Laufzeitplattformen für ver-teilte eingebettete Systeme

zen. Die Flexibilität und Konfigurierbarkeit des Betriebs-systems soll für den Anwendungsprogrammierer transpa-rent sein.

Dazu wurden einige Werkzeuge entwickelt, mit de-nen es möglich ist, konfigurierbare Laufzeitplattformenfür verteilte eingebettete Systeme zu beschreiben, auto-matisch zu konfigurieren und bezüglich ihrer Realzeit-Eigenschaften zu analysieren.

3. Lösung

In TEReCS wird streng zwischen dem Wissen über dieAnwendung und dem Expertenwissen über die Konfigu-rationsoptionen des Betriebssystems unterschieden. DasWissen über die Anwendung wird als Anforderungsspezi-fikation angesehen. Diese Anforderungsspezifikation dientals Eingabe für den Konfigurationsprozess. Die Anforde-rungsspezifikation besteht im wesentlichen aus einer ab-strakten Beschreibung der Anwendung und bestimmteneinzuhaltenden Eigenschaften (Deadlines). Die Anwen-dungsbeschreibung spezifiziert dabei welche Betriebsy-stemdienste welcher Prozess auf welchem Knoten wannaufruft. Außerdem wird in der Anforderungsspezifikationauch die Hardware-Plattform (CPU-Typen, Kommunika-tionsgeräte) und -Topologie definiert. Es wird eine festeVerteilung von Prozessen auf die Knoten im System vor-ausgesetzt. Insbesondere werden auch die Kommunikati-onsverbindungen zwischen den einzelnen Prozessen mitihren Eigenschaften spezifiziert.

Der komplette gültige Entwurfsraum des konfigurier-baren Betriebssystems wird mit Hilfe eines sogenanntenUND/ODER-Dienstabhängigkeitsgraphen in einer Wis-sensbasis spezifiziert [5]. Der Konfigurationsprozessvervollständigt dieses domänenspezifische Wissen un-ter Zuhilfenahme der Anforderungsspezifikation. Dabeiwird dann eine Konfiguration einer Laufzeitplattform au-tomatisch für ein konkretes verteiltes System erstellt.Diese Integration der Wissensbasen kann als Wissen-stransfer von der Anwendung hin zum Betriebssysteminterpretiert werden.

18

Assembly

Configuration

Process

Control

Knowledge

+

DomainKnowledgeDatabase

SystemComponentsRepository

Configuration

Description

User Interaction

describes

optional

Application

Specific

Knowledge

Requirement

Specification=

System

TE

ReC

SD

RE

AM

S

steers

Abbildung 4. Ein-/Ausgabeflüsse bei der Konfi-gurierung von technischen Systemen

3.1. Konfigurierung

Die Beschreibung des gesamten gültigen Entwurfs-raums eines konfigurierbaren Betriebssystems erfolgtmit Hilfe eines UND/ODER-Graphen. Dieser spezifi-ziert:

• Knoten sind als Dienste atomare konfigurierbare Ob-jekte

• Zwingende Abhängigkeiten zwischen Diensten wer-den durch UND-Kanten repräsentiert

• Optionale oder alternative Abhängigkeiten zwischenden Diensten werden als ODER-Kanten repräsentiert

• Dienste und ihre Abhängigkeiten besitzen Kostenund Prioritäten

• Randbedingungen (Präferenzen, Verbote, Forcierun-gen) für ODER-Entscheidungen können spezifiziertwerden

• Wurzelknoten des Graphen sind sogenannte Primi-tiven, welche Betriebssystemfunktionsaufrufe reprä-sentieren

Ziel des Konfigurationsprozesses ist das Auflösen al-ler ODER-Entscheidungen (Über-Spezifikation→ voll-ständigen Spezifikation) bzw. die Beschreibung derZiel-Konfiguration als Teilgraph ohne ODER-Kanten.

3.2. Laufzeitanalyse

Die Laufzeitanlyse dient der Überprüfung bzw. Sicher-stellung der Realzeitanforderungen der Anwendung vordem eigentlichen Targeting (Beschleunigung der Entwick-lungszeit ohne aufwendige Testläufe). D.h. die Laufzeit-analyse findet offline statt.

3.3. Entwurfsprozess

Der Entwurfsprozess [4] unterteilt sich in drei Schritte:

1. Suche einer funktional gültigen Konfiguration2. Überprüfung der Realzeit-Anforderungen durch eine

offline Laufzeitanalyse

3. Falls die Realzeitanforderungen nicht erfüllt werden,suche eine weitere Konfiguration (gehe zu Schritt 1.)

Im ersten Schritt integriert der Algorithmus imwesentlichen alle als Graphen gegebenen Spezifi-kationen (Anforderungs- und Kommunikationgraph,Hardware-Graph, Dienstabhängigkeitsgraph) zu ei-nem Super-Graphen. Als gültige Konfiguration wird einmöglichst kostengünstiger Teilgraph gesucht. Die gülti-gen Konfigurationen werden innerhalb des Entwurfszy-klus mit zunehmenden Kosten generiert.

Im zweiten Schritt werden für alle Prozessoren undKommunikationsverbindungen die Laufzeitpläne (Sche-dules) bestimmt.

Im dritten Schritt wird dann überprüft, ob die Prozesseihre Deadlines einhalten. Falls dies nicht der Fall ist, wirdzyklisch mit Schritt 1 fortgefahren. Aus den Ergebnissender Laufzeitanalyse werden dann zusätzliche Randbedin-gungen (Nutzungsverbote oder neue Kosten für Diensteund/oder Geräte) zur Anforderungsspezifikation hinzuge-fügt.

Graph

Architecture-

Graph

Universal

Service

Graph

Analysis of

Requirements

Generation of Code for

Communication Platform

Analysis of

Graph

Architecture-

Graph

Universal

Service

Graph

Analysis of

Requirements



Analysis of

Network

Operating System-

LibrariesSystem-

Description

DReaMS

TEReCS

TEReCS - Synthesis

Task A Task E

Task DTask B

Task C

Task F

Application-Tasks:Communication

Graph

Architecture

Graph

Universal

Service

Graph

Analysis of

Requirements



Analysis of

Timing Constraints ProcessDesign-

Device 1 Medium 1Task 1

CPU 1

Device 2Router

Task

CPU 2

Device 3 Medium 2 Device 4 Task 2

CPU 3

t

send

acquire

write

arbitration

transfer collect

deliver

read

route arbitration

transfer collect

deliver

readsend

acquire

write

receive

1st Hop 2nd Hop

TEReCS - Timing and Load Analysis:

Network

Operating System-

LibrariesSystem-

Description

DReaMS

TEReCS

TEReCS - Synthesis

Task A Task E

Task DTask B

Task C

Task F

Application-Tasks:

ExecutionBlocks

Abbildung 5. Entwurfszyklus zwischen Spezifika-tion, Konfigurierung und Analyse in TEReCS

4. Wissenschaftlicher Fortschritt

Die wissenschaftlichen Beiträge, die dieses Pro-jekt im wesentlichen geleistet hat, sind: (1) Die “Pup-pet Configuration” als ein neuer Ansatz zur Konfi-gurierung von Betriebssystemen und Laufzeitplattfor-men für verteilte eingebettete Realzeitanwendungen. (2)Das “Time-Triggered Event Scheduling”, welches denBetriebssystem-Overhead einer Konfiguration berücksich-tigt und die Betriebssystemereignisse zu den durch dasScheduling vorgegebenen Zeitpunkten ausführt. (3) Kon-figurierung und Analyse haben wechselseitigen Einflußaufeinander.

4.1. Puppet Configuration

Die Dienstnutzungsprimitiven stellen die Wurzelkno-ten des Dienstabhängigkeitsgraphen dar und verweisen

19

auf konkrete Dienste. Die Dienstabhängigkeiten spanneneinen Graphen auf. An den Blattknoten dieses Graphenkönnen Dienste stehen, die wiederum Abhängigkeiten zuHardware-Geräten besitzen. Hierbei handelt es sich ggf.um Kommunikationsgeräte, die wiederum Verbindungenmit Medien haben. Auf diese Weise können dann Wegedurch den gesamten integriertenService Resource Graphvon der Sende-Primitive bis zur Empfangs-Primitive ge-sucht werden. Dabei wird gleichzeitig das Routing derNachrichten bestimmt. Die auf dem Weg befindlichenDienste, sind in die Laufzeitplattform zu integrieren.

Diese Wege werden für alle in der Anforderungsspe-zifikation genutzten Primitiven gesucht. Da nur ein Teilaller möglichen Dienst-Primitiven genutzt wird, entschei-det im wesentlichen die Auswahl der genutzten Primitivendarüber, welche Dienste zu nutzen und zu parameterisie-ren sind. Die Wurzel-Primitiven sind ähnlich den Fäden ei-ner Marionette anzusehen. Jenachdem an welchen Fädengezogen wird, ändert sich die Konfiguration der Marionet-te. Die Dienstabhängigkeiten sind dabei mit den Gelenkender Marionette vergleichbar.

4.2. Time-Triggered Event Scheduling

Bei der Wegfindung, bzw. Teilgraphsuche, werdendurch die Abhängigkeiten auf den Pfaden die Dienste be-stimmt, die bei der Nutzung einer Primitive ausgeführtwerden. Dienste können Listen mit sogenanntenAusfüh-rungsblöckendefinieren. Ein Ausführungsblock besitzt ei-ne bestimmte (worst-case) Ausführungszeit und kannggf. an seinem Ende Signale senden oder an seinem An-fang auf Signale warten. Hierdurch wird ein Signal/WaitMechanismus implementiert.

In der Anforderungsspezifikation wurde nicht nur fest-gelegt, dass bestimmte Betriebssystemprimitiven aufgeru-fen werden, sondern auch wann. Auch die maximale Aus-führungszeit des Prozesscodes, der diese Aufrufe ausführt,ist bekannt. Somit können in einem offline Scheduling dieProzesse und die entsprechenden Ausführungsblöcke derBetriebssystemdienste in einem globalen Schedule für je-de CPU geplant werden. Durch den Signal/Wait Mecha-nismus können auch Ausführungsblöcke als Nachrichtenauf den Kommunikationsmedien eingeplant werden.

Die Aufrufe der Betriebssystemprimitiven stellen Er-eignisse dar, die das Scheduling der Prozesse unterbrechenund entsprechenden Betriebssystem-Overhead einplanen.Damit das offline berechnete Schedule während der rea-len Ausführung auch tatsächlich so abläuft, kann das Be-triebssystem DREAMS im realen Betrieb die Ausführungsolcher Betriebssystemaufrufe durch sogenannteGuardsauf genau die Zeit festlegen, die im Schedule bestimmtwurde. Zu frühe Aufrufe (durch schlechte worst-case Ab-schätzungen) werden verzögert. Zu späte Aufrufe werdenerkannt und können schon eher zu einer Fehlerbehandlungführen, bevor eine Deadline am Ende eines Prozesses ver-letzt wird.

4.3. Wechselspiel zwischen Konfigurierung undLaufzeitanalyse

Konfiguration und Laufzeitanalyse haben wechselsei-tigen Einfluß aufeinander. Die Konfiguration bestimmtdas Routing der Nachrichten, die Betriebsmittelnutzun-gen, sowie den Betriebssystem-Overhead, die in der Ana-lyse einzuplanen sind. Die Analyse entdeckt gegebenen-falls Bursts oder Überlastsituationen, die dazu führen, dasdie Betriebsmittelnutzungen, das Routing oder bestimm-te Dienstnutzungen verboten oder anders priorisiert wer-den. Dies führt zu Ergänzungen in der Anforderungsspezi-fikation, sodass bei einem erneuten Konfigurationslauf ei-ne andere Konfiguration erzeugt wird. Zum Beispiel durchdie Nutzung alternativer Routen oder Dienste.

5. Ausblick

Die wesentlichen Ergebnisse dieses Forschungspro-jekts sind in eine Dissertation [3] eingeflossen. Ebensowird das Projekt in dem Teilprojekt C2 des Sonder-forschungsbereichs 614 “Selbstoptimierende Systemedes Maschinenbaus” weitergeführt. Hierbei soll die offli-ne Konfigurierung und Analyse zu einem online Verfahrenweiterentwickelt werden. Insbesondere sollen dabei hoch-gradig dynamisch rekonfigurierbare Applikationen besserunterstützt werden.

Literatur

[1] C. Böke. Software Synthesis of Real-Time Communicati-on System Code for Distributed Embedded Applications. InProc. of the 6th Annual Australasian Conf. on Parallel andReal-Time Systems (PART), Melbourne, Australia, Decem-ber 1999. IFIP, IEEE.

[2] C. Böke. Combining Two Customization Approaches: Ex-tending the Customization Tool TEReCS for Software Syn-thesis of Real-Time Execution Platforms. InProc. of theWorkshop on Architectures of Embedded Systems (AES),Karlsruhe, Germany, January 2000.

[3] C. Böke. Automatic Configuration of Real-Time OperatingSystems and Real-Time Communication Systems for Distri-buted Embedded Applications. Phd thesis, Faculty of Com-puter Science, Electrical Engineering, and Mathematics, Pa-derborn University, Paderborn, Germany, 2003.

[4] C. Böke, C. Ditze, H. J. Eickerling, U. Glässer, B. Kleinjo-hann, F. J. Rammig, and W. Thronike. Software IP in Em-bedded Systems. InProc. of the Forum on Design Langua-ges (FDL), Lyon, France, September 1999.

[5] R. P. Chivukula, C. Böke, and F. J. Rammig. Customizingthe Configuration Process of an Operating System UsingHierarchy and Clustering. InProc. of the5th IEEE Inter-national Symposium on Object-oriented Real-time distribu-ted Computing (ISORC), pages 280–287, Crystal City, VA,USA, 29 April – 1 May 2002. IFIP WG 10.5. ISBN 0-7695-1558-4.

20

BeQuest:Beschreibung und formale Qualitätssicherung für eingebettete Systeme

Jan Romberg, Thomas StaunerSoftware & Systems Engineering

Institut für Informatik (Prof. Dr. Dr.h.c. Manfred Broy)Technische Universität München

Zusammenfassung

Eine große Klasse eingebetteter HW/SW Syste-me steht nicht nur mit zeitdiskreten Systemen, sondernauch mit kontinuierlichen Prozessen in der Umge-bung in Wechselwirkung, oder enthält selbst kontinu-ierliche Teile. Für die Entwicklung solcher Systemeist eine Methodik wünschenswert, welche die Entwick-lung diskret-kontinuierlicher Systeme durch integrierteBeschreibungstechniken und formalisierte Prozessschrit-te unterstützt.

Im Projekt BeQuest wurden zunächst für solche diskret-kontinuierlichen Systeme formal definierte, grafische Be-schreibungstechniken mit dem Ziel der Praxistauglichkeitund der intuitiven Verständlichkeit durch Entwickler defi-niert. Die Beschreibungstechniken wurden gezielt in Rich-tung auf Anforderungsspezifikation sowie diskreter Imple-mentierung erweitert. Für den Übergang zwischen den inverschiedenen Entwicklungsphasen eingesetzten Beschrei-bungstechniken wurde eine teilweise formalisierte Metho-dik erarbeitet.

Speziell für den Übergang von hybriden zu diskretenModellen konnte die Erhaltung wesentlicher verifizierterEigenschaften (Verfeinerung) gezeigt werden. Somit kanndie einmal verifizierte Korrektheit sicherheitskritischer Sy-steme über mehrere Entwicklungsphasen hinweg sicherge-stellt werden. Auf der Basis formaler Verfeinerungsregelnfür die Verhaltensspezifikation ist somit ein durchgängigerEinsatz der Methode im Entwicklungsprozess möglich.

In vielen Bereichen interagiert eingebettete Hard-und Software mit ihrer physikalischen Umgebung. Phy-sikalische Gesetzmäßigkeiten lassen sich zumeist als(zeit-)kontinuierliche Differenzialgleichungen charakte-risieren; zum Teil beinhaltet auch die Umgebung dis-krete Umschalteffekte, und darüber hinaus sind häufigdiskrete Wechsel zwischen in Hard- oder Software zu rea-lisierenden Regelalgorithmen nötig. Die systematischeEntwicklung und insbesondere das Erfassen von Anfor-derungen an solche diskret-kontinuierliche oderhybrideeingebettete Systeme erfordert Beschreibungstechni-ken, die es erlauben, die Wechselwirkung der diskretenund kontinuierlichen Aspekte eines Systems unmittel-bar zu beschreiben und zu validieren. Sicherheitskritische

Abbildung 1: Beispiel Zugbremssysteme

Anwendungen wie z.B. im Eisenbahnbereich (Abb.1) er-fordern darüber hinaus mathematisch fundierte System-beschreibungen, die als Grundlage für formale Verifikati-onsverfahren geeignet sind.

1. Erste Projektphase

Wesentliche Ergebnisse der ersten Projektphase wa-ren formal fundierte Notationen für den Entwurf hybrider,eingebetteter Systeme. Aufgrund Ihres suggestiven, gra-fischen Charakters und ihrer Anlehnung an die Beschrei-bungstechniken von UML eignen sich die Notationen un-mittelbar für den praktischen Einsatz. Diese Eignung wur-de im Laufe des Projekts an kleineren Fallstudien über-prüft. Konkret entstanden ist eine Systembeschreibungs-sprache,HyCharts, die es erlaubt, Architektur und Ver-halten hybrider, eingebetteter Systeme formal zu beschrei-ben. Zur Anforderungsspezifikation wurde eine zweiteSprache,HySCs, definiert und formal fundiert.HySCsstellen eine Erweiterung von UML-Sequenzdiagrammenbzw. MSCs für hybride Systeme dar.

Unsere Arbeit an HyCharts wurde zum einen dadurchbestätigt, daß ein entsprechender Artikel für das Jour-nal Formal Methods in System Designakzeptiert wurde.Zum anderen belegt die Arbeit, die (unter anderem) auchauf unseren Erkenntnissen aufsetzt, daß unsere Ergebnis-se auch international aufgegriffen wurden. Auch die HySCNotation wurde auf internationaler Ebene vorgestellt. Dar-über hinaus wurde die Idee, Sequenzdiagramm-basierte

21

formal verification

system environment

conventionaltechniques

requirements,

(HyCharts ,...)hybrid parts

(block diagrams)control laws, plant

HW

late partitioning

HW

and refinement

(DiCharts)

(DiCharts+Act)

(block diagrams)

HW / SW HW / SWHW / SW

control lawsstate−trans. logic

partitioning where appropriate

hybrid parts

requirements specification,environment model(HySCs, HyCharts, ...)

continuous−time

Ana

lysi

sD

esig

n

discrete−event /continuous−timediscrete−time

Abbildung 2: Integrierter Entwicklungsprozess mit formalen Notationen für hybride Systeme

Notationen im Entwurf hybrider Systeme zu verwenden,auch in anderen Forschergruppen aufgegriffen.

Als Ergebnis der ersten Projektphase wurde außerdemeine integrierte Methodik zum Einsatz der Notationen ent-wickelt, welche die Phasen Analyse, Grob- und Feinent-wurf mit einschließt (Abb.2)

2. Zweite Projektphase

Hauptergebnisse der zweiten Projektphase war die Ver-bindung der Arbeiten aus der ersten Phase mit anderenArbeiten im Rahmen des Schwerpunktprogrammes, sowiedie Definition einer formal fundierten Methodik, die denÜbergang zwischen verschiedenen Beschreibungstechni-ken aus BeQuest unter Verwendung von Verfeinerungsre-geln ermöglicht. Diese Infrastruktur unterstützt den durch-gängigen Einsatz von HySCs und HyCharts von der Ana-lysephase bis in die Entwurfsphase und ermöglicht es, dieEinhaltung der Systemanforderungen über Verfeinerungs-schritte sicherzustellen. In einer erweiterten Veröffentli-chung wurden die erarbeiteten Techniken in Bezug zu er-gänzenden Verfahren wie z.B. modellbasiertem Testen ge-setzt.

Zum Thema grundlegende Eigenschaften hybrider Sy-steme wurden am Beispiel Stabilität existierende Beweis-methoden aus der Systemtheorie auf HyCharts adaptiertund mit Verfahren aus der Informatik in Beziehung ge-setzt.

Mit diesen Aktivitäten einher ging eine Überarbeitungder Beschreibungstechniken aus der ersten Projektphase.Über die rein konzeptionellen Arbeiten hinaus wurde an-hand des im DFG-Projekt IMMA am Lehrstuhl Prof. Ben-der entstandenen CASE-Tools MaSiEd gezeigt, wie dieHyCharts-Methodik durch Werkzeuge unterstützt werdenkann. Zusätzlich wurde der formale Bezug der in Ma-

SiEd verwendeten Beschreibungstechnik zu HyCharts her-gestellt.

3. Dritte Projektphase

In der dritten Projektphase wurde das Thema “Verifi-kation hybrider Systeme” auf der Basis der Kooperationmit Prof. Schmid, Uni Karlsruhe, zuende geführt. Als Wei-terführung der Arbeiten im Umfeld der diskreten Spra-che PURR wurde die hybride Sprache HYPERQUARTZ

definiert, die sich gegenüber der diskreten Sprache ESTE-REL durch zusätzliche Konstrukte zur Modellierung hybri-der Berechnungen auszeichnet. Dabei hat sich herausge-stellt, dass die typischen Eigenschaften der Sprache ESTE-REL mit einem kontinuierliches Zeitmodell gut verträglichsind.

Die Eignung der Sprache für die Beschreibung einge-betteter Systeme wurde am Beispiel einer Karosseriehö-henkontrolle im Automobilbereich demonstriert.

Zum Thema “HyCharts im Mixed-Signal-Entwurf”wurde von uns die Sprache SystemC als geeignete Er-gänzung zu den eher abstrakten, analyseorientiertenHyCharts identifiziert, da eine breite Akzeptanz bei Ent-wicklern sowie eine gute Unterstützung durch Simula-toren sowie Werkzeuge für HW/SW-Synthese vorliegt.Wir haben deshalb in Zusammenarbeit mit dem Lehr-stuhl von Prof. Waldschmidt eine Übersetzung von Hy-Charts in SystemC-AMS definiert.

Im Gegensatz zu der in den ersten zwei Projektab-schnitten betrachteten Sprache HDFG ist SystemC vonvornherein als von Rechnern simuliertes Modell kon-zipiert. Dies schließt insbesondere die beliebig genaueBerechnung von kontinuierlichen Systemteilen aus. Ei-ne direkte Übersetzung der semantisch präzisen dis-kret/kontinuierlichen HyChart-Spezifikationen in Sys-temC scheidet also aus.

22

System-Level Structure

System-Level Requirements:

HySCs

Component-Level Structure:

HyACharts

Component-Level Requirements:HySCs

Component-Level Behavior:

HySCharts

Discretization and Implementation:

DiSCharts

Abbildung 3: Methodisches Vorgehen für Fallstudie“Train Brake Controller”

Die Bearbeitung der Fallstudie “Train Brake Control-ler” dient im Projekt BeQuest dem Ziel, die Projektergeb-nisse anhand einer praxisnahen Aufgabenstellung zu über-prüfen und die Überleitung der Ergebnisse in die prakti-sche Nutzung durchzuführen. Dazu wurde zunächst eineinformelle Spezifikation, ergänzt durch mündliche Aussa-gen der Entwickler (implizites Erfahrungswissen), in eineformalisierte Anforderungsspezifikation in der Beschrei-bungstechnik HySCs übersetzt. Die formalisierten Anfor-derungen wurden dann in ein HyCharts-Modell übersetzt.Bei diesem (hier manuell ausgeführten) Schritt werdendie partiell beschriebenen Systemabläufe zu einer einga-bevollständigen HyCharts-Spezifikation ergänzt, es findenalso generell im Rahmen der Übersetzung weitere Festle-gungen statt. Abb.3 zeigt das methodische Vorgehen fürdie Fallstudie “Train Brake Controller”.

Als Ergebnis der Fallstudie wurde festgestellt, dass dieim Projekt erarbeiteten Beschreibungstechniken, mit derAusnahme der intuitiv schwer nachzuvollziehenden hier-archischen Sequenzdiagramme (HHSCs), für die Model-lierung der Fallstudie adäquat waren.

Auf der Grundlage des Fallstudie wurde die erweiterteBeschreibungstechnik AutoFLEX vorgestellt. AutoFLEX

ist eine Adaption von diskreten HyCharts auf das grafi-sche CASE-Werkzeug AutoFOCUS. Ziel ist die Syntheseverteilter Software für eingebettete Systeme. Dieser An-spruch geht deutlich über die Ziele des Projektes BeQuesthinaus.

4. Wirtschaftliche Verwertung, Folgeprojek-te

Auf der Basis der Erfahrungen mit der Modellie-rung und Verfeinerung von Modellen hybrider Systemeim Projekt BeQuest wurde in weitern Veröffentlichun-gen ein integrierter Ansatz zur modellbasierten Entwick-lung automobiler Software-Systeme präsentiert. Innerhalbder automobilen SW-Landschaft steht dabei, wie auch imBeQuest-Projekt, die Domäne der Regelungs- und Steue-rungssysteme im Vordergrund.

Der Ansatz basiert auf der in BeQuest definierten Be-

EmergencyBraking

emergencyBrake

System

ventilate

shut

ControlLoop SolenoidValve

T

EngineerConsole

belowEbPressure

MainLine

T

Abbildung 4: HySC: Notbremsung (System)

PreControl

GradientControl

ThrustControl

Voter IntegratorbrakeCmd

pTarget

pSource

pTarget

pSource

pDot

pTarget

pSource

select

pDot

pDot1

pDot2

select pDot

pDot

pSet

pSet

pSet

belowEbPressure

solenoidValve

lastBrakeCmd

Abbildung 5: HyAChart: System “Train Brake Controller”

schreibungstechnik AutoFlex. Ein Schwerpunkt des An-satzes sind dabei formalisierte Prozesschritte ähnlich de-nen in BeQuest definierten Verfeinerungsregeln. Zu denweiteren abgedeckten Themen zählen Codesynthese ausModellen und Implementierungsvarianten, die automati-sierte Synthese von Modellen des Grobentwurfs aus vor-handenen Designdaten, sowie Kopplung mit kommerziel-len Werkzeugen. Die Erarbeitung des Ansatzes ist The-ma eines laufenden Antrages beim Bundesministerium fürBildung und Forschung (BMBF) unter Beteiligung einesIndustriekonsortiums.

5. Fallstudie “Train Brake Controller”

Zur Illustration der Methode wird im Folgenden dieim Rahmen des Projekts dokumentierte Fallstudie “TrainBrake Controller” auszugsweise gezeigt. Basis für dieFallstudie ist ein kommerzielles Bremssystem für Züge,dassen Dokumentation von der Firma Knorr-Bremse zurVerfügung gestellt wurde. Das generelle Vorgehen ist inAbb.3 illustriert: Dabei wird das System Schritt für Schrittmit Hilfe der BeQuest-Beschreibungstechniken spezifi-ziert und in Einzelkomponenten zerlegt. Abb.4 zeigt ei-ne mittels HySC illustrierte Beispielsequenz für eine sy-stemweite Anforderung (Notbremsung). Abb.5 zeigt dieanhand der Anforderungen erfolgte Zergliederung des Sy-stems in Einzelkomponenten. Das Verhalten von Kom-ponenten wird mit Hilfe von HySCs zunächst teilwei-se (Abb.6) und dann mit der Beschreibungstechnik Hy-SCharts vollständig (Abb.7 und 8) spezifiziert. Als Bei-spiel dient hier die Komponente “PreControl”.

23

PreControl GradientControl

FastFalling

brakeCmd = 9

Hold

Braking(8)

WaitForPressureDrop

onTarget

pTarget = pB(8)

pSource = pB(8)

Hold

belowEbPressure

shut

SolenoidValve

T

EmergencyBraking

Abbildung 6: HySC: Komponente “PreControl”, Not-bremsung

PreControl

embfall2ftt

embfall2brake

brake2embfall

brake2ftt

ftt2brake

timer_inc

FillingThrustTimeout

BrakeReleaseEmergency

BrakingFallback

brake2brake

ftt2embfall

Abbildung 7: HySChart: Komponente “PreControl”

EmergencyBrakingFallback

WaitForPressureDrop

embfall2waitpdrop

FallbackAction

EmergencyBraking

waitpdrop2embrake

fallback2embrake

waitpdrop2fallback

embfall2ftt,embfall2brake

brake2embfall,ftt2embfall

Abbildung 8: HySChart: Zustand “EmergencyBraking” inKomponente “PreControl”

Literatur

[1] BALDAMUS , M. und T. STAUNER: Modifying EsterelConcepts to Model Hybrid Systems. In: Proceedings ofSLAP’02, Nummer 5 inElectronic Notes in TheoreticalComputer Science 65. Elsevier Science, 2002.

[2] BAUER, A., J. ROMBERG und B. SCHÄTZ: The AutoMo-De Design Notation: Concepts, Consistency, and Timing.Internal Report, 2003.

[3] GROSU, R., I. KRÜGER und T. STAUNER: Hybrid Se-quence Charts. Technischer Bericht TUM-I9914, Techni-sche Universität München, 1999.

[4] GROSU, R., I. KRÜGER und T. STAUNER: RequirementsSpecification of an Automotive System with Hybrid Se-quence Charts. In: Proc. of WORDS’99F, Fifth Interna-tional Workshop on Object-oriented Real-time DependableSystems. IEEE, 1999.

[5] GROSU, R., I. KRÜGER und T. STAUNER: Hybrid Se-quence Charts. In: Proc. of ISORC 2000. IEEE, 2000.

[6] GROSU, R. und T. STAUNER: Visual Description of Hy-brid Systems. In: Workshop On Real Time Programming(WRTP’98). Elsevier Science Ltd., 1998.

[7] GROSU, R. und T. STAUNER: Modular and Visual Speci-fication of Hybrid Systems – An Introduction to HyCharts.Accepted forFormal Methods in System Design, 2000.

[8] PÉTER, I., A. PRETSCHNER und T. STAUNER: Hetero-geneous Development of Hybrid Systems. In: Proc. of GIworkshop Rigorose Entwicklung software-intensiver Syste-me. Ludwig-Maximilians-Universität München, Institut fürInformatik, Bericht 0005, September 2000.

[9] PRETSCHNER, A., O. SLOTOSCHund T. STAUNER: Deve-loping Correct Safety Critical, Hybrid, Embedded Systems.In: Proc. of New Information Processing Techniques forMilitary Systems, RTO Meeting Proceedings MP-049. NA-TO Research and Technology Organization, Oktober 2000.

[10] ROMBERG, J.:The Train Brake Controller: A Case Studyusing HySCs and HyCharts. Technical Report, TechnischeUniversität München, Institut für Informatik, 2003.

[11] ROMBERG, J. und C. GRIMM : Refinement of Hybrid Sy-stems from Formal Models to Design Languages. In: Pro-ceedings of FDL ’03, 2003.

[12] STAUNER, T.: Specification of (parts of) a Lip-Sync Proto-col Using HyCharts. In: FBT’99, 9. GI/ITG-Fachgespräch“Formale Beschreibungstechniken für verteilte Systeme”.Herbert Utz Verlag Wissenschaft, 1999.

[13] STAUNER, T.: Hybrid Systems’ Properties - Classificati-on and Relation to Computer Science. In: Proc. of Euro-CAST’2001 (Eight International Conference on ComputerAided Systems Theory), LNCS. Springer-Verlag, 2001.

[14] STAUNER, T.: Systematic Development of Hybrid Systems.Doktorarbeit, Technische Universität München, 2001.

24

Durchgängige Entwurfsmethodik dezentraler Steuerungselemente fürmechatronische Systeme in der Automatisierungstechnik (DESSY)

Clemens Reichmann, Markus Kühl, Philipp GrafInstitut für Technik der Informationsverarbeitung (Prof. Dr. K. D. Müller-Glaser)

Universität Karlsruhe

Zusammenfassung

Die Integrationsplattform GeneralStore ist ein Werk-zeug, welches einen durchgängigen Entwurfsprozess vomModell zum ausführbaren Code für eingebettete Systemeunterstützt. Die Software bietet eine Kopplung von Modell-teilen aus unterschiedlichen Modellierungsdomänen aufModellebene. Aus dem gekoppelten Modell kann durch ei-ne automatische Codegenerierung, mit Hilfe kommerziel-ler Codegeneratoren, ein Prototyp bzw. das Zielsystem er-stellt werden.

1. Umfeld und Zielsetzung

Durch die verstärkte Akzeptanz objektorientierter An-sätze im Bereich des Software- aber auch des Systement-wurfs befindet sich der Entwurf eingebetteter Systeme imUmbruch. Dieser Wandel wird in erster Linie von der stei-genden Systemkomplexität getrieben, aber auch durch im-mer kürzer werdende Produktzyklen geprägt, ohne dassdabei der begrenzende Kostenfaktor vernachlässigt wer-den darf. Mit der Einführung der Unified Modeling Lan-guage (UML) als standardisierte und verbreitete Notati-onsform im Bereich des Softwareentwurfs wächst auchdie Häufigkeit und Qualität der Unterstützung von UMLin kommerziellen CASE-Werkzeugen.

Ausgelöst wird dieser Trend durch die zunehmendeNutzung von Softwarekomponenten in typischen einge-betteten Systemen. Beispielhaft seien Systeme im Au-tomobilbereich genannt, die üblicherweise aus zahlrei-chen Software-Subsystemen, ereignisgetriebenen Kompo-nenten und häufig auch (quasi-)zeitkontinuierlichen Rege-lungssystemen bestehen. Diese Systeme übernehmen Auf-gaben von der Diagnose über (verschlüsselte) Kommuni-kation bis hin zu datenbankorientieren Diensten.

Einen häufig angewandten Ansatz zum Umgang mitder solchen Systemen inhärenten Komplexität währenddes Systementwurfs bietet dask̈onzeptorientierte Rapid-Prototyping̈. Konzeptorientiertes Rapid-Prototypingbeschreibt einen Prozess zur schnellen Umwandlung ei-ner Spezifikation, welche die Anforderungen mit Hilfeverschiedener Modellierungstechniken für ereignisdis-krete, regelungstechnische und Softwaresysteme erfasst,in einen lauffähigen Prototypen. Dabei wird auf auto-matische Code-Generatoren von CASE-Werkzeugen wie

MATLAB/Simulink, ASCET-SD oder Statemate zurück-gegriffen. Der erhaltene Prototyp dient meist der schnel-len Verifizierung von Anwendungszielen und -konzeptenund soll eine breite Basis von Hardware-Schnittstellen un-terstützen. Die Kosten der Hardware sind dagegen nichtkritisch, da Prototypen nur in kleiner Stückzahl zur Verfü-gung stehen müssen und ein solches System für mehrerePrototypen wiederverwendet werden kann.

Abbildung 1. Rapid-Prototyping

Bisher wurde das konzeptorientierte Rapid-Prototyping(Abbildung. 1) hauptsächlich durch CASE-Werkzeuge ge-prägt, die auf State Charts, also der Modellierung hierar-chischer endlicher Zustandsautomaten, oder dem Entwurfregelungstechnischer Systeme mit Hilfe von Block-diagrammen beruhen. In der Vergangenheit lag daherder Schwerpunkt bei der Entwicklung von Metho-den und Werkzeugen zur Verbesserung der Integrationdieser beiden Modellierungsansätze, wie sie beispiels-weise in MATLAB mit Simulink und Stateflow realisiertist.

Die angesprochenen sich wandelnden Anforderungenan eingebettete Systeme verschieben jedoch den Fokusvon einem reinen Ansatz über State Charts und Blockdia-gramme hin zu einer mehr und mehr Software-orientierenSicht auf den Systementwurf, wie er durch moderne in derSoftwareentwicklung genutzte Entwurfswerkzeuge gebo-ten wird. Während die Modellierung zustandsorientierterSysteme unterstützt wird, ist ein großes, allen kommerziel-len Software-Entwurfswerkzeugen gemeines Problem diefehlende Unterstützung für den Entwurf von Regelungssy-

25

stemen. Eine Modellierung von Systemen, die zeitdiskreteoder zeitkontinuierliche Modellteile mit Softwarekompo-nenten verbinden ist daher derzeit nicht durchgängig mög-lich.

Der Entwickler soll jedoch nicht gezwungen werden,seine vertraute und ihm angepasste Modellierungswelt zuverlassen. Die Integration der verschiedensten Modellie-rungsansätze ist der Weg, welcher dieses Spannungsfeldlösen kann.

Aus diesem Grund wird eine einheitliche, auf ei-nem Metamodell beruhende, Beschreibung benötigt, dieeinen konsistenten und lückenlosen Entwurfsablauf er-möglicht. Auch die Integration der einzelnen Bereiche imHinblick auf Codeerzeugung, Daten- und Nachrichten-austausch, Taskverteilung, Modellversionierung, Nutzer-verwaltung und automatisierter Transformation zwischenden Modellierungsbereichen muss berücksichtigt wer-den.

Besondere Beachtung muß auch die Verwendung vonbestehenden oder sich abzeichnenden Standards undde-facto Standards im Hinblick auf Methoden, Beschrei-bungssprachen, Datenaustauschformate und industriellverfügbaren Werkzeuge finden. Dies geschieht so-wohl um die Solidität des Ansatzes zu unterstützen, aberauch um eine gute Akzeptanz vor dem Hintergrund der tat-sächlichen Entwicklungsarbeit im industriellen Umfelderst zu ermöglichen.

Im wissenschaftlichen und kommerziellen Umfeld un-serer Arbeit findet man mehrere Ansätze, welche versu-chen, die Kluft zwischen verschiedenen Modellierungs-formen zu überbrücken. Im Bereich der Co-Simulation istzum Beispiel das Produkt EXITE der Firma Extessy zunennen. Andere Werkzeuge (z.B. MLDesigner der FirmaMLDesign Technologies oder Ascet-SD der Firma ETAS)versuchen ebenfalls zahlreiche Modellierungsmöglichkei-ten in einem Werkzeug zu integrieren, bieten aber geradeim Softwarebereich nicht die Mächtigkeit und Akzeptanzvon UML.

2. Entwurfsmethodik

Während sich allgemein im Bereich der objektorien-tierten Softwareentwicklung die Unified Modeling Lan-guage (UML) als Modellierungssprache etabliert hat, istdies im Umfeld des ingenieurnäheren Entwurfs eingebet-teter Systeme, beispielsweise im Automobilbereich meistnicht der Fall.

Wie bereits in Abschnitt 1 dargestellt, ist eine wichti-ge Ursache dafür ist, dass gerade Fragen der Regelungs-technik und Signalverarbeitung optimal mit Hilfe ande-rer Notationen und Werkzeuge, beispielsweise mit MAT-LAB/Simulink/Stateflow von Mathworks, bearbeitet undbeschrieben werden können, die somit die Entwurfsba-sis für solche Aufgaben darstellen. Der Nachteil solcherLösungen ist, dass diese Notationen nicht die Mächtig-keit besitzen, um allgemeine komplexe Softwareproble-me adäquat zu lösen. Dieses Handicap gewinnt dadurch anBrisanz, dass der Anteil reiner Softwareentwicklung beimEntwurf eingebetteter Systeme stetig ansteigt.

Abbildung 2. Betrachtete Modellierungsdomä-nen und Beispiele für Werkzeuge

Es besteht also der Bedarf nach einer Methodik, umein Entwurfsproblem so zerlegen zu können, dass einzel-ne Unterprobleme mit dem bestmöglichen Entwicklungs-werkzeug bearbeitet werden können (Abbildung. 2). DieKopplung dieser Untermodelle muss dabei transparent er-folgen, so dass wie bei der Nutzung nur einer Notation ei-ne einfache Generierung und Erprobung eines Prototypenmöglich wird.

Die im Rahmen des DESSY-Projektes entwickelte Me-thodik, welche in der Realisierung der Integrationsplatt-form GeneralStore mündete, ermöglicht einen durchgän-gigen Entwurfsprozess vom Modell zum ausführbaren Co-de (Abbildung. 5) für eingebettete elektronische Systeme.

Als vereinheitlichtes Datenmodell zur Verwaltung undAblage aller Modelldaten des Entwurfs wird die UML ver-wendet. Grund für diese Entscheidung waren nach Prü-fung weiterer Möglichkeiten neben der schon sehr großenMächtigkeit der Modellierung, die sehr gute Erweiterbar-keit und das durchgängige Metamodellierungs-Konzeptdes Standards.

Abbildung 3. Modelltransformation zwischen No-tationen und Codegenerierung

Zur Integration weiterer Paradigmen zur Systemmodel-lierung, insbesondere von in der UML nicht enthaltenensignalflußorientierten Ansätzen, wird die dort modellier-te Systemstruktur in das UML-Metamodell transformiertund kann dann in einem auf der UML basierenden Re-pository abgelegt und versioniert werden. Das prinzipiel-le Vorgehen dabei zeigt (Abbildung. 3). Neben der Ver-

26

einheitlichung der Modellverwaltung wird dadurch eineDurchgängigkeit der Entwicklung über Notationsgrenzenhinweg möglich.

Aus dem gekoppelten Modell kann durch automati-sche Codegenerierung sowohl ein Prototyp als auch Se-riencode für eine immer größer werdende Zahl an Zie-larchitekturen (Microcontroller und DSP, wie z.B. HC12und C167) erstellt werden. Die Codeerzeugung für ereig-nisdiskrete und regelungstechnische Systemteile geschiehtdabei durch erprobte kommerzielle Codegeneratoren (z.B. Rhapsody in MicroC oder Embedded Coder). Für denUML-Modellteil werden templategesteuert sowohl struk-turelle als auch Verhaltensaspekte mit Hilfe eines selbstentwickelten und in GeneralStore umgesetzten Codegene-rators in C, C++ und Java transformiert.

Durchgängigkeit des Entwurfs bedeutet jedoch auch,dass die entworfenen Teilmodelle nicht isoliert voneinan-der betrachtet werden und dass der Entwickler zu keinemZeitpunkt die Modellierungswelt verlassen und händischAnpassungen vornehmen muss. Von Interesse sind bei ei-nem Entwurf der hier betrachteteten heterogenen Syste-me insbesondere die Schnittstellen zwischen den unter-schiedlich notierten Modellteilen. Aus diesem Grund wur-den im Rahmen dieses Projektes Verfahren entwickelt undimplementiert, welche automatisch sowohl für signalfluß-orientierte Modellierung in MATLAB/Simulink/Stateflowals auch für ereignisdiskret in i-Logix Statemate model-lierte Teilsysteme im UML-Modell Schnittstellenklassenerzeugen, welche einen für den Entwickler transparentenZugriff auf die durch die vorgenannten Werkzeuge model-lierten und in Code umgesetzten Systemteile ermöglicht.

Insgesamt ergeben die angeführten Teilaspekte der hiervorgestellten Entwurfsmethodik für heterogen modellier-te eingebettete Systeme einen Entwurfsablauf, der einedurchgängige Modellorientierung vom Entwurf mit Hil-fe verschiedener Werkzeuge und Ansätze bis hin zum Co-de und lauffähigen Prototypen ermöglicht. Unterstützt undumgesetzt wird die Methodik durch das Software-SystemGeneralStore (Abbildung. 4).

Das Projekt hat einen Stand erreicht, der eine vollauto-matische Generierung eines lauffähigen Prototyps aus ei-nem heterogenen Modell ermöglicht.

Um die Leistungsfähigkeit des Ansatzes zu zeigen,wurden zwei Fallstudien durchgeführt: In einer ersten Fall-studie wurde ein automatischer Probengeber (Autosamp-ler) für ein chemisches Analysegerät der Firma Agilentheterogen modelliert und durch Codeerzeugung automa-tisch ein lauffähiger Prototyp erzeugt. Eine zweite Fallstu-die konzentrierte sich auf die Integration eines Werkzeu-ges zur Systemvalidierung, dem KeY Tool der UniversitätKarlsruhe, in unsere Werkzeugkette.

3. Ergebnisse

Aus unserer Sicht bietet die entstandene Methode einegegenüber dem Stand der Technik deutliche Verbesserungim Hinblick auf die in Abschnitt 1 genannte Problemstel-lung im Bereich eingebetteter Systeme (steigende System-

Abbildung 4. Integrationsplattform GeneralStore

komplexität, kürzere Produktzyklen, steigender Anteil ob-jektorientierter Softwareentwicklung).

Im Folgenden sollen die wichtigsten Ergebnisse kurzumrissen werden (Abbildung. 5):

Abbildung 5. Entwurfsmethodik im Überblick

Unser in Abbildung. 5 im Überblick gezeigte An-satz und seine Verwirklichung in GeneralStore ermöglichteinen durchgängig modellbasierten Entwurf. Mehre-re Entwickler können zur gleichen Zeit und mit unter-schiedlichen Werkzeugen an verschiedenen Teilen desselben Modells arbeiten. Implementiert wurde eine An-bindung an zahlreiche UML-Werkzeuge, sowie an MAT-LAB/Simulink/Stateflow und Statemate.

Der in Abbildung. 3 gezeigte White-Box-Ansatz alsKopplungsstrategie für eine durchgehende Werkzeugkettehat mit ihrer kompletten Datenintegration den Vorteil ei-ner gewährleisteten Konsistenz der Modelldaten zwischenden Entwicklungswerkzeugen. Auch die flexible Granu-larität bei der Modellpartitionierung auf Werkzeuge undEntwickler erwies sich als Vorteil dieser Herangehenswei-se.

Um paralleles Arbeiten mehrerer Entwickler zu ermög-lichen, ist die Modellverwaltung datenbankbasiert. Zu-dem implementiert GeneralStore Benutzerverwaltung undeinen Versionierungsalgorithmus, der das Modell auf ver-schiedensten Granularitätsebenen verwalten kann.

27

Durchgängigkeit heißt auch, dass der Entwickler zukeinem Zeitpunkt die Modellierungswelt verlassen undhändisch Anpassungen vornehmen muss. Um diese For-derung zu erfüllen, ermöglicht GeneralStore die automa-tische Generierung von Schnittstellenklassen, die sowohlSimulink/Stateflow-, als auch Statemate-Modelle in trans-parenter Weise aus der UML-Welt zugänglich machen.Dies ist ein Ansatz der, verglichen mit manueller Program-mierarbeit, deutlich unanfälliger gegenüber Fehlern undviel robuster gegenüber Änderungen in einzelnen Modell-teilen ist.

Der Endpunkt eines so entworfenen Systems soll einlauffähiger Prototyp sein. GeneralStore kann für UML-Modelle selbstständig und mit Hilfe leicht anpassbarerTemplates Code generieren. Für in Simulink/Stateflowoder Statemate modellierte Teilsysteme werden kommer-zielle Codegeneratoren angesteuert. Die Kommunikationzwischen den Modellteilen geschieht über die beschriebe-nen automatisch generierten Schnittstellen.

Das Projekt hat einen Stand erreicht, der eine vollauto-matische Generierung eines lauffähigen Prototyps aus ei-nem Modell ermöglicht.

Die Tragfähigkeit unserer Methodik konnte im Rah-men zweier Fallstudien überprüft werden. In einer erstenumfangreichen Fallstudie (Abbildung. 6), welche den ge-samten Entwurfsweg für einen automatischen Probenneh-mer (Autosampler) für ein chemisches Analysegerät vonder Spezifikation bis zum ausführbaren Modell umfasste,konnte die Durchführbarkeit unseres Ansatzes erfolgreichverifiziert werden.

Abbildung 6. Fallstudie: Autosampler AgilentTechnologies Waldbron

Die dort gewonnenen Ergebnisse und das dem Projektentgegengebrachte Interesse aus der Industrie bringen unszu der Einschätzung, dass GeneralStore in hohem Maßerelevant für praktische Entwurfsprobleme ist.

Im engeren Sinne existiert derzeit kein anderes Werk-zeug, welches es ermöglicht objektorientierte Software-entwicklung mit Hilfe der UML mit anderen Beschrei-bungsformen automatisiert auf Modellebene verwaltenund koppeln zu können.

Auch gleichzeitiges Arbeiten an unterschiedlichen Mo-dellteilen und gleichzeitige Versionierung von Teilsyste-

men ist ansonsten nur vereinzelt bei einigen Einzelwerk-zeugen, jedoch nicht werkzeugübergreifend möglich. FürMATLAB/Simulink/Stateflow stellt für sich alleine einNovum dar, dass Subsysteme eine Modells herausgelöstund getrennt bearbeitet und versioniert werden können. Ei-ne Kommerzialisierung allein dieser Eigenschaft wird ge-genwärtig geprüft.

Am Markt existieren Bibliotheken zur Repräsentierungand Serialisierung von UML-Modelldaten, welche meistals Basistechnologie für UML-Modellierungswerkzeugegenutzt werden (z.B. Netbeans MDR). Diese enthalten je-doch keine Möglichkeit zur Versionsverwaltung und bie-ten damit auch keine Möglichkeit zu verteiltem Arbeiten.

Literatur

[1] Klaus D. Müller-Glaser Clemens Reichmann, Markus Kühl.Overall system design approach doing object-oriented mo-deling to code-generation for embedded electronic systems.ETAPS FASE Conference 2003, Warschau, April 2003.

[2] Klaus D. Müller-Glaser Clemens Reichmann, Philipp Graf.Vom modell zum code. EKA 2003, Braunschweig, Juni2003.

[3] Ingo Prötel Klaus D. Müller-Glaser Markus Kühl, Cle-mens Reichmann. From object-oriented modeling to codegeneration for rapid prototyping of embedded electronic sy-stems.IEEE RSP-Workshop 2002, Darmstadt, Juli 2002.

[4] Markus Kühl und Clemens Reichmann und Bernhard Spit-zer und Klaus D. Müller-Glaser. Eine durchgehende ent-wurfsmethodik für das rapid prototyping von eingebetteten,elektronischen systemen.it+ti Heft 6/2001, Oldenbourg Ver-lag, Dezember 2001.

[5] Markus Kühl und Clemens Reichmann und Bernhard Spit-zer und Klaus D. Müller-Glaser. Eine durchgehende ent-wurfsmethodik für das rapid prototyping von eingebettetensystemen.Workshop Modelltransformation und Werkzeug-kopplung, Braunschweig, Juni 2001.

[6] Clemens Reichmann und Philipp Graf und Klaus D. Müller-Glaser. Ein durchgängiger ansatz vom systementwurf zur co-degeneration auf basis eines objektorientierten modells füreingebettete heterogene systeme.ATP, Automatisierungs-technische Praxis, Oldenbourg Industrieverlag, 45 (2003) 6,Juni 2003.

28

Entwurf eingebetteter paralleler Steuerungssysteme für integriertemulti-axiale Antriebssysteme

Bernd DäneTheoretische und Technische Informatik (Prof. Dr.W. Fengler)

Technische Universität Ilmenau

Zusammenfassung

Gegenstand des Projekts war der modellbasierte Ent-wurf der Hard- und Software für eingebettete Systeme,die bei innovativen Mehrkoordinatenantrieben zur Anwen-dung kommen. Dabei wurde besonderes Augenmerk aufFragen der Validierung und Verifikation gelegt. Es wur-den verschiedene Formalismen untersucht, wie HybridePetrinetze, Hybride Objektnetze, Intervall-Petrinetze undMessage-Sequence-Charts. Betrachtet wurden zum Bei-spiel Fragen der Zeitverifikation und der gegenseitigenUmformbarkeit. Die Implementierung der Software in ei-ne Echtzeit-Umgebung wurde ebenfalls betrachtet.

1. Problemstellung

Eingebettete Systeme müssen oft unter harten Echtzeit-bedingungen arbeiten. Ein Beispiel ist die Steuerung undRegelung von Bewegungsvorgängen innerhalb integrier-ter Mehrkoordinatenantriebe (siehe Abbildung 1 und Ab-bildung 2). Hier werden Funktionen, die in konventionel-len Lösungen durch mechanische Baugruppen ausgeführtwerden, durch eingebettete Systeme übernommen. Dazusind geschlossene Regelkreise mit kurzen Reaktionszeitenund komplexen Algorithmen erforderlich.

Abbildung 1. Schematische Darstellung einesplanaren Mehrkoordinatenantriebes

Beim Entwurf der eingebetteten Systeme müssen zu ei-nem frühen Zeitpunkt Entwurfsentscheidungen getroffenwerden, die die Performance und die Kosten des fertigenSystems entscheidend beeinflussen. Zu diesem Zeitpunktist in der Regel noch kein funktionierendes Exemplar desGesamtsystems verfügbar. Der Entwurf und insbesonderedie Verifizierung und Validierung müssen daher in mög-lichst aussagekräftiger Form an einem Modell vorgenom-men werden.

Abbildung 2. Schematische Darstellung einerhoch auflösenden Mehrkoordinatenpositionier-maschine

Insbesondere die immens wichtigen Aussagen zu Zei-teigenschaften bereiten dabei regelmäßig große Schwie-rigkeiten. Die Lösung besteht darin, die Zeiteigenschaftenin den Modellen in möglichst qualifizierter Weise darzu-stellen und mittels fortgeschrittener Analyseverfahren aus-zuwerten. Die Modelle müssen dazu nicht nur das zu ent-werfende eingebettete System darstellen, sondern das Ge-samtsystem in seiner Vielfalt und Heterogenität widerspie-geln können.

2. Ausgangssituation

Aus dem Gesagten ergibt sich die Notwendigkeit, imProzess der Modellierung folgende sich gegenseitig wider-

29

sprechende Anforderungen zu erfüllen:

• Multi-Domain-Fähigkeit, d.h. Verknüpfung undgleichberechtigte Behandlung unterschiedlicher Mo-dellierungsparadigmen (insbesondere zeitdiskreteund quasikontinuierliche Ansätze),

• Qualifizierte Notation von Zeiteigenschaften undZeitrestriktionen,

• Durchgehender Weg bis zur Implementierung vonHard- und Software.

Verfügbaren Lösungen mangelt es an der gleichzeitigenBeachtung dieser drei Forderungen. Weit verbreitete Mo-dellierungwerkzeuge wie Matlab bieten z.B. keine wirkli-che Multi-Domain-Fähigkeit, sondern stellen jeweils einebestimmte Domäne in den Vordergrund.

Ausgewiesenen Multi-Domain-Entwurfswerkzeugenwie z.B. Ptolemy oder ML-Designer mangelt es hinge-gen an der vollen Unterstützung von formaler Analy-se und von Implementierungsvorgängen im Targetsystembei Beibehaltung der Multi-Domain-Eigenschaften.

Stark formalisierte Modellierungsmittel wie z.B. Petri-netze, Sequenzdiagramme bzw. Message Sequence Charts(MSC) und vergleichbare Darstellungsformen sind einerexakten Analyse und in der Regel auch einer automa-tischen oder halbautomatischen Target-Implementierungwesentlich besser zugänglich. Ihnen fehlt aber in beson-ders starkem Maße die Fähigkeit, unterschiedliche Model-lierungsdomänen abzudecken.

3. Wissenschaftliche Fortschritte

Ausgehend von dieser Situation wurde das Kon-zept entwickelt, die Darstellungsmöglichkeiten mitstark formalisierten Modellierungsmitteln wie Petri-netzen und MSC zu untersuchen und zu erweitern [3].Durch Transfomationen zwischen diesen Darstellungs-mitteln untereinander und mit solchen aus dem Be-reich von Multi-Domain-Werkzeugen soll ein Weg vonder Multi-Domain-Modellierung zur formalen Analy-se und darauf aufbauend auch zur Implementierungim Targetsystem entwickelt werden. Im Verlauf die-ses Weges werden Beiträge zur Erweiterung der Darstel-lungsmittel und zur gegenseitigen Konvertierung gelei-stet.

3.1. Zeitanalyse mit Intervall-Petrinetzen (IPN)

Petrinetze mit Zeitintervall-Attributen (siehe Abbil-dung 3) eröffnen den Weg zur formalen Analyse zeitbezo-gener Eigenschaften für komplexe Systeme. Die Analysedes Modells liefert Angaben über folgende Eigenschaf-ten:

• Erreichbarkeit und Nichterreichbarkeit von System-zuständen,

• Beschränktheit von Systemressourcen (z.B. Spei-cher) oder Verklemmungen im System, d.h. Syn-chronisationsfehler zwischen Teilmodulen, die zu

unerwünschtem Stillstand im Gesamtsystem füh-ren.

[2.1,4.3]

Zeit521 30 4

Abbildung 3. Prinzip einer zeitintervallbewerte-ten Transition

Das Problem bei den klassischen Petrinetzen bestehtdarin, dass der Erreichbarkeitsgraph des untersuchten Net-zes, der als Hilfskonstrukt zur Analyse der Systemeigen-schaften verwendet wird, bei steigender Größe des Netzessehr schnell an Größe und an Anzahl seiner Zustände zu-nimmt. Man spricht hierbei von einer Zustandsexplosion.

Um den Zustand eines Intervall-Petrinetzes beschrei-ben zu können, muss im Gegensatz zu den klassischen Pe-trinetzen neben den Markierungen auch die Zeitkompo-nente berücksichtigt werden. Der Erreichbarkeitsgraph äh-nelt dem einfacher Petrinetze, aber Zustandübergänge sindzusätzlich von den diskreten Zeitpunkten abhängig (sieheAbbildung 4). Für komplexe Netze besteht hier die Ge-fahr, dass der Erreichbarkeitsgraph explodiert.

( )0020 ,,=m

( )0111 ,,=m ( )1012 ,,=m

( )0203 ,,=m ( )1104 ,,=m ( )2005 ,,=m

t2

t2

t2

t1

t1

[3,5]

t1

[4,6]

t2

t1

6 Sekunden 4 - 6 Sekunden

nicht erreichbar

Abbildung 4. Erreichbarkeitsgraph mit zeitinter-vallbezogenen Einschränkungen

30

Die Analysemethode von Popova gibt jedoch die Mög-lichkeit, einzelne Entwicklungsprozesse im Netz, d.h. Pfa-de im Erreichbarkeitsraum, zu verfolgen und unter ver-tretbarem Rechenaufwand Prozesseigenschaften zu ana-lysieren. Für einen angegebenen Anfangszustand und ei-ne Transitionssequenz lassen sich mehrere Zeitkennziffernermitteln:

• worst-case-Zeit: kürzeste und längste Zeitdauer,

• Einhaltung einer gegebenen Zeitschranke (deadline),

• Grenzwerte für die Intervalle, bei denen die Schaltse-quenz eine minimale Dauer nicht überschreitet,

• Grenzwerte für die Intervalle, bei denen ein bestimm-ter Zustand im Netz nicht erreicht werden kann.

Auf Grundlage dieser Methode wurde ein Analysever-fahren entwickelt [4] und, wie später noch beschrieben, ineinem Petrinetz-Werkzeug implementiert.

3.2. Erweiterung der Hybriden Objektnetze umdie Intervall-Petrinetze

Der Formalismus der Hybriden Objektnetze nachDrath, wie er in dem Werkzeug VisualObjectNet++ ent-halten ist, vereint diskrete und kontinuierliche Kompo-nenten. Dazu werden zusätzlich zu den zeitdiskreten Ele-menten des gewöhnlichen Petrinetzes kontinuierlicheTransitionen und Plätze definiert. Damit existiert inner-halb eines formal gut analysierbaren Darstellungsmittelseine gleichwertige Kombination unterschiedlicher Model-lierungsdomänen [1]. Die Hybriden Objektnetze verfügenüber ein leistungsfähiges objektorientiertes Hierarchie-konzept (Abbildung 5).

Abbildung 5. Hierarchieaufbau in Hybriden Ob-jektnetzen

Das Konzept der Zeitintervalle wurde nun in diezeitdiskreten Transitionen integriert, um eine Zu-gangsmöglichkeit zu den Analysemöglichkeiten derIntervall-Petrinetze zu schaffen. Damit ist ein Schritt

auf dem Wege zu formal analysierbaren domänenüber-greifenden Darstellungsmitteln gegeben. Zur Unterstüt-zung der praktischen Anwendung und als Werkzeugfür weitere Untersuchungen wurde das schon erwähn-te Werkzeug VisualObjectNet++ um das Konzept derIntervall-Petrinetze erweitert und auch die im vorigen Un-terabschnitt beschriebene Analysemethode implementiert[5].

Zur Validierung des Konzepts wurden Modelle fürdie beispielhaft betrachteten Mehrkoordinaten-Antriebs-und Positioniersysteme entwickelt und untersucht. Ab-bildung 6 zeigt einen Ausschnitt aus einem zeitinter-vallbewerteten Hybriden Objektnetz für ein derartigesAntriebssystem.

vorw

Vorwärts

rueckw

Rückwärts

Pos

Position

Sin Sinus

Cos Cosinus

stop

Stop

m1

m2P

m3

1

1

-1

-1cos(Pos)-Cos

sin(Pos)-Sin

Abbildung 6. Ausschnitt aus einem zeitintervall-bewerteten Hybriden Objektnetz für einen Mehr-koordinatenantrieb

3.3. Transformation von Message SequenceCharts in Intervall-Petrinetze

Das Konzept der Transformation von Message Se-quence Charts in Intervall-Petrinetze dient als weitererAngriffspunkt für die Überführung vorhandener spezia-lisierter Modelldarstellungen in eine formal analysier-bare Darstellungsform. Damit wird das Ziel unterstützt,aus vorhandenen Modellen eine besser analysierbare ein-heitliche Darstellungsform zu generieren und die Ana-lyseergebnisse im ursprünglichen Modell auszuwerten.Es wurden strukturbasierte Transformationsvorschrif-ten für Message Sequence Charts entworfen, implemen-tiert und verifiziert.

Unabhängig davon wurde eine Erweiterung der Mes-sage Sequence Charts (MSC) zu Coloured Message Se-quence Charts (CMSC) konzipiert, implementiert undverifiziert. Analog zum Konzept der Gefärbten Petrinet-ze werden strukturähnliche Teilmodelle innerhalb einesMSC aufeinander gefaltet, wobei die einzelnen Instan-zen durch unterschiedliche Farben adressiert werdenkönnen [2]. Das führt zu einer Kompaktierung der Dar-stellung mit entsprechenden Vorteilen bei Übersichtlich-

31

keit und Darstellungsmächtigkeit. Die Verhaltensgleich-heit ist durch die Faltungsregeln gesichert. Auf demWeg über gefärbte Intervall-Petrinetze und deren Entfal-tung können die CMSC denselben Transformations- undAnalyseverfahren zugänglich gemacht werden wie die zu-vor genannten MSC (Abbildung 7).

col:ALL:grün

Object_1color: rot, blau, grün

Object_2color: rot, blau, grün

p12

p11

ro&bla&gr schw

schw

gr

grrovbla

ro,bla

p21

p22

t1 t21 t22

Abbildung 7. Gefärbter MSC und resultierendesgefärbtes Petrinetz

3.4. Implementierung im Zielsystem

In Kooperation mit anderen Forschungsprojekten wur-den Wege der Implementierung von Software aus denModellen in konkrete Targetsysteme untersucht. Da-bei wurden Mehrprozessorsysteme auf der Basis be-sonders schneller Digitaler Signalprozessoren angepeilt,welche die Bedienung der geschlossenen Regelkrei-se innerhalb der Mehrkoordinatenantriebe überneh-men sollen. Dabei war insbesondere die Erhaltung derMulti-Domain-Eigenschaften der Modelle mit ihrer Ver-bindung diskreter und kontinuierlicher Paradigmen vonBedeutung.

Aufgrund der Eigenheiten realer Zielsysteme ist die In-tegration in Echtzeitumgebungen mit Multitask-Echtzeit-Betriebssystemen notwendig. Diese Betriebssysteme bie-ten Funktionen zur Verwaltung von Konkurrenz, Prioritä-ten, zyklischen Abläufen und Nachrichtenaustausch. Füreine effektive Implementierung müssen diese Funktionenin zweckmäßiger Weise ausgenutzt werden. Insbesonderemuss die zuverlässige Aktivierung ratenmonotoner Funk-tionen aus quasikontinuierlichen Domänen innerhalb ihrerDeadline in Einklang gebracht werden mit den notwen-digen kurzen Reaktionszeiten ereignisdiskreter Prozesse.Die Schnittstellen beider Paradigmen bedürfen einer be-sonderen Behandlung, welche nicht im Widerspruch zuden im Modellierungsprozess verwendeten Prinzipien ste-hen darf.

In einer experimentellen Implementierung wur-de die automatische Generierung von Targetcode

aus Multi-Domain-Modellen erprobt. Als Infrastruk-tur beim Modellierungsvorgang wurde das WerkzeugML-Designer eingesetzt, welches auf den Grundprinzipi-en und Verfahren des bekannten ModellierungswerkzeugsPtolemy aufsetzt. Als Zielsystem wurde ein eingebette-tes System mit Digitalen Signalprozessoren verwendet,wobei eine Kooperation mit der gleichzeitig verlaufen-den Entwicklung eines problemangepassten Echtzeitbe-triebssystems stattfand.

4. Bezug zu industriellen Entwicklungen

Die Präzisierung der Aufgabenstellung und der tech-nologische Hintergrund wurden in Kooperation mit Pro-jekten zu Mehrkoordinatenantrieben und Mehrkoordina-tenpositioniermaschinen umgesetzt, die in der Fakultät fürMaschinenbau der TU Ilmenau (Prof. Kallenbach, Prof.Jäger) entwickelt und durch die innomas Innovative Ma-gnetsysteme GmbH Ilmenau und die SIOS MesstechnikGmbH Ilmenau realisiert werden. Die Erweiterung derHybriden Objektnetze um das Intervallkonzept einschließ-lich der Analysemethodik wurden in Zusammenarbeit mitDr. Drath (TU Ilmenau) realisiert und mit Hilfe des Werk-zeugs VisualObjectNet++ der ParamSoft Software Deve-lopment Ilmenau GbR implementiert und verifiziert.

Bei den Verfahren zur Transformation von MSC undCMSC in Hybride Objektnetze mit Zeitintervallen wurdeebenfalls auf das Werkzeug VisualObjectNet++ Bezug ge-nommen und Impulse für dessen Weiterentwicklung bei-gesteuert. Im Zusammenhang mit den Fragen zur Targe-timplementierung erfolgte eine intensive Auseinanderset-zung mit dem Werkzeug MLDesigner, welche zu Koope-rationen mit Prof. Salzwedel (TU Ilmenau) und der FirmaMission Level Design GmbH Ilmenau führte.

Literatur

[1] DURIDANOVA , VESSELKAund THORSTENHUMMEL : Mo-delling of Embedded Mechatronic Systems Using Hybrid Pe-tri Nets. In: IASTED International Conference on Modelling,Identification, and Control, 2001.

[2] FENGLER, OLGA, WOLFGANG FENGLER, VESSELKADU-RIDANOVA und BERND DAENE: Modeling of Complex Au-tomation Systems Using Colored Sequence Charts. In: Pro-ceedings of the 2002 IEEE International Conference on Ro-botics and Automation, 2002.

[3] FENGLER, WOLFGANG, BERND DAENE, VESSELKA DU-RIDANOVA und THOMAS L ICHT: Design Methodology foran Embedded System for High-Performance Computing. In:Real-Time Programming 2003, Proceedings of WRTP 2003,27th IFAC/IFIP/IEEE Workshop on Real-Time Program-ming, 2003.

[4] GUROVIC, DANIEL , WOLFGANG FENGLER und JUERGEN

NUETZEL: Development of Real-Time System Specificationsthrough the Refinement of Duration Interval Petri Nets. In:IEEE International Conference on Systems, Man and Cyber-netics, 2000.

[5] HUMMEL , THORSTENund WOLFGANG FENGLER: Designof Embedded Control Systems Using Hybrid Petri Nets. In:The International Workshop on Discrete-Event System De-sign DESDes’01, 2001.

32

Bewertung und Analyse hybrider Systeme

Wilhelm HeupkeTechnische Informatik (Prof. Dr. Klaus Waldschmidt)

Johann Wolfgang Goethe - Universität Frankfurt am Main

Zusammenfassung

Für eine erfolgreiche Implementierung von komplexenSystemen ist es wichtig, geeignete Realisierungen für dasgewünschte Verhalten zu wählen, die für den Zweck gut ge-nug sind, andererseits aber auch nicht unnötig aufwendigsind. In möglichst endlicher Zeit eine gute Wahl zu treffenist relativ schwierig und erfolgt üblicherweise sehr starkintuitionsgetrieben. Dass dies häufig zu erheblich subop-timalen Lösungen führt, kann man sich leicht denken undbestätigt sich auch oft bei genauerer Analyse von käuflicherhältlichen Geräten. Verfahren, die hier den Entwicklerunterstützen, sind das Ziel des Teilprojekts. Dazu wurdenstatische und dynamische Bewertungsverfahren realisiert.Mit Hilfe derartiger Bewertungsverfahren ist es möglich,bestimmte Realisierungsalternativen miteinander zu ver-gleichen und mit vertretbarem Zeitaufwand zu einer nahe-zu optimalen Lösung zu gelangen.

1. Problemstellung

Rechnersysteme haben heute in vielen Bereichen destäglichen Lebens Einzug gehalten. Typische Anwendungs-bereiche sind die Automobilelektronik, Multimedia, Te-lekommunikationsgeräte oder “Ambient Intelligence”. Indiesen Anwendungsbereichen bestehen die Systeme häu-fig aus mechanischen Komponenten, Sensoren, Aktoren,Leistungselektronik, analoger und digitaler Signalverar-beitung sowie umfangreichen Softwaresystemen. Damitergeben sich Gesamtsysteme, die außerordentlich kom-plex und heterogen sind und deren Komponenten wegenenger, funktionaler Abhängigkeiten nicht mehr alleine fürsich betrachtet werden können. Die Wechselwirkungen derKomponenten zu überschauen ist kaum möglich. WelcheEigenschaften besonders wichtig sind, ist oft nur aus Er-fahrung zu beurteilen.

Für den Entwickler ergibt sich beim Entwurf dieser Sy-steme vor allem ein Problem: Das gewünschte Verhal-ten des Systems lässt sich fast immer durch viele un-terschiedliche Architekturvarianten implementieren. Die-se Varianten haben allerdings in der Regel verschiedenenicht-funktionaleEigenschaften (z.B. Kosten, Geschwin-digkeit oder Leistungsaufnahme) und es ist nicht immervorher klar, ob diefunktionalenEigenschaften von einerprinzipiell brauchbar erscheinenden Implementierungsva-riante überhaupt erfüllt werden (z.B. keine Unterbrechung

der Klangwiedergabe bei einem MP3-Datenstrom, der voneinem Prozessor dekodiert wird). Bei der üblichen Her-angehensweise werden nach der Spezifikation grundsätz-licher Eigenschaften verschiedene Realisierungsvarianten,in der Regel auf Grund von Erfahrungen des Entwicklers,gegeneinander abgewogen und dann wird eine davon im-plementiert. Je komplexer das System ist, um so schwieri-ger ist es, Aussagen über das System vor der Implementie-rung zu treffen und um so teurer sind Fehlentscheidungen.Insbesondere sind die manuellen Lösungen des Optimie-rungsproblems oft weit entfernt von den Pareto-Punkten.Die Optimierung der Eigenschaften entscheidet aber oftüber den Markterfolg des zu entwerfenden Systems. DenEntwickler bei der Auswahl der besten Variante zu un-terstützen, ist daher ein wesentliches Ziel des Teilprojekts[5].

Spezifikation

Architektur 1Architektur 2

Architektur 3

Hw/Sw Codesign und/oderAnalog/Digital Co-design

Abbildung 1. Architekturbewertung

Eine wichtige Entscheidung ist, eine gegebene Funk-tion geeignet auf Hard- und Software zu verteilen. Ausder Erkenntnis heraus, dass man bei dieser Entscheidungdas Gesamtsystem betrachten muss, entstand das Kon-zept des Hardware/Software-Codesign. Aus einer entspre-chenden Überlegung heraus wurde auch die Methodik desAnalog/Digital-Codesigns geprägt, denn gerade in der Si-gnalverarbeitung ist es häufig möglich, die gleiche Funk-tion durch analoge Schaltungen oder mit Hilfe von Wand-lern und digitaler Elektronik zu realisieren. Man sollteaber auch im Auge behalten, dass viele Systeme nichtnur aus Elektronik, sondern auch aus mechanisch, optischoder chemisch arbeitenden Teilsystemen bestehen und so-mit auch als analoges Teilsystem modelliert werden kön-nen. Dies spielt bekanntermaßen bei den mikromechani-schen Systemen eine große Rolle.

Die im Folgenden beschriebenen Arbeiten bilden einenSchwerpunkt des Analog/Digital-Codesigns.

33

Analog/DigitalHW/SW

Co-Design

Systemplattform

IP-Abbildung

TechnologieAbbildung

Spezifikation

Synthese

Technologie -Abbildung

Syntheseplattform

-

Implementation

Abbildung 2. Entwurfsmethodik mitAnalog/Digital-Codesign

2. Statische Verfahren

Es wurden zwei Herangehensweisen betrachtet: Stati-sche und dynamische Verfahren. Beim statischen Ansatzwerden auf Basis von grundsätzlichem Wissen über be-stimmte typische Realisierungskonzepte Entscheidungenvor einer Implementierung getroffen. Dieser statische An-satz wurde für signalverarbeitende und für digitale Syste-me untersucht.

2.1. Analoge und hybride Systeme

Bei analogen und hybriden Schaltungen besteht häufigdie Möglichkeit eine Funktion in klassischer Analogelek-tronik oder die gleiche Funktionalität mit Hilfe digitalerSchaltungen/Prozessoren (und Wandlern) zu realisieren.Zur qualitativen Unterscheidung dieser Varianten wurdenMethoden zur Analyse des Entwurfsraumes gemischt ana-log/digitaler eingebetteter Systeme entwickelt. Zur Be-schreibung der Strukturen wurde das Modell der System-graphen im Rahmen des Projektes formuliert. Es wurdemit Hilfe dieser Systemgraphen eine Entwurfsraumerfor-schung auf der Basis von Simulated Annealing implemen-tiert.

Für die wesentlichen Schaltungen der analogen Signal-verarbeitung wurden Bewertungsmethoden entwickelt undals C++ - Klassenbibliothek realisiert. Die Bewertung er-folgte konstruktiv. Die konstruktive Methode hat den Vor-teil, dass man mit den gleichen Funktionen, die für die Er-mittlung der Schätzwerte verwendet werden, auch in ei-nem späteren Abschnitt des Entwurfs die Synthese deranalogen Schaltungen durchführen kann. Eine graphischeOberfläche erlaubt den schnellen und interaktiven Ver-gleich unterschiedlicher Implementierungsvarianten vonFiltern.

Bei gemischt analog/digitalen Systemen müssen, be-dingt durch die Eigenschaften der beiden Schaltungsklas-sen, zwei grundsätzlich verschiedene Schätzverfahrenin Betracht gezogen werden: Die konstruktive Schät-

zung analoger Schaltungsklassen und die heuristischeSchätzung, die bei digitalen Schaltwerken eingesetzt wer-den kann.

Bei analogen Schaltungen lassen sich funktionale undnicht-funktionale Eigenschaften nicht ohne weiteres von-einander trennen. Wenn man physikalische Parameter wiezum Beispiel die aktive Schaltungsfläche oder die Lei-stungsaufnahme ermitteln will, ist man gezwungen, denfunktionalen Anforderungen gemäß eine Schaltung auszu-wählen, und diese dann entsprechend zu dimensionieren.Konstruktive Schätzverfahren sind folglich Programmmo-dule, die sowohl eine Schätzung als auch eine Synthe-se für ihre jeweilige Schaltungsklasse durchführen. Mankann sie daher sowohl während der analytischen als auchwährend der Synthese-Phase des Entwurfsablaufes einset-zen.

2.2. Digitale Systeme

Parallel zu den Verfahren für signalverarbeitende Syste-me, wurden fürdigitaleSchaltungen Methoden zur schnel-len und genauen Bewertung der nicht-funktionalen Eigen-schaften der Realisierungen entwickelt [7].

Den konstruktiven Verfahren und ihrer Doppelfunkti-on stehen die heuristischen Verfahren gegenüber, die sicheinzig und allein zur Schätzung einsetzen lassen. Aus ei-ner VHDL-Beschreibung eines algorithmischen Verhal-tens wurden in einem Teilprojekt die beiden Komponen-ten Kontroll- und Datenpfad einer digitalen, sequentiel-len Schaltung extrahiert. Die Eigenschaften einer digitalenHardware, die diese Komponenten implementiert, wurdenin Anlehnung an die Verfahren der High-Level-Syntheseermittelt, indem die laufzeitlastigen Aspekte durch heuri-stische Verfahren abgekürzt wurden.

Zur Evaluierung der erarbeiteten Konzepte wur-de im Rahmen des Projektes ein prototypisches Werk-zeug erstellt. Dabei wurde eine objektorientierte Re-präsentation des Systemgraphen entwickelt und alsC++-Klassenbibliothek implementiert. Darauf aufbau-end entstand ein prototypisches Werkzeug mit graphischerOberfläche, das einen interaktiven Aufbau des Implemen-tierungsraumes ermöglicht.

Konfiguration- Modulauswahl-

Konfiguration- Modulauswahl- Ablaufplanung

Implementierung- Allokation-

Implementierung- Allokation- Bindung

Ope

ratio

nsw

erk

tclktclk

TT

Implementierungmit min.Verzögerungszeit

- Zustandscodierung-

Implementierungmit min.Verzögerungszeit

- Zustandscodierung- BewertungSt

euer

wer

k

Module

Verhaltensbeschreibung des Steuerwerks

TC

Bewertungder min.Verzöge-rungszeitdes

Bewertungder min.Verzöge-rungszeitdesSteuerwerks

Implementierungmit min. Fläche

- Zustandscodierung-

Implementierungmit min. Fläche

- Zustandscodierung- Bewertung

Implementierungmit min.Leistungsaufnahme

--

Implementierungmit min.Leistungsaufnahme

- Zustandscodierung- Bewertung

nichtfunktionale Eigenschaften

Sim

ulat

ed

Anne

alin

g

Abbildung 3. zeitbeschränkende Architekturbe-wertung

34

Auch für die Bewertung der Datenpfadkomponenten(Funktionseinheiten, Multiplexer und Register) wurde einkonstruktiver Ansatz gewählt. Dieser hat den Vorteil, dassdie nicht-funktionalen Eigenschaften der Komponentenmit einer sehr hohen Genauigkeit geschätzt werden kön-nen. Als Nachteil ist der Zeitaufwand für die Synthese derKomponenten zu nennen, der jedoch bei der Bewertungder Systeme vernachlässigt werden kann, weil die einma-lige Synthese der Komponentenvor der Systembewertungerfolgt.

Der Nachteil solcher statischer Verfahren ist, dasssie viele Detailschwierigkeiten nicht erkennen. Außer-dem muss das Werkzeug schon die Entwurfskonzepte ken-nen. Statische Verfahren sind daher nur sinnvoll, wennman große Bereiche des Entwurfsraums schnell durchsu-chen kann. Dies ist z.B. bei signalverarbeitenden Syste-men möglich.

3. Dynamische Verfahren

Zu den statischen Verfahren bilden die dynamischenBewertungsverfahren eine gute Alternative. Gemeint sinddamit Verfahren, die auf einer Simulation basieren. Eswird eine Realisierung modelliert, als Simulation imple-mentiert und ihr Verhalten untersucht. Der Vorteil ist, dasshier, ohne abstraktes Wissen über bestimmte Eigenschaf-ten, sehr detailliert untersucht werden kann, inwiefern diejeweilige Implementierung geeignet ist. Gerade Fragenwie z.B. Rauschen und Echtzeitverhalten oder die Wech-selwirkung der Soft- mit der Hardware sind auf diesemWeg deutlich besser handhabbar. Allerdings muss hierfürbereits eine Entscheidung für eine Implementierung ge-troffen werden um diese dann weiter zu untersuchen undanderen Implementierungen gegenüberzustellen.

Bekanntermaßen steht allerdings der Simulation beigrößeren Systemen in der Regel die benötigte Rechenzeitim Weg. Eine Simulation kann leicht, selbst für kleine Tei-le, Tage und Wochen an Rechenzeit beanspruchen. Manhilft sich daher häufig mit Makromodellen. Durch einegrößere Abstraktion beschränkt man sich auf die wesentli-chen Effekte. Erste Arbeiten an einer Schaltungsklasse [3],basierend auf dem weiter unten erwähnten SystemC, wa-ren recht vielversprechend. Es kam dabei mit zwei Indu-striefirmen der Region zu erfolgreichen Kooperationen.

Das Konzept solcher Makromodellierung ist bekanntund auch sinnvoll; allerdings muss man diese Makro-modelle erstellen, was fehlerträchtig und arbeitszeitinten-siv ist. Daher werden Verfahren untersucht, die Netzli-sten bestimmter gängiger Schaltungstypen partitionierenund automatisiert Makromodelle aus der jeweiligen Netz-liste erstellen. Als Demonstrator wird ein Programm im-plementiert, das mit dem Hintergrund erstellt wird, diebei Bremssystemen (s. Abb. 4) üblichen Teilfunktionen(Mess- und Regelsysteme) auf Bauelementeebene zu ana-lysieren (Programm BeCom) und Makromodelle zu erstel-len [6].

Abbildung 4. Anwendungsbeispiel: elektro-hydraulisches Bremssystem von Continental-Teves

3.1. SystemC-AMS

Ein pragmatischer Ansatz zur homogenen Modellie-rung und Simulation von Hardware/Software-Systemen istdie Verwendung von Programmiersprachen zur gemein-samen Spezifikation bzw. Modellierung von Soft-undHardware. Typische Vertreter dieses Ansatzes sind z.B.SpecC, OCAPI und SystemC. SystemC hat sich seit Ver-sion 2.0 zu einem de-facto Standard zur Modellierung vonHardware/Software-Systemen entwickelt. Version 3.0 er-weitert SystemC um Möglichkeiten zur Modellierung vonEigenschaften eines Betriebssystems.

SystemC wurde entworfen zur Spezifikation und Simu-lation beim Hardware/Software Co-Design, also dem ge-meinsamen Entwurf der Software zusammen mit der digi-talen Hardware. Ziel in diesem Projekt ist aber auch eineEntwurfsmethodik für Systeme mit Teilen analoger Elek-tronik (Analog/Digital-Codesign) und somit reicht dieseKlassenbibliothek nicht. Daher wurdeASC (Analog Sy-stemC)als eine Erweiterung der Klassenbibliothek Sy-stemC entwickelt. Mit dieser ist es möglich auf Syste-mebene sowohl analoge, als auch digitale Schaltungenund Software gemeinsam zu spezifizieren und somit Aus-wirkungen bestimmter Entwurfsentscheidungen (z.B. ge-wählte Bitbreiten) auf das Verhalten des Gesamtsystemsdurch Simulation zu bewerten. Mit der ASC-Bibliothekkonnte also das Analog/Digital-Codesign als dynamischesVerfahren in SystemC integriert werden.

Diese ASC-Bibliothek findet derzeit Eingang in dieStandardisierung von SystemC-AMS (einer Erweiterungvon SystemC zur Modellierung analoger Systeme). In Ab-bildung 5 sieht man den Aufbau der Erweiterung. Sie istin Schichten aufgeteilt. Es gibt eine gemeinsame Syn-chronisationsschicht. Darüber liegen Klassen für speziel-le Lösungsverfahren, so dass auch später Erweiterungenhinzugefügt werden können. Über diesen wiederrum sinddann noch verschiedene Sichten angeordnet um z.B. unter-schiedliche Eingabeformate für Beschreibungen von Teil-systemen handhaben zu können, falls sich mehrere mitdem gleichen Lösungsverfahren berechnen lassen. Dies er-

35

gibt einen recht flexiblen Ansatz, der es erlaubt, praktischalle üblichen Simulationsverfahren in das Konzept zu in-tegrieren [8].

Abbildung 5. lagenbasierter Aufbau vonSystemC-AMS

3.2. Ungenauigkeit in Schaltungen (parasi-täre Effekte)

Neben den auch aus der Welt der digitalen Hardwa-re bekannten Eigenschaften spezifiziert bei einer analogenSchaltung oft das Maß anToleranz, ob die Schaltung über-haupt den Anforderungen genügt. Daher wurde zur Be-wertung der Genauigkeit einer Implementierung ein Tole-ranzmodell auf Basis der affinen Arithmetik [1] erstellt. Eserlaubt verschiedene Arten von Störeinflüssen zu model-lieren und die Genauigkeit einer Implementierung zu be-urteilen. Die Implementierung basiert dabei auf der ASC-Klassenbibliothek.

tolerancesimplementation

m1:H1(s)

m2:H2(s)

m3:+I O

affineterms(I)

affineterms

+

affineterms

+

affineterms

+

Input Output

Abbildung 6. Regelschleife mit den spezifiziertenToleranzen als Blockdiagramm

Somit kann man durch Simulation von Schaltungen er-kennen, in welchem Maß sich die einzelnen spezifiziertenToleranzen auf bestimmte Ausgänge ausgewirkt haben [4].Alternative Realisierungsvarianten einer Schaltung kön-nen dadurch bezüglich ihrer Genauigkeit bewertet werden.Dieses Konzept wurde schließlich in einen Entwurfsablaufintegriert [2].

Die bisherigen Arbeiten sind auf lineare Schaltun-gen beschränkt. Zwar sind sie eine sehr bedeutende Schal-tungsklasse, aber gerade bei Nichtlinearitäten wird die

Toleranzanalyse schwierig. Daher werden in laufen-den Arbeiten Methoden untersucht, die es erlauben, dieentwickelten Konzepte der Modellierung von Toleran-zen auch auf einige Klassen nichtlinearer Schaltungenauszuweiten.

-10

0

10

20

30

40

50

60

70

80

0 1 2 3 4 5 6 7 8 9 10

offset error

control variable

manipulating variable

Abbildung 7. Simulation eines PI-Reglers mit To-leranzen (auf SystemC und ASC basierend)

Literatur

[1] A NDRADE, M.V.A., J.L.D. COMBA und J. STOLFI: Affi-ne Arithmetic (Extended Abstract). In: INTERVAL ’94, St.Petersburg, Russia, 1994.

[2] GRIMM , CHRISTOPH, WILHELM HEUPKE, CHRISTIAN

MEISE und KLAUS WALDSCHMIDT: Refinement of Mixed-Signal Systems with Affine Arithmetic. In: Design and Testin Europe 2004 (DATE ’04), Paris, France, 2004.

[3] GRIMM , CHRISTOPH, PETER OEHLER, CHRISTIAN MEI-SE, KLAUS WALDSCHMIDT und WOLFGANG FEY: Ana-logSL: A Library for Modeling Analog Power Drivers withC++ . In: Forum on Design Languages, Lyon, France, Sep-tember 2001.

[4] HEUPKE, WILHELM , CHRISTOPH GRIMM und KLAUS

WALDSCHMIDT: A New Method for Modeling and Analy-sis of Accuracy and Tolerances in Mixed-Signal Systems. In:Proceedings of the Forum on Design Languages (FDL’03),Frankfurt, Germany, September 2003.

[5] HEUSCHEN, FRANK und KLAUS WALDSCHMIDT: Ana-log/Digital Co-Design. In: Architecture and Design of Dis-tributed Embedded Systems. Kluwer Academic Publishers,2001.

[6] M EISE, CHRISTIAN und CHRISTOPH GRIMM : Konzept ei-ner Klassensammlung zur Verhaltensmodellierung hybri-der Systeme am Beispiel der Leistungselektronik. In:ITG/GI/GMM-Workshop Methoden und Beschreibungsspra-chen zur Modellierung und Verifikation von Schaltungen undSystemen, Bremen, Germany, März 2003.

[7] SCHMITT, HOLGER, MARKUS ELF und KLAUS WALD -SCHMIDT: Bewertung und Analyse hybrider Systeme. it+tiSonderheft: Entwurfsmethoden für eingebettete Systeme,2001.

[8] VACHOUX, ALAIN , CHRISTOPH GRIMM und KAR-STEN EINWICH: Analog and Mixed-Signal Modeling withSystemC-AMS (invited paper). In: International Symposionon Circuits and Systems 2003 (ISCAS ’03), Bangkok, Thai-land, 2003.

36

Simulationsbasierter Testentwurf analoger integrierter Systemkomponenten

Helmut Gräb, Michael Pronath, Volker GlöckelLehrstuhl für Entwurfsautomatisierung (Prof. Dr. K. Antreich)

Fakultät für Elektrotechnik und InformationstechnikTechnische Universität München

Zusammenfassung

Aufgrund von Produktionsschwankungen erfüllen nichtalle gefertigten Systeme die an sie gestellten Anforderun-gen. Deshalb muss im Anschluss an die Fertigung einTest durchgeführt werden, um fehlerhafte Teile vor ih-rer Auslieferung zu identifizieren und auszusortieren. Indiesem Projekt wurden Verfahren erforscht, um solcheTests für analoge Systemkomponenten zu entwerfen. Aus-gangspunkt war dabei die Simulierbarkeit des Problemsam Rechner, um bereits zu einem frühen Zeitpunkt desSystementwurfs den Test vorbereiten zu können. Als Er-gebnis liegen Verfahren für den praktischen Einsatz be-reit, die den besonderen Anforderungen beim Test analo-ger Komponenten genügen. Insbesondere können nun fürschwer zugängliche Schaltungen geeignete Testmessungenzum Einsatz kommen, die einen zuverlässigen Schluss aufdie Funktionstüchtigkeit erlauben.

1. Aufgabenstellung

Eingebettete Systeme weisen eine besonders aus-geprägte Heterogenität aus Hardware- und Software-Anteilen einerseits und Analog- und Digitalkomponentenandererseits auf. Analoge Hardware-Komponenten ha-ben dabei einen Systemanteil von 20% bis über 50%bezogen auf die Chipfläche (Abb. 1).

Analoge Komponenten erfüllen wesentliche System-funktionen wie z.B. Takterzeugung oder Signalwandlungzwischen analoger Systemumgebung und digitaler Signal-verarbeitung und sind deshalb ein nicht wegzudenkenderBestandteil jedes Systems. Im Zuge ihrer großen Varian-tenvielfalt und komplexer physikalischer Randbedingun-gen ist der Entwurf analoger Schaltungen eine nur schwerautomatisierbare Aufgabe. Analogentwurf findet deshalbnach wie vor ohne eine dem Digitalentwurf vergleichbareUnterstützung durch EDA-Werkzeuge statt. Der Entwurfanaloger Systemkomponenten beansprucht so einen be-deutenden Teil des Entwurfsaufwandes eines Systems undbildet oft sogar den Flaschenhals. Eine besonders heraus-ragende Rolle in dieser Hinsicht nimmt der Testentwurfbzw. der Test der analogen Komponenten ein, der einenbedeutenden Kostenfaktor in der Produktion bildet. Die-se Problematik verschärft sich mit zunehmender System-

analoges System

20% der Fläche

80% der Kosten

GSM Basisba

Infineon Technol

Abbildung 1. Layoutskizze des GSM-Basisband-Chips von Infineon Technologies im SiemensS45 Handy. Die analogen Komponenten sind um-randet. Hinter diesem Chip verbergen sich Mil-lionen von Transistoren, deren strukturelle Ver-knüpfung, Plazierung und Verdrahtung zu ent-werfen sind. Dies ist vergleichbar mit der Pla-nung einer Stadt mitsamt Versorgungs- und Ent-sorgungstechnik und soll in wenigen Monatenbewerkstelligt werden!

faulty

goodgood

faulty

recycle / repair / relabel

goodfaulty

reject

accept

Test

customer

Production

Abbildung 2. Ausgangssituation beim Test: Feh-lerhafte Bauteile aus der Produktion werden imTest detektiert und aussortiert. Dabei kommt eszu Fehlentscheidungen, so dass ungewollt so-wohl fehlerhafte Schaltungen zum Kunden gelan-gen, als auch fehlerfreie Schaltungen aussortiertwerden. Ziel des Testentwurfs ist es, die erwar-tete Zahl von Fehlentscheidungen so klein wiemöglich zu halten.

komplexität, also gerade bei eingebetteten Systemen, im-mer mehr.

Die Ausgangssituation beim Test stellt sich wie in

37

Abbildung 3. Analog-Filter als Beispiel eines de-vice under test (DUT). Beim funktionalen Testwird man die Betriebseigenschaften, anhand de-rer diese Schaltung entworfen wurde, überprü-fen, hier z.B. Mittenfrequenz und Güte.

Abb. 2 dar. Grundsätzlich handelt es sich beim Test umein Klassifikationsproblem mit spezifischen Randbedin-gungen.

Beim Test von analogen Komponenten wird man zu-nächst auf eine Messung der für den Entwurf spezifizier-ten Betriebseigenschaften abzielen (Abb. 3). Wegen ihrerEinbettung in eine digitale Chip-Umgebung ist es jedochin den meisten Fällen nicht möglich, diese Betriebseigen-schaften in einem sogenannten funktionalen Test direkt zumessen (Abb. 4).

Zum einen sind die dafür erforderlichen Pins von au-ßen häufig nicht zugänglich, zum anderen können die fürdie Messung notwendigen Lasten und Eingangssignale nursystemintern eingestellt werden. Überdies reagieren dieBetriebseigenschaften so unempfindlich wie möglich aufProduktionsschwankungen, was wunschgemäß einer ho-hen Produktionsausbeute entspricht. Im Test werden aberMessungen benötigt, die ganz im Gegenteil sehr empfind-lich auf Produktionsschwankungen reagieren, um die De-tektion fehlerhafter Bauteile zu erleichtern.

Aus diesen Gründen besteht die grundsätzliche Auf-gabe eines Analogtestentwurfs darin, erstens geeigne-te Testmessungen auszuwählen und zweitens auf diesenTestmessungen aufbauend einen sogenannten implizi-ten Test zu entwerfen, mit dem der funktionale Testnachgebildet werden kann. Dieses Projekt hat sich da-bei vor allem folgenden Teilaufgaben gewidmet:• dem Entwurf eines geeigneten Fehlermodells, das lo-kale und globale, katastrophische und parametrische Po-zessdefekte berücksichtigt,• dem Entwurf von geeigneten Mixed-Signal-Teststrategien für implizite Testmessungen,• der Erforschung von deterministischen und sto-chastischen Testentwurfsverfahren für Go/No-Go-Entscheidungskriterien eines impliziten Tests unterBerücksichtigung von Variationen in Messungen und Ein-gangssignalen.

In diesem Projekt wurden dabei Verfahren zum Testent-wurf angestrebt, die auf einer Simulation des Herstellungs-prozesses mittels sogenannter Monte-Carlo-Analysen be-ruhen. Dies ist deshalb eine besonders schwierige Aufga-be, weil wegen der extrem hohen Simulationszeiten nurein sehr beschränkter Stichprobenumfang angesetzt wer-den kann.

A D AAnalogAnalog Digital

Testumgebung

Abbildung 4. Die Einbettung einer analogenKomponente in die digitale Chip-Umgebung er-schwert ihren funktionalen Test.

2. Ausgangssituation bei Projektbeginn

Auch wegen der besonderen ökonomischen Bedeutungdes Tests in der Produktion gibt es weltweit zahlreiche Ak-tivitäten zum Testentwurf sowohl für digitale als auch füranaloge Komponenten. Im Bereich digitaler Schaltungenhat sich das Ständigfehlermodell als Basismodell für denTest etabliert. Für jedes Signal einer Schaltung wird da-bei angenommen, das es im Fehlerfall ständig eines derdiskreten Signalwerte (z.B. “1” oder “0”) aufweist. BeimTestentwurf wird dann mit Verfahren der Fehlersimulati-on und der diskreten Optimimierung auf Logikebene ei-ne Minimalmenge von an den Chip-Eingang anzulegen-den Signalmustern ermittelt, mit der alle möglichen Stän-digfehler am Chip-Ausgang sichtbar werden.

Im Analogbereich werden solche Ständigfehler auchkatastrophisch genannt, weil sie meist zu einem Total-ausfall des Systems führen. Die beim Analogtest zu be-trachtenden katastrophischen Fehler sind komplexer, sieumfassen z.B. Unterbrechungen und Kurzschlüsse bei Si-gnalen und Grundbauelementen analoger Schaltungen,den Transistoren. Beim Analogtest muss man sich zu-nächst damit beschäftigen, katastrophische Fehlertypenund -häufigkeiten layoutbezogen zu analysieren und ih-re Simulierbarkeit auf Transistorebene herzustellen. Danngeht es darum, mittels Fehlersimulation die Erkenn-barkeit von Fehlern für verschiedene Teststrategien zuanalysieren und darauf aufbauend einen Test zu entwer-fen.

Bei analogen Schaltungen sind über katastrophischeFehler hinaus sogenannte parametrische Fehler von Be-deutung. Sie sind auf globale und lokale Prozessschwan-kungen zurückzuführen, äußern sich in kontinuierlichenVerteilungen von Transistorparametern und führen nichtzwangsläufig sondern mit einer gewissen Wahrscheinlich-keit zu Ausfällen. Diese Fehler sind anerkanntermaßenschwieriger zu detektieren und stellen hohe Anforderun-gen an den Testentwurf, gewinnen aber in der Praxismehr und mehr an Bedeutung. Parametrische Fehler lie-gen dann vor, wenn die stochastischen Abweichungen imHerstellungsprozess zu einer Verletzung von Grenzwertenin spezifizierten Schaltungseigenschaften führen. Ein so-genannter funktionaler Test zielt dann auf die Erkennbar-

38

keit von Grenzwertüberschreitungen in der spezifiziertenSchaltungsfunktion ab.

Zu Projektbeginn existierten Untersuchungen über dieEignung verschiedener Teststrategien für den implizitenTest sowie Verfahren der Diskriminanzanalyse zur Lösungdes Klassifikationsproblems. Diese Verfahren waren nochnicht in der Lage, Klassifikatoren mit einer für den prak-tischen Einsatz erforderlichen Güte hinsichtlich der Fehl-klassifikationen zu entwerfen.


In diesem Projekt wurden in den folgenden drei Be-reichen des Testentwurfes für analoge Komponenten wis-senschaftliche Fortschritte erzielt, die zu einer Verbesse-rung der Testentwurfsqualität und -effizienz von integrier-ten Hardwarekomponenten (“Chips”) eingebetteter Syste-me führen.

3.1. Fehlermodell

Es wurde ein Fehlermodell entwickelt, dass auf Pro-zessschwankungen beruht, die als statistische Verteilun-gen auf Transistorebene modelliert werden und mit einergewissen Wahrscheinlichkeit zu einer Verletzung von spe-zifizierten Grenzwerten führen (parametrische Fehler).Dieses parametrische Fehlermodell führt zunächst zu ei-ner sehr schwer zu lösenden Aufgabe, die hohe Anforde-rungen an die zu entwickelnden Lösungsverfahren stellt.Dafür werden aber die leichter zu detektierenden ka-tastrophischen Fehler weitgehend mit erfasst. Zum an-deren kann mit diesem parametrischen Fehlermodellbei den beim Schaltungsentwurf eingesetzten Optimie-rungsverfahren angesetzt werden, was Testentwurfsver-fahren ermöglicht hat, die die erforderliche besondershohe Ergebnisqualität erbringen. Darüber hinaus konn-te so zur Schließung einer Lücke im Entwurfsablaufzwischen Schaltungsentwurf und Testentwurf beigetra-gen werden.

3.2. Mixed-Signal-Teststrategien

Bei analogen Komponenten in Mixed-Signal-Systemenaus digitalen und analogen Komponenten ist anstelle desfunktionalen Tests meist nur ein impliziter Test möglich,beim dem auf die Funktion rückgeschlossen wird. Poten-tiell geeignete Testmessungen eines impliziten Tests müs-sen leicht und schnell durchführbar sein, empfindlich aufdie zu detektierenden parametrischen Prozessschwankun-gen reagieren und unempfindlich gegenüber den unver-meidlichen Streuungen bei Teststimuli und Messwertensein. In diesem Projekt wurden folgende Teststrategienentwickelt und zur Validierung der erforschten Testent-wurfsverfahren verwendet:• DC- und AC-Messungen (schnell im Sinne der Schal-tungssimulation),• Nutzung der Power-Down-Ansteuerung (z.B. Abb. 5oben, wird im Betrieb zum Abschalten eines Schaltungs-teils zur Leistungseinsparung verwendet und im Test zur

Abbildung 5. Testansteuerung einer analogenKomponente mittels der Power-Down-Schaltung(oben) oder mittels digitaler Eingangsstimuli (un-ten).

Einstellung eines empfindlichen Zwischenzustands),• Versorgungsstrom-Messungen (werden auch beim Testdigitaler Komponenten eingesetzt),• digitale Eingangsstimuli (z.B. Abb. 5 unten, können voneinfachen Testgeräten oder auf dem Chip selbst erzeugtwerden),• diskrete Abtastung transienter Ausgangssignale und an-schließende Signaltransformation (z.B. Fourier, Wavelet).

3.3. Testentwurfsverfahren

Es wurden stochastische und deterministische Lö-sungsverfahren zum Entwurf eines impliziten Testserforscht, bei dem von Testmessungen auf die Funktions-tüchtigkeit, d.h. die Einhaltung verschiedener Grenzwertevon Betriebseigenschaften, rückgeschlossen wird. Der im-plizite Testentwurf beinhaltet also die Lösung einesKlassifikationsproblems (Schaltung fehlerfrei, Schal-tung fehlerhaft) mit dem Ziel, Auswertevorschriften fürTestmessungen bereitzustellen, mit denen im Idealfall ge-nau dann eine Schaltung als fehlerhaft klassifiziert wird,wenn Betriebseigenschaften ihre spezifizierten Grenzwer-te verletzen würden.

In diesem Projekt wurden im Sinne einer Problem-partitionierung die einzelnen Grenzwerte der Betriebsei-genschaften getrennt betrachtet. Dabei wurde jeweils einGrenzwert nicht mit einer einzelnen Testmessung, son-dern durch eine Kombination von Testmessungen in ei-ner sogenannten Testeigenschaft nachgebildet. Diese Test-eigenschaft ist zwar nicht mehr technisch interpretierbar,ermöglicht aber über den Stand der Technik hinaus erst-mals eine gute Nachbildung einer Betriebseigenschaft. Ei-ne Testeigenschaft aus einer linearen Kombination vonTestmessungen hat sich als besonders vorteilhaft heraus-gestellt. Damit muss für jeden einzelnen Grenzwert einerBetriebseigenschaft jeweils ein Satz von Linearkombina-tionskoeffizienten und ein Grenzwert der Testeigenschaftermittelt werden.

Die entwickelten und untersuchten Lösungsverfahren

39

Abbildung 6. Fehlerdurchlässigkeit (fehlerhafteSchaltungen, die fälschlicherweise als fehlerfreiangenommen wurden) bei 1% Ausbeuteeinbu-ße (fehlerfreie Schaltungen, die fälschlicherwei-se abgelehnt wurden)

waren:• klassische Diskriminanzanalyse nach Fisher,• logistische Diskriminanzanalyse,• allgemeines stochastisches Verfahren mittels nichtlinea-rer Optimierung, beruhend auf Minimierung der konku-rierrenden Häufigkeiten von Fehlklassifikationen durchAnnahme einer fehlerhaften Schaltung bzw. Ablehnungeiner fehlerfreien Schaltung,• deterministisches Verfahren beruhend auf Ergebnissendes Schaltungsentwurfs.

Ein typisches Ergebnis des Vergleichs zwischen denVerfahren 1, 2 und 3 ist in Abb. 6 zu sehen. Man sieht,dass es mit den Ergebnissen des Projektes erstmals mög-lich ist, implizite Testentwürfe mit akzeptablen Fehlklas-sifikationsraten zu erzielen. Das entwickelte deterministi-sche Verfahren erreicht den beiden Diskriminanzanalyse-verfahren vergleichbare Ergebnisse bei wesentlich nied-rigeren Testentwurfszeiten und eignet sich vor allem zurVorbereitung des Testentwurfs z.B. bei der Auswahl vonTestmessungen.

Um trotz der eingangs erläuterten Notwendigkeit einesbeschränkten Stichprobenumfangs diese Ergebnisqualitätzu erzielen, mussten Fortschritte in den drei folgenden we-sentlichen Bereichen stochastischer Schätzung erzielt wer-den: Berücksichtigung von Messfehlern bei der Schätzungvon Ausbeuteeinbuße und Fehlerdurchlässigkeit, Stich-probengenerierung mit überlagerten Verteilung, sowie Be-rücksichtigung von Häufigkeitsverteilung der Schaltungs-klassen bzw. der Stichprobengenerierung.

Darüber hinaus haben die Forschungsarbeiten zu neu-en Verfahren zur Pareto-Optimierung der konkurrierendenMinimierziele Fehlerdurchlässigkeit und Ausbeute-einbuße unter Berücksichtigung von Messfehlern undStimuli-Fehlern geführt, und es sind Fehlermodelle undTestentwurfsverfahren für sogenannte Open-Gate-Fehlerentwickelt worden.

Die Ergebnisse sind detailliert in einer Reihe von inter-nationalen Veröffentlichungen niedergelegt (siehe unten).

4. Praktische ErgebnisseDie Forschungsarbeiten sind in enger Zusammenarbeit

mit den Firmen Motorola und Infineon durchgeführt wor-den. In einem Forschungsaufenthalt bei Motorola wurdenpraktische Beiträge zur Modellierung von Testproblemenfür einen simulationsbasierten Testentwurf geleistet. MitInfineon wurden Demonstratoren und Ergebnisse ausge-tauscht und diskutiert. Obwohl die Projektarbeiten auf dieVerbesserung von Grundlagen als Vorbereitung auf einenzukünftigen praktischen Einsatz abzielten, sind die Fort-schritte in Richtung industrieller Verwertung weiter ge-diehen als erwartet. Zum einen zeichnet sich ein Einsatzauf dem Gebiet desbuilt-in self test(BIST) ab. Hier kön-nen die entwickelten Verfahren dazu dienen, die Testquali-tät zu analysieren, die mit den direkt in ein System einge-bauten Testschaltungen erzielt werden kann. Zum anderensind die entwickelten Verfahren zu einer aus dem Lehr-stuhl ausgegründeten CAD-Firma transferiert worden, dienun auch die an diesem Projekt beteiligten Mitarbeiter be-schäftigt, und können für den industriellen Einsatz schnellverfügbar gemacht werden.

5. Zusammenfassung und AusblickIn diesem Projekt sind in enger Zusammenarbeit mit

industriellen Partnern ausgefeilte Verfahren für die beson-ders schwierige Aufgabe des impliziten Testentwurfs füranaloge integrierte Schaltungen erforscht und entwickeltworden, die nun für den praktischen Einsatz bereit stehen.Vor einem breiten industriellen Einsatz sind seitens der In-dustrie weitere Fortschritte bei der Erstellung von Simula-tionsmodellen für den Testentwurf (virtual test) erforder-lich. Zukünftige Forschungsarbeiten beschäftigen sich mitder Aufgabe, Verfahren zum Testentwurf zu erforschen,die bei praktikablen Simulationskosten Fehlerraten im Be-reich weniger Teile pro Milliarde behandeln können.

Literatur[1] GLÖCKEL, V., M. PRONATH und H. GRÄB: Determini-

stischer parametrischer Testentwurf für analoge integrierteSchaltungen mit Testbeobachtungen unter Anwendung vonErgebnissen aus dem Toleranzentwurf. In: ITG/GMM/GITestmethoden und Zuverlässigkeit von Schaltungen und Sy-stemen, Seiten 5.2.1–4, Februar 2001.

[2] L INDERMEIR, W., H. GRÄB, and K. ANTREICH: Analogtesting by characteristic observation inference. IEEE Trans.on Computer-Aided Design of Integrated Circuits and Sys-tems (CAD), 18(9):1353–1368, September 1999.

[3] PRONATH, M., V. GLÖCKEL, and H. GRÄB: A para-metric test method for analog components in integratedmixed-signal circuits. In IEEE International Conference onComputer-Aided Design (ICCAD), pages 575–561, 2000.

[4] PRONATH, M., H. GRÄB, and K. ANTREICH: A test designmethod for floating gate defects (FGD) in analog integratedcircuits. In Design, Automation, and Test in Europe Confer-ence (DATE), 2002.

[5] PRONATH, M., H. GRÄB, and K. ANTREICH: On paramet-ric test design for analog integrated circuits considering er-ror in measurement and stimulus. In Modeling, Simulationand Optimization of Integrated Circuits, volume 146 ofIn-ternational Series of Numerical Mathematics, pages 283–301. Birkhäuser Verlag, 2003.

40

Template-basierte Entwicklung von eingebetteten Systemen

Benito Liccardi, Thomas Maier-KomorLehrstuhl für Realzeit-Computersysteme (Prof. Dr. G. Färber)

Technische Universität München

Zusammenfassung

Der Entwurf von eingebetteten Systemen mit ei-nem Produktionsvolumen mittlerer Stückzahl umfasst inDeutschland einen sehr großen Markt, der internatio-nal steigendem Wettbewerb ausgesetzt ist. Die hier be-schriebenen Arbeiten beschäftigen sich mit der Frage, wiedas enorme Optimierungspotenzial, das in der Entwurfs-phase dieser Systeme steckt, genutzt werden kann. Dazuwurde ein Meta-Modell basierendes Framework ent-wickelt, dass insbesondere die Explorationsphase miteiner strukturierten und differenzierten Methodik unter-stützt.

1. Ausgangssituation

Der Entwurf von eingebetteten Systemen mit einemProduktionsvolumen mittlerer Stückzahl (ca. 100 - 10000Einheiten) hat besondere Anforderungen an den Entwick-lungsprozess, die von den meisten Werkzeugen nicht imerforderlichen Maße berücksichtigt werden. Die gängigenCASE-Tools unterstützen insbesondere den Entwurf vonSystemen mit kleiner Stückzahl. Jedoch könnten insbe-sondere mittelständische Unternehmen von einer Metho-dik profitieren, die diese Rahmenbedingungen verbessert.

Das Kernproblem besteht darin, dass sich keine kla-ren, allgemeingültigen Optimierungsziele formulieren las-sen, da sich die Gesamtkosten von Entwicklung und Fer-tigung applikationsspezifisch unterschiedlich verteilen. Somacht es beispielsweise wenig Sinn, die Stückkosten fürjedes Bauteil durch einen langwierigen Preisvergleich ins-gesamt zu reduzieren, da der Aufwand hierfür auch be-zahlt werden muss und die dabei entstehenden Kostenschnell den Nutzen übersteigen.

Ebenso verhält es sich mit den komplexen Optimie-rungsbedingungen für Design und Implementierung vonHard- und Software, da die Kosten der Ingenieursstundender hierfür erforderlichen Spezialisten sich häufig wirt-schaftlich nicht rechnen. Dies hat zur Folge, dass einGroßteil des Optimierungspotenzials bei solchen Syste-men ungenutzt bleibt und nur solche Unternehmen kon-kurenzfähig sind, die über Mitarbeiter mit vieljähriger Er-fahrung verfügen. Denn diese bringen das erforderlicheWissen mit, das insbesondere in der frühen Phase der Ent-wurfsraumexploration zum Tragen kommt. Dabei kommtes unter anderem darauf an, Abhängigkeiten und Konflik-

te zwischen Rand- und Vorbedingungen und eingesetztenKomponenten zu erkennen.

Fehler, die in der ersten Projektphase gemacht werden,sind in den Folgen am schwerwiegendsten und erzeugendamit auch die höchsten Kosten. Deshalb wurde im Rah-men des Projekts ATLAS eine Methodik erarbeitet, dieden Entwicklern ein Hilfsmittel in Form eines Werkzeugesan die Hand gibt, das es erlaubt, Detailwissen schnell undeffizient zu erlangen, ihnen Vergleichsmöglichkeiten zwi-schen verschiedenen Szenarien bietet und dabei bekann-te Rand- und Vorbedingungen berücksichtigt. Insbesonde-re sollte der für dieses Umfeld so wichtige Wiedereinsatzvorangegangener Entwicklungen und Kommunikation undInformationshaltung in den Projekten verbessert werden,damit der Verlust eines Know-How-Trägers nicht mit demVerlust der zugehörigen Projekterfahrung einhergeht.

2. Methodik

Die für diese Ziele erarbeitete Methodik stellt eineInfrastruktur bereit, die Unternehmensgrenzen durch dieNutzung von etablierten Internettechniken überschreitenkann. Die Verwendung eines Meta-Modells liefert im Kerndieser Infrastruktur eine Abstraktionsebene, die generischgenug ist, um auf der einen Seite Interaktion beliebigerKomponenten zu ermöglichen und auf der anderen Seitespezialisierbar ist und damit Operationen erlaubt, die De-tailwissen erfordern.

Abbildung 1. Beteiligte Parteien

Dieser Ansatz berücksichtigt darüber hinaus die unter-schiedlichen Anforderungen der am Entwurfsfluss betei-ligten Parteien (siehe Abb. 1, beschrieben in [1]). Diesmacht sich insbesondere dadurch bemerkbar, dass der je-

41

weiligen Person nur die Informationen dargestellt werden,die für sie von Bedeutung und für die jeweilige Aufga-be nötig sind. Das Datenvolumen auf das Wesentliche zureduzieren, verkürzt die Einarbeitungszeit und Suche, dadie von Menschen zu verarbeitendende Information vonmehreren hundert Seiten Text auf wenige Seiten zusam-menschmilzt. Die Form der Darstellung kann hierbei einzusätzliches Hilfsmittel sein, da durch spezialisierte For-matierungen eine einfachere Verarbeitung erzielt werdenkann.

ENTITY

Vendor : StringID : StringXML_URI : StringName : String

entity_contains_entity

entity_requires_entity and

xor

SERVICE

XML_URI : StringCommittee : StringXSD_URI : StringName : String

xor

binds

entity_requires_serviceentity_provides_service

contains

and

Abbildung 2. AM3 Metamodell

Das Konzept für die Implementierung [2] besteht ausdem Meta-Modell AM3 (siehe Abb. 2), das abstrakt be-schreibt, was für Informationen jede Komponenten-beschreibung mitbringen muss, um verwaltet werdenzu können. Dabei beschreibenEntity Klassen abstrak-te Einheiten mit definierten strukturellen Eigenschaften.Service Klassen hingegen kapseln Verhaltensbeschrei-bungen, die durch einfache aber semantisch eindeutigeAssozationen in Relation zu denEntity Klassen ge-bracht werden.

Die eigentliche Verwaltungsarbeit wird von einem Fra-mework durchgeführt, das auf der Meta-Object Facilityder Object Management Group basiert und die Relationenzwischen einzelnen Komponenten auf der Basis der hin-terlagerten Modelle verarbeiten kann. Die Modelle der inder Datenbasis gespeicherten Komponenten sind wieder-um durch eine zweigeteilte Verarbeitungsform beschrie-ben.

Einerseits werden Freiheitsgrade von einer einzelnenKlasse gewisser Bauteile, die für ein Systemdesign geeig-net sind, durch ihre Freiheitsgrade mit Hilfe von XML-Schemata beschrieben. XML-Schemata und ihre Datenre-presentation in XML alleine ermöglichen lediglich die Da-tenhaltung, nicht aber eine Informationsverarbeitung auf

der Basis eines semantischen Modells, das einer jeden sol-chen Komponente zugrunde liegt. Deshalb ist jedes Sche-ma über eine auf JAXB basierende Java-Implementierungeng an ein Modell des Verhaltens und der Freiheitsgradeder realen Komponente gekoppelt.

Diese mehrstufige Aufteilung von Eigenschaften er-möglicht zum einen eine feingranulare Suche optimal ge-eigneter Komponenten, wie sie zuvor nicht möglich war.Zum anderen können durch die modellbasierte Verarbei-tung Fehler in den frühen Phasen des Entwicklungspro-zess erkannt und somit Kosten gesenkt und die Time-To-Market reduziert werden.

KundePflichtenheft

erzeugt

Ingenieur

Reuse Anforderungen

Lastenheft

erstellt

System Anforderungen

Einsetzbare Komponenten AbhängigkeitenATLAS

schlägt vor zeigt

initialisiert

Ausgewählte Komponenten

verarbeitet

System Entwickler

liest

leitet ab

interagiert

bestimmt

Erfahrung

Abbildung 3. AM3 Entwurfsfluss

Darüber hinaus kann durch dieses Konzept nicht nur In-formation über neue Produkte schneller aquiriert werden,sondern es ist dem Systemdesigner auch möglich, Rand-bedingungen, die das Design betreffen, als Daten in dasFramework fließen zu lassen. Diese Daten (z.B. verfüg-bares Entwickler Know-How, Mindestanforderungen fürVerträglichkeiten von Umwelteinflüssen, langfristige Lie-fergarantien) können genutzt werden, um den Entwurfs-raum zu begrenzen und basierend auf dem Hintergrund desProjekts anhand von Projektparametern in einem iterativenProzess zu optimieren (siehe Abb. 3).

Hersteller von Produkten können davon profitieren, in-dem sie potenziellen Kunden ihre Produkte in einem in-tegrierenden Kontext anbieten. Insbesondere können Inte-grationspotenziale mit anderen Produkten, besondere Vor-teile gegenüber Mitbewerbern und andere schwer erkenn-bare Eigenschaften kommuniziert werden. Die Kundengewinnen neben den Vorteilen durch die Verbesserungenfür das Systemdesign die Möglichkeit dazu, Produkte aufeiner selbst wählbaren Basis zu vergleichen und zu profi-lieren.

42

3. Anwendung

Das in dem Forschungsvorhaben entstandene AM3Framework begleitet denState–of–the–PracticeEnt-wurfsprozess während nahezu aller Phasen des Ent-wurfes. Die strukturierten, maschinenverarbeitbarenund semantisch eindeutigen Architektur–Templates die-nen sowohl bei derSystem Spezifikationals auch spä-ter beim modellbasierten Entwerfen der Applikation alsanwendbares Applikationswissen. Selbst bei nahezu fer-tig entwickelten Systemen können mögliche Variantenund deren Migrationsaufwand auf verschiedene Opti-mierungskriterien exploriert werden. Jedes erstellte underprobte Teilsystem kann wiederum mit dem AM3 Fra-mework spezifiziert und somit für zukünftige Projektezur Verfügung gestellt werden. Abbildung 4 zeigt die An-bindung des AM3 Frameworks an denTOP–DOWNEntwurfsprozess und die Interaktion in den verschiede-nen Phasen.

Abbildung 4. AM3 Entwurfsflussanbindung

Die AM3 Methodik wurde an einem bereits existie-renden eingebetteten System für die Medizintechnik eva-luiert. Die in den frühen Phasen relevante Informationzur Architekturexploration, wie beispielsweise eine effi-ziente Anbindung mehrerer Analog Digital Wandler aneinen DSP mit notwendigen Software Routinen und Com-pilerversion, konnte mit denArchitektur–Templatesbe-schrieben werden. Die Ergebnisse haben gezeigt, dass ei-ne strukturierte und semantisch eindeutige Beschreibungmöglich ist. Die Exploration verschiedener Architekturva-rianten in Bezug auf mehrere Auswahlkriterien war werk-zeuggestützt in sehr kurzer Zeit möglich. Voraussetzungist zum einen das Vorhandensein von semantisch eindeu-tigen und standardisierten Servicebeschreibungsvorschrif-ten und zum anderen die Beschreibung derArchitektur–Templatesauf Basis des AM3 Metamodells.

4. Werkzeug-Integration

Die enge Integration der verwendeten Entwicklungs-werkzeuge untereinander und ein abgeschlossener Infor-mationsfluss zurück in die Tools ist ein entscheidender

Vorteil für den Entwurf, da hierdurch der Zeitaufwanddeutlich reduziert werden kann. Jedoch treten bei der dafürerforderlichen Kopplung einzelner CASE-Tools, insbe-sondere bei der Wiederverwendung von Ergebnissen vor-angegangener Projekte, erhebliche Schwierigkeiten auf,was die Einbindung von automatisch generiertem Codeund die Auflösung der sich daraus ergebenden Abhängig-keiten betrifft.

Der Grund hierfür ist, dass es keine Norm und keinenStandard gibt, die einen allgemeinen Datenaustausch zwi-schen verschiedenen Entwicklungswerkzeugen ermögli-chen. Deshalb wurde in diesem Projekt eine Methodik ent-wickelt, die auf der ATLAS Meta Modell Methodik auf-setzt und eine vereinfachte Integration von automatischgeniertem Quelltext und von Hand erstelltem Legacy-Code in neue Projekte zur Verfügung stellt.

Abbildung 5. Toolintegration in ATLAS

Die ALIS-Toolkette [5] läßt sich nahtlos in einenCASE-Tool basierten Entwurfsfluss einbinden (sie-he Abb. 5). Dabei wird die Programmiersprache C alszentrale Integrationsstelle beim Entwurf der Softwa-re benutzt, da die meisten Werkzeuge sie als Zielspra-che anbieten und es für sie für nahezu jede Architektureinen Compiler gibt. Aus dem automatisch generier-tem Quelltext werden verschiedene Informationen ge-wonnen, die für eine Integration von Softwaremodulenerforderlich sind. Dazu gehören auch jene Eigenschaf-ten der Software, über die der Entwickler informiertsein muss, die das Systemverhalten grundlegend be-einflussen können. So ist es beispielsweise nicht mög-lich, beliebigen Source-Code für die Steuerung undRegelung von mechatronischen Systemen zu verwen-den, da diese in der Regel Zeitanforderungen an dassteuernde System stellen, die eingehalten werden müs-sen.

Die Software muss die jeweilige Anforderungen derRealzeitapplikation einhalten und entsprechend müssenalle Funktionen der Implementierung beispielsweise einemaximale obere Schranke, die so genannte Worst-Case-Execution-Time (WCET), besitzen. Dies hat zur Folge,dass gewisse Klassen von Algorithmen nicht zum Einsatzkommen dürfen und darüber hinaus für die parallele Ver-

43

arbeitung mehrere Aufgaben verschiedene Vorkehrungengetroffen werden müssen, die die Einhaltung der gegebe-nen Forderungen an das System garantieren können.

Die sich aus der Software-Struktur ergebende Anfor-derungen können durch den Einsatz der Toolkette ALISauf die Informationen heruntergebrochen werden, die fürden Entwickler relevant sind. Diese Daten werden in derAM3-Datenbank abgelegt und so kann ein Systemdesignerbereits in der frühen Phasen der Entwurfsraumexplorationnach geeigneten Komponenten zur Reintegration suchen,ohne dass er dafür den Quelltext der Einzelimplementie-rungen studieren muss.

5. Standardarchitekturen

Auch die Anforderungen an die Hardware wachsenkontinuierlich, während der Markt immer kürzere Zyklus-zeiten fordert. Dieser Zwang steht der bisherigen Praxisentgegen, für Anwendungen mit besonderen Anforderun-gen an die Verlässlichkeit hochspezialisierte Hardware zuentwickeln. Im Teilprojekt ADES („Architecture for De-pendable Embedded Systems“) wurde eine Standardarchi-tektur erarbeitet, die diesen hohen Anforderungen genügt.

Die Schwerpunkte bei der Verwirklichung lagen da-bei zum einen auf der Verwendung von Standardkompo-nenten sowohl der Hardware als auch der Software. Da-durch kann die Entwicklungszeit für spezialisierte Hard-ware auf ein Minimum reduziert werden, und die zugrun-deliegende Softwarearchitektur weitestgehend für die ver-schiedensten Anwendungen übernommen werden. Zumanderen sollte die Zuverlässigkeit des Systems durch dieArchitektur vorgegeben werden und darüber hinaus ohneÄnderungen der eigentlichen Anwendung skalierbar sein.Hardwareseitig wurde dies durch den Einsatz von iden-tischen Rechnereinheiten (im Projekt wurden Standard-PCs mit dem Betriebssystem QNX verwendet) bewerk-stelligt, die über eine Punkt-zu-Punkt-Verbindung gekop-pelt sind. Softwareseitig wurde dies realisiert, indem eineFehlertoleranzschicht zwischen Anwendung und Betriebs-system eingeführt wurde, die an bestimmten Synchronisa-tionspunkten in der Anwendung einen Abgleich mit denanderen Rechnern vornimmt. Erst danach darf die An-wendungssoftware weiter abgearbeitet werden. Eine Zeit-überwachung verhindert, dass ein ausgefallener Rechnerdie übrigen blockieren kann. Der Entwickler der Anwen-dungssoftware muss sich nicht explizit um die Synchro-nisation kümmern; er legt lediglich den Synchronisations-punkt und den zu synchronisierenden Datensatz fest. DieKommunikation, Votierung und eventuelle Fehlerreaktionübernimmt die Fehlertoleranzschicht.

Bei der momentanen Implementierung hat jeder Syn-chronisationspunkt einen hohen zeitlichen Aufwand, derdurch zwei Umstände verursacht wird. Zum einen müssendie zu synchronisierenden Daten eine Vielzahl von Schrit-ten durchlaufen, bevor sie tatsächlich synchronisiert wer-den können – sie werden zuerst an einen Kommunikati-onsprozess übergeben, der sie dann über TCP/IP an dieanderen Rechner sendet. Zum anderen benötigt die Kom-munikation über TCP/IP unter QNX sporadisch deutlich

mehr Zeit als normal; bei der Dimensionierung der Ti-meouts, mit denen ein Rechnerausfall erkannt wird, mussaber grundsätzlich der ungünstigste im nicht fehlerhaftenBetrieb mögliche Fall berücksichtigt werden. Dies bedeu-tet, dass die für die Synchronisation notwendige Zeit nichtlinear mit der Anzahl der zu synchronisierenden Datenwächst, sondern primär von der Anzahl der Synchronisa-tionspunkte abhängt. Eine komplexere Anwendung wirddaher nur eine unwesentlich längere Reaktionszeit als dieBeispielanwendung haben, wenn nur die Menge der syn-chronisierten Daten erhöht wird, und nicht gleichzeitigauch die Anzahl der Synchronisationspunkte.

Da von der Funktionalität von TCP/IP nur ein Bruch-teil benötigt wird, liegt der Gedanke nahe, ein eigenes,wesentlich einfacheres Kommunikationsprotokoll für dasRechner/Rechner-Kommunikationssystem zu entwickeln,mit dem die für die Kommunikation benötigte Zeit redu-ziert werden kann. Generell aber wird in einem ADES-System ein Großteil der verfügbaren Systemleistung fürdie Synchronisation der Rechner benötigt werden. Einedeutliche Reduzierung des Synchronisationsoverheads lie-ße sich nur durch den Einsatz taktsynchroner Hardwaremit Hardwarevotern erreichen, was aber dem Ziel, mög-lichst nur COTS-Komponenten zu verwenden, direkt wi-derspricht.

Dem gegenüber stehen aber die Vorteile eines aufCOTS Komponenten basierenden Systems. So könn-ten die Reaktionszeiten des Prototypen allein durchden Einsatz aktueller Rechnertechnik verbessert wer-den, ohne am sonstigen System etwas ändern zu müs-sen.

Die Wichtigkeit und Notwendigkeit einer solchen Ar-chitektur wurde bereits zu Beginn des Projekts in [4] dar-gestellt. Später konnten die Ergebnisse noch vertieft wer-den. [3] beschreibt einen möglichen Einsatz im Robotik-Vision-Bereich.

Literatur

[1] BENITO L ICCARDI, THOMAS MAIER-KOMOR und HANS

OSWALD: Meta-Modell basierte Architektur Templates fürdie High-Level Exploration Eingebetteter Realzeitsysteme.In: 8. Fachtagung Entwurf komplexer Automatisierungssy-steme (EKA), 2003.

[2] BENITO L ICCARDI, THOMAS MAIER-KOMOR, HANS OS-WALD , M. ELKOTOB und GEORG FÄRBER: A Meta-Modeling Concept for Embedded RT-Systems Design. 14thEuromicro Conference on Real-Time Systems – Work inProgress Session, 2002.

[3] CHRISTOF EBERST und THOMAS HERBIG: On the Appli-cation of the Concept of Dependability for Design and Ana-lysis of Vision Systems. In: Proceedings of the 3rd Int. Conf.on Computer Vision Systems (ICVS), Seiten 290–303, 2003.

[4] ERIC DÖNGESund GEORG FÄRBER: Architekturvorschlagzur Entwicklung verläßlicher eingebetteter Realzeitsystemeauf Basis von Standardkomponenten. at - Automatisierungs-technik, 47(7):314–319, 1999.

[5] THOMAS MAIER-KOMOR: An Aspect-oriented ApproachMaking Autogenerated Code for Embedded RT-Systems Re-targetable. In: Proceedings of FORUM on Specification &Design Languages, 2002.

44

Kombination von Sprachen und Berechnungsmodellenfür die Synthese eingebetteter Systeme

Marek Jersak, Razvan Racu, Kai RichterInstitut für Datentechnik und Kommunikationsnetze (Prof. Dr. R. Ernst)

TU Braunschweig

Zusammenfassung

Die Komplexität und Heterogenität moderner eingebet-teter Systeme führt zu kaum überschaubaren Abhängig-keiten im System. Daher ist insbesondere die Verifikationnicht-funktionaler Anforderungen, speziell desEchtzeit-verhaltensoder allgemeiner derSystemperformanz, mitheutigen Verfahren kaum noch zu leisten. Dies führt in al-len Anwendungsbereichen entweder zu überdimensionier-ten oder zu unzuverlässigen Lösungen.

Unser Lösungsansatz zur Verifikation von System-performanz basiert auf der Kombination verschiedenerSystemmodelle und Verfahren zur Performanzanaly-se, so dass Performanzaussagen auch für komplexe,heterogene Systeme ermöglicht werden, für die keine ein-heitliche Lösung zur Verfügung steht. Hierzu entstandenim Rahmen dieses DFG-Projekts das SPI-Modell so-wie das Werkzeug SymTA/S. In zahlreichen Studien wurdedie Wirksamkeit unseres Ansatzes gezeigt.

1. Problemstellung

Moderne eingebettete Systeme wie zum Beispiel Mo-biltelefone, Steuer-Elektronik im Automobil, Internet-Router oder Multimedia-Elektronik müssen eine Viel-zahl höchst komplexer Funktionen ausführen. Zusätzlichsind strenge Anforderungen insbesondere an Zuverläs-sigkeit, Sicherheit, Kostenminimierung sowie geringst-möglichen Platz- und Strombedarf zu erfüllen. Dies alleserfordert hochoptimierte Lösungen. Als Folge sind ein-gebettete Systeme ausgesprochenheterogen, denn fürverschiedene Teilfunktionen eignen sich jeweils unter-schiedliche spezialisierte Implementierungen am be-sten.

Heterogene ArchitekturDie Architektur eines eingebet-teten Systems besteht aus spezialisierten Prozessorenund Kommunikations-Komponenten. Diese können so-wohl hochintegriert sein, etwa in einem Mobiltelefon, oderverteilt, etwa im Automobil. Abbildung 1 zeigt beispiel-haft die Komponenten eines typischen System-on-Chip(SoC) aus dem Bereich Multimedia.

Ein eingebettetes System besteht zur Steigerung derEntwurfsproduktivität zum großen Teil aus wiederverwen-deten Komponenten, die nur soweit wie nötig angepasstwerden. Dies führt dazu, das Teilkomponenten, auch ver-schiedener Hersteller, integriert werden müssen. Dabeientstehen eine Vielzahl von Abhängigkeiten. Abbildung 2

R. Ernst, TU Braunschweig 1

Phillips NexperiaTM Platform

MpSoC Example: Viper Setop Box

MIPS bridge

MIP

SP

I bu s

MIPS C-BridgeAudio I/O

Sony PhilipsDigital I/OHigh-performance

2D-rendering engine

Adv. imagecompositionProcessor

MPEG-2video decoder

Video inputprocessor

MPEGsystem proc.

Universal async.receiver/transmitter

(UART)

Universal serial bus

ISO UART

IEEE 1394 link layer controller

I²C

Exp. bus interfaceunit PCI/XIO

Synchronousserial interface

Memory-basedscaler

Interrupt ctrl.

Transport streamDMA

General-purposeI/O

IC debug

Clocks

CPU debug

Reset

CRC DMA

Interrupt controller

Enhanced JTAG

Fast

PI b

us

MIPS(PR3940)

CPU

D$

I$

Tri M

edia

PI b

us

TriMedia(TM32)CPU

D$

I$

C-bridge

External SDRAM

Memory controller

Mem

.M

gmt .

IF b

u s

TriMediaC-BridgeFast C-Bridge

Abbildung 1. SoC für Multimedia Anwendungen

zeigt dies am Beispiel zweier unabhängiger Subsysteme,die sich nach der Integration einen gemeinsamen Kommu-nikationsbus teilen müssen, und sich daher gegenseitig be-einflussen können.


Subsystem integration - example

M2IP2M3

M1

Com Netw

DSPIP1

HWCPU

M2

IP2M3

M1DSP

IP1HW

CPU

Integration

subsystem 1

subsystem 2

P1

P3

P2

Sens

Sens

subsystem 2

subsystem 1

Abbildung 2. Integration von Hardware/Software-Komponenten

Heterogene SystemsoftwareUnterschiedliche Funktionenmüssen sich häufig einen Prozessor teilen. Hierzu läuft aufjedem Prozessor eine spezialisierte, mehrschichtige Sy-stemsoftware, bestehend aus Betriebssystem und hardwa-

45

reabhängigen Software-Funktionen, auf der die Anwen-dungssoftware aufsetzt. Dies führt zu weiteren Abhängig-keiten zwischen verschiedenen Anwendungen.

Heterogene AnwendungenJede Anwendung, etwa ESP(elektronisches Stabilität-Programm) oder GRA (Ge-schwindigkeit Regel-Anlage) im Automobil, besteht auszahlreichen komplexen Software-Funktionen. Diese wer-den in spezialisierten Entwurfsprozessen mittels speziali-sierter Modelle und Werkzeuge entworfen (Abbildung 3).Dies führt zu mehrsprachigem Entwurf und damit zu ei-nem weiteren Integrationsproblem.


Heterogene Systeme und SPI Workbench

implementation languagearchitecture layer

application „articulation point“

subsystem 2Simulink

inputlanguage 2

subsystem 3

subsystem 1

IP

UML

application development

application layer

M

CoP

M

M

PDSP

M

P

core

RTOS

I/O Int Bus-CTRL

timertimer

drivers

RTOS-APIs

application

implementation

Abbildung 3. Integration einer Vielzahl heteroge-ner Funktionen auf der Zielarchitektur

Die Folge von Komplexität, Heterogenität und Integra-tion auf verschiedenen Ebenen sind kaum überschauba-re Abhängigkeiten der Funktionen im System. Daher istdieVerifikationeines solchen Systems ein außerordentlichschwieriges Problem. Insbesondere die Verifikation nicht-funktionaler Anforderungen, speziell desEchtzeitverhal-tensoder allgemeiner derSystemperformanz, ist mit heu-tigen Verfahren kaum noch zu leisten. Ohne zuverlässigeAussagen über die Systemperformanz kann die korrekteFunktion des Systems aber nicht unter allen Bedingungengarantiert werden.

Dies führt in allen Anwendungsbereichen entwe-der zu überdimensionierten oder zu unzuverlässigenLösungen. In sicherheitskritischen Bereichen, insbeson-dere bei den sogenannten X-by-wire Anwendungen imAutomobil, wird die Einführung von elektronischen Lö-sungen zum Teil um Jahre verzögert, da der Nachweisder geforderten Systemzuverlässigkeit nicht erbracht wer-den kann.

2. Stand der Technik

Heutige Verfahren zur Validierung der Systemperfor-manz mit Werkzeugen wie Mentor Seamless, Axys Ma-xSim oder mit spezieller Prototyping-Hardware basierenauf Simulation und Test. Dies hat den Vorteil, dass exi-stierende Testmuster zur Validierung der Systemfunkti-on wiederverwendet werden können. Der Nachteil ist je-doch, dass die Vielzahl der Abhängigkeiten der Funktio-nen im System, die erst bei der Integration entsteht, vonsolchen Testmustern nicht abgedeckt wird, da die zu te-stenden Fälle beim Funktionsentwurf nicht bekannt sind.

Gerade die Einflüsse der Integration wirken sich jedochdramatisch auf die Systemperformanz aus. Solche Einflüs-se sind bei ausreichender Systemkomplexität mit Simula-tion oder Test kaum noch vollständig zu finden.

Aus der Forschung sind weiter eine Vielzahl vonana-lytischenVerfahren bekannt, die für spezielle Teilsyste-me zuverlässigGrenzen des mögliche Systemverhaltenbestimmen. Dies ist ein wichtiger Schritt in Richtung si-cherer Performanzaussagen. Für die von uns betrachtetenkomplexen, heterogenen Systeme sind solche Verfahren inder Regel jedoch nicht verfügbar.

3. Vorgehen

Unser Lösungsansatz basiert auf der Kombination ver-schiedener Systemmodelle und Verfahren zur Performan-zanalyse, so dass Performanzaussagen auch für komplexe,heterogene Systeme ermöglicht werden, für die keine ein-heitliche Lösung zur Verfügung steht.

Das von uns verwirklichte Vorgehen basiert auf der sy-stematische Erfassung performanzrelevanter Eigenschaf-ten von Applikation, Architektur und Implementierung,sowie von Performanz-Anforderungen und Zusicherungender Systemumgebung. Die erfassten Eigenschaften wer-den in ein geeignetes Analysemodell transformiert. An-schließend findet eine Performanzbewertung mittelszu-verlässiger, analytischer Verfahren statt.

3.1. Erfassung von Architektur und Implemen-tierung

Ein eingebettetes System besteht aus Rechen- undKommunikations-Komponenten, die miteinander ver-knüpft sind. Auf jeder Komponente verwaltet eine ge-eignete Systemsoftware die zu erledigenden Aufgaben(im folgenden Prozesse genannt). Mit Hilfe sogenann-ter Schedulinganalyse lassen sich zuverlässige Aussagenüber die minimale und maximale Zeit machen, die ei-ne Komponente zum Erledigen eines Prozesses benötigt.Hierzu müssen zuvor Schedulingparameter, z.B. Priori-täten, sowie die zu erwartende Last erfasst werden. Lastwird mit Hilfe sogenannter Ereignismodelle an den Ein-gängen von Prozessen angegeben.


t

Periode d max d minJitter

Ereignisse

Abbildung 4. Beispiel für Ereignismodell: Peri-odisch mit Jitter

Das Beispiel in Abbildung 4 zeigt ein Ereignismodell,das einen Prozess im Mittel mit der PeriodeP aktiviert. Je-de Aktivierung kann jedoch in einem Intervall der BreiteJ jittern, was zu zeitweilig höherer oder niedrigerer Lastführt.

46

3.2. System-Analyse

Ein Kernbeitrag unserer Arbeiten ist die Erweiterungvon Schedulinganalysen auf komplexe, heterogene Archi-tekturen. Für solche System existiert i.A. kein geeigne-tes Analyseverfahren. Wir konnten jedoch zeigen, dass esmöglich ist, vorhandene Analysen für Teilsysteme mitein-ander zu verknüpfen, genauso wie die Komponenten jaselbst miteinander verknüpft sind. Hierzu musste der Er-eignismodellbegriff auch auf Prozess-Ausgänge erweitertwerden [5, 6]. Dies wird in Abbildung 5 dargestellt. Es istnun möglich, die Ausgangsmodelle von Prozessen auf ei-ner Komponente (CPU, NoC, DSP, . . . ) zur benachbartenKomponente zu propagieren, und dort für die Scheduling-analyse zu nutzen.


M2DSP

HW

IP2M3IP1

M1CPUSens

C1

C3NoC C2

P1P3

P2

RTOS

Kopplung über Ereignismodelle

EM EM EM EM

EM EM

EM Ereignismodell

Abbildung 5. Kopplung von Komponentenanaly-sen über Ereignismodelle

Da Ausgangsmodelle meist komplexer sind als Ein-gangsmodelle, sind ggf. Anpassungen notwendig. Hierzuwurden von uns verschiedene Verfahren entwickelt. Al-le beschriebenen Konzepte wurden im Werkzeug Sym-TA/S (Symbolic Timing Analysis for Systems) verwirk-licht (Abbildung 8).

3.3. Erfassung der Applikation

Eine Darstellung, die sich für die Performanzanalyseeignet, muss zuerst aus gängigen Darstellungen gewonnenwerden, die für die Modellierung eingebetteter Systemeverwendet werden. Im ersten Schritt werden hierfür alleperformanzrelevanten Eigenschaften im SPI-Modell (Sy-stem Property Intervals) [7] erfasst. Details, die die Per-formanz nicht beeinflussen, werden abstrahiert. Das Prin-zip ist in Abbildung 6 verdeutlicht. Die Transformation indas SPI-Modell wurde für zahlreiche grundlegende Mo-delleigenschaften, sowie beispielhaft für die gängigen Mo-dellierungswerkzeuge Simulink [2] und SDL [4] gezeigt.

Im zweiten Schritt muss die Architektur-unabhängigeSPI-Darstellung in die in SymTA/S verwendete Darstel-lung transformiert werden, in der Architektur-Einflüsseberücksichtigt werden. Hierzu werden zum einen Prozes-se an Komponenten gebunden, zum anderen werden kom-


SPI als Gemeinsame Zwischendarstellungsubsystem 2

Simulink

inputlanguage 2

subsystem 3subsystem 1

IPUML

SPI+Host languages

Abbildung 6. Transformation performanzrelevan-ter Applikationseigenschaften in das SPI-Modell

plexe Prozess-Abhängigkeiten in Ereignismodelle trans-formiert, die SymTA/S verwendet (Abbildung 7 und [3]).


Application model compatibility

• stream model represents exact data volume– keeps causality for application model activation

– required for „AND“ activation, e.g. data flow graphsotherwise infinite buffers or starvation

– not needed for process systems with „OR“ activation or timedriven activation

P1 P2

1

1 11

11

CPU1 CPU2

P1 P2

2

1 1 11

CPU1 CPU2

P321

Abbildung 7. Erfassung Komplexer Prozess-Abhängigkeiten

Damit ist endlich der Weg frei für die Performanzana-lyse realer Anwendungen, die auf auf heterogenen Archi-tekturen implementiert werden. Damit wird eine Verifika-tion von Performanzbedingungen, wie End-zu-End Dead-lines, von Synchronsiationsbedingungen und von Puffer-speicherdimensionierung möglich. Gleichzeitig wird dieSystemoptimierung unterstützt.

4. Ergebnisse

Als Ergebnis der Arbeiten an SPI und SymTA/S ent-standen mehr als 20 Publikationen in Büchern, in interna-tional erstrangigen Zeitschriften und auf führenden inter-nationalen Konferenzen. Eine Dissertation wurde vollen-det, zwei sind im Endstadium. Als besonders fruchtbarhaben sich die Kooperationen mit der ETH-Zürich (Prof.Thiele), der Universität Paderborn (Prof. Teich, jetzt UniErlangen) sowie der Princeton University (Prof. Wolf) inden Bereichen Modellierung, Analyse und Exploration er-wiesen. Das SPI-Modell diente hierbei als gemeinsameGrundlage und Austauschformat.

Äußerst wertvoll waren zahlreiche Industrie-Kooperationen. Die beschriebene Methodik wurdeinsbesondere im Rahmen der Software-Entwicklung fürMotorsteuergeräte bei Volkswagen angewendet. Es konn-te gezeigt werden, dass mit einer systematischen Model-lierung von Architektur, Systemsoftware und Anwender-software, und anschließender Performanzanalyse, genaueAussagen über das mögliche Systemverhalten getrof-fen werden können [1]. Hieraus wurde ein Szenario fürdie Integration, Validierung und Zertifizierung von Soft-ware im Bereich Motorsteuerung entwickelt, das Volks-

47

Abbildung 8. Schreenshot des Performanz-Analysewerkzeugs SymTA/S

wagen verbindlich in Verträge mit Zulieferern aufnehmenwill.

In einem weiteren Projekt mit Volkswagen wird zurZeit an einer Plattform zur Exploration von Elektronikar-chitekturen im Automobil gearbeitet, die mittels simulati-ver und analytischer Verfahren eine Architekturbewertunganhand von virtuellen Prototypen ermöglicht. Der Vorteileines virtuellen Prototypen ist seine sehr frühe Verfüg-barkeit und hohe Flexibilität. Daraus resultiert ein enor-mes Potential zur Systemoptimierung und Kostenredukti-on. Ähnliche Ziele verfolgen zwei kürzlich gestartete Pro-jekte mit der Firma Intel im Bereich Netzwerkprozesso-ren, sowie mit der Firma Thomson im Bereich Nachbear-beitung digitaler Bilddaten für hochauflösende Kinofilme.

Das schon erwähnte Werkzeug SymTA/S entstand, umPerformanzanalyse komplexer Systeme schnell und kom-fortabel durchführen zu können. SymTA/S hat in zahlrei-chen Vorführungen großes Interesse geweckt und wird ak-tiv weiter entwickelt. Es gibt mehrere Anfragen von For-schungsgruppen, SymTA/S zu verwenden oder um eige-ne Analysemodule zu erweitern. In SymTA/S lebt alsoder von Anfang an anvisierte Geist einer offenen Analyse-Workbench. Parallel dazu wird über die Kommerzialisie-rung der in SymTA/S realisierten Konzepte nachgedacht.

Literatur

[1] JERRAYA, A.A., S. YOO, D. VERKEST und N. WEHN

(Herausgeber):Embedded Software for SoC, Kapitel Formal

Methods for Integration of Automotive Software, Seiten 11–24. Kluwer Academic Publishers, August 2003.

[2] JERSAK, M., Y. CAI , D. ZIEGENBEIN und R. ERNST: ATransformational Approach to Constraint Relaxation of aTime-driven Simulation Model. In: Proceedings 13th In-ternational Symposium on System Synthesis, Madrid, Spain,September 2000.

[3] JERSAK, M. und R. ERNST: Enabling Scheduling Analysisof Heterogeneous Systems with Multi-Rate Data Dependen-cies and Rate Intervals. In: Proceeding 40th Design Auto-mation Conference, Annaheim, USA, Juni 2003.

[4] JERSAK, M., K. RICHTER, R. HENIA, R. ERNST undF. SLOMKA : Transformation of SDL Specifications forSystem-Level Timing Analysis. In: Tenth International Sym-posium on Hardware/Software Codesign (CODES’02), EstesPark, Colorado, USA, Mai 2002.

[5] RICHTER, K., M. JERSAK und R. ERNST: A Formal Ap-proach to MpSoC Performance Verification. IEEE Compu-ter, 36(4), April 2003.

[6] RICHTER, K., R. RACU und R. ERNST: Scheduling Analy-sis Integration for Heterogeneous Multiprocessor SoC. In:Proceedings 24th International Real-Time Systems Sympo-sium (RTSS’03), Cancun, Mexico, Dezember 2003.

[7] Z IEGENBEIN, D., K. RICHTER, R. ERNST, L. THIELE undJ. TEICH: SPI – A System Model for Heterogeneously Spe-cified Embedded Systems. IEEE Transactions on Very LargeScale Integration (VLSI) Systems, 10(4), August 2002.

48

SPI-Workbench: Modelle und Verfahren zur Analyse, Synthese undOptimierung von gemischt reaktiv/transformativen eingebetteten Systemen

Christian Haubelt, Dirk Koch, Cornelia GrabbeLehrstuhl für Hardware-Software-Co-Design (Prof. Dr.-Ing. Jürgen Teich)

Universität Erlangen-Nürnberg

Zusammenfassung

Komplexe eingebettete Systeme wie mobile Kom-munikationsgeräte, Industriesteuerungen, Medizintech-nik, etc. sind von Natur aus meist heterogen. Ein Aspektder Heterogenität liegt in den unterschiedlichen Berech-nungsmodellen, die diese Systeme oder Teile hierausbeschreiben. So beschreibt ein Modell eines Audiosys-tems überwiegend die Transformation von Eingangsströ-men in Ausgangsströme, während eine Industriesteuerungauf Eingangsereignisse reagiert. Ein Beispiel für ein Sys-tem, das sowohl reaktive als auch transformative Kompo-nenten enthält, ist das Mobiltelefon.

Im Zusammenhang mit gemischt reaktiv/transforma-tiven Systemen liegen Probleme in den Bereichen der Ana-lyse, Synthese, Optimierung und Verifikation. Das hiervorgestellte Projekt ist Teil einer Kooperation mit der TUBraunschweig, der ETH Zürich und der Princeton Univer-sity. Innerhalb dieser Kooperation wurden Modelle undMethoden zum Entwurf gemischt reaktiv/transformativereingebetteter Systeme entwickelt. Das Ergebnis ist dasSPI-Modell, das in der Lage ist, von bekannten Model-len zu abstrahieren. Für dieses Modell wurden Methodenentwickelt, die entweder direkt aus Methoden für bekann-te Berechnungsmodelle abgeleitet oder gänzlich neu ent-wickelt wurden. Somit hat diese Kooperation in den ver-gangenen Jahren die Entwurfsmethodik für gemischt reak-tiv/transformative Systeme auf unterschiedlichen Gebietenbeeinflusst und vorangetrieben. Dies ist durch zahlreichegemeinsame Publikationen belegt.

1. Problemstellung

Bevor der wissenschaftlichen Fortschritt und der Ein-fluss der Ergebnisse auf die Industrie beschrieben wer-den, soll zunächst nochmals der Stand der Wissenschaftzu Beginn des Projektes und die eigentliche Problemstel-lung skizziert werden. Das hier vorgestellte Projekt wur-de in der zweiten und dritten Antragsphase mit jeweils ei-ner wissenschaftlichen Mitarbeiterstelle gefördert.

1.1. Erkenntnisstand zu Beginn des Projektes

Die rasante Entwicklung des Markteseingebette-ter Systemein Bereichen der Kommunikationstechnik,Unterhaltungselektronik, Medizintechnik, etc. zeigt auf-grund des technologischen Fortschritts, verbunden mit

zunehmender Akzeptanz von Verfahren zur automati-schen Synthese und Verifikation auf unteren Entwurfsebe-nen, eine ungeahnte Wachstumsdynamik. Im Gegensatzzu Vielzweckrechnern können eingebettete Systeme aller-dings nur dann gewinnbringend vermarktet werden, wenndie zu entwerfenden Systemeheterogene Nebenbedingun-gen erfüllen. Durch den Kunden eines zu entwerfendenSystems werden beispielsweise Kosten, Leistungsver-brauch und Variantenfreundlichkeit diktiert. Fernerbestimmt häufig die Einsatzumgebung zusätzliche Anfor-derungen an das System.

Kombinationen unterschiedlichster Anforderungenführen dazu, dass die resultierenden Systeme hetero-gen, z.B. gemischt in Hard- und Software, realisiert sind[5]. Ein bisher ungelöstes Problem im Entwurf eingebet-teter Systeme besteht in der Definition eines geeignetenBeschreibungsformalismus, mit dessen Hilfe die we-sentlichen heterogenen Systemeigenschaften dargestellt,analysiert und synthetisiert werden können.

Um die Eingabe des zu entwerfenden Systems ein-fach zu gestalten und dennoch effiziente Analyseverfah-ren zu erlauben, haben sichdomänenspezifische Modelleals erfolgreich bewiesen: Hierzu gehören im Bereich desEntwurfs reaktiver Systemebeispielsweise unterschiedli-che Varianten von Zustandsmaschinenmodellen. Im Be-reich von transformativen Systemenwerden Ströme vonDaten verarbeitet. Für beide Gebiete lassen sich nun auf-grund der formalen Eigenschaften und der Eingeschränkt-heit der Modelle feste Aussagen über das Systemverhal-ten mit Hilfe effizienter Analyseverfahren treffen. Zu sol-chen Verfahren gehören u.a. Verfahren zur Analyse vonDeadlocks, Beschränktheit von Speichern und zur Ablauf-planung. Mit diesen Ergebnissen lassen sich häufig direktVerfahren zur Synthese effizienten Zielcodes ableiten.

Abbildung 1 zeigt denklassischenEntwurfsfluss. Be-ginnend mit den domänenspezifischen Spezifikationen derTeilsysteme werden diese analysiert und optimiert. Die sooptimierten Implementierungen der Teilsysteme werdenmit Hilfe einer sog.Backplaneintegriert.

1.2. Ziele des Projektes

Da die Optimierung der Teilsysteme unabhängig von-einander erfolgt, ist die Implementierung des Gesamt-systems im Allgemeinen suboptimal. Ziel dieses Projek-tes war es, in Zusammenarbeit mit den Kooperationspart-nern der TU Braunschweig (Prof. Ernst), der ETH Zürich

49

Integration (Backplane)

Subsystem n(Sprache n)

ValidierungEntwurf &

Optimierung

Subsystem 2(Sprache 2)



(Sprache 1)Subsystem 1

Optimierung Optimierung

Abbildung 1. Domänenspezifischer Entwurf: Diedomänenspezifischen Spezifikationen der Teil-systeme werden getrennt von einander optimiertund anschließend integriert.

(Prof. Thiele) und der Princeton University (Prof. Wolf)dieses Problem zu lösen und Modelle und Methoden zurAnalyse, Synthese und Optimierung von gemischt reak-tiv/transformativen Systemen zu ermöglichen.

Das beantragte Forschungsvorhaben ergab sich ausder Zielsetzung, eine Entwurfsmethodik zu schaf-fen, die die Vorteile eines modellbasierten Entwurfsmit domänenspezifischen Methoden aus mehreren Be-reichen nutzen kann, um damit effiziente, gemischtreaktiv/transformative Systeme synthetisieren zu kön-nen. Dazu sollte eine geeignete interne Repräsentationals Zwischendarstellung für Analyse- und Synthesever-fahren definiert werden. Die Philosophie besteht darin,sowohl bekannte domänenspezifische Modelle und Ana-lyseverfahren integrieren als auch neue domänenspezischeModelle einfach in das resultierende Entwurfssystem ein-bringen zu können (siehe Abbildung 2).

2. Wissenschaftlicher Fortschritt

Hier sollen kurz die wichtigsten wissenschaftlichen Er-gebnisse innerhalb dieses Projektes vorgestellt werden.Diese Ergebnisse beziehen sich auf alle wesentlichen Be-reiche des Entwurfs eingebetteter Systeme. Hierzu gehö-ren die Modellierung, die Analyse, die Optimierung, dieSynthese und die Verifikation eingebetteter Systeme.

2.1. Modellierung

Zu Beginn des Projektes wurde das SPI-Modell (Sys-tem Property Intervals) definiert [3]. Die Besonderheit desSPI-Modells liegt vor allem in den Bereichen a) Model-lierung von Kontroll- und Datenfluss und b) Modellierungvon unsicherem Verhalten durch Intervalle.

Ein einfaches SPI-Modell, bestehend aus drei Prozes-sen (P1,P2 und P3) welche über zwei Kanäle (C1 und C2)miteinander kommunizieren, ist in Abbildung 3 gegeben.Sowohl den Kanälen Ci als auch den Prozessen Pi sind La-tenzzeiten latCi bzw. latPi zugeordnet, welche die Bearbei-tungszeit eines Kanals bzw. Prozesses darstellen. Weiter-hin sind Parameter sCi und rCi den Kanälen Ci zugeord-net. Diese geben die Anzahl der produzierten bzw. konsu-

Subsystem n(Sprache n)

Subsystem 2(Sprache 2)(Sprache 1)

Subsystem 1

Subsystem 2(Sprache 2)(Sprache 1)

Subsystem 1 Subsystem n(Sprache n)


Optimierung Analyse Synthese Verifikation

Abbildung 2. Entwurfsfluss mit SPI: Die domä-nenspezifischen Spezifikationen werden in demSPI-Modell gekapselt. Anschließend kann eineglobale Analyse, Synthese, Optimierung oder Ve-rifikation des Modells erfolgen.

mierten Daten bei Ausführung de jeweiligen Prozesses an.Die Anzahl der Marken, die in einem Kanal Ci gespeichertsind werden durch den Parameter dCi modelliert. Die Ak-tivierung eines Prozesses Pi wird durch die Aktivierungs-funktion aPi bestimmt. Sämtliche Parameter lat,s, r und dsind durch Intervalle repräsentiert. Dies bedeutet, dass ent-weder die genauen Werte nicht bekannt sind oder die Para-meter ungenau spezifiziert wurden. Das SPI-Modell bildetdie Basis für alle oben genannten Kooperationspartner.

Basierend auf dem SPI-Modell wurden unterschiedli-che Modellerweiterungen diskutiert, u.a., FunState [4] undhierarchische Spezifikationsgraphen [2]. Das Ziel bei bei-den Modellerweiterungen war die Einführung von Hier-archie in das SPI-Modells und die Beschränkung aufanalysierbare Eigenschaften. Das Modell der hierarchi-schen Spezifikationsgraphen rückt weiterhin den Aspektder Ressourcenbeschränkung in den Mittelpunkt. Das re-sultierende Modell trennt strikt zwischen Verhalten (ge-geben durch einen SPI-Prozessgraphen) und der fürdie Implementierung wichtige Architektur (siehe Ab-bildung 4). Die Prozesse und Kanäle des SPI-Modellskönnen auf die Komponenten der Architektur abge-bildet werden. Weiterhin können Prozesse und Kanä-le durch SPI-Prozessgraphen weiter verfeinert werden.

2.2. Analyse

Basierend auf dem FunState-Modell wurden Verfah-ren zur Analyse der Beschränktheit, Verklemmungsfrei-heit und der Existenz periodischer Abläufe entwickelt[4]. Während die Beschränktheit eines Systems garantiert,dass keine Daten verloren gehen, zeigt die Verklemmungs-freiheit an, dass ein System stets funktionsfähig bleibt.Beides sind somit wesentliche Eigenschaften, die hier ge-zeigt werden konnten.

50

P1 1C C2 P3P2

lat P2lat C1lat P1 lat C2 lat P3

C1s C1r sC2 r C2

C1d dC2P2aa P1 P2a

Abbildung 3. Einfaches Beispiel eines SPI-Prozessgraphen. Die Prozesse P1,P2, und P3

kommunizieren über Kanäle C1,C2. Die Parame-ter lat,s, r, und d sind durch Intervalle spezifiziert.Die Aktivierungsfunktionen aPi beeinflussen dieAusführung eines Prozesses Pi.

Ein weiterer Durchbruch gelang auf dem Gebietder Verifikation während der Synthese durch den Ein-satz von SAT-Techniken (SATisfiability - Erfüllbar-keitsproblem) [1]. Hierfür wurde das Bindungsproblem,also welcher Prozess auf welche Komponente berech-net wird, auf ein binäres Erfüllbarkeitsproblem reduziert.Dieses Problem besitzt genau dann eine Lösung, wenn ei-ne Lösung zu dem oben beschriebenen Bindungsproblemexistiert. Durch den Einsatz von SAT-Techniken kön-nen somit sehr schnell Lösungen überprüft und Suchräu-me nach gültigen Lösungen reduziert werden. Im Ein-satz von Verifikationstechniken während der Synthese-und Optimierungszeit sehen wir auch neue und inter-essante Perspektiven für weitere Arbeiten.

2.3. Synthese

Die Ergebnisse im Bereich Synthese wurden insbe-sondere in den beiden Bereichen Ablaufplanung undHardware/Software-Partitionierung erreicht. Bei der Ab-laufplanung konnte zum einen die Integration bestehenderstatischer Ablaufplanungsverfahren aus der Datenfluss-domäne (synchrone Datenflussgraphen und zyklostati-scher Datenflussgraphen) in die SPI-Methodik gezeigtwerden als auch die Entwicklung neuer Ablaufplanungs-verfahren für gemischt reaktiv/transformativer Systemevorangetrieben werden. Bei der Integration der beste-henden Verfahren wurde auf das ressourcenbeschränk-te Modell der Spezifikationsgraphen zurückgegriffen. DieEntwicklung des sog.Conflict Dependent Schedulinger-folgte anhand des FunState-Modells [4]. Das wesentlicheErgebnis hierbei ist, dass dieses Verfahren einen vollstän-digen, verklemmungsfreien und beschränkten Ablaufplanfindet, falls ein solcher existiert.

Das Problem der Hardware/Software-Partitionierungbeschreibt die Aufgabe, Prozesse an Komponenten inder Architektur zu binden. Basierend auf den hierar-chischen Spezifikationsgraphen wurden in diesem Be-reich neue Verfahren entwickelt [2]. Hierbei wurdenzwei Ansätze untersucht: a) diehierarchische Parti-tionierung mit Evolutionären Algorithmen und b) diesog. Pareto-Front-Arithmetik. Die hierarchische Partitio-nierung codiert das zu partitionierende Problem als ganzesund verwendet Evolutionäre Algorithmen zur Suche opti-maler Lösungen. Die genetischen Operatoren beeinflussenhierbei auch die Auswahl der hierarchischen Verfeinerun-gen für Prozesse.

P1

1C

P2

C2

P3

a P1

C1d

P2a

dC2

P2a

sC2

C1s

C1r

r C2

lat P2, 2

lat P2, 1

lat C1, 2

lat C1, 1

lat P1, 1

lat C2, 2

lat P3, 2

lat C2, 1

lat P3, 1

lat P1, 2

Abbildung 4. Beispiel einer ressourcenbe-schränkten Spezifikation. Die Prozesse (Kanäle)des SPI-Prozessgraphen können auf Kompo-nenten der Architektur abgebildet werden. DieAusführungszeiten lat hängen von der Bin-dung der Prozesse auf die Komponenten ab.

Bei dem zweiten Ansatz werden zunächst die Verfei-nerungen der Prozesse einzeln optimiert und später, ent-sprechend der Struktur des Gesamtproblems, die Lösun-gen kombiniert. Da diese Kombination im Lösungsraumvorgenommen wird, bezeichnen wir diese Verfahren alsPareto-Front-Arithmetik. Das Ergebnis sind approximier-te Lösungen des Gesamtproblems. Wie aber bereits in derEinleitung gesagt, führt dieses Verfahren im Allgemeinennicht zu optimalen Ergebnissen. Dennoch sind diese Er-gebnisse hilfreich, um das oben beschriebene Verfahrender hierarchischen Hardware/Software-Partitionierung mit„guten“ Lösungen zu initialisieren und das Suchen nach„der Nadel im Heuhaufen“ zu verhindern.

2.4. Optimierung

Die in diesem Projekt betrachteten Probleme sind imAllgemeinen Mehrziel-Optimierungs-Probleme. Hier-bei werden mehrere Zielgrößen, welche sich gegensei-tig beeinflussen können, gleichzeitig optimiert. So sindbeim Entwurf eingebetteter Systeme nicht nur die Kos-ten des Systems interessant, sondern insbesondere beimobilen Geräten auch technische Größen wie Leis-tungsaufnahme und Größe. Abbildung 5a) zeigt einBeispiel eines 3-dimensionalen und Abbildung 5b) ei-nes 2-dimensionalen Entwurfsraums. Im Allgemeinen gibtes bei der mehrdimensionalen Optimierung mehr als ei-ne optimale Lösung (Abbildung 5b)). So gibt es in diesemBeispiel vier Entwurfspunkte, die von keinem ande-ren Entwurfspunkt in allen Zielgrößen gleichzeitig domi-niert (kleiner sind) werden. In diesem Fall spricht mandavon, dass diese LösungenPareto-optimalsind.

In diesem Projekt wurden die Verfahren zur Op-timierung bei der Hardware/Software-Partitionierungeingebetteter Systeme um Verfahren zur sog.stochasti-schen Pareto-Front-Analyseerweitert [6]. Hierbei wirdnicht mehr mit exakten Werten sondern mit Interval-

51

0

a)

0

b)

Latenz Latenz

Fläc

he

Fläche

Leis

tung

sver

brau

ch

Abbildung 5. Beim Entwurf eingebetteter Syste-me werden mehrere Zielgrößen gleichzeitig opti-miert. a) zeigt einen 3-dimensionalen Entwurfs-raum. In b) sind mehrere Lösungen in einem 2-dimensionalen Entwurfsraum gegeben. Aber nurvier der acht Lösungen sind Pareto-optimal.

len und Wahrscheinlichkeitsdichtefunktionen das Opti-mierungsproblem gelöst. Die Idee hierbei ist, dass Ziel-größen im Allgemeinen nicht exakt bekannt sind sondern,wie im SPI-Modell, meist nur untere und obere Schran-ken. Weiterhin wurden diese Verfahren erfolgreich in diePareto-Front-Arithmetik integriert [2]. Die Ergebnisse, dieim Bereich der stochastischen Pareto-Front-Analyse er-reicht wurden, gehen weit über das Gebiet des Entwurfseingebetteter Systeme hinaus.

3. Industriebezug

Innerhalb des SPI-Projektes wurden die entwickeltenMethoden an zahlreichen Industriebeispielen getestet undverbessert. Hier sollen kurz die wichtigsten Industrieko-operationen beschrieben werden.

Eine vielschichtige Kooperation gab es mit der Daim-lerChrysler AG, Esslingen, im Bereich Hardware/-Software-Partitionierung und Optimierung der Innenrau-melektronik. Untersucht wurden u.a. der Einsatz dyna-misch veränderlicher Architekturen. Hierfür wurden diehierarchischen Spezifikationsgraphen verwendet. Zur Op-timierung kamen die Verfahren zur hierarchischenHardware/Software-Partitionierung zum Einsatz. Hierausergab sich die Notwendigkeit, die resultierenden Ergeb-nisse in Bezug auf ihre Robustheit, die sog.Ausfallsi-cherheit, zu bewerten. Hierfür konnten die SAT-basiertenVerfahren erweitert werden, um eine Bewertung der Lö-sungen für dynamische Szenarien zu erhalten. Weite-re Kooperationen mit der DaimlerChrysler AG liefen inden Gebieten der Topologie-Optimierung für die Innen-raumelektronik und Hardware/Software-Partitionierungeiner Motorsteuerung.

Kooperationen mit dem Fraunhofer Institut für Inte-grierte Schaltungen (FhG-IIS), Erlangen, gibt es eben-falls auf dem Gebiet des automatischen Entwurfs digi-taler Hardware/Software-Systeme. Wiederum kamen hierdie Verfahren zur Hardware/Software-Partitionierung undOptimierung zum Einsatz. Die in dieser Kooperation un-tersuchten Systeme kamen aus dem Bereich digitaler Si-gnalverarbeitung. Diese Kooperation wird auf Grund derfachlichen und geographischen Nähe des Lehrstuhls fürHardware-Software-Co-Design zum FhG-IIS in der nahen

Abbildung 6. Alle im Projekt entstandenen Me-thoden wurden prototypisch implementiert. Hierist ein Screenshot eines Werkzeuges zur Opti-mierung hierarchischer Systeme zu sehen.

Zukunft weiter ausgebaut.Wie oben beschrieben, wurden erste Ansätze zur In-

tegration von Verifikationstechniken in die Entwurfsrau-mexploration untersucht. Aus diesen Aktivitäten ergabsich eine Kooperation mit der Firma Lucent Technologies,Nürnberg. Im Rahmen dieser Kooperation zeichnen sicherste Ideen und Ergebnisse zu verifkationsgerechten Spe-zifikationen ab. Diese Ansätze versprechen ein enormesEinsparungspotential für die Industrie und werden voraus-sichtlich im Rahmen ein großangelegten Kooperation ausIndustriepartnern und Forschungseinrichtungen weiter un-tersucht werden.

Literatur

[1] FELDMANN , R., C. HAUBELT, B. MONIEN und J. TEICH:Fault Tolerance Analysis of Distributed Reconfigurable Sys-tems Using SAT-Based Techniques. In: Proc. of 13th Interna-tional Conference on Field Programmable Logic and Appli-cations, Seiten 478–487, Lisbon, Portugal, September 2003.

[2] HAUBELT, C., S. MOSTAGHIM, F. SLOMKA , J. TEICH undA. TYAGI : Hierarchical Synthesis of Embedded SystemsUsing Evolutionary Algorithms. In: DRECHSLER, R. undN. DRECHSLER (Herausgeber):Evolutionary Algorithmsfor Embedded System Design, Genetic Algorithms and Evo-lutionary Computation, Seiten 63–104, Boston, Dordrecht,London, 2003. Kluwer Academic Publishers.

[3] JERSAK, M., D. ZIEGENBEIN, F. WOLF, K. RICHTER,R. ERNST, F. CIESLOK, J. TEICH, K. STREHL undL. THIELE: Embedded System Design using the SPI Work-bench. In: Proceedings FDL’00, Forum on Design Langua-ges 2000, Tübingen, Germany, September 2000.

[4] STREHL, K., L. THIELE, D. ZIEGENBEIN, R. ERNST,J. TEICH und M. GRIES: Symbolic] Scheduling Based onthe Internal Design Representation FunState. IEEE Trans.on VLSI Systems, 9(4):522–544, 2001.

[5] TEICH, J.: Digitale Hardware/Software-Systeme: Synthe-se und Optimierung. Springer-Lehrbuch, Heidelberg, NewYork, Tokio, 1997.

[6] TEICH, J.:Pareto-Front Exploration with Uncertain Objec-tives. In: Lecture Notes in Computer Science (LNCS), Band1993, Seiten 314–328, Zurich, Switzerland, March 7-9 2001.

52

Objektorientierte Cosimulation eingebetteter Steuerungssysteme

Michael Kersten, Frank OppenheimerDepartment für Informatik (Prof. Dr. W. Nebel)

Universität Oldenburg

Zusammenfassung

Den Rahmen des OOCOSIM-Projektes bildete die Un-tersuchung einer Gesamtmethodik zum Entwurf eingebet-teter Systeme basierend auf dem objektorientierten Model-lierungsparadigma.

Diese Methodik sollte die Möglichkeit der abstraktenSpezifikation auf Systemebene bieten, wozu Weiterentwick-lungen von HRT-HOOD bzw. UML untersucht wurden.

Besonderer Wert wurde dabei neben den Realzeit-eigenschaften und der Ausnutzung der Objektorien-tierung auf die Modellierung von Hardware/Software-Schnittstellen gelegt. Dazu wurde die Schnittstellen-Beschreibungssprache ComiX definiert.

Zur Validierung von Systemmodellen wurde ei-ne Umgebung zur zeitsynchronen Hardware/Software-Cosimulation geschaffen.

Um eine Durchgängigkeit der Methodik zu erreichen,wurden Konzepte zur Codegenerierung erstellt.

1. Problemstellung

Das Projekt „Objektorientierte Cosimulation für ein-gebettete Steuerungssysteme OOCOSIM“ verfolgte seitseinem Beginn im Jahr 1996 das Ziel der Entwicklungeiner objektorientierten Entwurfsmethodik für eingebet-tete Realzeitsysteme. Das Hauptziel des Projektes wardie Konzeption einer objektorientierten Entwurfsmethodikfür eingebettete Realzeitsysteme, die von der abstraktenSpezifikation bis zur Implementierung des zu entwickeln-den Systems reicht. Von besonderer Bedeutung war da-bei die Möglichkeit der abstrakten Spezifikation, um auchkomplexe Systeme beherrschbar zu machen. Zur Vermei-dung besonders häufig auftretender Schnittstellenfehler ander Hardware/Software-Schnittstelle, wurde auf eine flexi-ble, objektbasierte Hardware/Software-Schnittstelle Wertgelegt. Um Aussagen über das Echtzeitverhalten bei kom-plexen Systemen treffen zu können, sollte die Möglichkeitder zeitsynchronen Hardware/Software-Cosimulation be-stehen. Durch die Definition von Übersetzungsschemataund deren Implementierung durch Codegeneratoren soll-te die Durchgängigkeit gewährleistet werden.

2. Ausgangssituation bei Projektbeginn

Zu Beginn des Projekts OOCOSIM waren als objekt-orientierte Spezifikationsmethoden für das Co-Designdie Methoden OMT(INSYDE) (vgl. [8]), HRT-HOOD(vgl. [1]) und MOOSE (vgl. [3]) bekannt. Die OMT-Methode erwies sich als ungeeignet für den Entwurfeingebetteter Systeme, weil sie die Spezifikation vonEchtzeit-Anforderungen nicht unterstützt. OMT sieht ei-ne frühzeitige Partitionierung des Gesamtsystems inHardware- und Software-Komponenten vor, an die sichdie Abbildung der Software-Komponenten auf SDL92 so-wie der Hardware-Komponenten nach VHDL anschließt.HRT-HOOD und MOOSE adressieren zwar den Ent-wurf eingebetteter Systeme, beschränken die objekt-orientierten Konzepte aber im wesentlichen auf diehierarchische Dekomposition. Die MOOSE Metho-de umfaßt Konzepte für alle Phasen der Entwicklung.Dazu gehören Klassendiagramme, Datenflußdiagram-men, Objekt-Interaktionsdiagramme etc. Die Vortei-le von MOOSE sind die Unterstützung der Spezifikationnicht-funktionaler Anforderungen, sowie die Generie-rung eines ausführbaren System-Modells zur Validie-rung.

Ein Nachteil vieler Entwurfsumgebungen für eingebet-tete Systeme ist, dass sie Zielsprachen verwenden, die zurGewährleistung der Real-Zeit-Bedingungen auf echtzeit-fähigen Betriebssysteme aufsetzen. Für die Synthese müs-sen dabei sowohl die Zielsprache als auch das unterliegen-de Echtzeitbetriebssystem bekannt sein, was die Portier-barkeit erheblich einschränkt.

Diesen Nachteil hat die HRT-HOOD-Methode nicht,weil sie die Zielsprache Ada95 verwendet, bei derdie Mechanismen zur Gewährleistung von Real-Zeit-Bedingungen betriebssystemunabhängig in der Spra-che verankert sind. An der Integration von Klassenund Vererbung in die HRT-HOOD Methode wur-de zu Beginn von OOCOSIM noch gearbeitet. Einederartig erweiterte HRT-HOOD-Methode wurde auf-grund der Kombination hervorragender Konzepte zurReal-Zeit-Modellierung mit objektorientierten Kon-zepten als Grundkonzept für OOCOSIM ausgewählt.Die fehlende Unterstützung von Modellierungskon-zepten für Hardware-Komponenten wurde als wenigergravierend angesehen und sollte im Laufe des Projek-tes als Erweiterung von HRT-HOOD erarbeitet wer-den.

53

Modelleigenschaft HRT-HOOD+ UML UML-RTES

Objektbasiert ✓ ✓ ✓

Klassenbasiert – ✓ ✓

Verhaltensdefinition – ✓ ✓

Verfeinerungsmethodik ✓ – –

Realzeitunterstützung ✓ – ✓

Analysierbarkeit des Timings ✓ – ©Deadlockfreiheit ✓ © ©

Tabelle 1. Spracheigenschaften


Die OOCOSIM–Methodik beginnt mit der abstraktenModellierung auf Systemebene. Dabei geht es darum, eineDekomposition des Systems in Software-Komponenten,Hardware-Komponenten sowie Interface-Komponentenzu erreichen, die schrittweise verfeinert werden kön-nen. Dazu stehen in OOCOSIM zwei grafische Sprachenzur Verfügung:

• HRT-HOOD+ und

• UML-RTES.

Die Besonderheiten dieser Sprachen sind in Tabelle 1zusammengefasst. Ihre Verwendung wird in der folgen-den Darstellung der OOCOSIM-Methodik (siehe Abbil-dung 1) skizziert. Von der Systemebene existieren Ab-bildungen zum Ausführungsmodell und zur Cosimula-tion. Auf dieser Ebene werden Software-Komponenten

HRT−HOOD+

Implementierung

Initiale Spezifikation

Ausführb. Modelle

Cosimulation

Systemebene

Finaler TestCPU/RAM ASIC/FPGA

Driver

I/OVHDL

Software Schnittstellen

Objekte

Hardware

ObjekteObjekte

Dev.−Register/IRQ

Compilation

Synthese

AutomatischeTransformation

Ada95

Abbildung 1. OOCOSIM-Methodik

durch Ada95 und Hardware-Komponenten durch VHDLbeschrieben. Die Interface-Komponenten werden durchAda95 und VHDL beschrieben. Die Cosimulation basiertdabei auf dem Quellcodemodell. Durch Kompilation desAda95-Codes und Synthese des VHDL-Codes wird dieImplementierung des Systems erzeugt.

3.1. Spezifikation auf der abstrakten Ebene

Für die abstrakte Modellierung wurden zwei Ansät-ze näher untersucht, zum einen die HRT-HOOD+ Metho-dik und zum anderen der UML-RTES-Ansatz. Der HRT-HOOD+-Ansatz stellt eine Erweiterung des HRT-HOOD-Ansatzes von Burns und Wellings dar.

3.1.1. Der HRT-HOOD+-Ansatz Neu an der HRT--HOOD+-Methode sind Hardware-Objekte zur Re-präsentation von Hardwarekomponenten im Modellund Kommunikations-Objekte zur Modellierung derHardware/Software-Schnittstelle von eingebetteten Sys-temen auf der abstrakten Ebene. Letztere stehen in denfolgenden Varianten zur Verfügung:

• Memory Objects dienen der Modellierung von Da-tenflüssen via Shared-Memory,

• Asynchronous Signals dienen der Modellierungder Behandlung von asynchronen Hardware-Eventsdurch Software Interrupt-Routinen,

• Asynchronous Objects kombinieren beide Konzeptemiteinander und erlauben es Events mit Daten zu ver-knüpfen.

In Abbildung 2 wird ein Modellierungs-Beispiel in HRT-HOOD+ gezeigt.

SY Prozessorlüftungsregelung

C Überwachung

Period = 20 ms

Priority = 4

WCET = 2 ms

C Rg_Lüfter_G

Period = 40 ms

Priority = 5

WCET = 1 ms

MO Temperatur

Direction = hw_to_sw

Type = Temperature_T

Protected = off

setze_temp

hole_temp

MO Kommando

Direction = sw_to_hw

Type = Kommando_T

Protected = off

setze_komm

hole_komm

AS Lüfter_Defekt

IRQ_Number = 12melde

S Alarm

Min_Interval = 100 ms

starte

ASER_BY_IT

H Kühler

H Prüfe_Lüfter

H Messe_Temp

Abbildung 2. Beispiel in HRT-HOOD+

3.1.2. Der UML-RTES-Ansatz Der UML-RTES-An-satz ist die Erweiterung einer Teilmenge der populärenUnified Modeling Language (UML) um spezielle Aspek-te der Hardware/Software-Schnittstellenmodellierung so-wie Realzeiteigenschaften. Konkret bedeutet dies die De-finition eines UML-Profils für Klassen-, Zustands- undKollaborationsdiagramme sowie HRT-HOOD+ nachemp-fundene Stereotypen und TaggedValues. Die Möglichkeitder Realzeitmodellierung wurde durch die Erweiterungdes UML-Metamodells um Zeit-Attribute für die relevan-ten Modellelemente erreicht. Durch die Einführung einesZeitmodells und Erweiterung der Object-Constraint Lan-guage um passende Zeittypen erlaubt UML-RTES die For-mulierung komplexer Zeitbedingungen (vgl. [2]). Die Ab-bildung 3 zeigt das bereits für HRT-HOOD+ gezeigte Bei-spiel einer Lüftungsregelung in UML-RTES-Notation1.

Die Systemgrenzen werden hier durch ein UML-Package mit dem Stereotyp System definiert. Die Objekt-

1 Die Abbildung zeigt aus Gründen der Übersichtlichkeit ein um De-tails aus dem hier nicht gezeigten Klassendiagramm angereichertesObjektdiagramm. In der Standard-UML werden in Objektdiagram-men Attribute und Operationen nicht gezeigt, da sie äquivalent zudenen des zugehörigen Klassendiagramms sind.

54

<<system>>

Prozessorlüftungsregelung

<<sw>>

Ü: Überwachung

{ Activation = Cyclic

Period = 20 ms

Priority = 4

WCET = 2 ms }

<<sw>>

RG: Rg_Lüfter_G

{ Activation = Cyclic

Period = 20 ms

Priority = 4

WCET = 2 ms }

<<hw_sw_sh_mem>>

IT: Temperatur

{ Direction = hw_to_sw

Type = Temperature_T

Protected = off }

+Setze_Temp()

+Hole_Temp()

<<hw_sw_sh_mem>>

KO: Kommando

{ Direction = sw_to_hw

Type = Kommando_T

Protected = off }

+Setze_Komm()

+Hole_Komm()

<<hw_sw_async_sig>>

MD: Lüfter_Defekt

{ IRQ_Number = 12

Min_Interval = 100 ms }

+Melde()

<<hw>>

K: Kühler

<<hw>>

MT: Messe_Temp

MT

<<hw>>

PL: Prüfe_Lüfter PL

MD

KO

IT

KO

IT

ITPL

<<

ow

ner>

>

<<owner>>

Abbildung 3. Beispiel in UML-RTES

typen der HRT-HOOD+-Objekte wurden durch entspre-chend definierte Stereotypen modelliert. Die speziellenEigenschaften, die in HRT-HOOD+ durch Objektattri-bute ausgedrückt werden, sind in UML-RTES durchTaggedValues modelliert. Diese sind den entsprechen-den Stereotypen zugeordnet. So besagt z.B. der Stereotyp“sw”, dass es sich um ein Softwareobjekt handelt, die nä-heren Eigenschaften werden durch TaggedValues ausge-drückt. Analoges gilt auch für die Interface-Objekte sowiefür die Hardware-Objekte.

3.2. Flexible objektbasierte Hardware/Software-Schnittstelle

Bereits auf der abstrakten Ebene werden in OOCOSIMwesentliche Aspekte des Hardware/Software-Interfacesmodelliert. Ein Beispiel für die Hardware/Software-Interface-Modellierung auf der Systemebene ist in Ab-bildung 4 gezeigt. In diesem ist die Hardware/Software-

C Rg_Lüfter_G

Period = 40 ms

Priority = 5

WCET = 1 ms

MO Kommando

Direction = sw_to_hw

Type = Kommando_T

Protected = off

setze_komm

hole_komm

AS Lüfter_Defekt

IRQ-Number = 12melde

S Alarm

Min_Interval = 100 ms

starte

ASER_BY_IT

H Kühler

H Prüfe_Lüfter

H Messe_Temp

Shared-Memory-Kommunikation

Methoden-Schnittstelle

Methodenaufruf-Richtung

Asynchronous-Signal-Kommunikation

Datenfluss-Richtung

Abbildung 4. Interface in HRT-HOOD+

Schnittstelle der bereits gezeigten Lüftungsregelungin HRT-HOOD+-Notation dargestellt. Das Memo-ry Object Kommando erlaubt die Shared-Memory-Kommunikation zwischen der HW-KomponenteKühlerund der SW-KomponenteRg_Lüfter_G. Die Kommunika-tion erfolgt über Methodenaufrufesetze_kommund ho-le_komm des ObjektsKommando. Die Richtung derAufrufe ist mit großen Pfeilen gekennzeichnet, die klei-

nen Pfeile mit Kreis zeigen die Richtung des Datenflus-ses. Die Kommunikationsrichtung des Memory Objectswird durch das AttributDirection definiert. Der Daten-typ der ausgetauschten Daten wird durch das AttributTypefestgelegt. Mit dem AttributProtectedwird festge-legt, ob der gegenseitige Ausschluss bei konkurrierendemSchreibzugriff vom Memory Object sichergestellt wer-den muss. Daher wurde im gezeigten Beispiel mit nureinem schreibenden ObjektProtected auf „off“ ge-setzt. Nachdem diese grundsätzlichen Eigenschaften derKommunikation definiert wurden, findet die weitere Ver-feinerung auf der Zwischenebene in der Sprache Co-miX statt. Diese werden dann auf einer Zwischenebenemit Hilfe der Sprache ComiX verfeinert und weiter detail-liert. Durch einen ComiX-basierten Codegenerator wer-den dann die Softwareanteile in die Sprache Ada95,sowie die Hardwareanteile in die Sprache VHDL über-setzt (siehe dazu Abbildung 5). Abbildung 6 zeigt eine

Code (VHDL)Kommunikations−

Code (Ada95)Kommunikations−

Hardware−ObjekteSoftware−Objekte Interface−Objekte

HW−Modell (VHDL)SW−Modell (Ada95)

Sim−Code (VHDL)Kommunikations−

Sim−Code (Ada95)Kommunikations−

Zielsystem

SoftwareZielsystem

Hardware

ComiX

Abbildung 5. Interface-Modellierung in OOCOSIM

ComiX-Beschreibung nebst einer schematischen Dar-stellung des korrespondierenden Speichers. Modelliertwird dabei die Repräsentation des Kommando-Objekts(vgl. Abbildung 4). Dieses liegt an der Startadresse Ok-

8#111#

8#100#

0 7

<!DOCTYPE ComiX SYSTEM “ComiX.dtd”>

<ComiX name = “Prozessorlüftungsregelung”>

<architecture

name = “Prozessorlüftungsregelung_A”unitbase = “8” alignment = “byte”

startaddress = “8#100#” count = “8#12” />

<declaration>

<enumeration name = “Kontroll_T” size = “4”>

<item name = “ON” use = “2#0001#” />

<item name = “OFF” use = “2#0010#” />

<item name = “UP” use = “2#0100#” />

<item name = “DOWN” use = “2#1000#” />

</enumeration>

< record name = “Kommando_T”>

<component name = “Kontroll” type = “Kontroll_T”>

<representation at = “0” range = “0..3” />

</component>

</record>

</declaration>

<registerset name = “Kühler”>

<register address = “8#111#” type = “Kommando_T”

name = “Kommando”>

</register>

</registerset>

</ComiX>

Kommando

Abbildung 6. Interface in Comix

tal 111 im Speicher und ist durch den TypKommando_Tals Register eines Registersatzes modelliert. Der TypKommando_Tist ein Record-Typ der als einzige Kompo-nente, die KomponenteKontroll_T besitzt. Diese ist alsAufzählungstyp definiert, deren Repräsentation der ein-zelnen Werte in One-Hot-Codierung angegeben ist.Zusätzlich sind noch einige übergeordnete Informatio-nen zur modellierten Hardware/Software-Schnittstelle

55

wie z.B. die Startadresse der gesamten Schnittstel-le und die Anzahl der Adressen in Oktal-Darstellungangegeben.

3.3. Hardware/Software-Cosimulation

Das zugrundeliegende Prinzip der Cosimulation (sie-he Abbildung 7) ist es, eine zeitsynchrone Cosimulationder Software- und Hardwarekomponenten zu ermögli-chen. Dazu muss eine gemeinsame Uhr eingeführt werdenund die Soft- und Hardware events in einer gemeinsa-men event queue verwaltet. Als Prämisse ergibt sich, dassauf beiden Seiten jeweils entsprechend gewartet wird. Be-sonders schwierig ist dabei der Umgang mit asynchronenHardware events, die zu beliebigen Zeitpunkten auftre-ten können und dann bevorzugt behandelt werden müssen.Hinzu kommt, dass die Cosimulation möglichst effi-zient ausführbar sein muss.

Es ergibt sich folgende Architektur: Eine Simulations-bibliothek stellt die Simulationsmechanismen zur Verfü-gung und wird auf der Softwareseite vom Cosimulations-kern in Ada95 genutzt und auf der Hardwareseite vomCosimulationskern in VHDL. Die Kommunikation fin-det dabei über Inter-Prozeß-Kommunikation statt. WeitereAspekte der Cosimulation wurden in der Zeitschrift it+tiveröffentlicht (vgl. [5]).

ProzessCSt

TaskB

TaskAC

TaskCC

ProzessBL

ProzessASt

Pr

... ...

Ts

Ts

Ts

Ts

Th

Th

Ts

Ts

Th

H

S

H

S

S

H

Th

Th

Th2

1

1

2

3

3

S

S

S

1

2

3

1

2

3

1

1

2

2

3

3

1

2

3

H

H

H

1

2

3

Hardware−Events

System−Events

Software−EventsEvent Zeit

Hardware−ModellSoftware−Modell

Abbildung 7. Prinzip der Cosimulation

4. Prototypische Werkzeuge

Im Rahmen einer Diplomarbeit wurde bereits ein ersterPrototyp eines Werkzeuges konzipiert und implementiert,das auf den in OOCOSIM geschaffene Grundlagen ba-siert. Später wurde dieser Ansatz im Rahmen eines zwei-jährigen institutsinternen Projektes weiterentwickelt. AmEnde stand dann der schon recht reife Werkzeug-PrototypDESHICO (siehe Abb. 8), der die grafische Definition undAufteilung des Speichers über Drag and Drop unterstütztund auch die Codegenerierung implementiert, zur Verfü-gung. DESHICO wurde unter anderem auf dem Universi-ty Booth der Date 2001 präsentiert.

Abbildung 8. Werkzeug-Prototyp DESHICO

5. Ausblick

Auch nach Ende des Projekts OOCOSIM gehen un-sere Arbeiten in diesem Bereich weiter. Die Erweite-rung der Hardware/Software-Schnittstellenmodellierungum komplexere, protokollbasierte Kommunikationsme-chanismen ist geplant. Desweiteren soll die Entwurfsqua-lität durch automatisierte Nachweisverfahren, z.B. zurErkennung von Deadlocks und Memory-Leaks, weiter ge-steigert werden.

Literatur

[1] BURNS, A. und A. WELLINGS: HRT-HOOD A StructuredDesign Method for Hard Real-Time Systems. Elsevier, 1995.

[2] K ERSTEN, MICHAEL, RAMON BINIASCH, WOLFGANG

NEBEL und FRANK OPPENHEIMER: Die Erweiterung derUML um Zeitannotationen zur Analyse des Zeitverhaltensreaktiver Systeme. In: DRECHSLER, R. undOTHERS(Her-ausgeber):GI/ITG/GMM Workshop 2003, Seiten 11–20,Bremen, Februar 2003. Shaker Verlag.

[3] M ORRIS, D., D. G. EVAMS und P. N. GREEN: An Integra-ted A]pproach to Engineering Computer Systems. UMIST,Machester, UK, 1995.

[4] NEBEL, WOLFGANG, MARTIN RADETZKI , FRANK OP-PENHEIMER, GUIDO SCHUMACHER, LAILA KABOUS undWOLFRAM PUTZKE-RÖMING: Object-oriented specificati-on and design of embedded hard real-time systems. In: 16thIFIP World Congress, Seiten 504–515, 2000.

[5] OPPENHEIMER, FRANK, GUIDO SCHUMACHER undWOLFGANG NEBEL: OOCOSIM - objektorientierte Spezi-fikation und Simulation eingebetteter Realzeitsysteme. it+ti,41(2), 1999. Schwerpunktthema: Entwurfsmethoden für ein-gebettete Systeme.

[6] OPPENHEIMER, FRANK, DONGMING ZHANG und WOLF-GANG NEBEL: Modelling Communication Interfaces withComiX. In: CRAEYNEST, DIRK und ALFRED STROHMEIER

(Herausgeber):Proceedings of the 6th International Confe-rence on Reliable Software Technologies - Ada-Europe 2001,Band 2043 der ReiheLecture Notes in Computer Science,Seiten 337–348. Springer, Mai 14-18, 2001.

[7] RÖMING, WOLFRAM PUTZKE: Durchgängiges Kommu-nikationsdesign für den strukturalen, objektorientiertenHardware-Entwurf. Doktorarbeit, Universität Oldenburg,April 2001.

[8] RUMBAUGH, J.:OMT: The Object Model. Journal of ObjectOriented Programming, Januar 1995.

56

Abschlussbericht DFG-Schwerpunktprogramm 1040: Entwurf und ... · Überblick über das...

Documents

Transcript of Abschlussbericht DFG-Schwerpunktprogramm 1040: Entwurf und ... · Überblick über das...