download - SPES 2020

Kosimulation im Kontext von SPES
Tayfun Gezgin, OFFIS
25. Juli 2011
Project name SPES2020
Accountability Tayfun Gezgin
QS-Accountability Herr Schachner (Embedded4You)
Created on 20.05.2011
Last changed 25. Juli 2011
Disclosure confidential
project open
public
Status work in progress
submitted
finished

Changes
No. Date
Change
Version
Changed
Chapter(s)
Description Author Status
1 20.05.2011 v0.1 – Setup document template TG work in progress
2 25.05.2011 v0.9 – First version of document TG work in progress
5 21.04.2011 v1.0 3 - 5 Improvements based on Review TG finished

Inhaltsverzeichnis
1 Einleitung 1
2 High Level Architecture 3
2.1 Aufbau der HLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Zeitmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Ordnung von Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Fortschreiten der logischen Uhren . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Time Regulating Federates . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4 Time Constrained Federates . . . . . . . . . . . . . . . . . . . . . . . 8
3 SPES Architektur Meta-Modell 10
3.1 Heterogeneous Rich Components . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 SPES Entwurfsraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 HLA im Kontext von SPES 14
5 Zusammenfassung und Ausblick 16
Bibliography 16
iii

1 Einleitung
Die Entwicklung von softwareintensiven technischen Systemen stellt eine zunehmend große
Herausforderung dar: Der wachsende Anteil der Funktionen, die durch Software gelöst werden,
sowie die steigende Vernetzung und die Integration bestehender heterogener Teilsysteme führt
zu Systemen mit hochgradig komplexen Abhängigkeiten. Da aus Kostengründen die Entwicklung
relativ zügig erfolgen muss, wird diese meist durch mehrere parallele Aktivitäten realisiert.
Diese parallelen Aktivitäten werden innerhalb eines Betriebes von unterschiedlichen Bereichen
oder extern durch Supplier Ketten bearbeitet. Diese Gruppen arbeiten mit einer eigenen Arbeitsplanung,
eigener Begriffswelt und eigenen Methoden und Tools weitgehend unabhängig
voneinander.
Die wesentlichen Probleme, die bei einer parallelen Entwicklung entstehen, sind eine Mehrfachspezifikation
gleicher Daten, Werkzeug- und Modellbrüche und die nicht rechtzeitige Weitergabe
von Schnittstellenänderungen. Beispielsweise hat jede Gruppe eigene Anforderungen
auf Entwicklungsgegenstände und spezifiziert die für sie relevanten Aspekte unabhängig von
den anderen Gruppen. Alle Anforderungen zusammen ergeben dann die gesamte Spezifikation
an den jeweiligen Entwicklungsgegenstand. In der Implementierungsphase werden Subsysteme
in den einzelnen Gruppen durch unterschiedliche Tools realisiert. Durch ausführbare Modelle
können hier frühzeitig Fehler durch Simulation oder formale Analysemethoden entdeckt und
korrigiert werden. Bleibt der Einsatz dieser Verifikationstechniken allerdings nur lokal, d.h. werden
diese nur auf den einzelnen Modellen der Gruppen durchgeführt, können Probleme in der
Integrationsphase entstehen. Erst zu dieser späten Projektphase werden dann Fehlplanungen,
Schnittstellenprobleme und Inkonsistenzen festgestellt. Aufwändige, nicht geplante Iterationszyklen,
die kostspielige Projektverzögerungen mit sich ziehen, sind die Folge.
Das Ziel des SPES Projektes ist es, diese Schwierigkeiten zu adressieren: In [4] wurde ein
Anwendungsbereichunabhängiges Meta-Modell zur Architekturmodellierung entwickelt, das
einen Ansatz bietet, um softwareintensive Systeme und deren Architektur strukturiert zu entwickeln
und somit unter anderem Integrationsprobleme zu verringern.
Das Meta-Modell basiert auf den Heterogeneous Rich Components (HRC) [5], das das Konzept
der Kontrakt-basierten Spezifikation realisiert. Bei einer Kontrakt-basierten Spezifikation
werden im Allgemeinen explizit Annahmen über das Eingangsverhalten eines Entwicklungsgegenstandes
von dem Systemkontext spezifiziert und Garantien über das Ausgangsverhalten an
den Kontext getroffen, an den sich der Entwicklungsgegenstand bei korrektem Einsatz hält, d.h.
wenn der Systemkontext sich innerhalb der Annahmen bewegt. Das “Rich” der HRCs bezieht
sich im Speziellen darauf, dass aspektspezifische Schnittstellenspezifikationen eindeutig erfasst
werden. Aspekte dienen zur Gruppierung der Spezifikation und kapseln sowohl funktionale
als auch extra-funktionale (z. B. Safety oder Real-Time) Eigenschaften von Entwicklungsgegenständen.
Das Meta-Modell bietet des Weiteren Abstraktions- und Verfeinerungstechniken sowie Sichten
(View) auf eine Architektur. Abstraktion im Allgemeinen erlaubt dem Entwickler, sich auf
die wesentlichen Probleme in einem Entwurfsschritt zu konzentrieren und unnötige Details auszublenden.
Das Meta-Modell bietet Abstraktionsebenen an, die es ermöglichen, einen Entwicklungsgegenstand
mit einer bestimmten Granularität zu beschreiben und somit in einer bestimm-
1/ 18

Kosimulation in SPES
ten Entwicklungsphase von irrelevanten Details auszublenden.
Ein Modell eines zu entwickelnden Systems kann mit mehreren Viewpoints assoziiert werden,
die Konstrukte und Regeln zum Beschreiben von unterschiedlichen Views des zu entwickelnden
Systems bieten. Der Begriff der Views und Viewpoints bezieht sich hierbei auf den IEEE Standard
1471-2000 [14]. Im Speziellen bietet das Meta-Modell hierzu einerseits Viewpoints, die
eine strukturell verschiedene Sichten auf das Modell realisieren - die sogenannten Perspektiven
- und andererseits Viewpoints, die orthogonal zur Struktur des Systems stehen und verschiedene
Aspekte von funktionalen und extra-funktionalen Eigenschaften des Entwicklungsgegenstandes
beschreiben.
Aspekt-Realisierungen von Subsystemen kann durch beliebige Tools erfolgen. Werden diese
Subsysteme mit ausführbaren Modellen realisiert, kann eine automatische Verifikation gegen ihre
Spezifikationen erfolgen. Durch Simulieren der entstehenden ausführbaren Modelle können
frühzeitig Designalternativen evaluiert und Fehler aufgedeckt werden, ohne vorher einen kostenintensiven
Prototypen erstellen zu müssen. Eine einzelne, monolithische Simulation kann allerdings
die Anforderungen und Bedürfnisse aller Anwender und Anwendungen nicht decken.
Aus diesem Grund wurde die High Level Architecture (HLA) von dem US-amerikanischen
Verteidigungsministerium entwickelt: Sie ist eine Softwarearchitektur für eine verteilte Modellierung
und Simulation. Die generelle Idee hierbei ist, dass verschiedene Simulatoren zu
einer Kosimulation zusammengeschlossen werden können. Anstelle eines einzigen Simulators,
der mehrere unterschiedliche Aufgaben realisieren müsste, können somit mehrere spezielle,
domänenspezifische Simulatoren eingesetzt werden. Die HLA legt hierzu funktionale Komponenten,
Design-Regeln und Schnittstellen fest und spezifiziert die Kommunikation zwischen
den am Simulationsverbund teilnehmenden Simulationssystemen.
Die Verwaltung einer Kosimulation - also insbesondere dem der Kommunikation zwischen
den einzelnen Simulatoren und dem der gemeinsamen Simulationszeit - übernimmt eine funktionale
Komponente der HLA, die als Runtime Infrastructure (RTI) bezeichnet wird. Die Kommunikation
zwischen einzelnen Simulationsteilnehmern, die auch als Federates bezeichnet werden,
läuft damit ausschließlich über diese zentrale Komponente. Der HLA Standard legt dabei
fest, wie die Kommunikation mit der RTI abzulaufen und wie die Schnittstelle zwischen den
Federates und der RTI auszusehen hat.
Die Verwendung der HLA im Kontext von SPES kann die Entwicklung von Systemen bereichern:
Das System wird zunächst mithilfe des Meta-Modells strukturiert entwickelt. Dabei
werden die einzelnen Subkomponenten und deren Schnittstellen durch Kontrakte spezifiziert.
Realisierungen von den Kompnenten können dann mittels Anbindung an die RTI durch eine
Kosimulation verifiziert weren.
Kontrakte können des Weiteren als weitere Federates in Form von Observern mit an die
Kosimulation angeschlossen werden und den Simulationsverlauf automatisch verifizieren. Ein
solcher Ansatz wurde in [12, 10] realisiert, in dem anstelle von Kontrakten QLTL-Formeln
(Quantitative Linear Time Temporal Logic) in Observer-Federates überführt wurden.
Das Dokument ist wie folgt gegliedert. Zunächst wird die High Level Architecture vorgestellt
und im Speziellen das Zeitmanagement in einer Kosimulation erläutert. In dem darauf folgenden
Abschnitt werden die Heterogeneous Rich Components und der SPES Entwurfsraum
eingeführt. In Abschnitt 4 wird der Einsatz von der HLA im Kontext von SPES vorgestellt.
Abschnitt 5 fasst schließlich das Dokument zusammen.
2/ 18

2 High Level Architecture
Die High Level Architecture (HLA) ist ein Framework für verteilte Modellierung und Simulation.
Sie wurde von dem US-amerikanischen Verteidigungsministerium entwickelt und später
von der Institute of Electrical and Electronics Engineers (IEEE) standardisiert.
Die generelle Idee der HLA ist, dass verschiedene Simulatoren zu einer Kosimulation zusammengeschlossen
werden können. Anstelle eines einzigen Simulationsmodells, das mehrere
unterschiedliche Aufgabenbereiche abdecken müsste, können somit mehrere spezielle,
domänenspezifische Simulatoren eingesetzt werden. Eine solche verteilte Simulation hat mehrere
Vorteile. Komplexe Simulationsmodelle sind im Allgemeinen umso rechenaufwendiger,
je höher der Detaillierungsgrad eines modellierten Systems ist. Wird ein solches Simulationsmodell
nun unterteilt in mehrere kleinere Teilsimulationen, so können diese auf verschiedenen
Prozessoren ausgeführt werden, sodass im Gegensatz zu dem monolytischen Simulationsmodell
die Rechenzeit verkürzt werden kann. Ein weiterer wesentlicher Vorteil einer solchen Modularisierung
ist die Wiederverwendbarkeit von bereits existierenden Komponenten.
Zur Realisierung einer verteilten Simulation bietet die HLA eine standardisierte Architektur
für Simulatoren. Damit die Interoperabilität für eine solche Kosimulation gegeben ist, müssen
sich die Komponenten der Kosimulation an gewisse Standards halten. Hierzu wird eine einheitliche
Schnittstelle definiert, die die Teilnehmer einer verteilten Simulation realisieren müssen.
Außerdem definiert die HLA eine gemeinsame Software Infrastruktur, die die Koordinierung
der Kosimulation übernimmt. Die Teilnehmer einer Kosimulation kommunizieren dann über
diese Software Infrastruktur. Sie ist eine zentrale Komponente und wird als Run Time Infrastructure
(RTI) bezeichnet [6]. Die HLA liefert dabei für eine RTI keine fertige Software, sondern
definiert nur die Dienste, die eine solche RTI den Kosimulationsteilnehmern bieten muss.
Auf die Dienste der RTI wird im Folgenden genauer eingegangen.
In diesem Kapitel wird zunächst eine allgemeine Übersicht der HLA gegeben. Im Anschluss
wird auf das Zeitmanagement konkreter eingegangen. Ziel dieses Kapitels ist es nicht, eine
vollständige Darstellung aller Funktionen der HLA zu bieten. Es steht dem interessierten Leser
frei, sich durch die im Verlauf dieses Kapitels genannten Quellen genauer zu informieren.
2.1 Aufbau der HLA
Eine HLA definiert einen Standard zum Aufbau einer Kosimulation zwischen mehreren Simulatoren,
die durch eine Run Time Infastructure (RTI) miteinander verbunden werden. Da neben
Simulatoren auch andere Komponenten an die RTI angeschlossen werden können, werden die
Teilnehmer einer Kosimulation auch als Federate, die Kosimulation selbst als Federation bezeichnet.
Die HLA besteht dabei aus drei Teilen, die im Folgenden aufgeführt sind [9]:
1. Federations-Regeln: Die Federationsregeln beschreiben die generellen Prinzipien der
HLA und spezifizieren die Dienstbereiche der Federates und der Federation selbst. Die
Regeln im Detail können in [7] nachgelesen werden.
3/ 18

Kosimulation in SPES
Abbildung 2.1: Funktionelle Komponenten einer HLA Federation [3]
2. Object Model Template (OMT): Objektmodelle der HLA stellen Beschreibungen der austauschbaren
Elemente einer Federation dar. Dabei spezifiziert die HLA zwei Typen von
Objektmodellen: In dem Federation Object Model (FOM) soll die Menge der Informationen
beschrieben werden, die innerhalb einer Federation ausgetauscht werden kann. Im
Gegensatz dazu soll ein Simulation Object Model (SOM) nur für jeweils ein Federate
beschreiben, welche Informationen dieses Federate anbietet und welche es von anderen
empfangen kann. Die Informationen stellen dabei Objektklassen und Interaktionen dar
[3, 8]. Objektklassen bestehen aus einer Menge von Attributen und beschreiben solche
Informationen, die beständig sind. Im Gegensatz dazu bestehen Interaktionen aus einer
Menge von Parametern und beschreiben Ereignisse, d.h. nicht beständige Informationen.
3. Schnittstellenspezifikation: Die Schnittstellenspezifikation definiert für Federates die
Schnittstelle zur RTI. Außerdem wird definiert, welche Dienste die RTI zur Verfügung
stellen muss, damit eine Kosimulation ermöglicht werden kann.
Die Spezifikationen aus diesen drei Teilen zusammen definieren ein Framework zum Erstellen
und zum Ausführen von HLA Federationen [9]. Um eine HLA Federation also aufbauen und
HLA konforme Federates erstellen zu können, müssen die in diesen drei Teilen aufgeführten
Spezifikationen eingehalten werden. Eine HLA Federation besteht dann aus mehreren funktionellen
Komponenten, die in Abbildung 2.1 aufgeführt sind. Die erste funktionelle Komponente
bilden die Federates. Wie eingangs bereits erwähnt, können neben Simulatoren auch andere
Komponenten wie beispielsweise eine Schnittstelle zu einem bemannten Simulator oder zu einer
passiven Datensammlungskomponente an einer HLA Federation teilnehmen [3]. Die zweite
funktionelle Komponente einer HLA Federation bildet die Schnittstelle zur RTI, die von jedem
Federate implementiert werden muss, um an einer Federation teilnehmen zu können. Die dritte
funktionelle Komponente bildet die RTI. Die RTI muss den Federates mehrere Dienste anbieten,
damit die Federation funktionieren kann. Die einzelnen Dienstbereiche der RTI sind im
Folgenden aufgeführt [6]:
• Federation Management Dienste stellen die grundlegenden Funktionalitäten zur
Verfügung, mit denen es einem Federate ermöglicht wird, eine Federation zu erstellen
und zu betreiben.
• Declaration Management Dienste ermöglichen den Datenaustausch zwischen den Federates
einer Federation und sind nach dem Observer Entwurfsmuster realisiert. Mit diesen
4/ 18

Kosimulation in SPES
Diensten können Federates deklarieren, welche Informationen sie generieren und welche
sie empfangen möchten. Anders ausgedrückt kann ein Federate ausdrücken, dass er Daten
für Instanzen einer bestimmten Objektklasse generieren kann oder daran interessiert ist,
Daten einer Objektklasse zu empfangen. Hierzu muss der Federate bei der RTI angeben,
für welche Objektklassen dieser Daten generieren kann bzw. an welchen er interessiert
ist, indem er entsprechende Objektklassen veröffentlicht (publish) bzw. sich für solche
anmelden (subscribe) .
• Object Management Dienste ermöglichen es für ein Federate, unter anderem Objektinstanzen
von entsprechenden Objektklassen zu erstellen, zu modifizieren und zu löschen.
So kann beispielsweise eine Aktualisierung von Attributenwerten einer Objektinstanz der
RTI mitgeteilt werden. Diese wiederum leitet die Aktualisierung den entsprechenden Federates,
die sich für die Objektinstanz interessieren, weiter. Solche Aktualisierungen von
Attributenwerten einer Objektinstanz werden im Folgenden als Nachrichten bezeichnet.
• Ownership Management Dienste regeln die Besitzrechte von Objektinstanzen. Dabei ist
anzumerken, dass jede Objektinstanz zu jeder Zeit genau einem Federate gehört. Nur der
Federate, das die Besitzrechte für eine Objektinstanz hat, kann die Werte der Attribute
der Objektinstanz aktualisieren. Die Besitzrechte können während der Kosimulation
wechseln.
• Time Management Dienste ermöglichen das Sortieren von Nachrichten, so dass kausale
Zusammenhänge während der Kosimulation nicht verloren gehen.
• Data Distribution Management Dienste, die das Senden sowie Empfangen von irrelevanten
Daten reduzieren sollen.
• Support Services Dienste, die es einem Federate unter anderem ermöglichen, über
Änderungen von vorher definierten Bedingungen informiert zu werden.
Der Zeitmanagement-Dienst soll im folgenden Abschnitt näher erläutert werden, da dieser
zum korrekten Ablauf einer Kosimulation wesentlich ist und zum Verständis des Ablaufs einer
Kosimulation beiträgt.
2.2 Zeitmanagement
Die Aufgabe des Zeitmanagements der RTI ist es, die logischen Zeiten aller Federates zu koordinieren.
Dies ist nötig, da jeder Federate eine eigene logische Zeit hat.
Das Zeitmanagement besteht aus zwei Komponenten [11], nämlich aus einem Dienst, der
Nachrichten bezüglich ihrer Ordnungsrelation sortiert und an die Empängerfederates weiterleitet
sowie aus einem Protokoll, das das Fortschreiten der logischen Zeiten aller Federates regelt.
2.2.1 Ordnung von Nachrichten
Die HLA definiert für Nachrichten zwei Ordnungstypen: Die einfache receive order (RO) leitet
Nachrichten in der Reihenfolge an die Empfängerfederates weiter, in der sie bei der RTI eingegangen
sind. Die Nachrichten werden also vorher nicht sortiert und es wird diejenige Nachricht,
die zuerst bei der RTI eingeht, dem Empfängerfederate als erstes geliefert. Die Zweite wird als
time-stamp order (TSO) bezeichnet. Hier werden Nachrichten mit einem Zeitstempel versehen,
sodass die RTI diese Nachrichten nach den Zeitstempeln sortieren und in dieser sortierten
5/ 18

Kosimulation in SPES
Reihenfolge den Empfangsfederates übermitteln kann. Nachrichten, die mit einem Zeitstempel
versehen wurden, werden im Folgenden als TSO-Nachrichten bezeichnet. Entsprechend werden
Nachrichten ohne Zeitstempel als RO-Nachrichten bezeichnet. Die RTI garantiert, dass ein
Federate niemals Nachrichten mit Zeitstemplen empfängt, die kleiner sind als derjenige Zeitstempel
der zuletzt empfangenen Nachricht. Die RTI erhält somit durch die TSO-Ordnung der
Nachrichten kausale Zusammenhänge.
2.2.2 Fortschreiten der logischen Uhren
Eine wesentliche Anforderung der RTI ist es, zu gewährleisten, dass kein Federate TSO-
Nachrichten empfängt, deren Gültigkeit abgelaufen ist, d.h. deren Zeitstempel kleiner ist als die
logische Zeit des Federates. Um dieses zu gewährleisten, wird ein Protokoll zum Fortschreiten
der logischen Zeit der Federates benötigt: Federates müssen explizit bei der RTI anfragen, ihre
logische Zeit fortschreiten lassen zu dürfen, was von der RTI genehmigt werden muss. Der
konkrete Ablauf des Protokolls sieht dabei wie folgt aus [11]:
• Der Federate fragt bei der RTI an, seine lokale Zeit auf einen Wert treq fortschreiten zu
lassen.
• Die RTI liefert dem Federate daraufhin sämtliche RO-Nachrichten sowie alle TSO-
Nachrichten, die einen Zeitstempel kleiner als bzw. gleich der beantragen Zeit treq haben,
die in der RTI über andere Federates eingegangen sind.
• Die RTI gewährt dem Federate das Fortschreiten seiner logischen Zeit, falls sie garantieren
kann, dass keine weiteren TSO-Nachrichten mit einem kleineren Zeitstempel als bzw.
gleichem Zeitstempel wie treq diesem gesendet werden können [6].
Das Fortschreiten der Zeit von Federates, die TSO-Nachrichten empfangen, hängt also implizit
von denjenigen Federates ab, die ihnen diese Daten zur Verfügung stellen.
Generell stellt die HLA es jedem Federate frei, die Zeitmanagement-Dienste zu nutzen.
Wichtigstes Mittel hierzu ist dabei der Typ eines Federates, den es durch zwei Flags bestimmen
kann [11]:
• Time Regulating : Falls ein Federate TSO-Nachrichten verschicken will, muss er das time
regulation Flag setzen. Damit deklariert sich der Federate als time regulating Federate.
• Time Constrained : Falls ein Federate TSO-Nachrichten empfangen will, muss er seinen
Status als time constrained Federate setzen.
Ein Federate kann hierbei sowohl time regulating als auch time constrained sein. Ein Federate,
der weder TSO-Nachrichten senden noch empfangen will, muss keinen der oben genannten
Typen setzten. Die beiden Typen suggerieren bereits den Beitrag eines entsprechenden Federates
zu der Koordinierung der logischen Zeiten aller restlichen Federates einer Federation: Ein
time constraint Federate darf seine logische Zeit nicht beliebig fortschreiten lassen, da dieser
TSO-Nachrichten von anderen Federates erwartet und somit TSO-Nachrichten mit Zeitstempeln
kleiner als seine logische Zeit empfangen könnte. Time regulation Federates bestimmen
damit implizit, bis zu welcher logischen Zeit die Federates, die von ihnen Daten erwarten, voranschreiten
dürfen, ohne diese Bedingung zu verletzen. Diese Eigenschaften werden in den
nächsten beiden Abschnitten genauer untersucht.
6/ 18

Kosimulation in SPES
Abbildung 2.2: Schnappschuss einer Federation zu einem Zeitpunkt, in dem sich die logischen
Zeiten aller Federates 10 betragen. Falls der Lookahead aller Federates
Null ist, können nur TSO-Nachrichten mit Zeitstempel t ′ = 10 an die
Empfängerfederates weitergeleitet werden. Beträgt der Lookahead dagegen L =
5, können alle TSO-Nachrichten mit Zeitstempel kleiner gleich 15 übermittelt
werden. [11]
2.2.3 Time Regulating Federates
Falls ein Federate TSO-Nachrichten senden will, muss der bei der RTI anfragen, das time
regulating Flag zu setzen. Nachdem die RTI dieses bestätigt, ist der Typ des Federates time
regulating.
Beim Setzen des Flags muss der Federate einen Lookahead angeben. Ein Lookahead ist
dabei eine positive Zahl, mit der der kleinst mögliche Zeitstempel bestimmt wird, den der Federate
einer TSO-Nachricht zuweisen kann [6]. Der kleinst mögliche Zeitstempel ergibt sich
dabei aus der Summe der aktuellen logischen Zeit des Federates und des Lookaheads.
Beantragt ein time constrained Federate bei der RTI seine logische Zeit auf einen bestimmten
Wert fortschreiten zu lassen, garantiert dieser Federate damit gleichzeitig, dass es keine TSO-
Nachrichten mit Zeitstempeln versieht, die kleiner sind als die Summe aus beantragter Zeit und
Lookahead (bzw. kleiner gleich dieser Summe, falls der Lookahead Null ist).
Abbildung 2.2 verdeutlicht den Nutzen des Lookaheads: Abgebildet ist ein Schnappschuss
einer Federation, in dem die logischen Zeiten aller Federates 10 betragen. Die Boxen stehen
für TSO-Nachrichten, die von den jeweiligen Federates noch nicht empfangen wurden, schon
aber in der RTI eingegangen sind und gepuffert wurden. Der Federate D bearbeitet zur aktuellen
Zeit die TSO-Nachricht mit Zeitstempel t ′ = 10. Nach dem Bearbeiten könnte der Federate allen
anderen Federates eine TSO-Nachricht senden. Ist der Lookahead von Federate D Null, so kann
Federate D diese Nachricht mit Zeitstempel 10 versehen. In Abbildung 2.2 ist dies durch die
roten Pfeile dargestellt. Damit müssten aber alle anderen Federates warten, bis Federate D seine
logische Zeit fortschreitet, um sicher zu gehen, dass sie eine solche Nachricht mit Zeitstempel
10 nicht in der Vergangenheit empfangen können. Ist der Lookahead jedoch auf beispielsweise
5 gesetzt, so können alle Federates ihre logischen Zeiten bis auf 15 fortschreiten lassen, ohne
auf Federate D warten zu müssen. Somit können alle in der Abbildung grün markierten TSO-
7/ 18

Kosimulation in SPES
Abbildung 2.3: Nachrichtenaustausch in einer Federation mit zwei Federates und der RTI
Nachrichten an die entsprechenden Federates übermittelt und von diesen bearbeitet werden. Mit
dem Lookahead wird also die parallele Bearbeitung von TSO-Nachrichten ermöglicht.
2.2.4 Time Constrained Federates
Time Constrained Federates sind Federates, die den time constrained Flag gesetzt haben. Sie
können damit von anderen Federates TSO-Nachrichten empfangen.
Um zu garantieren, dass alle TSO-Nachrichten rechtzeitig bei einem Federate ankommen,
d.h. ein Federate empfängt keine TSO-Nachricht, deren Zeitstempel kleiner sind als die logische
Zeit des Federates, muss die RTI für alle time constained Federates eine obere Zeitschranke
berechnen, bis zu der diese ihre logischen Zeiten fortschreiten dürfen. Diese obere Schranke
garantiert damit, dass time constrained Federates ihre Zeit nicht soweit fortschreiten können,
dass sie TSO-Nachrichten empfangen, deren Zeitstempel kleiner sind als die logische Zeit des
Federates. Diese obere Schranke wird als Greatest Available Logical Time (GALT) bezeichnet
[6]. Anfragen eines time constrained Federate, seine logische Zeit auf Werte kleiner dem GALT
fortschreiten zu lassen, können dann von der RTI direkt genehmigt werden. Beantragt ein time
constrained Federate jedoch seine Zeit über dem GALT fortschreiten zu lassen, so wird dies
von der RTI solange nicht gewährt, bis der GALT größer als die beantragte Zeit wird. Dies
ist dann der Fall, wenn time regulating Federates, von denen der betrachtete time constrained
Federate TSO-Nachrichten erwartet, ihre logischen Zeiten fortschreiten.
Neben dem GALT berechnet die RTI für alle time constrained Federates den Least Incoming
Time Stamp (LITS) . Der LITS gibt den kleinsten Zeitstempel einer TSO-Nachricht an, den ein
time constrained Federate in der Zukunft empfangen könnte [6]. Der LITS wird bestimmt durch
die logischen Zeiten der time regulating Federates (von denen der betrachtete time constrained
Federate TSO-Nachrichten empfängt) und deren Lookaheads.
Der Unterschied zwischen LITS und GALT soll durch das Beispiel in Abbildung 2.3 verdeutlicht
werden: In der Abbildung ist eine Federation mit zwei Federates und der dazwischen
liegenden RTI dargestellt. Der Federate A ist dabei ein time regulating Federate und
hat einen Lookahead L mit L = 0.3. Federate A hat bei der RTI Daten für eine Objektklasse
veröffentlicht, für die sich Federate B angemeldet hat. Somit bekommt Federate B von Federate
A TSO-Nachrichten geliefert. Federate B ist damit ein time constrained Federate. Die
Folge der Nachrichten, die zwischen diesen Federates und der RTI versendet werden, verläuft
in der Abbildung 2.3 von links nach rechts. Der Federate A fragt zunächst durch den Methodenaufruf
timeAdvanceRequest(t) bei der RTI an, seine logische Zeit auf den Wert t = 1
8/ 18

Kosimulation in SPES
fortschreiten zu lassen und bekommt dies direkt genehmigt, indem bei diesem die Methode
timeAdvanceGrant(t) aufgerufen wird. Nachdem es dann eine TSO-Nachricht mit Zeitstempel
1.3 über den Aufruf der Methode updateAttributeValues(t) sendet, erhöht
es seine logische Zeit auf 1.5. Der GALT des Federates B beträgt an dieser Stelle 1.8, d.h.
Federate B darf seine logische Zeit mit Werten kleiner als 1.8 fortschreiten lassen. Dies wird
sofort klar, da die RTI Kenntnis davon hat, welche TSO-Nachrichten der Federate B bis zu dieser
Zeiteinheit empfangen wird. Die nächste von Federate A generierte TSO-Nachricht darf nur
noch einen Zeitstempel von mindestens 1.8 haben. Der LITS jedoch beträgt 1.3, da der Federate
B die Nachricht mit diesem Zeitstempel noch nicht empfangen hat. Erhöht Federate B nun
seine logische Zeit auf 1.5, empfängt es alle Nachrichten mit einem kleineren bzw. gleichem
Zeitstempel, indem die RTI die Methode reflectAttributeValues(t) beim Federate
aufruft. In diesem Beispiel ist nach dieser Aktion der LITS gleich dem GALT.
9/ 18

3 SPES Architektur Meta-Modell
In diesem Abschnitt wird das Meta-Modell der Heterogeneous Rich Components und der SPES
Entwurfsraum vorgestellt. Dieses Kapitel soll nur eine Einführung in die wesentlichen Konzepte
bieten. Zu einer detaillierten Beschreibung des Meta-Modells sei der interessierte Leser auf [4]
verwiesen.
3.1 Heterogeneous Rich Components
Heterogeneous Rich Components (HRC) wurden in [16] eingeführt. Das Meta-Modell der HR-
Cs bietet ein Framework zum Durchführen eines komponentenbasierten Entwurfs. Eine Komponente
stellt dabei ein Modul dar, das eine bestimmte Funktionalität des zu entwickelnden
Systems kapselt und eine wohldefinierte Schnittstelle bietet. Ports stellen dabei die Interaktionspunkte
einer Komponente dar. Eine Komponente kann selbst aus Subkomponenten bestehen,
die miteinander verbunden sind und zusammen das Verhalten und die Funktionalität der
Komponente realisieren.
Abbildung 3.1: Komponente BasicAutomation ist zusammangesetzt aus Subkomponenten
Sensor, WidthCtrl und Actuator.
Ein Beispiel für eine HRC ist in Abbildung 3.1 dargestellt. Die Komponente
BasicAutomation hat zwei Eingangsports setPoint width und rawMaterial und
einen Ausgangsport material. Sie ist zusammengesetzt aus den Subkomponenten Sensor,
WidthCtrl and Actuator.
Neben diesen Standardkonzepten bietet die HRC Mittel, um eindeutige Schnittstellenspezifikationen
einer Komponente zu definieren. Das “Rich” der HRCs bezieht sich darauf, eine
Komponente eine aspektspezifische Spezifikation und eine Realisierung haben kann. Das “He-
10/ 18

Kosimulation in SPES
Abbildung 3.2: Der SPES Entwurfsraum.
terogeneous” bezieht sich darauf, das verschiedene Aspekte typischerweise verschiedene Modellierungselemente
verwenden.
Eine Spezifikation definiert, was eine Komponente machen soll. In HRC werden Spezifikationen
partitioniert in Aspekte, die funktionale und extra-funktionale Eigenschaften erfassen.
Damit kann eine Komponente verschiedene Aspekt-Spezifikationen haben wie beispielsweise
eine Real-Time oder eine Safety Spezifikation. Diese Spezifikationen werden durch Kontrakte
erfasst, die wiederum in Form von Textmustern (Requirement Specification Language, kurz
RSL) formuliert werden. Auf die Textmuster soll in diesem Deliverable jedoch nicht näher eingegangen
werden. Weitere Details kann der interessierte Leser in [15, 4] finden.
Kontrakt-basierte Spezifikation ermöglicht es, für jeden Aspekt den erlaubten Entwurfskontext
eines Entwicklungsgegenstandes mittels strong Assumptions zu charakterisieren: Eine Verletzung
dieser ist gleichbedeutend mit einer Verletzung der Nutzungsspezifikation, sodass für
solche Fälle die Produkthaftung nicht mehr gewährleistet wird. Für erlaubte Entwurfskontexte
charakterisiert die Guarantee eines Kontrakts sowohl funktionale als auch extra-funktionale
Eigenschaften des Entwurfsgegenstandes.
Der Annahme-Teil eines Kontrakts besteht neben der strong Assumption aus einer weak Assumption.
Dieser partitioniert den erlaubten Kontext, der durch die strong Assumption definiert
wird. Eine einzelne weak Assumption definiert damit nur einen Teil des erlaubten Kontexts
und ermöglicht es somit, verschiedene Anwendungsfälle eines Entwicklungsgegenstandes zu
definieren. Erfüllt dann der Kontext eine solche weak Assumption, kann der Entwicklungsgegenstand
ein strengeres Verhalten garantieren.
Neben der Spezifikation bieten HRCs Mittel um Aspekt-Realisierungen zu erfassen. Aspekt-
Realisierungen definieren, wie eine Komponente sich konkret verhält. Die Realisierung eines
konkreten Aspekts einer Komponente kann durch andere Formalismen außerhalb der SPES
Entwurfsmethodik erfolgen, wie beispielsweise Programmcode oder ausführbare Modelle.
Die HRCs bilden das Grundkonzept der SPES Entwurfsmethodik, auf dem der SPES Entwurfsraum
aufbaut, der im nächsten Abschnitt eingeführt wird.
3.2 SPES Entwurfsraum
Das Meta-Modell bietet Abstraktions- und Verfeinerungstechniken(↑) sowie Sichten (View(↑))
auf eine Architektur. Diese Entwurfsmethoden bilden den SPES Entwurfsraum, der in Abbildung
3.2 mit schemenhaften Modellen dargestellt ist. Im Folgenden wird auf die einzelnen
11/ 18

Kosimulation in SPES
Begriffe näher eingegangen.
Abstraktion im Allgemeinen erlaubt dem Entwickler, sich auf die wesentlichen Probleme in
einem Entwurfsschritt zu konzentrieren und unnötige Details auszublenden. Das Meta-Modell
bietet Abstraktionsebenen(↑) an, die es ermöglichen, einen Entwicklungsgegenstand mit einer
bestimmten Granularität zu beschreiben. Die Granulatität ist dabei abhängig vom konkreten
Entwicklungsprozess und erlaubt es, sich auf bestimmte Teile zu konzentrieren und zu einer
bestimmten Entwicklungsphase irrelevante Details auszublenden. Die Anzahl sowie Benennung
von Abstraktionsebenen ist dabei anwendungsabhängig und kann z. B. durch eine konkrete
Suppy-Chain beeinflusst werden.
Ein Modell eines zu entwickelnden Systems kann mit mehreren Viewpoints assoziiert werden,
die Konstrukte und Regeln zum Beschreiben von unterschiedlichen Views des zu entwickelnden
Systems bieten. Der Begriff der Views und Viewpoints bezieht sich hierbei auf den IEEE
Standard 1471-2000 [14].
Das Meta-Modell bietet hierzu einerseits Viewpoints, die eine strukturell verschiedene Sichten
auf das Modell realisieren - die sogenannten Perspektiven - und andererseits Viewpoints,
die orthogonal zur Struktur des Systems stehen und verschiedene Aspekte von funktionalen
und extra-funktionalen Eigenschaften des Entwicklungsgegenstandes beschreiben.
Orientiert an weit verbreiteten Software-Engineering-Vorgehensweisen (z. B. [18])
berücksichtigt das Meta-Modell also verschiedene Perspektiven auf das zu entwickelnde System,
um Sichten von lösungsunabhängiger Entwicklung bis hin zu konkreten technischen
Lösungen zu unterstützen. Im Speziellen wurden die Perspektiven operationale, funktionale,
logische, technische sowie geometrische definiert, die im Folgenden näher erläutert werden.
In der operationalen Perspektive(↑) werden unabhängig von einer konkreten (technischen)
Lösung der Kontext des zu entwickelten System betrachtet und Anforderungen an das zu entwickelnde
System sowie die nötigen Schnittstellen des Systems zu seiner Umwelt festgehalten.
Hierdurch wird eine frühe präzise Beschreibung der Anwendungsfälle des zu entwickelten Systems
ermöglicht. Durch z. B. einer Validierung mittels Simulation von Szenarien kann in dieser
Perspektive sehr früh erkannt werden, ob das richtige System entwickelt wird. Einen ganzheitlichen
Ansatz zum modellbasierten Requirements Engineering bietet dabei ZP-AP2 an. Die
operationale Perspektive stellt die Schnittstelle zu diesen Konzepten dar.
In der funktionalen Perspektive(↑) erfolgt basierend auf den Anwendungsfällen und Anforderungen
aus der operationalen Perspektive das Erfassen sämtlicher Funktionen, die das zu
entwickelnde System anbieten soll. Top-Level Funktionen werden dabei durch Funktionsdekomposition
in feingranularere Sub-Funktionen abgeleitet. Je nach Grad der Vollständigkeit
der Funktionsbeschreibung können z. B. erste Überprüfungen hinsichtlich der Abhängigkeiten
zwischen den verschiedenen Funktionen erstellt werden (z.B. mittels AutoFocus[1]).
Die logische Perspektive(↑) erfasst die logische Architektur des Systems, die plattformunabhängig
erstellt wird. Der Fokus liegt hier bei der Wiederverwendbarkeit der erstellten Komponenten.
Plattformunabhängige Analysen können hier durchgeführt werden, um beispielsweise
Fehler, die bei der Transformation auf plattformabhängige Spezifika entstehen, aufdecken zu
können.
Die technische Perspektive(↑) konkretisiert die logische Architektur. In dieser Perspektive
werden Software/Hardware-Partitionierungsfragen geklärt. Beispielsweise kann eine logische
Komponente in dieser Perspektive durch einen konkreten Aktor realisiert werden. Informationstechnisch
gesehen stellt die technische Perspektive die plattformabhängige Modellierung
des Systems dar.
In der geometrischen Perspektive(↑) wird das Layout des Systems modelliert. Die geometrische
Perspektive lag bisher nicht in dem Kompetenzbereich von SPES und wird daher in der in
12/ 18

Kosimulation in SPES
diesem Dokument vorgestellten Fallstudie nicht weiter betrachtet.
Zwischen Entwicklungsgegenständen auf unterschiedlichen Abstraktionsebenen und Perspektiven
können Verlinkungen erstellt werden, um die Traceability zu wahren und Modelle in
Beziehung zu setzen. Zwischen verlinkten Entwicklungsgegenständen müssen Verfeinerungsbeziehungen
gelten, die im Deliverable [4] definiert wurden. Diese Verfeinerungen beziehen
sich dabei auf die Aspekt-Spezifikationen: Entwicklungsgegenstände, die sich in einer tieferen
Abstraktionsebene oder in einer konkreteren Perspektive befinden, müssen (mindestens)
die Spezifikationen der Entwicklungsgegenstände auf abstrakteren Ebenen und Perspektiven,
zu denen sie verlinkt sind, erfüllen. Techniken zum automatischen Verifizieren dieser Beziehungen
wurden in den Deliverables [13, 19] ausgearbeitet.
Der nächste Abschnitt behandelt die Observer-basierte Verifikation von Aspekt-
Realisierungen, d.h. einer Technik, um die in Deliverable [4] definierte Satisfiability der Implementierung
einer Komponente bezüglich ihrer Spezifikation zu überprüfen.
13/ 18

4 HLA im Kontext von SPES
In [17] wurde die operationale Semantik von Kontrakt-basierten Aspekt-Spezifikationen definiert.
Diese Semantik wird hier verwendet, um eine Simulation der Spezifikationen mit den
entsprechenden Aspekt-Realisierungen zu etablieren.
In Abbildung 4.1 wurde ein zu entwickelnden Systems mit dem SPES Architektur Meta-
Modell modelliert. Ein Teil des logischen Modells auf der zweiten Abstraktionsebene (Subsysteme)
ist dabei in der Mitte des Bildes hervorgehoben und soll näher betrachtet werden.
Die Komponente Cmp1 ist mit der Komponente Cmp2 verbunden und bietet dieser die Daten
d1. Beide Komponenten sind mit jeweils einem Kontrakt versehen, die aus einer strong
Assumption (As), einer weak Assumption (Aw) und einer Guarantee (G) bestehen. Weiter unten
im Bild werden die Aspekt-Realisierungen beider Komponenten schemenhaft angedeutet:
Das Verhalten der Komponente Cmp1 wurde in Matlab/Simulink 1 und das der Cmp2 in Scade
2 modelliert. Diese beiden Verhaltensmodellierungen können nun mittels einer RTI zu einer
Kosimulation zusammgengeschlossen und erste Simulationsergebnisse ermittelt werden.
Die Komponente Cmp1 veröffentlicht dabei die Objektklassen, die von seinem Ausgangsport
spezifiziert wurden. Wurde des Weiteren eine zeitliche Spezifikation für den Ausgangskanal
angegeben, so kann sich die Komponente als Time Regulating Federate bei der RTI anmelden
und einen entsprechenden Lookahead aus der Spezifikation ableiten. Beispielsweise wurde für
den Port folgendes Aktivierungsverhalten mit Hilfe eines Real-Time Pattern 3 spezifiziert:
d1 occurs each 5ms with jitter 2ms.
Der Lookahead eines solchen Nachrichtenstroms würde dann 3ms betragen.
Um die Kontrakte automatisch zu überprüfen, kann ein analoger Ansatz zu [12, 10] durchgeführt
wereden: Kontrakte werden zu Observer-Programmen generiert und als zusätzliche Federates
in die Kosimulation mit aufgenommen. Sie melden sich dabei zu den Nachrichten an,
die in der Spezifikation referenziert werden. Zur Laufzeit prüfen die Observer dann, ob das
observierte Verhalten dem spezifizierten entspricht.
1 http://www.mathworks.de/
2 http://www.esterel-technologies.com/products/scade-suite/
3 Für mehr Informationen über RSL sei der interessierte Leser auf [2] veriwesen.
14/ 18

Perspektive
Ebene
Gesamtanlage
Subsysteme
...
Kosimulation in SPES
Operational Funktional Logisch Technisch Geometrisch
...
...
As Aw G
...
RTI
Cmp1
Observer1
Observer2
d1
As Aw G
Cmp2
... ...
Abbildung 4.1: Anbindung der Aspekt-Realisierungen an eine Kosimulation.
15/ 18

5 Zusammenfassung und Ausblick
In diesem Deliverable wurde die High Level Architecture vorgestellt und der Nutzen im Kontext
von SPES erläutert. Im Speziellen wurde beschrieben, dass eine Anbindung der Aspekt-
Realisierungen, die durch verschiedene Tools in einem parallelisierten Entwicklungsprozess
entstehen, an eine gemeinsame Kommunikationsplattform erfolgen kann.
Werden - analog zu dem in [12, 10] vorgestellten Verfahren - an die entstehende Federation
die zu den entsprechenden Subsystemen der Aspekt-Realisierungen zugehörigen Kontrakte
zu Observer-Federates übersetzt und als Federates an die Federation dazugeschaltet, kann eine
on-the-fly Auswertung dieser im Kosimulationsverlauf erfolgen. Der Beitrag einer solchen
Kosimulation wäre eine sehr frühzeitige Aufdeckung von Integrations- und Schnittstellenproblemen.
Im Rahmen einer Studentischen Projektgruppe kam die High Level Architecture bereits zum
Einsatz: Ein entwickeltes Fahrerassistenssystem wurde hierzu zusammen mit einer Verkehrssimulation
an eine RTI der Firma Pitch 1 geschlossen 2 . Durch Ausführen dieser Kosimulation
konnten mehrere Fehler aufgedeckt werden.
Des Weiteren wird im Rahmen einer Masterarbeit an der Anpassung und Erweiterung einer
Open-Source RTI namens CERTI 3 gearbeitet. CERTI realisiert dabei vollständig den HLA
Standard 1.3 und Teilweise den neueren Standard 1516 − 2000. Die Masterarbeit erweitert diese
Open-Source RTI um grundlegende Bestandteile, die in dem Standard 1516 − 2000 definiert
sind, sodass Kosimulationen nach diesem Standard durchgeführt werden könnnen. Für die in
diesem Deliverable beschriebene Kosimulation könnte diese RTI nach Fertigstellung und Evaluation
zum Einsatz kommen, was den großen Vorteil mit sich bringt, dass eine teure Anschaffung
einer kommerziellen RTI entfällt.
1 http://www.pitch.se/
2 https://svnbroy.in.tum.de/spes2020/Zentralprojekt/ZP-AP3/Deliverables/D3.3Architekturbewertung/D3.3.C-
ACC demo.mp4
3 http://savannah.nongnu.org/projects/certi
16/ 18

Literaturverzeichnis
[1] Manfred Broy, Franz Huber, and Bernhard Schätz. AutoFocus – Ein Werkzeugprototyp zur
Entwicklung eingebetteter Systeme. Informatik Forschung und Entwicklung, (13(3)):121–
134, 1999.
[2] CESAR SP2 Partners. Definition and exemplification of requirements specification
language and requirements meta model. CESAR D SP2 R2.2 M2 v1.000.pdf on
http://www.cesarproject.eu/fileadmin/user upload/, 2010.
[3] Judith Dahmann, Richard M. Fujimoto, and Richard M. Weatherly. The dod high level
architecture: an update. In WSC ’98: Proceedings of the 30th conference on Winter simulation,
pages 797–804, Los Alamitos, CA, USA, 1998. IEEE Computer Society Press.
[4] Werner Damm, Hardi Hungar, Stefan Henkler, Ingo Stierand, Bernhard Josko, Philipp
Reinkemeier, Andreas Baumgart, Matthias Büker, Tayfun Gezgin, Günter Ehmen, and Raphael
Weber. SPES2020 Architecture Modeling. SPES2020 Deliverable D3.5, SPES2020,
November 2010.
[5] Werner Damm, Angelika Votintseva, Alexander Metzner, Bernhard Josko, Thomas Peikenkamp,
and Eckard Böde. Boosting re-use of embedded automotive applications
through rich components. In Foundations of Interface Technologies, FIT’05, 2005.
[6] IEEE Standard for Modeling and Simulation (M&S). High level architecture - federate
interface specification. IEEE Computer Society Press, September 2000.
[7] IEEE Standard for Modeling and Simulation (M&S). High level architecture - framework
and rules. IEEE Computer Society Press, September 2000.
[8] IEEE Standard for Modeling and Simulation (M&S). High level architecture - object
model template (omt) specification. IEEE Computer Society Press, September 2000.
[9] IEEE Standard for Modeling and Simulation (M&S). Recommended practice for high level
architecture - federation development and execution process. IEEE Computer Society
Press, März 2003.
[10] Martin Fränzle, Tayfun Gezgin, Hardi Hungar, Stefan Puch, and Gerald Sauter. Using
guided simulation to assess driver assistance systems. In Eckehard Schnieder and Geza
Tarnai, editors, FORMS/FORMAT 2010, pages 195–205. Springer Berlin Heidelberg,
2011.
[11] Richard M. Fujimoto. Time management in the high level architecture. SIMULATION,
71(6):388–400, 1998.
[12] Tayfun Gezgin. Observerbasierte on-the-fly Auswertung von QLTL-Formeln innerhalb
eines HLA-Simulationsverbundes. Master’s thesis, Carl von Ossietzky Universität Oldenburg,
26121 Oldenburg, 2009.
17/ 18

Kosimulation in SPES
[13] Tayfun Gezgin. On the Role of Perspectives and Aspects on Architectural Description
of Software-Intensive Systems. SPES 2020 Deliverable D3.2.B-Subtask 3.2.2, The SPES
2020 Project, OFFIS, May 2011.
[14] ISO/IEC/(IEEE). ISO/IEC 42010 (IEEE Std) 1471-2000 : Systems and Software engineering
- Recomended practice for architectural description of software-intensive systems,
July 2007.
[15] Andreas Mitschke. Requirements Specification Language and Requirements Meta Model.
CESAR Deliverable D SP2 R2.2 M2, CESAR Project, October 2010.
[16] WP.2.1 Partners. SPEEDS L-1 Meta-Model. Technical report, SPEEDS Consortium, May
2009.
[17] Phillip Reinkemeier. Operational Semantics. SPES 2020 Deliverable D3.3.B-Subtask
3.3.4, The SPES 2020 Project, OFFIS, April 2011.
[18] Andrew P. Sage and William B. Rouse. Handbook of Systems Engineering and Management.
Wiley-Interscience, Wiley-Interscience.
[19] Raphael Weber and Tayfun Gezgin. Composition Concepts or Abstraction Levels - Realization
Test. SPES 2020 Deliverable D3.2.C-Subtask 3.2.2, The SPES 2020 Project,
OFFIS, June 2011.
18/ 18