Einleitung<\/h2>\n
Eingebettete Systeme werden f\u00fcr die verschiedensten Einsatzgebiete und Aufgaben immer bedeutender und in st\u00e4rkerem Ma\u00dfe miteinander vernetzt. Damit ist auch der Entwurf eingebetteter Systeme durch steigende Anforderungen und neue Herausforderungen gekennzeichnet. Dazu z\u00e4hlen:<\/p>\n
- \n
- die steigende Komplexit\u00e4t der zu entwerfenden Systeme bedingt durch die komplexeren und vielf\u00e4ltigeren Aufgaben<\/li>\n
- gesteigerte Vernetzung untereinander, mit der Umgebung und informationstechnischen Systemen<\/li>\n
- Korrektheit, Robustheit, Verf\u00fcgbarkeit und Sicherheit im zunehmend autonomen Einsatz in „unkontrollierten“ Umgebungen<\/li>\n<\/ul>\n
Eine L\u00f6sung, um derartige Herausforderungen zu meistern, ist die Modellierung von Systemen. Aufgrund der verschiedensten Einsatzgebiete und deren unterschiedlicher Beschaffenheit muss die Modellierung die Spezialit\u00e4ten, Methoden und Techniken dieser Einsatzgebiete ber\u00fccksichtigen, spezialisierte Sichten darauf bereitstellen und miteinander vereinen\/integrieren k\u00f6nnen (siehe dazu auch [4]).<\/p>\n
Eine weitere etablierte Methodik, um die Herausforderungen, insbesondere die Komplexit\u00e4t im Entwurf derartiger Systeme, zu bew\u00e4ltigen, ist die Plattform-Entwicklung (eng. Platform-based design, siehe [1] und [8]).<\/p>\n
Diese Entwurfsmethoden werden durch den komponentenbasierten Ansatz erg\u00e4nzt. Man versteht unter einer Komponente einen modularen Teil eines (komplexen) Systems, der in seiner Umgebung durch eine \u00e4quivalente Komponente ersetzt werden kann. Eine Komponente realisiert eine in sich abgeschlossene Teilfunktion eines Systems.<\/p>\n
Die im Folgenden eingef\u00fchrte Entwurfsmethodik st\u00fctzt sich konsequent auf die Plattform-Entwicklung und Modellierung von eingebetteten Systemen und deren Umgebung. Damit soll den genannten Herausforderungen begegnet und die Wiederverwendung von Plattform- und Anwendungs-Modellen in verschiedenen Produkten und Produktlinien erreicht werden. Wir haben die Entwurfsmethodik in [9] eingef\u00fchrt, das Plattform-Modell wurde durch [2] erg\u00e4nzt und detailliert. Insbesondere die Modellierung von Plattformen derartiger komplexer Systeme ist eine komplexe Aufgabe, die durch unsere Entwurfsmethodik verbessert werden soll. Dabei kommt vor allem das Konzept der hierarchischen Modellierung zum Einsatz.<\/p>\n
Die Modellierung der Anwendung und der Anwendungsumgebung ist ein weiterer wesentlicher Aspekt unserer Entwurfsmethodik. Neben funktionalen Anforderungen existiert eine Vielzahl nicht-funktionaler Anforderungen, die durch die Plattform erf\u00fcllt werden m\u00fcssen. Im Kapitel „Anforderungsdefinition“ werden wir eine Methode vorstellen, um derartige Anforderungen (im Allgemeinen Einschr\u00e4nkungen, daher auch Constraints) grafisch zu modellieren.<\/p>\n
Verwandte Arbeiten<\/h2>\n
Mit der UML [7] und den dazugeh\u00f6rigen Erweiterungen SysML [5] und MARTE [6] kann die statische Architektur einer Software gut beschrieben werden. UML wird f\u00fcr die Modellierung von eingebetteten Systemen durch die Erweiterungen MARTE und SysML erg\u00e4nzt. SysML erm\u00f6glicht die Modellierung aller Arten von Systemen, ist daber aber weniger konkret in der Definition der Semantik der SysML-Elemente und -Diagramme. Der plattformbasierte Ansatz wird von SysML nicht explizit unterst\u00fctzt. F\u00fcr diesen Zweck kann sie mit MARTE kombiniert werden.<\/p>\n
MARTE wurde f\u00fcr den plattformbasierten Ansatz entwickelt und unterst\u00fctzt, genau wie unsere Methodik, die hierarchische Modellierung von Plattformen. Ebenfalls nutzt MARTE das Konzept der Ressourcen und Dienste (siehe Kapitel „Adressr\u00e4ume und Dienste des Betriebssystems“).<\/p>\n
Insbesondere das dynamische Zusammenspiel zwischen der Hardware, dem Speichermodell, dem Betriebssystem und der Anwendungssoftware kann mit UML und den Erweiterungen SysML und MARTE nur unzureichend strukturiert und beschrieben werden.<\/p>\n
Der epizyklische Entwurfsprozess<\/h2>\n
Unsere Entwurfs-Methodik erweiterter objektorientierter Entwurfsmethoden wie in [3] auf einen technologieunabh\u00e4ngigen komponentenbasierten Ansatz. Er ist iterativ und enth\u00e4lt einen Hauptprozess, der aus Teilprozessen besteht. Wir visualisieren unseren Ansatz mittels Kreisen, um darzustellen, dass es sich um Iterationen handelt. Alle Teilprozesse sind als Epizyklen auf dem Hauptprozess dargestellt und werden daher als epizyklische Entwurfsprozesse bezeichnet. Abbildung 1 (siehe\u00a0PDF<\/a>-Datei) gibt einen \u00dcberblick \u00fcber den epizyklischen Entwurfsprozess.<\/p>\n
Eine Iteration des Hauptprozesses erzeugt eine Auspr\u00e4gung (Version, Produkt) eines eingebetteten Systems. Eine Iteration besteht aus 5 Teilprozessen, die aus Entwurfsschritten bestehen. Teilprozesse erzeugen Arbeitsprodukte (Zwischenprodukte) und haben Abh\u00e4ngigkeiten zueinander. Die folgenden 5 Teilprozesses sind definiert:<\/p>\n
- \n
- System-Anforderungsanalyse<\/li>\n
- funktionaler Systementwurf<\/li>\n
- Plattformentwurf<\/li>\n
- Komponenten-Implementierung<\/li>\n
- System-Integration (Implementierung)<\/li>\n<\/ol>\n
Der Hauptprozess kann iterativ mehrfach durchlaufen werden. Das zu entwerfende eingebettete System wird in mehreren Iterationen entwickelt (Auspr\u00e4gungen, Versionen, Baumustern). Eine Iteration des Hauptprozesses ist vergleichbar mit dem einmaligen Durchlaufen des klassischen V-Modells.<\/p>\n
Teilprozesse k\u00f6nnen ebenfalls iterativ mehrfach durchlaufen werden. Sie produzieren Arbeitsprodukte f\u00fcr andere Teilprozesse sowie bei Bedarf interne Arbeitsprodukte und ben\u00f6tigen Inputs anderer Teilprozesse oder aus der Umgebung.<\/p>\n
Das Ziel des epizyklischen Entwurfsprozesses ist einerseits, eine automatisierte Erstellung von Systemen anwendungszentriert zu erm\u00f6glichen. Andererseits soll die systematische und wiederholbare Erstellung von Systemen erm\u00f6glicht werden. Die konkrete Plattform bzw. das System entsteht aus Kundenanforderungen bzw. Anforderungen der Anwendung und verf\u00fcgbaren Plattform-Modellelementen. Dadurch kann sowohl ein optimal auf die Anwendung angepasstes System entwickelt als auch der Plattformansatz effizient verfolgt werden.<\/p>\n
System-Anforderungsanalyse und funktionaler Systementwurf<\/h2>\n
Die System-Anforderungsanalyse beinhaltet das klassische Requirements-Engineering mit textuellen Anforderungen, die von Bildern\/Diagrammen erg\u00e4nzt werden. In dieser Phase werden Kundenanforderungen aufgenommen, bewertet und abgestimmt. Da die hier erfassten Anforderungen und ihr Einfluss auf das zu entwerfende System in allen nachfolgenden Phasen ben\u00f6tigt werden, werden insbesondere die nicht-funktionalen Anforderungen hier bereits modelliert (formalisiert, wie im Kapitel „Anforderungsdefinition“ beschrieben). Das Ergebnis dieser Phase ist eine Anforderungs-Spezifikation.<\/p>\n
Der funktionale Systementwurf beinhaltet die Modellierung eines funktionalen Systems (auch Anwendung) anhand der funktionalen Anforderungen. Die nicht-funktionalen Anforderungen werden im Modell annotiert, um die Auswirkungen auf Anwendung und sp\u00e4ter Plattform ber\u00fccksichtigen zu k\u00f6nnen.<\/p>\n
Das Anwendungs-Modell<\/h2>\n
Das Metamodell f\u00fcr die Anwendung und das umgebende System besteht aus Modulen, Tasks Ports und Links. Ports dienen als Verbindungspunkte zwischen Modulen und Tasks und werden mittels Links verbunden. Wir unterscheiden zwischen strukturellen Ports und transferorientierten Ports. Im Folgenden werden nur transferorientierte Ports ber\u00fccksichtigt.<\/p>\n
Wir unterscheiden eine technologieunabh\u00e4ngige Modellierung und in der n\u00e4chsten Verfeinerung eine technologieabh\u00e4ngige Modellierung. Der \u00dcbergang zwischen beiden Phasen wird als Technologie-Bindung bezeichnet (siehe [9]). Anwendungsmodule sind Elemente, die andere Elemente wie Module und Tasks enthalten k\u00f6nnen. Sie werden verwendet, um einen hierarchischen Entwurf zu erm\u00f6glichen. Ein Modul ist ein strukturelles Element, das der Kapselung von Funktionen dient (Geheimnisprinzip). Module dienen der Gruppierung von Tasks oder Modulen mit hoher funktionaler Kopplung.<\/p>\n
Module sind keine Elemente physischer Kapselung, und sie korrespondieren nicht zwangsl\u00e4ufig mit Elementen der Plattform. Module beschreiben entweder ein Umgebungsmodell oder ein technisches System (die Anwendung).<\/p>\n
Das Umgebungsmodell ist ein Modell eines relevanten Ausschnitts der realen Welt, das im direkten Zusammenhang mit dem zu entwerfenden technischen System steht. Das technische Systemmodell interagiert mit dem Umgebungsmodell, um die geforderten Aktionen\/Reaktionen zu erreichen, also die funktionalen Anforderungen zu erf\u00fcllen.<\/p>\n
Zusammen mit seiner Plattform realisiert ein technisches Systemmodell ein eingebettetes System.<\/p>\n
Dem Gedanken des hierarchischen Enthaltenseins von Modulen folgend ist die gesamte Anwendungsarchitektur ebenfalls ein Modul, das sowohl das technische System als auch notwendige Umgebungsmodelle enth\u00e4lt (siehe Abbildung 2,\u00a0PDF<\/a>).<\/p>\n
Anwendungs-Tasks (Tasks) beschreiben und modellieren das Verhalten von Anwendungen. Tasks kapseln das Verhalten und k\u00f6nnen \u00fcber Ports miteinander kommunizieren. Ein Task ist ein Entwurfselement, das eine Basisfunktionalit\u00e4t (Verhalten) mit Eingangsgr\u00f6\u00dfen und Ausgangsgr\u00f6\u00dfen bereitstellt. Tasks k\u00f6nnen beispielsweise Modelle, Gleichungen oder Funktionen sein. Jeder Task besitzt mindestens einen Port.<\/p>\n
Neben Tasks mit Basisfunktionalit\u00e4t gibt es spezielle Tasks, die mit anderen Technologien interagieren. Sie werden als Transformations-Tasks bezeichnet und erm\u00f6glichen den Austausch zwischen unterschiedlichen Technologien. Andere Spezial-Tasks interagieren mit der Plattform eines technischen Systems. Wir unterscheiden hier Zeit-Tasks, die eine Schnittstelle zu Zeitinformationen der Plattform (Zeit-Ereignissen) bereitstellen, und Speichertasks, die eine Schnittstelle zu Speicher-Ressourcen der Plattform bereitstellen.<\/p>\n
Ports dienen als Kommunikationsendpunkte f\u00fcr Tasks und Module. Ports werden untereinander durch Links verbunden. Sowohl Ports als auch Links sind durch ihre Schnittstellenbeschreibung typisiert. Nur kompatible Ports k\u00f6nnen druch passende Links miteinander verbunden werden. Ports modellieren die Ein- und Ausg\u00e4nge von Tasks und Modulen und beschreiben deren Schnittstellen. Es werden Eingangs- und Ausgangs-Ports unterschieden.<\/p>\n
Module k\u00f6nnen nur spezielle Ports besitzen, die als Proxy-Ports bezeichnet werden. Sie dienen als externe Schnittstelle eines Moduls und verbinden die Umgebung des Moduls mit den internen Modulen oder Tasks. Es handelt sich um virtuelle Ports, die der Sicherstellung von Kapselung und Geheimnisprinzip des Moduls und der enthaltenen Tasks und Module dienen.<\/p>\n
Ein Link verbindet zwei kompatible Ports. Ein Ausgangs-Port liefert Entit\u00e4ten (zum Beispiel Informationen) abh\u00e4ngig von seiner Schnittstellenbeschreibung, und ein Eingangs-Port empf\u00e4ngt diese Entit\u00e4ten. Der verbindende Link erbt seine Schnittstellenbeschreibung von den Ports. Die Art der Schnittstelle kann mittels Symbolen am Link visualisiert werden.<\/p>\n
Im ersten Entwurfsschritt werden die funktionalen Anforderungen in eine technologieunabh\u00e4ngige Anwendung \u00fcberf\u00fchrt. Der n\u00e4chste Schritt verfeinert diese Anwendung (technisches System), indem Entscheidung \u00fcber die realisierenden Technologien getroffen werden. Dieser Schritt wird Technologiebindung genannt. Hier werden im Rahmen des funktionalen Systementwurfs die ersten Plattformentscheidungen getroffen, denn jede Entscheidung \u00fcber die Technologie bedingt Entscheidungen und Anforderungen an die Plattform. Hier wird z.B. die Entscheidung zwischen Digitaltechnik oder Analogtechnik getroffen. Wie weiter oben beschrieben wird die Verbindung zwischen unterschiedlichen Technologien durch sog. Transformations-Tasks modelliert.<\/p>\n
Ein Modul kann unterschiedliche Technologien enthalten: ein mathematisches Modell, Digitaltechnik (Computersystem oder elektronisches System), ein analoges elektronisches System (Analogtechnik) oder ein physikalisches System (z.B. Mechanik, Optik, Akkustik; h\u00e4ufig bei Umgebungsmodellen).<\/p>\n
Anforderungsdefinition<\/h2>\n
Neben funktionalen Anforderungen unterscheiden wir nicht-funktionale (oder extra-funktionale) Anforderungen. Nicht-funktionale Anforderungen beschreiben Forderungen an z.B. die Leistungsf\u00e4higkeit, Reaktionsf\u00e4higkeit oder Skalierbarkeit des Systems. Da sie h\u00e4ufig Einschr\u00e4nkungen beschreiben, unter denen ein System seine Aufgaben erf\u00fcllen soll, werden sie im weiteren Verlauf als Constraints bezeichnet.<\/p>\n
In der System-Anforderungsanalyse werden nicht-funktionale Anforderungen formalisiert und als Constraints modelliert. Es handelt sich sowohl um statische als auch dynamische Constraints. Dabei wird aktuell zwischen den folgenden Typen von Constraints unterschieden:<\/p>\n
- \n
- Zeit<\/li>\n
- Fl\u00e4che oder Kosten<\/li>\n
- Leistung und Energie<\/li>\n
- Sicherheit und Zuverl\u00e4ssigkeit, Verf\u00fcgbarkeit<\/li>\n<\/ul>\n
Aufgrund der Erweitbarkeit des Metamodells k\u00f6nnen einfach weitere Arten von Constraints hinzugef\u00fcgt werden.<\/p>\n
Constraints haben einen G\u00fcltigkeitsbereich, eine Menge von Modellelementen, auf die sie wirken. Sie werden im Anwendungsmodell annotiert. Das erfolgt, indem sie zwischen Ankerpunkten (Probes) spezifiziert werden. Diese Ankerpunkte k\u00f6nnen an jedes Modellelement der Anwendung gebunden werden. Um Constraints, deren G\u00fcltigkeitsbereich und Auswirkungen zu visualisieren, werden Symbole f\u00fcr Constraings definiert (siehe Abbildung 3,\u00a0PDF<\/a>). Der G\u00fcltigkeitsbereich eines Constraints wird farblich hervorgehoben.<\/p>\n
Die eigentliche nicht-funktionale Anforderung wird durch einen Ausdruck modelliert, der f\u00fcr den G\u00fcltigkeitsbereich des Constraints erf\u00fcllt sein muss. Hierbei unterscheiden sich verschiedene Arten der Erf\u00fcllung, z.B. kann ein Constraint erf\u00fcllt sein, wenn er auf allen Elementen des G\u00fcltigkeitsbereichs in Summe erf\u00fcllt ist, oder wenn er f\u00fcr jedes Element des G\u00fcltigkeitsbereichs einzeln erf\u00fcllt ist.<\/p>\n
Als Beispiel kann eine zeitliche Einschr\u00e4nkung die maximale Reaktionszeit eines Signals spezifizieren:<\/p>\n
<\/p>\n
Dieser Constraint wird mittels Ankerpunkten an die Kommunikationslinks der Anwendung annotiert, die dieses Signal beinhalten (G\u00fcltigkeitsbereich). Damit wird im funktionalen Systementwurf auch die geforderte zeitliche Einschr\u00e4nkung des Signals visualisiert. Er wird im weiteren Verlauf auch an die Plattform des Systems annotiert und schr\u00e4nkt damit die verwendbaren Plattform-Elemente ein. Mittels dieser formalen Annotationen kann in fr\u00fchen Entwurfsphasen die Einhaltung der nicht-funktionalen Anforderungen sichergestellt werden.<\/p>\n
Plattformentwurf<\/h2>\n
Ausgehend vom funktionalen Systementwurf und den nicht-funktionalen Anforderungen (Constraints) kann eine passende Plattform abgeleitet werden. Die Modellierung der Plattform f\u00fcr digitale Systeme wird im Folgenden vorgestellt.<\/p>\n
Schichtenmodell und Rollentrennung<\/h2>\n
Wesentliche Konzepte im Systementwurf sind Kapselung und Schichtenbildung. Eine SW-Plattform kann in verschiedene Schichten unterteilt werden. Unser Plattform-Modell erm\u00f6glicht die Bildung von Schichten \u00fcber ein hierarchisches Modell. Damit entspricht die Modellierung einer Plattformschicht der Modellierung einer Anwendung die an die darunterliegende Plattform gebunden wird. Unser Plattformkonzept basiert auf einer Schichtenbildung, wobei jede Schicht nur mit ihrer direkt benachbarten h\u00f6heren oder niederen Schicht kommuniziert.<\/p>\n
Dieses Konzept vereinfacht auch die Rollen- und Zust\u00e4ndigkeitstrennung. In unserem generischen Schichtenmodell wird die unterste Schicht durch die HW-Plattform (Schicht 0) repr\u00e4sentiert. Diese Schicht wird mittels des Plattform-Komponenten-Modells modelliert (siehe Kapitel „Hardwarearchitektur“). Dar\u00fcberliegende Plattformschichten stellen Dienste bereit, die von der jeweils dar\u00fcberliegenden Schicht (Anwendung) genutzt werden. Dies Schichten werden mittels des Plattform-Dom\u00e4nen-Modells beschrieben (siehe Kapitel „Adressr\u00e4ume und Dienste des Betriebssystems“). Abbildung 4 (siehe\u00a0PDF<\/a>) zeigt einen \u00dcberblick des Schichtenmodells.<\/p>\n
Dadurch werden die Abh\u00e4ngigkeiten zwischen unterschiedlichen Rollen im Entwurfsprozess reduziert. Beispielsweise wird ein Hardware-Entwickler die Hardware-Plattform mittels des Plattform-Komponenten-Modells beschreiben und mit dem Plattform-Entwickler abstimmen. Direkte Abh\u00e4ngigkeiten zwischen Hardware-Entwickler und Anwendungs-Entwickler werden minimiert. Dieser hat im Allgemeinen nur mit dem Plattform-Entwickler Abstimmungsbedarf, denn er ben\u00f6tigt nur die oberste Schicht der Plattform, um seine Anwendung zu modellieren.<\/p>\n
Hardwarearchitektur<\/h2>\n
Das Plattform-Komponenten-Modell (eingef\u00fchrt in [2]) besteht aus Modulen und Komponenten und unterst\u00fctzt \u00e4hnlich dem Anwendungs-Modell hierarchisches Design, indem Module aus Modulen oder Komponenten bestehen.<\/p>\n
Module sind beispielsweise physikalische Einheiten wie Ger\u00e4te, Steckkarten oder Chips bzw. SoC (Systems on Chip). Komponenten sind die atomaren Hardware-Elemente, sie enthalten Bus Control Interfaces, die als Schnittstellen dienen (siehe Abbildung 5,\u00a0PDF<\/a>). \u00c4hnlich den Ports im Anwendungsmodell k\u00f6nnen auch hier nur kompatible Bus Control Interfaces miteinander verbunden werden.<\/p>\n
Weitere Elemente des Plattform-Komponente-Modells sind Zeit-Elemente, die Zeitgeber (Timer) und Uhren (Clocks). Sie k\u00f6nnen mit allen anderen Elementen verbunden werden und werden mittels eines Timing-Interface mit anderen Elementen verbunden (siehe Abbildung 5,\u00a0PDF<\/a>).<\/p>\n
Ziel dieser Modellierung ist es, die Hardwarearchitektur von Plattformen strukturell bzw. in ihren Bausteinen zu beschreiben. Die Hardwarearchitektur kann durch das im folgenden Kapitel beschriebene Plattform-Dom\u00e4nen-Modell in Hinblick auf Ressourcen und Dienste substituiert werden. Diese Dienste erm\u00f6glichen im weiteren Verlauf die Bindung der Applikation an die Plattform.<\/p>\n
Adressr\u00e4ume und Dienste des Betriebssystems<\/h2>\n
In diesem Kapitel wird das Plattform-Dom\u00e4nen-Modell beschrieben. Die Idee hinter diesem Modell ist die Einf\u00fchrung einer Abstraktion, die alle Aspekte einer Plattform aus Sicht der Anwendung ber\u00fccksichtigt. Wir f\u00fchren hier das Konzept der Dom\u00e4nen Ressourcen und Dienste f\u00fcr alle Plattformen ein, unabh\u00e4ngig davon, ob diese von Software oder Hardware bereitgestellt werden. Damit soll die Austauschbarkeit der Plattform und auch der Anwendung verbessert werden. Au\u00dferdem wird das Ziel verfolgt unabh\u00e4ngig von industriellen Einsatzgebieten zu sein.<\/p>\n
Detaillierte Kenntnisse der Hardware-Plattform werden durch das Plattform-Dom\u00e4nen-Modell gekapselt. Die Anwendung muss nur die relevanten Informationen des Plattform-Dom\u00e4nen-Modells kennen. Mittels des Plattform-Dom\u00e4nen-Modells werden Plattformen logisch strukturiert, und die physikalische Strukturierung aus dem Plattform-Komponenten-Modell (Ger\u00e4te, Chips, usw.) wird \u00fcberwunden. Damit wird ein erh\u00f6hter Grad von Unabh\u00e4ngigkeit und Austauschbarkeit zwischen Plattform und Anwendung erm\u00f6glicht.<\/p>\n
Plattform-Dom\u00e4nen<\/h2>\n
Eine Plattform-Dom\u00e4ne (im weiteren Dom\u00e4ne) ist ein Strukturenelement des Plattform-Dom\u00e4nen-Modells. Es stellt einen Container dar, der logische Einheiten wie Ressourcen und Services kapselt. Das Dom\u00e4nen-Modell stellt die logische Sicht der Plattform dar. Dom\u00e4nen k\u00f6nnen Sub-Dom\u00e4nen enthalten und erm\u00f6glichen damit wieder die hierarchische Modellierung von Plattformen.<\/p>\n
Dom\u00e4nen besitzen eine Schnittstelle in Form von Diensten, die von den enthaltenen Ressourcen bereitgestellt werden. Eine Dom\u00e4ne bindet Elemente des Anwendungsmodells, wie Tasks, wenn sie eine Ausf\u00fchrungs-Ressource (Sequential Execution Ressource) enth\u00e4lt. Besitzt sie keine derartige Ressource, dient die Dom\u00e4ne als Container f\u00fcr weitere Sub-Dom\u00e4nen. Dom\u00e4nen sind logische Einheiten, die f\u00fcr die Realisierung des eingebetteten Systems in Hardware oder Software implementiert werden m\u00fcssen.<\/p>\n
In der untersten Plattform-Schicht sind Dom\u00e4nen, die logische Sicht auf die mittels Komponenten modellierte Hardwarearchitektur. Hier k\u00f6nnen Dom\u00e4nen durch Module oder Gruppen von Komponenten (auch aus verschiedenen Modulen) realisiert werden. Dadurch kann eine Dom\u00e4ne Ressourcen besitzen, die z.B. in verschiedenen Ger\u00e4ten oder Chips enthalten sind (siehe auch Kapitel „Entwurfstudie“).<\/p>\n
Auf h\u00f6heren Ebenen des Plattform-Schichtenmodells werden Dom\u00e4nen durch Software implementiert, beispielsweise durch Betriebssysteme und deren Zeit- und Speicher-Partitionen wie Prozesse und Threads. Eine m\u00f6gliche Modellierung eines Betriebssystems im Dom\u00e4nen-Modell sieht so aus:<\/p>\n
- \n
- Betriebssystem selbst wird durch eine Dom\u00e4ne beschrieben<\/li>\n
- Jeder Prozess wird durch eine Sub-Dom\u00e4ne beschrieben<\/li>\n
- Jeder Thread wird durch eine Sub-Dom\u00e4ne der entsprechenden Prozess-Sub-Dom\u00e4nen beschrieben<\/li>\n<\/ol>\n
Falls die Anwendung keine Nebenl\u00e4ufigkeit oder Speichertrennung ben\u00f6tigt, wird im Allgemeinen auch kein Betriebssystem genutzt. Andere Dienste (z.B. Treiber f\u00fcr Plattform-Hardware) werden normalerweise trotzdem von der Anwendung ben\u00f6tigt und \u00fcber eine Dom\u00e4ne beschrieben.<\/p>\n
Ressourcen und Dienste<\/h2>\n
Ressourcen sind logische Elemente, die Services f\u00fcr Anwendungs-Elemente oder Resourcen h\u00f6herer Schichten bereitstellen. Ressourcen andererseits ben\u00f6tigen Dienste niederer Schichten, um ihre Aufgaben zu erf\u00fcllen (siehe Tabelle 1,\u00a0PDF<\/a>).<\/p>\n
Die von Ressourcen angebotenen Dienste bilden die Schnittstelle der Ressource. Man kann Dienste auch als die \u00f6ffentlichen Methoden einer Ressource interpretieren. Dienste sind die einzige M\u00f6glichkeit, Ressourcen aus einer h\u00f6heren Schicht zu nutzen. Wir unterscheiden angebotene und ben\u00f6tigte Dienste oder Dienste, die der Konfiguration einer Ressource dienen. Ausgangs-Dienste sind lesende Dienste oder Ereignis-Behandlungsroutinen. Die Einteilung in Eingangs- und Ausgangsdienste erfolgt immer aus dem Blickwinkel der den Dienst besitzenden Ressource.<\/p>\n
Die Bindung von Plattform-Elementen benachbarter Schichten erfolgt durch die Verbindung von ben\u00f6tigten Diensten der Schicht\u00a0X\u00a0<\/em>mit kompatiblen angebotenen Diensten der Schicht\u00a0X<\/em>\u00a0– 1. Auf der untersten Plattform-Schicht realisieren Plattform-Komponenten Ressourcen, die Dienste bereitstellen. Diese Realisierungsbezeichnung wird als Bindung in dieser Ebene betrachtet.<\/p>\n
In einer Dom\u00e4ne werden normalerweise nicht alle m\u00f6glichen Ressourcen und Dienste modelliert, sondern nur die, die von h\u00f6heren Schichten ben\u00f6tigt werden. Wir bezeichnen sie als relevante Ressourcen und Dienste.<\/p>\n
Ressourcen und Dienste werden durch ihren Ressourcen-Typ, wie in Tabelle 1 dargestellt (siehe Tabelle 1,\u00a0PDF<\/a>), klassifiziert. Weiterhin unterscheiden wir Ressourcen-Manager. Sie verwalten andere Ressourcen und deren Dienste. Ein typischer Ressourcen-Manager ist eine MMU (Memory Management Unit), die andere Speicher-Ressourcen verwaltet und als Proxy f\u00fcr sie und ihre Dienste dient.<\/p>\n
Die zentralen Dienste, die von Plattformen angeboten werden, sind Rechenzeit bzw. Rechenkapazit\u00e4t, Speicher und Kommunikation. Wird eine Dom\u00e4ne nicht nur als Container f\u00fcr Sub-Dom\u00e4nen genutzt, stellt sie mindestens eine Rechenzeit-Partition („Zeitscheibe“) dar, die durch eine Ausf\u00fchrungs-Ressource (Sequential Execution Ressource) modelliert ist. Das bedeutet, dass alle Tasks die durch die Anwendung an diese Dom\u00e4ne gebunden werden, an genau eine Ausf\u00fchrungs-Ressource gebunden sind. Sie wird an eine Prozessor-Ressource gebunden. Das bedeutet, dass alle Aufgaben in einer Domne nacheinander und nicht parallel (nebenl\u00e4ufig) abgearbeitet werden. Damit k\u00f6nnen mehrere Sub-Dom\u00e4nen einer Dom\u00e4ne nur durch eine verwaltete Prozessor-Ressource (Scheduler) mit Rechenzeit versorgt werden.<\/p>\n
Im Gegensatz dazu k\u00f6nnen Dom\u00e4nen auch als Speicherpartition agieren und damit den gesamten verf\u00fcgbaren Speicherbereich mittels Adressr\u00e4umen separieren. Dabei werden alle Speicherzugriffe an virtuelle Speicher-Ressourcen (verwaltete Ressourcen) gebunden.<\/p>\n
Bindung von Anwendung und Plattform<\/h2>\n
Dieser Entwurfsschritt kombiniert Anwendung und Plattform. Anwendungs-Elemente wie Tasks werden an angebotene Dienste der Plattform gebunden. Nachdem dieser Schritt erfolgt ist, kann das modellierte System analysiert und bei Bedarf verfeinert werden (erneute Iteration der vorgelagerten Prozesse).<\/p>\n
Danach erfolgen die Implementierung oder Generierung des modellierten Systems bzw. seiner Komponenten (Teilprozess Komponenten-Implementierung) und Integration und Test der Komponenten zum eingebetteten System (Teilprozess System-Integration). Aufgrund der Verlagerung wesentlicher Analyse- und Testschritte, wie Modellierung und Analyse der Einhaltung nicht-funktionaler Anforderungen (Constraints) in fr\u00fche Entwurfsphasen, wird dieser Teilprozess deutlich vereinfacht.<\/p>\n
F\u00fcr diesen Entwurfsschritt wird eine spezielle Sicht zur Bindung von Anwendung und Plattform bereitgestellt. Sie wird von System- oder Anwendungs-Entwicklern genutzt, um Anwedungs-Elemente an Plattformen zu binden. Hier werden die Anwendungs-Sicht und die Dom\u00e4nen-Sicht verschmolzen, wobei die Anwendungs-Sicht \u00fcber die Dom\u00e4nen-Sicht gelegt wird. Die grafischen Elemente der Dom\u00e4nen-Sicht werden reduziert weiterverwendet. Beispielsweise werden keine Ressourcen mehr angezeigt, sondern nur noch die angebotenen Dienste, denn die Darstellung der Plattform-Schnittstelle zur Anwendung und nicht die Darstellung der Plattform-Struktur ist die Hauptaufgabe dieser Sicht. Weitere Details zur grafischen Bindung sind Bestandteil unserer zuk\u00fcnftigen Forschungsarbeiten (siehe auch Kapitel „Zusammenfassung“).<\/p>\n
Entwurfsstudie<\/h2>\n
In diesem Kapitel wird die Modellierung eines Sonar-Systems f\u00fcr ein autonomes Unterwasserfahrzeug unter Anwendung unserer Methodik beschrieben. Die Hauptaufgabe des Sonar-Systems ist die Erkennung von Objekten im Wasser. Das Sonar-System sendet Schallwellen aus und empf\u00e4ngt die Echos, die von Objekten im Wasser erzeugt werden. Ein solches System ist ein gutes Beispiel f\u00fcr die Nutzung unterschiedlicher Technologien. Es besteht aus elektromechanischen Teilen zur Erzeugung der Schallwellen, analogen elektronischen Teilen f\u00fcr die Ansteuerung der Schallerzeuger und f\u00fcr den Empfang der Echos sowie aus digitalen elektronischen Teilen mit Hard- und Software f\u00fcr die Signalverarbeitung und Objekterkennung.<\/p>\n
Die Entwurfsstudie folgt unserer Methodik und teilt sich daher in die folgenden Abschnitte:<\/p>\n
- \n
- System-Anforderungsanalyse<\/li>\n
- Funktionaler Systementwurf<\/li>\n
- Plattformentwurf<\/li>\n
- Komponenten-Implementierung und System-Integration.<\/li>\n<\/ol>\n
Hierbei konzentrieren wir uns auf die ersten 3 Entwurfsprozesse, die Komponenten-Implementierung und System-Integration werden in dieser Entwurfsstudie nicht weiter betrachtet und sind Teil unserer weiteren Forschungsarbeiten (siehe Kapitel „Zusammenfassung“).<\/p>\n
System-Anforderungsanalyse<\/h2>\n
Es soll ein Sonar entwickelt werden, welches Unterwasserobjekte (Objekte) erkennen und einen Vektor berechnen kann, der Abstand und Ortung relativ zum System angibt. Die System-Anforderungsanalyse beginnt mit der Analyse und Austellung der wesentlichen Anforderungen, die auszugsweise in der folgenden Abbildung 6 (siehe\u00a0PDF<\/a>) aufgef\u00fchrt sind.<\/p>\n
Funktionaler Systementwurf<\/h2>\n
Basierend auf den Anforderungen (Anforderungs-Spezifikation) beginnt der funktionale Systementwurf. Hierbei werden die funktionalen Hauptkomponenten identifiziert und die Technologie-Bindung vorgenommen.<\/p>\n
Im ersten Schritt wird der funktionale Systemkontext festgelegt bzw. aus den Anforderungen abgeleitet. Es wird ein Sonar-System entworfen, das Unterwasser-Objekte mittels Schallwellen erkennen kann. Das Sonar-System wird als Modell der Anwendung und bekannte Schnittstellen als Ports des Moduls modelliert.<\/p>\n
Die n\u00e4chsten Schritte sind nicht in strikter zeitlicher Reihenfolge durchzuf\u00fchren. Im n\u00e4chsten Schritt werden die Funktionen des Sonar-Systems aus den funktionalen Anforderungen extrahiert und als Anwendungs-Module im Modul Sonar modelliert. Jede Funktion, die in einer funktionalen Anforderung beschrieben ist, kann beispielsweise ein Modul sein.<\/p>\n
Dann erfolgt die Gruppierung von Funktionen zu sinnvollen Einheiten. Dadurch entstehen Module, die funktionale Gruppen bilden. Das Sonar-System wird dabei in die funktionalen Gruppen Signalerzeugung, Signalverarbeitung sowie Management aufgeteilt. Um erzeugte Signale in Schallwellen zu wandeln, wird eine weitere Funktion ben\u00f6tigt. Um Schall-Echos von Objekten als Signale verarbeiten zu k\u00f6nnen, m\u00fcssen sie wieder empfangen werden k\u00f6nnen. Daf\u00fcr wird die funktionale Gruppe Transceiver erzeugt. Hier wird bereits ein erster Teil der Technologie-Bindung durchgef\u00fchrt, da (elektrische) Signale in Schallwellen (und umgekehrt) umgewandelt werden m\u00fcssen.<\/p>\n
Technologie-Bindung<\/h2>\n
In der n\u00e4chsten Verfeinerung wird die Technologie-Bindung durchgef\u00fchrt. Elemente unterschiedlicher Technologie werden hierbei durch Transformations-Tasks verbunden und die Verbindungen (im Allgemeinten Signale oder Signalfl\u00fcsse) je nach gew\u00e4hlter Technologie und Art der Signale verfeinert.<\/p>\n
Der System-Architekt oder Anwendungs-Entwickler legt fest, welche Teile der Anwendung in welcher Technologie realisiert werden sollen. Die Module Signalerzeugung, Signalverarbeitung und Management werden als digitale Elektronik realisiert. Um digitale Signale in Schallwellen umzuwandeln und empfangene Schall-Echos digital verarbeiten zu k\u00f6nnen, ist eine Transformation von der digitalen Elektronik in analoge Elektronik und elektromechanischen Teile notwendig. Daher wird das Modul Transceiver bzw. Transducer als analoge Elektronik realisiert. Die Abbildung 7 (siehe\u00a0PDF<\/a>) zeigt das Anwendungs-Modell nach der Technologie-Bindung.<\/p>\n
Zeitliche Einschr\u00e4nkungen (Constraints)<\/h2>\n
Danach wird der funktionale Systementwurf durch die Annotation von Constraints am Anwendungs-Element (z.B. Signale) verfeinert und kann nun als ein Input in den Plattformentwurf dienen.<\/p>\n
Um 200kHz-Signale sicher zu erfassen, ist die doppelte Sampling-Rate notwendig. Im Sonar-System wird die Sampling-Rate der Analog-Digital-Wandlung auf 1MHz festgelegt, um Ungenauifkeiten im Low-Pass-Filter abzufangen und Signalanteile \u00fcber 200kHz Frequenz zu erfassen. Daher werden in diesem Schritt drei Zeit-Constraints annotiert, die sich aus den nicht-funktionalen Anforderungen ergeben:<\/p>\n
- \n
- die Sampling-Rate der Analog-Digital-Wandung<\/li>\n
- die maximale Zeit f\u00fcr die Objekterkennung<\/li>\n
- die gesamte Berechnungszeit des Systems<\/li>\n<\/ul>\n
Die maximale Zeit f\u00fcr die Objekterkennung ermittelt sich daraus, dass im Erkennungsbereich von bis zu 50m Objeckt-Echo innerhalb von 71ms emfpangen wird. Daher muss das Sonar-System diese Zeit warten, bevor ein neues Signal ausgesendet werden kann. Innerhalb dieser Zeit muss das System ein Echo auswerten und die Objekterkennung durchf\u00fchren k\u00f6nnen. Die Objekterkennung wird mittels Kreuzkorrelation durchgef\u00fchrt. Daf\u00fcr ist ein weiterer Zeit-Constraint notwendig, der sich aus dem bestehenden funktionalen Systementwurf und den Systemanforderungen ergibt. Das Fourier-transformierte ausgesendete Signal muss gespeichert werden, bevor die ersten Echos empfangen werden. Die maximale Zeit bis zum Speichert ergibt sich daraus, dass der Erkennungsbereich bei 2m beginnt. Innerhalb von 3ms k\u00f6nnen die ersten Echos empfangen werden. Damit muss zus\u00e4tzlich die maximale Zeit bis zum Speichern (T_Speichern) bei weniger als 3ms liegen. Abbildung 7 (siehe\u00a0PDF<\/a>) zeigt, wie dieser Constraint im funktionalen Systementwurf annotiert wird.<\/p>\n
Plattformentwurf<\/h2>\n
In unserer Entwurfsstudie wird f\u00fcr den Plattformentwurf eine bestehende Hardware-Plattform wiederverwendet. Sie ist als Plattform-Komponenten-Modell (siehe Abbilung 8,\u00a0PDF<\/a>) verf\u00fcgbar und besteht aus sechs Plattform-Modulen, dem FPGA-Motherboard, dem FPGA-Extension Board, dem A\/D-Converter Board, dem Transducer Interface, dem Transducer selbst und einem Spannungsversorgungs-Modul.<\/p>\n
Hier wird erkennbar, dass die Prozessor-Elemente (PWM und NIOS) physikalisch durch den Avalon-Bus miteinander verbunden sind. Der Avalon-Bus dient auch als Verbindung zum CAN-Controller und den SPI-Controllern „AD-Controller1“ und „AD-Controller2“, die sich auf dem FPGA-Extension Board befinden. Die Prozessorelemente erf\u00fcllen unterschiedliche Aufgaben. Um sie logisch zu trennten, werden bei der Erstellung des Plattform-Dom\u00e4nen-Modells der Hardware-Plattform drei Dom\u00e4nen erzeugt, die die Prozessor-Elemente kapseln (siehe Abbildung 9,\u00a0PDF<\/a>). Damit wird auch die physikalische Trennung der Plattform-Module \u00fcberwunden, und relevante Ressourcen werden den logischen Dom\u00e4nen bereitgestellt.<\/p>\n
Alle Hardware-Komponenten werden durch passende Ressourcen repr\u00e4sentiert, beispielsweise werden die Speicher-Elemente MEM2 und MEM3 als Speiche-Ressourcen modelliert. Alle Ressourcen die von mehreren Dom\u00e4nen genutzt werden, sind als geteilte Ressourcen (shared ressource) modelliert und in der Dom\u00e4nen-Sicht im Zwischenraum zwischen den nutzenden Dom\u00e4nen visualisiert.<\/p>\n
Die Dom\u00e4ne NiosMainSystem, die das Prozessor-Element NIOS kapselt, stellt eine Speicherpartition dar (mittels der Ressource MEM3). Im Gegensatz dazu ist PwmSubsystem nur eine Rechenzeitpartition.<\/p>\n
Nachdem die Hardware-Dom\u00e4nen modelliert sind, werden h\u00f6herwertige Dom\u00e4nen wie beim NiosMainSystem ein Betriebssystem modelliert. Hier werden 2 Tasks (Sub-Dom\u00e4nen) modelliert, die verschiedene Dienste anbieten. Ein Scheduler (Ressourcen-Manager) hat hier bis zu 64 Tasks (siehe Abbildung 9,\u00a0PDF<\/a>). Die Hardware-Dom\u00e4ne PwmSubsystem ben\u00f6tigt keine zus\u00e4tzliche Software-Schicht, die Anwendungs-Elemente werden hier direkt an die Dienste der Hardware-Dom\u00e4ne gebunden.<\/p>\n
Bindung von Sonar-Anwendung und Plattform<\/h2>\n
Nachdem sowohl die Anwendung als auch die Plattform modelliert wurden, kann die Bindung der Anwendungs-Elemente an die Plattform erfolgen. Abbildung 10 (siehe\u00a0PDF<\/a>) zeigt beispielhaft die Bindung von Tasks an Dom\u00e4nen und deren Ausf\u00fchrungs-Dienste. Die Bindung von Tasks an Dom\u00e4nen erfolgt, indem die Tasks im Ausf\u00fchrungsbereich der Dom\u00e4nen, der freien Fl\u00e4che, platziert werden. Die Bindung von Kommunikation (Ports und Links) oder Spezial-Tasks wie Speicher und Zeit wird hier nicht dargestellt.<\/p>\n
Die Plattform stellt eine Dom\u00e4ne FftSubsystem bereit, die speziell f\u00fcr die Besprechung von Fast-Fourier-Transformationen geeignet ist. Deshalb werden das Modul CrossCorrelation und der Task IFFT zur Ausf\u00fchrung an den Ausf\u00fchrungsdienst dieser Dom\u00e4ne gebunden. Der Anwendungs-Task SignalGenerator wird an die Dom\u00e4ne PwmSubsystem gebunden. Wie in Abbildung 10 (siehe\u00a0PDF<\/a>) dargestellt, werden die Tasks des Moduls TargetDetection auf 2 unterschiedliche Dom\u00e4nen aufgeteilt. Die Tasks EnvelopeFilter und ThresholdFilter werden durch die Dom\u00e4ne NiosMainsystem bzw. deren Sub-Dom\u00e4ne Task1 ausgef\u00fchrt. Die Dom\u00e4ne Task2 bindet das Modul Management und erm\u00f6glicht damit eine nebenl\u00e4ufige Ausf\u00fchrung von Management und TargetDetection auf einem Prozessor.<\/p>\n
Zusammenfassung<\/h2>\n
Wir zeigen mit unserer Entwurfsmethodik und dem zugeh\u00f6rigen Metamodell, wie die Besonderheiten des dynamischen Verhaltens eingebetteter Software ber\u00fccksichtigt werden k\u00f6nnen. Ein besonderes Augenmerk gilt dabei der Dynamik der Hardware\/Software-Schnittstelle.<\/p>\n
In unseren weiteren Forschungsarbeiten wollen wir die Bindung von Anwendung und Plattform – insbesondere deren intuitive grafische Darstellung – analysieren und uns verst\u00e4rkt um die Anbindung von Constraints an Anwendungs- und Plattform-Elemente k\u00fcmmern. Als Basis daf\u00fcr soll eine Implementierung der Entwurfsmethodik und des Metamodells erfolgen.<\/p>\n
Literatur- und Quellenverzeichnis<\/h2>\n
[1]\u00a0\u00a0\u00a0 L. P. Carloni, F. De Bernardinis, C. Pinello, A. L. Sangiovanni-Vincentelli, and M. Sgroi. Platform-Based Design for Embedded Systems. In R. Zurawski, editor,\u00a0Embedded systems handbook<\/em>, Industrial information technology series, pages 1\u201326. Taylor & Francis, Boca Raton, 2006.<\/p>\n
[2]\u00a0\u00a0\u00a0 C. Hausner and F. Slomka. Abstract Modeling of Embedded Systems Hardware. In\u00a0Proceedings of the 3rd International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH 2013)<\/em>, pages 251\u2013258, 2013.<\/p>\n
[3]\u00a0\u00a0\u00a0 I. Jacobson.\u00a0Object-oriented software engineering: A use case driven approach<\/em>. Addison-Wesley, Harlow, revised printing edition, 1998.<\/p>\n
[4]\u00a0\u00a0\u00a0 G. Karsai. Modeling Cyber-Physical Systems: Challenges and Recent Advances, 05.09.2014.<\/p>\n
[5]\u00a0\u00a0\u00a0 Object Management Group.\u00a0OMG Systems Modeling Language, version 1.2 (OMG SysML)<\/em>. Object Management Group, Needham, 1.2 edition, 2010.<\/p>\n
[6]\u00a0\u00a0\u00a0 Object Management Group.\u00a0UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems<\/em>. Object Management Group, Needham, 1.1 edition, 2011.<\/p>\n
[7]\u00a0\u00a0\u00a0 Object Management Group. Unified Modeling Language (UML), 2013.<\/p>\n
[8]\u00a0\u00a0\u00a0 A. L. Sangiovanni-Vincentelli. Defining Platform-based Design. 2002.<\/p>\n
[9]\u00a0\u00a0\u00a0 F. Slomka, S. Kollmann, S. Moser, and K. Kempf. A Multidisciplinary Design Methodology for Cyber-physical Systems. In S. V. Baelen, S. G\u00e9rard, I. Ober, T. Weigert, H. Espinoza, and I. Ober, editors,\u00a0Proceedings of the 4th International Workshop on Model Based Architecting and Construction of Embedded Systems ACES-MB 2011<\/em>, CEUR Workshop Proceedings, 2011.<\/p>\n
\nBeitrag als PDF-Datei herunterladen<\/strong><\/a><\/p>\n
\nEchtzeit – MicroConsult Trainings & Coachings<\/h2>\n
Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n
Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n
\nTraining & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n
\nEchtzeit – Fachwissen<\/h2>\n
Wertvolles Fachwissen zum Thema\u00a0Architektur \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong><\/a>\u00a0f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n