Zunächst einmal: Warum ist dieser Prozess wichtig?
In meinen Schulungen und Assessments werde ich oft gefragt: „Wir machen viele Anforderungstests – lohnt sich der zusätzliche Aufwand für Integrationstests wirklich?“
Um diese Frage zu beantworten, müssen wir zunächst klären, was ein Integrationstest eigentlich ist.
Integrationstests werden durchgeführt, um die Einhaltung der Systemarchitektur zu überprüfen. Dazu gehört auch die Überprüfung der Schnittstellen und des dynamischen Verhaltens gemäß SYS.4, dem System-Architekturentwurf-Prozess.
Besser wäre zu fragen: „Kann durch Anforderungstests die Konformität mit der Systemarchitektur nachgewiesen werden?“
Die Antwort darauf lautet: Natürlich nicht, denn diese Tests beziehen sich auf die Anforderungen und nicht auf die Architektur.
So weit, so gut. Aber was nutzt das Testen der Architektur denn dann? Die Funktionalität ist gut, reicht das nicht?
Lassen Sie uns einen genaueren Blick darauf werfen: Kann eine Nichtkonformität mit der Architektur im Rahmen der Anforderungstests festgestellt werden?
Ja, das ist möglich, aber es gibt keine Garantie dafür.
Sie können unzählige Anforderungstests durchführen, und selbst dann gibt es keine Garantie.
Die Kosten wären enorm, aber das System könnte trotzdem Fehler aufweisen, die durch einfache Tests der Architektur hätten vermieden werden können.
Und das ist der springende Punkt: Integrationstests führen zu einem robusteren System, wobei die Kosten gegenüber detaillierten Anforderungstests geringer sind.
Im Folgenden sind die wichtigsten Aspekte der Systemintegration und Integrationstests in Automotive SPICE® aufgeführt.
Strategie für die Integration und Integrationstests definieren.
Eine Strategie ist eine leicht verständliche Anleitung. Strategien sind vor allem für größere, verteilte Projekte wichtig, damit alle Beteiligten wissen, was sie zu tun haben. Diese Strategie beschreibt zunächst die Beispielphasen, in denen Systemkomponenten mit neuen Versionen verfügbar werden. In diesen Fällen müssen Integrationstests durchgeführt oder wiederholt werden. Ein weiterer Aspekt, der in der Strategie beschrieben werden muss, ist die Abfolge der elektromechanischen Schritte, die das System verwendet, um die Aufgabe zu erfüllen.
Hier ein Beispiel: Angenommen wir haben eine Treibersoftware, die einen digitalen Wert an einen Digital-Analog-Wandler überträgt, der ein analoges Signal an einen Motor ausgibt, der wiederum ein mechanisches Teil in Bewegung setzt. Die logische Testreihenfolge liegt auf der Hand – die Tests sollten in genau dieser Reihenfolge durchgeführt werden. Welchen Sinn hätte es, die Beschleunigung des mechanischen Teils zu messen, ohne vorher sicherzustellen, dass die vorhergehenden Schritte richtig funktionieren?
Zusätzlich verlangt Automotive SPICE eine „Regressionsteststrategie“. Mit einem Regressionstest stellen Sie sicher, dass, wenn Sie etwas im System ändern, alles, was nicht geändert wurde, immer noch richtig funktioniert. Für das genannte Beispiel würde das also bedeuten, dass Sie, wenn Sie die Treibersoftware ändern, in der Regel alle folgenden Integrationstests erneut durchführen. Wenn Sie jedoch den mechanischen Teil ändern, müssen Sie die Schnittstelle zwischen der Treibersoftware und dem Digital-Analog-Wandler nicht erneut testen.
Bidirektionale Traceability und Konsistenz mit der Systemarchitektur gewährleisten. Traceability bedeutet, dass für jedes relevante Architekturelement, z. B. eine Schnittstelle, der entsprechende Test lokalisiert werden kann. Funktioniert das auch in die umgekehrte Richtung, dann ist die Traceability bidirektional.
Was bedeutet nun Konsistenz? In dem Beispiel mit der Schnittstelle würde die Konsistenz das Folgende voraussetzen:
- Die Schnittstelle ist mit dem richtigen Test verknüpft (und nicht mit dem Test von etwas anderem).
- Dieser Test ist dazu geeignet, die Schnittstelle vollständig zu testen.
Ist das nicht der Fall, müssen zusätzliche Tests verknüpft werden. Konsistenz bedeutet auch, dass die Tests die Schnittstelle tatsächlich richtig testen. Das Ziel lautet also mit anderen Worten: fehlerhafte Tests unbedingt vermeiden.
Testergebnisse zusammenfassen und kommunizieren. Diese Art von Bericht wird normalerweise als Testergebnisbericht bezeichnet. Dieser Testergebnisbericht ist an die Personen weiterzuleiten, die diese Informationen benötigen, etwa das Entwicklungsteam, der Projektmanager, der Qualitätsingenieur usw.
Werfen wir einen genaueren Blick darauf, wie dieser Bericht aussehen soll. Wie der Name schon sagt, sollte er die Ergebnisse zusammenfassen und unnötige Details ausblenden. Was soll der Testergebnisbericht hauptsächlich vermitteln? Er sollte natürlich die Einhaltung der Systemarchitektur aufzeigen.
Hier ein Gegenbeispiel, das man oft bei Assessments sieht:
Der Bericht enthält Tortendiagramme mit den 139 Tests, die hätten durchgeführt werden sollen, von denen 11 nicht durchgeführt werden konnten und 10 fehlgeschlagen sind – und sonst nichts. Es wird weder angegeben, warum die 11 Tests nicht durchgeführt werden konnten, noch welche Risiken damit verbunden sind
bzw. warum die 10 fehlgeschlagenen Tests ein großes Problem darstellen.
Auch die Einhaltung der Systemarchitektur wird in dem Bericht nicht belegt.
Um genau zu sein, wird die Systemarchitektur mit keinem Wort erwähnt.
Das Tortendiagramm sollte sich auf die 85 Architekturelemente beziehen, nicht nur auf die 139 Tests. Das führt natürlich zu Schwachstellen im Assessment.
Systemintegration und Integrationstest – der Prozess nach Automotive SPICE®
Bei der Systemintegration und den Integrationstests geht es darum, die Systemelemente so zu integrieren, dass ein integriertes System entsteht, das dem System-Architekturentwurf entspricht. Außerdem soll sichergestellt werden, dass die Systemelemente getestet werden, um nachzuweisen, dass die integrierten Systemelemente mit dem System-Architekturentwurf übereinstimmen, einschließlich der Schnittstellen zwischen den Systemelementen.
Best Practice (BP) 1: Entwickeln Sie eine Strategie für die Integration der Systemelemente in Übereinstimmung mit dem Projekt- und Freigabeplan. Ermitteln Sie die Systemelemente auf Grundlage der Systemarchitektur und legen Sie eine Reihenfolge für ihre Integration fest.
BP2: Entwickeln Sie eine Strategie zum Testen der integrierten Systemelemente in Übereinstimmung mit der Integrationsstrategie. Dazu gehört auch eine Regressionsteststrategie für das erneute Testen integrierter Systemelemente, wenn ein Systemelement geändert wird.
BP3: Entwickeln Sie die Testspezifikation für den Systemintegrationstest, einschließlich der Testfälle für jeden Integrationsschritt eines Systemelements gemäß der Teststrategie zur Systemintegration.Die Testspezifikation muss auch dazu geeignet sein, die Übereinstimmung der integrierten Systemelemente mit dem System-Architekturentwurf nachzuweisen.
- ANMERKUNG 1: Die Schnittstellenbeschreibungen zwischen den Systemelementen sind ein Input für die Testfälle zur Systemintegration.
- ANMERKUNG 2: Die Einhaltung des Architekturentwurfs bedeutet, dass die spezifizierten Integrationstests dazu geeignet sind, nachzuweisen, dass die Schnittstellen zwischen den Systemelementen die durch den System-Architekturentwurf vorgegebene Spezifikation erfüllen.
- ANMERKUNG 3: Die Testfälle für die Systemintegration können sich auf den richtigen Signalfluss zwischen den Systemelementen, die Rechtzeitigkeit und die zeitlichen Abhängigkeiten des Signalflusses zwischen den Systemelementen, die richtige Interpretation der Signale durch alle Systemelemente unter Verwendung einer Schnittstelle und die dynamische Interaktion zwischen den Systemelementen konzentrieren.
- ANMERKUNG 4: Der Systemintegrationstest kann durch Simulation der Umgebung unterstützt werden (z. B. Hardware-in-the-Loop-Simulation, Bordnetz-Simulation, Digital Mock-up).
BP4: Integrieren Sie die Systemelemente zu einem integrierten System gemäß der Systemintegrationsstrategie.
- ANMERKUNG 5: Die Systemintegration kann schrittweise erfolgen, indem die Systemelemente (z. B.Hardwareelemente wie Prototyp-Hardware, Peripheriegeräte (Sensoren und Aktoren), Mechanik und integrierte Software integriert werden, um ein System zu schaffen, das der Systemarchitektur entspricht.
BP5: Wählen Sie Testfälle aus der Testspezifikation für die Systemintegration aus.Die Auswahl der Testfälle muss eine ausreichende Abdeckung gemäß der Teststrategie für die Systemintegration und dem Freigabeplan gewährleisten.
BP6: Führen Sie den Systemintegrationstest anhand der ausgewählten Testfälle durch. Halten Sie die Ergebnisse der Integrationstests und die Protokolle fest.
- Anmerkung 6: Siehe SUP.9 zur Vorgehensweise bei Nichtkonformität.
BP7: Stellen Sie eine bidirektionale Traceability zwischen den Elementen des System-Architekturentwurfs und den in der Testspezifikation für die Systemintegration enthaltenen Testfällen her.Stellen Sie eine bidirektionale Traceability zwischen den in der Testspezifikation für die Systemintegration enthaltenen Testfällen und den Ergebnissen der Systemintegrationstests her.
- ANMERKUNG 7: Die bidirektionale Traceability unterstützt Abdeckungs-, Konsistenz- und Auswirkungsanalysen.
BP8: Stellen Sie die Konsistenz zwischen den Elementen des System-Architekturentwurfs und den in der Testspezifikation für die Systemintegration enthaltenen Testfällen sicher.
- ANMERKUNG 8: Die Konsistenz wird durch eine bidirektionale Traceability unterstützt und kann durch Reviewprotokolle nachgewiesen werden.
BP9: Fassen Sie die Ergebnisse der Systemintegrationstests zusammen und teilen Sie sie allen Beteiligten mit.
- ANMERKUNG 9: Durch die Bereitstellung aller notwendigen Informationen aus der Testfalldurchführung in einem Ergebnisbericht können andere Parteien die Auswirkungen beurteilen.
Welchen Nutzen bietet die Systemintegration und Integrationstests?
Das System wird schrittweise integriert und getestet, um Fehler in den Interaktionen zwischen den Systemelementen zu finden, bevor der Systemtest (SYS.5) durchgeführt wird. Alle Schnittstellen und das dynamische Verhalten werden getestet.
Was beinhalten die Systemintegration und Integrationstests?
Zuerst werden eine Integrationsstrategie und eine Integrationstest-Strategie sowie eine Regressionstest-Strategie festgelegt. Die Strategie stimmt mit der Systemarchitektur und dem Produktfreigabeplan (BP1, BP2) überein.
Testspezifikationen für die Integration werden erstellt und ihre Traceability und Konsistenz mit der Systemarchitektur wird hergestellt (BP3, BP7, BP8).
Die Systemelemente werden entsprechend der Strategie integriert (BP4), Systemintegrationstests und Regressionstests werden durchgeführt (BP5, BP6) und die Ergebnisse werden zusammengefasst und berichtet (BP9).
Beispiel für testbare Schnittstellen
Erfahrungen, Probleme und Tipps:
Unter Systemintegration versteht man die Integration der Systemkomponenten in ein Gesamtsystem, nicht die Integration in das Fahrzeug. Der Ablauf der Systemintegration ist oft unstrukturiert, ohne eine festgelegte Vorgehensweise oder Reihenfolge.
Auch ist oft unklar, was genau Systemintegrationstests sind. Jede relevante Schnittstelle (intern und extern) und jedes dynamische Verhalten muss getestet werden – zum Beispiel Hardware-Software-Integration, Speichertests, Tests der Schnittstellenkomponenten mit der Software, interne und externe Kommunikation, oder Flash-Tests unter verschiedenen Bedingungen.
Das dynamische Systemverhalten wird bei Integrationstests oft nicht berücksichtigt.
Besonders bei sicherheitsbezogenen Systemen müssen die Reaktionszeiten getestet werden.
Der Systemintegrationstest wird manchmal in gemeinsamen Testläufen mit dem Systemtest durchgeführt. Das ist kein Problem, solange alle relevanten Schnittstellen und dynamische Verhalten getestet werden können.
Der Leiter der Elektrokonstruktion ist häufig an der Systemintegration beteiligt, wenn er neue Leiterplattenmuster erhält und nachweisen muss, dass die Leiterplatte reibungslos mit der Software funktioniert.
Das ist ein guter Ausgangspunkt, um eine Strategie und ein Verfahren für Systemintegration und -tests zu entwickeln.
Systemintegrationstests müssen bestätigen, dass die folgenden Elemente der Systemarchitektur mit ausreichender Abdeckung getestet werden: Hardware-Software-Schnittstellen und dynamisches Verhalten. Außerdem muss der Ressourcenverbrauch anhand der in SYS.3 definierten Ziele gemessen werden.
Bei der Bewertung des dynamischen Verhaltens auf Systemebene ist es wichtig zu berücksichtigen, wie das System auf die wichtigsten Fahrzeugbetriebszustände wie Zündung ein/aus, verzögertes Ausschalten, Anfahren usw. reagiert.
Erfahren Sie mehr über Automotive SPICE
Nehmen Sie an einer unserer Automotive SPICE® Schulungen teil!
Über den Autor
Thomas Liedtke ist von Haus aus Informatiker. Nach seiner Promotion an der Universität Stuttgart ging er in die Telekommunikationsbranche. Bei Alcatel-Lucent leitete er 14 Jahre lang erfolgreich zahlreiche Projekte und mehrere Abteilungen. Inzwischen ist er seit mehr als zehn Jahren in der Beratung tätig und teilt seine Erfahrungen mit Kunden in verschiedenen Branchen, vor allem in den Bereichen Sicherheit, Cybersicherheit, Datenschutz und Projektmanagement.
Er hat in mehreren Gremien mitgewirkt, insbesondere in der Arbeitsgruppe für automobile Cybersicherheit bei German Electrical und in der VDA-Arbeitsgruppe Cybersicherheit (DIN-Norm NA052-00-32-11AK und ISO-Norm TC22/SC32/WG11).
Um Zugang zu weiteren spannenden Inhalten dieser Website zu erhalten, füllen Sie bitte das nachstehende Formular aus:
Bitte warten…