Die in dieser Arbeit entwickelte modellbasierte Entwicklungsmethode soll über alle Phasen der Entwicklung hinweg durch einen modellbasierten Ansatz Defizite im aktuellen Flow beseitigen und die Effizienz der SoC-Entwicklung in Gesamtheit steigern. Nach aktuellem Stand gibt es nach Wissen des Autors keine existierende Lösung für die modellbasierte Systementwicklung von Automotive SoCs, welche dabei den gesamten Entwicklungs-Flow von der Analyse der Kundenanforderungen bis zum Systementwurf berücksichtigt und dabei eine Automatisierung des Entwurfs sowie der Verifikationserstellung ermöglicht. Daher erfolgt in diesem Kapitel eine Betrachtung von Lösungsansätzen aus der Literatur, welche Teilbereiche des SoC-Entwicklungs-Flows abdecken bzw. einen Teil der gestellten Anforderungen erfüllen.
Im vorangegangenen Kapitel wurden die Grundlagen der SoC-Entwicklung sowie Themen aus der modellbasierten Systementwicklung behandelt. Als Teil dessen, wurde der SoC-Entwicklungs-Flow mit seinen unterschiedlichen Phasen der Entwicklung vorgestellt. Die in dieser Arbeit entwickelte modellbasierte Entwicklungsmethode soll, wie in Kapitel 1 beschrieben, über alle Phasen der Entwicklung hinweg durch einen modellbasierten Ansatz Defizite im aktuellen Flow beseitigen und die Effizienz der SoC-Entwicklung in Gesamtheit steigern. Eine detaillierte Behandlung der Methode folgt in Kapitel 4. Nach aktuellem Stand gibt es nach Wissen des Autors keine existierende Lösung für die modellbasierte Systementwicklung von Automotive SoCs, welche dabei den gesamten Entwicklungs-Flow von der Analyse der Kundenanforderungen bis zum Systementwurf berücksichtigt und dabei eine Automatisierung des Entwurfs sowie der Verifikationserstellung ermöglicht. Daher erfolgt in diesem Kapitel eine Betrachtung von Lösungsansätzen aus der Literatur, welche lediglich Teilbereiche des SoC-Entwicklungs-Flows abdecken bzw. einen Teil der gestellten Anforderungen erfüllen. In dem folgenden Kapitel werden daher die existierenden Forschungs- und Lösungsansätze auf die Erfüllung der in Abschnitt 1.1 definierten Anforderungen A1 (Reduzierung von nachträglichen Änderungen), A2 (Reduzierung von Implementierungsfehlern), A3 (Reduzieren von Inkonsistenzen) sowie auf die Erfüllung der Anforderungen A7 (Reduzierung Aufwand Entwurf) und A8 (Reduzierung Aufwand Verifikation) untersucht. Die Anforderungen A4 (Integrierbarkeit der Methode in bestehenden Flow), A5 (Einfluss der Methode auf Spezifikationsaufwand) und A6 (Anwenderfreundlichkeit) beziehen sich auf die Gesamtlösung dieser Arbeit. Deren Erfüllung wurde in den hier diskutierten Teillösungen der Literatur nicht ausreichend betrachtet. Aus diesem Grund lassen sich die Arbeiten nur bedingt auf die Erfüllung dieser Anforderungen überprüfen.
Die Erfüllung der Anforderungen A1 (Reduzierung von nachträglichen Änderungen), A2 (Reduzierung von Implementierungsfehlern) und A3 (Reduzieren von Inkonsistenzen) wird, wie nachfolgend in Kapitel 4 beschrieben, in der hier vorliegenden Arbeit durch die Definition einer Modellierungsmethode gepaart mit einer Arbeitsweise nach dem Top-down-Ansatz und der Formalisierung der modellierten Spezifikation für den SoC-Bereich erreicht. Daher werden in Abschnitt 3.1 Lösungen aus der Literatur für die folgenden Themengebiete diskutiert:
Die modellbasierte Systementwicklung, welche allgemeine Modellierungsmethoden und modellierungssprachenbasierte Lösungen für die modellbasierte Entwicklung bietet
Die Formalisierung und Modellierung der Spezifikation, welche sich meist auf einen bestimmten Anwendungsbereich fokussieren
Anzeige
Die Anforderungen A7 (Reduzierung Aufwand Entwurf) und A8 (Reduzierung Aufwand Verifikation) stehen für die Effizienzsteigerung in der Entwurfsphase und der daran anschließenden Verifikation. In Abschnitt 3.2 folgen daher:
Lösungen aus der Literatur für den modellgetriebenen Systementwurf sowie die Entwicklung von Virtuellen Prototypen aus dem Bereich der Eingebetteten Systeme.
Bestehende Lösungen für die Reduzierung des Aufwandes bei der Verifikationserstellung.
Eine Abgrenzung der Arbeit gegen die hier untersuchten bestehenden Lösungen aus der Literatur folgt in Abschnitt 3.3.
3.1 Modellbasierte Systementwicklung
Die Behebung der Defizite in der aktuellen Spezifikationsmethodik ist in Abschnitt 1.1 durch die Definition der Anforderungen A1, A2 und A3 abgebildet. Mittels einer modellbasierten Entwicklungsmethode, welche zugleich eine Arbeitsweise für die Systementwicklung beinhaltet, kann die Analyse der Anforderungen und die Strukturierung des Modells unterstützt und so nachträgliche Änderungen (A1) reduziert werden. Aus diesem Grund betrachtet der nachfolgende Abschnitt Modellierungsmethoden aus der Literatur für die Systementwicklung.
Für die Reduktion von Inkonsistenzen und Implementierungsfehlern, welche aus der Spezifikation resultieren, ist die Formalisierung der Spezifikationssprache jedoch zusätzlich nötig, da diese die Eindeutigkeit der Spezifikation maßgeblich erhöht. Die modellbasierte Entwicklungsmethode dieser Arbeit soll über alle in Abschnitt 2.6 dargestellten Phasen hinweg eine modellbasierte Entwicklung und Spezifikation in der SoC-Entwicklung ermöglichen.
Anzeige
3.1.1 Modellierungsmethoden
Die Literatur bietet verschiedene Modellierungsmethoden für die Systementwicklung an, welche sich auf die Entwicklung von Eingebetteten Systeme anwenden lassen. Die in [32] beschriebene Modellierungsmethode der OMG (Object Management Group) trägt die Bezeichnung Model Driven Architecture (MDA). Hierbei handelt es sich um einen generellen Modellierungsansatz, welcher sich domänen- und modellierungssprachen-übergreifend anwenden lässt. Als Teil des Ansatzes werden unter Verwendung von Industriestandards die generelle Struktur, Notation und Semantik für die Modellierung definiert. Einen vergleichbaren Ansatz bietet die Modellierungsmethode in [33], genannt Electronic System Level (ESL)-Design. Diese Methode wurde darüber hinaus jedoch speziell für die Modellierung und Entwicklung von SoCs entwickelt und bietet hierfür eine Top-down-basierte Arbeitsweise. Ein wichtiger Aspekt der Methode ist die modellbasierte Analyse und Simulation des abstrahierten Entwurfs in einer frühen Phase der Entwicklung.
Die in [22] vorgestellte SYSMOD-Methode sowie die in [34] vorgestellte SPES-Modellierungsmethode bietet ebenfalls einen Ansatz für die Systemmodellierung. Jedoch orientieren sich beide Methoden in der Umsetzung der Modellierungsschritte an den in der UML bzw. SysML enthaltenen Diagrammen. Zusätzlich zur reinen Modellierungsmethode definiert die SPES2020-Methode aus [34] eine spezielle Modellstruktur. So bestehen heutige Systeme in der Regel aus einzelnen Subsystemen, welche wiederum aus Subsystemen oder einzelnen Modulen und Submodulen bestehen. Diese Subsysteme werden oftmals mehr oder weniger getrennt entwickelt, wodurch ebenso mehrere unabhängige Modelle entstehen. Um die so voneinander unabhängig entstehenden Modelle unterschiedlicher Subsysteme zusammensetzen zu können, werden als Teil der SPES2020-Methode eine Arbeitsweise für die Modellierung sowie Teile der Struktur formalisiert. Dabei dient die SPES2020-Methode in erster Linie zur Modellierung von großen Gesamtsystemen auf abstrakter Ebene, ohne dabei die spezifischen Anforderungen einer Domäne oder der SoC-Entwicklung zu erfüllen.
Die in diesem Abschnitt vorgestellten Modellierungsmethoden bieten Lösungen für die Modellierung und modellbasierte Entwicklung von Systemen. Dabei dient die Modellierung des Systems jedoch in der Regel als Ergänzung für die aktuell genutzten Beschreibungsformen und ist nicht als Teil der Spezifikation vorgesehen. Darüber hinaus bleibt bei der Anwendung einer Modellierungsmethode ohne die Verwendung einer eindeutigen Beschreibung die Interpretierbarkeit und damit die fehlende Eindeutigkeit der Beschreibung weitestgehend bestehen. Dadurch bleibt auch das Risiko für Implementierungsfehler aufgrund einer unzureichenden Spezifikation bestehen und ebenso das Risiko für Inkonsistenzen zwischen implementiertem Entwurf und Spezifikation. Aus diesem Grund werden im nachfolgenden Abschnitt Lösungen aus der Literatur für die modellbasierte Spezifikation und Formalisierung der Spezifikation betrachtet.
3.1.2 Methoden zur modellbasierten Spezifikation und Formalisierung
Die Grundlagen der modellbasierten Systementwicklung sowie die Formalisierung der Spezifikation wurden in Abschnitt 2.5 behandelt. Mögliche Lösungen für die Formalisierung und Modellierung der Spezifikation aus der Literatur werden im Nachfolgenden diskutiert. Dabei werden ebenfalls Ansätze diskutiert, welche lediglich auf eine einzelne Domäne der SoC-Entwicklung anwendbar sind. Der Abschnitt ist in drei Unterabschnitte unterteilt: Spezifikationslogiken, objektorientierte Modellierung und aufgrund der besonderen Nähe zu der in dieser Arbeit vorgestellten Methode, davon losgelöst, SysML-basierte Modellierungsansätze.
Spezifikationslogiken
Die Literatur bietet neben den gängigen grafischen Modellierungssprachen auch Term-basierte Modellierungssprachen für die Analyse und Beschreibung von Systemen. So bieten die Arbeiten [35], [36] und [37] Modellierungssprachen zur Spezifikation von Eingebetteten Systemen, welche auf Termen und Algorithmen basieren. In [35] findet dabei zu Beginn des Entwicklungs-Flows eine Dekomposition der Systemfunktionalität mittels Termen statt, um diese anschließend in die Domänen Analog- und Digitaltechnik aufzuteilen. Auf Grundlage der so erhaltenen Gruppierungen der Funktionalitäten werden diese den jeweiligen Modulen des Systems zugeordnet. Die Steigerung der Effizienz in der Verifikation sowie die Formalisierung der Spezifikation sind Ziele der in [37] beschriebenen Methode. Dabei wird zur Beschreibung des Systems die Projection Temporal Logic (PTL) verwendet, um das Verhalten des Systems als diskrete Zustandsfolgen zu spezifizieren. Darauf aufbauend nutzt der Autor die Programmiersprache Tempura, um eine Ausführbarkeit der Spezifikation zu erreichen. Die Autoren/-innen in [36] definieren hingegen eine Sprache basierend auf einer typisierten Logik erster Ordnung. Dabei wird das System als eine Sammlung aus verschiedenen Konzepten beschrieben und somit der Zustandsraum des Systems modelliert. Ein Konzept beschreibt dabei einen Teilbereich des Modells. Term-basierte Sprachen lassen sich aufgrund ihrer Nähe zur Mathematik leichter formalisieren, bergen jedoch viele Nachteile bei der Lesbarkeit und Fehlerwahrscheinlichkeit, wodurch die Anwenderfreundlichkeit – verglichen mit grafischen Modellierungssprachen – sinkt
Objektorientierte Modellierungssprachen
Weitaus verbreiteter als die Spezifikationslogiken ist in der Entwicklung von Eingebetteten Systemen die Verwendung von objektorientierten Modellierungssprachen. Ein Auszug der verfügbaren grafischen Modellierungssprachen bietet der Abschnitt 2.5. Die in Arbeit [38] entwickelte Methode beschäftigt sich nicht in erster Linie mit der Modellierung der Spezifikation, sondern bietet einen Ansatz zur Übersetzung von in natürlicher Sprache geschriebenen Softwareanforderungen in ein UML-Modell. Dazu werden die Anforderungen, welche im Concern-Aware Requirements Engineering (CARE)-Format spezifiziert wurden, in UML-Klassendiagramme übersetzt, um diese für die Generierung weiterverwenden zu können. Die Literaturquellen [39], [40] und [41] bieten dementgegen Ansätze zur rein modellbasierten Entwicklung. So wird eine Teilmenge der UML, bestehend aus Klassen-, State- und Sequenzdiagrammen, zur Spezifikation des Systems genutzt. Zusätzlich zur Verwendung einer standardisierten und maschinenlesbaren Modellierungssprache definiert der Autor eine UML Virtual Machine (UVM). Mithilfe dieser UVM lassen sich die State-Diagramme in Binärcode und die Sequenzdiagramme in Bytecode übersetzen und somit eine Ausführbarkeit der Spezifikation erreichen.
Einen semi-formalen Ansatz für die Modellierung der Anforderungen bietet die Arbeit in [42]. Dabei wird das in der SysML enthaltene Modellelement, genannt Requirements-Block, zur Definition von Anforderungs-Pattern genutzt. Dieser Ansatz ermöglicht die Vereinheitlichung und damit die Wiederverwendbarkeit von modellierten Anforderungen in der SoC-Entwicklung. Zusätzlich zur Aufwandsreduzierung werden die Anwender/-innen durch die Definition von Pattern bei der korrekten Beschreibung der Anforderungen unterstützt.
Der in [43] behandelte Ansatz kombiniert UML und „Actor-oriented Modelling“ zur modellbasierten Spezifikation von SoCs. „Actor-oriented Modelling“ bezeichnet eine Formalisierung von Techniken, welche über viele Jahre hinweg im Entwurf Eingebetteter Systeme eingesetzt wurden. Dabei liegt das Hauptmerkmal des „Actor-oriented Modelling“-Ansatzes, anders als bei der UML, auf der Modellierung von Verhalten zusammengesetzter Systeme. Die UML bietet hingegen die Darstellung verschiedener Aspekte in einzelnen Diagrammen.
Die Arbeiten [44] und [45] ermöglichen die Entwicklung von „Realtime and Embedded Systems“ (RTES) durch die Verwendung von MARTE, einem UML-Profil für die Modellierung und Analyse von RTES. Hierbei verwenden die Autoren/-innen in [44] zusätzlich eine Kombination aus MARTE und SPES, um die Architektur von RTES mittels verschiedener „Viewpoints“ (Sichtweisen) abzubilden. Dabei werden die einzelnen Sichtweisen der SPES-Methode auf die MARTE-Semantik zugeordnet.
Einen vergleichbaren Ansatz bietet die Arbeit [46]. Hierbei wird auf Basis der UML und des MARTE-Profils eine „Single-Source“-Modellierungsmethode (aus einer Hand) für die Modellierung von Eingebetteten Hardware-/Softwaresystemen vorgestellt. Dabei ermöglicht die Methode die Trennung verschiedener Aspekte der Systementwicklung, die inkrementelle Modellierung und die Modellierung funktionaler Komponenten. Sie unterstützt darüber hinaus wichtige Entwurfsaufgaben wie Design Space Exploration und die Software-Synthese.
Die Publikation [47] schlägt ein Hardware/Software-Co-Entwurf-Framework vor, welches die Inkompatibilität über Hardware-Software-Grenzen hinweg beheben und somit Schwierigkeiten bei der Verifizierung reduzieren soll. Dabei wird eine SystemC-basierte Modellierung in Form eines Model-of-Computation (MoC, Berechnungsmodell) sowie eines Model-of-Communication (MoComm, Kommunikationsmodell) zur Beschreibung des Systems verwendet. Ein MoC wird dabei zur Modellierung von Operationen und Berechnungen verwendet, sowohl für Software als auch für Hardware. Mithilfe des MoComm wird die Datenkommunikation zwischen einzelnen Hardware MoCs modelliert.
[48] nutzt die UML als Frontend zur grafischen Modellierung einer IP-XACT-basierten IP-Beschreibung. Hierzu wird in der Arbeit ein Profil der UML vorgestellt sowie eine Bibliothek definiert, welche eine Zuordnung zwischen IP-XACT und UML-Elementen ermöglicht. Durch diesen Ansatz wird die Anwenderfreundlichkeit der grafischen Beschreibung in der UML mit den Stärken der IP-XACT im Bereich Austauschbarkeit und Weiterverwendbarkeit kombiniert.
Neben den methodischen Lösungen aus dem akademischen Bereich bietet beispielsweise das grafische Modellierungswerkzeug STATEMATE der Firma I-Logix die entsprechende Tool-Umgebung für die Entwicklung Eingebetteter Systeme. Dabei fokussiert sich das Werkzeug auf die Beschreibung von Systemen mittels Zustandsautomaten. Es wurde bereits vor der UML entwickelt und lässt sich als Vorgänger des Modellierungswerkzeugs IBM® Rational® Rhapsody® verstehen [22].
SysML-basierte Modellierung
Da die in dieser Arbeit entwickelte Methode auf der SysML als Modellierungssprache aufbaut, sollen im folgenden Abschnitt entsprechende SysML-basierte Lösungen aus der Literatur gesondert betrachtet werden. So behandelt die Veröffentlichung [49] die Defizite bei der Dokumentation von Anforderungen in natürlicher Sprache und nutzt zusätzlich zum Use Case Diagram das in SysML enthaltene Requirement Diagram, um die Beziehungen der einzelnen Anforderungen zueinander im Modell abbilden zu können. Des Weiteren wird als zusätzliche Darstellungsform der SysML die tabellarische Darstellung der Anforderungen zur Steigerung der Übersichtlichkeit vorgeschlagen. Die Modellierung der Anforderungen soll hierbei noch vor der Anwendungsfallanalyse im Use Case Diagram stattfinden. Einen vergleichbaren Ansatz verfolgen die Autoren/-innen in [50]. Hier wird eine Kombination aus UML-, SysML- und MARTE-Stereotypen verwendet, um das Anforderungsmanagement in der Domäne Eingebetteter Systeme zu verbessern. Die UML dient dabei zur Modellierung der Funktionalen-, der Strukturellen- sowie der Verhaltenssicht des Systems. Die SysML wird als Ergänzung verwendet, um die Anforderungen im Requirement Diagram und die Beziehungen untereinander abzubilden. Zusätzlich wird eine „Traceability“-Matrix vorgestellt, mit der sich das Anforderungsmanagement optimieren lässt. Die Stereotypen des MARTE-Profils werden dabei verwendet, um die nichtfunktionalen Anforderungen zu spezifizieren.
Die Publikation in [51] kommt aus dem Umfeld der Chemie, beschäftigt sich jedoch ebenso mit der Beschreibung eines Systems mittels SysML. Dabei wendet der Autor zudem die SYSMOD-Methode für die Modellierung an. Ziel der Arbeit ist es, den Nutzen der SysML-basierten Systembeschreibung für die Spezifikation von Systemen aus dem Chemielabor zu testen, um daraus Erkenntnisse über die Funktionsweise des Systems gewinnen zu können.
Eine Fallstudie zum Nutzen von UML 2.0 und SysML für die SoC-Entwicklung wurde in [52] anhand eines Wireless LAN SoCs durchgeführt. Dabei kommen die Autoren/-innen zu dem Schluss, dass durch die Entwicklung der UML 2.0 und der SysML ein großer Meilenstein für die SoC-Entwicklung erreicht wurde, darüber hinaus jedoch die Standardisierung und Formalisierung der Sprachen erforderlich ist. Zudem wird die Notwendigkeit von leistungsbezogenen Aspekten für die Modellierung von SoCs genannt. Durch die Erweiterung der SysML und die Kombination von SysML mit MATLAB-Simulink-Modellen ermöglicht [53] die Modellierung von kontinuierlichem Zeitverhalten. Zusätzlich wird durch die Entwicklung eines Eclipse-basierten Ausführungstools die Co-Simulation der beiden Modelle ermöglicht [54] [55].
Für die Modellierung und modellbasierte Entwicklung von Systemen mittels SysML und UML steht eine Vielzahl unterschiedlicher Modellierungswerkzeuge zur Verfügung. So bietet die Firma Sparx Systems das Werkzeug Enterprise Architect, welches unter anderem die Anwender/-innen bei der Modellierung von UML und SysML unterstützt. Neben der reinen Modellierung bietet Enterprise Architect die Möglichkeit der Simulation sowie verschiedene Generatoren für die modellgetriebene Entwicklung [56].
VisualSim Architect der Firma Mirabilis Design ist ein weiteres Modellierungswerkzeug, welches für die Modellierung mit SysML entwickelt wurde. Das Modellierungswerkzeug ist dabei Teil einer Tool-Umgebung namens VisualSim. Mithilfe der darin enthaltenen Lösungen soll die Brücke zwischen SysML-basierter Spezifikation und MATLAB-Simulink-programmierter Implementierung geschlossen werden [57].
Neben den konventionellen Werkzeugen bietet die Open-Source-Lösung Eclipse Papyrus die modellbasierte Systementwicklung und Modellierung. Es bietet neben anderen Standard-Modellierungssprachen die Möglichkeit der Modellierung von UML und SysML und kann durch seinen Open-Source-Ansatz leicht an die jeweilige Domäne angepasst werden. Darüber hinaus wurde das „Papyrus Industry Consortium“ gegründet, um die Bedürfnisse der Industrie bei der Entwicklung des Werkzeugs zu berücksichtigen [58].
Eine weitere Entwicklungs- und Modellierungsumgebung bietet das in dieser Arbeit verwendete Werkzeug IBM® Rational® Rhapsody® der Firma IBM. Es bildet ein zentrales Werkzeug der Rational-Tool-Umgebung und bietet neben anderen Modellierungssprachen eine Oberfläche für die Modellierung von UML und SysML [59]. Eine nähere Beschreibung des Werkzeugs erfolgt in Abschnitt 5.1.
Abgrenzung zur Arbeit
Die in Abschnitt 3.1.1 vorgestellten Modellierungsmethoden bieten Lösungen für die modellbasierte Systementwicklung. Dabei wird als Teil der Modellierungsmethoden eine Arbeitsweise implementiert, welche die modellbasierte Analyse der Kundenanforderungen und der Anwendungsfälle beinhaltet. Zusätzlich ermöglicht die Modellierung des Systems ein besseres Systemverständnis sowie eine bessere Kommunikation zwischen Kunde und Entwickler und ermöglicht damit die Reduzierung von nachträglichen Änderungen an den vertraglich vereinbarten Anforderungen (A1).
Abschnitt 3.1.2 diskutiert Lösungen für die Modellierung von Systemen und die Formalisierung der Spezifikation. Dabei kann durch die Modellierung und im besonderen Maße durch die Formalisierung der Spezifikation die Eindeutigkeit dieser erheblich gesteigert und somit das Risiko für Interpretationen minimiert werden. Somit kann die Reduzierung von Implementierungsfehlern aufgrund einer unzureichenden Spezifikation (A2) und auch das Risiko von Inkonsistenzen (A3) durch die hier gezeigten Lösungen aus der Literatur erreicht werden. Dadurch ist zudem eine indirekte Aufwandsreduzierung, bezogen auf das Beheben von Fehlern und das Durchführen von Nachbearbeitungen, möglich. Der Aufwand bei der Implementierung des Entwurfs selbst (A7) kann durch diese Lösungen nicht reduziert werden. Ebenso kann für die Verifikation der Aufwand nur indirekt durch die höhere Eindeutigkeit der Spezifikation erreicht werden. Der Aufwand für die Erstellung der Verifikation bleibt unverändert hoch (A8). Einige der hier vorgestellten Lösungen kombinieren die Modellierung der Spezifikation mit einer der zuvor behandelten Modellierungsmethoden und ermöglichen somit sowohl die teilweise Erfüllung der Anforderungen A1 und A2 wie auch die Anforderung A3, wie in Tabelle 3.1 abgebildet.
3.2 Modellgetriebener Systementwurf und Verifikation
Neben der modellbasierten Spezifikation und Entwicklung von Systemen bietet die Literatur Lösungen der darauf aufbauenden modellgetriebenen Automatisierung des Systementwurfs und damit verbunden der Entwicklung von Virtuellen Prototypen. Der modellgetriebene Systementwurf und die damit verbundene Generierung finden dabei in verschiedenen Domänen Anwendung. Im nachfolgenden Abschnitt werden aufgrund der besonderen Anforderungen der Entwicklung von Eingebetteten Systemen in erster Linie Ansätze aus diesem Bereich diskutiert. Dabei wird der Einfluss der Lösungen auf den Implementierungsaufwand und damit die Erfüllung der Anforderungen A7 diskutiert.
Automatisierung Systementwurf
Die Publikationen [60] und [61] beschreiben einen Ansatz zur SysML-basierten Modellierung und anschließender Codegenerierung. Dabei findet mittels SysML-Profilen ein Mapping zwischen SysML-Stereotypen und SystemC-Code-Elementen statt. Für die automatisierte Codegenerierung verwendet der Autor die in Atego Artisan Studio enthaltenen Frameworks für die Model-zu-Code-Generierung TDK (Template Development Kit) und Shadow ACS. Ziel der Arbeiten ist es, die Lücke zwischen UML-/SysML-basierter Beschreibung und SystemC-basierter Verifikation und Synthese zu schließen. PTC Integrity Modeler, ehemals Atego Artisan Studio der Firma PTC, ist ein Werkzeug für die Modellierung von SysML, UML sowie für die Variabilitätsmodellierung [62] [63].
Einen vergleichbaren Ansatz bietet die Arbeit [64]; hierbei findet die Generierung des SystemC-Codes in zwei Schritten statt. Im ersten Schritt werden die UML-Modelle in XMI-Dateien umgewandelt. Anschließend wird auf Basis von vordefinierten Templates SystemC-Code generiert. Die Besonderheit der Arbeit ist die Modellierung und Generierung eines Bussystems mittels UML State Chart Diagram [65].
Wie bereits erwähnt ist die Anwendung von Virtuellen Prototypen weitestgehend etabliert. Darüber hinaus wurden bereits erste Möglichkeiten der Automatisierung entwickelt. So verwendet der Autor in [66] den generierten SystemC-Code zur Realisierung eines Virtuellen Prototyps. Dabei dient das SysML-Modell als Startpunkt der Entwicklung. Auf Basis des SysML-Modells wird eine grobe IP-XACT-Architekturbeschreibung erzeugt, welche im Nachfolgenden weiter verfeinert werden muss. Die Generierung des SystemC-Codes erfolgt somit auf Grundlage der verfeinerten IP-XACT-Registerbeschreibung.
Die Arbeit in [67] nutzt den modellbasierten Ansatz ebenfalls, um die Effizienz der Entwicklung von Prototypen zu steigern. Dabei wird die Architektur von SIMD (Single Instruction Multiple Data) SOCs mittels Kombination aus UML2 und MARTE-Profil beschrieben. Die so erhaltene Architekturbeschreibung wird um Bestandteile bestehender IP-Bibliotheken und Instruktionen aus einem parallel spezifizierten Befehlssatz erweitert. Dies ermöglicht die Generierung von VHDL-Code mittels MARTE2VHDL-Transformation und bietet somit die Möglichkeit, verschiedene Konfigurationen eines Systems je nach Anwendungsfall zu erzeugen.
Entwicklung Virtueller Prototypen
Die vorliegende Arbeit baut hinsichtlich der Automatisierung bei der Entwicklung von Virtuellen Prototypen auf der Arbeit von [15] auf. Daher soll diese nachfolgend ausführlicher als eine Lösung aus der Literatur für die modellgetriebene Entwicklung von Virtuellen Prototypen behandelt werden. Die Arbeit konzentriert sich dabei auf die Generierung von SystemC-Code für die signalverarbeitenden Komponenten des SoCs. Die nachfolgende Abbildung 3.1 zeigt somit den aktuellen Stand der VP-Entwicklung auf den die in Abschnitt 4.3 beschriebene Generierung aufbaut.
Abbildung 3.1
Aktueller Flow für Virtuelle Prototypen
×
Ausgangspunkt in der vorangegangenen Arbeit von [15] ist die Konzeptspezifikation, welche in der Regel in natürlicher Sprache beschrieben ist. Basierend auf der Konzeptspezifikation findet eine Verfeinerung der Informationen statt, wodurch das Modell der Signalverarbeitung, eine Registerbeschreibung in IP-XACT sowie die Entwurfsspezifikation entsteht. Aufbauend auf diesen drei Beschreibungsformen entstehen drei Pfade.
Die Arbeit von [15] ermöglicht eine Generierung der signalverarbeitenden Komponenten, welche sich für den Virtuellen Prototyp aus einem sogenannten SystemC-Wrapper-Signalpfad und einer SystemC-Verhaltensbeschreibung-Signalpfad zusammengesetzt werden. Dabei wird zuerst ein Modell der Signalverarbeitung erstellt und mit den Informationen der Registerbeschreibung in IP-XACT kombiniert. SystemC-Wrapper lassen sich vereinfacht als leere Modulhüllen mit definierten Schnittstellen verstehen.
Für die übrigen kontrollflussorientierten Module ermöglicht die Arbeit zudem, wie im mittleren Pfad 2 dargestellt, eine Generierung der SystemC-Wrapper auf Basis der IP-XACT-Registerbeschreibung. Um den generierten Wrapper jedoch mit der zugehörigen Verhaltensbeschreibung zu kombinieren, muss hier, wie im Pfad 2 dargestellt, die SystemC-Verhaltensbeschreibung der kontrollflussorientierten Module manuell implementiert werden. Gleiches gilt für die Informationen der Architektur, welche ebenfalls manuell als Teil von Pfad 3 aus den Anforderungen übertragen werden müssen. Es handelt sich somit in dieser Arbeit um einen teilautomatisierten Flow, der jedoch besonders in Pfad 2 der kontrollflussorientierten Module Lücken aufweist.
Eine weitverbreitete Entwurfsumgebung mit Fokus auf die Signalverarbeitung sind MATLAB und Simulink der Firma The MathWorks. MATLAB bildet dabei die proprietäre Entwicklungsumgebung und Programmiersprache für die Visualisierung, während Simulink eine blockbasierte Modellierungs- und Simulationsoberfläche bietet. Vergleichbares bietet die objektorientierte Sprache Modelica der Modelica Association, für deren Nutzung verschiedene kommerzielle sowie Open-Source-Modellierungs- und Simulationswerkzeuge wie zum Beispiel OpenModelica zur Verfügung stehen [68] [69].
Die große Stärke von MATLAB, Simulink und Modelica liegt in der Simulation; daher bieten diese sich als Ergänzung zu SysML-Modellierungswerkzeugen an, welche wiederum in der Regel Vorteile bei der Anforderungsmodellierung und dem Gesamtsystemdesign bieten [54] [55] [22].
Für die Entwicklung, Verwaltung und Simulation von Virtuellen Prototypen bietet das Unternehmen Synopsys neben anderen Werkzeugen die Eclipse-basierte Entwicklungsumgebung Virtualizer Studio, welche eine Kombination verschiedener Modellierungs- und Debuggingwerkzeuge darstellt. Die Entwicklungsumgebung wurde dabei speziell für die Halbleitertechnik entwickelt [70].
Ergänzend bietet Synopsys für die Entwicklung von Virtuellen Prototypen das Werkzeug Platform Architect Ultra an, welches der frühzeitigen Analyse und Optimierung von Multicore-SoC-Architekturen hinsichtlich Performance und Power dient [71]. Weitere Werkzeuge für die Entwicklung und Simulation von Virtuellen Prototypen bieten die Firma Mentor Graphics, genannt Vista Architect [72], und die Firma Cadence, genannt Virtual System Platform, an [73].
Automatisierung Verifikationserstellung
Neben der Reduzierung des Aufwandes bei der Implementierung wurde als Ziel die Aufwandsreduzierung bei der Verifikation (A8) angestrebt. In der Literatur bestehen dazu verschiedene Lösungsansätze:
Die Arbeit [74] ermöglicht eine semi-formale Beschreibung der Spezifikation in tabellarischer Form, wodurch zum einen die Eindeutigkeit der Spezifikation erhöht werden kann und zudem die Validierung der Spezifikation erleichtert wird. Darauf aufbauend wird die Generierung von SystemVerilog-Properties für die Verifikation auf Basis der tabellarischen Spezifikation ermöglicht.
Einen vergleichbaren Lösungsansatz bietet die Arbeit [75]. Hierbei wird die Generierung von SystemVerilog-Assertions auf Basis von Prozessor-Architektur-Beschreibungen sowie von Modellen ermöglicht. Darüber hinaus streben beide Arbeiten die Formalisierung der Spezifikation an und ermöglichen somit neben der Automatisierung der Verifikationserstellung die Reduzierung von Inkonsistenzen und Implementierungsfehlern aufgrund einer nicht eindeutigen Spezifikation.
Die Automatisierung des Systementwurfs wie auch der Verifikationserstellung birgt das Potenzial, den Aufwand für diese Bereiche der SoC-Entwicklung erheblich zu senken. Dabei bleiben jedoch die Defizite in der Systemkonzeptentwicklung wie auch der Interpretierbarkeit der Spezifikation meist unverändert.
Abgrenzung zur Arbeit
Die in diesem Kapitel vorgestellten Lösungen für die modellgetriebene Systementwicklung und Verifikation bieten Ansätze zur modellbasierten Codegenerierung. Da sich die Lösungen dabei meist auf die Realisierung von Generatoren oder die Entwicklung eines Generierungs-Flows für einen spezifischen Anwendungsfall fokussieren, haben diese nur einen indirekten und geringen Einfluss auf die Anforderungen A1, A2 und A3, welche verschiedene qualitative Aspekte der Spezifikation betreffen. Darüber hinaus beschäftigen sich die Arbeiten aus der Literatur nicht mit Themen wie der Integrierbarkeit der Lösungen in den bestehenden SoC-Entwicklungs-Flow (A4), dem Einfluss der Lösungen auf den Aufwand bei der Spezifikation (A5) oder der Anwenderfreundlichkeit der jeweiligen Lösungen (A6).
Zu Beginn des Kapitels werden Lösungen für die Automatisierung des Systementwurfs verschiedener Domänen und als Teil dessen die Erstellung von Virtuellen Prototypen mittels modellbasierter Codegenerierung diskutiert. Die Automatisierung ermöglicht in erster Linie die Reduzierung des manuellen Aufwandes für die Implementierung des Entwurfs (A7), hat jedoch darüber hinaus in der Regel indirekt einen positiven Einfluss auf die Konsistenz zwischen implementiertem System und Spezifikation, da Interpretationen der Spezifikation vermieden werden können.
Die Lösungsansätze zur Automatisierung der Verifikationserstellung haben in erster Linie die Reduzierung des Aufwandes in diesem Bereich (A8) zum Ziel, beschäftigen sich jedoch darüber hinaus mit der Formalisierung der Spezifikation und führen damit zu einer Steigerung der Eindeutigkeit. Wie bereits beschrieben, führt eine Steigerung der Eindeutigkeit der Spezifikation seinerseits zu einer Reduzierung der Wahrscheinlichkeit für Implementierungsfehler (A2) und Inkonsistenzen (A3).
3.3 Abgrenzung zur Arbeit
In dem nachfolgenden Abschnitt folgt die Abgrenzung der vorliegenden Arbeit von den in der Literatur beschriebenen Lösungen. Die hier entwickelte und vorgestellte Methode soll die in Abschnitt 1.1 definierten Anforderungen erfüllen. Daher werden die Lösungen der Literatur, wie zu Beginn des Kapitels beschrieben, auf die Erfüllung der in dieser Arbeit gestellten Anforderungen A1–A8 geprüft und somit eine Abgrenzung der Arbeit erreicht. Zusätzlich hebt sich die hier entwickelte Methode von allen dem Autor bekannten Ansätzen und Methoden aus der Literatur durch die folgenden Merkmale in Summe maßgeblich ab:
Die modellbasierte Entwicklungsmethode zielt auf die Steigerung der Effizienz in der SoC-Entwicklung über alle Phasen des SoC-Entwicklungs-Flows hinweg ab. Die Methode ermöglicht hierfür einen modellbasierten Ansatz von der Analyse der Kundenforderungen über die Spezifikation des SoCs und die Entwicklung des Systemkonzeptes bis hin zur Automatisierung des Entwurfs und der Verifikationserstellung.
Die Methode beinhaltet eine an den Bereich der SoC-Entwicklung angepasste domänenspezifische Formalisierung einer standardisierten und grafischen Modellierungssprache.
Die Bereitstellung eines Automotive-SoC-Profils auf Basis einer „Stakeholder“-Befragung, welches den domänenspezifischen Anforderungen angepasst wurde und somit möglichst optimal die Bedürfnisse der Anwender/-innen erfüllt.
Die Möglichkeit, die Methode in den bestehenden Entwicklungs-Flow mit dessen spezifischen Arbeitsweisen, Tools und Beschreibungsformaten zu integrieren.
Einen kombinierten Ansatz für die Spezifikation aus Systemmodell und in natürlicher Sprache beschriebener Systemanforderungen.
Aufgrund der dargestellten Eigenschaften unterscheidet sich die Methode bereits von den in dieser Arbeit diskutierten Ansätzen aus der Literatur. So bieten reine Modellierungsmethoden eine eindeutigere Beschreibungsform bei der Systementwicklung und unterstützen dabei in der Regel eine umfangreiche und modellbasierte Analyse zu Beginn der Entwicklung. Eine ausführliche Analyse und modellierte Beschreibung des Systems kann somit benötigte nachträgliche Änderungen der vertraglich vereinbarten Anforderungen reduzieren (A1). Die Definition des Modells als Teil der Spezifikation und die Formalisierung der Spezifikation erhöhen darüber hinaus die Eindeutigkeit der Spezifikation. Durch diese zugewonnene Eindeutigkeit müssen die Entwickler/-innen die Informationen nicht mehr interpretieren, wodurch das Risiko für Implementierungsfehler (A2) und Inkonsistenzen zwischen Spezifikation und Entwurf (A3) reduziert werden kann. Einzelne der hier diskutierten Lösungsansätze aus der Literatur kombinieren die modellbasierte Spezifikation des Systems mit einer standardisierten Modellierungsmethode und ermöglichen somit die Erfüllung der Anforderungen A1, A2 und A3 gleichermaßen.
Neben Defiziten in der Spezifikation und Systemkonzeptentwicklung wurden Lösungen für die Automatisierung des Systementwurfs, der Entwicklung von Virtuellen Prototypen (A7) und der Verifikationserstellung (A8) aus dem Bereich der Eingebetteten Systeme diskutiert.
In der nachfolgenden Tabelle 3.1 wird sowohl der Vergleich der vorgestellten Lösungen aus der Literatur als auch die Erfüllung der genannten Anforderungen zusammengefasst dargestellt.
Tabelle 3.1
Vergleichende Einordnung der Lösungen aus der Literatur
Abschnitt
Lösungsansatz
Lösung
A1
A2
A3
A4–A6
A7
A8
Modellbasierte Systementwicklung
Modellierungsmethode
[32]
✓
✗
✗
–
–
–
[33]
✓
✓
✗
–
–
–
[22]
✓
✗
✗
–
–
–
[34]
✓
✗
✗
–
–
–
Spezifikationslogiken
[35]
✗
✗
✓
–
–
–
[36]
✗
✗
✓
–
–
–
[37]
✗
✗
✓
–
–
–
Objekt–orientierte Modellierungssprachen.
[38]
✗
✓
✓
–
–
–
[39]
✗
✓
✓
–
–
–
[40]
✗
✓
✓
–
–
–
[41]
✗
✓
✓
–
–
–
[42]
✗
✓
✓
–
–
–
[43]
✓
✓
✓
–
–
–
[44]
✓
✓
✓
–
–
–
[45]
✓
✓
✓
–
–
–
[46]
✗
✓
✓
–
–
–
[47]
✗
✓
✓
–
–
–
[48]
✗
✓
✓
–
–
–
SysML-basierte Ansätze
[49]
✗
✓
✓
–
–
–
[50]
✗
✓
✓
–
–
–
[51]
✓
✓
✓
–
–
–
[52]
✗
✓
✓
–
–
–
[53]
✗
✓
✓
–
–
–
Modell-getriebener Systementwurf und Verifikation
Automatisierung
Systementwurf
[60]
–
✗
✗
–
✓
✗
[61]
–
✗
✗
–
✓
✗
[64]
–
✗
✗
–
✓
✗
[66]
–
✗
✗
–
✓
✗
[67]
–
✗
✗
–
✓
✗
[15]
–
✗
✗
–
✓
✗
Autom. Verifikationserstellung
[74]
✗
✓
✓
–
✗
✓
[75]
✗
✓
✓
–
✗
✓
Open Access Dieses Kapitel wird unter der Creative Commons Namensnennung 4.0 International Lizenz (http://creativecommons.org/licenses/by/4.0/deed.de) veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Kapitel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
