4. Methode zur abstrakten Modellierung von Automotive Systems-on-Chips

Zur Definition einer Methode für die modellbasierte Systementwicklung bedarf es nicht in jedem Fall der Festlegung einer zu verwendenden Modellierungssprache, wie am Beispiel der in Kapitel 3 diskutierten MDA-Methode zu sehen ist. Da jedoch in dieser Arbeit eine Formalisierung der modellbasierten Spezifikation erfolgen soll und damit eine Zuweisung von Modellelementen und Diagrammen zu einer SoC-spezifischen formalisierten Bedeutung, ist dies nur durch die vorherige Auswahl einer Modellierungssprache möglich.

Ein Automotive SoC besteht, wie in Abschnitt 2.​6.​1 beschrieben, aus Komponenten verschiedener Domänen. Somit muss sich auch die gewählte Modellierungssprache für die Modellierung aller dieser Domänen eignen. Darüber hinaus sollten die Eindeutigkeit und die Lesbarkeit der Informationen erhöht werden. Dies wird durch die Verwendung einer standardisierten und grafischen Modellierungssprache begünstigt. Durch die bereits beschriebene modulare Implementierung der SoCs eignet sich besonders die Verwendung einer objektorientierten Modellierungssprache. Diese Anforderungen an die Modellierungssprache werden durch die in Abschnitt 2.​5.​2 vorgestellte SysML vollständig erfüllt. Daher baut die nachfolgend konzeptuell behandelte Methode dieser Arbeit auf der SysML als Modellierungssprache auf.

Um neben der Auswahl der Modellierungssprache die Kombination der zuvor genannten Ansätze für die Systementwicklung zu ermöglichen, ist die Definition einer an die speziellen Anforderungen der SoC-Entwicklung angepassten Modellierungsmethode notwendig. Dabei dient die in dieser Arbeit beschriebene Methode nicht nur zur Definition einer Arbeitsweise für die modellbasierte Systementwicklung von SoCs. Als Teil der Methode wird zudem eine Modellstruktur definiert, welche die Anwender/-innen an diese Arbeitsweise weitestgehend binden soll. Die Modellierungsmethode implementiert dabei eine Arbeitsweise nach dem Top-down-Ansatz und baut zudem auf der in Kapitel 3 vorgestellten SPES-Methode von [34] auf. Durch die Definition der Modellstruktur als Teil der Methode wird nicht nur ein Wiedererkennungswert zwischen den Modellen und damit eine allgemeine Lesbarkeit aller Modelle erreicht, es wird zudem der Modellierende in gewissem Maße an die Verwendung der Methode gebunden. Nachfolgend soll die SysML-basierte Modellierungsmethode anhand der in Abbildung 4.4 gezeigten Modellstruktur dieser Arbeit beschrieben werden.

Die Struktur ist dabei in drei Submodelle unterteilt, deren Inhalt sich an dem in Abschnitt 2.​6.​1 beschriebenen analytischen Vorgehen des Top-down-Ansatzes orientiert, und weist zudem den Diagrammen der SysML eine formale Bedeutung für die SoC-Entwicklung zu. Damit wird nachfolgend der Grundstein für die Formalisierung der Spezifikation gelegt. Die Aufteilung des Modells in Submodelle erfolgt durch das in Abschnitt 2.​5 vorgestellte Modellelement, genannt Package.

Nachfolgend soll als Teil der hier entwickelten Methode die Formalisierung für die modellbasierte Spezifikation von SoCs aufgezeigt werden. Auf die Bedeutung der Diagramme wurde bereits als Teil der Beschreibung der Modellstruktur in Abschnitt 4.1.1 eingegangen. Nachfolgend soll die Verwendung der Diagramme näher behandelt sowie die Bedeutung der jeweiligen Modellelemente bezogen auf die Automotive-SoC-Entwicklung formalisiert werden. Darüber hinaus findet als Teil der Formalisierung eine Einschränkung der für die Methode anzuwendenden SysML-Modellelemente im jeweiligen Diagramm statt. Zur Veranschaulichung soll für die wichtigsten Diagramme exemplarisch die Zuweisung von Modellelement zur formalen Bedeutung in den nachfolgenden Tabellen – Tabelle 4.1, 4.2, 4.3, 4.4, 4.5 und Tabelle 4.6 – vorgestellt werden.

Als Teil von Abschnitt 4.1.1 wurde das entwickelte Automotive-SoC-Profil, welches die definierte Modellstruktur den Anwendern/-innen in Form von Packages zur Verfügung stellt, bereits vorgestellt. Nachfolgend werden weitere Inhalte des in dieser Arbeit entwickelten Automotive-SoC-Profils beschrieben. Tabelle 4.7 zeigt dazu einen Auszug der wichtigsten Elemente des Automotive-SoC-Profils.

Da, wie in Abschnitt 4.1.1 beschrieben, jedes Submodell als Teil dieser Methode definierte Diagramme enthalten kann, können sowohl die Modellstruktur als auch die typischen Diagramme bereits als Teil des Profils vorgefertigt zur Verfügung gestellt werden. Darüber hinaus wurden in Zusammenarbeit mit SoC-Entwicklern/-innen eine Reihe von Modellelementen definiert, welche im Regelfall für die Modellierung eines jeden SoC-Systemkonzeptes benötigt werden. So wurde beispielsweise ein generischer SoC-Block mit zugehörigem Part sowie ein generalisierter Block einer SoC-Komponente, ebenfalls mit zugehörigem Part, modelliert. Diese Templates werden zudem bereits mit vordefinierten Ports ausgestattet, welche mit hoher Wahrscheinlichkeit später für das jeweilige Element benötigt werden. Auf Grundlage einer „Stakeholder“-Befragung, welche Aspekte der SoC-Entwicklung aus ihrer Sicht im Modell abgebildet werden müssen, wurden zudem als Teil des Profils funktionale sowie nichtfunktionale Eigenschaften in Form von Datentypen und Variablen definiert [82]. Ein Beispiel hierfür ist die Definition einer Variable samt möglichen Werten für das ASIL. Bei ASIL handelt es sich, wie in Abschnitt 2.​2 beschrieben, um ein Risikoklassifizierungssystem [13]. Die Definition des ASIL ist fester Bestandteil der SoC-Entwicklung und wird somit in allen zukünftigen Entwicklungsprojekten benötigt. Darüber hinaus hat es eine durch die Norm definierte Anzahl an Werten und bietet sich somit optimal als Bestandteil des Automotive-SoC-Profils an. Die Definition solcher Datentypen und Variablen als Teil des Profils sorgt nicht nur für eine einheitliche Namenskonvention über alle Modelle hinweg, sondern führt dazu, dass die Entwickler/-innen sich bereits bei der Modellierung mit diesen Aspekten der SoC-Entwicklung auseinandersetzen muss. Besonders bei dem hier gezeigten Beispiel, der Bestimmung des ASIL für Module des SoCs, ist es wichtig, dass dies bei der Modellierung nicht vergessen wird.

Das Automotive-SoC-Profil mit den enthaltenen Templates und vordefinierten Variablen reduziert den Aufwand für die Anwender/-innen bei der Modellierung der Spezifikation, ermöglicht durch die einheitliche Namenskonvention eine zusätzliche Vereinheitlichung der Spezifikationen und senkt zudem die Fehleranfälligkeit. Da es speziell für die Anforderungen der Automotive-SoC-Entwicklung entwickelt wurde, ist es essenzieller Bestandteil der hier vorgestellten Methode zur modellbasierten Systementwicklung. Als Teil der Modellierungsmethode wird das Automotive-SoC-Profil einem Modell eines SoC-Entwicklungsprojekts lediglich als referenziertes Objekt hinzugefügt, wie in Abbildung 4.7 dargestellt.

Der Nutzer kann den Inhalt des Profils für seine Modellierung nutzen, jedoch keine direkten Änderungen an den Inhalten im Profil vornehmen. Da das Profil jedoch im Laufe der Zeit an die Bedürfnisse der Anwender/-innen angepasst werden soll, empfiehlt sich eine zentrale Verwaltung des SoC-Profils.

Durch die Anwendung der Modellierungsmethode auf das Systemkonzept lassen sich alle Informationen des Systemkonzeptes in nur einem zentralen Dokument spezifizieren. Verglichen mit der formlosen Sammlung aus verschiedenen Beschreibungsformen im aktuellen Flow kann so die Konsistenz gewährleistet werden. Dennoch beinhaltet das Systemkonzept Informationen, deren Spezifikation sich in anderen Formaten als der SysML besser eignen oder sich hierfür andere Formate als „Goldstandard“ für bestimmte Anwendungen in der Praxis erwiesen haben. Um diese Formate mit der SysML kombinieren zu können und so die Vorteile der jeweiligen Beschreibungsform für die Spezifikation zu addieren, werden als Teil der hier vorliegenden Arbeit Schnittstellen und Interaktionsmöglichkeiten diskutiert. Nachfolgend sollen drei der wichtigsten Formate sowie die Möglichkeiten der Kombination betrachtet werden.

In dem vorangegangenen Abschnitt wurde ein Konzept für die modellbasierte Systemkonzeptentwicklung vorgestellt. Abbildung 4.9 erweitert den in Abbildung 4.2 abstrahierten Entwicklungs-Flow um die in diesem Kapitel vorgestellten Anteile der Methode bis zum Übergang von der Konzeptphase zur Entwurfsphase.

In Abschnitt 4.1.1 wurde die in dieser Arbeit entwickelte Modellierungsmethode, in der Abbildung 4.9 gelb dargestellt, behandelt. Dabei unterstützt die Methode die Entwickler/-innen bei einer weniger lösungsorientierten Arbeitsweise nach dem Top-down-Ansatz und fördert so zu Beginn der Systementwicklung die ausführliche Analyse der Kundenanforderungen. Durch die ausführliche und modellbasierte Analyse der Kundenanforderungen und somit einer Analyse der Anwendungsfälle und des technischen Systemkontextes kann ein einheitliches Systemverständnis zwischen Kunde und Entwickler geschaffen werden. Hierdurch sowie durch die in Abschnitt 4.1.2 beschriebene Formalisierung wird die Wahrscheinlichkeit für unterschiedliche Interpretationen der Spezifikationsdokumente verringert und somit Folgefehler reduziert. Durch die Implementierung des Top-down-Ansatzes als Teil der Modellierungsmethode und die modellbasierte Analyse der Kundenanforderungen kann eine Senkung der Wahrscheinlichkeit für nachträgliche Änderungen an den bereits vertraglich vereinbarten Anforderungen in Lasten- und Pflichtenheft erreicht werden. Somit ermöglicht die hier vorgestellte Modellierungsmethode für die modellbasierte SoC-Systemkonzeptentwicklung die Erfüllung der in der in Abschnitt 1.​1 definierten Anforderung A1 zumindest teilweise.

Das Systemmodell entspricht in der Konzeptphase dem modellierten Systemkonzept. In Abbildung 4.9 wird das SysML-Modell abstrahiert als SysML-Funktions- und Architekturbeschreibung dargestellt und ist zu Beginn der Konzeptphase mit dem Pflichtenheft und später mit der daraus hervorgehenden Konzeptspezifikation, in der Abbildung 4.9 als roter Pfeil dargestellt, bidirektional verlinkt. Die Systemanforderungen werden aus den Kundenanforderungen abgeleitet und ergeben sich zudem aus der Entwicklung des Systemkonzepts. Die Modellierung und Formalisierung des Systemkonzeptes als ein zentrales Spezifikationsdokument in direkter Verlinkung mit den Systemanforderungen aus der Konzeptspezifikation sorgt darüber hinaus für eine Eindeutigkeit und Vollständigkeit der Spezifikationsdokumente in der Konzeptphase. Da in der später folgenden Entwurfsphase zu Beginn die Basis des Systemkonzeptes implementiert wird, ist die Steigerung der Vollständigkeit, Korrektheit und Eindeutigkeit dieses Dokuments entscheidend für eine erfolgreiche Implementierung des SoCs. Durch die Formalisierung der modellbasierten Spezifikation kann somit von einer mindestens teilweise Erfüllung der Anforderung A2 ausgegangen werden.

Die Erweiterung der Methode mittels Automotive-SoC-Profil, in Abbildung 4.9 hellgelb dargestellt, wurde in Abschnitt 4.1.3 behandelt. Dieses sorgt durch die im Profil zur Verfügung gestellten Templates zu einer modellübergreifenden Einheitlichkeit in der Modellstruktur und Namenskonvention. Hierdurch bietet es Mechanismen zur Reduzierung des Modellierungsaufwandes und reduziert somit den Aufwand der Spezifikation, verglichen mit der aktuell angewandten Arbeitsweise. Durch das Profil werden die Anwender/-innen in der Umsetzung der Methode bei der Modellierung unterstützt und damit die Anwenderfreundlichkeit der Methode erhöht. Durch die Erweiterung der Methode um das in dieser Arbeit entwickelte Automotive-SoC-Profil wird daher ebenfalls die Erfüllung der Anforderungen A5 und A6 ermöglicht.

Abschnitt 4.1.4 behandelt die Kombination des mittels SysML modellierten Systemkonzeptes mit anderen etablierten Beschreibungsformen heutiger SoC-Entwicklungen. Dabei stellt die Signalverarbeitung einen essenziellen Bestandteil eines SoCs dar, für dessen Beschreibung sich andere Formate etabliert haben und somit als optimale Ergänzung dient. Ebenso hat die Schnittstelle zur Registerbeschreibung in IP-XACT einen besonderen Stellenwert, da hieraus die Namenskonvention für die Register und Bitfelder des SoCs hervorgehen, welche ebenfalls im modellierten Systemkonzept eingehalten werden müssen. Darüber hinaus bietet die hier vorgestellte Methode eine ebenfalls toolbasierte Lösung für die bidirektionale Verlinkung zwischen den Anforderungen und den Modellelementen im Systemkonzept. Die Betrachtung der Schnittstellen und die Kombination der für den jeweiligen Anwendungsfall optimalen Beschreibungsform, gepaart mit der Möglichkeit der Verlinkung der unterschiedlichen Beschreibungsformen ermöglicht eine Steigerung der Konsistenz. Eine konsistente Spezifikation über alle Dokumente und Formate hinweg führt zu einer Minderung von Inkonsistenzen zwischen Spezifikation und Implementierung in der Entwurfsphase. Somit ermöglicht die hier beschriebene Methode die Erfüllung der in Abschnitt 1.​1 beschriebenen Anforderungen A3. Darüber hinaus wurde durch die Entwicklung und Nutzung von Schnittstellen zwischen dem SysML-basierten Systemkonzept und bereits etablierten ergänzenden Beschreibungsformen die Integration der in dieser Arbeit entwickelten Methode in den bestehenden Entwicklungs-Flow ermöglicht und somit kann die Anforderungen A4 als erfüllt angesehen werden.

Ein Beispiel für die Verfeinerung der Architektur ist die Modellierung von On-Chip-Bussen als Teil der Hardware-Architektur. Die Busse der Hardware-Architektur werden, wie alle Teile der Architektur, als Blöcke im BDD und als Parts im IBD modelliert. Dies geschieht in der Regel bereits in der Konzeptphase. Spätestens in der Entwurfsphase reicht es jedoch nicht mehr aus, den Bus abstrahiert als nicht näher spezifizierten Part der Architektur zu modellieren. Es wird neben der Architektur der SoC-Architektur auf System-Ebene eine Modellierung der Busarchitektur benötigt. Damit wird, vergleichbar mit einer Verbindungstabelle, definiert wie die Komponenten über den Bus kommunizieren. Um dies im Modell zu realisieren, wird als nächsttiefere Abstraktionsebene hinter dem Part des Busses im Architecture Diagram ein weiteres IBD mit der Busstruktur hinterlegt. Dieses IBD der Busstruktur zeigt die Module, welche über den Bus verbunden sind und löst dabei die Busarchitektur mittels Connectoren auf. Das bedeutet, die Parts als Repräsentation der Hardware-Komponenten werden direkt miteinander verbunden.

Dies ist nur ein Beispiel für den Prozess der Verfeinerung des Architekturmodells als Teil der Spezifikation. Vergleichbar wird bei den einzelnen Komponenten bzw. Modulen vorgegangen. So können Module in Submodule mit eigenen Architekturmodellen zerlegt werden, um die Module weiter zu spezifizieren. Darüber hinaus findet beim Übergang zwischen Konzept- und Entwurfsphase, als Teil der Modellverfeinerung, die Einteilung der in der Konzeptphase rein funktional betrachteten Module in die in Abschnitt 2.​6.​1 beschriebenen Domänen analoge Hardware, digitale Hardware und Software statt.

Das Behavioral Model ist, wie in Abbildung 4.4 gezeigt, Teil des Technical Model. Es wird dabei allerdings einem eigenen Package zugeordnet, da hieraus später die Codegenerierung ermöglicht werden soll. Im Behavioral Model wird das Verhalten sowohl von der Hardware als auch von der Software des SoCs modelliert. Dabei kann zum einen das Modell als reine Spezifikation, welche das implementierte Verhalten grafisch repräsentiert und als Teil der Entwurfsspezifikation spezifiziert, dienen. Zum anderen kann die Entwicklung des Verhaltens in der Entwurfsphase ebenfalls modellbasiert erfolgen. Das bedeutet, die Entwicklung des geforderten Verhaltens der einzelnen Module beginnt im Systemmodell. Dabei wird zu Beginn das Verhalten eines Moduls noch abstrahiert modelliert und kann anschließend in mehreren Schritten und je nach Bedarf verfeinert werden. Die anfängliche Abstrahierung, welche die Modellierung bietet, kann bei der Entwicklung komplexer Funktionen und Operationen helfen und bietet zudem eine übersichtliche Kommunikationsgrundlage. Zusätzlich bietet diese Arbeitsweise einen entscheidenden Vorteil bei der Automatisierung der Entwicklung. So wird durch die formalisierte und maschinenlesbare Beschreibung mittels SysML ein Format in der Spezifikation geschaffen, welches es ermöglicht, Code auf Basis des Modells zu generieren.

Im Behavioral Model können alle verhaltensbeschreibenden Diagramme der SysML in einer formalisierten Form zum Einsatz kommen. Nachfolgend soll am Beispiel des Activity Diagram beziehungsweise des Flowchart Diagram die Formalisierung für das Behavioral Model aufgrund der hohen Relevanz für diese Arbeit beispielhaft beschrieben werden. Dabei muss durch die doppelte Verwendung der verhaltensbeschreibenden Diagramme je nach Submodell denselben Modellelementen eine unterschiedliche formale Bedeutung zugeordnet werden.

Im vorangegangenen Abschnitt wurde der Übergang zwischen Konzept- und Entwurfsphase im Kontext der in dieser Arbeit vorgestellten modellbasierten Entwicklungsmethode behandelt. Dabei findet ein Wechsel der Arbeitsweise von einer rein konzeptionellen Entwicklung zu einer implementierungsfokussierten Entwicklung statt. Aufgrund dieses Wechsels in der Arbeitsweise verändert sich auch die Rolle des Systemmodells wie in Abbildung 4.10 dargestellt. So wird das Systemmodell, welches dem Systemkonzept in der Konzeptphase entspricht und als zentrales Spezifikationsdokument der Entwicklung in dieser Phase dient, zu einem Bestandteil der Entwurfsspezifikation.

Als Teil des Übergangs zwischen Konzept- und Entwurfsphase bedarf es einer Verfeinerung der Architektur sowie einer Modellierung des Verhaltens der Software- und Hardwaremodule. Dazu wurde in dem vorangegangenen Abschnitt an Beispielen aus der SoC-Entwicklung die Verfeinerung der Modellierung veranschaulicht und als Teil dessen die Formalisierung der Spezifikation für den Bereich der Verhaltensbeschreibung erweitert.

Als Möglichkeit für die Automatisierung wurde der Bereich der Entwicklung von Virtuellen Prototypen identifiziert. Wie in Abschnitt 2.​6.​4 beschrieben, kann durch die Verwendung von Virtuellen Prototypen die Software zu einem früheren Zeitpunkt entwickelt und getestet werden. Darüber hinaus wird durch die Verwendung von Virtuellen Prototypen ein Hardware/Software-Co-Entwurf ermöglicht. Somit können viele Fehler in einer früheren Phase der Entwicklung entdeckt werden und lassen sich dadurch leichter beheben. Hierdurch ist es möglich, Aufwand und Kosten bei der Entwicklung zu reduzieren. Jedoch entsteht bei der Erstellung eines Virtuellen Prototyps zusätzlicher Aufwand, welcher zudem parallel zu anderen Entwicklungsaufgaben anfällt. Daraus resultiert ein höherer Bedarf an Personenstunden zur selben Zeit. Um diesen Nachteil zu eliminieren, ohne dabei auf die Vorteile bei der Nutzung von Virtuellen Prototypen verzichten zu müssen, wurde ein modellbasierter Ansatz für die Generierung des Virtuellen Prototyps entwickelt.

Die Automatisierung mittels modellgetriebener Generierung bietet sich hierbei besonders an, da der Virtuelle Prototyp in der Regel abstrahiert auf System-Ebene realisiert wird. Zudem werden bei einigen Modulen lediglich die Funktionalitäten realisiert, die für die Simulation des Software/Hardware-Interfaces benötigt werden. Da im Technical Model die Architektur auf System-Ebene bereits modelliert ist, ist ebenso bereits ein Großteil der für die Generierung benötigten Informationen enthalten. Lediglich die implementierungsnahen Informationen der Architektur sowie die Verhaltensbeschreibung im Behavioral Model, welche aufgrund der anfangs noch abstrakten Modellierung des SoCs fehlen, müssen ergänzt werden. Die Verfeinerung der Modellierung ist in Abschnitt 4.2 beschrieben. Anhand der nachfolgenden Abbildung 4.11 sollen die Vorteile eines automatisierten Entwicklungs-Flows mit dem Flow aus Abbildung 2.​22 verglichen werden.

Die Abbildung 4.11 veranschaulicht dabei schematisch die Aufwände der einzelnen Entwicklungsphasen. Durch den modellbasierten Ansatz teilt sich die Spezifikation in zwei Abschnitte. Hinzu kommt der hier dunkelgrün dargestellte Abschnitt für die formale Spezifikation. Bei der formalen Spezifikation handelt es sich um die Modellierung des Systemmodells. Auf Grundlage dieses Modells kann der Virtuelle Prototyp generiert und damit der manuelle Aufwand bei der Entwicklung reduziert werden. Hierdurch wird nicht nur der Aufwand in Gesamtheit reduziert, es wird ebenso eine schnellere Fertigstellung des Virtuellen Prototyps und damit ein früherer Beginn der On-Chip-Softwareentwicklung ermöglicht.

Wie bereits ausgeführt, ist die Anwendung von Virtuellen Prototypen weitestgehend etabliert. Darüber hinaus wurden bereits erste Möglichkeiten der Automatisierung entwickelt, wie in Abschnitt 3.​2 dargelegt. Die Arbeit von [15] beschreibt dazu einen teilautomatisierten Entwurfs-Flow für die Implementierung von Virtuellen Prototypen. Dabei konzentriert sich der in [15] beschriebene Generierungs-Flow auf die Generierung der signalverarbeitenden Anteile des SoCs auf Basis von MATLAB-Simulink-Modellen. Dieser teilautomatisierte Entwurfs-Flow für die Implementierung von Virtuellen Prototypen wurde durch die in dieser Arbeit entwickelten Lösungen zur modellbasierten Generierung der kontrollflussorientierten Anteile sowie der Architektur des SoCs erweitert. Abbildung 4.12 zeigt, als Auszug von Abbildung 3.​1, noch einmal Pfad 2 und Pfad 3 und stellt damit den Stand der Technik zum Startzeitpunkt dieser Arbeit dar.

Es handelt sich, wie in Abschnitt 3.​2 beschrieben, um einen teilautomatisierten Entwurfs-Flow, der besonders in Pfad 3 der kontrollflussorientierten Module Lücken bei der Automatisierung aufweist. Hinzu kommt, dass das in der Konzeptphase entwickelte Systemkonzept im aktuellen Entwicklungs-Flow nicht Teil der offiziellen Spezifikation ist und die hier enthaltenen Informationen manuell in die Konzeptspezifikation bzw. die Entwurfsspezifikation übertragen werden müssen. Neben dem in Abbildung 4.11 schematisch dargestellten Mehraufwand bei der manuellen Implementierung eines Virtuellen Prototyps birgt jede manuelle Übertragung von Informationen das Potenzial für Fehler und Inkonsistenzen.

Darüber hinaus müssen bereits in der Entwurfsspezifikation beschriebene Informationen manuell in Code übersetzt werden, da das ursprüngliche Format nicht maschinenlesbar ist. An eben diesen Stellen setzt die in dieser Arbeit entwickelte modellgetriebene Methode an. Da das Systemkonzept, wie in Abschnitt 4.1 beschrieben, bereits als SysML-Modell entwickelt wurde, steht es nun in einem maschinenlesbaren Format zur Verfügung. Darüber hinaus gilt es durch die Formalisierung als Teil der Spezifikation, wodurch die dort modellierten Informationen nicht manuell in ein anderes beschreibendes Format übertragen werden müssen. Das Systemkonzept zu Beginn der Entwurfsphase entspricht dem Systemmodell und muss lediglich, wie in Abschnitt 4.2 beschrieben, für die Generierung verfeinert werden, wie in Abbildung 4.13 dargestellt.

Das Systemmodell wird in der Abbildung 4.13 abstrahiert als SysML-Verhaltens- und Architekturbeschreibung repräsentiert und ist Teil der Entwurfsspezifikation. Der gestrichelte hellgelbe Pfeil zwischen IP-XACT-Registerbeschreibung und Entwurfsspezifikation veranschaulicht die in Abschnitt 4.1.4 beschriebene Schnittstelle und die damit verbundene Bekanntmachung der Registernamen im Systemmodell.

Wie in Abbildung 4.13 gezeigt, wurde im ersten Schritt die Generierung der Verhaltensbeschreibung für die kontrollflussorientierten Module realisiert. Dazu wurde das Systemmodell um die Verhaltensbeschreibung in Form des in Abschnitt 4.2.2 vorgestellten Behavioral Model erweitert. Zur Generierung der SystemC-Verhaltensbeschreibung wurde ein C++ -Generator für die Modellierung von SystemC-Code auf Basis von SysML-Modellen konfiguriert. Zur Beschreibung des Verhaltens wurde in dieser Arbeit auf die Modellierung mittels Flowchart Diagram zurückgegriffen. Die Modellierbarkeit von Parallelität der Activity Diagrams wird im Regelfall bei der Modellierung von Funktionskörpern nicht benötigt, würde jedoch zu einer deutlich höheren Komplexität bei der Generierung führen. Die Informationen über die Architektur werden zu diesem Zeitpunkt, wie in Abbildung 4.13 gezeigt, weiterhin manuell übertragen.

Um diesen letzten manuellen Schritt ebenfalls zu automatisieren, wurde eine skriptbasierte Generierung und damit eine Übertragung der Architekturinformationen, wie in Abbildung 4.14 gezeigt, gewählt. Eine detaillierte Beschreibung der skriptbasierten Lösung folgt in Abschnitt 5.​3.​2.

Anders als die Verhaltensbeschreibung ist die Architekturbeschreibung bereits im modellierten Systemkonzept auf System-Ebenen enthalten. Es muss lediglich eine Verfeinerung bzw. Präzisierung der modellierten Informationen, wie in Abschnitt 4.2.1 beschrieben, für die Generierung erfolgen. Die Generierung erfolgt in zwei Schritten. Im ersten Schritt werden alle benötigten Informationen der Architekturbeschreibung aus dem Technical Model vollautomatisiert in Tabellen übertragen. Anschließend werden die Informationen aus den erhaltenen Tabellen extrahiert und die Architekturinformationen in den Virtuellen Prototyp übertragen. Durch die hier gezeigte Erweiterung des teilautomatisierten Entwurf-Flows aus [15] um den modellgetriebenen Ansatz für die kontrollflussorientierten Module wird ein vollautomatisierter Generierungs-Flow für die Implementierung von Virtuellen Hardware-Prototypen ermöglicht.

Wie in Abschnitt 2.​5.​1 beschrieben, wurde die UML als Softwarebeschreibungssprache entwickelt. Diese Fähigkeit blieb auch in der SysML im Kern erhalten und so lassen sich Software-Operationen und -Funktionen mittels Activity Diagrams bzw. Flowchart Diagrams darstellen und beschreiben. Aufgrund der steigenden Anforderungen und der daraus resultierenden Komplexität der SoCs gewinnt die On-Chip-Software, wie bereits in Abschnitt 2.​6.​5 beschrieben, immer stärker an Bedeutung. So werden immer mehr Funktionalitäten als Softwarecode auf Mikroprozessoren realisiert.

Wurde im vorangegangenen Abschnitt die Entwicklung der Virtuellen Prototypen automatisiert, um Softwarekonzepte bereits in einer früheren Phase der Entwicklungsphase testen zu können, soll nun die Softwareimplementierung selbst automatisiert werden. Durch die Automatisierung der Softwareentwicklung ist es möglich, den manuellen Aufwand in einer frühen Phase der Entwicklung zusätzlich zu senken, wie in Abbildung 4.15 veranschaulicht.

Neben der in der Abbildung 4.15 veranschaulichten erheblichen Reduzierung des Aufwandes durch die Generierung der On-Chip-Software beinhaltet dieser Schritt weitere entscheidende Vorteile. So wird durch die modellgetriebene Generierung der Software die Wahrscheinlichkeit von Fehlern reduziert. Dies gilt besonders in Hinblick auf Inkonsistenzen zwischen modellierter Spezifikation und implementierter Software. Wird der hier entwickelte Softwaregenerierungs-Flow als Teil der Gesamtmethode in vollem Umfang eingesetzt, werden Änderungen am generierten Code lediglich durch Änderungen an dem Modell vorgenommen und der Code anschließend neu generiert. Dies ermöglicht die Sicherstellung einer zu jeder Zeit vollständigen und bezogen auf den generierten Code konsistenten Entwurfsspezifikation.

Diese Konsistenz der Spezifikation im aktuellen Entwicklungs-Flow zu gewährleisten, ist aufgrund der großen Entwicklungsteams, der langen Entwicklungszeiten und dem hohen Zeitdruck sehr schwierig. In der Entwurfsphase werden viele Entwurfsentscheidungen und Anpassungen im Zuge der Implementierung vorgenommen und direkt in Software bzw. Hardware umgesetzt. Die Dokumentation der Entwurfsentscheidungen und die Anpassungen in der Entwurfsspezifikation kommen dabei häufig zu kurz und es entstehen Inkonsistenzen.

Die modellbasierte Generierung der Software erfolgt in C-Code mittels eines in dieser Arbeit konfigurierten Generators. Das Ergebnis der Generierung wird dabei maßgeblich durch zwei Faktoren beeinflusst. Zum einen hängt der resultierende Code von der Konfiguration des Generators und dem damit verbundenen Mapping zwischen SysML-Modellelement und C-Code ab. Zum anderen wird sie entscheidend durch die Modellierungstechnik beeinflusst. Auf die Konfiguration des Generators wird in Kapitel 5 näher eingegangen. Der Einfluss der Modellierung soll am Beispiel der Modellierung von Schleifen- und If-Abfragen veranschaulicht werden. Dabei kommt das bereits vorgestellte Modellelement Decision Node zum Einsatz. Lediglich die Art der Verbindungen mittels Activity Flow entscheidet darüber, ob der Generator den modellierten Ablauf als Schleife oder If-Abfrage interpretiert und dementsprechend C-Code generiert. In Abbildung 4.16 werden die beiden Modellierungen gegenübergestellt.

Links in Abbildung 4.16 ist eine While-Schleife als Beispiel dargestellt. Hierbei dient die Decision Node als Entscheidungsknoten. Der Actionblock LoopBody dient als Schleifenkörper und enthält die Anweisungen, wie zum Beispiel das Hochzählen einer Zählervariablen, welche in der Schleife ausgeführt werden sollen. Der Guard am Activity Flow, welcher den Entscheidungsknoten mit dem LoopBody verbindet, dient als Schleifenbedingung für den Entscheidungsknoten. Ist die Schleifenbedingung nicht erfüllt, gilt der zweite Weg vom Entscheidungsknoten zum Terminationspunkt; dies ist gleichzeitig das Funktionsende.

Rechts in der Abbildung 4.16 ist die Modellierung einer If-Abfrage bzw. in diesem Fall einer If-Else-Abfrage abgebildet. Zentrales Modellelement ist wieder die Decision Node als Entscheidungsknoten. Ist die If-Bedingung des linken Entscheidungspfades erfüllt, wird die Anweisung des Actionblocks exampleAction2 ausgeführt. Ist die If-Bedingung nicht erfüllt, greift der Else-Entscheidungspfad und der Actionblock wird übergangen. Die beiden Entscheidungspfade laufen wieder zusammen in einem Modellelement, welches in der Darstellung der Decision Node deckungsgleich ist. Jedoch handelt es sich hierbei um einen Merge Node, der die Aufgabe erfüllt, Entscheidungsknoten zusammenzuführen. Beide Entscheidungspfade enden im selben Terminationspunkt, was auch hier dem Funktionsende entspricht.

Durch die Zunahme in Umfang und Komplexität der Implementierung und die damit einhergehende Heterogenität von Automotive SoCs wächst die Verifikation dieser Systeme zu einer herausfordernden Aufgabe für die SoC-Entwicklung. Die Aufwände für die Verifikation komplexer Systeme übersteigen dabei, wie in der Fallstudie in [84] gezeigt, stellenweise die Aufwände für den Entwurf selbst.

So ist eine hohe Qualität in Form von Fehlerfreiheit, Robustheit und Zuverlässigkeit entscheidend bei der Entwicklung von Automotive SoCs, welche beispielsweise im Bereich der Fahrassistenzsysteme und der Fahrsicherheitssysteme zum Einsatz kommen. Um dies sicherzustellen, bedarf es einer umfangreichen Verifikation [2]. Diese zu planen, zu entwickeln und durchzuführen führt zu erheblichen Kosten- und Zeitaufwänden und schränkt nach heutigen Methoden die Effizienz der SoC-Entwicklung ein. Daher sollen als Teil der in dieser Arbeit entwickelten modellbasierten Entwicklungsmethode Möglichkeiten der Aufwandsreduzierung in der Verifikation betrachtet werden. Dabei werden zwei Aspekte der Verifikation maßgeblich durch die hier entwickelte Gesamtmethode aufgegriffen:

In diesem Abschnitt wurden Möglichkeiten der modellgetriebenen Automatisierung für den Systementwurf betrachtet. Dazu wurde die Generierung der Architekturbeschreibung wie auch der Verhaltensbeschreibung des Hardware-VPs konzeptuell behandelt, und die Vorteile der Automatisierung wurden diskutiert. Darüber hinaus wurde die Generierung der On-Chip-Software als Teil der hier beschriebenen Methode vorgestellt sowie die Automatisierung der Verifikationserstellung behandelt. Die Automatisierung als Teil der Implementierung ist in Abbildung 4.17 als Übergang zwischen Systemmodell und den Bereichen Software, Hardware-VP (Virtueller Prototyp) und Verifikation dargestellt.

Die Generierung erfolgt bei den hier behandelten Ansätzen auf Basis der SysML-Architektur- bzw. der Verhaltensbeschreibung des Systemmodells. Durch die modellgetriebene Generierung von Code entsteht die Möglichkeit einer Arbeitsweise, welche Änderungen am implementierten Entwurf nur durch Änderungen am Modell erlaubt. Dies ermöglicht somit eine nahezu vollständige Konsistenz zwischen modellierter Spezifikation und implementiertem Code und unterstützt damit die Erfüllung der Anforderung A3. Durch die Automatisierung selbst kann gemäß Anforderung A7 der Aufwand bei der Implementierung für die jeweiligen Bereiche der Entwicklung reduziert werden. Darüber hinaus wird durch die Modellierung und Formalisierung der Spezifikation verbunden mit der Automatisierung eine Reduzierung des Aufwandes in der Verifikationserstellung (Anforderung A8) ermöglicht.