ISO 26262 von der Item-Definition bis zur Tool-Qualifizierung.

Was wir abdecken

Das vollständige V-Modell auf der Sicherheitsseite, von der Konzeptphase bis zur Bestätigung. Wir sind Praktiker, nicht nur Auditoren: Die Arbeitsprodukte, die wir erstellen, sind genau die, die Ihr TÜV- / SGS- / Kunden-Assessor liest.

Konzeptphase (ISO 26262-3)

• Item-DefinitionGrenzen, Funktion, Umgebung, abhängige Items, Katalog des Fehlverhaltens.
• HARA (Gefahren- und Risikoanalyse)Betriebssituationen, Exposure / Severity / Controllability, ASIL-Bestimmung, Sicherheitsziele.
• Funktionales Sicherheitskonzept (FSC)Sicherheitsanforderungen, sichere Zustände, fehlertolerante Zeitintervalle, Allokation auf Elemente.
• ASIL-Dekompositionwo sie legitim ist und wo sie missbraucht wird. (Siehe unsere Insights zum Thema.)

System & Hardware (ISO 26262-4, -5)

• Technisches Sicherheitskonzept (TSC)Sicherheitsmechanismen, Ziele für Diagnoseabdeckung, Latent-Fault-Metriken.
• FMEDAquantitative Analyse von Single-Point- und Latent-Faults, Validierung der Diagnoseabdeckung.
• DFA (Dependent Failure Analysis)kaskadierende und Common-Cause-Ausfälle über redundante Elemente.
• FTAfür Vollständigkeitsargumente von Sicherheitsmechanismen und Hazard-Tracing bei hohem ASIL.
• HSI (Hardware-Software-Schnittstelle)das Dokument, das die Lücke zwischen zwei Teams schließt, die einander nicht ausstehen können.

Software (ISO 26262-6)

• Software-Sicherheitsanforderungen + Architektur, MISRA-C-/-C++-Konformität, modellbasierte Entwicklung mit TargetLink / Embedded Coder.
• SWE.4- / SWE.5- / SWE.6-Verifikation, Unit, Integration, Qualifizierung, mit formaler Verifikation und automatischem Back-to-Back-Testing, dSPACE TargetLink, Vector CANoe, Matlab / Simulink Test.
• Back-to-Back-Testing Modell ↔ Code, Modell-Coverage, Code-Coverage, strukturelle Coverage-Ziele je ASIL.

Formale & semi-formale Verifikation (ISO 26262-6 §9)

• Wo Architektur und Eigenschaften es zulassen, beweisen wir sicherheitskritische Eigenschaften formalstatt nur die Anwesenheit von Fehlern zu testen (Dijkstra). Formaler Eigenschaftsbeweis und Model Checking auf Software-Unit- und Architekturebene.
• Semi-formale Verifikation von SW-Unit- und Systemarchitektur-Designs sowie Definition des SFV-Entwicklungsprozesses, die von ISO 26262 bei ASIL-D dringend empfohlene Methode, umgesetzt in laufenden ASIL-D-EV-Plattformprogrammen.
• Aufgebaut auf formaler Verifikation, die unser Gründer mit in die Industrie gebracht hat, heute in laufenden Programmen angewandt, nicht nur als Folie.

Sehen Sie, wie eine Eigenschaft bewiesen wird →

Unterstützende Prozesse (ISO 26262-8)

• Tool-QualifizierungTCL-Klassifizierung, Qualifizierungsnachweise je Tool. Wir haben das für kommerzielle Formal-Methods-Tools, dSPACE, Vector und interne Tools gemacht.
• Confirmation Reviewsunabhängige Reviews gemäß der Confirmation-Matrix in Tabelle 1.
• Safety Casedie GSN-artige Argumentation, die jedes Arbeitsprodukt in eine einzige verteidigbare Struktur zusammenführt.

SOTIF (ISO 21448) für ADAS / AEB

Safety of the Intended Functionality, Leistungsgrenzen, Sensor-Edge-Cases, ODD-Definition. Wir integrieren SOTIF-Analysen in die ISO-26262-HARA, statt sie als Parallelstrang zu fahren.