Empfohlenes Webinar: KI-gestütztes API-Testing: Ein No-Code-Ansatz zum Testen | Zum Video

ISO 26262 Software-Compliance in der Automobilindustrie

Übersicht

Ausblick für die Automobilindustrie

Der Automobilindustrie Die Branche entwickelt sich weiterhin rasant und dringt in technische Bereiche vor, in denen andere Branchen schon seit vielen Jahren tätig sind. Das Jet Propulsion Laboratory der NASA veröffentlicht beispielsweise Codekorrekturen und neue Funktionen, die derzeit für ein Millionen von Kilometern entferntes Raumschiff entwickelt werden, das sich auf dem Weg zu seinem Ziel befindet. In ähnlicher Weise stellt die Automobilindustrie Software-Updates für Autos bereit, die bereits verkauft wurden und von Kunden auf der ganzen Welt gefahren werden.

Auch die Zukunft selbstfahrender Autos sieht vielversprechend aus und könnte in den nächsten Jahrzehnten weit verbreitet sein. Mehrere Unternehmen, darunter Waymo, Tesla, Uber und traditionelle Autohersteller wie GM und Ford, sind Vorreiter bei der Entwicklung selbstfahrender Technologie. Viele führen umfangreiche Tests durch und einige haben Pilotprogramme in ausgewählten Städten gestartet. Mit zunehmender Weiterentwicklung der Technologie wird erwartet, dass sie den Verkehr revolutionieren und ihn sicherer, effizienter und zugänglicher machen wird.

Herausforderungen im Bereich Sicherheit

Diese Art der Entwicklung – insbesondere bei fortschrittlichen Fahrerassistenzsystemen (ADAS) – bringt neue Herausforderungen in Bezug auf Sicherheit und Schutz mit sich. Normen wie ISO 26262 befassen sich mit der funktionalen Sicherheit bei der Entwicklung elektrischer und elektronischer Systeme (E/E), zu denen Antrieb, dynamische Steuerungssysteme und Fahrerassistenz gehören.

Darüber hinaus bieten Plattformen wie AUTOSAR eine offene standardisierte Software-Schichtarchitektur, die die Sicherheit weiter verbessert. Sie enthalten Richtlinien für die Verwendung der Sprache C++14 bei der Entwicklung kritischer und sicherheitsrelevanter Systeme. Die Hersteller haben jedoch erkannt, dass aufgrund der zunehmenden Komplexität und Unbekanntheit der Zusammenarbeit moderner Technologien sowie der Änderungen in der internen und externen Umgebung Sicherheitsbedenken aufgekommen sind, die diese Standards nicht berücksichtigen.

Wenn Sie sich mit ISO 21343 befassen, ist es wichtig zu verstehen, dass die empfohlenen Sicherheitsüberlegungen zur Cybersicherheit in Ihre vorhandenen Entwicklungsprozesse integriert werden sollten. ISO 21434 verweist auf ISO 26262, um einen interdisziplinären Austausch von Strategien, Koordination und sogar verwendeten Tools zwischen diesen beiden Disziplinen zu ermöglichen. Das bedeutet, dass Ihre Organisation Ihre Systemingenieure in der Phase der Anforderungsanalyse für Sicherheit und Schutz mit Ihren Sicherheitsingenieuren zusammenarbeiten lassen sollte.

Führen Sie parallel dazu eine Gefahrenanalyse und Risikobewertung (HARA) für die Sicherheit sowie eine Bedrohungsanalyse und Risikobewertung (TARA) für die Sicherheit durch. Dennoch ist eine starke kollaborative Umgebung erforderlich, um ein sicheres Ergebnis zu gewährleisten.

V-Prozessmodell für Software-Sicherheit und -Schutz. Zeigt, dass Sicherheit und Schutz Teil des gesamten Prozesses sind.
V-Prozessmodell für Software-Sicherheit.

Die Gewährleistung der Sicherheit bei der Softwareimplementierung beginnt mit Anwenden einer statischen CodeanalyseDer MISRA-Codierungsstandard enthält Sicherheitsrichtlinien, aber Sie können die Codesicherheit auch erweitern und stärken, indem Sie Einführung von CERT.

Führen Sie auf der rechten Seite des V weiter Unit-Tests aller Ihrer Sicherheitsanforderungen auf niedriger Ebene durch. Erstellen Sie in der nächsten Phase Testfälle, die zusätzliche Funktionen integrieren. Diese Testfälle stellen sicher, dass Ihre Anforderungen auf hoher Ebene erfüllt werden.

Erstellen Sie Systemtests, um sicherzustellen, dass die Systemanforderungen überprüft werden. Stellen Sie sicher, dass alle Testfälle auf Ihre Anforderungen zurückgeführt werden können. Dies garantiert, dass keine Anforderung ungetestet bleibt. Um jedoch sicherzustellen, dass jede Anforderung vollständig getestet wird, integrieren Sie eine strukturelle Codeabdeckung, wie in ISO 21434 und ISO 26262 empfohlen. Die Codeabdeckung stellt nicht nur sicher, dass jede Codezeile getestet wurde, sondern auch, dass Ihre Sicherheitstestfälle durch ihre Maßnahmen zur Behebung der Sicherheitsfunktionalität jeden möglichen Ausführungspfad vollständig abdecken.

Um Sicherheitsprobleme zu überwinden, können Teams auf Lösungen wie Parasoft C/C++test zurückgreifen, das vom TÜV SÜD für den Einsatz in sicherheitskritischen Anwendungen gemäß ISO 26262 und durch die Vereinigung für ISO 21434 zertifiziert wurde. Beide Standards empfehlen die Durchführung einer statischen Analyse, einer dynamischen Analyse – die Unit-, Integrations- und Systemtests umfasst –, einer Codeabdeckung und einer Anforderungsnachverfolgung. Parasoft bietet genau das, was ISO 26262 und ISO 21434 für die Softwareüberprüfung in Bezug auf Sicherheit empfehlen, und stellt auch die erforderliche Dokumentation zum Nachweis der Einhaltung beider Standards bereit.

UNECE WP.29 Regulatorische Anforderungen

Die Wirtschaftskommission der Vereinten Nationen für Europa (UNECE) hat am 23. Juni 2020 regulatorische Anforderungen veröffentlicht, in denen sie neue Prozesse und Technologien skizziert, die Automobilhersteller sowohl in ihre Organisation als auch in ihre Fahrzeuge integrieren müssen. Diese Vorschriften gelten auch für Tier-1- und Tier-2-Lieferanten von Software- und Hardwarekomponenten, einschließlich mobiler Dienste.

Fahrzeughersteller müssen in ihre Organisationsstruktur ein risikobasiertes Management-Framework zur Erkennung, Analyse und Abwehr relevanter Bedrohungen, Schwachstellen und Cyberangriffe integrieren.

Für die folgenden Kategorien sind Cybersicherheitstests und das Bestehen von Inspektionen erforderlich.

  • Kategorie M umfasst Standardfahrzeuge mit vier Rädern.
  • Kategorie N ist für Pickups und Transporter.
  • Die Kategorien L6 und L7 umfassen Elektroautos und autonome Fähigkeiten.

Wenn der Hersteller die organisatorischen und fahrzeugbezogenen Schlüsselanforderungen von WP.29 erfüllt, erhält er eine Konformitätsbescheinigung. Neue Fahrzeuge ohne diese Bescheinigung dürfen in der EU ab Juli 2024 nicht mehr verkauft werden. Beachten Sie, dass die USA nicht teilnehmen und keine eigenen ähnlichen Regelungen haben. Die Zeichen stehen jedoch an der Wand.

Auto-Gewürz

Automotive Software Process Improvement and Capability Determination (ASPICE) bietet einen Messrahmen für unabhängige Gutachter, um die Fähigkeiten einer Organisation zur Softwareentwicklung zu bewerten. Die Gewährleistung der Softwaresicherheit und Cybersicherheit liegt nicht nur in den technischen Aspekten der Entwicklung des elektronischen Systems, sondern erfordert auch die Integration von Prozessen und Kontrollen durch die Organisation.

Diese Prozesse und Kontrollen müssen Möglichkeiten zur Verfolgung und Überwachung des Fortschritts in allen Abläufen der Organisation umfassen, um Folgendes sicherzustellen:

  1. Es wurden Sicherheits- und Cybersicherheitspraktiken übernommen.
  2. Die Anforderungen an Sicherheit und Cybersecurity werden erfüllt.

Dies ist auch eines der beiden wichtigsten Zertifizierungskriterien für UNECE WP.29 zur organisatorischen Cybersicherheitsfähigkeit.

Unsichere Szenarien

Es wurden weitere Auswüchse von ISO 26262 umgesetzt, wie etwa ISO/PAS 21448, das allgemein als SOTIF (Safety of the Intended Functionality, Sicherheit der beabsichtigten Funktionalität) bezeichnet wird. SOTIF hilft Ihnen, den Missbrauch der beabsichtigten Funktionalität zu analysieren und zu verhindern, wenn er zu einem unsicheren Szenario führt. Beispielsweise schaltet sich Ihr Fahrzeug während der Fahrt aufgrund eines eingeleiteten Softwareupdates unbeabsichtigt ab.

Sicherheitslücken stellen ebenfalls gefährliche Szenarien dar. Ein Angreifer könnte die Wi-Fi-Verbindung des Autos nutzen, um einen exponierten Port aus der Ferne auszunutzen. Er könnte sich auf irgendeine Weise vom fortschrittlichen Infotainmentsystem im Fahrzeug (IVI) aus vorarbeiten und die Kontrolle über sicherheitskritische Komponenten wie Bremsen oder Lenkung übernehmen oder diese beeinflussen, da diese die gleiche Kommunikationsinfrastruktur nutzen.

Die Rolle von Standards

Standards wie SAE J3061, ersetzt durch ISO/SAE 21434, schreiben vor, dass zunächst eine Bedrohungsanalyse und Risikobewertung (TARA) durchgeführt werden muss, um potenzielle Bedrohungen in Bezug auf Betrieb, Datenschutz und andere Faktoren zu bewerten, die einen Verkehrsteilnehmer/Fahrer betreffen können. Wenn das Risiko einer Bedrohung ausreichend hoch ist, ist ein Cybersicherheitsprozess erforderlich. Es gibt verschiedene Ansätze zum Aufdecken von Sicherheitslücken und Anforderungen, die die Risiken mindern. Erfahren Sie mehr über TARA und warum Ihr Entwicklungsteam TARA braucht.

Standards wie UL 4600 gibt es mittlerweile speziell für den Betrieb vollautonomer Fahrzeuge. Das bedeutet, dass es keine menschliche Aufsicht gibt und das autonome Fahrzeug die volle Verantwortung übernimmt. Dieser Standard konzentriert sich auf die Erstellung eines Sicherheitsnachweises für den Einsatz von Fahrzeugen der SAE-Stufe 4/5, nicht darauf, wie die Sicherheit autonomer Fahrzeuge auf öffentlichen Straßen getestet werden kann. Dafür wäre ein anderer Standard erforderlich.

Diese und andere Normen spielen eine entscheidende Rolle für die Sicherheit der Automobilindustrie. Die OEMs tragen die Haftungskosten für die Auslieferung unsicherer Fahrzeuge an die Massen. Um diese Risiken zu mindern, müssen die OEMs diese Normen übernehmen und einhalten. Allerdings sollten die OEMs von ihren Zulieferern die gleiche Qualität und Einhaltung verlangen. Eine Schwäche in einer Komponente kann die Sicherheit des gesamten Systems gefährden.

Erstellen benutzerdefinierter Codierungsstandards

In Zusammenarbeit mit einigen seiner Automobilhersteller hat Parasoft benutzerdefinierte Codierungsstandards entwickelt, die MISRA, AUTOSAR C++14, CERT, CWE und andere benutzerdefinierte Regeln enthalten, die von ihren Lieferanten verwendet werden können. Dadurch wird sichergestellt, dass in der gesamten Lieferkette die gleiche Qualität der Software vorhanden ist.

Parasoft C/C++test ist eine einheitliche Testlösung die Unit-Tests und strukturelle Code-Abdeckung als Teil ihrer Funktionalität umfasst. Diese Lösung für die C/C++-Softwareentwicklung unterstützt eine umfassende Reihe von Hardwarezielen und Entwicklungsökosystemen, die Lieferanten und OEMs mit unterschiedlichen Entwicklungsinfrastrukturen nutzen können. C/C++test wurde vom TÜV SÜD für den Einsatz auf sicherheitskritischen Systemen zertifiziert. Für ADAS und sichere vernetzte Autos bietet C/C++test nahtlose Integrationen mit SOAtest und dem Virtualisieren Kombinieren Sie API-Tests mit Laufzeitanwendungsabdeckung und simulierten virtuellen Testumgebungen.

Was ist ISO 26262?

ISO 26262 ist ein funktionaler Sicherheitsstandard, der den gesamten Produktentwicklungsprozess im Automobilbereich abdeckt. Er umfasst Aktivitäten wie Anforderungsspezifikation, Design, Implementierung, Integration, Verifizierung, Validierung und Konfiguration.

Die Norm bietet Leitlinien für Aktivitäten im gesamten Automobil-Sicherheitslebenszyklus, indem sie die folgenden Anforderungen festlegt:

  • Funktionales Sicherheitsmanagement für Automobilanwendungen
  • Die Konzeptphase für Automotive-Anwendungen
  • Produktentwicklung auf Systemebene für Softwarearchitekturdesign für Automobilanwendungen
  • Produktentwicklung auf Hardwareebene für Software-Unit-Tests für Automobilanwendungen
  • Produktentwicklung auf Softwareebene für Automotive-Anwendungen
  • Produktion, Betrieb, Service und Außerbetriebnahme
  • Unterstützende Prozesse: Schnittstellen innerhalb verteilter Entwicklungen, Anforderungen an das Sicherheitsmanagement, Änderungs- und Konfigurationsmanagement, Verifizierung, Dokumentation, Einsatz von Softwaretools, Qualifizierung von Softwarekomponenten, Qualifizierung von Hardwarekomponenten und Proven-in-Use-Argumentation
  • Automotive Safety Integrity Level (ASIL) orientierte und sicherheitsorientierte Analysen

ISO 26262 ist eine Anpassung von IEC 61508 für die Automobilindustrie. IEC 61508 ist ein grundlegender funktionaler Industriesicherheitsstandard für elektrische, elektronische und programmierbare elektronische Geräte und gilt für alle Arten von Branchen. Andere Sektoren wie Medizin IEC 62304 und dem Bahn EN 50128 wurden ebenfalls aus der IEC 61508 abgeleitet.

Da ISO 26262 aus IEC 61508 für die Automobilindustrie abgeleitet und erweitert wurde, handelt es sich um einen funktionalen Sicherheitsstandard, der Leitlinien für die Regelung des gesamten Produktlebenszyklus auf Software- und Hardwareebene von der Konzeptentwicklung bis zur Außerbetriebnahme bereitstellt. Er umfasst elektrische und elektronische Automobilsysteme und deren Entwicklungsprozess, einschließlich Anforderungsspezifikation, Design, Implementierung, Integration, Verifizierung, Validierung und Konfiguration.

Die neueste Version, ISO 26262:2018, ist in 12 Teile unterteilt. Der Standard wurde seit seiner ersten Ausgabe im Jahr 2011 weiterentwickelt.

Was sind die Teile von ISO 26262?

Grafik mit einer Übersicht über ISO 26262. Jeder Teil wird weiter unten ausführlicher beschrieben.
Übersicht über ISO 26262
Teil 1Vokabularabschnitt für den Standard. Begriffe, Definitionen und Abkürzungen finden Sie hier. 
Teil 2Management der funktionalen Sicherheit, das einen internen funktionalen Sicherheitsprozess für das Team oder Unternehmen definiert. Dazu gehört eine Sicherheitsorganisation, die die Planungs-, Koordinierungs- und Dokumentationsaktivitäten im Zusammenhang mit der funktionalen Sicherheit überwacht.
Teil 3Die Konzeptphase, in der die Anforderungen der Stakeholder berücksichtigt werden und die bestimmt, was Sie entwickeln und letztendlich liefern werden. Beachten Sie in der Abbildung „Übersicht über ISO 26262“ auf der rechten Seite des Konzeptphasenfelds den Anfang eines grau schattierten V-Wasserzeichens. Die schattierten Vs stellen die Verbindung zwischen den Teilen 3, 4, 5, 6 und 7 des Standards dar. Diese Teilereihen basieren auf dem V-Modell des Softwareentwicklungslebenszyklus. Auf der linken Seite sind die verschiedenen Entwicklungsphasen und auf der rechten die Verifizierungs- und Validierungs- oder Testphasen dargestellt. Wenn Sie System- oder Softwareentwickler in der Embedded-Branche sind, ist Ihnen das V-Modell wohlbekannt.  
Teil 4Beginn der Produktentwicklung auf Systemebene, die die Teile 5 und 6 umfasst, diese jedoch von einem hohen Abstraktionsniveau aus betrachtet. Die Architektur wird definiert, einschließlich funktionaler Testfälle, die die Architektur verifizieren und validieren. Um tiefer in das Detaildesign und die Implementierung einzutauchen, werden Teil 5 und Teil 6 definiert.
Teil 5Teil 5 befasst sich mit der Entwicklung von Hardware, die außerhalb des Geltungsbereichs dieses Dokuments liegt.
Teil 6Zielt auf Softwareentwicklung ab. Sie können ein kleineres, hellgraues V-Wasserzeichen für Softwareentwicklung sehen, und die linke Seite des V umfasst wiederum die Phasen der Anforderungszerlegung, des Entwurfs und der Implementierung, jetzt jedoch auf einer viel niedrigeren Granularitätsebene. Auf der rechten Seite des V stellen die Abschnitte 6.9, 6.10 und 6.11 das Testen oder die Verifizierung und Validierung der Software dar. Dazu gehören Unit-Tests, statische Analysen, strukturelle Codeabdeckung, Anforderungsrückverfolgbarkeit und mehr.

Es enthält außerdem Anforderungen an die Softwareentwicklung von Automobilanwendungen. Dazu gehören Verpflichtungen zur Einleitung der Produktentwicklung, zur Spezifikation von Softwaresicherheitsanforderungen, zum Entwurf der Softwarearchitektur sowie zur Entwicklung und Implementierung von Softwareeinheiten. Für die Verifizierung und Validierung der Softwarekomponente werden Ihnen basierend auf dem zugewiesenen Sicherheitsintegritätslevel (ASIL) mehrere Methoden empfohlen oder vorgeschrieben.
Teil 7Befasst sich mit der Produktion und dem Betrieb des Produkts, sobald es im Einsatz ist. Das bedeutet, dass Sie Dinge wie Wartung und Außerbetriebnahme oder Einstellung Ihres Produkts berücksichtigen müssen.
Teil 8Gibt die verschiedenen unterstützenden Prozesse und Lösungen an, die bei der Entwicklung des Systems erforderlich sind, um die funktionale Sicherheit zu gewährleisten. Dazu gehört die Bereitstellung einer Konfigurationsmanagementlösung, eines Änderungsmanagements, eines Dokumentationsmanagements und anderer Lösungen.

Ein weiterer wichtiger Aspekt von Teil 8 ist die Qualifikation der verwendeten Softwaretools. Sie möchten kein Open-Source-Tool oder ein nicht zertifiziertes Tool eines Anbieters verwenden, das die Sicherheit Ihres Produkts durch die Einführung von Problemen untergräbt. Verwenden Sie ein Tool, das vom Technischen Überwachungsverein (TÜV) zertifiziert wurde und eine nachgewiesene Nutzungsgeschichte oder Argumentation hat. 
Teil 9Dieser Abschnitt ist sehr wichtig, da er sich auf die Risikoklassifizierung des zu entwickelnden Systems bezieht. Das bedeutet, dass Sie das Risiko für Passagiere oder Fußgänger berücksichtigen müssen, wenn das zu entwickelnde elektrische oder elektronische System eine Fehlfunktion aufweist oder ausfällt. 
Teil 10Ein Überblick über die Norm ISO 26262 mit zusätzlichen Erklärungen, die das Verständnis und die Konzepte der anderen Teile der Norm verbessern und daher informativ sind.
Teil 11Anpassung der Richtlinien zur funktionalen Sicherheit an Halbleiter für die Automobilindustrie. Es bietet Halbleiterherstellern Anleitung und Informationen zur Entwicklung von ISO 26262-konformem IP. Es hilft bei der Integration der funktionalen Sicherheit, da Benutzer von Halbleitern möglicherweise nicht wissen, wie sie die Halbleiter sicher verwenden. Dies ist darauf zurückzuführen, dass Automobilsysteme sehr komplex geworden sind und Halbleiter die meisten der jüngsten Innovationen ermöglicht haben. Dazu gehören visionsbasierte Technologie, verbesserte Grafikprozessoren (GPUs), Anwendungsprozessoren, Sensoren, DRAM und andere Komponenten, die fortschrittliche Fahrerassistenzsysteme oder ADAS ermöglichen.
Teil 12Anpassung der Norm für Motorräder, die in Abbildung 2-1 und diesem E-Book bewusst weggelassen wurde.

Durchführen von Gefahrenanalysen und Risikobewertungen

In ISO 26262 muss eine Gefahrenanalyse und Risikobewertung (HARA) für das zu entwickelnde System durchgeführt werden. Nach Abschluss der HARA wird der Softwarekomponente ein ASIL zugewiesen, wobei die Stufen A bis D angegeben werden. Stufe A stellt die niedrigste Gefahrenstufe dar und Stufe D die höchste Gefahrenstufe. Das bedeutet, dass der Ausfall eines Systems mit ASIL D-Zuweisung katastrophale Folgen haben könnte.

Es gibt auch eine Zuordnung der Qualitätsmanagementebene (QM), was bedeutet, dass keine Sicherheitsanforderungen bestehen. ASIL wird zugewiesen, indem die Schwere der Verletzung mit der Wahrscheinlichkeit des Versagens und der Kontrollierbarkeit multipliziert wird. In der folgenden Tabelle sind die einzelnen Ebenen für Schwere, Gefährdung und Kontrollierbarkeit aufgeführt.

Tabelle mit Schweregrad, Belastung und Steuerbarkeit im Kraftfahrzeugbereich (ASIL).
Gefahrenanalyse und Risikobewertung
Schweregrad = Welche Auswirkungen oder Schäden hätte der Fehler?

Exposition = Die Häufigkeit oder Wahrscheinlichkeit, mit der der Fehler auftritt.

Kontrollierbarkeit – Das Ausmaß, in dem wir sicherstellen können, dass das Ereignis nicht eintritt.

Es stehen mehrere kostenlos verfügbare Tabellen zur Verfügung, die bei der Ermittlung des ASIL-Werts hilfreich sind. Die folgende Tabelle ist ein Beispiel für eine Tabelle, die viel einfacher zu lesen ist und die ASIL-Stufen in Farben basierend auf Schweregrad, Belastung und Kontrollierbarkeit anzeigt.

Vereinfachte ASIL-Bewertungstabelle
Vereinfachte ASIL-Bewertungstabelle

Aktive und passive Sicherheit

Straßenfahrzeuge sind mit zahlreichen Sicherheitssystemen ausgestattet. Einige davon gelten als aktive Sicherheit, andere als passive Sicherheit.

Unter aktiver Sicherheit versteht man Technologien, die dabei helfen, einen Zusammenstoß oder Unfall zu verhindern. Dazu gehören Traktionskontrolle, Antiblockiersystem, Vision ADAS und mehr.

Passive Sicherheitssysteme dienen der Sicherheit der Passagiere. Im Falle eines Unfalls gibt es beispielsweise Airbags und Sicherheitsgurte. Der elektronische Scheibenwischer und das Kombiinstrument sind ebenfalls passive Sicherheitssysteme.

Aktive und passive Automobilkomponenten und ihre ASIL-Stufen.
Aktive und passive Sicherheit

Durchführen von Testüberprüfungen und Validierungen des Entwurfs und der Implementierung von Softwareeinheiten

Da der Schwerpunkt dieses Handbuchs auf Software liegt, ist es wichtig, die Testverifizierungs- und Validierungsmethoden vom Standard empfohlen. Tabelle 7 erfasst beispielsweise die Verifizierungsmethoden 1a bis 1k, die während des Gerätedesigns und der Implementierung angewendet werden sollen. Methode 1h, „Statische Codeanalyse“, wird für die ASIL-Stufen A bis D dringend empfohlen.

Die Spalten in Tabelle 7 rechts zeigen die ASIL-Stufen A bis D. Ein einzelnes „+“-Symbol bedeutet, dass die Norm dies empfiehlt, ein doppeltes „++“ bedeutet, dass dies dringend empfohlen wird, und ein „o“ bedeutet, dass dies nicht empfohlen wird.

ISO 26262 Teil 6, 9.4.2:2018 - Methoden zur Software-Unit-Verifizierung
ISO 26262 Teil 6, 9.4.2:2018
Andere wichtige Verifizierungsmethoden werden durch dynamische Analysen für anforderungsbasierte Tests und Fehlereinfügungen durchgeführt. Tabelle 26262 von ISO 8 enthält beispielsweise eine „Analyse von Grenzwerten“. Dies ist eine Methode zum Ableiten eines Testfalls, um Fehler zu beseitigen, indem Eingaben in die Einheit nachgewiesen werden, die nicht nur die Mindest-, Mittel- und Höchstwerte sind, sondern die Grenzen außerhalb des Bereichs, um zu sehen, ob die Einheit robust genug ist, um diese Ausreißerfälle zu bewältigen.

ISO 26262 Teil 6, 9.4.3:2018 - Methoden zur Ableitung von Testfällen
ISO 26262 Teil 6, 9.4.3:2018
Und Tabelle 9 listet die empfohlenen strukturellen Code-Abdeckungsmetriken auf, um die Test-Abdeckung sicherzustellen und toten Code sowie versteckte Defekte zu beseitigen.

ISO 26262 Teil 6, 9.4.4:2018 - Strukturelle Abdeckungsmetriken
ISO 26262 Teil 6, 9.4.4:2018
Dunkelblaues Banner mit dem Bild eines Mannes, der in einem Serverraum mit einer Frau spricht, die ein Tablet in der Hand hält.
Bild eines Mannes und einer Frau mit einem Tablet in der Hand, die in einem Serverraum diskutieren.

Verbessern Sie Ihre Softwaretests mit Parasoft-Lösungen.