E Anlage 24 EFM_Anh 9_Anl 1_Technische Anforderung Deutschlandticket V1.9_240816_MVU 250428.pdf

[Seite 1]

Technische Anforderung

Deutschlandticket

Technische Beschreibung der Ausgabe und Kontrolle

Version: 1.9

Datum: 16.08.2024

Autor Daniel Ackers, Bernd Pieper, VDV-ETS

[Seite 2]

Versionsverwaltung

Version Bearbeiter Datum Bemerkung

1.0 Daniel 28.09.2022 Ersterstellung Ackers, Bernd Pieper

1.1 Bernd 06.10.2022 Konkretisierung nach Hinweisen aus der Branche Pieper Abbildung der räumlichen Gültigkeit eingeführt, um eine Kontrolle im Ausland zu ermöglichen

13.10.2022 Weitere redaktionelle Überarbeitung nach Diskussion mit UA2 und AG Online-Vertrieb Datenelement/Tag 0xD7 „Identifikationsmedium“ bei der Ausgabe auf Sicherheitspapier gestrichen

1.2 Bernd 21.10.2022 Weitere redaktionelle Überarbeitung nach Pieper Diskussion mit (((eTicket Deutschland Teilnehmern Kapitel 2: Angaben zur Abbildung der zeitlichen Gültigkeit ergänzt. Kapitel 2.3: Variante: Handschriftliche Ergänzung des Namens auf Sicherheitspapier ergänzt.

1.3 Bernd 21.11.2022 Weitere redaktionelle Überarbeitung Pieper Begriff „Deutschlandticket“ eingeführt Kapitel 2: Produktnummer für Jobticket ergänzt Kapitel 2: Vorgabe zum Gültigkeitsende geändert Kapitel 4: Darstellung der verschiedenen Ausprägungen des Deutschlandtickets ergänzt

[Seite 3]

Version Bearbeiter Datum Bemerkung

1.4 Daniel 31.01.2023 Weitere redaktionelle Überarbeitung Ackers, Begriff „Konzept“ durch „Leitfaden“ ersetzt Bernd Kapitel 2: Produktnummer für Startkarte und Pieper Semester- und Schülerticket ergänzt Kapitel 2 und 4: Anpassung der zeitlichen Gültigkeit an die Tarifbestimmungen. Kapitel 2.3: Anpassung an Beschluss von Bund und Ländern vom 27.01.2023 zur Zulassung von Papiertickets Kapitel 3: Hinweis auf logTransaktionsOrt_ID ergänzt Kapitel 3.1: Ausführungen zum MAC ergänzt. Kontrolle Kapitel 3.2: Hinweis auf logTransaktionsTyp.code bei Kontrolle Motics-Ticket ergänzt. Kapitel 5: Beschreibung der Umsetzung der tariflichen Kontrolle mit Kontrollmodulen ergänzt.

1.5 Bernd 15.03.2023 Weitere redaktionelle Überarbeitung Pieper Hinweis zur Befristung der „Startkarte“ in Kapitel 2 eingefügt. Hinweise zur Angabe 3 Uhr, zum Betriebsschluss und zur zeitlichen Gültigkeit bei Chipkarten in Kapitel 2 eingefügt. Hinweis zur Angabe des Geburtsdatums in Kapitel 2 eingefügt. Hinweis zum CR 141 in Kapitel 2.2 und 2.3 eingefügt. Hinweis zum Zeitpunkt der Einführung der Kontrollnachweise in Kapitel 3 eingefügt. Hinweis zum CR 232 in Kapitel 3.1 eingefügt. Hinweis zur Überprüfung des Namens in Kapitel 3.1, 3.2 und 3.3 eingefügt.

1.6 Daniel 20.04.2023 Kapitel 2: Zentrales PVS eingeführt Ackers, Bernd Pieper

1.7 Bernd 05.05.2023 Kapitel 4: Längenangabe der Version des MK PV Pieper (Inkonsistenz zur Spezifikation) beim Motics-Ticket und beim VDV-Barcode korrigiert. In allen Darstellungen bei den Hinweisen zum Inhalt der prodProdukt_ID zentralen PV berücksichtigt.

[Seite 4]

Version Bearbeiter Datum Bemerkung

1.8 Bernd 07.06.2023 Kapitel 2: Produktnummern für das Pieper Deutschlandticket als Semester- und Schülerticket nach PuV-Beschluss vom 05.06.2023 freigegeben.

1.9 Bernd 13.08.2024 Redaktionelle Anpassungen: Pieper Kapitel 2, Seite 7: Bezeichnung „lokaler PV“ durch Daniel „anderer PV“ ersetzt. Ackers Kapitel 2, Seite 8: Hinweis ergänzt, dass das Tag 0xDC im Level 2 und 3 gleich ausgefüllt wird. Kapitel 3, Seite 11: Bezeichnung „lokaler Verbund“ durch „eingetragenen PV“ ersetzt. Anpassungen aufgrund politischer Beschlüsse: (siehe Dokument „Beschluss Tarifbestimmungen Deutschlandticket 230308 aktualisiert 230530 230710 230925 231127 231211“ in (((efi in der Gruppe „Umsetzung Deutschlandticket“ unter Politische Beschlüsse) Kapitel 2, Seite 8: Das Geburtsdatum ist verpflichtend (bei Chipkarten ab 01.01.2025). Hinweis zum Geburtsdatum angepasst. Kapitel 3, Seite 12: Ausführungen zur Anzeige des Geburtsdatums angepasst. Kapitel 2, Seite 6 und 7: Startkarte (9997) und Hinweis dazu entfernt, da nur bis 31.12.2023 zugelassen. Anpassungen wegen ZPVS: Kapitel 3, Seite 12: Kontrollnachweise an ZPVS freigegeben und DHID dringend empfohlen

[Seite 5]

Inhaltsverzeichnis

Versionsverwaltung

1 Einordnung und Aufgabe des Dokuments

2 Ausgabe allgemein

2.1 Ausgabekanal Chipkarte

2.2 Ausgabekanal Motics-Ticket

2.3 Ausgabekanal VDV-Barcode

3 Kontrolle allgemein

3.1 Kontrolle Chipkarte

3.2 Kontrolle Motics-Ticket

3.3 Kontrolle VDV-Barcode

4 Darstellungen Deutschlandticket

4.1 TLV EFS Chipkarte

4.2 TLV EFS Motics-Ticket

4.3 TLV EFS VDV-Barcode

5 Umsetzung der Kontrolle mit Kontrollmodulen

[Seite 6]

Hinweise:

Bei den Dokumenten, auf die im Folgenden verwiesen wird, handelt es sich um

Dokumente, die Bestandteil der Spezifikation der VDV-KA sind. Es handelt sich nicht um

spezielle Dokumente zum Deutschlandticket.

Bezüglich der Umsetzung des Deutschlandtickets sind alle KA-Releases miteinander

kompatibel.

1 Einordnung und Aufgabe des Dokuments

Das Dokument beschreibt die technischen Rahmenbedingungen für die Einführung von

Tarifprodukten mit nationaler Gültigkeit und richtet sich an Vertriebsverantwortliche und

Entwickler für ÖPV-Vertriebssysteme. Im Dokument wird nicht von Empfehlungen

gesprochen, sondern von Anforderungen. Dies liegt vor allem in der Situation begründet,

dass einem durch Bund und Länder finanzierten nationalen Tarifprodukt andere

Erwartungen aus Politik und Gesellschaft gegenüberstehen, als dem kommunal

organisierten Vertrieb des ÖPNV.

Für die Umsetzung ist es erforderlich, Teilnehmer von (((eTicket Deutschland zu sein.

Wer noch kein Teilnehmer ist, erhält über https://www.eticket-deutschland.de/fuer-

oepnv/ Informationen, um Teilnehmer zu werden.

2 Ausgabe allgemein

Für die Ausgabe wird die in der VDV-KA spezifizierte Eigenschaft der interoperablen

Produktnummern verwendet (siehe „KA Produkt_ID-ANW“, Kapitel 3.3 und 3.5). Es

werden die folgenden Produktnummern verwendet:

• 9999 für das Deutschlandticket als Abo

• 9998 für das Deutschlandticket als Jobticket

• 9996 für das Deutschlandticket als Semesterticket

• 9995 für das Deutschlandticket als Schülerticket

[Seite 7]

Hinweise:

Die für Schülertickets (9995) und Semestertickets (9996) vorgesehenen

Produktnummern werden gemäß Beschluss des PuV vom 05.06.2023 ab sofort für die

Ausgabe mit frühstem Gültigkeitsbeginn zum 01.08.2023 freigegeben.

Dabei tragen die ausgebenden Unternehmen das Risiko für etwaige Anpassungen bzw.

einen Tickettausch, wenn die Tarifbestimmungen für die deutschlandweiten gültigen

Schülertickets bzw. Semestertickets festgelegt wurden.

Die „Startkarte“ mit der Produktnummer 9997 entfällt, da sie nur bis zum 31.12.2023

zugelassen war

Aufgrund des Beschlusses des VDV-Präsidiums vom 5. Oktober 2023 wird ein zentraler,

technischer PV eingeführt. Das entsprechende zentrale PVS (ZPVS) wird vorläufig von

VDV-ETS betrieben und arbeitet mit der ORG_ID 3000 (Level 3) bzw. 35768 (Level 2).

Demzufolge ist als PV-Schlüssel (KID 40) der mit der ORG_ID 3000 (Level 3) bzw. 35768

(Level 2) jeweils in der Regel- und Notfallversion zu verwenden. Diese ORG_ID ist in die

Produkt_ID einzutragen.

Übergangsweise kann für die Produkt_ID auch noch die ORG_ID eines anderen PV

verwendet werden, dessen Produkte der KVP vertreiben darf. Ein verpflichtender Termin,

bis zu dem der Übergang abgeschlossen ist, muss noch abgestimmt werden. Beim

Motics-Ticket und beim VDV-Barcode kann wegen der kürzeren Ticketgültigkeit der

Übergang bereits erfolgen, sobald der neue Schlüssel in die SAMs eingebracht worden ist.

Das ZPVS ist auch für die neuen Teilnehmer an eTicket Deutschland wichtig, die noch

keinen PV haben und somit auch für das Deutschlandticket keinen aufbauen müssen.

Eine Konfiguration des KOSE durch den PV ist nicht erforderlich, da zu sperrende

Berechtigungen mit interoperablen Produktnummern grundsätzlich analog zur Applikation

in jeder Sperrliste enthalten sind.

Bei der Angabe der zeitlichen Gültigkeit ist darauf zu achten, dass es gemäß

KA HD_BOM-SPEC, Tabelle 6-9 die Angabe 00:00:00 nicht gibt und die Anzahl der

Sekunden in 2-Sekunden-Schritten angegeben wird. Die tagesscharfe zeitliche Gültigkeit

ist somit folgendermaßen anzugeben:

TT.MM.JJJJ 00:00:02 bis TT.MM.JJJJ 03:00:00

[Seite 8]

Es ist zu beachten, dass die Angabe 3 Uhr sich auf den dem Ende der Gültigkeit

folgenden Tag bezieht. Beispiel:

Zeitliche Gültigkeit: 01.05.2023 bis 31.05.2023

Angabe im Ticket: 01.05.2023 00:00:02 bis 01.06.2023 03:00:00

Es ist zu beachten, dass der bei Verkehrsunternehmen unterschiedliche Betriebsschluss

beim Deutschlandticket keine Rolle bei der zeitlichen Gültigkeit spielt.

Beim Ausgabekanal Chipkarte ist die Möglichkeit der Anpassung an die zeitliche Gültigkeit

der Applikation zu beachten (siehe Kapitel 2.1).

Es wird der TLV EFS verwendet (siehe „Anlage TLV EFS“). Dabei wird grundsätzlich

immer das Datenelement/Tag 0xDB „Fahrgast“ verwendet (siehe „Anlage TLV EFS“,

Kapitel 2.2), da das Ticket personengebunden ist. Das Tag ist wie folgt zu füllen:

• efsFahrgastGeschlecht wird mit 0x00 gefüllt, da keine Geschlechtsangabe erfolgt.

• efsFahrgastGeburtsdatum wird mit dem Geburtsdatum gefüllt.

• efsFahrgastName wird mit dem Namen unter Heranziehung der Kürzungsregel 1

oder 2 (siehe „KA HD_BOM-SPEC“, Kapitel 6.7.2) gefüllt. Bei Verwendung von

Kürzungsregel 2 und dem zentralen PV kommt für die Parameter x und y der Wert

12 zum Tragen (siehe KA HD_BOM-SPEC, Kapitel 6.7.2.2.

Hinweis:

Bei Chipkarten muss das Geburtsdatum ab dem 01.01.2025 mit eingetragen werden.

Falls bis dahin kein Geburtsdatum eingetragen wird, ist 0x00000000 einzutragen.

Für die Angabe der räumlichen Gültigkeit ist das Tag 0xDC in der Variante D und dem

Typ 0x0F zu verwenden (siehe „Anlage TLV EFS“, Kapitel 2.4). Als Organisation_ID (PV)

ist 5000 dezimal (0x1388 hexadezimal) und als Flaeche_ID „1“ gemäß KA HD_BOM-

SPEC, Kapitel 6.15 einzutragen. Das Tag ist demzufolge im Level 2 und 3 wie folgt zu

füllen:

[Seite 9]

Diese Ausprägung musste gewählt werden, da die Bundesrepublik die höchste

Hierarchieebene im Sinne der „Anlage TLV EFS“, Tabelle 2-8 ist und keine numerisch

erkennbare Hierarchie zu einer niedrigeren Hierarchieebene gegeben ist.

Der Grund für die Angabe der räumlichen Gültigkeit ist, dass damit bei

grenzüberschreitenden Linien, auf denen das Ticket ebenfalls gilt, Haltestellen im Ausland

entsprechend der bereits vorhandenen Systematik dem Gültigkeitsraum „Bundesrepublik

gesamt“ zugeordnet werden können. Damit ist auch in diesem Fall eine elektronische

Kontrolle möglich.

Eine eigenes Datenelement/Tag für die Angabe der Serviceklasse wird nicht verwendet,

da das Ticket grundsätzlich nur für die 2. Klasse gültig ist.

Weitere je nach Ausgabekanal zu verwendende Datenelemente/Tags sind in den

folgenden Kapiteln beschrieben. Darüber hinaus sind keine weiteren verpflichtende

Datenelemente/Tags vorgesehen.

Ein PV kann jedoch weitere Datenelemente/Tags des TLV EFS jedoch keine

konkurrierenden Tags 0xDC für interne Zwecke vorgeben (z.B. 0xDA "Grundlegende

Daten" oder 0xDE "PV_Container"). Hierzu muss er eine separate ergänzende

Füllvorschrift herausgeben. Für die Kontrolle sind diese Datenelemente/Tags aber

irrelevant. In diesen Datenelementen dürfen keine den Tarifbestimmungen des

Deutschlandtickets widersprechende Angaben enthalten sein. Es ist nicht zulässig hier

eine 1. Klasse oder eine Mitnahme einzutragen. Dies muss gemäß der

Tarifbestimmungen über gesonderte Produkte der PV realisiert werden.

Die Umsetzung der Ausgabe kann aus tariflicher Sicht proprietär oder über

Produktmodule erfolgen.

[Seite 10]

2.1 Ausgabekanal Chipkarte

Für den Ausgabekanal Chipkarte ist die Ausbauvariante 2a (((eFahrschein Abo /

(((eKontrolle EFS und die optionale Ergänzung Multi-Berechtigung zu verwenden (siehe

„Anlage 2 zum (((eTicket-Teilnahmevertrag, Migrationsszenarien in den Ausbauvarianten

des (((eTicket Deutschland“).

Bei der Chipkarte ist als Authentisierungsschlüssel (KID 30), Transaktionsschlüssel (KID

60 und 70) der mit der ORG_ID 5900 (Level 3) bzw. 38668 (Level 2) zu verwenden.

Diese Schlüssel sind in Regel- und Notfallversion im Regelfall bereits in allen SAMs

vorhanden. Ansonsten müssen sie über Kryptogramme in die SAMs nachgeladen werden.

Diese ORG_ID 5900 (Level 3) bzw. 38668 (Level 2) ist in das Datenelement

prodKeyOrganisation_ID einzutragen. Bezüglich der Transaktionsschlüssel ist die „KA TR-

Schlüssel-ANW“ zu beachten.

Das Ticket kann als normale Berechtigung oder als Multi-Berechtigung (siehe „KA

MultiBER-SPEC“) ausgegeben werden. Für die Ausgabe als Multi-Berechtigung muss der

Authentisierungsschlüssel (KID 30) mit der ORG_ID 5900 (Level 3) bzw. 38668 (Level 2)

dazu im Schlüsselspeicher vorhanden sein.

Die Angabe der zeitlichen Gültigkeit kann gemäß der gelebten Praxis an die zeitliche

Gültigkeit der Applikation anpasst werden.

2.2 Ausgabekanal Motics-Ticket

Für den Ausgabekanal Motics-Ticket (VDV-Barcode mobile+) sind in erster Linie die

Dokumente KA STB-SPEC mobile plus (ab KA-Release 1.7.0 veröffentlicht) und KA STB-

SPEC relevant. Der CR 141 „Mehrere Berechtigungen im VDV-Barcode – Alternative

Struktur für die statische Berechtigung“ kommt nicht zur Anwendung.

Im TLV EFS muss ergänzend zu den Datenelementen aus Kapitel 2 als erstes das

Datenelement/Tag 0xD6 „sceId“ (früher „ID_MG“, siehe „Anlage TLV EFS“, Kapitel 2.9)

enthalten sein.

Da ein Motics-Ticket nicht kopierbar ist, kann die Angabe der zeitlichen Gültigkeit analog

zum Ausgabekanal Chipkarte einen größeren Zeitraum umfassen. Dieser kann bei 2

Jahren oder größer liegen.

[Seite 11]

2.3 Ausgabekanal VDV-Barcode

Der VDV-Barcode kann über eine App und durfte befristet bis zum 31.12.2023 auf

Normalpapier ausgegeben werden.

Für den Ausgabekanal ist in erster Linie das Dokument KA STB-SPEC relevant. Der CR

141 „Mehrere Berechtigungen im VDV-Barcode – Alternative Struktur für die statische

Berechtigung“ kommt nicht zur Anwendung.

Der TLV EFS besteht aus den Datenelementen gemäß Kapitel 2.

Da der VDV-Barcode kopierbar ist, liegt die maximal zugelassene zeitliche Gültigkeit bei

einem Monat. Ansonsten ist der Ausgabekanal Motics zu verwenden.

3 Kontrolle allgemein

Die unten beschriebenen Besonderheiten bei den verschiedenen Ausgabekanälen sind

zusätzlich zu beachten.

Berechtigungen mit den Produktnummern gemäß Kapitel 2 sind unabhängig von der

eingetragenen ORG_ID des PVs einzulesen und gegen die Sperrlisten abzugleichen (siehe

„KA SysLH DLRT“, bis Release 1.9.0 „Generelle Abläufe mit dem Nutzermedium“, ab

Release 1.10.0 Kapitel 2).

Wenn es softwaretechnisch erforderlich ist, wird mit der ORG_ID des eingetragenen PV

intern weitergearbeitet. Die Umsetzung der Kontrolle kann aus tariflicher Sicht proprietär

oder über Kontrollmodule erfolgen.

Bei der Erstellung des Transaktionsdatensatzes für den Kontrollnachweis muss mit der in

der Berechtigung eingetragenen ORG_ID des PV gearbeitet werden.

Der Status des Tickets und die zeitliche Gültigkeit sind zu überprüfen. Ist das Ticket nicht

gesperrt und ist die zeitliche Gültigkeit gegeben und befindet sich der Nutzer in der 2.

Klasse, ist das Ticket innerhalb Deutschlands gültig.

Bei grenzüberschreitenden Linien kann zur Ermittlung der ggf. gegebenen räumlichen

Gültigkeit im Ausland das Tag 0xDC ausgewertet werden. Ansonsten kann das Tag 0xDC

ignoriert werden.

[Seite 12]

Name und Geburtsdatum des Fahrgastes sind anzuzeigen. Falls bei Chipkarten das

Geburtsdatum nicht angegeben ist (siehe Kapitel 2), ist dies anzuzeigen.

Weitere Datenelemente sind zu ignorieren.

Die Erzeugung und der Versand der Kontrollnachweise (TXEBER, TXEMBER, TXESTBER,

siehe „KA SysLH DLRT“ inklusive Anlage „Kontrollnachweise EFS“ und „KA STB-SPEC“) an

das ZPVS sind freigegeben. Ansprechpartner für den Anschluss an das ZPVS ist Cezary

Zglinski (Kontaktdaten siehe https://www.eticket-deutschland.de/ueber-uns/unser-

team/).

Bei den Kontrollnachweisen sollte als Transaktionsort im Datenelement

logTransaktionsOrt_ID die DHID der Haltestelle eingetragen werden, an der die Kontrolle

stattgefunden bzw. begonnen hat (siehe KA HD_BOM-SPEC, siehe Tabellen 6-69 und 6-

123). Es kann aber auch eine andere Form der Haltestellenangabe gemäß KA HD_BOM-

SPEC erfolgen. Der Eintrag der DHID wird allerdings perspektivisch dringend empfohlen.

3.1 Kontrolle Chipkarte

Für die Kontrolle der Chipkarte ist die Ausbauvariante 2a (((eFahrschein Abo /

(((eKontrolle EFS und die optionale Ergänzung Multi-Berechtigung zu verwenden (siehe

„Anlage 2 zum (((eTicket-Teilnahmevertrag, Migrationsszenarien in den Ausbauvarianten

des (((eTicket Deutschland“).Der CR 232 „Erweiterung TXEBER“ kommt nicht zur

Anwendung.

Bei der Chipkarte ist als Authentisierungsschlüssel (KID 30), Transaktionsschlüssel (KID

60 und 70) der mit der ORG_ID 5900 (Level 3) bzw. 38668 (Level 2) zu verwenden.

Diese Schlüssel sind in Regel- und Notfallversion im Regelfall bereits in allen SAMs

vorhanden. Ansonsten müssen sie über Kryptogramme in die SAMs nachgeladen werden.

Das Ticket auf der Chipkarte muss ausgelesen und mit Hilfe des SAMs auf Authentizität

geprüft werden (siehe „KA SysLH DLRT“ und „KA MultiBER-SPEC“). Dabei ist es

unerheblich, ob das Ticket als normale Berechtigung oder als Multiberechtigung

ausgegeben wurde. Bei der Prüfung auf Authentizität darf vorerst keine Prüfung des

MAC stattfinden, d. h. das SAM-Kommando Check Entitlement wird mit P1=01 Kontrolle

durchgeführt (siehe „KA SAM-SPEC“, Kapitel 9.1.1). Der Grund dafür ist, dass bei älteren

SAMs der MAC mit einem falsch abgeleiteten Schlüssel erzeugt wird und somit die Kontrolle

[Seite 13]

Prüfung des MAC immer einen Fehler ergeben würde. Voraussichtlich ab Januar Kontrolle

2026 ist die Prüfung des MAC dann durchzuführen, d. h. das SAM-Kommando Kontrolle

Check Entitlement wird mit P1=03 durchgeführt (siehe „KA SAM-SPEC“, Kapitel 9.1.1).

Bezüglich der Transaktionsschlüssel ist auch die „KA TR-Schlüssel-ANW“ zu beachten. Ist

der Authentisierungsschlüssel noch nicht im SAM vorhanden, kann das Ticket nur

ungesichert ausgelesen und somit nicht die Authentizität geprüft werden. In diesem Fall

muss das NM-Kommando Get Data (siehe „KA NM-SPEC“, Kapitel 3.5.3) verwendet

werden.

Stichprobenartig sollten die Fahrgastdaten im auf dem Kontrollgerät angezeigten Ticket

mit den Personendaten eines Ausweisdokumentes abgeglichen werden, da es sich

tariflich um ein nicht übertragbares Ticket handelt.

3.2 Kontrolle Motics-Ticket

Für das Einlesen des Motics-Tickets ist insbesondere sicherzustellen, dass der Motics-

Container korrekt geprüft wird (siehe „Specification Copy Protection Verification“, ab KA-

Release 1.11.0 veröffentlicht) und alle Root- und CA-Zertifikate geladen sind (siehe „KA

STB-SPEC“).

Als logTransaktionsTyp.code ist bei TXESTBER der Wert dezimal 41 (Kontrolle mit Motics

und time stamp) zu verwenden (siehe KA HD_BOM-SPEC, Tabelle 6-65, ab KA-Release

1.11.0).

Stichprobenartig sollten die Fahrgastdaten im auf dem Kontrollgerät angezeigten Ticket

mit den Personendaten eines Ausweisdokumentes abgeglichen werden, da es sich

tariflich um ein nicht übertragbares Ticket handelt.

3.3 Kontrolle VDV-Barcode

Für das Einlesen eines VDV-Barcodes müssen alle Root- und CA-Zertifikate geladen sein

(siehe „KA STB-SPEC“).

Die Fahrgastdaten im auf dem Kontrollgerät angezeigten Ticket müssen zwingend mit

den Personendaten eines Ausweisdokumentes abgeglichen werden, um die Nutzung von

Kopien auszuschließen. Außerdem ist das Ticket tariflich nicht übertragbar.

[Seite 14]

[Seite 14: Text nur als Bild — nicht lesbar]

[Seite 15]

4.1 TLV EFS Chipkarte

Hinweis: Die unten stehende Darstellung einer Berechtigung ist als Hilfestellung zu verstehen. Verbindlich sind die Spezifikation der VDV-KA und die Beschreibung der technischen Anforderungen an das Deutschkandticket. Die Darstellung zeigt die Struktur eines Deutschlandtickets nach der Ausgabe auf einer Chipkarte. Datenelement Länge Wert Hinweise zum Inhalt Datenstruktur "Berechtigung" Tag „Berechtigung“ 1 0xE8 Länge „Berechtigung TLV EFS“ 2 variabel Wertebereich 0x8180 bis 0x81FF Datentruktur „Verzeichniseintrag – Berechtigung“ Tag „Verzeichniseintrag – Berechtigung“ 1 0xE9 Länge „Verzeichniseintrag – Berechtigung“ 1 0x1D Struktur „Systemspezifischer Verzeichnisteil“ Tag „Systemspezifischer Verzeichnisteil“ 1 0xC0 Länge „Systemspezifischer Verzeichnisteil“ 1 0x01 Zeiger auf Separaten Datenteil 1 variabel Wertebereich 0x05 bis 0xC0 Struktur „Verzeichniseintrag – Berechtigung – Statischer Teil“ Tag „Verzeichniseintrag – Berechtigung – Statischer Teil“ 1 0x83 Länge „Verzeichniseintrag – Berechtigung – Statischer Teil“ 1 0x14 berBerechtigung_ID (Struktur „Berechtigung_ID“) (Referenz-ORG_ID für KKVP) 6 Relevante Produktnummer für das prodProdukt_ID (Struktur („EFMProdukt_ID“) (Referenz-ORG_ID für KPV) 4 zen D t e ra u l t e s n c h P la V n o d d ti e ck r e ü t b u e n rg d a O ng R s G w _ e I i D se d n e o s c h des lokalen PV prodKeyOrganisiation_ID (Referenz-ORG_ID für KAUTH und Referenz-ORG_ID für MK/KTR) 2 0x170C Gemäß Vorgabe VDV-ETS berGueltigkeitsbeginn 4 Gemäß Vorgabe 0 0 V :0 D 0 V :0 -E 2 TS TT.MM.JJJJ berGueltigkeitsende 4 Gemäß Vorgabe 0 3 V :0 D 0 V :0 -E 0 TS TT.MM.JJJJ Struktur „Verzeichniseintrag – Berechtigung – Dynamischer Teil“ Tag „Verzeichniseintrag – Berechtigung – Dynamischer Teil“ 1 0x84 Länge „Verzeichniseintrag – Berechtigung – Dynamischer Teil“ 1 0x02 berStatus 1 0x07 Zustand nach der Ausgabe berSynchronNummer 1 0x01 Zustand nach der Ausgabe Struktur „Separate Daten – Berechtigung“ Tag „Separate Daten – Berechtigung“ 1 0xEA Länge „Separate Daten – Berechtigung “ 1 bis 2 variabel Struktur „Separate Daten – Berechtigung – Statischer Produktspezifischer Teil“ Tag „Separate Daten – Berechtigung – Statischer produktspezifischer Teil“ 1 0x85 Länge „Separate Daten – Berechtigung – Statischer produktspezifischer Teil“ 1 variabel Tag "Fahrgast" 1 0xDB Länge "Fahrgast" 1 variabel efsFahrgastGeschlecht 1 0x00 Gemäß Vorgabe VDV-ETS efsFahrgastGeburtsdatum 4 Format JJJJMMTT oder 0x00000000 efsFahrgastName variabel Anwendung Kürzungsregel 1 oder 2 Tag „Liste originärer Geltungsbereich“ 1 0xDC Länge „Liste originärer Geltungsbereich“ 1 0x05 Typ-Definition 1 0x0F Gemäß Vorgabe VDV-ETS Organisation_ID (PV) 2 0x1388 Gemäß Vorgabe VDV-ETS Liste-Flaeche-IDs 2 0x0001 Gemäß Vorgabe VDV-ETS Weitere Tags des TLV EFS jedoch keine konkurrierenden Tags 0xDC durch den … PV möglich. Hierzu muss er eine separate ergänzende Füllvorschrift herausgeben. Tag „Ausgabetransaktion – Berechtigung“ 1 0xF6 Länge „Ausgabetransaktion – Berechtigung“ 1 0x3F Struktur „Allgemeine Transaktionsdaten“ Tag „Allgemeine Transaktionsdaten“ 1 0x89 Länge „Allgemeine Transaktionsdaten“ 1 0x1B logApplikationSeqNummer 2 Trägt das Terminal ein. logNMTransaktion_ID 7 Trägt das SAM ein. logTransaktionsOperator_ID 2 Gemäß Konfiguration des Terminals logTerminal_ID (Struktur „Terminal_ ID“) 5 Gemäß Konfiguration des Terminals logTransaktionsZeitpunkt 4 TransaktionsOrtID (Struktur „Ort_ID“) 6 T G X e x_ m P ä r ß ü f V un o g rg s a -A be N W de s b e P a V c h (K te A n ) logTransaktionsTyp.code 1 0x01 Bei der Ausgabe Struktur „Transaktion Produktspezifischer Teil“ Tag „Transaktion Produktspezifischer Teil“ 1 0x8A Länge „Transaktion Produktspezifischer Teil" 1 0x00 Der w T ir r d a n b s e a im kt i T on L V P r E o F d S uk n ts ic p h e t z b if e is n c u h tz e t . Teil Struktur „Ausgabe Berechtigung Daten“ Tag „Ausgabe Berechtigung Daten“ 1 0x9A Länge „Ausgabe Berechtigung Daten“ 1 0x04 berProdLog SAMSeqNummer 4 Trägt das SAM ein. Struktur„Statusaenderung – Berechtigung“ Tag „Statusaenderung – Berechtigung“ 1 0x8D Länge „Statusaenderung – Berechtigung“ 1 0x18 berLogSeqNummer 2 0x0001 Bei der Ausgabe berBerechtigung_ID (Struktur „Berechtigung_ID“) 6 Relevante Produktnummer für das prodProdukt_ID (Struktur „EFMProdukt_ID“) 4 zen D t e ra u l t e s n c h P la V n o d d ti e ck r e ü t b u e n rg d a O ng R s G w _ e I i D se d n e o s c h des lokalen PV alterStatus.code 1 0x00 Bei der Ausgabe neuerStatus.code 1 0x07 Bei der Ausgabe berSynchronNummer 1 0x01 Bei der Ausgabe MACKontrolle 8 Trägt die Chipkarte ein. Version KKontrolle 1 Trägt die Chipkarte ein. Struktur „Schluesselversionen – Berechtigung“ Tag „Schluesselversionen – Berechtigung“ 1 0x91 Länge „Schluesselversionen – Berechtigung“ 1 0x03 Version KPV 1 Gemäß Vorgabe des PV Version KKVP 1 Gemäß Vorgabe des KVP Version KAUTH 1 0x01 Gemäß Vorgabe VDV-ETS Struktur „Ausgabetransaktionskennung“ Tag „Ausgabetransaktionskennung“ 1 0x99 Länge „Ausgabetransaktionskennung“ 1 0x07 SamSequenznummer 4 Trägt die Chipkarte ein. SAM_ID.samNummer 3 Trägt die Chipkarte ein. Struktur „Infotext“ Tag „Infotext“ 1 0xC7 Länge „Infotext" 1 0x00 Der Infotext wir b d e b n e u i t m zt . TLV EFS nicht

[Seite 16]

4.2 TLV EFS Motics-Ticket

[Seite 17]

4.3 TLV EFS VDV-Barcode

5 Umsetzung der Kontrolle mit Kontrollmodulen

Die Umsetzung der tariflichen Kontrolle mit Kontrollmodulen vor dem Hintergrund der

interoperablen Produktnummern erfolgt wie im separaten Dokument „Deutschlandticket-

mit-PKM_v1.0.pdf“ von FhG IVI beschrieben. Für das Deutschlandticket wird die dort

beschriebene Variante 2 verwendet.

Das Dokument von FhG IVI bezieht sich auf die Version 1.4 der „Technischen

Anforderung Deutschlandticket“, ist aber auch für alle weiteren Versionen des Leitfadens

gültig, wenn sich die Kontrollparameter nicht ändern.