6. Evaluierung

Frage 1 befasst sich mit der Priorisierung der Defizite in Hinblick auf die negative Auswirkung des jeweiligen Defizites auf die Effizienz der SoC-Entwicklung. Dabei wurden aus dem Leitfaden fünf mögliche Antworten zur Verfügung gestellt, um deren Priorisierung die Interview-Teilnehmer/-innen von „höchste Zustimmung“ und damit „höchster negativer Einfluss“ nach „keine Zustimmung“ bzw. „kein negativer Einfluss“, wie in Abschnitt 6.1.1 und Abschnitt 6.1.2 beschrieben, gebeten wurden. Tabelle 6.2 zeigt die genaue Fragestellung, die zur Verfügung stehenden Antwortmöglichkeiten sowie die als Ergebnis der Befragung und anschließenden Analyse erhaltene gZR der Interviewevaluierung.

D1 (Implementierungsfehler) und D2 (Verifikationsfehler) fokussieren sich auf die direkten Auswirkungen einer defizitären Spezifikation, auf die Implementierung bzw. die Verifikation und damit auf die Auswirkung des Defizites auf die Effizienz aufgrund der benötigten Fehlerbehebung.

Bei der Interviewevaluierung wurden Implementierungsfehler aufgrund einer unzureichenden Spezifikation mit 23 % gZR und Verifikationsfehler aufgrund einer unzureichenden Spezifikation mit 20 % gZR am niedrigsten priorisiert. Die Befragten SE1, SE2, SM1 und SE3 gaben zusätzlich an, dass aus ihrer Sicht entstandene Fehler in der Implementierung durch die Verifikation im aktuell bestehenden Entwicklungs-Flow erkannt und behoben werden. Zudem wird bereits von Anfang an eine Behebung der Fehler in der Planung berücksichtigt.

D3 steht für den negativen Einfluss auf die Effizienz durch nachträgliche Änderungen an den vereinbarten Anforderungen zwischen Kunde und Entwickler. Solche nachträglichen Änderungen werden meist erst spät erkannt und deren Durchführung bindet in der Regel eine hohe Menge Ressourcen, führt zu einer Verschiebung des Zeitplans und kann laut SE1 und SE2 zu Folgefehlern führen. Die Folgefehler entstehen dabei aufgrund von nicht beachteten Einflüssen auf das umgebende System, welche durch die nachträglichen Änderungen hervorgerufen werden. Aufgrund der Häufigkeit, mit der das Defizit D3 in der SoC-Entwicklung auftritt, und die schwerwiegenden Auswirkungen auf die Effizienz wurde das Defizit D3 mit 80 % gZR am höchsten priorisiert.

Dem folgen D4 (Inkonsistenzen Spezifikation/Entwurf) mit 65 % gZR und D5 (Fehlkommunikation Entwickler-Kunde) mit 63 % gZR. Dabei wurde D4 von den Interview-Teilnehmern/-innen SA2, SM1 und SE3 am höchsten priorisiert. Die stellenweise hohe Priorisierung resultiert laut SE3 aus dem häufigen Auftreten des Defizits und der Gefahr, dass durch die Inkonsistenz Fehler im Entwurf durch die Verifikation nicht erkannt werden könnten.

D5 erhielt von fast allen Interview-Teilnehmern/-innen eine Priorisierung zwischen Priorisierungsstufe 1 und Priorisierungsstufe 3. Zudem wurde es besonders von den Systemarchitekten/-innen und dem Interview-Teilnehmer aus dem Managementbereich hoch priorisiert. Als Grund wurden dabei von MA1 auch hier die schwerwiegenden Folgen aus solchen Fehlkommunikationen für ein Entwicklungsprojekt genannt.

Tabelle 6.3 zeigt die Fragestellung, die Antwortmöglichkeiten sowie die gZR als Ergebnis der Befragung bezüglich möglicher Ursachen für D1.

Die Interview-Teilnehmer/-innen wurden gebeten, die in der Tabelle 6.3 dargestellten Antwortmöglichkeiten zu nennen, welche aus ihrer Sicht als Ursache für das Defizit D1 besteht. Da in der Regel mehrere Ursachen für die hier behandelten Defizite verantwortlich sind, wurden die Interview-Teilnehmer/-innen zudem gebeten, die Ursachen zu priorisieren. Nach der Befragung wurden die Antworten gemäß Abschnitt 6.1.2 gewichtet und die gZR berechnet.

Wie in der Tabelle 6.3 zu sehen, wurde die Unvollständigkeit der Spezifikation (U1) als Hauptursache für Implementierungsfehler mit einer gZR von 75 % priorisiert. So führt eine Unvollständigkeit der Spezifikation laut SA2 und SE1 dazu, dass die Modulentwickler/-innen die fehlenden Informationen durch Annahmen ergänzen und es in Folge dessen häufig zu Implementierungsfehlern kommen kann.

Die U3 (Mangelnde Verständlichkeit) mit 15 % gZR und U4 (fehlende Nachverfolgbarkeit) mit 35 % gZR wurden von allen Interview-Teilnehmern/-innen gering priorisiert. Als Grund hierfür nannten die Interview-Teilnehmer/-innen SE2 und SE3, dass sowohl die Verständlichkeit aus Sicht der Modulentwickler/-innen als auch die Nachverfolgbarkeit der Anforderungen bereits im aktuell angewendeten Entwicklungs-Flow gegeben sei.

Das gleiche Vorgehen wurde für die Frage nach den Ursachen für D2 gewählt. Den Interview-Teilnehmern/-innen wurden dieselben Antwortmöglichkeiten, wie in Tabelle 6.4 zu sehen, zur Verfügung gestellt. Erneut zeigt die Tabelle 6.4 die gZR als Ergebnis der Befragung.

Als Hauptursache mit 80 % gZR nannten die Interview-Teilnehmer/-innen eine unvollständige Spezifikation (U1). Eine unvollständige Spezifikation führt – wie bei der Implementierung – bei der Verifikation dazu, dass die Verifikationsingenieure/-innen zu Annahmen gezwungen sind, um die fehlenden Informationen zu ergänzen. Dieser Sachverhalt birgt bei der Verifikation zudem die Gefahr, dass Fehler in der Implementierung durch eine defizitäre Verifikation nicht oder sehr spät erkannt und erhebliche Aufwände für die Fehlerbehebung verursacht werden. Ähnlich verhält es sich bei einer nicht eindeutigen Spezifikation (U2). Diese Ursache erhielt eine gZR von 65 % und birgt ebenfalls durch die Gefahr von Fehlinterpretationen das Risiko, dass die Implementierung nicht korrekt verifiziert wird und somit Fehler nicht erkannt werden können.

Die mangelnde Verständlichkeit (U3) und die fehlende Nachverfolgbarkeit der Anforderungen (U4) wurden mit einer gZR von 38 % priorisiert. Auch hier wurden die bestehende Verständlichkeit sowie die bestehende Nachverfolgbarkeit der Anforderungen als Begründung für die Priorisierung genannt. Darüber hinaus wurde die U4 dreimal als höchst priorisierte und viermal als niedrig priorisierte Ursache genannt. In der weiteren Befragung zu den Gründen der Priorisierung wurden die unterschiedlichen Arbeitsweisen und Erfahrungen der Interview-Teilnehmer/-innen deutlich. Zum einen wurde die Ursache U4 hoch priorisiert, da eine fehlende Nachverfolgbarkeit der Anforderungen aktuell zu erheblichen Problemen bei der Verifikation führt. So betonten alle Interview-Teilnehmer/-innen die Wichtigkeit der Nachverfolgbarkeit der Anforderungen. Darüber hinaus besteht laut SE4 aktuell keine Zeit, um diese in den Projekten umzusetzen. Demgegenüber gaben die Befragten SE2 und SE3 an, dass die Nachverfolgbarkeit der Anforderungen in aktuellen Projekten bereits in hohem Maße gegeben sei und priorisierten daher U4 niedrig ein.

Vergleichbar fiel die Priorisierung der Ursachen für nachträgliche Änderungen (D3) aus, wie Tabelle 6.5 zeigt.

Auch hier wurde die Unvollständigkeit der Spezifikation (U1) mit 83 % gZR als Hauptursache für nachträgliche Änderungen genannt, da besonders eine fehlende Vollständigkeit in Pflichtenheft und Systemkonzept laut SE1, SE3 und SA1 zu einer fehlenden Realisierung von Funktionalitäten im SoC führen kann.

Vergleichbar verhält es sich bei der fehlenden Eindeutigkeit der Spezifikation (U2), da dies zu Fehlinterpretationen und damit gegebenenfalls sogar zu einer Realisierung falscher Funktionen führen könnte, welche so nicht vom Kunden gefordert wurden. U2 wurde mit einer gZR von 75 % priorisiert.

Die mangelnde Verständlichkeit der Spezifikation (U3) wurde mit 53 % als Ursache für nachträgliche Änderungen priorisiert. Dabei birgt die mangelnde Verständlichkeit laut SM1 besonders die Gefahr, dass der Kunde das Pflichtenheft bei der Planungsphase nicht korrekt versteht und somit ein fehlerbehaftetes Verständnis des Entwicklungsvorhabens erhält.

Das Ergebnis der Befragung über die Ursachen für Inkonsistenzen Spezifikation/Entwurf sowie die Fragestellung und Antwortmöglichkeiten sind in Tabelle 6.6 dargestellt.

Bei der Frage nach den Ursachen für Inkonsistenzen zwischen den Spezifikationsdokumenten sowie zwischen Spezifikation und Entwurf (D4) wurde die fehlende Vollständigkeit (U1) als zweithöchste priorisierte Ursache mit 70 % gZR genannt. Die fehlende Eindeutigkeit der Spezifikation (U2) ist laut den Befragten mit 78 % gZR Hauptursache für Inkonsistenzen. Dabei wurde vermehrt von Situationen berichtet, bei denen in der Entwurfsphase der SoC auf Grundlage des Entwurfes weiterentwickelt wurde und nicht auf Grundlage der Spezifikation. Darüber hinaus wurden die so getroffenen Entwurfsentscheidungen nicht oder nur unzureichend in der Spezifikation nachgepflegt.

Die mangelnde Verständlichkeit der Spezifikation (U3) wurde mit einer gZR von 18 % niedrig priorisiert. Die mangelnde Verständlichkeit ist aus Sicht der Interview-Teilnehmer/-innen und damit aus Sicht der Entwickler/-innen eher selten der Fall im aktuell angewendeten Entwicklungs-Flow. Die fehlende Nachverfolgbarkeit der Anforderungen (U4) wurde mit 35 % gZR priorisiert. Der manuelle Übertrag erhielt somit die dritthöchste Priorisierung mit 50 % gZR.

Bei der Befragung zu den möglichen Ursachen für die Fehlkommunikation zwischen Kunde und Entwickler wurden den Interview-Teilnehmern/-innen lediglich die Antwortmöglichkeiten Ursache U1–U4 zur Verfügung gestellt, da die U5 (manueller Übertrag) nicht als mögliche Ursache für die Fehlkommunikation mit dem Kunden infrage kommt (Tabelle 6.7).

Zusammenfassend lassen sich als Hauptursachen für die hier betrachteten Defizite besonders die Unvollständigkeit und die fehlende Eindeutigkeit der Spezifikation herausstellen, da diese durchweg eine vergleichsweise hohe Priorisierung erhielten.

Nach der Analyse zu möglichen Ursachen für die Defizite in der SoC-Entwicklung folgte die Befragung der Interview-Teilnehmer/-innen zu möglichen Lösungsansätzen, um die Defizite D1 bis D5 zu minimieren bzw. die Ursachen für die Defizite anzugehen. Wie bei den Fragen zuvor, standen auch hier den Interview-Teilnehmern/-innen unterschiedliche Antwortmöglichkeiten als Teil des Leitfadens zur Verfügung. Dabei wurden die Interview-Teilnehmer/-innen erneut gebeten, die Lösungsansätze zu priorisieren. Hierbei bestanden einzelne der Antwortmöglichkeiten aus Teilaspekten der in dieser Arbeit entwickelten Gesamtmethode. So sind beispielsweise die Lösungsansätze „Modellbasierte Spezifikation“ und „Formalisierung Spezifikation“ Teil der hier vorliegenden Arbeit und wurden in Abschnitt 4.​1 und Abschnitt 5.​1 näher behandelt. Ebenso beinhaltet die Arbeit den „modellgetriebenen Entwurf“, eine „starke Nachverfolgbarkeit der Anforderungen“ und die „Arbeitsweise nach dem Top-down-Ansatz“. Die „Ausführbarkeit der Spezifikation“ ist jedoch in dieser Arbeit nur teilweise erfüllt und könnte daher in einer weiterführenden Arbeit Umsetzung finden.

Die Antworten wurden nach der Interviewevaluierung, wie zuvor in Abschnitt 6.1.2 beschrieben, quantifiziert und ein Mittelwert über alle Antworten der Interview-Teilnehmer/-innen gebildet. Tabelle 6.8 beinhaltet die Fragestellung sowie Antwortmöglichkeiten und das Ergebnis für die Frage 3.1. Die Fragestellung bleibt hierbei für alle Defizite gleich, die Antwortmöglichkeiten variieren jedoch.

Die höchste Priorisierung als möglichen Lösungsansatz für „Implementierungsfehler aufgrund einer unzureichenden Spezifikation“ wurde die modellbasierte Spezifikation mit 78 % gZR, dicht gefolgt von der formalisierten Spezifikation mit 75 % gZR genannt. Eine hohe gZR mit 63 % erhielt zudem der modellgetriebene Entwurf als Lösungsansatz. Die ausführbare Spezifikation mit 28 % und besonders die stärkere Nachverfolgbarkeit wurden bezogen auf das Vorbeugen von Implementierungsfehlern niedrig priorisiert.

Bei Frage 3.2 zu möglichen Lösungsansätzen und deren Wirkung für das Defizit D2 (Verifikationsfehler aufgrund unzureichender Spezifikation) blieben die Antwortmöglichkeiten weitestgehend gleich. Lediglich der modellgetriebene Entwurf wurde durch die modellgetriebene Verifikation, welche ebenfalls Teil dieser Arbeit ist, ersetzt. Tabelle 6.9 zeigt die Fragestellung sowie die Antwortmöglichkeiten und das Ergebnis der Befragung zu Frage 3.2.

Als möglicher Lösungsansatz für die Reduzierung von Verifikationsfehlern aufgrund einer unzureichenden Spezifikation wurde die Formalisierung der Spezifikation von den Interview-Teilnehmern/-innen mit 75 % gZR höchst priorisiert. Die Modellierung der Spezifikation mit 53 % gZR wurde als zweithöchste Priorisierung benannt. Die ausführbare Spezifikation (39 % gZR), die modellgetriebene Verifikation (44 % gZR) und die stärkere Nachverfolgbarkeit (39 % gZR) lagen nah beieinander und erhielten mit etwa 40 % ebenfalls eine verhältnismäßig hohe gZR.

Für die Befragung nach möglichen Lösungsansätzen, um nachträglichen Änderungen vorzubeugen, wurden die Antwortmöglichkeiten erneut entsprechend angepasst, wie in Tabelle 6.10 zu sehen. Die Tabelle 6.10 zeigt zudem die Fragestellung sowie das Ergebnis der Befragung in Form der gZR.

Bei der Frage, welche der hier gezeigten Lösungsansätze das Auftreten von nachträglichen Änderungen in der SoC-Entwicklung zu reduzieren vermag, wurde mit hoher Übereinstimmung der Top-down-Ansatz mit 85 % gZR höchst priorisiert. Durch die ausführliche Analyse der Kundenanforderungen und Anwendungsfälle sowie die lösungslosgelöste Dekomposition der benötigten Funktionen sinkt die Wahrscheinlichkeit, geforderte Funktionen zu vernachlässigen bzw. nicht geforderte Funktionen dennoch zu realisieren. Darüber hinaus steigt die Vollständigkeit der Spezifikation durch den Top-down-Ansatz in der Regel an.

Die modellbasierte Spezifikation mit 65 % gZR und die formalisierte Spezifikation mit 60 % gZR wurden ebenfalls als mögliche Lösungen hoch priorisiert. So sind sich die Interview-Teilnehmer/-innen einig, dass die Modellierung und Formalisierung der Spezifikation zu einer Steigerung der Spezifikationsqualität führt und somit nachträgliche Änderungen verhindert werden können. Die ausführbare Spezifikation (25 % gZR) und die stärkere Nachverfolgbarkeit der Anforderungen (20 % gZR) wurden verhältnismäßig niedrig priorisiert.

Das Ergebnis der Befragung zu möglichen Lösungsansätzen für die Reduzierung von Inkonsistenzen Spezifikation/Entwurf, die dabei verwendete Fragestellung sowie die Antwortmöglichkeiten sind nachfolgend in Tabelle 6.11 abgebildet.

Tabelle 6.12 zeigt zum Schluss des Abschnittes die Fragestellung, mögliche Lösungsansätze sowie das Ergebnis der Befragung in Form der gZR. Befragt wurden die Interview-Teilnehmer/-innen zu möglichen Lösungsansätzen für die Reduzierung von Fehlkommunikationen zwischen Kunde und Entwickler sowie zwischen den Entwicklern/-innen.

Wie zuvor kam auch bei dieser Frage eine nur knapp unterschiedliche Priorisierung zustande. Höchst priorisiert wurde die Formalisierung der Spezifikation mit 70 % gZR. Mit nur 2 % Unterschied folgte in diesem Fall die ausführbare Spezifikation mit 68 % gZR. Die modellbasierte Spezifikation erhielt eine gZR von 65 % und die stärkere Nachverfolgbarkeit der Anforderungen eine gZR von 48 %.

Dies ist die höchste Priorisierung der ausführbaren Spezifikation über das gesamte Evaluierungssinterview betrachtet. So sehen die Interview-Teilnehmer/-innen besonders bei der Kommunikation mit dem Kunden große Vorteile in der Ausführbarkeit der Spezifikation, um so die Verständlichkeit der Spezifikation neben der Formalisierung und Modellierung weiter zu erhöhen.

Bei der, im vorangegangenen Abschnitt beschriebenen Evaluierung möglicher Ursachen der nachfolgend näher betrachteten Defizite erhielten besonders die Lösungsansätze Modellierung und Formalisierung der Spezifikation sowie Top-down-Ansatz eine durchweg hohe Priorisierung. Somit konnte der Nutzen der in dieser Arbeit vorgestellten modellbasierten Entwicklungsmethode auf die Reduzierung der Defizite und damit die Steigerung der Effizienz in der SoC-Entwicklung aus Sicht der Interview-Teilnehmer/-innen evaluiert und bestätigt werden.

Für die Kommunikation mit dem Kunden und um dabei Missverständnisse auszuschließen, sollte jedoch die Ausführbarkeit großer Teile der Spezifikation zusätzlich ermöglicht werden.

Zum Ende der Interviewevaluierung wurden die Teilnehmer/-innen gebeten, den Einfluss der neuen modellbasierten Methode auf die Aufwände in den nachfolgenden Bereichen im Vergleich zur aktuellen Arbeitsweise zu bewerten:

Tabelle 6.13 zeigt das Ergebnis der Befragung über den Einfluss der modellbasierten Entwicklung auf den Aufwand bei der Spezifikation. Dabei gaben alle Interview-Teilnehmer/-innen im ersten Schritt als Tendenz eine Erhöhung des Aufwandes an.

Die Tabelle 6.13 zeigt die Einstimmigkeit bezüglich der Tendenz aller Interview-Teilnehmer/-innen, dass sich der Aufwand im Bereich der Spezifikation durch Anwendung der neuen Methode auf die SoC-Entwicklung erhöhen wird. Dabei gaben die Interview-Teilnehmer/-innen SA1, MA1, VI1 und SE2 als Grund für diese Erhöhung eine vollständigere Spezifikation an. Das heißt, der Mehraufwand resultiert teilweise aus der Schließung der Lücken in der Spezifikation und ist daher für die Schaffung einer vollständigen Spezifikation in jedem Fall nötig.

Tabelle 6.14 zeigt das Ergebnis der Befragung über den Einfluss der modellbasierten Entwicklungsmethode auf den Aufwand beim Entwurf des SoCs verglichen mit der aktuell angewendeten Arbeitsweise. Hierbei gaben alle Interview-Teilnehmer/-innen als Tendenz eine Verringerung des Aufwandes an.

Als Nächstes wurden die Interview-Teilnehmer/-innen zum Einfluss der Methode auf den Aufwand in der Verifikation befragt. Das Ergebnis der Befragung ist in Tabelle 6.15 als Diagramm dargestellt.

Bei dem Einfluss der modellbasierten Entwicklungsmethode dieser Arbeit auf den Aufwand bei der Verifikation gingen die Antworten bereits in Bezug auf die Tendenzen auseinander. So antworteten sieben Interview-Teilnehmer/-innen, dass aufgrund der erhöhten Eindeutigkeit, Vollständigkeit und Verständlichkeit der Spezifikation die Arbeit der Verifikationsingenieure/-innen erleichtert würde und somit der Aufwand zwischen leicht (40 % ZR) und mittel (30 % ZR) sinke. Eine Reduzierung des Aufwandes bei der Verifikation von 30 % würde, bezogen auf das zu Beginn dieses Abschnittes genannten Mittelwerts eines SoCs, eine Reduktion von 5 Mio. auf circa 3,5 Mio. Euro bedeuten.

Tabelle 6.16 zeigt zum Ende des Abschnittes das Ergebnis der Interviewevaluierung – bezogen auf den Einfluss der modellbasierten Entwicklungsmethode – hinsichtlich des Aufwands über den gesamten SoC-Entwicklungs-Flow gesehen, da hierbei auch der Einfluss auf den Aufwand durch Nacharbeiten, Fehlkommunikation und Behebung von Fehlern betrachtet wird, welcher erst zu einem späteren Zeitpunkt der Entwicklung auftritt. Alle zehn Interview-Teilnehmer/-innen gaben als Tendenz eine Reduzierung des Aufwandes an.

Darüber hinaus fiel das Ergebnis der Befragungen sehr eindeutig aus. So stimmten 80 % der Interview-Teilnehmer/-innen einer mittel bis starken Verringerung des Aufwandes über den gesamten SoC-Entwicklungs-Flow hinweg betrachtet zu. Weitere 20 % ZR erhielt der Skalenwert „stark verringert“. Sollte sich dieses Ergebnis auch auf Dauer in der SoC-Entwicklung erreichen lassen, könnte sich durch die in dieser Arbeit vorgestellte modellbasierte Entwicklungsmethode eine Reduzierung des Aufwandes von circa 40 % einstellen. Dies entspräche, bezogen auf die zu Beginn des Abschnittes angegebenen Mittelwerte für die SoC-Entwicklung, einer Reduktion der Kosten von 20 Mio. Euro auf etwa 12 Mio. Euro sowie eine Reduktion der Entwicklungsdauer von vier auf zweieinhalb Jahre. Vergleicht man diesen reduzierten Wert der Kosten für die gesamte SoC-Entwicklung aus der Beispielrechnung mit der Summe der reduzierten Werte der Bereiche Spezifikation, Entwurf und Verifikation, fällt auf, dass die Summe der Einzelwerte mit 12,5 Mio. bereits den Wert der gesamten Kosten übersteigt. Darüber hinaus ist zu beachten, dass in den zu Beginn des Abschnitts angenommenen Kosten für die gesamte SoC-Entwicklung (20 Mio. Euro) bereits die „Sonstigen Kosten“ (7 Mio. Euro) stellvertretend für die Bereiche Projektplanung, Fehlerhebung und Maskendruck enthalten sind.

Wird der Einfluss der modellbasierten Entwicklungsmethode auf die gesamten Kosten der SoC-Entwicklung betrachtet, resultiert die starke Senkung der Kosten, so MA1, neben der Reduktion der Kosten bei Entwurf und Verifikation besonders aus der Reduzierung der Kosten bei der Fehlerbehebung und aus der Vermeidung von Rekursionen bei der Maskenherstellung des Wafers. Muss diese Maskenerstellung aufgrund von Fehlern oder nachträglichen Anpassungen wiederholt werden, entsteht laut MA1 eine Verzögerung von etwa einem Jahr und etwa 1 Mio. Euro an Mehrkosten pro Rekursion.

Dabei bleibt jedoch in diesem Abschnitt die Zunahme der Komplexität der zukünftig zu entwickelnden SoCs, welche der Reduktion des Aufwandes entgegenwirken würde, unbeachtet. Dennoch sehen, so das Ergebnis der Interviewevaluierung, alle Interview-Teilnehmer/-innen die Reduzierung des Aufwandes, bezogen auf die gesamte SoC-Entwicklung, durch Anwendung der modellbasierten Entwicklungsmethode als erfüllt an. Somit kann das in Kapitel 1 beschriebene übergeordnete Ziel der Effizienzsteigerung als erfüllt angesehen werden.

Als Ergebnis der in dieser Arbeit durchgeführten und in den vorangegangenen Abschnitten beschriebenen Tests lässt sich die Abwesenheit von Fehlern sowie die Abwesenheit von funktionellen Unterschieden zwischen generiertem und manuell implementiertem Code belegen. Dies gilt sowohl für die generierten Anteile der Software als auch für die in SystemC generierten kontrollflussorientierten Module des Virtuellen Prototyps. Zudem wurde ein korrektes Verhalten im Fehlerfall nachgewiesen. Jedoch geben die Tests keine Informationen über die Unterschiede in der Performance zwischen generiertem und manuell implementiertem Code.