ISO 26262 & ASIL.
Sicherheit, nachweisbar.
AIASIL (Automotive Safety Integrity Level) ist die Risikoklassifizierung der ISO 26262 für sicherheitsrelevante Fahrzeugfunktionen. Es gibt vier ASIL-Level: ASIL A (niedrigstes Risiko), ASIL B, ASIL C und ASIL D (höchstes — z. B. Bremse, Lenkung, Airbag), ergänzt um QM für Funktionen ohne Sicherheitsrelevanz; die Einstufung ergibt sich aus Schwere, Eintrittswahrscheinlichkeit und Beherrschbarkeit einer Gefährdung. Die ISO 26262 selbst ist der internationale Standard für funktionale Sicherheit elektrischer/elektronischer Systeme im Straßenfahrzeug. Die von ihr geforderten Nachweise — Testabdeckung, Traceability, Audit-Reports — lassen sich in der CI/CD-Pipeline automatisieren.
Ist die ISO 26262 bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Welche ASIL-Level gibt es?
Die ISO 26262 kennt vier ASIL-Level — ASIL A, ASIL B, ASIL C und ASIL D — sowie die Einstufung QM für Funktionen ohne Sicherheitsrelevanz. ASIL A ist die niedrigste, ASIL D die höchste Stufe. Mit jedem Level steigen die verbindlich geforderte Testtiefe, die Methodik und der Umfang der Nachweisführung.
Was bedeutet ASIL D — und was verlangt es von der Toolchain?
ASIL D ist die höchste der vier Sicherheitsstufen der ISO 26262 und gilt für Funktionen, deren Ausfall lebensbedrohliche Folgen hat und vom Fahrer kaum abgefangen werden kann — Bremse, Lenkung, Airbag. Sie verlangt die höchste Methoden- und Nachweistiefe: MC/DC-Überdeckung im Unit-Test, Mechanismen zur Fehlererkennung, in der Regel Redundanz auf Architekturebene, hinreichend unabhängige Reviews und eine lückenlose Traceability von der Sicherheitsanforderung bis zum Testergebnis. Für die Hardware kommen quantitative Zielwerte hinzu — mindestens 99 % Single-Point-Fault-Metrik und weniger als 10 FIT für zufällige Hardwareausfälle. Der Unterschied zu ASIL C ist damit weniger eine andere Systematik als eine deutlich engere Toleranz.
Für die Toolchain heißt das dreierlei: ein Coverage-Werkzeug, das MC/DC wirklich misst und nicht nur Zeilen zählt; eine Trace-Matrix, die aus Anforderungs-IDs in Commits und Tests entsteht statt aus einer Tabelle, die jemand nachpflegt; und Werkzeuge, deren Vertrauensstufe (Tool Confidence Level, TCL) nach ISO 26262-8 klassifiziert ist — der Compiler meist mit Qualifizierung, der Pipeline-Orchestrierer oft ohne, sofern nachgelagerte Gates seine Fehler aufdecken würden. Wie das in der Pipeline aussieht, zeigt der Pipeline-Aufbau weiter unten.
| Kennzahl | ASIL A | ASIL B | ASIL C | ASIL D |
|---|---|---|---|---|
| Single-Point-Fault-Metrik (SPFM) | kein Zielwert | ≥ 90 % | ≥ 97 % | ≥ 99 % |
| Latent-Fault-Metrik (LFM) | kein Zielwert | ≥ 60 % | ≥ 80 % | ≥ 90 % |
| Zufällige Hardware-Ausfälle (PMHF) | kein Zielwert | < 100 FIT | < 100 FIT | < 10 FIT |
| Zweigüberdeckung (Branch Coverage) | empfohlen | dringend empf. | dringend empf. | dringend empf. |
| MC/DC-Überdeckung | empfohlen | empfohlen | empfohlen | dringend empf. |
Quelle: ISO 26262-5, Tabellen 4 und 6 (Hardware-Architekturmetriken, Zielwerte für zufällige Hardwareausfälle) sowie ISO 26262-6, Tabelle 12 (strukturelle Überdeckung auf Unit-Ebene). „Dringend empfohlen“ (++) und „empfohlen“ (+) sind die Abstufungen, mit denen die Norm Methoden gewichtet — wer von einer empfohlenen Methode abweicht, muss die Abweichung begründen, nicht nur dokumentieren. FIT steht für Failures in Time, also Ausfälle je 109 Betriebsstunden.
Was bedeutet ASIL für die Entwicklung?
ASIL-gerechte Entwicklung heißt, dass die ISO 26262 mit jeder Stufe von ASIL A bis ASIL D mehr Methodentiefe im selben Entwicklungsprozess verlangt. Höher eingestufte Funktionen brauchen strengere strukturelle Testabdeckung, von der Anweisungsüberdeckung bei ASIL A bis zur MC/DC-Überdeckung bei ASIL D, dazu unabhängigere Reviews, Mechanismen zur Fehlererkennung und eine lückenlose Traceability von der Anforderung bis zum Testergebnis. Die grundsätzliche Systematik bleibt über alle ASIL-Stufen gleich; strenger werden die Nachweistiefe und das geforderte Coverage-Maß.
In der Praxis entscheidet damit nicht die ASIL-Stufe allein über den Aufwand, sondern die Frage, ob die geforderten Nachweise von Hand entstehen oder bei jedem Build. Genau hier setzt die Automatisierung an: Coverage-Ziele, statische Analyse nach MISRA C und die Traceability-Matrix als Quality Gate erzeugen den Nachweis fortlaufend, statt ihn vor dem Assessment zusammenzutragen. Aus einer ASIL-Einstufung wird so eine Menge prüfbarer Artefakte statt einer Zusicherung auf Papier.
Wie funktioniert die ASIL-Einstufung?
Die ASIL-Einstufung entsteht in der Gefährdungsanalyse und Risikobewertung (HARA, Hazard Analysis and Risk Assessment) aus drei Parametern: Schwere der möglichen Verletzung (S), Eintrittswahrscheinlichkeit der Fahrsituation (E) und Beherrschbarkeit durch den Fahrer (C). Die Kombination der drei Werte ergibt nach der Zuordnungstabelle in ISO 26262-3 die Stufe — von QM bis ASIL D.
Wie schwer sind die möglichen Verletzungen? S0 = keine Verletzungen, S3 = lebensbedrohliche bis tödliche Verletzungen.
Wie häufig tritt die Fahrsituation auf, in der die Fehlfunktion gefährlich wird? E1 = sehr selten, E4 = hohe Wahrscheinlichkeit im Normalbetrieb.
Kann ein durchschnittlicher Fahrer die Situation noch abfangen? C1 = einfach beherrschbar, C3 = schwer oder gar nicht beherrschbar.
ASIL-Tabelle: die Einstufung von S, E und C zum ASIL-Level
Die ASIL-Tabelle nach ISO 26262-3 ordnet jeder Kombination aus Schwere, Exposition und Beherrschbarkeit genau ein Ergebnis zu. ASIL D entsteht ausschließlich aus der schärfsten Kombination S3 / E4 / C3 — alle übrigen Felder liegen darunter.
| Schwere | Exposition | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | QM |
| S1 | E2 | QM | QM | QM |
| S1 | E3 | QM | QM | ASIL A |
| S1 | E4 | QM | ASIL A | ASIL B |
| S2 | E1 | QM | QM | QM |
| S2 | E2 | QM | QM | ASIL A |
| S2 | E3 | QM | ASIL A | ASIL B |
| S2 | E4 | ASIL A | ASIL B | ASIL C |
| S3 | E1 | QM | QM | ASIL A |
| S3 | E2 | QM | ASIL A | ASIL B |
| S3 | E3 | ASIL A | ASIL B | ASIL C |
| S3 | E4 | ASIL B | ASIL C | ASIL D |
Beispiel elektrische Servolenkung: Fällt die Lenkunterstützung bei Autobahngeschwindigkeit schlagartig aus, drohen lebensbedrohliche Unfälle (S3), die Fahrsituation ist alltäglich (E4), und ein durchschnittlicher Fahrer kann den plötzlichen Kraftsprung kaum kompensieren (C3) — Ergebnis: ASIL D. Eine fehlerhafte elektrische Sitzverstellung im Stand landet dagegen bei QM: Sie verletzt niemanden, der Fahrer kann jederzeit loslassen.
Wichtig für die Architektur: Über ASIL-Dekomposition lässt sich eine ASIL-D-Anforderung auf redundante, unabhängige Pfade niedrigerer Stufe aufteilen — das reduziert den Methodenaufwand pro Komponente, verlangt aber den Nachweis der Rückwirkungsfreiheit (Freedom from Interference).
Wie hängen ISO 26262 und das V-Modell zusammen?
Die ISO 26262 ist entlang eines V-Modells aufgebaut. Auf dem linken Ast entstehen Item-Definition, Gefährdungsanalyse mit ASIL-Einstufung, Sicherheitsziele und die daraus abgeleiteten Anforderungen bis hinunter zum Software-Unit-Design. Auf dem rechten Ast steht zu jeder dieser Ebenen ein eigener Verifikations- oder Validierungsschritt. Jede Anforderung braucht also einen zugeordneten Test — und genau diese Zuordnung ist es, die im Assessment nachgewiesen werden muss.
Item-Definition, Gefährdungsanalyse (HARA), ASIL-Einstufung, Sicherheitsziele
Validierung der Sicherheitsziele im Gesamtfahrzeug
Funktionale Sicherheitsanforderungen
Systemintegration und Systemtest
Technische Sicherheitsanforderungen
Hardware-Software-Integration, HiL-Test mit Fehlerinjektion
Software-Sicherheitsanforderungen und Software-Architektur
Software-Integrationstest gegen die Architektur
Software-Unit-Design
Unit-Test mit ASIL-gerechter struktureller Überdeckung
Das V ist dabei kein Wasserfall. In der Praxis werden die Äste mehrfach durchlaufen, Sicherheitsanforderungen ändern sich noch spät, und die rechte Seite läuft längst nicht mehr am Projektende, sondern bei jedem Merge. Genau hier setzt CI/CD an: Der rechte Ast lässt sich weitgehend automatisieren — Unit-Tests mit struktureller Überdeckung, Integrationsläufe, nächtliche HiL-Tests in der Automotive-Toolchain. Der linke Ast bleibt Kopfarbeit; automatisieren lässt sich dort allenfalls die Verwaltung, nicht das Urteil.
Was die beiden Äste verbindet, ist die horizontale Verknüpfung: Anforderung ↔ Test. Sie ist der Kern der Traceability und der Punkt, an dem die meisten Projekte im Assessment ins Rutschen kommen — nicht weil nicht getestet worden wäre, sondern weil niemand mehr sicher sagen kann, welcher Test welche Sicherheitsanforderung abdeckt. Dieselbe Logik der Prozessreife bewertet übrigens ASPICE mit seinem eigenen V-Modell — die beiden Normen teilen sich die Struktur, nicht den Zweck.
Was gehört in eine ISO-26262-konforme CI/CD-Pipeline?
Eine ISO-26262-konforme Pipeline verankert die geforderten Verifikationsmethoden als automatische Quality Gates: statische Analyse nach MISRA C, Unit-Tests mit struktureller Coverage (bis MC/DC für ASIL D), Integrations- und HiL-Tests, eine generierte Traceability-Matrix und signierte Reports. Jeder Merge erzeugt damit auditierbare Nachweise — statt einer Dokumentationswelle kurz vor dem Assessment. Wer das einmal erlebt hat, kennt die Szene: Drei Wochen vor dem Termin sitzt das Team abends über einer Excel-Trace-Matrix, deren Anforderungs-IDs auf einen Softwarestand zeigen, den es so längst nicht mehr gibt. Jede manuell rekonstruierte Zeile ist Entwicklungszeit, die dem Projekt verloren geht.
pipeline (vereinfacht, Ziel: ASIL D) ├── 01 static-analysis MISRA-C-Prüfung — 0 offene Violations als Gate ├── 02 unit-tests MC/DC-Coverage gegen Zielwert, Report archiviert ├── 03 integration-tests Schnittstellen gegen die Software-Architektur ├── 04 hil-tests Fehlerinjektion am HiL-Prüfstand (nightly) ├── 05 trace-matrix Anforderung → Code → Test, automatisch generiert └── 06 sign-and-archive Reports signieren, Build reproduzierbar ablegen
Entscheidend ist die Reihenfolge der Gates: Statische Analyse und Unit-Coverage laufen bei jedem Commit und brechen den Build hart ab, teure HiL-Läufe mit Fehlerinjektion nightly. Die Traceability-Matrix wird nicht in Excel gepflegt, sondern aus Anforderungs-IDs in Commits und Test-Annotationen generiert — so kann sie gar nicht erst veralten. Falls Ihre Matrix heute noch in Excel lebt: Damit sind Sie nicht allein — die Excel-Matrix ist der Stand, mit dem die meisten Zulieferer in ihr erstes Assessment gehen, weil kein Lastenheft ein Werkzeug dafür vorschreibt. Sobald der erste Merge eine vollständige, aktuelle Trace-Matrix als Build-Artefakt auswirft, fragt im Team niemand mehr, wozu die Pipeline gut ist: Die Compliance-Last ist zum Nebenprodukt geworden.
Dazu kommt die Tool-Qualifizierung nach ISO 26262-8: Jedes Werkzeug der Kette wird klassifiziert, ob ein Werkzeugfehler unentdeckt einen Produktfehler verursachen könnte. Eine Pipeline mit redundanten, voneinander unabhängigen Prüfungen senkt das nötige Tool Confidence Level — ein oft übersehener Vorteil der Automatisierung. Auch die Frage des Assessors, warum das Compiler-Update mitten im Projekt die Nachweise nicht berührt hat, beantwortet sich dann aus der Pipeline heraus — nicht aus dem Gedächtnis der Beteiligten. Wie sich solche Nachweis-Pipelines mit Security-Gates kombinieren lassen, zeigt unsere Seite zu DevSecOps & Compliance. Die Prinzipien dahinter — Versionierung, automatisierte Gates und Deployments unter den Randbedingungen physischer Systeme — sind im Leitfaden zu Industrial DevOps zusammengefasst.
ASIL über Gefährdungsanalyse bestimmen
Aus Schwere (S), Eintrittswahrscheinlichkeit (E) und Beherrschbarkeit (C) der Gefährdung ergibt sich die ASIL-Einstufung A–D je sicherheitsrelevanter Funktion.
Anforderungen versionieren
Sicherheitsanforderungen in Git ablegen und mit Tests verknüpfen, damit jede Änderung nachvollziehbar und auditierbar bleibt — Grundlage für Traceability.
Testabdeckung automatisieren
Unit-, Integrations- und HiL-Tests in der CI/CD-Pipeline mit ASIL-gerechten Coverage-Zielen (z. B. MC/DC für ASIL D) als Quality Gate verankern.
Traceability-Matrix generieren
Verknüpfung Anforderung → Design → Code → Test automatisiert aus der Pipeline erzeugen, statt sie manuell in Excel zu pflegen.
Audit-Artefakte signieren
Reports, Coverage-Nachweise und Trace-Matrix als signierte, reproduzierbare Build-Artefakte ablegen — bereit für das Assessment.
Für was steht ASIL?
ASIL steht für Automotive Safety Integrity Level, auf Deutsch etwa „Automobil-Sicherheitsintegritätsgrad". Der Begriff stammt aus der ISO 26262 und bezeichnet die Risikoklasse, die einer sicherheitsrelevanten Fahrzeugfunktion zugeordnet wird. Aus dem ASIL leiten sich die verbindlichen Anforderungen an Entwicklungsmethoden, Testtiefe und Nachweisführung ab — je höher die Stufe, desto strenger.
Was bedeutet ASIL auf Deutsch?
ASIL steht für Automotive Safety Integrity Level; auf Deutsch am ehesten „Automobil-Sicherheitsintegritätsgrad" oder, weniger sperrig, „Sicherheitsanforderungsstufe". Eine offizielle deutsche Übersetzung führt die ISO 26262 nicht — auch in deutschsprachigen Projekten wird durchgängig von ASIL A bis ASIL D gesprochen, und in Lastenheften taucht die Abkürzung unübersetzt auf. Nicht zu verwechseln mit dem gleichlautenden Vornamen Asil, der aus dem Arabischen stammt und „edel" bedeutet; mit der Norm hat er nichts zu tun.
Was sind die funktionalen Sicherheitsstufen (ASIL)?
Die funktionalen Sicherheitsstufen im Automotive-Bereich sind QM, ASIL A, ASIL B, ASIL C und ASIL D. Sie sind das Automotive-Pendant zu den SIL-Stufen (Safety Integrity Level) der IEC 61508, aus der die ISO 26262 abgeleitet ist — anders als SIL wird ASIL jedoch nicht allein aus der Ausfallwahrscheinlichkeit bestimmt, sondern zusätzlich aus der Beherrschbarkeit durch den Fahrer. Eine Funktion ohne Sicherheitsrelevanz erhält kein ASIL, sondern die Einstufung QM.
Was ist der Unterschied zwischen ASIL und SIL?
SIL (Safety Integrity Level, SIL 1 bis SIL 4) stammt aus der branchenübergreifenden IEC 61508, ASIL (A bis D) aus der davon abgeleiteten Automotive-Norm ISO 26262. Der wesentliche Unterschied liegt in der Herleitung: SIL wird im Kern aus der tolerierbaren Ausfallwahrscheinlichkeit bestimmt, ASIL zusätzlich aus der Beherrschbarkeit der Situation durch den Fahrer — dem C-Parameter. Eine verbindliche Umrechnung zwischen beiden Skalen gibt es nicht; grob liegt ASIL D auf dem Anspruchsniveau von SIL 3, eine Gleichsetzung im Sicherheitsargument ist damit aber nicht gedeckt.
Was bedeutet ASIL A?
ASIL A ist die niedrigste der vier ASIL-Stufen und steht für ein geringes Sicherheitsrisiko, etwa bei Rückleuchten oder Komfortfunktionen mit begrenzter Wirkung. Gefordert sind vor allem systematische Anforderungs- und Code-Reviews sowie Anweisungsüberdeckung (Statement Coverage) im Unit-Test. ASIL A ist damit methodisch der Einstieg in die funktionale Sicherheit; mit ASIL B, C und D steigen Coverage-Maß, Review-Unabhängigkeit und Nachweistiefe schrittweise an.
Was bedeutet ASIL B?
ASIL B ist die zweitniedrigste der vier ASIL-Stufen und steht für ein mittleres Sicherheitsrisiko — typisch für Funktionen wie Rückfahrkamera, Instrumentenanzeige oder Teile der Beleuchtung. Gefordert werden unter anderem Anforderungs- und Code-Reviews, strukturelle Testabdeckung auf Zweigebene (Branch Coverage) sowie eine dokumentierte Traceability. Der Sprung zu ASIL C und D betrifft vor allem Methodentiefe und Coverage-Maß, nicht die grundsätzliche Systematik.
Was bedeutet ASIL C?
ASIL C ist die zweithöchste der vier Stufen und kennzeichnet ein hohes Risiko — typischerweise Funktionen im Antriebsstrang oder Fahrwerk, bei denen dem Fahrer noch eine Reaktionschance bleibt. Verlangt werden Zweigüberdeckung im Unit-Test, Fehlererkennungsmechanismen, unabhängige Reviews und Hardware-Architekturmetriken von mindestens 97 % Single-Point-Fault-Metrik. Der Abstand zu ASIL D liegt weniger in der Systematik als in der Nachweistiefe: MC/DC-Überdeckung ist für ASIL C empfohlen, für ASIL D dringend empfohlen.
Was ist die ISO 26262?
Die ISO 26262 ist der internationale Standard für funktionale Sicherheit (Functional Safety) von elektrischen und elektronischen Systemen in Straßenfahrzeugen. Sie leitet sich aus der allgemeinen Sicherheitsnorm IEC 61508 ab und definiert einen Sicherheitslebenszyklus über Entwicklung, Produktion und Betrieb — mit nachweisbarer Testabdeckung, Traceability und Dokumentation.
Was ist eine ISO-26262-Zertifizierung?
Streng genommen wird ein Fahrzeug nicht „nach ISO 26262 zertifiziert". Die Norm sieht ein Assessment der funktionalen Sicherheit vor, in dem eine hinreichend unabhängige Person die Arbeitsergebnisse eines Projekts bewertet — oft begleitet von einer Bestätigung durch eine Prüforganisation wie TÜV oder Dekra. Zertifikate gibt es für einzelne Produkte, für Entwicklungsprozesse und für Personen (Functional Safety Engineer). Das Sicherheitsargument selbst bleibt ein projektbezogener Nachweis, und genau deshalb entscheidet die Qualität der Artefakte über den Ausgang: Was die Pipeline bei jedem Build erzeugt, muss im Assessment niemand rekonstruieren.
Was bedeuten die ASIL-Stufen A bis D?
ASIL (Automotive Safety Integrity Level) klassifiziert das Risiko einer Funktion. Die Einstufung ergibt sich aus Schwere, Eintrittswahrscheinlichkeit und Beherrschbarkeit einer Gefährdung. ASIL A ist die niedrigste, ASIL D die höchste Stufe — letztere gilt für Funktionen wie Bremse, Lenkung oder Airbag und verlangt die strengsten Nachweise. Funktionen ohne Sicherheitsrelevanz laufen als QM.
Was bedeutet ASIL D konkret für die Entwicklung?
ASIL D fordert die höchste Methodentiefe: strukturelle Code-Coverage bis MC/DC, Fehlererkennungsmechanismen, oft Redundanz, strikte Reviews und lückenlose Traceability zwischen Anforderungen, Design, Code und Tests. Genau diese Nachweise lassen sich am wirksamsten automatisiert in der CI/CD-Pipeline erzeugen.
Wie passt ISO 26262 mit dem V-Modell zusammen?
ISO 26262 folgt einem V-Modell: Auf der linken Seite Anforderungen und Design, auf der rechten Seite die zugehörigen Verifikations- und Validierungsschritte. Jede Anforderung braucht einen korrespondierenden Test. CI/CD automatisiert die rechte Seite und macht die Verknüpfung über eine Traceability-Matrix sichtbar.
Lassen sich ISO-26262-Nachweise in CI/CD automatisieren?
Ja — und das ist der größte Hebel. Testabdeckung, statische Analyse (MISRA), Traceability-Matrix und signierte Audit-Reports lassen sich als Quality Gates in die Pipeline integrieren. So entsteht der Sicherheitsnachweis bei jedem Build, statt mühsam vor dem Assessment zusammengetragen zu werden.
Was ist der Unterschied zwischen ISO 26262 und ASPICE?
ISO 26262 adressiert die funktionale Sicherheit (was ein System sicher macht), Automotive SPICE (ASPICE) bewertet die Reife des Entwicklungsprozesses (wie diszipliniert entwickelt wird). In der Praxis greifen beide ineinander: ASPICE-konforme Prozesse liefern die Disziplin, ISO 26262 die sicherheitsspezifischen Anforderungen.
Was bedeutet ASIL B(D), gesprochen „ASIL B von D"?
Die Schreibweise ASIL B(D) bezeichnet ein Element, das nach ASIL B entwickelt wird, aber aus einer ursprünglichen ASIL-D-Anforderung hervorgegangen ist. Sie entsteht durch ASIL-Dekomposition nach ISO 26262-9: Eine hohe Sicherheitsanforderung wird auf mehrere redundante, ausreichend unabhängige Elemente niedrigerer Stufe aufgeteilt — etwa ASIL D in zwei Pfade ASIL B(D) + ASIL B(D). Das senkt den Methodenaufwand pro Element, verlangt aber den Nachweis der Unabhängigkeit (Freedom from Interference); fehlt er, gilt weiterhin die ursprüngliche Stufe in Klammern.
Müssen CI/CD-Tools wie Jenkins nach ISO 26262 qualifiziert werden?
Nicht pauschal. ISO 26262-8 (Kapitel 11) verlangt eine Tool-Klassifizierung: Kann ein Werkzeugfehler einen Fehler ins Produkt einbringen oder dessen Entdeckung verhindern, ergibt sich daraus ein Tool Confidence Level (TCL 1–3). Orchestrierer wie Jenkins oder GitLab CI kommen oft mit TCL 1 davon, wenn nachgelagerte Gates (Tests, Reviews, Prüfsummen) Werkzeugfehler aufdecken würden — Compiler oder Codegeneratoren brauchen dagegen meist eine Qualifizierung.
Eine solche Pipeline zu bauen ist das eine — sie über einen Produktzyklus hinweg nachweisfähig zu halten, das andere. Toolchain-Updates, Zertifikate, Build-Agents, ausgeschiedene Kolleginnen und Kollegen: Die Nachweiskette reißt selten am Tag des Assessments, sondern in den Monaten davor. Wer den laufenden Betrieb nicht intern vorhalten will, gibt ihn als Managed CI/CD per SLA ab — inklusive der Auditierbarkeit, die ISO 26262 und TISAX verlangen.
Wenn Sie einordnen möchten, wie weit Ihre Pipeline von auditierbaren ISO-26262-Nachweisen entfernt ist: Ein 30-minütiges Erstgespräch kostet nichts und verpflichtet zu nichts — Sie entscheiden danach, ob mehr daraus wird.
Wie geht es bei Ihnen mit der ISO 26262 weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
DevSecOps für die Industrie & IEC 62443
Security-Gates und Zonen-Modell in industriellen CI/CD-Pipelines.
ASPICE: Automotive SPICE einfach erklärt
Prozessreife-Bewertung für die Automotive-Softwareentwicklung.
TIA Portal mit Git versionieren
Mergefähige SPS-Quelltexte als Basis für Traceability und Audits.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance