Diplomarbeit BCool

Technische Universitt Ilmenau Fakultt fr Informatik und Automatisierung Institut fr Theoretische und Technische Informatik Fachgebiet Rechnerarchitekturen
Diplomarbeit
Architekturoptimierungen von heterogenen Plattformen

Vorgelegt von:
Benjamin Cool
Verantwortlicher Professor: Prof. Dr.-Ing. habil. Wolfgang Fengler Hochschulbetreuer: Dr.-Ing. Alexander Pacholik Studiengang: Diplom-Informatik M03 Matrikel-Nr.: 36490 Inventarisierungsnummer: 2011-05-02/035/IN03/2231 Eingereicht: Ilmenau, den 30. Juni 2011
- 2011-05-02/035/IN03/2231
Zusammenfassung
Der Entwurf von eingebetteten Systemen die aus Hardware- und Softwarekomponenten bestehen, sogenannten Hardware/Software-Systemen verlangt die Optimierung verschiedener Parameter wie Kosten und Rechenzeit. Die zu entwickelnden Schaltungen sollen genug Rechenleistung besitzen um die Softwarekomponenten schnell genug abzuarbeiten, aber nicht zu viel um den Energieverbrauch zu minimieren. Gleichzeitig sollen die Schaltungen gnstig sein, um die Preise fr die Systeme bezahlbar zu halten. Ein Entwurf so eines Systems von Hand ist sehr aufwndig und die Zahl mglicher Systeme sehr gro, was eine automatisierte Lsung nahelegt. Die Systemsynthese ist ein solches Verfahren zur automatisierten Generierung von Hardware/Software-Systemen. Ein Schritt der Systemsynthese ist die Abbildung von Softwarekomponenten auf Hardwarekomponenten unter Bercksichtigung von Randbedingungen und unter Optimierung von gegebenen Bedingungen. Dieser Mapping Schritt wird als Ausgangspunkt fr diese Arbeit verwendet. Ziel dieser Arbeit ist die Konzeption und Implementierung eines modularen Synthesetools, dass es ermglicht die verwendeten Optimierungsalgorithmen einfach auszutauschen und die Modelleigenschaften leicht auswechselbar zu machen. Als Modell wird hierfr der im Fachgebiet entwickelte ArchitectureMapGraph verwendet und um Hierarchieebenen und ein Eigenschaftskonzept erweitert. Das Eigenschaftskonzept ermglicht eine detaillierte Beschreibung der Operationen, Ausfhrungs- und Kommunikationsressourcen. Mit Hilfe dieses Konzepts knnen spezielle Abhngigkeiten z.B. von unterschiedlichen Befehlsstzen der Ausfhrungseinheiten sowie messbare Parameter wie Ausfhrungszeiten beschrieben. Das eigentliche Mapping ndet mit Hilfe eines evolutionren Algorithmus statt, mit dem Ziel fr ein gegebenes Programm eine optimale Hardwareplattform auszuwhlen. Zur Evaluierung der Ergebnisse der Arbeit werden Mappings fr einen komplexen Regler erstellt und mit Lsungen aus [Kon10] verglichen.
ii
2011-05-02/035/IN03/2231 -
Abstract
The design of embedded systems requires the optimization of several parameters like costs and computing time. The system should have enough computing power to compute the given software components but not too much in order to minimize the power consumption and prize. The manual design of such systems is complex and thus time-consuming which necessitates the an automated approach. System synthesis is such an approach. One step in the system synthesis is the mapping of software components to hardware components in due consideration of specic constraints and parameter optimization. This mapping is the starting point of this thesis. The goal is the design and implementation of an modular synthesis tool with exchangeable optimization algorithms and system properties. The computation model is the ArchitectureMapGraph, a graph framework developed in the department. In order to t the requirements of this thesis the model was extended with a hierarchy concept and system properties. The system properties oer a concept for a more detailed description of operations, communicationand execution resources like specic instruction sets and execution times. For the mapping step an evolutionary algorithm is used which selects a specic hardware platform for a specic problem. For the evaluation the results of this thesis are compared to results of [Kon10].
iii
Inhaltsverzeichnis
1 Einleitung 1.1 1.2 1.3 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 2 2 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 4 7 7 8 8 11 13 14 17 22 22 23 24 24 25 25 25 28 31
2 Grundlagen 2.1 Systemsynthese . . . . . . 2.1.1 Allgemein . . . . . 2.1.2 Modelle . . . . . . 2.1.3 Synthese . . . . . . 2.1.4 Systemoptimierung
2.2
Optimierung . . . . . . . . . . . . 2.2.1 Denitionen . . . . . . . . 2.2.2 Problembeispiele . . . . . 2.2.3 Strategieelemente . . . . . 2.2.4 Verfahren . . . . . . . . . 2.2.5 Evolutionre Algorithmen Scheduling . . . . . . . . . 2.3.1 Notation . . . . . . 2.3.2 Einzelmaschinen . 2.3.3 Parallele Maschinen 2.3.4 Komplexitt . . . . Entwurfssysteme . . . . . 2.4.1 Grundlagen . . . . 2.4.2 Frameworks . . . . 2.4.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
2.4
3 Konzeption 3.1 3.2
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.1 Problemgraph . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.2 Architekturgraph . . . . . . . . . . . . . . . . . . . . . . . . 33
iv 3.2.3 3.2.4 3.2.5 3.3
2011-05-02/035/IN03/2231 - Inhaltsverzeichnis Speicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . 33 Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . 34 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 36 36 37 37
Systemsynthese . 3.3.1 bersicht 3.3.2 Kodierung 3.3.3 Scheduling 3.3.4 Bewertung
3.4
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 39 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 39 40 40 42 42 44 44 45 45 46 46 46 47 47
4 Implementierung 4.1 Softwareumgebung . . . . . . . . . 4.1.1 Eclipse Rich Client Platform 4.1.2 Eclipse Modeling Framework 4.1.3 Implementierung von PISA Modelle . . . . . . . . 4.2.1 Hierarchisierung 4.2.2 Projektstruktur 4.2.3 Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
4.3
Mapping . . . . . . . . . . . 4.3.1 Elementidentikation 4.3.2 Problemkodierung . 4.3.3 Kommunikation . . . 4.3.4 Hierarchie . . . . . . 4.3.5 Scheduling . . . . . . 4.3.6 Individuen . . . . . .
4.4
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 49
5 Evaluation 5.1 5.2
Vergleich zu einem Partitionierungsbeispiel . . . . . . . . . . . . . . 49 Parameterkonguration . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.2.1 Paramter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.2.2 Startpopulation . . . . . . . . . . . . . . . . . . . . . . . . . 51 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 53 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 54 54 54
5.3
6 Zusammenfassung und Ausblick 6.1 6.2 Ausblick . . . . . . . . . . . . 6.2.1 Eigenschaften . . . . . 6.2.2 Scheduling . . . . . . . 6.2.3 Informationskodierung
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Inhaltsverzeichnis - 2011-05-02/035/IN03/2231 6.2.4
Parallelitt . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Anhang 57 A Abbildungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Literaturverzeichnis 64
vi
KAPITEL 1
Einleitung
Der Entwurf von eingebetteten Systemen die aus Hardware- und Softwarekomponenten bestehen, sogenannten Hardware/Software-Systemen verlangt die Optimierung verschiedener Parameter wie Kosten und Rechenzeit. Die zu entwickelnden Schaltungen sollen genug Rechenleistung besitzen um die Softwarekomponenten schnell genug abzuarbeiten, aber nicht zu viel um den Energieverbrauch zu minimieren. Gleichzeitig sollen die Schaltungen gnstig sein, um die Preise fr die Systeme bezahlbar zu halten. Ein Entwurf so eines Systems von Hand ist sehr aufwndig und die Zahl mglicher Systeme sehr gro, was eine automatisierte Lsung nahelegt. Neben simulationsbasierten Verfahren ist die modellbasierte Systemsynthese nach [TH07] ist ein Verfahren fr eine solche automatisierte Schaltungssynthese. Ein Schritt der Systemsynthese ist die Abbildung von Softwarekomponenten auf Hardwarekomponenten. Im Folgenden wird zuerst die Aufgabenstellung erlutert und daraus Zielstellungen abgeleitet. Abschlieend wird kurz auf die Struktur der Arbeit eingegangen.
1.1
Aufgabenstellung
Ziel dieser Arbeit ist die Konzeption und Implementierung einer Anwendung zur Architekturoptimierung von heterogenen Plattformen. Hierfr wird zunchst eine Literaturrecherche fr die thematischen Grundlagen sowie die vorhandenen Frameworks durchgefhrt. Darauf aufbauend wird ein Konzept fr ein Mapping Framework erarbeitet und in die aktuellen Arbeiten des Fachgebiets integriert. Abschlieend soll eine Realisierung des Konzept in Form einer prototypischen Implementierung erfolgen.
2011-05-02/035/IN03/2231 - Kapitel 1. Einleitung
1.2
Zielstellung
Als Modell fr diese Arbeit wird der ArchitectureMapGraph verwendet. Fr die Systemsynthese ist es dabei erforderlich, dass dieses Modell um Hierarchieebenen und ein Eigenschaftskonzept erweitert wird. Dabei soll das Eigenschaftskonzept variabel sein um Modikationen und Erweiterungen einfach durchfhren zu knnen. Das Mapping im Rahmen der Systemsynthese ist ein Optimierungsproblem deren Zielgren z.B. Kosten und Ausfhrungszeit der Schaltung sind. Da der Suchraum des Mappings sehr gro ist und je nach Problemstellung unterschiedliche Anforderungen an die Optimierung stellt, soll der verwendete Suchalgorithmus leicht auswechselbar sein. Die Optimierung selbst soll mit Hilfe eines evolutionren Algorithmus durchgefhrt werden.
1.3
Struktur der Arbeit
Die Arbeit gliedert sich in sechs Kapitel. Nach der Einfhrung in Kapitel 1 folgen in Kapitel 2 die Grundlagen der Systemsynthese, der Optimierung und des Scheduling sowie eine Recherche vorhandener Frameworks in Abschnitt 2.4. In Kapitel 3 wird ein Mapping Konzept fr eine modulare Mapping Anwendung erarbeitet, dass in Kapitel 4 als Prototyp implementiert wird. Anschlieend werden die generierten Lsungen in Kapitel 5 mit den Ergebnissen der Arbeit [Kon10] verglichen in denen ein Scheduling fr eine festgelegte Hardwareplattform berechnet wird. Abschlieend werden in Kapitel 6 die Ergebnisse der Arbeit zusammengefasst und ein Ausblick fr zuknftige Entwicklungen gegeben.
KAPITEL 2
Grundlagen
Im Fachgebiet Rechnerarchitekturen wird im Rahmen des Sonderforschungsbereichs 622 ein Reglersystem zur Steuerung verwendet. Eine Abbildung des Reglersystems in Simulink ist im Anhang Abb. A.1 dargestellt. Dieses Reglersystem wird zur Veranschaulichung der Vorgehensweise als durchgehendes Beispiel in dieser Arbeit verwendet. Dabei wird das Reglersystem zunchst, wie in Abb. 2.2 links zu sehen, in einer abstrakten Form verwendet und im Verlauf der Arbeit verfeinert. Fr das Ziel dieser Arbeit, ein Systemsynthesewerkzeug mit dem Fokus des Mapping von Programmen auf Architekturen zu erstellen werden in Abschnitt 2.1 zunchst grundlegende Begrie der Systemsynthese eingefhrt, bevor Abschnitt 2.2 auf die Grundlagen der mathematischen Optimierung und Abschnitt 2.3 eingeht. Abschlieend folgt in Abschnitt 2.4 eine bersicht und Bewertung der fr diese Arbeit in Betracht gezogenen Frameworks.
2.1
Systemsynthese
In dieser Arbeit wird der Begri Systemsynthese analog zu [TH07] verwendet. In Abschnitt 2.1.1 wird zunchst ein kurzer berblick der Systemsynthese gegeben. Anschlieend werden die verwendet Modelle Problemgraph, Architekturgraph und Spezikationsgraph deniert. Darauf aufbauend wird in Abschnitt 2.1.3 der eigentliche Syntheseschritt deniert indem ein Mapping des Anwendungsmodells auf das Architekturmodell stattndet, bevor in Abschnitt 2.1.4 auf die Optimierung des Mappings eingegangen wird.
2.1.1
Allgemein
In dieser Arbeit wird der Begri Systemsynthese analog zu der in [TH07] gegebenen Denition verwendet und beschreibt die Abbildung eines Anwendungsmodells auf ein Hardwaremodell. Abb. 2.1 stellt der Vorgang der Systemsynthese graphisch dar. Fr diese Arbeit relevant ist dabei der Schritt HW/SW-Partitionierung.
2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen
Hierbei werden die Spezikationen eines Anwendungsmodells mit dem eines Architekturmodells in einem Mapping verknpft. Eine Erluterung der Modelle ist in Abschnitt 2.1.2 gegeben. Ein solches Mapping wird mit Informationen zu den Laufzeiteigenschaften der Anwendung auf der Architektur verknpft um daraus Performanzinformationen zu gewinnen. Der zentrale Kern bestehend aus Mapping, Bibliothek und Performanzanalyse stellt die sogenannte Entwurfsraumexploration dar. Sie beschreibt die zyklische Generierung von Lsungen die unter gegebenen Bedingungen optimiert werden sollen. Der Schritt des Mapping, also die Synthese auf Anwendungsmodell und Architekturmodell, hier als Synthese bezeichnet, wird in [TH07] auch als Implementierung bezeichnet.
Abbildung 2.1: berblick: Systemsynthese (nach [TH07])
2.1.2
Modelle
Fr die Systemsynthese sind drei Modelle von zentraler Bedeutung. Basierend auf den Modellen der Anwendung und der Architektur wird eine Spezikation erzeugt. Anwendung. Die Anwendung wird als gegeben vorausgesetzt. Dabei erfolgt die Reprsentation der Anwendung in Form eines Datenussgraphen. Ein Beispiel fr einen solchen Graphen zeigt Abb. 2.2 auf der linken Seiten, benannt als Gp . Ein solcher Anwendungsgraph wird im folgenden als Problemgraph bezeichnet.
2.1. Systemsynthese - 2011-05-02/035/IN03/2231
Architektur. Die zu verwendete Architektur wird ebenfalls vorausgesetzt. Berechnungskomponenten und Kommunikationskomponenten werden dabei getrennt modelliert und ihre mglichen Verbindungen als Kanten im entstehenden Graphen dargestellt. Ein Beispiel fr einen solchen Graphen zeigt Abb. 2.2 auf der rechten Seite benannt als Ga . Ein solcher Graph wird im folgenden als Architekturgraph bezeichnet.
Mapping. In [TH07] wird ein Modell zur Systemsynthese beschrieben das, wie in Abb. 2.2 gezeigt, aus vier Komponenten besteht. Die erste Komponente ist ein Problemgraph Gp (Vp , Ep ) der eine systemunabhngige Graphdarstellung eines Programms enthlt. Die Knotenmenge Vp enthlt alle Operationen des Programms und jede Kante e Ep stellt eine Datenabhngigkeit zwischen zwei Operationen dar. Die zweite Komponente ist ein Architekturgraph Ga (Va , Ea ) der Graphdarstellung der zur Verfgung stehenden Hardwarekomponenten. Die Knotenmenge Vp enthlt alle Hardwarekomponenten (Prozessoren, FPGAs, Busse, ...) und die Kanten e Ep stellen die mglichen Kommunikationsverbindungen zwischen zwei Komponenten dar. Die dritte Komponente ist eine Kantenmenge Em die den Problemgraphen auf den Architekturgraphen abbildet. Dabei beschreiben die Kanten e Em alle potentiell mglichen Abbildungen. Somit stellt diese Menge den maximalen Suchraum bei der Ermittlung von mglichen Implementierungen dar. Die vierte Komponente ist eine Menge von Aktivierungsattributen a : Vs Es 0, 1 zur Kennzeichnung einer speziellen Implementierung. Somit ist es mglich die Suche nach einer Implementierung als Attributsverteilung zur Erfllung von Optimalittskriterien aufzufassen. Zusammen bilden diese vier Komponenten einen Spezikationsgraphen Gs (Vs , Es ) fr den gilt Vs = Vp Va und Es = Ep Ea Em in dem jeder Knoten und jede Kante ein Aktivierungsattribut besitzt. Abb. 2.2 zeigt den Spezikationsgraphen Gs des Reglersystems. In [TH07] und [TTRE02] wird auerdem ein Konzept vorgestellt um einen Spezikationsgraphen mit Hierarchieebenen auszustatten. Dazu werden sogenannte Cluster (I, O, V, E, ) deniert der einen gerichteten Graphen G = (VG , EG ) enthlt und V und eine Bipartition ber die Menge VG denieren und E der Kantenmenge EG entspricht. I ist die Menge der Eingangsports, O die Menge der Ausgangsports, V die Menge der nicht hierarchischen Knoten (Bltter), E (I {IV I }) (OV {IV I }) (O {IV O}) (OV O) und die Menge der hierarchischen Knoten (Interfaces). Ein Interface (I, O, , ) enthlt I als Menge der Eingangsports, O als Menge der Ausgangsports, als Menge der zu assoziierten Cluster und : I O I O stellt das Portmapping dar.
Abbildung 2.2: Spezikationsgraph des Reglers
Mit Hilfe der Hierarchieebenen lassen sich Verfeinerungen bzw. Abstraktionen und Alternativen modellieren. Verfeinerungen erlauben es Probleme auf verschiedenen Abstraktionsniveaus zu modellieren um sie bei Bedarf abstrakter bzw. konkreter zu betrachten. Der Knoten V2b im Problemgraphen wird nun nicht mehr als einfacher Knoten, sondern als Interface 2b interpretiert. Dieses Interface ist Teil des neuen Clusters 2b das zur Modellierung genutzt wird. Abbildung 2.3 zeigt den Graphen G2b inklusive der Ports I2b und O2b zur Kommunikation mit dem einbettenden Graphen dargestellt.
Abbildung 2.3: Verfeinerung des Knotens V2b
2.1.3
Synthese
Gem [TH07] setzt sich eine Implementierung aus Allokation, Bindung und Ablaufplanung zusammen. Eine Allokation ist eine Teilmenge der aktivierten Knoten und Kanten des Spezikationsgraphen die nicht Teil der Abbildungskantenmenge = v e mit v = {v Vs |a(v) = 1} und e = {e Ep Ea |a(e) = 1} sind. Eine Bindung ist eine Teilmenge der aktivierten Abbildungskantenmenge = {e Em |a(e) = 1}. Ein Ablaufplan ordnet jedem Knoten des Problemgraphen eine Startzeit : Vp Z+ zu. Fr die Denition der Gltigkeit sowie des Be0 weises der NP-vollstndigkeit des Entscheidungsproblems GLTIGE BINDUNG sei auf [TH07] verwiesen, da diese ber den Fokus dieser Arbeit hinausgehen.
2.1.4
Systemoptimierung
Das Optimierungsproblem der Systemsynthese kann verstanden werden als Kombination der Menge gltiger Implementierungen beschrieben durch die Funktion f (, , ) mit zustzlichen Beschrnkungen beschrieben durch die Funktion g(, , ). Das Problem der Systemsynthese ist im Allgemeinen ein Mehrzieloptimierungsproblem der Funktion f = (f1 , ..., fm ), d.h. m > 1 Ziele sollen gleichzeitig optimiert werden. Die Ziele der Optimierung lassen sich wie in [Gri04] beschrieben in primre und sekundre Kriterien einteilen. Primre Ziele resultieren aus konkreten Eigenschaften des Gesamtsystems wie z.B. monetre Kosten, Leistungsverbrauch oder Verarbeitungsgeschwindigkeit. Sekundre Ziele leiten sich von bestimmten Teilen des Gesamtsystems ab oder beruhen auf domnenspezischen Faktoren wie z.B. Ressourcenauslastung, Zuverlssigkeit oder physikalische Gre. Im Allgemeinen sind die Ziele der Optimierung nicht voneinander unabhngig, so dass zur Verbesserung der Lsung im Hinblick auf ein bestimmtes Ziel, eine Verschlechterung in anderen Zielen entsteht. Darum gibt es bei Mehrzieloptimierungsproblemen mehrere mgliche Lsungen, sogenannte Pareto-optimale Lsungen oder Pareto Punkte. Diese Lsungen zeichnen sich dadurch aus, dass keine ihrer Zielgren verbessert werden kann ohne dadurch eine andere Zielgre zu verschlechtern. Abb. 2.4 zeigt den Lsungsraum der durch zwei unabhngige Zielfunktionen f1 und f2 aufgespannt wird inklusive der Pareto Punkte.
Abbildung 2.4: Lsungsraum mit Pareto Punkten
2.2
Optimierung
Optimierung beschftigt sich mit der Suche eines optimalen Funktionswertes einer gegebenen Inputmenge. Einfhrungen aus dem Bereich der Evolutionren Algorithmen nden sich in [GKK04] und [Wei02]. Der erste Schritt der Optimierung besteht in der mathematischen Darstellung des gegebenen Problems. Dazu werden drei Komponenten bentigt. Die erste ist die Formulierung einer Menge von potentiellen Lsungen. Dieser wird im Folgenden als Suchraum S bezeichnet. Die zweite Komponente ist eine Bewertungsfunktion f die jedem s S eine Bewertung zuordnet. Auerdem wird ein Vergleichsoperator bentigt, der eine Vergleichbarkeit der Bewertungen ermglicht. Im folgenden wird kurz auf Optimierungsprobleme eingegangen und anschlieend werden einige ausgewhlte Optimierungsverfahren kurz erlutert.
2.2.1
Denitionen
Optimierungsprobleme werden blicherweise als Menge Lsungen S, sowie einer Bewertung f (s) R die jedem s S eine Bewertung zuordnet. Durch die Abbildung in die reellen Zahlen ist der Vergleichsoperator implizit durch die Ordnung der reellen Zahlen gegeben. 2.2.1.1 Mehrkriterienoptimierung Falls das gegebene Problem mehr als ein Optimierungskriterium hat ist es jedoch ntig sich weitere Gedanken ber die Bewertungsfunktion zu machen. Allgemein ist es sinnvoll bei Verwendung von n Optimierungskriterien die Bewertungsfunkti-
2.2. Optimierung - 2011-05-02/035/IN03/2231
on wie folgt zu formulieren: f (s) Rn . Um Lsungen im Rn zu ordnen gibt es zwei prinzipielle Anstze. Der erste Ansatz basiert auf einer Gewichtungsfunktion g die den einzelnen Kriterien Gewichte zuordnet, so dass sich eine neue Bewertungsfunktion z.B. als f (s) = n wi fi (s) formulieren lsst. Natrlich lassen sich auf i=1 komplexere Beziehungen sowohl zwischen den einzelnen fi als bei der Verknpfung mit den einzelnen wi abbilden. Wesentlich dabei ist lediglich die Zielabbildung in R um eine Vergleichbarkeit der Elemente zu ermglichen. Eine solche explizite Bewertung ist i.A. jedoch oft nur unter groem Aufwand zu realisieren, so dass hug auf den zweiten Ansatz ausgewichen wird. Dieser Ansatz besteht in der Angabe sogenannter pareto optimaler Lsungen. Eine Lsung s0 S heit pareto optimal, falls sie von keiner anderen Lsung s1 S echt dominiert wird. Man sagt, eine Lsung s1 dominiert eine Lsung s0 wenn s1 in keinem Kriterium eine schlechtere Bewertung als s0 hat. Wenn s1 s0 dominiert und in mindestens einem Kriterium eine bessere Bewertung hat, dann wird s0 von s1 echt dominiert. Die Menge aller pareto optimalen Lsungen wird im Folgenden als Pareto-Menge bezeichnet.
2.2.1.2 Klassizierung Optimierungsverfahren lassen sich nach vielen Kriterien einteilen, wobei dieser Arbeit die Einteilung in Abb. 2.5 verwendet wird. Eine kurze Beschreibung der Funktionsweise der genannten Verfahren ndet sich in Abschnitt 2.2.4.
Abbildung 2.5: Klassizeirung von Optimierungsverfahren Zunchst wird hierbei zwischen exakten Lsungsverfahren und Heuristiken unterschieden. Exakte Lsungsverfahren liefern nach ihrem Ablauf immer das Optimum
10
(sofern eines existiert), allerdings haben diese Verfahren relativ strenge Anforderungen an die Zielfunktion (z.B. stetige Dierenzierbarkeit). Falls diese Anforderungen nicht erfllt werden gibt es die Mglichkeit sogenannte Heuristiken einzusetzen. Diese ermglichen bestehende Lsungen zu verbessern, sind bereits nach kurzer Zeit in der Lage akzeptable Lsungen zu liefern und knnen fr nahezu beliebige Probleme eingesetzt werden. Der Nachteil dieser Verfahren besteht darin, das sie nicht garantieren das Optimum zu nden. Selbst wenn man es schat die Zielfunktion bei der Systemsynthese so zu gestalten, dass sie sich exakt lsen lsst, besteht das Problem, dass der Lsungsraum bei der Systemsynthese so gro ist, dass es sich nicht lohnt ihn erschpfend zu durchsuchen. Aus praktischen Gesichtspunkten ist es deshalb sinnvoll zur Auswertung der Zielfunktion eine Heuristik zu verwenden. Bei den Heuristiken kann man zwischen klassischen und naturanalogen Verfahren unterscheiden. Dabei liegt der Unterschied nicht explizit in den Eigenschaften der Funktionen, sondern in ihrer Entstehung. Naturanaloge Verfahren haben einen natrlichen Vorgang als Abbild. Diese Verfahren haben zwar ganz allgemein das Problem, dass sie extrem rechenaufwendig sind und die Gte der Lsung auch von der gewhlten Startposition abhngt, dafr sind sie extrem robust und hochgradig parallelisierbar. Zu den klassischen Heuristiken gehren z.B. sogenannte Greedy Algorithmen. Diese Algorithmen zeichnen sich ganz Allgemein dadurch aus, dass sie in jedem Schritt grtmglichen Gewinn machen. Sie haben den Vorteil, dass sie extrem schnell gegen ein Optimum konvergieren, ihr Nachteil besteht jedoch darin, dass sie lokalen Optima quasi nicht entkommen knnen. Die weiter betrachteten Verfahren stammen alle aus dem Bereich der naturanalogen Verfahren, da die klassischen im Allgemeinen zu problemspezisch sind. Die letzte Klasse von Methoden sind die sogenannten Metaheuristiken. Als Beispiel sei hier die Tabu Suche erwhnt. Da dieses Verfahren darauf beruht, dass verschiedene Heuristiken zur Suche von Optima miteinander kombiniert werden hngt eine Beurteilung der Eigenschaften stark von den verwendeten Verfahren ab. Durch die Kombination verschiedener Algorithmen ist die Tabu Suche jedoch weniger anfllig fr die Konvergenz zu lokalen Optima. Ein weiteres Kriterium das in Abb. 2.5 aus Platzgrnden nicht aufgenommen wurde ist die Verwendung von Zufallselementen. Das schliet allerdings die Verwendung von zuflligen Startpositionen nicht mit ein, sondern bezieht sich nur auf die Verwendung von Zufallselementen whrend der Laufzeit des Algorithmus. Eine Verwendung von zuflligen Startpositionen ist bei allen Algorithmen mglich, jedoch liefern gute Startpositionen in vielen Fllen deutlich krzere Laufzeiten. Verfah-
2.2. Optimierung - 2011-05-02/035/IN03/2231
11
ren die Zufallselemente verwenden werden probabilistisch genannt und verwenden diese Elemente in den meisten Fllen dazu die Suchraum nicht nur lokal bei den Startpositionen zu durchsuchen, sondern neue Positionen im Suchraum zu nden in denen sich eine Suche ebenfalls lohnen knnte. Allgemein werden Zufallselemente hug dafr eingesetzt um lokalen Optima zu entkommen. Verfahren die keine Zufallselemente enthalten heien deterministisch und liefern bei identischer Eingabe auf eine identische Ausgabe. Der Vorteil dieser Verfahren liegt in ihrer extrem guten Vorhersagbarkeit und der fehlenden Abhngigkeit zu einem Zufallsgenerator. Generatoren fr Zufallszahlen knnen die Suche massiv verschlechtern, wenn sie statt gleichmig verteilten Zufallszahlen bestimmte Zahlbereiche bevorzugen und somit die Suche in eine bestimmte Richtung drngen. Die hier beschriebenen naturanalogen Verfahren verwenden alle probabilistische Elemente. Optimierungsverfahren lassen sich auch an Hand der Eigenschaften des Suchraums einteilen. Falls der Suchraum auf ganzzahlige Elemente beschrnkt wird, dann spricht man auch von einem kombinatorischen Optimierungsproblem. Da es sich bei der Systemsynthese um ein solches kombinatorisches Optimierungsproblem handelt, sind die vorgestellten Verfahren aus genau diesem Bereich. Die einzige Ausnahme bildet hier die Lineare Programmierung. Der Simplex Algorithmus als klassisches Verfahren der Linearen Programmierung verlangt jedoch einen konvexen Suchraum, was bei ganzzahligen Variablen nicht gegeben ist. Fr weitere Informationen zu diesem Thema sei auf [KV08] oder [DS06] verwiesen.
2.2.2
Problembeispiele
Die fr die Systemsynthese betrachteten Probleme des Mapping und des Scheduling gehren zum Bereich der kombinatorischen Optimierung. Um Lsungsverfahren fr die Probleme oder zumindest Teilprobleme zu nden ist es sinnvoll zunchst einige allgemeine Probleme zu betrachten. Dazu werden im Folgenden die Probleme SHORTEST PATH, BIN PACKING sowie BIPARTITE MATCHING vorgestellt. 2.2.2.1 SHORTEST PATH SHORTEST PATH (SP) ist ein Problem aus der Graphentheorie und beschreibt die Suche nach einem krzesten Weg zwischen zwei Knoten eines Graphen. Gegeben ist ein gewichteter Graph G = (V, E) mit V als Menge aller Knoten und E als Menge aller Kanten. Gesucht ist der krzeste Weg zwischen zwei beliebigen Knoten v1, v2 V . SP ist ein Problem der kombinatorischen Optimierung, da Knoten nicht teilweise im Weg enthalten sein knnen. Es ist im Sinne der
12
Abbildung 2.6: Abstrakter Beispielgraph Komplexittstheorie [HMU02] ein ezient zu lsendes Problem und kann z.B. mit Hilfe des Dijkstra Algorithmus [Zim08] exakt gelst werden. Je nach exakter Formulierung des Problems oder Gre des Netzwerks kann es jedoch auch Sinn machen eine Heuristik wie z.B. den A* Algorithmus [LC08] zu verwenden. In dieser Arbeit ist es von Bedeutung, da es zur Beurteilung der Gte eines Ablaufplans beim Scheduling bentigt wird. Programme werden oft als Graph dargestellt und der lngste krzeste Pfad in einer Anwendung ist der sogenannte kritische Pfad. Dieser Pfad gibt die Mindestlaufzeit des Programms an. Somit stellt sie die untere Schranke fr die Gte eines Scheduling Algorithmus dar.
2.2.2.2 BIPARTITE MATCHING BIPARTITE MATCHING (BM) ist hnlich wie SP ein Problem aus der Graphentheorie. Der Ausgangsgraph G = (V1 V2 , E) besteht dabei aus zwei disjunkten Knotenmenge und der Kantenmenge E V1 xV2 . Ein solcher Graph heit auch bipartiter Graph. Gesucht wird ein Matching M E indem keine zwei Kanten einen gemeinsamen Knoten besitzen mit mglichst grer Kardinalitt. In [Bru01] wird gezeigt, dass sich bestimmte Scheduling Probleme auf BM reduzieren lassen.
2.2.2.3 BIN PACKING BIN PACKING (BP) ist das Problem n Objekte fester Gre in mglichst wenige Behlter gleicher Gre zu packen und wird z.B. in [KV08] beschrieben. Im Gegensatz zum SHORTEST PATH Problem handelt es sich hierbei jedoch um ein schwer zu lsendes Problem fr das es vermutlich keinen ezienten Lsungsalgorithmus gibt. Dafr handelt es sich hierbei um ein Problem fr das es ein voll-polynomielles asymptotisches Approximationsschema gibt. Da diese Betrachtungen jedoch ber den Fokus der Arbeit hinausgehen wird an dieser Stelle nicht weiter auf den Bereich der Komplexittstheorie und Approximationsschemata eingegangen.
2.2. Optimierung - 2011-05-02/035/IN03/2231 2.2.2.4 TRAVELING SALESPERSON PROBLEM
13
Das TRAVELING SALESPERSON PROBLEM (TSP) beschreibt das Problem, dass eine Person n Stdte mit unterschiedlichen Abstnden bereisen mchte und dabei die zurckgelegte Strecke minimal sein soll. Im Gegensatz zum BP ist es nur schwer zu approximieren, bietet aber mit seinen vielen Varianten ein sehr reiches Anwendungsgebiet wie in [App06] nachzulesen. Ein Ansatz zur Lsung des Problems mit Hilfe von Evolutionren Algorithmen bietet [Wei02].
2.2.3
Strategieelemente
Laut [GKK04] lassen sich folgende drei Strategieelemente fr heuristische Optimierungsverfahren identizieren: gezielte Suche Ziel ist es Lsungen zu verbessern anstatt vllig neue auszuwhlen, um mglichst schnell brauchbare Ergebnisse zu erhalten. Dies fhrt zu einer deutlichen Beschleunigung der Suche, hat allerdings den Nachteil, dass das Verfahren nur schlecht lokalen Optima entkommen kann. Zufallssuche Ziel ist es neue Lsungen auszuwhlen anstatt vorhandene zu verbessern. Dies ermglicht ein breites Abtasten des Suchraums und das Entkommen aus lokalen Optima. Allerdings sind die zufllig ausgewhlten Lsungen nicht unbedingt besser als die bereits gefundenen und eine Konvergenz zu einem Optimum kann deutlich lnger dauern. Informationsaustausch Ziel ist es ber die gesamte Laufzeit des Verfahrens Informationen ber den Suchraum nicht nur zu erzeugen, sondern aufzubewahren, um mit steigender Laufzeit bessere Lsungen erzeugen zu knnen. Dies ermglicht es Optima nicht nur zufllig zu entdecken, sondern den Suchraum systematisch zu durchsuchen. Diese Strategieelemente knnen als Kriterien herangezogen werden, um verschiedene Heuristiken zu beurteilen und zu vergleichen und bilden die Grundlage fr den Vergleich der Algorithmen in Abschnitt 2.2.4.
14
2.2.4
Verfahren
Im Folgenden werden fnf verschiedene Optimierungsverfahren vorgestellt, die jeweils unterschiedliche Zweige der Grak 2.5 reprsentieren. Abschlieend werden die Verfahren gegenber gestellt und bezglich ihrer Eignung fr die Systemsynthese beurteilt. 2.2.4.1 Mathematische Programmierung Mathematisches Programmieren ist der Sammelbegri fr eine ganze Reihe von Verfahren die aus dem Operations Research stammen. Alle Verfahren haben dabei zum Ziel eine Funktion f (x) mit den Nebenbedingungen gi (x){, =, }bi , i = 1,...,m einen optimalen Wert annimmt. Eine bersicht der Verfahren ndet sich in [Zim08]. Die Verfahren sind dabei streng mathematisch und haben hohe Anforderungen an die Zielfunktion. Falls alle Gleichungen linearer Natur sind, dann handelt es sich um ein Problem der Linearen Programmierung. Diese Gruppe ist besonders interessant, da es eziente Lsungsverfahren wie z.B. das Simplex Verfahren fr dieses Problem gibt. Da es sich bei der Systemsynthese um ein kombinatorisches Problem handelt sind Entscheidungsbaumverfahren wie das dynamische Programmieren von besonderem Interesse. Da diese jedoch verlangen dass f(x) monoton ist und die genaue Struktur des Suchraums der Systemsynthese nicht bekannt ist, scheint ein Einsatz dieser Verfahren wenig sinnvoll. Eine mgliche Lsung ist die Verwendung von Entscheidungsbaumverfahren aus dem Branch and Bound Bereich. Der Vorteil dieser Verfahren ist das denitive Aunden des globalen Optimums. Der Nachteil besteht jedoch in der vollstndigen Durchsuchung des Suchraums. Auf Grund der Gre des Suchraums sind Heuristiken zu bevorzugen. 2.2.4.2 Simulated Annealing Simulated Annealing (SA) ist ein Verfahren, dass auf den Eigenschaften von Teilchen beim Abkhlen beruht. Teilchen in einer Flssigkeit nehmen beim Abkhlen nicht immer die energetisch gnstigste Position ein. Handelt es sich bei der Flssigkeit um eine Metallschmelze, dann sind diese energetisch ungnstigen Positionen nicht erwnscht, da sie Fehler im Kristallgitter darstellen und somit das Ergebnis negativ beeinussen. Weitere Erluterungen hierzu sind z.B. in [GKK04] und [DT93] zu nden. Klassisch wird beim mit einem Startpunkt s0 begonnen und von diesem Punkt aus die Nachbarschaft ausgesucht. Dazu wird ein zuflliger Punkt s1 in der Nachbarschaft gewhlt und mit s0 verglichen. Analog zum Abkhlen wird hierbei nicht
2.2. Optimierung - 2011-05-02/035/IN03/2231
15
die Temperatur gesenkt, sondern die Akzeptanzwahrscheinlichkeit fr schlechtere Lsungen. Da s0 ein lokales Optimum sein knnte, kann es notwendig sein dieses zu verlassen und s1 als schlechteren Wert zu akzeptieren in der Honung, dass s1 auf dem Weg zum globalen Optimum liegt. Je lnger der Algorithmus luft desto geringer die Wahrscheinlichkeit, dass schlechtere Ergebnisse akzeptiert werden, damit eine Konvergenz des Algorithmus zu einem Optimum mglich ist. Dieser Algorithmus setzt die ersten beiden Strategiekriterien aus Abschnitt 2.2.3 um. Es wird eine gegebene Lsung gezielt verbessert und zur Vermeidung von lokalen Optima gibt es als Zufallselement eine Wahrscheinlichkeit auch schlechtere Positionen als neue Startpositionen auszuwhlen. Der Vorteil des Algorithmus ist die sichere Konvergenz gegen ein Optimum und eine gute Suchraumabdeckung. Der Nachteil ist jedoch der fehlende Informationsaustausch. Da nur von einem Startpunkt ausgegangen wird und es mglich ist auch ein globales Optimum zu verlassen und anschlieend gegen ein lokales zu konvergieren, ist es sinnvoll in der Implementierung auf entsprechende Erweiterungen zur Speicherung von Optima zu bercksichtigen.
2.2.4.3 Evolutionre Algorithmen Evolutionre Algorithmen (EA) sind Optimierungsverfahren die an die biologische Evolution angelehnt sind. Die Eigenschaften einer Lsung werden dabei als Gene aufgefasst, die fr eine bestimmte Ausprgung der Lsung sorgen. Eine Einfhrung in die Thematik bieten z.B. [Wei02] und [GKK04]. Die Gene werden mit Hilfe sogenannter evolutionrer Operatoren verndert um neue Lsungen zu erzeugen. Dabei ndet die Suche nach Optima nicht nur mit einzelnen Lsungen sogenannter Individuen statt sondern mit Populationen, sondern mit Populationen, also Mengen von Individuen. Dies sorgt fr eine massive Parallelitt in der Suche. Eine gezielte Suche kann durch die Wahl geeigneter Startindividuen beschleunigt werden, whrend die evolutionren Operatoren sowohl fr die Konvergenz als auch zur Erzeugung fr Diversitt und somit einer guten Suchraumabdeckung benutzt werden. Die Optimierung ndet rundenbasiert in sogenannten Generationen statt. In jeder Generation ndet eine Selektion statt, um die fr die nchste Runde besten Individuen auszuwhlen und somit Informationen ber den Suchraum weiterzugeben. Der Vorteil der EA liegen in der massiven Parallelitt und guten Suchraumabdeckung. Dafr ist es allerdings ntig die evolutionren Operatoren ausgewogen einzusetzen um eine Entartung der Population zu verhindern.
16 2.2.4.4 Tabu Suche
Tabu Suche ist eine aus dem Simulated Annealing entstandene Metaheuristik die zur Lsung eines Optimierungsproblems andere Verfahren kombiniert [Zim08]. Dabei werden zunchst lokale Optima bestimmt und diese als Ausgangspunkt fr verschiedene Heuristiken verwendet. Um zu verhindern, dass das Verfahren in einen Zyklus verfllt und sich nicht mehr von einem lokalen Optimum lsen kann gibt es bestimmte Tabu Bedingungen. Da der Einsatz und vor allem die Bewertung in welcher Situation welche Heuristik eingesetzt werden sollte erfordern tiefer gehendes Hintergrundwissen ber den Suchraum. Eine Beurteilung nach Kriterien ist in diesem Fall schwierig, da diese stark von den eingesetzten Heuristiken abhngen.
2.2.4.5 Ameisenkolonieoptimierung Ameisenkolonieoptimierung [CHS02] ist ein Verfahren aus dem Bereich der Schwarmintelligenz, dass die Art und Weise nachbildet in der Ameisen krzeste Wege zu ihren Nahrungsquellen ermitteln. Ameisen hinterlassen dazu Pheromone auf ihrem Weg zur Nahrung. Falls keine Pheromone vorhanden sind wir der Weg der Ameise als zufllig angenommen. Falls Pheromonspuren vorhanden sind, folgt sie einer solchen Spur mit einer bestimmten Wahrscheinlichkeit die mit steigender Pheromonstrke in einer Spur zunimmt. Da sich die Pheromone kontinuierlich verchtigen ist ihre Konzentration auf dem krzesten Weg am hchsten. Darum wird der krzeste Weg mit der hchsten Wahrscheinlichkeit von allen Ameisen gewhlt und die lngeren Wege lsen sich mit der Zeit auf. Vorausgesetzt wird dabei, dass sich die Gesamtlsung aus Teillsungen zusammensetzen lsst. Bei einem Optimierungsproblem erzeugt eine Ameise eine zulssige Lsung und markiert alle Teillsungen mit Pheromonen. Entsprechend werden Teillsungen mit hoher Pheromonanzahl mit hherer Wahrscheinlichkeit fr eine weitere Lsung ausgesucht. Gezielte Suche und somit die Verbesserung vorhandener Lsungen wird durch die entsprechend hhere Pheromonfrequentierung sichergestellt ebenso wie der Informationsaustausch. Ein Zufallselement zur breiten Abtastung des Suchraums ist durch die Wahrscheinlichkeit gegeben mit der eine Ameise einen Weg einschlgt. Je hher die Pheromonkonzentration, desto hher ist die Wahrscheinlichkeit diesen zu benutzen, jedoch besteht immer die Mglichkeit einen vllig neuen Weg zu whlen. Im Gegensatz zum Simulated Annealing ist das Ende der Suche nicht festgelegt, Abbruchkriterien knnten z.B. ein Schwellwert fr die Pheromondichte oder klassisch eine Laufzeitschranke sein.
2.2. Optimierung - 2011-05-02/035/IN03/2231 2.2.4.6 Zusammenfassung
17
Die mathematische Programmierung bietet eziente Lsungsmglichkeiten, allerdings sind die Anforderungen an Funktionen so hoch, dass sie als Einzelverfahren zunchst nicht verwendet werden. Allerdings knnte es durchaus interessant sein sie im Rahmen einer Metaheuristik zur Lsung von Teilproblemen zu verwenden. Metaheursitiken werden auf Grund ihrer hohen Wissensanforderungen ber den Suchraum ebenfalls ausgeschlossen, bleiben jedoch fr eine Betrachtung in einer Folgearbeit weiterhin oen. Simulated Annealing, Evolutionre Algorithmen und Ameisenkolonieoptimierung sind drei naturanaloge Verfahren, die alle interessante Anstze zur Lsung von Optimierungsproblemen darstellen. Simulated Annealing ist ein Verfahren, dass einen gegebenen Punkt im Suchraum weiter verbessert, whrend die beiden anderen Verfahren sich nicht auf einzelne Lsungen konzentrieren, sondern stattdessen Mengen von Lsungen parallel verarbeiten. Aus Grund dieser hohen inhrenten Parallelitt und der Gre des Suchraums wird Simualted Annealing als Lsungsverfahren ausgeschlossen. Sowohl die evolutionren Algorithmen als auch die Ameisenkolonieoptimierung sind vielversprechende Kandidaten fr einen Suchalgorithmus, auf Grund der Verfgbarkeit von Frameworks die Systemsynthese mit evolutionren Algorithmen wird diesen der Vorzug in dieser Arbeit gegeben.
2.2.5
Evolutionre Algorithmen
In der Entwicklung der evolutionren Algorithmen (eA) sind bereits sehr frh drei groe Teilgebiete entstanden. Diese sind jedoch weniger inhaltlicher als viel mehr historischer Natur. Zum Verstndnis der Algorithmen wird hier kurz auf Grundbegrie der eA eingegangen und anschlieend die einzelnen Gebiete vorgestellt. Eine ausfhrliche Erluterung geben [Wei02] und [GKK04]. 2.2.5.1 Grundbegrie Allen Teilgebieten gemeinsam ist die Anlehnung an die biologische Evolution und deren Terminologie. In der Biologie gibt es einzelne Individuen die sich zu Populationen () zusammenschlieen und sich fortpanzen. Entsprechend wird in der Optimierung eine Lsung als Individuum und eine Menge von Lsungen als Population bezeichnet. Populationen breiten sich blicherweise nicht ungehemmt aus, sondern unterliegen einer sogenannten Selektion. Diese kann extern also durch Umwelteinsse oder intern durch ihre genetische Ausprgung der Individuen erfolgen. In der Optimierung wird hug auf eine Umweltselektion verzichtet und
18
stattdessen die einzelnen Individuen nur nach ihrem Fitness Wert bewertet. Fitness beschreibt dabei den Grad der Anpassung an die Umwelt. In der Optimierung entspricht dies der Bewertungsfunktion. Die Fortpanzung wird als Generierung von Kindindividuen aus Elternindividuen durch genetische Operatoren interpretiert bei der eine bestimmte Anzahl von Kindindividuen pro Generation erzeugt werden. Die beiden Standardoperatoren sind die Mutation und die Rekombination. Bei der Mutation wird aus einem Individuum ein neues erzeugt indem alle Attribute mit einer gewissen Wahrscheinlichkeit verndert werden. Bei der Rekombination werden die Eigenschaften zweier Elternindividuen gemischt.
2.2.5.2 Allgemein Gemeinsam haben alle Algorithmen, dass sie in der Lage sind gute Lsungen schnell zu verbessern und durch den Mutationsoperator den Suchraum breit abzudecken. Der Informationsaustausch ndet implizit durch die Populationen statt. Dadurch dass es in allen Algorithmen einen Selektionsschritt zur Regulierung der Populationsgre gibt und die Selektion darauf abzielt die besten Individuen entsprechend ihrer Fitness auszuwhlen ist ein Informationsaustausch ber die besten Lsungen gewhrleistet.
2.2.5.3 Evolutionre Strategien Evolutionsstrategien stammen aus dem technisch-physikalischen Bereich und besitzen reellwertige Zielfunktionen. An genetischen Operatoren wird blicherweise nur die Mutation verwendet. In jeder Generation wird eine sehr groe Anzahl von Nachkommen () erzeugt und anschlieend die Population so lange reduziert bis sie wieder ihre festgelegte Gre () erreicht hat. Je nach Algorithmus knnen auch Elternindividuen in die neue Population aufgenommen werden, um schneller zu konvergieren. Der Nachteil besteht allerdings darin, dass die Konvergenz auch schneller gegen ein lokales Optimum erfolgen kann.
2.2.5.4 Evolutionre Programmierung Evolutionre Programmierung (eP) ist der kleinste der drei Teilbereiche und sehr hnlich den Evolutionsstrategien. Ursprnglich entwickelt wurden sie dabei nicht zur Optimierung, sondern zur Generierung intelligenter endlicher Automaten [FOW66]. Als genetischer Operator wird nur die Mutation verwendet. Als Zielfunktion wird eine reellwertige Funktion mit dem globalen Optimum beim
2.2. Optimierung - 2011-05-02/035/IN03/2231
19
Nullpunkt vorausgesetzt. Die Selektion erfolgt hauptschlich durch eine Umweltselektion.
2.2.5.5 Genetische Algorithmen Genetische Algorithmen (GA) zeichnen sich dadurch aus, dass der Selektionsdruck durch eine probabilistische Selektion der Eltern erfolgt und eine Umweltselektion nicht stattndet. Die Rekombination ist der primre Operator, whrend die Mutation nur selten eingesetzt wird, um die Diversitt in der Population zu erhalten. Der huge Einsatz der Rekombination bewirkt jedoch, dass die Population nach einer gewissen Zeit konvergiert und nur noch identische Individuen in der Population enthalten sind. Dies ist jedoch nicht mit der Konvergenz zu einem globalen Optimum zu verwechseln. Klassisch verwenden GA einen binr kodierten Suchraum.
2.2.5.6 Selektion Die Selektion spielt eine bedeutende Rolle bei den evolutionren Algorithmen, da sie fr die Auswahl der Individuen fr die nchste Generation sorgt und somit einen wesentlichen Bestandteil zur Konvergenz des Algorithmus liefert. Die Selektion kann entweder durch eine zufllige Auswahl der Individuen erfolgen, dann handelt es sich um eine probabilistische Selektion, ansonsten um eine deterministische. Die Selektion kann an zwei verschiedenen Stellen ansetzen. Die erste Stelle sind die Eltern die fr die Reproduktion ausgewhlt werden und wird entsprechend als Elternselektion bezeichnet. Die andere Mglichkeit besteht darin alle Individuen fr die Reproduktion auszuwhlen und anschlieend eine Selektion unter den Individuen auszufhren und wird Umweltselektion genannt. Der Name kommt daher, dass in der biologischen Evolution an dieser Stelle die Umwelt die Individuen mit einer zu niedrigen Anpassung entfernen wrde. Ein hoher Selektionsdruck fhrt dazu, dass die Population schnell konvergiert, da nur Individuen mit einer sehr hohen Fitness in die nchste Population bernommen werden. Dafr sinkt allerdings die Diversitt und somit erfolgt die Konvergenz mglicherweise nur gegen ein lokales Optimum. Ein niedriger Selektionsdruck auf der anderen Seite fhrt dazu, dass das eine gute Suchraumabdeckung vorliegt, dafr allerdings die Konvergenz deutlich erschwert wird.
20
2.2.5.7 Evolutionre Operatoren Evolutionre Operatoren sind das Gegenstck zu der Selektion indem sie fr eine Vergrerung der Population sorgen. Die beiden wichtigsten Operatoren sind die Mutation und die Rekombination. Einer der wichtigsten Unterschiede der beiden Operatoren ist dabei, dass bei der Rekombination die Konvergenz im Vordergrund steht, whrend die Mutation Diversitt zum Ziel hat. Mutation. Die Mutation ist ein evolutionrer Operatoren mit dem Ziel der Diversitt. Mit einer problemspezischen Wahrscheinlichkeit werden die Attribute eines Elternindividuums verndert um ein Kindindividuum zu erzeugen. Die Mutationen erfolgen dabei nicht zielgerichtet sondern zufllig um den Suchraum mglichst breit abzudecken. Durch die Mutation wird verhindert dass eine Population konvergiert, also nur noch aus identischen Individuum besteht, und es ermglicht das entkommen von lokalen Optima. Eine zu starke Gewichtung der Mutation fhrt allerdings dazu, dass die Individuen sich nicht mehr dem globalen Optimum annhern knnen, sondern stattdessen eine reine Zufallsfolge von Individuen erzeugt wird. Rekombination. Die Rekombination hat das Ziel der Konvergenz. Dabei werden Individuen blicherweise paarweise verknpft indem sie Attribute austauschen. Damit soll erreicht werden, dass ein Individuum mit den besten Eigenschaften aus den Eigenschaften der Eltern erzeugt wird. Der Vorteil des Operators ist die Erhaltung guter Eigenschaften in der Population und somit die Konvergenz zu dem besten Individuum das mit den gegebenen Attributen erzeugbar ist. Allerdings ist es nicht mglich mit diesem Operator neue Eigenschaften zu erzeugen. Eine zu starke Gewichtung des Operators fhrt dazu, dass die Population sehr schnell zu einem Individuum konvergiert und eine Konvergenz zu einem Optimum extrem schwierig wird. 2.2.5.8 Rolle der Diversitt Die Diversitt in der Population spielt bei populationsbasierten Verfahren wie den evolutionren Algorithmen eine groe Rolle. Diversitt bedeutet in diesem Fall, dass die Individuen einer Population eine mglichst breite Abbildung des Suchraums darstellen. Im Laufe der Zeit kann es passieren, dass die Diversitt einer Population abnimmt und alle Individuen einer Population nahezu identisch sind. Im Falle des globalen Optimums ist dies zwar wnschenswert, allerdings besteht die Gefahr, dass eine Population zu einem beliebigen Wert konvergiert.
2.2. Optimierung - 2011-05-02/035/IN03/2231
21
Darum ist es ntig dass bei der Auswahl der Operatoren darauf geachtet wird eine gewisse Diversitt innerhalb der Population zu erhalten. 2.2.5.9 Informationskodierung Individuen reprsentieren bestimmte Lsungen aus dem Suchraum und evolutionre Operatoren dienen der Suche nach neuen Individuen. Um diese Prinzipien allgemein anwenden zu knnen ist es ntig Problemlsungen in ein passendes Format zu konvertieren. Vor allem im Bereich der genetischen Algorithmen ist es blich Informationen binr zu kodieren. Da es sich bei der Systemsynthese um ein kombinatorisches Optimierungsproblem handelt, ist es auch in diesem Fall problemlos mglich die Informationen binr zu kodieren. Eigenschaften wie z.B. Ausfhrungszeiten werden dabei nicht von einer Gleitkommadarstellung in eine binr Darstellung berfhrt um einen Informationsverlust zu vermeiden.
22
2.3
Scheduling
Scheduling beschreibt allgemein das Problem, dass n Auftrge J1 ... Jn auf m Maschinen M1 ... Mm ausgefhrt werden sollen. Die Lsung eines Scheduling Problems teilt jedem Auftrag einen oder mehrere Slots auf einer oder mehreren Maschinen zu und wird als Ablaufplan bezeichnet. Die graphische Reprsentation erfolgt blicherweise als Gantt Diagramm wie in Abb. 2.7 dargestellt. Eine Einfhrung in das Gebiet bieten [Bru01] und [Dro09]. Einen historischen berblick zu dem Thema bietet [SAC+ 04].
Abbildung 2.7: Beispiel fr ein sequentielles Scheduling Ein Auftrag Ji besteht dabei aus ni Operationen, jede Operation Oij mit einer festgelegten Bearbeitungszeit pij , einem Startzeitpunkt ri , einer Menge von Maschinen ij {M1 , ..., Mm } auf denen Oi ausgefhrt werden kann, einer Kostenfunktion fi (t) die die Kosten der Ausfhrung Ji zum Zeitpunkt z angibt, einem Ablaufzeitpunkt di und einem Gewicht wi fr die Funktion fi (t). Allgemein wird davon ausgegangen, dass pi , pij , ri , di und wi nur ganzzahlige Werte annehmen knnen. Ein Ablaufplan wird als gltig bezeichnet, falls sich keine zwei Slots fr einen Auftrag auf einer Maschine berlappen und alle festgelegten problemspezischen Bedingungen erfllt sind. Falls sich zwei Slots eines Jobs auf unterschiedlichen Maschinen berlappen, dann muss es sich um eine Multiprozessoroperation handeln, ansonsten ist der Ablaufplan nicht gltig.
2.3.1
Notation
Scheduling Probleme werden klassisch in der ||-Notation dargestellt. Dabei charakterisiert die Maschinenumgebung, die Auftrge und die Optimalittskriterien.
2.3. Scheduling - 2011-05-02/035/IN03/2231 2.3.1.1 Maschinenumgebung
23
Eine Maschinenumgebung wird durch den String = 1 2 beschrieben. 1 gibt den Typ der bentigten Maschine an. Die Typen entsprechend [Bru01] sind P, Q, R, PMPM, QMPM, G, X, O, J, F und kann entfallen, falls alle Auftrge nur aus einzelnen Operationen bestehen. 2 gibt die Anzahl der Maschinen an.
2.3.1.2 Auftrge Auftrge werden durch den String = 1 2 3 4 5 6 beschrieben. 1 ist ein Boolescher Wert der angibt, ob Preemption untersttzt wird. 2 beschreibt die Abhngigkeitsrelation zwischen den einzelnen Jobs. In dem Modell das dieser Arbeit zu Grunde liegt werden Probleme als Datenussgraphen beschrieben, um einen mglichst hohen Grad an Parallelitt zu erzeugen. In diesem Graphen werden alle Abhngigkeiten als Daten reprsentiert und der Datenussgraph reprsentiert genau diese Abhngigkeitsrelation. 3 ist die Startzeit eines Jobs, 4 die Lnge des Auftrags und 5 die Deadline des Auftrags bis zu der er verarbeitet sein muss. Falls es notwendig ist mehrere Operationen eines Jobs parallel auf einer Maschine laufen zu lassen, dann gibt 6 an, ob diese Jobs entsprechend der lngsten Operationszeit (p-batch) oder entsprechend der Summe der Operationszeiten (s-batch) behandelt werden.
2.3.1.3 Optimalittskriterien Optimalittskriterien beschreiben die fr das Problem zu optimierenden Funktionen. Naheliegend ist es die Funktionen an Hand ihrer Abschlusszeitpunktes zu beurteilen. Entweder nach der Summe aller Abschlusszeiten, oder nach der sptesten Abschlusszeit.
2.3.2
Einzelmaschinen
Das Scheduling auf einzelnen, unabhngigen Rechner ist ein bereits gut erforschtes Gebiet. Da die Ausnutzung der dem Datenussgraphen inhrenten Parallelitt ein Ziel dieser Arbeit ist, ist es jedoch erforderlich Scheduling nicht nur auf einzelnen Rechnern, sondern auch fr verteilte Anwendungen zu betrachten. Aus diesem Grund wird an dieser Stelle nicht weiter darauf eingegangen.
24
2.3.3
Parallele Maschinen
Aus Sicht des Scheduling lassen sich Systeme mit parallelen Maschinen in drei Klassen aufteilen. Identische Maschinen liefern fr identische Jobs identische Ausfhrungszeiten. Uniforme Maschinen unterscheiden sich durch einen Skalierungsfaktor voneinander und unabhngige Maschinen schlielich knnen auf Grund unterschiedlicher Ausstattungen Jobs unterschiedlich schnell verarbeiten.
2.3.3.1 Identische Maschinen Identische Maschinen M1 , M2 knnen in einem gegebenen System einen Job J in der gleichen Zeit ausfhren. Wie in [Bru01] gezeigt gibt es eine ganze Reihe von Problemfllen die auf Basis eines solchen System in polynomieller Zeit lsbar sind.
2.3.3.2 Uniforme Maschinen Hug bestehen Systeme nicht aus absolut identischen Maschinen, sondern unterscheiden sich zumindest um einen Skalierungsfaktor s. In diesem Fall handelt es sich um ein System aus uniformen Maschinen. Diese Abstraktion bewirkt jedoch auch, dass im Falle nichtpreemtiver Jobs mit frei whlbaren Ausfhrungszeitpunkten lediglich noch das Problem Q || Ci noch in polynomieller Zeit lsbar ist.
2.3.3.3 Unabhngige Maschinen Die allgemeinste Form von parallelen Maschinen sind unabhngige Maschinen. Dabei lsst sich keine Beziehung zwischen den Ausfhrungszeiten der Jobs auf unterschiedlichen Maschinen angeben, da diese je nach Ausstattung Jobs unterschiedlich schnell erledigen knnen.
2.3.4
Komplexitt
In [Bru01] sind Algorithmen beschrieben die bestimmte Klassen von Scheduling Problemen in Polynomialzeit lsen. Allerdings ist zu bedenken, dass bereits Probleme mit zwei identischen parallelen Rechner und einem Optimalittskriterium das die maximale Abschlusszeit bewertet nicht mehr in polynomieller Zeit lsbar sind. Fr komplexere Probleme ist es deshalb von Interesse auch fr das Scheduling Heuristiken einzusetzen. Einen Ausblick hierzu bietet Abschnitt 6.2.2.
2.4. Entwurfssysteme - 2011-05-02/035/IN03/2231
25
2.4
Entwurfssysteme
In diesem Abschnitt werden die Bewertungskriterien erlutert, aussichtsreiche Kandidaten vorgestellt, ein tabellarischer berblick der betrachteten Frameworks gegeben sowie eine abschlieende Bewertung zum Einsatz der Frameworks gegeben. Neben der Beschreibung der vier aussichtsreichsten Kandidaten sind in den Tabellen 2.1 und 2.2 sechs weitere Frameworks zu nden die im Rahmen dieser Arbeit untersucht aber nicht eingesetzt werden.
2.4.1
Grundlagen
In diesem Abschnitt folgt eine Beschreibung der fr diese Arbeit verwendeten Laufzeitumgebung, der Modelle und der Softwaretests die fr die Tests der Frameworks verwendet wurden. Laufzeitumgebung. Als Betriebssystem wird ein Windows 7 (64 und 32 Bit), ein Windows XP, ein Ubuntu 10.04 sowie ein Debian 5.0. An Software standen die Frameworks Daedalus in der Version 0.0.1, LOTZ2 und SIBEA in den Versionen von 2008 als Beispielimplementierungen fr das PISA Framework sowie fr MILAN in der Version 1.2 mit der General Modeling Environment in der empfohlenen Version 4.11.10 und der aktuellen Version 10.8.18. Als Modelle wurden fr einen Test des Funktionsumfang die in den Frameworks enthaltenen Beispiele verwendet. Modelle. Das in dieser Arbeit verwendete Modell des ArchitectureMapGraph verwendet Datenussgraphen fr die Problemreprsentation, sowie eine kommunikationsorientierte Darstellung der Architekturen. Das MILAN Framework verwendet die vier Modelltypen Ressource, Application, Constraint und Performance and Communication. Daedalus als umfassendstes Framework geht von sequentiellen C Programmen aus die in Kahn Prozess Netzwerke umgewandelt werden und verwendet eine IP component library mit high level Architekturen zur Beschreibung der Architekturen die spter in VHDL Code umgewandelt werden.
2.4.2
Frameworks
Im Folgenden werden kurz vier Frameworks vorgestellt, die inhaltlich am besten fr das Mapping im Rahmen dieser Arbeit geeignet scheinen und von deren Software eine entliche Version zur Verfgung steht.
26 2.4.2.1 Daedalus
Daedalus [NTS+ 08] ist ein Framework zur Entwicklung von eingebetteten Multimedia MP-SoC (MultiProcessor System On Chip) Systemen. Die Entwurfsraumexploration wird dabei von dem frheren Sesame (Simulation of Embedded Systems Architectures for Multi-Level Exploration) [PEP06] Framework durchgefhrt. Aktuell ist das Framework lediglich in einer sehr frhen Version (0.0.1) von 2008 verfgbar. Deadalus ist ein deutlich umfassenderes Tool zur Systemsynthese, so dass sich die Beurteilung vor allem auf den aus dem Sesame Projekt stammenden Entwurfsraumexplorationsteil beschrnkt. Der hauptschliche Verwendungszweck liegt im eingebetteten Multimedia Bereich. In [GGH+ 10] ndet sich ein berblick ber einige aktuelle Frameworks und zeigt, dass Daedalus auf Grund seiner spezialisierten Anwendung noch einige Dezite im Bereich der Abbildung von Kommunikationsvorgngen hat. Bei einem Test des Frameworks viel auf, dass die gewhlten LinuxDistributionen zum Stand der Arbeit nicht mehr im Netz verfgbar waren und der Quellcode sich nicht kompilieren lie, da der verwendete Kode nicht den C++ Spezikationen entspricht und sich auch mit etwas Aufwand nicht kompilieren lie. 2.4.2.2 MILAN MILAN (Model based Integrated simuLAtioN) [BL01] wurde bis 2003 entwickelt und ist ein erweiterbares Framework zur Entwurfsraumexploration. Zur Darstellung von Anwendungen werden die hierarchischen Datenussgraphen der GME (General Modeling Environment) [LMB+ 01] verwendet. Ein Schwerpunkt des Frameworks liegt in der Simulation und Evaluation von Performanzmetriken. Das Projekt wurde bis 2003 entwickeltet und ist bereits von Seiten der Universitt Sd-Kaliforniens gelscht wurde und nur noch von der Vanderbilt Universitt verfgbar. Da es auf einer eigenen Modellierungsumgebung aufsetzt und nicht ber eine Kommandozeilen Anbindung verfgt, ist die Anbindung nur manuell mglich. Da selbst die Ausfhrung der Beispiele mit vielen Fehlern quittiert wird, scheint eine Verwendung nicht besonders lohnenswert. 2.4.2.3 NASA NASA (Non Ad-hoc Search Algorithm) [JPT+ 10] ist eine aktuelle Entwicklung im Bereich der Simulation auf Systemebene sowie der Entwurfsraumexploration. Es handelt sich hierbei um ein modulares Framework dessen Spezialitt in einer Vielzahl von Suchalgorithmen liegt. Es wird davon ausgegangen, dass es vorteilhaft
27
ist fr unterschiedliche Dimensionen des Entwurfsraums unterschiedliche Suchalgorithmen zu verwenden. Eine Integration von z.B. dem PISA Framework [BLTZ03] ist fr die Zukunft geplant. NASA ist gerade erst in der Entwicklung und zum Zeitpunkt der Arbeit stand noch keine entliche Testversion zur Verfgung. Der Ansatzpunkt PISA zu integrieren scheint jedoch interessant, da sich PISA als Framework fr Suchalgorithmen fr die Entwurfsraumexploration anbietet. 2.4.2.4 PISA PISA (Platform and Programming Language Independent Interface for Search Algorithms) [BLTZ03] ist ein Framework fr Suchalgorithmen dessen Strke in der Trennung von Algorithmen und Anwendungsspezischen Teilen liegt. Dies ermglicht es die anwendungsabhngige Reprsentation der Daten unabhngig von dem eigentlichen Suchalgorithmus zu implementieren und sich somit nicht auf spezielle Algorithmen begrenzen zu mssen. Zur Kommunikation der beiden Teile wird ein textbasiertes Interface verwendet. Fr beide Teile stehen auf [EZ09] Implementationen in verschiedenen Programmiersprachen zur Verfgung. Die Trennung von Datenreprsentation und Algorithmus ermglicht es ohne groen Aufwand den Suchalgorithmus oder das Problem auszuwechseln und sich somit nicht bereits kodeseitig festlegen muss. Fr diese Arbeit ist das Problem gegeben und die Verwendung von verschiedenen Suchalgorithmen von Interesse. Auf der Internetseite zum Framework [EZ09] stehen bereits einige Algorithmen und Beispielimplementationen fr den problemspezischen Teil zur Verfgung. Die Schnittstelle besteht aus einer einfachen Textdatei, so dass sie Programmiersprachen und sogar Betriebssystemunabhngig verwendet werden kann. Die vorhandenen Beispiele lieen sich problemlos verwenden und auf eigene Flle anpassen. Der Hohe Grad an Modularitt macht dieses Framework zur ersten Wahl bei der Implementierung, damit ein spterer Austausch des Suchalgorithmus problemlos mglich ist.
28
2.4.3
Zusammenfassung
Nach der Recherche ist festzustellen, dass es eine Reihe von akademischen Projekten im Bereich der Systemsynthese gibt, die entsprechenden Frameworks jedoch nur selten oen verfgbar oder nur sehr eingeschrnkt benutzbar sind. Die vorhandenen Frameworks sind also zunchst nicht fr den Einsatz geeignet, weshalb es sinnvoll erscheint eine eigene Implementierung vorzunehmen. Hierzu steht als Hilfe das PISA Framework zur Verfgung, dass einen Standard fr Suchalgorithmen prsentiert, so dass diese leicht ausgewechselt werden knnen.
Einsatzgebiet
Milan NASA Simulation verteil- Systemsynthese ter Systeme mit modularer Algorithmik multigranulare Performanzevaluation keine entliche Version verfgbar Konguration ei- genetische nes idealen Pro- rithmen zessors Algo-
GENIE MOGAC Simulation verteil- Systemsynthese ter Systeme von Echtzeitsystemen
Besonderheiten
Entwicklungsstand
Automatisierbarkeit Plattform Bemerkungen [BL01] [JPT+ 10] [NR07]
abgeschlossen (2003) nein Windows Programmfehler
Simulations- und Suchalgorithmen modular und dimensionsorientert keine entliche Version verfgbar -
keine entliche Version verfgbar -
Quelle
Deadalus Systemsynthese von eingebetteten Multimediasystemen vollstndige Systemsynthese fr den industriellen Einsatz frhe Testversion (Stand 2008) ja Linux nicht kompilierbar [NTS+ 08] [DJ98b]
Tabelle 2.1: Gesamtbersicht Entwurfssysteme Teil 1
29
30
Einsatzgebiet
PISA Interface fr Suchalgorithmen Lastverteilung, statistische Daten vergangener Testlufe
MARS Scheduling von Echtzeitsystemen
SymTA/S Scheduling
Besonderheiten
CORDS Systemsynthese von verteilten Echtzeitsystemen Einsatz rekongurierbarer FPGAs
SystemCoDesigner Systemsynthese aus SystemC Beschreibungen Rapid Prototyping
formale Scheduling Analyse und symbolische Simulation
Entwicklungsstand
keine entliche Version verfgbar
frhe Testversion (Stand 2006)
Automatisierbarkeit Plattform Bemerkungen
nicht geprft Linux
Windows / Linux
Quelle
[DJ98a]
[HFK+ 07]
Trennung von Algorithmus und Problem, unabhngig von Plattform und Sprache aktuell Entwicklungen auf der Webseite (Stand 24.05.2011) ja unabhngig abstraktes Interface, lauhige Algorithmen auf der Webseite (Stand 24.04.2011) [BLTZ03] [GR96]
[HHJ05]
Tabelle 2.2: Gesamtbersicht Entwurfssysteme Teil 2
31
KAPITEL 3
Konzeption
Aufbauend auf den Grundlagen aus Kapitel 2 wird in diesem Kapitel ein Konzept fr die Architektursynthese aus Multi-Level Systembeschreibungen entwickelt. Hierzu wird in Abschnitt 3.1 die Ausgangssituation der Arbeit geschildert und daraus die Ziele der Arbeit abgeleitet. Anschlieend werden in Abschnitt 3.2 die in der Arbeit verwendeten Modelle erlutert und erweitert. Darauf aufbauend wird in Abschnitt 3.3 das eigentliche Mapping im Rahmen der Systemsynthese erarbeitet.
3.1
Anforderungen
Diese Arbeit befasst sich mit der Konzeption und Erprobung einer Methode zur Architektursynthese aus Multi-Level Systembeschreibungen. Ausgangspunkt der Arbeit sind systemunabhngiger Problemgraph und ein Architekturgraph die in einem sogenannten ArchitectureMapGraph (AMGraph) gespeichert werden. Der AMGraph wird im Fachgebiet Rechnerarchitekturen der TU Ilmenau entwickelt und enthlt entsprechend [Kon10] ein Mapping um die Knoten des Problemgraphen auf die Knoten des Architekturgraphen abzubilden. Fr die Systemsynthese entsprechend 2.1 ist es vorteilhaft mit hierarchischen Graphen zu Arbeiten, da sich auf diese Weise sowohl die Granularitt als auch Funktionsalternativen darstellen lassen. Da der AMGraph aktuell keine Hierarchieebenen untersttzt besteht der erste Schritt darin den Graphen entsprechend zu erweitern. In dem AMGraph werden weiterhin nur Datenabhngigkeiten auf Seiten des Problemgraphen bzw. Verbindungen zwischen dem Ausfhrungs- und Kommunikationseinheiten auf Seiten der Architektur abgebildet. Da fr die Systemsynthese weitere Parameter wie z.B. die Datenbreite und die Ausfhrungszeit der Operationen ntig sind, besteht der zweite Schritt in der Einfhrung von Eigenschaften der Elemente im Graphen. Aufbauend auf dem so erweiterten Modell wird nun die Systemsynthese durchgefhrt. Dabei besteht der nchste Schritt in der Wahl eines passenden Optimierungsframeworks und der Abbildung des Modells in ein fr die Optimierung zugngliches
32
2011-05-02/035/IN03/2231 - Kapitel 3. Konzeption
Format. Ziel der Arbeit ist die Ausgabe mglicher Zielimplementierungen in Form der pareto optimalen Lsungsmenge. Um keine zu Problemspezische Lsung zu erhalten sollen auerdem die verwendeten Algorithmen, Optimierungskriterien sowie die modellierten Eigenschaften leicht austausch- und erweiterbar implementiert sein.
3.2
Modelle
Als Modell fr den in Abschnitt 2.1.2 eingefhrten Spezikationsgraph wird der im Fachgebiet entwickelte ArchitectureMapGraph verwendet. Um den Anforderungen in Abschnitt 3.1 zu gengen mssen sie um eine Hierarchie und um Eigenschaften erweitert werden. Die Hierarchisierung eines Spezikationsgraphen besteht aus der Hierarchisierung des Problemgraphen und des Architekturgraphen. Theoretisch lsst sich auch ein dynamisches Mapping zwischen verschiedenen Hierarchieebenen denieren, allerdings ist eine solche Erweiterung im Rahmen dieser Arbeit nicht notwendig, so dass lediglich der Problemgraph und der Architekturgraph um Hierarchieebenen erweitert werden. Der ursprngliche ArchitectureMapGraph ist im Anhang als Abb. A.2 vollstndig zu sehen, der erweiterte in Abb. ??.
3.2.1
Problemgraph
Im DFGraph werden Knoten Vp bzw. Kanten Ep des Problemgraphen Gp durch die Elemente Operation bzw. Datum modelliert. In [TH07] wird die Hierarchisierung dazu verwendet Funktionsalternativen fr Knoten abzubilden. In dieser Arbeit wird sie auch dazu verwendet Verfeinerungen bzw. Abstraktionen darzustellen. Eine Verfeinerung kann dabei als Spezialfall der Funktionsalternative betrachtet werden in der nur eine Alternative zur Verfgung steht. Eine Umsetzung des in Abschnitt 2.1.2 vorgestellten Hierarchiekonzepts fr Spezikationsgraphen erfordert zwei wesentliche Schritte. Als erster muss in Gp der Ursprungsknoten vi Vp durch ein Interface i ersetzt werden. Im DFGraph muss also die Mglichkeit bestehen einen Knoten zu erzeugen, der ber Menge eingehender Kanten I, eine Menge ausgehender Kanten O, eine Menge von Clustern und eine Menge von Kanten zur Beschreibung des Portmappings verfgt. Fr die Realisierung eines Cluster ist es ntig, dass ein Graph zur Verfgung steht, der ber Menge eingehender Kanten I, eine Menge ausgehender Kanten O, eine Menge von nicht hierarchischen Knoten V, eine Menge von E Kanten die die Abhngigkeiten zwischen allen Knoten beschreiben und eine Menge von Interfaces als Platzhalter fr den Cluster verfgt.
3.2. Modelle - 2011-05-02/035/IN03/2231
33
3.2.2
Architekturgraph
Eine Architekturbeschreibung Ga bestehend aus Kommunikationsressourcen vc Va , funktionalen Ressourcen vf Va und einer Menge von Kommunikationsverbindungen Ea ist im AMGraph realisiert als Platform mit den Elementen ProcessingResource und CommunicationResource . Die Hierarchisierung des Graphen Ga wird dabei analog zu des Graphen Gp ausgefhrt. In [TH07] werden lediglich funktionale Ressourcen im Architekturgraph um Cluster erweitert.
3.2.3
Speicher
In [Kon10] wird der ArchitectureMapGraph um Speicherelemente erweitert, da dort das Fehlen von Speicherelementen als Schwachstelle des Modells interpretiert wird. In dieser Arbeit wird davon ausgegangen, dass das Fehlen von Speicherelementen keine Schwachstelle ist, sondern eine positive Eigenschaft des Modells. Die Menge und Art des Speichers ist zwar eine wichtige Eigenschaft des Spezikationsgraphen sowohl auf der Seite des Problemgraphen dessen Daten gespeichert werden mssen, als auch auf Seiten des Architekturgraphen, da die funktionalen Ressourcen und Kommunikationsverbindungen nur eine begrenzte Menge an Speicher verfgen. Diese Eigenschaften leiten sich jedoch direkt von den verwendeten Elementen ab und treten nicht als eigenstndige Aktoren im Modell auf. Daten die von einem Knoten erzeugt werden mssen immer einen Abnehmer haben, ansonsten wre ist Erzeugung nutzlos. Aus diesem Grund ist eine Modellierung nur dann sinnvoll, wenn ein Datum auch einer Kommunikationsverbindung bergeben wird. Die weitere Verarbeitung der Daten kann natrlich auch auerhalb des Modells erfolgen. Wird ein Datum von zwei Knoten ber ein Shared Memory Element ausgetauscht, dann kann dies als Kommunikationsressource interpretiert werden. Auf Modellebene ist es demnach egal wie die Kommunikation stattndet und jeder Austausch von Daten wird als Kommunikation betrachtet. Eine eziente Verarbeitung der Daten zu erzeugen, z.B. indem mehrere Operationen hintereinander auf einem Prozessor ausgefhrt werden um Daten direkt in den Registern behalten zu knnen und somit eine extrem schnelle Kommunikationsverbindung zu erzeugen, ist ein Optimierungskriterium und nicht Gegenstand des Modells.
3.2.4
Kommunikation
In einem Problemgraphen beschreiben die Kanten e Ep die Datenabhngigkeiten zwischen zwei verschiedenen Knoten v Vp . Jede dieser Kanten beschreibt dabei
34
einen Kommunikationsvorgang zwischen zwei verarbeitenden Ressourcen. Bei entsprechend hoher Granularitt ist es mglich, dass verschiedene Operationen auf einer Verarbeitungsressource vv Va ausgefhrt und die Kommunikation intern erfolgt. In diesem Fall ist die Kommunikationsressource vk Va eine virtuelle Ressource mit einer bertragungsdauer von 0ms.
3.2.5
Eigenschaften
In dieser Arbeit wird die Gesamtlaufzeit des Programms zur Bewertung der Lsung herangezogen. Unter dieser Voraussetzung wurde eine mglichst kleine Menge an Eigenschaften ausgewhlt um die Gesamtlaufzeit auf einer heterogenen Plattform berechnen zu knnen. Als zweites Kriterium zu Bestimmung einer Plattform werden die Kosten Bauteilkosten der Plattform benutzt. 3.2.5.1 bersicht Die Modellierung der gewhlten Eigenschaften erfordern Erweiterungen in allen vier Bereichen des Graphen. Diese werden nun kurz vorgestellt. Ausfhrung. Fr die Kennzeichnung einer Ausfhrungseinheit sind die untersttzen Elementaroperationen sowie die Kosten des Bauteils relevant. Fr eine einfache Reprsentation der Lsungen gibt es auerdem noch die Mglichkeit eine Typenbezeichnung anzugeben. Kommunikation. Fr die Laufzeitberechnung ist es erforderlich die Zeit zu erfassen, die die bertragung der Daten auf einer Kommunikationseinheit bentigt. Neben der Angabe der Geschwindigkeit und der Latenz ist jedoch weiterhin zu beachten, dass die Bandbreite der Kommunikation nicht beliebig gro ist, so dass eine Erfassung der minimalen und maximalen Paketgre erforderlich ist. Im Rahmen dieser Arbeit werden die Kosten der Kommunikationsbauteile nicht weiter bercksichtigt, da sie sich auch Grund der Integration der Schaltungen nur schwer von den Kosten der Ausfhrungseinheiten trennen lassen. Auf Grund des modularen Charakters der Eigenschaften sind Erweiterungen aber beliebig mglich. Operationen. Da die Operationen eines Programms je nach gewhltem Abstraktionsgrad nicht den Elementaroperationen der Ausfhrungseinheiten entsprechen mssen, ist es ntig fr jede Operation die bentigten Elementaroperationen anzugeben, so dass eine Zuordnung zu einer Ausfhrungseinheit mglich ist. Fr
3.2. Modelle - 2011-05-02/035/IN03/2231
35
eine Bestimmung der Laufzeit ist es auerdem ntig die bentigte Zeit fr eine Operation anzugeben. Daten. Fr die Verarbeitung der Daten ist es ntig den Typ (z.B. Double) zu kennen und fr den Transport ist die Gre des Datentyps von Interesse, da dieser die Dauer der bertragung und somit die Gesamtlaufzeit beeinusst. 3.2.5.2 Berechnung Die einzelnen Eigenschaften werden im Rahmen des Mappings zusammengefhrt. Im Folgenden werden die Zusammenhnge der einzelnen Eigenschaften erlutert wie sie im Rahmen des Mappings vorkommen. Befehlssatz. Das erste Kriterium ist der Befehlssatz. Die Ausfhrungseinheiten stellen einen gewissen Basisbefehlssatz Bb zusammen whrend die Operationen einen bestimmten Befehlssatz Bo zur Ausfhrung bentigen. Sofern Bo Bb gilt, ist diese Eigenschaft erfllt. Um eine lesbarere Darstellung zu erreichen und die Geschwindigkeit der Auswertung zu erhhen ist es mglich statt elementarer Befehle auch Befehlsstze zu denieren. Dies kann die Anzahl der Vergleiche bei groen Befehlsstzen deutlich reduzieren. Kommunikationsgeschwindigkeit. Jedem Datum ist ein Gre g in Bit zugewiesen whrend die Kommunikationskanle eine bertragungsgeschwindigkeit in MByte/s haben. Dies ermglicht die Berechnung der Anzahl der theoretisch pro Sekunde bertragbaren Werte. Auerdem gibt es fr jeden Kommunikationskanal eine Latenz l und minimale bzw. maximale Paketgren pmin und pmax die weitere Einschrnkungen der Kommunikation darstellen. Um die konkrete Dauer zu berechnen ist es also zuerst ntig die Anzahl der bentigten Pakete zu berechnen und anschlieend die Zeit die diese Pakete fr eine bertragung inklusive der Latenz bentigen. Verarbeitungsgeschwindigkeit. Fr die Verarbeitungsgeschwindigkeit ist es im Embedded Bereich blich Schtzungen der Laufzeit auf bestimmten Hardwareelementen zu verwenden. Diese Werte werden zunchst als gegeben angenommen und direkt aus Eigenschaft ausgelesen. In einer weiterfhrenden Arbeit knnte dieses Verfahren durch eine Simulator verbessert werden der es ermglicht die Zeiten whrend des Ablaufs zu berechnen und wieder als Eigenschaft zu hinterlegen, so dass zuknftige Implementierungen von besseren Schtzungen ausgehen knnen.
36
3.3
Systemsynthese
Im Folgenden wird ein Mappingkonzept fr die Systemsynthese entwickelt, dass den in 1.2 genannten Zielen gengt. Als erstes wird die Systemsynthese in einzelne Schritte unterteilt die fr die Erzeugung des Mappings notwendig sind.
3.3.1
bersicht
Abb. 3.1 zeigt den Teil der Systemsynthese der in dieser Arbeit bearbeitet wird. Zunchst werden Modelle eingelesen, diese in einem Mapping Schritt zusammengefhrt, Parameter berechnet die einige Aussage ber die Qualitt der Realisierung geben und anschlieend wird dieses Mapping ausgegeben.
Abbildung 3.1: Ablauf des Mapping in der Systemsynthese Die Erzeugung eines Mappings ist dabei ein zyklischer Prozess wie er in Abb. 3.2 gezeigt ist. Zunchst wird also der hierarchische Graph in einen planaren umgewandelt indem Funktionsalternativen ausgesucht werden. Anschlieend wird das Problem auf eine Architektur abgebildet. Dieser Schritt beinhaltet die berprfung des Befehlssatzes so wie der Realisierbarkeit der Kommunikation und wird solange durchgefhrt bis eine gltige Bindung vorliegt. Anschlieend wird ein Scheduling durchgefhrt um einen gltigen Ablaufplan zu erhalten der unter Einhaltung aller Bedinungen eine Ausfhrung der Programms auf der Architektur ermglicht. Nach diesem Schritt erhlt man eine nach [TH07] gltige Implementierung die ausgegeben werden kann.
Abbildung 3.2: Optimierungsschritt des Mappings
3.3.2
Kodierung
Aufbauend auf dem oben denierten Modell besteht der nchste Schritt in der Konzeptions eines Mappings. Unabhngig von dem fr die Implementierung ver-
37
wendeten Framework ist als erstes eine Konvertierung der Modelle in ein fr die Optimierung zugngliches Format ntig. Eine naheliegende Mglichkeit besteht darin, die das Mapping binr zu kodieren. Wie in 2.1.2 beschrieben besitzen alle Elemente sogenannte Aktivierungsattribute die angeben, ob ein Element in einem Mapping vorkommt oder nicht. Elemente des Problemgraphen werden blicherweise vollstndig bernommen, da davon ausgegangen wird dass alle modellierten Elemente auch in der Lsung vorkommen mssen. Eine Ausnahme bilden jedoch die Funktionsalternativen die nicht vollstndig bernommen werden, sondern lediglich eine Variante. Hierzu wird jedes Element kodiert und eine Variante ausgewhlt. Bei dem Architekturgraphen ist zustzlich noch zu beachten, dass ganze Elemente wegfallen knnen, falls diese im Mapping nicht bentigt werden. Eine so erzeugte Lsung ist jedoch nicht unbedingt gltig, da zu diesem Zeitpunkt noch keine berprfung der Randbedingungen stattgefunden hat. Nach der Auswahl einer Lsung muss deswegen zunchst geprft werden, ob die gefundene Lsung auch gltig ist und keine Bedingungen verletzt werden. Hierzu wird geprft ob die Ausfhrungseinheiten alle Befehle untersttzten die von den auf sie abgebildeten Operationen verlangen und ob eine Kommunikationsverbindung zu allen nachfolgenden Operationen existiert.
3.3.3
Scheduling
Nachdem eine Architektur gewhlt wurde deren Eigenschaften eine Ausfhrung des Problemgraphen ermglichen muss als nchstes ein Scheduling ermittelt werden. Wie in Abschnitt 2.3.3 beschrieben ist es nicht ntig, dass beim Scheduling jede Operation exakt eine Ausfhrungseinheit zur Verfgung hat. Gibt es mehrere mgliche Ausfhrungseinheiten auf denen eine Operation ausgefhrt werden kann, dann ist es ntig die Operationen auf die verschiedenen Hardwareelemente abzubilden, analog zu dem Mapping der Systemsynthese. Da sich hierbei jedoch keine weiteren mglichen Kombinationen entstehen wird in dieser Arbeit jeder Operation genau die Ausfhrungseinheit zugewiesen die im Mapping der Systemsynthese ermittelt worden ist.
3.3.4
Bewertung
Im Anschluss an die Ermittlung des Scheduling ndet die Bewertung der gefundenen Lsung statt. Hierzu werden die Kosten und die Ablaufzeit berechnet. Die Kosten ergeben sich dabei aus den verwendeten Hardwareelementen. In der in
38
dieser Arbeit verwendeten Architektur sind die Kosten der Kommunikationsverbindungen zunchst in den Kosten der Ausfhrungseinheiten enthalten um die Komplexitt nicht zu gro werden zu lassen. Die Zeit besteht aus der Zeit die fr den Transport der Daten bentigt wird und aus der Zeit die die Ausfhrung einer Operation auf einer Ausfhrungseinheit in Anspruch nimmt.
3.4
Zusammenfassung
Beginnend mit der Anforderungsanalyse in Abschnitt 3.1 wird in diesem Kapitel das Konzept fr ein Mapping erstellt indem zunchst die Modelle des ArchitectureMapGraph erweitert werden. Die Erweiterungen bestehen aus einem Hierarchieebenen entsprechend 2.1.2 und einem abstrakten Modellkonzept. Anschlieend wird das Mapping analysiert und der zyklische Optimierungscharakter in 3.2 dargestellt, sowie das Mapping in die drei wesentliche Schritte Kodierung, Scheduling und Bewertung eingeteilt. Hierauf aufbauend wird nun das Konzept konkretisiert um es in eine Implementierung zu berfhren.
39
KAPITEL 4
Implementierung
In diesem Kapitel werden die in Kapitel 3 erarbeiteten Konzepte im Hinblick auf eine konkrete Implementierung erweitert. Dazu wird zunchst die Softwareumgebung beschrieben in der entwickelt wird, bevor anschlieend die eigentliche Umsetzung der Konzepte erfolgt.
4.1
Softwareumgebung
Fr die Evaluation der in Kapitel 3 vorgestellten Konzepte wird im Rahmen dieser Arbeit ein Tool fr das Mapping im Rahmen der Systemsynthese entwickelt. In diesem Abschnitt werden kurz die Grundlagen aus Sicht der Implementierung beschrieben. Grundgerst fr das Tool ist die Eclipse Rich Client Platform, die es ermglicht eine plattformunabhngige Anwendung zu schreiben, die zudem dank des OSGi Frameworks eine modulare und somit erweiterbare Plattform fr die Programmentwicklung darstellt. Die Modelle selbst liegen in Form des Fachgebiet internen ArchitectureMapGraph Formats vor und fr das Mapping selbst wird das PISA Framework zu Einbindung von Suchalgorithmen verwendet.
4.1.1
Eclipse Rich Client Platform
Die Eclipse Rich Client Platform (RCP) bietet die Mglichkeit Programme in Java zu schreiben und auf beliebigen Java Virtual Machines laufen zu lassen. Dies ermglicht es auf sehr einfache Weise platformunabhngige Anwendungen zu erstellen. Eine Einfhrung zu diesem Thema bietet [SJB08]. Auf Grund des OSGi Kern bietet eine Eclipse RCP eine gute Mglichkeit Code z.B. in Form von Algorithmen sogar zur Laufzeit einzubinden. Das dies zwar als Grundlage fr die Arbeit verwendet wird, jedoch nicht der eigentliche Kern der Arbeit ist wird an dieser Stelle nicht weiter auf diesen Bereich eingegangen.
40
2011-05-02/035/IN03/2231 - Kapitel 4. Implementierung
4.1.2
Eclipse Modeling Framework
Der ArchitectureMapGraph ist ein an der TU Ilmenau entstandenes Modell zur Beschreibung von Architekturabbildungen. Seine wesentlichen Bestandteile sind ein Datenussgraph zur Beschreibung von Programmen und ein Platformgraph zur Beschreibung von Architekturen. Die Formulierung des Modells ist mit Hilfe des Eclipse Modeling Frameworks entstanden. Dieses Framework bietet nicht nur die Mglichkeit der Modellierung, sondern auch der automatisierten Code Generierung aus den Modellen. Eine Einfhrung hierzu ndet sich in [SBPM09].
4.1.3
Implementierung von PISA
PISA ist, wie in Abschnitt 2.4.2.4 beschrieben, ein Plattform unabhngiges Framework fr Suchalgorithmen. Es handelt sich dabei allerdings weniger um ein echtes Framework als vielmehr um eine reine Schnittstellen Denition die um einige Beispielimplementierungen erweitert worden ist. Auf der Homepage [EZ09] stehen Implementierungen zur Verfgung auf denen die in dieser Arbeit entwickelten PISA Module beruhen. Suchalgorithmen bestehen im Framework aus einem Selector und einem Variator. Dabei stellt der Selector den eigentlichen Suchalgorithmus dar, whrend der Variator fr den problemspezischen Teil zustndig ist. Fr die Synchronisation werden die in Abschnitt 4.1.3.1 beschriebene Zustnde verwendet. Der in dieser Arbeit verwendete evolutionre Algorithmus verwendet dabei einen Generationszhler als Abbruchkriterium. 4.1.3.1 Zustnde PISA verwendet ein System aus elf Zustnden von denen sieben eine feste Bedeutung haben und fnf problemabhngig belegt werden knnen. Die Zustnde sind in Tabelle 4.1 zusammengefasst. Die Zustnde 5,7,9 und 11 sind nicht weiter belegt und knnen z.B. genutzt werden um direkt in die Zustnde 6,8,10 bzw. 0 berzugehen. Der Zyklus zwischen den Zustnden 2 und 3 wird berlicherweise durch einen bergang in Zustand 4 beendet sobald die maximale Anzahl von Generationen wurde. 4.1.3.2 Selector Der Selector ist die problemunabhngige Komponente eines Suchalgorithmus. Im Falle eines evolutionren Algorithmus reprsentiert er die Umweltselektion, also
4.1. Softwareumgebung - 2011-05-02/035/IN03/2231

Zustand 0 1 2 3 4 6 8 10 Beschreibung Variator initialisieren, Startpopulation erzeugen Selector initialisieren Individuen variieren Individuen fr die nchste Generation auswhlen Variator Terminierung Selector Terminierung Variator Reset Selector Reset Folgezustand 1 2 3 2 5 7 9 11
41
Tabelle 4.1: PISA Zustandsbersicht die Auswahl der Individuen die fr die nchste Generation ausgewhlt werden. Die Auswahl der Algorithmen erfolgt dabei aus der aktuellen Population, in PISA auch Archiv genannt. Innerhalb des Archivs werden Individuen ber eine eindeutige ID identiziert und ber sogeannte objective values charakterisiert. Diese objective values entsprechen den Fitnesswerten, bzw. den Funktionswerten der Zielfunktion. Das PISA Framework ist per Denition ein Minimierungsframework, so dass das Ziel des Algorithmus die Minimierung der objective values ist. 4.1.3.3 Variator Der Variator ist der problemabhngige Teil des Suchalgorithmus. Im Rahmen dieser Arbeit wurde eine binre Kodierung des Suchraums gewhlt, um eine mglichst kompatible Schnittstelle fr verschiedene Suchalgorithmen zu schaen. Von einem Mapperelement, dass diese Kodierung vornimmt erhlt der Variator nun den binren String und sorgt fr die Verwaltung der Population sowie die Erzeugung neuer Individuen durch Anwendung von evolutionren Operatoren. Aus Zeitgrnden wurden hierfr die beiden Basisoperatoren Rekombination und Mutation verwendet, wie sie fr die meisten evolutionren Algorithmen blich sind. 4.1.3.4 Selector-Variator-Schnittstelle Die Kommunikation zwischen Selector und Variator ndet ber Textdateien mit fester Struktur statt. Da die genaue Struktur im Rahmen dieser Arbeit nicht von Interesse ist sei hier auf [BLTZ03] verwiesen. Eine solche Schnittstelle ermglicht es ohne groen Aufwand Selector und Variator auf verschiedenen Rechnern oder Plattformen zu implementieren. Das fr diese Arbeit erstellte Programm ld Variator und Selector in unterschiedlichen Threads ber die Eclipse Job API. Innerhalb der Schnittstelle werden die Individuen ber eine eindeutige ID identiziert und ber die konkreten Werte der Zielfunktion charakterisiert.
42
4.2
Modelle
Als nchstes werden die Modelle erweitert. Die ersten beiden Abschnitt befassen sich mit den Problem- und Architekturgraphen. Anschlieend wird die in der Anwendung verwendete Projektstruktur gezeigt, die sich eng an das Modell anlehnt. Abschlieend wird der fr die Eigenschaften entworfene Editor vorgestellt, der die Eigenschaften der Elemente in tabellarischer Form darstellt.
4.2.1
Hierarchisierung
In Abschnitt 3.2 ist die Hierarchisierung des ArchitectureMapGraph bereits vorbereitet worden. Fr eine praktische Umsetzung der Erweiterung mssen noch einige Details festgelegt werden. Fr die Kompatibilitt mit anderen Anwendungen die auf dem AMGraph basieren ist es sinnvoll die vorhandenen Graphelemente so zu erweitern, dass eine Abwrtskompatibilitt zu dem alten Modell besteht. 4.2.1.1 Problemgraph Als erster wird der Problemgraph um Hierarchieebenen erweitert. Fr die Realisierung eines Interfaces (I, O, , ) wird ein Knoten vom Typ Operation als Grundlage genommen. Dieser verfgt bereits mit arguments ber eine Menge I von eingehenden Kanten und mit results ber eine Menge O von ausgehenden Kanten. Da ein Cluster ein Problemgraph mit denierten Ein- und Ausgangsknoten ist, dass eine Aggregation zwischen Operation und DFGraph wie in Abb. 4.1 hinzuzufgen. Damit der aggregierte DFGraph ein korrektes Cluster abbildet muss sichergestellt werden, dass bei der Erzeugung die Ports im Graphen korrekt erzeugt werden und alle Daten die zum Interface fhren im Cluster von dem Port ebenfalls erzeugt werden. Die Menge muss im Modell nicht explizit angegeben werden, sofern die Daten die vom Port erzeugt werden eindeutig den Daten im Ursprungsgraphen zugeordnet werden knnen. In der vorliegenden Implementierung wird diese Zuordnung ber das Feld DatumID der Daten vorgenommen, so dass eine explizite Angabe der Menge entfllt. Fr die Implementierung eines Cluster (I, O, V, E, ) als DFGraph ist es ntig diesen mit einem expliziten Eingangsknoten I und einem Ausgangsknoten O auszustatten. Diese dienen als Verbindung mit dem Interface des einbettenden Graphen. Die Wurzel der Hierarchie enthlt als Spezialfall weder einen Eingangsknoten noch einen Ausgangsknoten. Die Menge aller Interfaces eines Clusters wird durch die Menge interfaces im Klassendiagramm reprsentiert. Die Eigenschaften des
4.2. Modelle - 2011-05-02/035/IN03/2231 Interfaces sind die Maxima der Einzelkomponenten.
43
Abbildung 4.1: Erweitertes Klassendiagramm des Problemgraphen
4.2.1.2 Architekturgraph Der Architekturgraph wird analog zum Problemgraphen erweitert. Dabei werden sowohl Ausfhrungseinheiten als auch Kommunikationskanle hierarchisch deniert. Da zwei Elemente hierarchisch aufgebaut sind werden fr die Interfaces e und c Knoten vom Typ ExecutionResource bzw. CommunicationResource verwendet. Jeder dieser beiden Interfaces reprsentiert eine vollstndige Plattform und knnen dementsprechend wieder aus Ausfhrungs- und Kommunikationseinheiten zusammengesetzt sein. Abb. 4.2 zeigt den erweiterten Architekturgraphen. Die Eigenschaften der Ressourcen sind mit Ausnahme der minimalen Paketgre die Maxima der Eigenschaften der Einzelkomponenten. Die minimale Paketgre des Interfaces ist die kleinste minimale Paketgre aller Einzelkomponenten.
44
Abbildung 4.2: Erweitertes Klassendiagramm des Architekturgraphen
4.2.2
Projektstruktur
Die Projektstruktur ist eng an das theoretische Modell der Systemsynthese angelehnt. Ein Projekt besteht aus den drei Komponenten Problemgraph, Architekturgraph und Mapping wie sie auch im ArchitectureMapGraph vorkommen. Abbildung 4.3 zeigt die Projektstruktur aus Sicht der Anwendung
Abbildung 4.3: Projektstruktur
4.2.3
Eigenschaften
Fr die Eigenschaften ist ein Editor entwickelt worden, der alle verwendeten Eigenschaften in tabellarischer Form darstellt. Abbildung 4.4 zeigt die Editoransicht fr die Operationen des komplexen Reglers.
4.3. Mapping - 2011-05-02/035/IN03/2231
45
Abbildung 4.4: Eigenschaftseditor
4.3
Mapping
Als nchstes werden die Konzepte des Mappings konkretisiert. Dazu gehrt auch Abschnitt 4.3.6 in dem auf die Klassenhierarchie der Individuen eingegangen wird.
4.3.1
Elementidentikation
Fr die Erzeugung eines konkreten Mappings ist es ntig alle Elemente eindeutig identizieren zu knnen. Fr die Anwendungen im Rahmen dieser Arbeit gengt es bereits jedem Elemente eine eindeutige ID zuzuweisen. In dieser Arbeit wird dazu der Hashcode der Objekte verwendet. Es ist jedoch zu beachten, dass hiermit nur eine statische Abbildung der Objekte mglich ist und somit das Problem und die Architektur vollstndig modelliert sein mssen. Allgemein ist es jedoch erforderlich diese IDs allgemeiner zu halten, um auch Instanziierungen von Elementen zu ermglichen. Im Bereich des Problemgraphen bedeutet dies z.B. Unterfunktionen nicht situationsabhngig neu modellieren zu mssen, sondern nur einmalig zu modellieren und anschlieend zu instanziieren.
46
Im Bereich des Architekturgraphen bedeutet eine Instantiierung, dass Architekturelemente nur einmalig modelliert werden mssen, und anschlieend in beliebiger Konstellation verwendet werden. Dies fhrt dazu, dass fr ein gegebenes Programm eine passende Architektur zusammengebaut werden kann.
4.3.2
Problemkodierung
Das Problem wird innerhalb der Anwendung fr eine einfache Handhabung durch den Optimierungsalgorithmus in eine Binrdarstellung transformiert. Fr die Zuweisung der Komponenten wie z.B. einer Ausfhrungseinheit an eine Operation wird zunchst die binre Lnge der Mchtigkeit der Menge aller Ausfhrungseinheiten ermittelt. Diese Binrzahl ist Teil der gesamten Kodierung und wird dementsprechend durch den Optimierungsalgorithmus verndert. Da die Mchtigkeiten nicht auf Zweipotenzen beschrnkt sind ist es mglich an dieser Stelle illegale Werte zu bestimmen. In diesem Fall ist die Anwendung so angelegt, dass die Individuen automatisch repariert werden indem andere Komponenten gewhlt werden. Sofern es eine gltige Kombination gibt, wird diese auch dem Individuum zugeordnet. Dies funktioniert allerdings nur dann gut, wenn es eine hinreichend hohe dichte legaler Lsungen im Suchraum gibt. Andernfalls wird ein unntig groer Teil der Rechenzeit fr die Reparatur der Lsungen bentigt.
4.3.3
Kommunikation
Das Mapping der Kommunikation ndet durch die Abbildung von Daten auf Kommunikationsressourcen ab. Um den Aufwand fr eine erste Implementierung im Rahmen zu halten wurde allerdings darauf verzichtet alle Daten einzeln abzubilden. Stattdessen wird fr jede Operation eine Liste von Nachfolgern und den abhngigen Daten erstellt. Diese Daten werden fr die Kommunikation als Einheit betrachtet und zusammen auf eine Kommunikationsressource abgebildet. Dabei wird davon ausgegangen, dass der Kommunikationskanal stndig verfgbar ist und nicht wie z.B. bei einem Bus belegt sein kann. Falls in der Architektur die Kommunikationsressource konkurrierend benutzt wird, dann ensteht bei der Berechnung in der aktuellen Implementierung eine Abweichung gegenber einer realen Implementierung.
4.3.4
Hierarchie
Auf Grund der geringen Problemgre werden in der Implementierung die Hierarchieebenen vor dem Mapping komplett aufgelst. Fr aufwendigere Programme
4.3. Mapping - 2011-05-02/035/IN03/2231
47
und Architekturen ist es jedoch ratsam die Hierarchietiefe zu berdenken. Dabei hngt die Wahl der Hierarchieebene in erster Linie von der Laufzeit des Mapping ab. Je weiter die Hierarchie aufgelst wird desto grer wird der Suchraum und desto aufwendiger wird das Mapping. Neben der reinen Laufzeit kann es auch sein, dass es weitere Beschrnkugen aus Sicht des Programms gibt, wenn es z.B. um die Ausfhrung von sicherheitskritischen Operationen geht die nur auf spezieller Hardware ausgefhrt werden sollen.
4.3.5
Scheduling
Das Scheduling der Operationen ndet ber eine einfache Partitionierung statt. Die verwendeten Partitionen erzeugen eine partielle Ordnung < unter den Operationen O, so dass fr abhngige Operationen O1 , O2 gilt: O1 < O2 . Diese partielle Ordnung ist nicht ausreichend um komplexe Abhngigkeiten zu modellieren. Da ein solches Scheduling fr die gegebenen Beispiele ausreichend und schnell zu implementieren ist, wird es in dieser Arbeit verwendet.
4.3.6
Individuen
In der Anwendung wurde die Funktionalitt der Individuen auf mehrere Klassen verteilt um den Code besser strukturieren und die einzelnen Teile einfacher auswechselbar zu gestalten. Die drei wesentlichen Klassen sind SynthIndividual, SynthSaver und SynthMapper. SynthIndividual. SynthIndividual ist eine Schnittstellenklasse deren Aufgabe darin besteht den SynthMapper, SynthSaver und die Fitnesswerte zu verwalten und an aufrufende Klassen weiterzuleiten. SynthSaver. Der SynthSaver ist fr die Speicherung der Mappings zustndig. Um parallele Zugrie auf die Mappingdatei zu verhindern werden in die Mappings von den Individuen an diese Klasse bergeben und gepspeichert. Da alle Graphen gleichwertig in der Graphdatei gespeichert werden, ist diese Klasse nur fr die Synchronisation der Zugrie zustndig. SynthMapper. Der SynthMapper ist fr die Verwaltung der einzelnen Mappings zustndig. Er verwaltet die Graphen, eine Liste aller Teilmappings fr dieses Individuum sowie die ntigen Zielfunktionen um die Fitnesswerte des Individuums
48
zu berechnen. Nach Abschluss des Mappings werden in dieser Klasse die Eintrge fr den Mappingraphen erzeugt, die anschlieend mit Hilfe des SynthSavers gespeichert werden.
4.4
Zusammenfassung
Die Konzepte aus Kapitel 3 sind nun um Implementierungsdetails erweitert und in Form eines Prototyps umgesetzt. Neben den Hierarchieebenen wurde auch das Eigenschaftskonzept in das EMF Modell des ArchitectureMapGraph eingearbeitet. Allerdings sind die Eigenschaften so abstrakt gehalten, dass sie erst bei einer konkreten Implementierung speziziert werden mssen. Zur Validierung steht in jedem Mapping ein regulrer Ausdruck zur Verfgung um zu testen, ob alle fr ein konkretes Mapping vorhanden Eigenschaften vorhanden sind. Die Integration der PISA Schnittstelle ermglicht es auerdem sehr einfach den verwendeten Optimierungsalgorithmus zu wechseln. Somit ist eine mit einem einfach erweiterbaren Eigenschaftskonzept und einer auswechselbaren Algorithmik entstanden. Als nchster Schritt folgt nun die Evaluierung des Prototyps in Kapitel 5, um die Implementierung besser an ihren Einsatz anzupassen und die Umsetzung des Konzepts beurteilen zu knnen.
49
KAPITEL 5
Evaluation
Die Evaluation gliedert sich in zwei Abschnitte. Im ersten Abschnitt werden die generierten Lsungen mit denen der Arbeit [Kon10] verglichen. Im zweiten teil folgt die Untersuchung der Auswirkungen der Parameter auf die entstehenden Lsungen. Dabei werden zunchst die Parameter des PISA Frameworks untersucht, bevor auf die Parameter des Variators eingegangen wird. Die Parameter des Selectors werden hier nicht weiter bercksichtigt, da dieser als problemunabhngiger Lsungsteil nicht Teil der hier entwickelten Anwendung ist.
5.1
Vergleich zu einem Partitionierungsbeispiel
In der Arbeit ebenfalls im Fachgebiet entstandenen Arbeit [Kon10] ist ein Verfahren zur Partitionierung von Problemgraphen auf Architekturgraphen beschrieben. Hierfr wurde beispielhaft ein Scheduling fr einen komplexen Regler erzeugt. Dieser Regler wird auch in dieser Arbeit als Beispiel verwendet, so dass ein Vergleich mglich ist. Jedoch gibt es zwei Punkte die einen Vergleich erschweren. Der erste Punkt sind die fehlenden bertragungskosten. Beim Scheduling in [Kon10] werden lediglich die Ausfhrungszeiten der Operationen auf den Ausfhrungseinheiten betrachtet, eine Bercksichtigung der Kommunikationszeiten ndet nicht statt. Dies fhrt zu geringeren Laufzeiten als wenn diese bercksichtigt werden. Der zweite Punkt ist die Fixierung auf eine spezielle Hardwarearchitektur, im Gegensatz zu der hier verwendeten automatisierten Hardwareauswahl. Die Lsungen die der in [Kon10] betrachteten Hardwarekonguration entspricht weisen jedoch hnliche Ausfhrungszeiten auf.
50
2011-05-02/035/IN03/2231 - Kapitel 5. Evaluation
5.2
Parameterkonguration
Fr die Einstellungen der Algorithmen steht eine Reihe von Parametern zur Verfgung, deren Auswirkungen im Folgenden kurz erlutert wird. Abschnitt 5.2.1 geht dabei auf die vor dem Mapping whlbaren Parameter ein, whrend der Abschnitt 5.2.2 auf die Auswirkungen verschiedener Startpopulationen eingeht.
5.2.1
Paramter
Abbildung 5.1 zeigt das Einstellungsmen fr die Parameter der Suchalgorithmus. Neben der Auswahl eines Selectors, eines Variators sowie des verwendeten Namensraums fr die Kommunikationsdateien sind in der Auswahl die vier allgemeinen Parameter des PISA Frameworks zu sehen. Diese sind , , , dim. gibt die
Abbildung 5.1: Fr das PISA Framework bentigte Parameter Gre der Startpopulation an. Um den Suchraum gut abzudecken empehlt es sich die Zahl der Individuen nicht zu klein anzusetzen. Um die Populationen noch zu Entwicklungszwecken berschauen zu knnen wurde die Populationsgre hier zunchst auf 20 gesetzt. Um die Population stabil zu halten werden hier und kleiner als gewhlt. gibt die Anzahl der als Eltern gewhlten Individuen vor, whrend die Anzahl der neu erzeugten Individuen angibt. Es wre auch mglich die Population in jeder Runde wachsen zu lassen und sie im Variationsschritt durch Entfernung schlechter Individuen wieder zu verkleinern. Ein solches Ansatz ist aus Zeitgrnden allerdings hier nicht umgesetzt, so dass und nicht grer als gewhlt werden sollten.
5.2. Parameterkonguration - 2011-05-02/035/IN03/2231
51
Abbildung 5.2 zeigt die Parameter des Variators. Wichtig sind hierbei die Generationsanzahl, da diese indirekt auch die mgliche Suchraumabdeckung beeinusst. Ein Wert von 0,1 als bitip probability hat sich als hinreichend gut erwiesen, um die Individuen in jeder Runde merklich zu verndern. Dieser Wert beeinusst die Diversitt innerhalb der Individuen, whrend die Rekombination zu einer Konvergenz fhrt. Allerdings konnte fr die Rekombinationswahrscheinlichkeit aus Zeitgrnden kein guter Wert gefunden werden.
Abbildung 5.2: Parameter fr den Variator
5.2.2
Startpopulation
Um eine mglichst breite Auswahl an verschiedenen Startpopulationen zu erhalten werden zu Beginn des Mappings Individuen zufllig erzeugt. Der Optimierungsalgorithmus verwendet ein rundenbasiertes Abbruchkriterium, so dass eine vollstndige Abdeckung des Suchraums mglich ist und nicht durch eine ungnstige Wahl der Startpopulation eine Konvergenz zu einem lokalen Optimum erzwungen werden kann. Die Wahl von guten Startpositionen hat bei Optimierungsalgorithmen im Allgemeinen eine deutliche Beschleunigung des Verfahrens zur Folge. Da das Algorithmische Erzwingen von speziellen Individuen jedoch sehr zeitintensiv ist, ist ein direkter Vergleich mit den Lsungen aus [Kon10] als Startpopulation nicht fertig geworden.
52
2011-05-02/035/IN03/2231 - Kapitel 5. Evaluation
5.3
Zusammenfassung
Da die Evaluationsphase zeitlich leider sehr begrenzt stattnden musste konnten keine detailierteren Analysen auf Basis der Lsungen aus [Kon10] durchgefhrt werden. Dafr wurden jedoch die Auswirkungen der Parameter fr die Algorithmen untersucht. Dabei hat sich gezeigt, dass rundenbasierte Verfahren im Gegensatz zu schwellwertbasierten Verfahren das Problem haben den Zeitpunkt der Konvergenz zu bestimmen. Die in Abschnitt 5.2.1 genannten Werte scheinen jedoch eine zgige Konvergenz zu ermglichen, um die erzeugten Lsungen zu beurteilen.
53
KAPITEL 6
Zusammenfassung und Ausblick
In diesem Kapitel werden die Ergebnisse der Arbeit kurz zusammengefasst und anschlieend ein Ausblick auf bestimmte Themen gegeben, die sich whrend der Arbeit als interessante Ansatzpunkte gezeigt haben. Thematisch fallen diese Punkte in die Bereiche Eigenschaften, Scheduling, Informationskodierung und Parallelitt.
6.1
Zusammenfassung
Ausgangspunkt der Arbeit ist der Mappingschritt der Systemsynthese. Als Modell wird der im Fachgebiet erstellte ArchitectureMapGraph verwendet. Das Ziel der Arbeit besteht darin eine Konzeption und eine Implementierung fr ein solches Mapping zu erzeugen, dass die Modelle um Hierarchieebenen und Eigenschaften erweitert, Auswechselbarkeit im Bereich der Algorithmik ermglicht und fr den Optimierungsschritt des Mappings einen evolutionren Algorithmus verwendet. Sowohl in der Konzeption als auch in der Implementierung wurden alle diese Ziele umgesetzt und in Kapitel 5 an Hand des Beispiels eines komplexen Reglers getestet. Fr diesen wurden die Daten mit den Ergebnissen aus [Kon10] verglichen. Dort wurde fr diesen Regler eine Partitionierung berechnet, allerdings noch ohne die Betrachtung von Kommunikationskosten. Ein Vergleich der Lsungen ist allerdings schwierig, da sowohl durch die fehlenden Kommunikationskosten als auch durch die whlbare Anzahl an Hardwarekomponenten Unterschiede bestehen. Der Ansatz eines automatisierten Schaltungsdesigns ist erfolgversprechend, allerdings gibt es noch einige Probleme z.B. im Bereich der hohen Problemabhngigkeit. Die meisten existierenden Frameworks sind sehr problemabhngig und eine Erweiterung auf viele unterschiedliche Probleme ist schwierig. Der modulare Ansatz der in dieser Arbeit umgesetzt wurde ist interessant, ohne die Umsetzung z.B. der in 6.2 genannten Erweiterungen jedoch den problemspezischen Lsungen nicht berlegen.
54
2011-05-02/035/IN03/2231 - Kapitel 6. Zusammenfassung und Ausblick
6.2
Ausblick
Whrend der Erstellung dieser Arbeit sind einige Ansatzpunkte fr zuknftige Arbeiten entstanden, die an dieser Stelle Erwhnung nden. Dazu gehren erweiterte Eigenschaften, umfassenderes Scheduling, eine erweiterte Art der Informationskodierung sowie ein hherer Grad an Parallelitt zur Beschleunigung der Anwendung.
6.2.1
Eigenschaften
Das System der Eigenschaftsbehandlung ist bewusst einfach und erweiterbar gehalten, um zuknftige Modikationen zu erleichtern. Aktuell ist es lediglich mglich maximale Plattformen vorzugeben und automatisiert Elemente aus diesen beim Mapping nicht zu bercksichtigen. Es ist allerdings noch nicht mglich Plattformen vllig frei zu entwerfen. So fehlt aktuell noch eine Mglichkeit Architekturkosten nicht fest sondern stckzahlbasiert anzugeben. Somit wre es mglich nur Grundzge einer Plattform festzulegen und die Plattform automatisiert erweitern zu lassen um bestimmte Optimalittsbedingungen zu erfllen.
6.2.2
Scheduling
Das Scheduling ist gleich in mehreren Richtungen erweiterbar. Eine Richtung ist eine Verbesserung des Operationsscheduling, dass es ermglicht auch komplexe Ressourcenabhngigkeiten verarbeiten und somit optimale Ablaufplne auch unter mglichen Deadlock Zustnden zu ermglichen. Fr eine solche Aufgabe knnte z.B. das in Abschnitt 2.4 erwhnte SymTA/S Framework benutzt werden. Eine weitere Richtung ist die Implementierung eines erweiterten Schedulings unter Bercksichtigung von Kommunikationsressourcen. In der aktuellen Implementierung wird angenommen, dass Kommunikation immer mglich ist. Allerdings im Fall von z.B. Bus-Systemen ist es erforderlich ein Scheduling der Datenpakete vorzunehmen, da nur ein Paket gleichzeitig den Bus benutzen kann. Zwar ist es mglich mit Hilfe eines Multiplexers den Bus parallel zu nutzen, jedoch ist im Fall eines Zeit Multiplexers zu beachten, dass die maximalen Transferraten unter Volllast und whrend der alleinigen Nutzung unterscheiden.
6.2.3
Informationskodierung
In der aktuellen Implementierung wird der Suchraum lediglich zusammengesetzt, ohne auf spezielle Eigenschaften des Suchraums Rcksicht zu nehmen. Aus Sicht
6.2. Ausblick - 2011-05-02/035/IN03/2231
55
der Optimierung handelt es sich lediglich um einen homogenen binren String, dessen Interna erst nach einem Optimierungsschritt ausgewertet werden. Eine erste Verbesserung besteht darin, die Kodierung der Elemente so zu verschieben, dass mglichst nur kleine Sprnge im Suchraum auftreten. Im Falle von DSP und FPGA Lsungen, knnte darauf geachtet werden, dass die Kodierungen fr DSPs und FPGAs in unterschiedlichen Teilen des Suchraums liegen, oder die Lsungen entsprechend anderer Kriterien gemischt werden. Ein solches Kriterium kann z.B. eine Kostenfunktion sein und die Hardwarekomponenten knnen so angeordnet werden, dass sie entsprechend den Gesamtkosten des Systems angeordnet sind. Eine solche Anordnung kann die Ezienz eines Optimierungsalgorithmus deutlich steigern, da die Algorithmen hug von der Annahme einer kontinuierlichen Verteilung ausgehen. Dementsprechend htten Lsungen mit hnlichen Charakteristiken auch sehr hnliche Kodierungen. Eine weitere Verbesserung besteht darin auf unterschiedliche Teile des Suchraums unterschiedliche Optimierungsverfahren anzuwenden. So knnte untersucht werden, ob die Anwendung verschiedener Optimierungsverfahren z.B. fr Bindung und Scheduling, eine Auswertung auf die Konvergenzgeschwindigkeit hat.
6.2.4
Parallelitt
Die Umsetzung der Parallelitt ist in der aktuellen Implementierung auf den Variator und den Selector beschrnkt. Falls die Anwendung nicht nur auf einzelnen Prozessoren, sondern auf Mehrprozessorsystemen, dann ist es sinnvoll das Programm so zu erweitern, dass die einzelnen SynthMaps in separaten Threads ausgefhrt werden. Da fr die aktuelle Implementierung eine derart hohe Parallelitt nicht notwendig ist, wird zur Reduzierung des Overheads darauf verzichtet. Der Code ist jedoch bereits so unterteilt, dass eine Parallelisierung mglich ist. Da fr groe Anwendungen mit riesigen Architekturen die Ermittlung von Lsungen sehr aufwendig ist, kann es sich rentieren die Anwendung auf einem verteilten System laufen zu lassen. So knnen mehrere Individuen parallel berechnet werden. Innerhalb eines Individuums knnen verschiedene Aufgaben parallelisiert werden. Falls die in 6.2.3 genannten Erweiterungen durchgefhrt werden, dann knnen verschiedene Teile eines Individuums parallel berechnet werden. So knnte zur Ermittlung konkreter Ausfhrungszeiten ein Simulator verwendet werden, zur Berechnung des Scheduling ein eigenes Scheduling Framework, so dass sich insgesamt eine starke Verteilung der Berechnung ergibt. Ein solcher Aufwand lohnt sich allerdings erst bei sehr groen Problemen, da hierfr auch neue Probleme, z.B. im Bereich der Synchronisierung gelst werden mssen.
56
57
Anhang
Abbildungen
Abbildung A.1: Reglersystem (Simulink)
58
2011-05-02/035/IN03/2231 - Kapitel 6. Zusammenfassung und Ausblick
Abbildung A.2: Klassendiagramm des ArchitectureMapGraph
A. Abbildungen - 2011-05-02/035/IN03/2231
59
Abbildung A.3: Erweitertet ArchitectureMapGraph
60
61
Literaturverzeichnis
[App06]
David L. Applegate. The traveling salesman problem: a computational study. Princeton series in applied mathematics. Princeton Univ. Press, 2006. A. Bakshi and A. Ledeczi. Milan: A model based integrated simulation framework for design of embedded systems. In ACM SIGPLAN Notices, pages 8293, 2001.
[BL01]
[BLTZ03] Stefan Bleuler, Marco Laumanns, Lothar Thiele, and Eckart Zitzler. Pisa: a platform and programming language independent interface for search algorithms. In Proceedings of the 2nd international conference on Evolutionary multi-criterion optimization, EMO03, pages 494508, Berlin, Heidelberg, 2003. Springer-Verlag. [Bru01] [CHS02] Peter Brucker. Scheduling Algorithms. Springer, 2001. Oscar Cordon, Francisco Herrera, and Thomas Sttzle. A review on the ant colony optimization metaheuristic: Basis, models and new trends. Mathware & Soft Computing, 9:141175, 2002. Robert P. Dick and Niraj K. Jha. Cords: Hardware-software cosynthesis of recongurable real-time distributed embedded systems. In IEEE/ACM International Conference on Computer Aided Design, pages 6268, 1998. Robert P. Dick and Niraj K. Jha. Mogac: A multiobjective genetic algorithm for hardware-software co-synthesis of distributed embedded systems, 1998. Maciej Drozdowski. Scheduling for Parallel Processing. Springer, 2009. S. Dempe and H. Schreier. Operations Research: Deterministische Modelle und Methoden. Vieweg+Teubner, 2006.
[DJ98a]
[DJ98b]
[Dro09] [DS06]
62 [DT93]
2011-05-02/035/IN03/2231 - Literaturverzeichnis Bertsimas Dimitris and John Tsitsiklis. Simulated annealing. Statistical Science, 8(1):1015, 1993. Institut TIK ETH ZrichPisa - a platform and programming language independent interface for search algorithms, 2009. Online, accessed: May 24, 2011. L. J. Fogel, A. J. Owens, and M. J. Walsh. Articial Intelligence through Simulated Evolution. John Wiley, New York, USA, 1966.
[EZ09]
[FOW66]
[GGH+ 10] J. Gladigau, A. Gerstlauer, C. Haubelt, M. Streubuhr, and J. Teich. A system-level synthesis approach from formal application models to generic bus-based mpsocs. In Embedded Computer Systems (SAMOS), 2010 International Conference on, pages 118 125, july 2010. [GKK04] Ingrid Gerdes, Frank Klawonn, and Rudolf Kruse. Evolutionre Algorithmen. Vieweg, 2004. Jrn Gehring and Alexander Reinefeld. Mars a framework for minimizing the job execution time in a metacomputing environment. Future Gener. Comput. Syst., 12:8799, May 1996. Matthias Gries. Methods for evaluating and covering the design space during early design development. Integr. VLSI J., 38:131183, December 2004.
[GR96]
[Gri04]
[HFK+ 07] Christian Haubelt, Joachim Falk, Joachim Keinert, Thomas Schlichter, Martin Streubhr, Andreas Deyhle, Andreas Hadert, and Jrgen Teich. A systemc-based design methodology for digital signal processing systems. EURASIP J. Embedded Syst., 2007:1515, January 2007. [HHJ05] Rak Henia, Arne Hamann, and Marek Jersak. System level performance analysis - the symta/s approach. IEE Proceedings Computers and Digital Techniques, 2005.
[HMU02] J. Hopcroft, R. Motwani, and J. Ullman. Einfhrung in die Automatentheorie, Formale Sprachen und Komplexittstheorie. Pearson Studium, 2002. [JPT+ 10] Zai Jian Jia, Andy D. Pimentel, Mark Thompson, Toms Bautista, and Antonio Nez. Nasa: A generic infrastructure for system-level mp-soc design space exploration, 2010.
Literaturverzeichnis - 2011-05-02/035/IN03/2231 [Kon10]
63
A. Kondrat. Masterarbeit: Mapping von algorithmen und funktionalen systembeschreibungen auf architekturen unter nutzung von optimierungsstrategien. Masters thesis, TU-Ilmenau, 2010. Bernhard Korte and Jens Vygen. Kombinatorische Optimierung: Theorie und Algorithmen. Springer, 2008. Uwe Lmmel and Jrgen Cleve. Knstliche Intelligenz. Hanser, 2008.
[KV08]
[LC08]
[LMB+ 01] Akos Ledeczi, Miklos Maroti, Arpad Bakay, Gabor Karsai, Jason Garrett, Charles Thomason, Greg Nordstrom, Jonathan Sprinkle, and Peter Volgyesi. The generic modeling environment. In Workshop on Intelligent Signal Processing, 2001. [NR07] J Northern and M Ribeiro. Genie: A genetic algorithm model based integrated simulation framework for design of embedded systems. Region 5 Technical Conference 2007 IEEE, pages 223227, 2007.
[NTS+ 08] H. Nikolov, M. Thompson, T. Stefanov, A. Pimentel, S. Polstra, R. Bose, C. Zissulescu, and E. Deprettere. Daedalus: toward composable multimedia mp-soc design. In Proceedings of the 45th annual Design Automation Conference, DAC 08, pages 574579, New York, NY, USA, 2008. ACM. [PEP06] A.D. Pimentel, C. Erbas, and S. Polstra. A systematic approach to exploring embedded system architectures at multiple abstraction levels. Computers, IEEE Transactions on, 55(2):99 112, feb. 2006.
[SAC+ 04] Lui Sha, Karl-Erik Abdelzaher, Anton Cervin, Theodore Baker, Alan Burns, Giorgio Buttazzo, Marco Caccamo, John Lehoczky, and Aloysius K. Mok. Real time scheduling theory: A historical perspective. Real-Time Syst., 28:101155, November 2004. [SBPM09] David Steinberg, Frank Budinsky, Marcelo Paternostro, and Ed Merks. EMF: Eclipse Modeling Framework 2.0. Addison-Wesley Professional, 2nd edition, 2009. [SJB08] Heiko Sippel, Michael Jastram, and Jens Bendisposto. Eclipse Rich Client Platform. entwickler.press, 2008. Jrgen Teich and Christian Haubelt. Systeme. Springer, 2007. Digitale Hardware/Software-
[TH07]
64
2011-05-02/035/IN03/2231 - Literaturverzeichnis
[TTRE02] J. Teich, C. Taubelt, K. Richter, and R. Ernst. Modellierung rekongurierbarer systemarchitekturen. Methoden und Beschreibungssprachen zur Modellierung und Verikation von Schaltungen und Systemen, pages 2527, Feb 2002. [Wei02] [Zim08] Karsten Weicker. Evolutionre Algorithmen. Teubner, 2002. Hans-Jrgen Zimmermann. Operations Research: Methoden und Modelle. Vieweg, 2008.
Literaturverzeichnis - 2011-05-02/035/IN03/2231
65
Danksagung
Bedanken mchte ich mich in erster Linie bei meinen Eltern, die mich whrend meines ganzen Studiums untersttzt haben und mir den ntigen Rckhalt geboten haben um auch schwierige Situationen zu berstehen. Weiterhin mchte ich mich auch bei allen meinen Freunden bedanken, sowohl meinen alten Schulfreunden als auch denen die ich erst durch dieses Studium kennengelernt habe. Diese Arbeit wre nicht ohne die Hilfe des Fachgebiets Rechnerarchitekturen entstanden, so dass ich mich auch bei meinem Betreuer Dr.-Ing. Alexander Pacholik fr seine eifrige Hilfe.
66
67
Eidesstattliche Erklrung
Hiermit erklre ich an Eides statt, dass ich die vorliegende Arbeit selbststndig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Alle Stellen, die wrtlich oder sinngem aus verentlichten oder nicht verentlichten Schriften entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit hat in gleicher oder hnlicher Form noch keiner anderen Prfungsbehrde vorgelegen.
Ilmenau, den 30. Juni 2011
Benjamin Cool
68
2011-05-02/035/IN03/2231 - Literaturverzeichnis
Thesen
1. Das Mapping im Rahmen der Systemsynthese ist ein komplexes und aufwndiges Problem, so dass Hierarchieebenen fr die Modellierung eine deutliche Vereinfachung darstellen. 2. Verschiedene Problemstellungen verlangen die Modellierung unterschiedlicher Systemeigenschaften, was eine erweiterbare Modellierung der Eigenschaften fr die Systemsynthese vorraussetzt. 3. Unterschiedliche Optimierungskriterien verschiedener Problemstellungen machen es erforderlich die verwendeten Algorithmen austausch- und erweiterbar zu implementieren. 4. Bindung, Scheduling und Eigenschaftsauswertung sind komplexe Teilprobleme des Mappings in der Systemsynthese die zwar aufeinander aufbauen, aber separierbar und damit eigenstndig berechenbar sind. 5. Die Modellierung von Kommunikationskanlen ermglicht eine detailliertere Abbildung von Architekturen als eine ausschlieliche Betrachtung von Ausfhrungseinheiten. 6. Der Prototyp demonstriert die Umsetzung einer modularen Applikation auf Basis des OSGi Frameworks unter Einbundung des Eclipse Modeling Frameworks. 7. Die abstrakte Behandlung von Eigenschaften ermglicht eine Verbesserung des Mapping durch den Einsatz externer Programme, z.B. mit Hilfe eines Simulators zur Berechnung von Laufzeiten auf Ausfhrungseinheiten. 8. Fr viele Optimierungsalgorithmen ist es vorteilhaft wenn hnliche Lsungen auch hnliche Kodierungen aufweisen, weshalb es interessant ist zu untersuchen, ob der Vorteil eines entsprechend erzeugten Suchraums seine aufwendige Erzeugung rechtfertigt.
Ilmenau, den 30. Juni 2011
Benjamin Cool

Diplomarbeit BCool

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diplomarbeit BCool

Uploaded by

Copyright:

Available Formats

Technische Universitt Ilmenau Fakultt fr Informatik und Automatisierung Institut fr Theoretische und Technische Informatik Fachgebiet Rechnerarchitekturen

Architekturoptimierungen von heterogenen Plattformen

1 Einleitung 1.1 1.2 1.3 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Konzeption 3.1 3.2

Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.1 Problemgraph . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.2 Architekturgraph . . . . . . . . . . . . . . . . . . . . . . . . 33

iv 3.2.3 3.2.4 3.2.5 3.3

Systemsynthese . 3.3.1 bersicht 3.3.2 Kodierung 3.3.3 Scheduling 3.3.4 Bewertung

5 Evaluation 5.1 5.2

Inhaltsverzeichnis - 2011-05-02/035/IN03/2231 6.2.4

Anhang 57 A Abbildungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Literaturverzeichnis 64

2011-05-02/035/IN03/2231 - Kapitel 1. Einleitung

Struktur der Arbeit

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

Abbildung 2.1: berblick: Systemsynthese (nach [TH07])

2.1. Systemsynthese - 2011-05-02/035/IN03/2231

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

Abbildung 2.2: Spezikationsgraph des Reglers

Abbildung 2.3: Verfeinerung des Knotens V2b

2.1. Systemsynthese - 2011-05-02/035/IN03/2231

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

Abbildung 2.4: Lsungsraum mit Pareto Punkten

2.2. Optimierung - 2011-05-02/035/IN03/2231

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

2.2. Optimierung - 2011-05-02/035/IN03/2231

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

2.2. Optimierung - 2011-05-02/035/IN03/2231 2.2.2.4 TRAVELING SALESPERSON PROBLEM

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

2.2. Optimierung - 2011-05-02/035/IN03/2231

16 2.2.4.4 Tabu Suche

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

2.2. Optimierung - 2011-05-02/035/IN03/2231 2.2.4.6 Zusammenfassung

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

2.2. Optimierung - 2011-05-02/035/IN03/2231

Nullpunkt vorausgesetzt. Die Selektion erfolgt hauptschlich durch eine Umweltselektion.

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

2.2. Optimierung - 2011-05-02/035/IN03/2231

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

2.3. Scheduling - 2011-05-02/035/IN03/2231 2.3.1.1 Maschinenumgebung

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

2.4. Entwurfssysteme - 2011-05-02/035/IN03/2231

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

2.4. Entwurfssysteme - 2011-05-02/035/IN03/2231

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

GENIE MOGAC Simulation verteil- Systemsynthese ter Systeme von Echtzeitsystemen

Automatisierbarkeit Plattform Bemerkungen [BL01] [JPT+ 10] [NR07]

abgeschlossen (2003) nein Windows Programmfehler

keine entliche Version verfgbar -

2.4. Entwurfssysteme - 2011-05-02/035/IN03/2231

Tabelle 2.1: Gesamtbersicht Entwurfssysteme Teil 1

PISA Interface fr Suchalgorithmen Lastverteilung, statistische Daten vergangener Testlufe

MARS Scheduling von Echtzeitsystemen

CORDS Systemsynthese von verteilten Echtzeitsystemen Einsatz rekongurierbarer FPGAs

SystemCoDesigner Systemsynthese aus SystemC Beschreibungen Rapid Prototyping

formale Scheduling Analyse und symbolische Simulation

keine entliche Version verfgbar

frhe Testversion (Stand 2006)

keine entliche Version verfgbar

keine entliche Version verfgbar

Automatisierbarkeit Plattform Bemerkungen

nicht geprft Linux

2011-05-02/035/IN03/2231 - Kapitel 2. Grundlagen

Tabelle 2.2: Gesamtbersicht Entwurfssysteme Teil 2

2011-05-02/035/IN03/2231 - Kapitel 3. Konzeption