2. Grundlagen

Wie bereits erwähnt, beginnt die Entwicklung mit der Auftragserstellung durch den Auftraggeber, im Folgenden als Kunde bezeichnet. Dabei wird nach Lehrbuch das Lastenheft vom Kunden an den Auftragnehmer, im Folgenden als Entwickler bezeichnet, übergeben. Darin definiert der Kunde seine Vorstellungen über das zu entwickelnde System, definiert Anwendungsfälle, legt den technischen Kontext des Systems fest und definiert gegebenenfalls Soll- oder Grenzwerte. Die Analyse und adäquate Beschreibung dieser Informationen setzt jedoch ein gewisses Maß an Verständnis für die Technologie des zu entwickelnden Systems voraus. Daher findet bei der Entwicklung solch komplexer Systeme wie im Bereich der SoCs die Definition der Kundenanforderungen im Lastenheft oftmals bereits in Zusammenarbeit zwischen Kunde und Entwickler statt. Die genauen Inhalte des Lastenhefts sind in der DIN 69905 standardisiert. So sollte das Lastenheft neben den technischen Anforderungen auch qualitative und terminliche Anforderungen sowie auch Kostenanforderungen enthalten [14, p. 33] [16].

Auf Grundlage des Lastenheftes entwickelt der Auftragsnehmer bzw. Entwickler des Zielsystems das Pflichtenheft. Das Pflichtenheft dient zur Spezifikation des Systems, welches der Entwickler zu entwickeln gedenkt, um damit die Kundenanforderungen zu erfüllen. So können beispielsweise Performance-Eigenschaften, Toleranzbereiche und Grenzwerte zugesichert werden. Man spricht hierbei von Systemanforderungen. Nach allgemeiner Definition, wie in der DIN 69905, beschreibt das Pflichtenheft zudem, wie das System umgesetzt werden soll. Dies ist jedoch durch die hohe Komplexität in der SoC-Entwicklung zum Zeitpunkt der Pflichtenhefterstellung nur auf einer sehr abstrakten Ebene möglich. So werden die Funktionalitäten des Systems lediglich aus der Sicht des Kunden beschrieben. Zusätzlich zur Spezifikation des Systems dient das Pflichtenheft als Angebot an den Auftraggeber und bei Zustandekommen als Vertragsgrundlage für das Entwicklungsvorhaben. Dazu wird das Pflichtenheft zum Stand des Vertragsabschlusses in der Regel gemeinsam final geprüft und anschließend eingefroren [14, p. 33] [16].

Um Systemeigenschaften im Pflichtenheft zusichern zu können, erstellen die SoC-Architeken/-innentin parallel dazu ein erstes Konzept des Systems, nachfolgend als Systemkonzept bezeichnet. Das Systemkonzept besteht dabei meist aus einer formlosen Sammlung verschiedener Anforderungen, Tabellen, Notizen und Zeichnungen, die den SoC auf System-Ebene beschreibt. Aufgrund der formlosen Art des Systemkonzepts kann das Systemkonzept im aktuell bestehenden Entwicklungs-Flow nicht als offizielles Spezifikationsdokument gesehen werden. Die Entwicklung des Systemkonzeptes geht weit über die Definition des Pflichtenhefts hinaus und ist entscheidend für eine erfolgreiche Systementwicklung. So wird bereits hier eine Vielzahl an Entwurfsentscheidungen, oftmals auf Grundlage von Annahmen über das spätere System, getroffen. Dabei werden einzelne Module definiert und in die entsprechenden Domänen unterteilt. Die gesamte Entwicklung findet hierbei jedoch rein konzeptuell statt; es wird in der Regel nicht implementiert. Der Begriff des Moduls wird in dieser Arbeit für eine funktionale Einheit im SoC verwendet, die Komponente dagegen entspricht einem bestimmten Hardwarebauteil, wie beispielsweise einem bestimmten Typ eines Mikrocontrollers, welcher im SoC verbaut werden soll.

Da bei der Entwicklung des Systemkonzeptes weitere Systemanforderungen entstehen, welche über das bereits eingefrorene Pflichtenheft hinausgehen, werden diese in dem darauf aufbauenden Spezifikationsdokument, hier als Konzeptspezifikation bezeichnet, dokumentiert. Die zusätzliche Spezifikation des Systemkonzepts ist entscheidend für die spätere Entwurfsphase und die darauffolgende Verifikation des Systems.

Erreicht das Systemkonzept und damit die Konzeptspezifikation einen gewissen Reifegrad, wird dieser Stand eingefroren; die Konzeptphase endet und die Entwurfsphase beginnt [16].

Der Übergang zwischen Konzeptphase und Entwurfsphase führt zu einem Wechsel der Arbeitsweise. In der Konzeptphase findet die Entwicklung des SoCs rein konzeptuell auf Basis des Systemkonzeptes statt und wird meist von einem kleinen Team aus SoC-Architekt/-innen entwickelt; es wird nichts implementiert. Die Entwicklung endet in dieser Phase normalerweise auf Systemebene des SoCs.

In der Entwurfsphase steht die Implementierung des SoCs und seiner Module im Fokus. Dabei werden die maßgeblich in der Konzeptphase entwickelten Modulanforderungen an die Modulentwickler/-innen übergeben. Diese arbeiten meist alleine oder in kleinen Teams an einem Modul. Eine Projektleiterin oder ein Projektleiter, im Bereich der SoC-Entwicklung in der Regel als SoC-Architekt/-in bezeichnet, übernimmt die Koordination der einzelnen Entwicklerteams.

Die Konzeptspezifikation beinhaltet die Anforderungen an die Module, welche an die Modulentwickler/-innen zu Beginn der Entwurfsphase übergeben werden. Diese beginnen mit der Entwicklung und Implementierung der jeweiligen Module. Dabei findet erneut eine Dekomposition des Moduls in Submodule, Gatter und schließlich in Transistoren statt. Während dieses Prozesses treffen die Modulentwickler/-innen Entwurfsentscheidungen, woraus neue Systemanforderungen entstehen. Die Dokumentation der Systemanforderungen erfolgt während der Entwurfsphase in der Entwurfsspezifikation, welche auf der Konzeptspezifikation aufbaut. Die Entwurfsspezifikation sollte daher zu jedem Zeitpunkt der Entwurfsphase ein möglichst genaues Abbild des implementierten Entwurfs darstellen.

In dieser Phase arbeiten bis zu 60 Entwickler/-innen parallel an der Implementierung der einzelnen Module. Da diese Module jedoch am Ende erfolgreich als Gesamtsystem interagieren müssen, ist es entscheidend, dass jeder Modulentwickler und jede Modulentwicklerin über den Systemkontext seines Moduls Bescheid weiß. Dazu dient in erster Linie das Systemkonzept. Da sich dieses jedoch in der Entwurfsphase ebenfalls weiterentwickelt, ist die Entwurfsspezifikation wichtigste Grundlage für einen Wissenstransfer zwischen den einzelnen Modulentwicklern/-innen. Die Koordination der einzelnen Entwicklungsarbeiten übernehmen die SoC-Architekten/-innen [16].

Da sich die Entwicklungszeit eines SoCs zwischen fünf und zehn Jahren bewegt und ein Großteil dieser Zeit der Entwurfsphase entspricht, ist es entscheidend, die Vollständigkeit und Richtigkeit der Entwurfsspezifikation neben dem Entwurf zu prüfen. Die dazu verwendeten Methoden werden in Abschnitt 2.3.5 beschrieben.

Die Sicherstellung der Korrektheit und Vollständigkeit sowohl von Spezifikation als auch von Entwurf ist integraler Bestandteil der Entwicklung. Um dies zu ermöglichen, stehen unterschiedliche methodische Ansätze zur Verfügung, welche im Folgenden dargelegt werden.

In der Simulation wird in der Regel durch das Simulieren definierter Szenarien die Abwesenheit von Fehlern überprüft. So lassen sich die wichtigsten Funktionalitäten eines Systems weitestgehend auf Fehlerfreiheit prüfen. Die Korrektheit des implementierten Entwurfs lässt sich hingegen durch die Simulation nicht garantieren, da lediglich eine begrenzte Zahl an Eingabefällen überprüft werden kann [17, pp. 295–296].

Die Validation ist in weiten Teilen Bestandteil des beschriebenen Reviews zwischen den Entwicklungsphasen. Sie dient zur Überprüfung der Spezifikation auf Vollständigkeit, Fehlerfreiheit, Konsistenz und Eindeutigkeit und prüft dabei, ob das Spezifikationsdokument der jeweiligen Phase den Kundenanforderungen entspricht. Bei der Validation können somit Spezifikationsfehler aufgedeckt werden. Dies ist entscheidend für die Verifikation [18].

Die Verifikation prüft, ob das Verhalten des Entwurfs der Spezifikation entspricht. Ist die Spezifikation nicht vollständig, können diese Bereiche nicht geprüft werden. Dadurch sind Fehler möglich, die meist erst in der Produktion oder beim Kunden entdeckt werden. Formale Verifikation meint die vollständige Verifikation des Systems, was sehr aufwendig und bei komplexen Systemen wie SoCs nur schwer umsetzbar ist [18].

Aufgrund der hohen Relevanz der Verifikation und Validierung für die vorliegende Arbeit und für die SoC-Entwicklung selbst werden die Verifikation und die Validierung in Abschnitt 2.6.8 ausführlich behandelt.

Am Ende des Entwicklungs-Flows wird das System bzw. in diesem Fall der SoC erst an die Produktion und anschließend an den Kunden übergeben. Um das Produkt einsetzen zu können, benötigt der Kunde eine ausführliche Dokumentation, hier als technische Kundendokumentation bezeichnet. Diese stellt eine Teilmenge der Entwurfsspezifikation dar. Darin sollten dem Kunden alle Informationen, die später die Applikationsingenieure/-innen beispielsweise zur Interaktion mit dem System benötigen, zu Verfügung gestellt werden, ohne dabei jedoch zu viel Wissen über das System preiszugeben. Darüber hinaus enthält die technische Kundendokumentation oftmals Empfehlungen und Einschränkungen, wie das System zu benutzen ist, um kein unerwartetes Verhalten zu provozieren. Damit kann die falsche Verwendung seitens des Kunden vermieden werden und der Entwickler bzw. Zulieferer sichert sich im Falle einer nicht vorhergesehenen Verwendung rechtlich ab.

Bei den jeweiligen Spezifikationsdokumenten handelt es sich nicht um unabhängige Dokumente, sondern meist um eine Weiterentwicklung des Spezifikationsdokuments der vorangegangenen Phase, wie in Abbildung 2.5 veranschaulicht. Die namentliche Trennung der Spezifikationsdokumente dient in dieser Arbeit der Zuordnung der Spezifikationsdokumente zur jeweiligen Phase.

Die blau dargestellten Blöcke entsprechen den Spezifikationsdokumenten sowie der technischen Kundendokumentation. Die grauen Blöcke auf der rechten Seite des Entwicklungs-Flows den daraus entstehenden bzw. verlinkten Anteilen, welche jedoch nicht Teil der Spezifikation selbst sind. Die weißen Pfeile stehen für die weitestgehend manuellen Übergänge zwischen den Spezifikationsdokumenten selbst sowie zwischen jeweiligem Spezifikationsdokument und dem Systemkonzept bzw. Systementwurf. Die Validierung der Spezifikationsdokumente findet in der Regel bei den Übergängen zwischen diesen statt.

Durch die Erweiterungen in der UML2 wuchsen die Einsatzmöglichkeiten der Modellierungssprache über die Domäne der Softwaresysteme hinaus. Die UML als weltweiter Industriestandard wird durch die Object Management Group (OMG) verwaltet und stetig weiterentwickelt [22, pp. 157–162] [23].

Die „Systems Modeling Language“ (SysML) entstand ehemals aus der in Abschnitt 2.5.1 beschriebenen UML und ist wie diese ein Industriestandard der OMG. Die SysML wurde entwickelt, um zusätzlich zur Software auch komplette Systeme zu modellieren, und kann damit bei allen System-Engineering-Anwendungen zum Einsatz kommen. Anfangs stellte die SysML lediglich eine Art Dialekt der UML dar, welche in vielen Fällen über vergleichbare Sprachmechanismen verfügt. Spätestens seit der Entwicklung der SysML 2.0 jedoch, wird sie meist als eigenständige Sprache betrachtet [22] [25]. So lässt sich in Abbildung 2.11 die Schnittmenge zwischen UML und SysML erkennen.

Zu erkennen ist der große Anteil der UML-Diagramme, welche identisch oder lediglich modifiziert in die SysML übernommen wurden. Oftmals wurde lediglich eine Verallgemeinerung der Bezeichnungen einzelner Diagramme und Elemente vorgenommen, um sich von dem Fokus der Softwareentwicklung zu lösen. Ein Beispiel ist die Umbenennung vom Klassen- ins Blockdiagramm und der Modellelemente Klassen in Blöcke. Diese verfügen im Grunde über die gleichen Eigenschaften; lediglich die Bezeichnung ermöglicht eine allgemeinere Verwendung. Die SysML stellt somit einen Werkzeugkasten aus Diagrammen und Modellelementen zur Verfügung. Darüber hinaus wurde jedoch keine Methodik standardisiert, wie die Diagramme zu verwenden sind. Diese fehlende Zuordnung von Diagrammen und Modellelementen zu einer spezifischen Bedeutung ermöglicht zum einen ein sehr breites Anwendungsfeld aufgrund der generischen Beschreibung, wird jedoch zum anderen dann zum Hindernis, wenn firmen-, team- und systemübergreifend gearbeitet werden soll. Ein mögliches Szenario wäre ein Modell einer Steuereinheit, welche in das übergeordnete Systemmodell des Fahrzeugs eingebunden werden soll. Hierbei müssen meist Modelle unterschiedlicher Entwicklungsteams zusammengesetzt werden, was sich ohne eine gemeinsame Modellierungsmethode nur mit erheblichem Aufwand realisieren lässt.

Im Nachfolgenden sollen die Diagramme der SysML und ihre übliche Verwendung behandelt werden. Die Abbildung 2.12 zeigt die enthaltenen Diagramme als Baumstruktur und veranschaulicht über die Farbgebung, welche Diagramme aus der UML2 übernommen, welche modifiziert und welche neu entwickelt wurden.

Die Diagramme lassen sich in drei Oberkategorien unterteilen: die Verhaltensdiagramme, die Strukturdiagramme und das Anforderungsdiagramm. Die grün hinterlegten Anteile stehen für die Diagramme, welche neu in der SysML hinzugefügt wurden. Die orangen Blöcke stehen für Diagramme, welche verglichen mit der UML verändert wurden und die blauen Diagramme sind identisch wie in der UML2.

Zusätzlich zu bestehenden Modellierungssprachen lassen sich sogenannte „Domain-Specific Modeling Languages“ (DSMLs) definieren. Dabei wird eine Modellierungssprache speziell für eine Domäne entwickelt und definiert, um sie ideal an die Anforderungen der Domäne anzupassen. So bieten DSMLs bei der Modellierung eine hohe Anwenderfreundlichkeit, da die Modellelemente bereits mit Fachbegriffen versehen sind und die Anwender/-innen diese daher nicht erst rekonstruieren müssen. Darüber hinaus sollte aufgrund einer sorgfältigen Analyse der Anforderungen bei der Entwicklung der DSML diese keine Modellelemente oder Diagramme enthalten, welche nicht von den Anwendern/-innen benötigt werden. Für eine bessere Verständlichkeit der DSML-Modelle sorgt die grafische Anpassung der Modelle an die Domäne [26].

Neben den Vorteilen einer DSML lassen sich besonders drei Nachteile nennen:

Die Literatur bietet verschiedene Definitionen für den Vorgang der Formalisierung einer Modellierungssprache. In dieser Arbeit wird die Definition aus dem ISO/IEC/IEEE 31320–2-Standard zugrunde gelegt. Die Formalisierung wird hierbei als Definition einer genauen Semantik und damit einer Zuweisung von Modellelementen bzw. Diagrammen zu einer formalen Bedeutung beschrieben. Sie ermöglicht damit die genau definierte Interpretation aller Bestandteile eines Modells. Darüber hinaus beinhaltet die Formalisierung eine Einschränkung der zu verwendenden Modellelemente und Diagramme einer Modellierungssprache. Dabei dienen Metamodelle zur Beschreibung der zulässigen Diagramme, zur Definition dessen, was ein jeweiliges Diagramm enthalten darf, sowie zur Definition der Bedeutung der jeweiligen Modellelemente. Für das Modellieren der Metamodelle wird dabei meist die zu formalisierende Sprache verwendet, wodurch auch hier die Gefahr von Interpretationsfehlern entsteht. Um dies zu verhindern, eignet sich die Verwendung einer Prädikatenlogik als formale Sprache zur eindeutigen Beschreibung der Zuordnung zwischen Modellelement und formaler Bedeutung. Die Beschreibung mittels Prädikatenlogik erschwert hingegen jedoch den Wissenstransfer der Formalisierungsregeln zu den Anwendern/-innen, wodurch sich eine Kombination der beiden Ansätze empfiehlt: die eindeutige Beschreibung mittels Prädikatenlogik und die zusätzliche Veranschaulichung der Zusammenhänge als Metamodell für die Anwender/-innen.

SoCs sind heterogene Systeme, das heißt, sie setzen sich aus Teilsystemen zusammen, deren Datenverarbeitung auf grundsätzlich unterschiedlichen Signalarten beruhen. SoCs lassen sich in die Domänen Analog- und Digitaltechnik unterteilen. In der Analogtechnik basiert die Datenübertragung und -verarbeitung auf Basis von Spannungen und Strömen. In der Digitaltechnik erfolgt die Datenverarbeitung rein digital. Die analogen Anteile des SoCs werden vollständig durch Hardware realisiert. Dementgegen lassen sich die digitalen Anteile des SoCs in einen digitalen, festverdrahteten Hardware-Anteil und einen digitalen, programmierbaren Software-Anteil unterteilen. Aufgrund der damit einhergehenden unterschiedlichen Anforderungen werden für die Entwicklung unterschiedliche Entwurfsmethoden benötigt [14, p. 57]. Es ergeben sich drei Entwurfsdomänen:

Viele Funktionen des SoCs lassen sich sowohl in Hardware als auch in Software realisieren. Somit muss im Laufe des Entwicklungsprozesses diese Partitionierung durch die Entwickler/-innen erfolgen. Dies geschieht in der Regel bereits in der in Abschnitt 2.3.2 beschriebenen Konzeptphase. Dabei unterscheiden sich Hardware und Software maßgeblich in den folgenden Kriterien:

Aufgrund der hohen Komplexität heutiger Hardwaresysteme, besonders im Bereich der SoC-Entwicklung, findet der Entwurf auf mehreren Abstraktionsebenen statt. Dabei beginnen Entwickler/-innen in der Regel auf der höchsten Abstraktionsebene, d. h. auf Grundlage eines stark abstrahierten Systems bzw. SoCs, und verfeinern die Struktur und Verhaltensbeschreibung in mehreren Iterationsstufen bis zur Transistor-Ebene, welche den Abschluss des Entwicklungsprozesses darstellt. Das Y-Diagramm von Gajski und Kuhn definiert dazu fünf Abstraktionsebenen bzw. Entwicklungsstufen [27]. In Anlehnung an das Y-Diagramm werden nachfolgend Abstraktionsebenen aus Sicht der Struktur, bezogen auf die Automotive-SoC-Entwicklung, für diese Arbeit definiert:

Die in Abschnitt 2.3.2 beschriebene Konzeptentwicklung findet sowohl für die Funktions- als auch für die Struktursicht in erster Linie in der System-Ebene statt. Jedoch werden als Teil des Systemkonzepts in der Regel zudem Teile der Algorithmen- und der RT-Ebene beschrieben, wie beispielsweise die Register des SoCs.

Werden die im vorigen Abschnitt beschriebenen Abstraktionsebenen strikt sequenziell bearbeitet, spricht man von einer Entwicklung nach dem Top-down-Ansatz. Ganz allgemein sieht der Top-down-Ansatz eine Bearbeitung eines Problems anfangs auf einer stark abstrahierten Ebene vor. Anschließend soll in mehreren iterativen Schritten das Problem dekomponiert werden, um eine Menge kleinerer und leichter lösbarer Teilprobleme zu erhalten [14, p. 51].

Überträgt man diesen Ansatz auf die SoC-Entwicklung, stehen zu Beginn statt eines Problems die Kundenanforderungen bzw. eine geforderte Funktionalität des SoCs. Diese sind in der Regel sehr abstrakt beschrieben und müssen zu Beginn durch die Entwickler/-innen analysiert und dekomponiert werden. Um Kundenanforderungen zu analysieren, empfiehlt sich zu Beginn eine Anwendungsfallanalyse. Da Nutzer des Systems oftmals andere Systeme oder Komponenten sind, muss parallel eine Analyse des technischen Systemkontextes durchgeführt werden. Das bedeutet, es findet eine technische Betrachtung der umliegenden Komponenten und Systeme statt, mit denen der SoC später interagiert. Die Analysen dienen zudem dazu, ein einheitliches Verständnis über die Nutzung und den Kontext des geforderten Systems zu erlangen. Aus den hierbei gewonnenen Anwendungsfällen lassen sich Funktionen ableiten, welche das System den Nutzern zur Verfügung stellen muss. Um diese Funktionen zu realisieren, bedarf es wiederum einer Menge an Teilfunktionen, die durch eine Dekomposition analysiert werden können. Dieser Schritt soll jedoch losgelöst von der Auswahl möglicher Hardware-Komponenten des SoCs oder anderer Entwurfsentscheidungen erfolgen. Durch dieses Vorgehen wird zum einen die Wahrscheinlichkeit reduziert, Funktionen nicht zu berücksichtigen, zum anderen werden keine Funktionen realisiert, die nicht vom Kunden gefordert wurden.

Hat die Dekomposition der Funktionen eine gewisse Tiefe erreicht, kann im nächsten Schritt ein Systemkonzept entwickelt werden. Dabei werden Funktionen in Module zusammengefasst und erste Entwurfsentscheidungen über die Architektur des SoCs getroffen. Der SoC wird in dieser Phase in der Regel lediglich abstrahiert auf System-Ebene entwickelt. Während der Entwicklung des Systemkonzeptes entstehen Modulanforderungen, welche in mehreren Modulspezifikationen zusammengefasst werden. Diese Modulspezifikationen werden zu Beginn der Entwurfsphase an die jeweiligen Modulentwickler/-innen übergeben, welcher mit der Implementierung der Hardware bzw. Software beginnen.

Ein Werkzeug des Top-down-Ansatzes ist die Entwicklung von Hardware-Prototypen noch vor Fertigstellung der eigentlichen Hardware. Da hierbei die Hardware – meist auf System-Ebene – lediglich abstrahiert als Prototyp realisiert wird, kann so die Simulation von Hard- und Software zu einem früheren Zeitpunkt der Entwicklung erfolgen. Es wird dabei lediglich eine Teilfunktionalität der Hardware im Prototyp nachgebildet, welche für die Interaktion mit der Software benötigt wird.

Eine Möglichkeit der Realisierung von Hardware-Prototypen ist die Implementierung mittels FPGA. FPGA-Prototypen bieten eine sehr zuverlässige Möglichkeit der Simulation. Dementgegen steht die aufwendige Implementierung des FPGA als Prototyp, welche zudem meist erst in einer späten Phase der Hardware-Entwicklung erfolgt. Einen weit flexibleren Ansatz bietet die Implementierung des Prototyps mittels SystemC als sogenannter Virtueller Prototyp (VP) [15]. Bei SystemC handelt es sich um ein Hardware-Beschreibungsframework und eine Bibliothek der Sprache C++, welche die Implementierung von Virtuellen Prototypen ermöglichen. SystemC bietet bei der Simulation von Hardware die Möglichkeit einer Abstrahierung im Vergleich zu anderen Hardware-Beschreibungssprachen und damit eine bessere Performance bei der Simulation. Die Möglichkeit der Abstrahierung ist ein entscheidender Vorteil für die Entwicklung von Virtuellen Prototypen, da so bereits vor Fertigstellung eines vollständigen und finalen Entwurfs der Hardware erste Konzepte der Hardware und Software gemeinsam getestet werden können. Darüber hinaus bedeutet die Abstrahierung zwar in der Regel einen Verlust der Möglichkeit einer Taktzyklen-genauen Simulation, wobei eine solche Taktzyklen-genaue Ausführung der Simulation im Zusammenhang mit Virtuellen Prototypen meist nicht gefordert beziehungsweise nicht benötigt wird [28] [29]. Die Implementierung des Virtuellen Prototyps kann bereits parallel zur Spezifizierung des SoCs begonnen werden, wie in Abbildung 2.22 veranschaulicht.

Die Abbildung 2.22 zeigt abstrahiert den Entwicklungs-Flow eines SoCs. Im ersten Flow wurde kein Virtueller Prototyp eingesetzt und so erfolgt die Entwicklung der Hardware und Software vollständig sequenziell. Im zweiten Flow wird bereits parallel zur Erstellung der Spezifikation mit der Entwicklung des Virtuellen Prototyps begonnen und somit eine parallele Entwicklung von Software und Hardware ermöglicht. Zum Abschluss der Entwicklung erfolgt die Systemintegration und damit die Zusammenführung von Hardware und Software, in der Abbildung 2.22 als kurzer hellblauer Pfeil am Ende des Flows dargestellt. Durch den Einsatz der Virtuellen Prototypen kann im Idealfall eine Reduktion der Time-to-Market (TTM, Zeit bis zur Markteinführung), also der Zeit, die das Produkt von Auftragserteilung bis Marktfreigabe benötigt, erreicht werden.

Zusätzlich ermöglicht dieser Ansatz eine Validierung des Hardware/Software-Interfaces und somit die Entwicklung von Hardware und Software in ständigem Austausch über Änderungen am Systemkonzept. Dies ermöglicht, dass Fehler, welche bei einer linearen Entwicklung sonst erst in einer deutlich späteren Phase gefunden werden, früher entdeckt und somit leichter behoben werden können. Hierdurch können somit bei der Entwicklung zusätzlich Aufwand und Kosten reduziert werden.

Aufgrund der steigenden Anforderungen und der daraus resultierenden Komplexität der SoCs gewinnt die On-Chip-Software immer stärker an Bedeutung. So bietet die Realisierung des SoC-Verhaltens als Software eine einfachere und damit kostengünstigere Alternative für die Entwicklung und ermöglicht, verglichen mit der Realisierung mittels spezifischer Hardware, zudem nachträgliche Korrekturen und Erweiterungen bei minimalem Aufwand. Lediglich die Ausführungszeit der Standardprozessoren, welche die Software ausführen, ist in der Regel langsamer, wodurch besonders im Bereich der Automotive SoCs weiterhin Teile als spezifische Hardware realisiert werden müssen.

Die Realisierung der Software für Eingebettete Systeme erfolgt in einer maschinenlesbaren höheren Programmiersprache wie beispielsweise C. Anschließend übersetzt der Compiler die Software in Maschinencode bzw. Assembler-Code. Da es sich bei SoCs oftmals um Echtzeitsysteme handelt, welche strengen Beschränkungen unterliegen, ergeben sich auch für die Softwareentwicklung in diesem Bereich zusätzliche Anforderungen. So führt die Beschränkung des Platzbedarfs des SoCs zu einer Begrenzung des zulässigen Speichers und die Forderung nach einem minimalen Energiebedarf erfordert eine aufwendige Optimierung der Software-Performance. Hinzu kommt, dass die Entwicklung der Software stark von der Hardware abhängt und so die Softwareentwicklung in vielen Fällen erst in einer späten Phase der Entwicklung starten kann.

Für die Entwicklung komplexer Software haben sich heute meist sogenannte „agile“ Entwicklungsprozesse durchgesetzt. Dabei wird die Software nicht zu Beginn vollständig geplant und erst anschließend realisiert. Vielmehr wird die Software in mehreren iterativen Schritten entwickelt und implementiert. Hierdurch können erste Softwarekonzepte in Verbindung mit der Hardware überprüft und bei Bedarf sehr flexibel angepasst werden.

Seit einigen Jahren geht der Trend in der Entwicklung von Software für Eingebettete Systeme in Richtung der Softwaregenerierung. Dadurch kann die aufwendige und fehlerbehaftete manuelle Programmierung der Software zumindest teilweise entfallen [14, pp. 38–44].

Die Hardwareentwicklungsmethoden erfuhren in den vergangenen Jahrzehnten mehrere evolutionäre Entwicklungsschritte. Heute werden komplexe Systeme in der Regel nach der „Spezifizieren, Explorieren und Verfeinern (SER)“-Entwicklungsmethode entwickelt. Dabei werden die Anforderungen an das System zu Beginn umfangreich spezifiziert und auf Grundlage des Spezifikationsdokumentes wird in natürlicher Sprache ein Modell auf System-Ebene erstellt. Hierdurch lässt sich bei möglichst vollständiger Modellierung der zu Beginn textuell beschriebenen Funktionen eine simulierbare Spezifikation erreichen. Die erreichte Simulierbarkeit der Spezifikation ermöglicht die Überprüfung und Validierung erster Systemkonzepte bereits in einer sehr frühen Phase der Entwicklung. Dabei lassen sich verschiedene Konzepte mit verschiedenen Systemeigenschaften als Modell erstellen und durch die Simulation vergleichen. Man spricht von einer Exploration. Darauf aufbauend können Entwurfsentscheidungen getroffen werden und so das Konzept bzw. der Entwurf iterativ verfeinert werden [14, pp. 55–57].

Da SoCs in der Regel heterogene Systeme darstellen, welche über einen oder mehrere Prozessoren und damit über Software verfügen, wird ein Hardware/Software-Co-Entwurf benötigt. Dabei werden Software und Hardware von weitestgehend getrennt voneinander arbeitenden Entwicklern/-innen entworfen. Zuvor muss eine Einteilung der funktionalen Module auf System-Ebene in die entsprechende Entwurfsdomäne erfolgen. Wie im vorangegangenen Abschnitt beschrieben, hängt die Softwareentwicklung dabei stark von der Hardware ab und kann meist erst zu einem späteren Zeitpunkt der Entwicklung starten. Für die parallele Entwicklung von Hardware und Software ist ein hohes Maß an Kommunikation zwischen Hardware- und Softwareentwicklern/-innen nötig. Eine gemeinsame Simulation ist in der Regel erst in einer späten Phase der Entwicklung möglich. Um die Software bereits vor der Produktion der Hardware gemeinsam mit dieser simulieren zu können, werden Prototypen noch vor der finalen Fertigstellung der Hardware genutzt. Dabei kann ein Prototyp der Hardware mittels FPGA oder die Hardware als Virtueller Prototyp implementiert werden. Auf Virtuelle Prototypen wird im nachfolgenden Abschnitt näher eingegangen. Ein wichtiger Aspekt des Hardware/Software-Co-Entwurfes und der Simulation mittels Prototypen ist die damit verbundene frühzeitige Validierung der Hardware-Software-Schnittstelle.

Hardware und Software, welche fertig entwickelt wurden, werden zum Zeitpunkt der Systemintegration zusammengeführt und können anschließend als Gesamtsystem getestet und verifiziert werden [14, p. 37].

Die Verifikation ist ein unverzichtbarer Bestandteil des Entwurfs von Hardware/Software-Systemen, wie den Automotive SoCs. Daher werden sowohl Verifikation wie auch Validation in jedem Teil des Industriestandards ISO 26262 gefordert und sind essenziell, um für ein Produkt bzw. einen Prozess das höchste Maß an funktionaler Sicherheit und Qualität sicherzustellen [18]. Die Verifikation soll darüber hinaus, vereinfacht ausgedrückt, die Korrektheit eines Systems beweisen. Die Bedeutung der Korrektheit lässt sich dem IEEE-Standard 610.12 [30] nach jedoch unterschiedlich auslegen:

Die Erfüllung der Kundenerwartungen, unabhängig von der Spezifikation, spielt bei der SoC-Entwicklung eher eine untergeordnete Rolle. SoCs werden oftmals kundenspezifisch entwickelt, und die Entwicklung des SoCs basiert dabei, wie in Abschnitt 3.​1.​1 beschrieben, auf einer vertraglichen Vereinbarung, welche dem Lasten- und Pflichtenheft zugrunde liegt. Somit wird ein Entwicklungsvorhaben vereinbart, in dem lediglich zugesichert wird, was in Lastenheft und Pflichtenheft spezifiziert wurde [2, p. 4].

Bei der Entwicklung eines SoCs gibt es eine Vielzahl unterschiedlicher Fehlerpotenziale und Fehlerarten über den gesamten Entwicklungs-Flow hinweg. Hierbei lassen sich im Kontext der Verifikation zwei Arten von Fehlern definieren:

Beispielsweise kann eine fehlende Eindeutigkeit bei den zu Beginn der Entwicklung spezifizierten Kundenanforderungen zu einer falschen Interpretation durch die Entwickler/-innen führen, welche darauf aufbauend Entwurfsentscheidungen treffen und Systemanforderungen in den Spezifikationsdokumenten schreiben. Somit wird das System im Sinne der Systemanforderungen falsch spezifiziert. Eine fehlende Eindeutigkeit der Systemanforderungen, welche sich z. B. aus der Beschreibung mittels natürlicher Sprache ergeben kann, führt dagegen dazu, dass die Entwickler/-innen gezwungen sind, zu interpretieren. Somit entsteht ein eigenes Bild des Systems in der Vorstellung der Entwickler/-innen, welches nicht mehr der Spezifikation entspricht und falsch interpretiert sein könnte. Implementieren die Entwickler/-innen basierend auf diesem eigenen Bild des Systems, entstehen Entwurfsfehler, da der Entwurf nicht der Spezifikation entspricht. Um das Risiko einer fehlerhaften Implementierung aufgrund von Interpretationen zu minimieren, ist es wichtig, dass ein nicht am Entwurf beteiligter Entwickler die Verifikation des Systems durchführt.

Eine nicht vollständige Spezifikation birgt besonders schwerwiegende Gefahren, da so Szenarien, welche in der Nutzung des Systems auftreten können, nicht spezifiziert und damit auch nicht verifiziert werden. Es besteht somit die Gefahr eines unvorhersehbaren Zustandes bzw. Verhaltens und damit im schlimmsten Fall einer Gefährdung von Menschenleben, wie am Beispiel der Fahrassistenzsysteme deutlich wird. Spezifikationsfehler müssen daher mittels umfangreicher Validierung der Spezifikation minimiert werden.

Die Verifikation weist nach, dass ein System bezogen auf seine Spezifikation korrekt entworfen wurde. Es kann somit der Nachweis erbracht werden, dass das System sowohl die funktionalen Teile als auch Teile der nichtfunktionalen Anforderungen der Spezifikation erfüllt. Befinden sich jedoch Fehler in der Spezifikation oder ist die Spezifikation nicht vollständig, gilt der Entwurf dennoch als korrekt im Sinne der Verifikation.

Neben der bereits erwähnten Problematik von Interpretationen beim Entwurf eines Systems aufgrund einer nicht eindeutigen Spezifizierung gilt dieselbe Problematik für die Verifikation. Ist die Spezifikation nicht eindeutig, sind die Verifikationsingenieure/-innen gezwungen, die Verifikation aufgrund von Interpretationen zu planen und zu entwickeln. So entsteht auch in diesem Fall ein eigenes Bild des Systems in der Vorstellung der Verifikationsingenieure/-innen [2, pp. 11–12]. Darüber hinaus besteht das Risiko, dass die Verifikationsingenieure/-innen sich die fehlenden Informationen der Spezifikation durch einen Blick in den Systementwurf einholen und so die Verifikation auf Basis des implementierten Entwurfs entsteht. Ein solches Vorgehen würde jedoch die Verifikation im Regelfall entkräften, da so der Entwurf nicht mehr gegen die Spezifikation, sondern gegen sich selbst geprüft wird und damit das Aufdecken von Fehlern im Entwurf mittels Verifikation unwahrscheinlich wird.