Automotive SPICE · Traceability

ASPICE Traceability: Spec → Test → Nachweis

ASPICE bewertet Prozessreife und bidirektionale Traceability, nicht nur grüne Lab-Ergebnisse. Bricht Spec → Anforderung → Test → Nachweis, bleibt Audit-Risiko.

Gespräch buchen Demo starten

Kontext

Was ASPICE von einem Batterie-Prüfplan verlangt

Automotive SPICE bewertet Prozessreife und bidirektionale Traceability, nicht grüne Laborergebnisse allein. Die Kette Spec, Anforderung, Test, Nachweis muss in beide Richtungen halten. Bricht sie, bleibt Audit-Risiko.

Typische Lücken in Batterie-Programmen: Freitext ohne ID, Norm ohne Abschnitt, OEM-Änderungen nur in E-Mail, Excel-Pläne ohne Spec-Seite. Cevelar erzeugt stabile IDs aus der Quelle. Leitfäden daneben: IEC 62619, Prüfplanung.

Prozess-Treffer

Wo ASPICE auf Validierung trifft

SYS.2 / SWE.1

Requirements

Jede Anforderung braucht ID, Owner und Verification Method, kein Copy-Paste in Excel.

SWE.4 / SWE.5

Verification

Verfahren müssen Anforderung und Acceptance Criterion zitieren.

SUP.8 / SUP.10

Change

OEM-Deltas gehören in dieselbe Kette, nicht nur in Mail-Threads.

Assessment

Nachweis

Assessoren wollen den Pfad zur Spec-Seite, nicht den Screenshot einer grünen Zelle.

Findings Board

Typische Lücken vor Assessment

In Battery- und BMS-Programmen tauchen dieselben Brüche immer wieder auf, oft erst wenn das Lab schon gebucht ist.

F-01 Freitext ohne stabile ID Baseline und Re-Verify nach Change unmöglich.
F-02 Norm genannt, kein Abschnitt IEC 62619 oder UN 38.3 ohne Mapping → Über- oder Untertestung.
F-03 OEM-Delta nur in E-Mail Stiller Scope-Drift außerhalb der ALM-Kette.
F-04 Excel ohne Spec-Rückverweis Pass/Fail ohne Quellenlink bleibt Assessment-Risiko.
F-05 Transport und Einsatz vermischt Doppelkampagnen, weil UN 38.3 und IEC 62619 nie getrennt wurden.

Checkliste

Signal → Plan-Frage → Risiko

Spec-Signal	Plan-Frage	Risiko bei Lücke
REQ ohne ID	Baseline und Re-Verify nach Change möglich?	Finding / Nacharbeit
Norm ohne Abschnitt	Welches Verfahren schließt welche Anforderung?	Über- / Untertestung
OEM-Anhang / Mail-Delta	In derselben ALM-Kette?	Stiller Scope-Drift
Pass/Fail ohne Quellenlink	Warum existiert dieser Test?	Audit-Risiko trotz grünem Lab

Für Heads of Validation

Was Assessment wirklich prüft

Matrix Spec-Seite → REQ-ID → Norm → Verfahren → Nachweis
Frühe Konflikte: OEM vs. IEC / UN 38.3 / Kundenprofile
Kosten- und Sequenzschätzung vor Laborbuchung
Export für Polarion, Jira und Assessment-Reviews

Kontakt

Traceability aus der Spec, nicht aus dem Screenshot.

Cevelar extrahiert strukturierte Anforderungen, mappt Normen und erzeugt Testpläne mit Quellen-Traceability, EU-gehostet für IP-sensible Programme.

Gespräch buchen Demo starten

FAQ

Fragen zu ASPICE

Traceability, bevor das Assessment beginnt.

Was bedeutet ASPICE für Validierungsteams?

ASPICE fordert nachvollziehbare Prozesse und bidirektionale Traceability zwischen Anforderungen, Design und Tests. Für Battery-Validation heißt das: Spec-Anforderungen müssen bis zum Prüfverfahren und Nachweis belegbar bleiben.

Wo entstehen typische ASPICE-Lücken in Batterie-Programmen?

Freitext-Requirements ohne IDs, Norm-Referenzen ohne Abschnittsnummern, OEM-Änderungen nur in E-Mails und Excel-Testpläne ohne Rückverweis auf die Spec-Seite.

Wie unterstützt Cevelar ASPICE-Traceability?

Cevelar erzeugt strukturierte Anforderungen aus OEM-Specs mit Verweis auf Quelle und Normabschnitt, als Basis für auditierbare Testpläne und Export in ALM-Tools. EU-gehostet für IP-sensible Programme.