Dokumentation

VDA 231-301 definiert ein standardisiertes Datenformat für die Übermittlung von Werkstoffprüf- und Bemusterungsergebnissen entlang der automobilen Lieferkette. Es ermöglicht OEMs, Lieferanten und Prüflaboren, Daten maschinenlesbar und validiert auszutauschen — ohne proprietäre Systeme oder manuelle Nacherfassung.

Der Standard wird vom VDA — Verband der Automobilindustrie — veröffentlicht und von der VDA 231-301 Projektgruppe offen auf GitHub entwickelt.

Das aktuelle offizielle Dokument ist im VDA Webshop erhältlich. Es enthält zusätzliche normative Informationen über das hinaus, was in diesem Repository veröffentlicht ist.

Zweck und Geltungsbereich

Das Generic Schema definiert die zentralen semantischen und strukturellen Elemente des VDA 231-301-Datenmodells. Es bildet eine stabile, wiederverwendbare Grundlage für den standardisierten Austausch werkstoffbezogener Daten und gewährleistet Konsistenz, Interoperabilität und Rückverfolgbarkeit.

Das Generic Schema stellt die zentrale Kernschicht der modularen Architektur von VDA 231-301 dar. Es enthält gemeinsame Konzepte, Strukturen und Gestaltungsprinzipien, die allen Subschemata zugrunde liegen. Domänen-, prozess- oder regulierungsspezifische Aspekte sind hier bewusst nicht definiert — sie werden in dedizierten Subschemata implementiert, die das Generic Schema erweitern.

Für wen ist der Standard relevant

Der Standard ist relevant für:

• OEMs und Tier-1-Lieferanten, die Bemusterungsdaten empfangen oder übermitteln
• Prüflabore, die strukturierte Prüfberichte erstellen
• Softwareanbieter, die Datenaustauschschnittstellen entwickeln
• Qualitätssicherungsteams, die die Einhaltung von Werkstoffspezifikationen prüfen
• Open-Source-Beitragende, die Werkzeuge oder Subschemata entwickeln

Das VDA 231-301-Datenmodell wird in JSON Schema (Draft 2020-12) repräsentiert. Das Schema ist maschinenlesbar, erweiterbar und für die automatisierte Validierung und Verarbeitung ausgelegt.

Kernelemente

Das Generic Schema definiert wesentliche Bausteine, die konsistent in allen Subschemata wiederverwendet werden:

• Identifikatoren und Referenzen — jedes referenzierbare Objekt trägt ein internes _id-Feld (UUID v4), das innerhalb einer Übertragungsdatei eindeutig ist und nach der Zuweisung nicht geändert werden darf
• Metadaten und Kontext — Felder wie Titel, Datumsangaben, Bestellreferenzen und Parteiinformationen
• Generische Objektstrukturen — TestingProject, TestingCenter, Sample und verwandte Entitäten
• Muster für Erweiterbarkeit — Subschemata fügen domänenspezifische Felder hinzu und bleiben dabei strukturell kompatibel

Gestaltungsprinzipien

Das Schema folgt diesen Prinzipien:

• Maschinenlesbarkeit vor menschlicher Bequemlichkeit
• Konsistenz aller Subschemata durch gemeinsame $defs
• Erweiterbarkeit ohne Schemaduplizierung — Subschemata referenzieren das Generic Schema per $ref
• Eignung für automatisierte Verarbeitung und CI-gestützte Validierung

Identifikatoren

IDs in VDA 231-301 folgen UUID v4 (RFC 4122):

{
  "_id": "123e4567-e89b-12d3-a456-426655440000"
}

Regeln:

• Jedes referenzierbare Objekt muss _id tragen
• _id muss innerhalb einer Übertragungsdatei eindeutig sein
• _id darf nach der Zuweisung nicht geändert werden
• Referenzfelder (z. B. ContractorID) verwenden dasselbe UUID v4-Format

Subschemata erweitern das Generic Schema um spezialisierte Inhalte für einen bestimmten Standard oder eine bestimmte Empfehlung. Jedes Subschema fügt domänen-, prozess- oder regulierungsspezifische Attribute hinzu und hält dabei die Kerndefinitionen und Gestaltungsprinzipien des Generic Schema ein.

Lebenszyklus

Ein Subschema durchläuft zwei Phasen, bevor es als offiziell gilt:

Phase 1 — Entwurf und Diskussion. Jedes Subschema beginnt als eigenständiges GitHub-Repository. Diese Repositories sind öffentlich zugängliche Arbeitsentwürfe, die zur Diskussion einladen und Rückmeldungen über GitHub Issues und Discussions sammeln. Subschemata in dieser Phase sind noch nicht offiziell versioniert.

Phase 2 — Offizielle Veröffentlichung. Sobald ein Subschema von der zuständigen VDA-Projektgruppe geprüft und freigegeben wurde, erhält es eine Versionsnummer und wird im zentralen Schema-Repository veröffentlicht. Nur Subschemata im Schema-Repository gelten als offiziell freigegeben.

Detaillierungsgrad

Ein Subschema kann Anforderungen auf zwei Ebenen definieren:

• Muss — Pflichtanforderungen gemäß dem referenzierten Standard
• Kann — optionale Anforderungen, häufig durch interne Werknormen definiert

Beide Ebenen werden in JSON Schema unterstützt und können entsprechend validiert werden.

Versionierung

Jedes Schema muss eine eindeutige Versionierung nach Semantic Versioning aufweisen (z. B. v1.0.0). Änderungen müssen in einem Changelog dokumentiert und ausschließlich über Pull Requests eingebracht werden, um Konsistenz, Rückverfolgbarkeit und Transparenz zu gewährleisten.

Erstellen eines Subschemas

Leitlinien zur Entwicklung eines neuen Subschemas sind im Repository verfügbar:

• Englische Leitlinien
• Deutsche Leitlinien