TARIFMODULE NACH PKM - eTicket Deutschland · 2018. 8. 23. · 5.5.4 Layout (optional) 5.6...
Transcript of TARIFMODULE NACH PKM - eTicket Deutschland · 2018. 8. 23. · 5.5.4 Layout (optional) 5.6...
www.eticket-deutschland.de
TARIFMODULE NACH PKM
EINORDNUNG | FUNKTIONEN | VERWENDUNG
Tabellenverzeichnis
Abbildungsverzeichnis
Abkürzungsverzeichnis
1 Einleitung
2 Das Tarifmodul nach PKM im Gesamtkontext
2.1 Bestandteile und Begriffsabgrenzung des (((eTickets
2.2 Die VDV-Kernapplikation
3 Vorstellung des Tarifmoduls nach PKM
3.1 Das Tarifmodul nach PKM im Praxiskontext
3.2 Definition der Schnittstellen im Gesamtrollenkontext
3.3 Grundlegende Vorteile durch das Tarifmodul nach PKM
4 Entwicklung von Einführungstrategien
4.1 Kontrollstrategie
4.2 Produktstrategie
4.3 Verkaufsstrategie
4.4 Testfälle
5 Abbildung und Kontrolle von (((eTickets
5.1 Anwendung Produkteditor
5.2 Dokument „Abbildung und Kontrolle von (((eTickets“
5.3 Abbildung von Produkten
5.3.1 Beschreibung TLV-EFS
5.3.2 Differenzierung zum Barcode-Ticket
03
03
03
04
05
07
08
09
10
11
13
15
15
18
19
21
21
21
23
23
24
24
24
25
25
25
26
26
26
27
28
29
29
30
30
30
30
30
31
32
39
40
41
42
INHALTSVERZEICHNIS
5.4 Räumliche Definition (Wabe, Zone, Raumnummer)
5.5 Beschreibung von Produkten
5.5.1 Referenzberechtigungen
5.5.2 TAG Fahrgast – Kürzungsregel zum Fahrgastnamen
5.5.3 TAG Liste – räumlicher Geltungsbereich
5.5.4 Layout (optional)
5.6 Kontrolle von Produkten
5.6.1 Kontrollmodule und Kundenschnittstelle
5.6.2 Kontrollprozess
6 Ausgangsschnittstellen
6.1 Ausgang / Zieldefinition
6.1.1 Hintergrundsystem
6.1.2 Kontrollgerät personalbedient (Handprüfgerät)
6.1.3 Kontrollgerät selbstbedient (z. B. EKS)
6.1.4 Vertriebsgerät (z. B. Fahrausweisautomat)
6.2 Schnittstellendokument
7 Zusammenfassung
Anlage 1: Checkliste zur Einführung eines Tarifmoduls nach PKM
Anlage 2: Ausschnitt „TLV Gesamtübersicht TAGs“
Anlage 3: Ausschnitt TAG-Nutzung bei Tickets
Wer macht was? Das Rollenmodell der VDV-Kernapplikation
Impressum
VDV ETS – VDV eTicket Service GmbH & Co. KG
VDV-KA – VDV-Kernapplikation
VRR – Verkehrsverbund Rhein-Ruhr
VU – Verkehrsunternehmen
VV – Verkehrsverbund
WEB – Werteinheiten-Berechtigung
03/42
ABKÜRZUNGSVERZEICHNIS(((eTicket Deutschland – Eigenschreibweise für das „elektronische Ticket
Deutschland“
AFB – Automatisierte Fahrberechtigung
AH – Applikationsherausgeber
ALISE – Aktionslistenservice
DL – Dienstleister
EFM – Elektronisches Fahrgeldmanagement
EFS – Elektronischer Fahrschein
EKS – Einstiegskontrollsystem
FAA – Fahrausweisautomat
HGS – Hintergrundsystem
ID – Identifier
ION – Interoperables Netzwerk
KA BOM-Spec – Kernapplikation Basis-Objekt-Modell-Spezifikation
KCEFM – Kompetenzcenter Elektronisches Fahrgeldmanagement
KOSE – Kontroll- und Sperrlistenservice
KVP – Kundenvertragspartner
MDE – Mobile Datenerfassung
NFC – Near Field Communication
ÖPV – Öffentlicher Personenverkehr
ÖV – Öffentlicher Verkehr
PED – Produkteditor
PKM – Produkt- und Kontrollmodul
POB – Post-Paid-Konto-Berechtigung
POI – Point of Interest
PV – Produktverantwortliche
TLV-EFS – Tag-Length-Value Elektronischer Fahrschein
VDV – Verband Deutscher Verkehrsunternehmen
TABELLENVERZEICHNIS
ABBILDUNGSVERZEICHNIS
Tabelle 1: Ausbauvarianten der KA (Vgl.: KA-Vertiefungsseminar Modul 1:
Theoretische Grundlagen & Ausbauvarianten der VDV-KA vom 14./15.11.2017)
Abbildung 1: VDV-KA-Rollenmodell
Abbildung 2: Beispielhafter Aufbau der Ausbauvariante 2 (kombinierbar
mit allen optionalen Ergänzungen);
Abbildung 3: Abgrenzung Tarifmodul nach PKM
Abbildung 4: Abgrenzung Produkt- und Kontrollmodul im Rollenkontext
Abbildung 5: Kontrollstrategie
Abbildung 6: Produktstrategie
Abbildung 7: Verkaufsstrategie Direktverkauf
Abbildung 8: Verkaufsstrategie Verbindungsverkauf
Abbildung 9: Produkteditor
Abbildung 10: Beispiel räumliche Definition im VRR
Abbildung 11: Grundlegende Funktionsweise
14
15
16
17
18
19
21
23
24
26
29
31
reduziert. Zeitintensives, manuelles einpflegen von neuen Tarifdaten in die
Hintergrundsysteme und Gerätesoftware entfällt.
Durch die Implementierung des Tarifmoduls in die Kontrollgeräte kann die
Kontrolle von Tarifprodukten im ganzen Verbund nach einheitlichen Regeln
durchgeführt werden. Beispielsweise wird auch die elektronische Prüfung
von Tarifprodukten mit Mitnahmeregelungen oder personenbezogenen
Fahrberechtigungen durch vorgegebene Kontrollprozesse geregelt. Falls
erforderlich weist das Kontrollgerät je nach Tarifprodukt beispielsweise auf
den notwendigen Nachweis eines Identifikationsmediums (z. B. Personalaus-
weis) hin.
Die Verkehrsverbünde müssen zur Einführung des Tarifmoduls gewisse
Grundvoraussetzungen sicherstellen. Da die Digitalisierung von Tarifproduk-
ten regional sehr unterschiedliche Entwicklungsstufen aufweist, stellt dieses
Dokument eine grundlegende Beschreibung dar, welche Voraussetzungen
zur Einführung des Tarifmoduls nach PKM zu erfüllen sind.
Aufbauend auf einer thematischen Wissensgrundlage und einer Eingliede-
rung des Tarifmoduls nach PKM in die Gesamtthematik (((eTicket Deutsch-
land, soll das vorliegende Dokument als allgemein unterstützender Leitfaden
zur Einführung des Tarifmoduls nach PKM dienen. Eine Einzelfallbetrachtung
findet nicht statt, sodass nicht auszuschließen ist, dass auf Grund tariflicher
Besonderheiten der verschiedenen Verkehrsverbünde und -unternehmen
weitere Informationen benötigt werden.
Im Anhang dieses Dokuments befindet sich eine tabellarische „Checkliste“
(Anlage 1), welche unterstützend zur Einführung verwendet werden kann.
Das Tarifmodul nach PKM, bisher bekannt als PKM (Produkt- und Kontrollmo-
dul), bietet die Möglichkeit, Tarife des Öffentlichen Personenverkehrs (ÖPV)
standardisiert abzubilden. Die Integration in den ganzheitlichen Systempro-
zess der Tarifabwicklung erfolgt durch Implementierung über Schnittstel-
len in die Kontroll- und Vertriebsterminals sowie deren Hintergrundsysteme.
Durch Einführung dieses Standards kann das differenzierte Tarifsystem in
Deutschland erhalten bleiben und in einheitlicher digitaler Form abgebildet
werden.
Die Einführung eines Tarifmoduls nach PKM bietet den Anwendern neben
der einheitlichen Datenstruktur weitere Vorteile. Zusätzlich zu einer verein-
fachten Kommunikation zwischen Produktverantwortlichen und Kunden-
vertragspartnern bzw. Dienstleistern können Tarifdaten zentral verwaltet,
gepflegt und anschließend verteilt werden. Daher können tarifliche Verände-
rungen, Korrekturen und Anpassungen der Tarifdaten deutlich schneller als
bislang umgesetzt werden.
Nach einmaliger Implementierung der Logik der Tarifmodule nach PKM in
die Hintergrundsysteme und Gerätesoftware wird der laufende Anpassungs-
bedarf reduziert. Auch deshalb können beispielsweise zeitlich begrenzte
Veranstaltungstickets einfach und schnell in das Modul integriert und an die
angeschlossenen Systeme verteilt werden. Durch die einheitliche Darstel-
lung und Verarbeitung von Tarifen mit Hilfe der Tarifmodule nach PKM be-
darf es keiner zusätzlichen Änderung der Gerätesoftware. Durch die zentrale
Verarbeitung können neue Tarife problemlos eingebunden und abgeleitete
Produkte verkauft und kontrolliert werden. Der Aufwand für die Integration
sowie für den Verkauf und die Kontrolle von neuen oder geänderten Tarif-
produkten wird durch die Einführung eines Tarifmoduls nach PKM deutlich
04/42
EINLEITUNG1
gung annehmen. Im Unterschied zur elektroni-
schen Hinterlegung im Chip (dynamisch), werden
die Daten beim VDV-Barcode (statisch) optisch
abgespeichert. Der Barcode kann auf einem Smart-
phone in digitaler Form angezeigt oder in Papier-
form ausgedruckt werden. Der elektronische Chip
hat als Nutzermedium gegenüber dem Barcode den
entscheidenden Vorteil, dass dieser nicht nur gelesen,
sondern auch beschrieben werden kann und dement-
sprechend dynamisch ist.
Die signierte Datenstruktur eines Barcodes kann nach Erzeugung nicht mehr
verändert werden, es müsste entsprechend ein neuer Barcode erzeugt wer-
den. Die dynamische Fahrberechtigung kann beispielsweise auf einen Chip
einer Chipkarte oder auch in einem Smartphone mit Nahfeldkommunikation
(NFC-Schnittstelle) integriert werden. Zusätzlich können im Zuge der Inter-
operabilität Nutzerberechtigungen für Leistungen wie Bike- oder Carsharing
auf dem Chip hinterlegt und somit die Bereitstellung multimodaler Angebote
realisiert werden. Dementsprechend können nicht nur ÖPV-Tickets, sondern
auch Berechtigungen anderer Mobilitätskonzepte abgebildet werden. Ent-
scheidend bei der Hinterlegung der Berechtigung auf dem Chip ist die kryp-
tografische Absicherung. Durch eine Signatur der Fahrberechtigung und die
Echtheitsprüfung durch ein Sicherheitsmodul ist der Chip kopiergeschützt.
Statische Fahrberechtigungen in Form eines Barcodes sind hingegen ko-
pierbar, weshalb immer mindestens ein weiteres Kriterium zur Gültigkeits-
überprüfung definiert wird. In der Regel ist dies ein Kontroll-
medium, beispielsweise in Form eines Lichtbildausweises.
Der VDV eTicket Service empfiehlt im Zuge des (((eTicket
Deutschland die elektronisch hinterlegte Fahrberechtigung
auf einem Chip. Dennoch stellt der flächendeckend genutzte VDV-Barcode
eine geeignete Übergangslösung dar. Die Kontrolle der (((eTickets ist durch
Die VDV eTicket Service GmbH & Co KG. (VDV-ETS) ist der Herausgeber
der VDV-Kernapplikation als Standard für die Abbildung elektronischer
Tickets. Im Zuge der weiter voranschreitenden Digitalisierung wird das
(((eTicket perspektivisch den auf Papier gedruckten Fahrschein ablösen und
die Fahrberechtigung selbst in die digitale Welt übertragen. Das gesamte
(((eTicket-System basiert auf der VDV-Kernapplikation (KA) und dem damit
verbundenen KA-Rollenmodell, welches zum besseren Verständnis des Ge-
samtsystems im Verlaufe dieses Kapitels (Vgl. Abbildung 1) dargelegt wird1.
Grundsätzlich gibt es verschiedene Arten von Nutzermedien, auf denen eine
Fahrberechtigung bzw. ein Ticket hinterlegt werden kann. Die Berechtigung
kann einerseits eine statische und andererseits eine dynamische Ausprä-
DAS TARIFMODUL NACH PKM IM GESAMTKONTEXT2
KUNDE
KUNDEN-VERTRAGSPARTNER
PRODUKT-VERANTWORTLICHER
APPLIKATIONS-HERAUSGEBER
Abbildung 1: VDV-KA-Rollenmodell Quelle: Handbuch (((eTicket Deutschland (VDV eTicket Service)
DIENSTLEISTER
TicketTarif
1Vgl. https://oepnv.eticket-deutschland.de
05/42
eine elektronische Prüfung und das damit einhergehende Erkennen auf
Echtheit deutlich zuverlässiger als die Prüfung eines Papiertickets und stellt
so einen wichtigen Baustein zur Einnahmesicherung der Verkehrsverbünde
und –unternehmen dar.
Das VDV-KA-Rollenmodell beschreibt die Interaktion zwischen den am
Gesamtsystem (((eTicket beteiligten Rollen und deren Aufgaben. Jeder
Beteiligte nimmt eine oder mehrere Rollen im Gesamtsystem ein.
Das System ist fokussiert auf den Kunden, welcher seine Tickets beim
Kundenvertragspartner (KVP) erwerben kann.
Die Rolle des Kundenvertragspartners übernehmen in der Regel Verkehrs-
unternehmen (VU). Diese vertreiben die Tickets im personenbedienten (z.B.
Kundencentern oder Vertriebsstellen) oder maschinellen (Fahrausweisauto-
maten oder Handyticket) Verkauf und schließen dadurch einen entsprechen-
den Vertrag mit dem Kunden. Im Vertrag sind Rahmenbedingungen wie bei-
spielsweise die Vertragsart sowie die gewählte Zahlungsvariante enthalten.
Nach dem Erwerb und der Speicherung der elektronischen Fahrberechti-
gung auf einem Nutzermedium ist der Kunde berechtigt, die für das Ticket
vorgesehenen Verkehrsmittel zu nutzen und die entsprechende ÖPV-Leis-
tung in Anspruch zu nehmen.
Die Aufgabe der Beförderung übernimmt dann der Dienstleister (DL).
Dienstleister sind auch VU, welche nicht zwangsläufig Tickets verkaufen,
aber mit der entsprechenden Hardware kontrollieren und auf Gültigkeit prü-
fen. Dies kann sowohl mit personalbedienten Prüfgeräten, als auch durch
Einstiegskontrollsysteme (EKS) geschehen.
Die Rolle des Produktverantwortlichen (PV) übernimmt in den meisten
Fällen ein Verkehrsverbund, zu dessen Kernaufgaben in der Regel die Ent-
wicklung, Tarifierung und Pflege des Ticketsystems gehört. Der PV stellt den
Dienstleistern sowie den Kundenvertragspartnern die zum Vertrieb und zur
Kontrolle benötigten Daten bereit.
Die übergeordnete Rolle des Applikationsherausgebers (AH) übernimmt
im Gesamtsystem (((eTicket Deutschland ausschließlich die VDV eTicket
Service GmbH & Co KG. Der Applikationsherausgeber ist für den Betrieb des
Gesamtsystems verantwortlich. Für die Teilnahme an (((eTicket Deutschland
muss zwischen der VDV eTicket Service GmbH & Co KG und dem jeweiligen
PV, KVP und DL ein Vertragsverhältnis bestehen.
Weitere Aufgaben des Applikationsherausgebers sind das Zertifizieren der
einzelnen Komponenten, die Koordination und Bereitstellung des Sicher-
heitsmanagements und die Registrierung der am Gesamtsystem teilneh-
menden Organisationen. Zusätzlich nimmt der Applikationsherausgeber
über den Kontrollservice (KOSE) z.B. Sperraufträge entgegen und stellt wie-
derum Sperrlisten, beispielsweise für ungültige Fahrberechtigungen, bereit.
Das Gesamtsystem (((eTicket Deutschland beruht auf einem kontinuier-
lichen und lückenlosen Datenaustausch zwischen den am Gesamtprozess
beteiligten Rollen2.
KVP
DL
PV
AH
Vertreiben Tickets im Verkauf &
schließen Vertrag mit Kunden
Kontrollieren Tickets mit Prüf-
geräten und EKS auf Gültigkeit
Entwicklung, Tarifierung und
Pflege des Ticketsystems
für den Betrieb des Gesamt-
systems verantwortlich
2Vgl. https://oepnv.eticket-deutschland.de
06/42
ments oder Einzeltickets der Fall sein. Es können je nach Tarifmodell z. B.
der Fahrschein (räumlich, persönlich) oder auch die Reservierung (Fahrzeug
und Platz) auf dem EFS hinterlegt sein. Im Gegensatz zum EFS werden bei
der AFB die Nutzungsdaten erst während der Fahrt ermittelt und erfasst.
Der Nutzer kann sich beispielsweise in einem Check-In/Check-Out-System
(CiCo) bei Fahrtbeginn mit dem (((eTicket einchecken und beim Verlassen
des Fahrzeugs bzw. Fahrtende wieder auschecken. Anhand von Fahrtpara-
metern wie Zeit und Strecke oder auch weiterer Faktoren erfolgt dann die
Preisfindung. Zum Bezahlen stehen dem Nutzer dann drei Varianten der
AFB zur Verfügung. Auf der einen Seite ein vom KVP geführtes Konto, wel-
ches als Pre-Paid- (PEB: Pre-Paid-Konto-Berechtigung) oder Post-Paid-
Konto (POB: Post-Paid-Konto-Berechtigung) ausgeprägt werden kann. Die
finanzielle Regulierung der ÖPV-Leistungen wird beim Post-Paid-Konto
nach Inanspruchnahme selbiger vorgenommen und erfolgt über ein dem
KVP bekanntes Kundenkonto. Bei einem Pre-Paid-Konto findet der tatsäch-
liche Geldfluss vor der Inanspruchnahme der ÖPV-Leistung statt. Dieses
Konto ist nur mit der Applikationsnummer des Nutzermediums verknüpft
und kann somit auch anonym geführt werden. Die dritte und letzte Variante
der AFB stellt die Werteinheitenberechtigung (WEB) dar. Hierbei ist in der
Applikation auf dem Nutzermedium ein Werteinheitenspeicher integriert.
Somit erfolgt die Abrechnung nicht über ein vom KVP geführtes Konto. Die
Nutzung für den Kunden erfolgt bei dieser Variante der Bezahlung dement-
sprechend anonym.
Bei In-/Out-Systemen wird der Fahrpreis über den Einstieg (Check-In
oder Be-In) und den Ausstieg (Check-Out oder Be-Out) sowie der zurück-
gelegten Strecke errechnet, ähnlich wie bei einer Taxinutzung. Der Preis
wird im Fall der WEB-Variante während der Fahrt ermittelt, bei der POB/
PEB- Variante findet die Preisermittlung erst nach der Reise statt. (((eTicket
Deutschland ist durch die vielen möglichen Ausbauvarianten sehr flexibel
und kann dabei helfen, die ÖPV-Nutzung attraktiver zu gestalten.
Als (((eTicket wird hauptsächlich ein in einem
Chip gespeichertes Ticket (eine Berechti-
gung) zur Nutzung des ÖPV bezeichnet.
Auf einem Chip können genauso mehrere
Berechtigungen gespeichert werden. Die-
se spiegeln die geschlossenen Beförde-
rungsverträge des Kunden mit dem KVP wider.
Die „Berechtigung“ ist die technische Bezeichnung des Daten-
satzes für ein ÖPV-Ticket, mit welchem der Kunde eine Leistung des ÖPV
in Anspruch nehmen kann. Sie beinhaltet standardisierte Bereiche wie die
Identifikationsnummer (ID) von Berechtigung und (Tarif-)Produkt, den
Status der Berechtigung (nicht gesperrt oder gesperrt), die zeitliche Gül-
tigkeit sowie verschiedene Schlüssel zur Realisierung des Sicherheitsma-
nagements. Die auf der Berechtigung zu hinterlegenden Ticketinhalte, z.B.
zur Abbildung der räumlichen Gültigkeit, sind jedoch nicht standardisiert
und werden durch den PV definiert, da diese maßgeblich von dem jeweili-
gen Tarifmodell abhängen. Außerdem wird die Art der Berechtigung bzw.
die Art des (((eTickets durch die Tarifdaten bestimmt.
Hierbei gibt es zwei übergeordnete Varianten. Zum einen den Elektroni-
schen Fahrschein (EFS) und zum anderen die automatische Fahrberech-
tigung (AFB) bzw. Bezahlberechtigung. Der EFS unterscheidet sich von
der AFB (automatischen Fahrberechtigung) im Grunde genommen darin,
dass bei der Ausgabe der Preis sowie der räumliche und zeitliche Geltungs-
bereich des EFS bereits feststehen. Dies kann beispielsweise bei Abonne-
2.1 BESTANDTEILE UND BEGRIFFSABGRENZUNG DES (((eTICKETS
07/42
Die VDV-Kernapplikation (VDV-KA) ist der technische Standard von
(((eTicket Deutschland. Die VDV-KA ist als „Kern aller Chipkartenapplikatio-
nen3“ auf den verschiedenen Nutzermedien aufgebracht. Die VDV-KA stellt
die Basis für alle Ausführungen und Varianten des (((eTickets dar.
Der VDV-KA-Standard beschreibt das Datenmodell und die Schnittstellen
zwischen den teilnehmenden Systemen und gewährleistet somit die Inter-
operabilität der verschiedenen Systeme. Zu beachten ist, dass es sich hier-
bei ausschließlich um einen technischen, nicht jedoch um einen tariflichen
Standard handelt4.
Für die VDV-KA wurden grundsätzlich drei verschiedene Ausbauvarianten
(Tabelle1) definiert:
Der in Abbildung 2 beispielhaft dargestellte Aufbau der KA-Ausbauvari-
ante 2 beinhaltet, dass die momentan als Papierfahrschein ausgegebenen
ÖPV-Tickets als EFS auf dem Nutzermedium (z. B. Chipkarte) ausgegeben
und gespeichert werden können („(((eFahrschein“).
Darüber hinaus besteht bei dieser Variante die Möglichkeit, den EFS elek-
tronisch zu kontrollieren („(((eKontrolle“). Außerdem werden hierbei die
drei Zahlungsmethoden POB/PEB und WEB akzeptiert. Optionen wie bei-
spielsweise ein Tarifmodul nach PKM (ehemals Produkt- und Kontrollmodul
(PKM)) oder eine Multi-Berechtigung (Multi BER) können je nach Ausbau-
variante variabel mit aufgenommen werden.
DIE VDV-KERNAPPLIKATION2.2
Ausbauvariante 1:
Ausbauvariante 2:
Ausbauvariante 2a:
Ausbauvariante 2b-1:
Ausbauvariante 2b-2:
Ausbauvariante 3:
Ausbauvariante 3a-1:
Ausbauvariante 3a-2:
EFS + POB/PEB + WEB
EFS
EFS + POB/PEB
EFS + WEB
(((eBezahlen
(((eFahrschein / (((eKontrolle
(((eFahrschein Abo / (((eKontrolle
(((eFahrschein / (((eKontrolle
(((eFahrschein / (((eKontrolle
IN-OUT mit POB/PEB + WEB
Check-In/Check-Out räumlich begrenz mit POB/PEB
Check-In/Check-Out räumlich begrenz mit WEB
Tabelle 1: Ausbauvarianten der KA (Vgl.: KA-Vertiefungsseminar Modul 1: Theoretische Grundlagen & Ausbau-varianten der VDV-KA vom 14./15.11.2017)
(((eFAHRSCHEIN/(((eKONTROLLE EFS + AKZEPTANZ VON POB/PEB + WEBAbbildung 2: Beispielhafter Aufbau der Ausbauvariante 2 (kombinierbar mit allen optionalen Ergänzungen); (Quelle: KA-Vertiefungsseminar Modul 1: Theoretische Grundlagen & Ausbauvarianten der VDV-KA vom 14./15.11.2017)
tariflicheBesonder-
heiten
StBKA
eFahrscheinAbo/Jahres-
karteeKontrolle
V2a
eFahrscheineBezahlenPOB/PEBeKontrolle
V2b-1
eFahrscheineBezahlen
WENeKontrolle
V2b-2
AktM
Tarif-modul nach PKM
MultiBER
3Handbuch (((eTicket Deutschland (VDV eTicket Service)4Vgl. KA-Vertiefungsseminar Modul 1: Theoretische Grundlagen & Ausbauvarianten der VDV-KA vom 14./15.11.2017
08/42
Je nach Anwendungsfall kann ein PV entscheiden, welche Ausbauvarian-
te(n) angewendet werden sollen. Zusätzlich zu diesen Ausbauvarianten
stehen optionale Ergänzungen zur Verfügung. Je nach VDV-KA-Ausbauvari-
ante können folgende Optionen ergänzt werden:
Bei der Anwendung der Multi-Berechtigung wird das Sicherheitsmanage-
ment im Vorfeld und nicht bei der Fahrscheinausgabe durchgeführt. Aus
diesem Grund kann eine schnellere Ausgabe eines (((eTickets als EFS er-
möglicht werden. Dies kann beispielsweise bei einem Kauf eines EFS im Bus
von Vorteil sein, um die Transaktionszeit für das Aufbringen der Fahrberech-
tigung zu verringern.
Bei der optionalen Ergänzung „Aktionsmanagement“
ist der KVP in der Lage, die Ausgabe, Rücknah-
me oder eine Entsperrung eines (((eTickets als
EFS flexibel zu gestalten. Bestimmte Vorgänge
können als sogenannte Aktionen an einem Ver-
triebsterminal beauftragt werden. Dieses Ver-
triebsterminal hat Onlinezugriff auf das zuständige
KVP-System, aber keine Zugriffsmöglichkeit auf das
Nutzermedium. Die durch das System beauftragten Aktionen werden auto-
matisch ausgeführt sobald das Nutzermedium mit einem zur Ausführung
dieser Aktionen vorgesehenen Terminal in Kontakt kommt. Hierzu werden
die Aktionen in einer Aktionsliste (ALISE) gesammelt und an die relevanten
Vertriebsterminals verteilt. Somit bieten die ALISE für den KVP den Vorteil,
z.B. Tarifänderungen über alle Terminals verteilen zu können. Der Kunde pro-
fitiert davon, dass er bezüglich Datenänderungen kein Servicecenter mehr
aufsuchen muss, da diese beim nächsten Kontakt seines Nutzermediums mit
einem Terminal automatisch abgewickelt werden.
Bei der Option „Tarifliche Besonderheiten“ werden besondere Eigenschaf-
ten von Tarifen berücksichtigt. Dies kann beispielsweise die Anrechnung
eines EFS auf eine POB, PEB oder WEB sein.
Der bisher bekannte Begriff „Produkt- und Kontrollmodul“ ist durch „Tarif-
modul nach PKM“ ersetzt worden. Ausschließlich die Tarifmodule nach PKM
stehen bei allen Ausbauvarianten der VDV-KA optional zur Verfügung.
Die grundlegende Aufgabe des Tarifmoduls nach PKM ist es, Tarifmodelle
sowie Vertriebs- und Kontrollregeln in einer standardisierten Datenstruk-
tur abzubilden. Diese Daten werden durch den jeweiligen PV gepflegt und
an alle KVP- und DL-Hintergrundsysteme übertragen, die sie wiederum für
die jeweilige Vertriebs- und Kontrollinfrastruktur bereitstellen. Somit können
einheitliche, leichte und schnell zu aktualisierende Datenstände auch in he-
terogenen Infrastrukturen realisiert werden.
Durch die einheitliche Abbildung der Tarife wird ein standardisierter Rahmen
geschaffen und zentral gepflegt ohne die Tarifvielfalt zu beschränken. Die
Interpretation des Tarifmoduls nach PKM durch die Software in den Hinter-
grundsystemen und Terminals stellt eine Grundvoraussetzung für die erfolg-
reiche Einführung des Tarifmoduls nach PKM dar. Das folgende Kapitel soll
das Tarifmodul nach PKM zunächst grundsätzlich in einen verständlichen
Gesamtkontext eingliedern und die vorliegenden Schnittstellen des Tarifmo-
duls mit den unterschiedlichen Rollen erläutern. Bevor die Ausarbeitung ins
Detail geht und die Strukturen genauer beschrieben werden, erfolgt die Ein-
ordnung in einen Praxiskontext sowie die Abgrenzung zu anderen Systemen.
• Multi-Berechtigung
• Aktionsmanagement
• Statische Berechtigung
• Tarifliche Besonderheiten
• Tarifmodule nach PKM
VORSTELLUNG DES TARIFMODULS NACH PKM3
09/42
folgende Abbildung 3 dienen. Den Mittelpunkt dieser Abbildung und auch
des vorliegenden Dokuments stellt das Tarifmodul nach PKM als eigenstän-
diges Objekt dar. Inhalt des Moduls sind (Tarif-)Produkte, Preise, Tarif- und
Kontrollregeln. Mit Hilfe dieser Inhalte lässt sich ein ÖPV-Ticket eindeutig
zuordnen und mit entsprechenden Kontroll-Terminals auf räumliche und
zeitliche Gültigkeit überprüfen. Dennoch müssen Informationen aus anderen
Systemen in das Modul eingespeist werden um die genannten Funktionen zu
gewährleisten. Die ÖPNV-nahen Anwendungen sind im unteren Bereich der
Abbildung platziert.
Im Mittelpunkt des Tarifmoduls nach PKM steht die Implementierung des
Moduls in Vertriebs- und Kontrollgeräte sowie deren Hintergrundsysteme
und die damit einhergehende Bereitstellung von aktuellen Tarif- und Kon-
trolldatensätzen. Zum allgemeinen Verständnis der Aufgaben des Tarifmo-
duls und mit welchen Systemen aus dem ÖPV das Modul korreliert soll die
DAS TARIFMODUL NACH PKM IM PRAXISKONTEXT 3.1
Abbildung 3: Abgrenzung Tarifmodul nach PKM (Quelle: Projektskizze Tarifmodul nach PKM; VDV eTicket Service)
-Zentrales Tarifhaltestellenverzeichnis-Zentrales Haltestellenverzeichnis (DELFI)
Verbindungsauskunft(Hacon / Mentz)
-Tarifserver
Tarifprodukte Preise Tarifregeln Kontrollregeln
ÖPNV-nahe Anwendungen
BIKESHARING CARSHARINGONLINEABFRAGE
TARIFMODULE
-Tarife für BikeSharing-Ausleihstellen/Abstellanlagen
für BikeSharing
-Tarife für CarSharing-Ausleihstellen/Parkplätze
für CarSharing
externe Kontingente/Zähler z.B. für rabattierte Tickets bzw. Aktionsangebote, Fahrzeug-Up-grades auf eine andere Fzg.-Kategorie, extern gespeicherte Nutzungshistorien von Kunde (z.B. individuelle Rabattzähler, aktuell noch verfügbare Freiminuten/Freikilometer), externe Stand-ortermittlung bei free floating Flotten, extern bereitgestellte Preisparameter von Bike-/Car-/
RideSharing-Angeboten (z. B. zurückgelegte Entfernung)
CLEARINGHALTESTELLENVERZEICHNISSE FAHRPLANAUSKUNFTSSYSTEME
10/42
notwendig sein kann, andererseits aber auch das mögliche Ausmaß an Infor-
mationsflüssen sowie die Beteiligung und gegebenenfalls auch die Abhän-
gigkeit von anderen Systemen.
Wie die Schnittstellen zwischen den beteiligten Rollen definiert sind und
welche genaue Aufgabe die Rollen erfüllen soll im Folgenden dargestellt
werden. Zusätzlich wird aufgezeigt, an welchen Schnittstellen das Produkt-
und an welchen Schnittstellen das Kontrollmodul ansetzt sowie über welche
Schnittstellen und Wege die Kommunikation zwischen den Rollen bezüglich
der verschiedenen Aufgabenbereiche stattfindet.
Den Gesamtkontext der Interaktion zwischen den einzelnen Rollen sowie die
Integration des Tarifmoduls nach PKM wird in der Abbildung 4 dargelegt.
Das rollenneutrale Tarifmodul nach PKM besteht im weitesten Sinne aus zwei
Modulen: dem Produkt- und dem Kontrollmodul. Eine gewisse Abhängigkeit
zwischen beiden Teilmodulen ist dadurch gegeben, dass das Produktmo-
dul die Tarife und Produkte definiert, welche das Kontrollmodul letztendlich
kontrolliert und auf Gültigkeit überprüft. Demnach sind die beiden Teilmodu-
le als Tarifmodul nach PKM miteinander verbunden und schließen den prak-
tischen Gesamtprozess zwischen Vertrieb und Kontrolle von Tarifprodukten
ab.
Der PV stellt die Ausgangsbasis dar. Er ist dafür zuständig, das Tarifmodul
nach PKM so zu definieren, dass alle relevanten Tarife inklusive ihrer Tarifbe-
stimmungen und Kontrollregeln hinterlegt sind. Der PV stellt die eingepfleg-
ten Tarife und Regeln in Form einer Datei (gem. der VDV-KA Spezifikation)
für die KVP und DL zur Verfügung.
Das Tarifmodul nach PKM bündelt einen Pool von Informationen und Daten-
sätzen an einer zentralen Stelle. Aus Fahrplanauskunftssystemen kann das
Tarifmodul nach PKM die Datensätze zu dem für eine Fahrtstrecke hinter-
legten Preis beziehen und diese Daten nutzen. Das Haltestellenverzeichnis
(beispielsweise ein zentrales Haltestellenregister für Deutschland) stellt dem-
entsprechend die Haltestellen und ihre Zuordnung zu einem Tarifpunkt (z. B.
einer Tarifzone) für die Tarif- und Preisbildung bereit.
Das Clearing regelt die Abrechnung von Leistungen aus fremden Tarifre-
gionen. Zukünftig sollen auch Tarifleistungen anderer VU von einem KVP
angeboten werden können. Dies ist relevant, wenn der Kunde Tickets für Ta-
rifregionen anderer VU nutzt, diese jedoch bei dem KVP bezahlt, bei dem er
ein Kundenkonto angelegt hat. Das Clearing sorgt dementsprechend dafür,
dass die Leistungen aus fremden Tarifregionen untereinander abgerechnet
werden können.
Die Bereitstellung von Datensätzen aus verschiedenen ÖPV-nahen Anwen-
dungen wird benötigt, um Produkte und Preise für ÖPV-Leistungen im Ta-
rifmodul nach PKM final zu definieren, aber auch, um diese nach Ausga-
be kontrollieren zu können. Während die Datensätze aus Fahrplanauskunft,
Clearing und Haltestellenverzeichnis über ÖPNV-nahe Anwendungen einge-
speist werden, lassen sich die Informationen im oberen Teil der Abbildung
3 über Onlineabfragen ermitteln. Im Zuge der Inter- und Multimodalität be-
steht die Möglichkeit, verschiedene weitere Dienste in das Gesamtsystem
(((eTicket mit einfließen zu lassen, insbesondere bei der Tarif- und Produkt-
bildung. Die Onlineabfragen sind beispielsweise für Sitzplatzreservierungen
in Zügen notwendig oder bei den verschiedensten Sharing-Modellen, um
aktuelle Informationen über Preise, Preisparameter (Entfernungseinheiten)
oder Ausleihstellen bzw. Parkplätze für Sharing-Objekte zu erhalten5.
Der grobe Überblick über das Tarifmodul nach PKM und die Abgrenzung
zu anderen Systemen verdeutlicht einerseits die Informationsvielfalt, die für
die Generierung von Tarifprodukten und den dazugehörigen Kontrollregeln
5Vgl. Projektskizze Tarifmodul nach PKM (VDV eTicket Service)
DEFINITION DER SCHNITTSTELLEN IM GESAMTROLLENKONTEXT3.2
11/42
gebenen Fahrberechtigungen zur Verfügung. In Form von Kontrollmodulen
werden die Kontrolldaten für die entsprechenden Tarifprodukte an die DL
verteilt. Der Prozess findet analog zu dem des Produktmoduls statt. Die vom
DL benötigten PV-Kontrollmodule werden vom DL in einem DL-Kontroll-
modul zusammengeführt und um die eigenen Kontrollregeln ergänzt. Dabei
fließen auch die vom KVP über seinen Haustarif erzeugten Kontrollmodule
mit ein. Hiermit können die DL-Terminals (z. B. personalbediente Prüfgeräte
oder ein EKS) nach Implementierung des DL-Kontrollmoduls das vollständi-
ge Produktsortiment auf räumliche und zeitliche Gültigkeit überprüfen.
Ein Tarifmodul nach PKM kann unabhängig von einem (((eTicket-Projekt
eingeführt werden. Für den ausnahmslosen Umgang mit Papiertickets muss
dann kein Kontrollmodul definiert werden. Ein Kontrollmodul ist nur notwen-
dig, wenn Tickets auf elektronischem Wege auf ihre Gültigkeit geprüft werden.
Der KVP empfängt die Produktmodule von allen PV, deren Tarife er verkauft
und führt diese in ein KVP-Produktmodul zusammen. Das KVP-Produktmo-
dul kann außerdem um die Haustarife des KVP inklusive aller nötigen Kont-
rollregeln ergänzt werden, sodass der KVP über ein vollständiges KVP-Pro-
duktmodul für seinen Vertrieb verfügt.
Das vollständige KVP-Produktmodul wird anschließend in die KVP-Systeme
importiert. Seine Daten werden in Verbindung mit den Daten aus dem jewei-
ligen KVP-Terminal (z. B. aktuelles Datum), dem Dialog zwischen Kunde und
Terminal (z. B. Auswahl des gewünschten Fahrausweises) und den Daten
aus dem Nutzermedium verarbeitet, um im Ergebnis die gewünschte Fahr-
berechtigung erzeugen zu können.
Der PV trägt nicht nur für die vertriebsseitigen Tarifdaten die Verantwortung,
sondern stellt auch die Informationen zur Kontrolle der als (((eTicket ausge-
Abbildung 4: Abgrenzung Produkt- und Kontrollmodul im Rollenkontext (Quelle: Fraunhofer-Institut für Verkehrs- und Infrastruktursysteme IVI)
1 23
c4
56
b7
8 9d
ö0
äk
KUNDENVERTRAGS-PARTNER (KVP)
KVP-PRODUKTMODUL
PV-PRODUKTMODUL
PV-PRODUKTMODUL
TICKETAUSGABE
PV-PRODUKTMODUL PV-KONTROLLMODUL
DL-KONTROLLMODUL
PV-KONTROLLMODUL
PV-KONTROLLMODUL
TICKETKONTROLLE
PRODUKTVER-ANTWORTLICHER
(PV)
DIENSTLEISTER(DL)
12/42
Im Allgemeinen sind die Nachteile vieler aktueller Strukturen einfach be-
schrieben. Das Problem stellt die Verwendung und das Exportieren von
alten, (PV-)spezifischen Datenformaten dar. Es gibt durchaus Systeme, die
Daten zentral zusammenführen. Diese verwenden aber nicht den VDV-KA-
Standard und basieren auf verschiedenen anderen Formaten oder haben
abweichende bzw. geringere Leistungsumfänge als der VDV-KA-Standard.
Beispielsweise muss eine Tarifanpassung bei jedem KVP-System einzeln
durchgeführt und verarbeitet werden, anstatt die Informationen in einem
zentralen System „mit einem Klick“ zu bearbeiten6.
Durch die Integration des Tarifmoduls nach PKM und die damit einher-
gehende Umsetzung des VDV-KA-Standards liegt ein Fokus auf der Ver-
einheitlichung der Tarifdatenstruktur. Ein mögliches Werkzeug hierfür
ist der sogenannte „Produkteditor“, welcher im Zuge des Kapitels 5 „Ab-
bildung und Kontrolle von (((eTickets“ kurz dargestellt wird. Durch die
Eingabe der Tarife in den Editor wird eine Tarifdatenbank mit entsprechen-
den Parametern zur Tariffindung versorgt. Der Export aus dem Editor wird
als XML-basiertes Tarifmodul nach PKM durchgeführt und stellt im Ergebnis
ein standardisiertes und einheitliches Datenformat nach VDV KA-Standard
dar. Dabei ist der Schlüsselaspekt, dass die XML-Dateien nun die komplette
Der heutige Standard „Tarifmodule nach PKM“ wird nicht von allen PV mit
Produkt- und Kontrollmodulen bei der Einführung und Umsetzung von
(((eTickets verwendet. Datenaustausch und –pflege erfolgen zum Teil in
proprietären und untereinander inkompatiblen Formaten und Systemen. Der
heutige Ist-Zustand stellt sich wie folgt dar:
GRUNDLEGENDE VOR-TEILE DURCH DAS TARIFMODUL NACH PKM
3.3
» gleiche Tarife mit abweichenden Beschreibungen
» unterschiedliche Methoden der Tarifaufzeichnung
» keine standardisierten Datenstrukturen
» Implementierung der Daten unternehmensabhängig (heterogene
Systemlandschaft)
» Vorgaben der PV/KVP für Integration der Daten in die Software-
systeme unvollständig und ungenau
» Tarifänderungen ohne Tarifmodul nach PKM beim KVP:
» jeder Vertriebsweg (Terminal, Kundencenter, Online-Shop etc.) muss
individuell mit neuen Tarifdaten versorgt werden, keine
» zentrale Datenverteilung möglich
» hoher manueller Aufwand
» deutlich erhöhte Fehleranfälligkeit
» Tarifänderungen ohne Tarifmodul nach PKM beim PV:
» Dateneingabe der Tarifprodukte in unterschiedliche Systeme
keine zentrale Datenpflege
» hoher Aufwand und erhöhte Fehleranfälligkeit
» Dateiformate und Dateitiefe müssen je nach KVP auf unterschied-
liche Art bereitgestellt werden
6Vgl. Tarifmodule nach PKM – Vortrag im Rahmen des Anwendertages vom 07.11.2017 (VDV eTicket Service)
13/42
fachliche Verarbeitungslogik für Tarifdaten enthalten können. Durch die ma-
schinenlesbaren Steueranweisungen können mit den XML-Dateien sowohl
komplexe Verkaufs- und Kontrollregeln, als auch Algorithmen zum Erzeu-
gen von Druck- und Anzeigetexten in einem Tarifmodul abgebildet werden.
Zusätzlich können 2D-Barcodes durch einen Ticketgenerierer erzeugt sowie
die Abläufe an Bedienschnittstellen des Terminals mit Hilfe der Fachlogik in
einem Tarifmodul abgebildet werden.
Das Tarifmodul nach PKM kann die oben dargestellte Problematik und Feh-
leranfälligkeit durch Implementierung eines zentralen Systems auf ein Mini-
mum reduzieren. Durch die Einführung bieten sich die folgenden Vorteile:
Das Tarifmodul nach PKM bietet vor allem durch die ein-
heitlichen Datenstrukturen sowie die zentrale Verwaltung
und Bearbeitung der Tarifdaten enorme Vorteile. Die Abläufe
der Änderung und Verteilung von Tarifdaten durch den PV werden optimiert
und das Fehlerpotential durch die einseitige Anpassung und Verteilung
der Daten minimiert. Durch die zentrale Datenpflege können Korrekturen
schnellstens durchgeführt werden und die Verteilung der aktualisierten Da-
ten durch ein gesichertes Netzwerk zeitnah stattfinden. Durch die Anwen-
dung der XML-Datenstruktur in der VDV-KA werden alle Datenstrukturen
standardisiert. Wenn die Hintergrundsysteme und Terminals des KVP den
KA-Standard unterstützen, bietet sich eine einfache Möglichkeit zur Aktua-
lisierung der Datenstände. Das Tarifmodul nach PKM bietet somit eine stan-
dardisierte Lösung und einen vordefinierten Ablauf zwischen den einzelnen
Rollen und optimiert sowohl den Datenfluss als auch
die Datenqualität.
Die vorangegangen Kapitel 2 und 3 dienen dem all-
gemeinen Verständnis und der Eingliederung des
Tarifmoduls nach PKM. Sie bilden die grundlegen-
de Wissensbasis für die folgenden Kapitel, die unter
dem Überbegriff der Integration eines Tarifmoduls
nach PKM stehen. Mit Abschluss dieses Kapitels ist
das notwendige theoretische Fundament gelegt. Nachfolgend werden die
notwendigen Voraussetzungen und Vorbereitungen für die Einführung des
Tarifmoduls nach PKM als PV, KVP und DL beleuchtet. Dies betrifft sowohl
die Visualisierung von Strategien als auch die technische Definition von ver-
schiedenen mit dem Tarifmodul nach PKM verbundenen Prozessen.
7Vgl. Tarifmodule nach PKM – Vortrag im Rahmen des Anwendertages vom 07.11.2017 (VDV eTicket Service)8Vgl. VDV-Kernapplikation Einführung EFS-Produkt- & EFS-Kontrollmodule (VDV eTicket Service; Stand: 10.05.2016)
1. standardisierte und einheitliche Datengrundlage
2. vollständige und zentrale Datenverwaltung „single point of truth“
3. geringerer Aufwand bei der Einarbeitung von neuen Mitarbeitern
» Tarifänderungen mit Tarifmodul nach PKM beim PV:
» zentrale Verwaltung der Tarifdaten
» geringer manueller Aufwand der Datenpflege
» zentrale Verteilung an alle KVP/DL (z. B. Datenverteilung durch
eine Datendrehscheibe wie beispielsweise das Interoperable
Netzwerk (ION) oder auch Webservices mit Download-Funktionen)
» Tarifänderungen mit Tarifmodul nach PKM beim KVP:
» Quelle der Tarifdaten ist zentralisiert und damit eindeutig
» Tarifdaten müssen nicht manuell eingegeben werden
» Datenübernahme mit geringem Aufwand verbunden
» nur die Haustarife müssen ggf. im Tarifmodul angepasst werden
» simple und schnelle Beschaffung der Daten über Datendrehscheibe
(Webservices)7,8
FAZIT
14/42
Die in Kapitel 3 beschriebenen Teilmodule erfordern je nach Rolle unter-
schiedliche Strategien zur Einführung. Im Normalfall übernimmt der PV die
Entwicklung einer Produkt- und Kontrollstrategie. Die Verkaufsstrategie
wird genau wie die Produktstrategie dem Produktmodul zugeordnet. Die
Kontrollstrategie ist dementsprechend dem Kontrollmodul zuzuordnen. Die
Visualisierung der einzelnen Strategien bietet eine abstrakte Vorlage zur
technischen Umsetzung und Eingabe in ein Tool (z. B. „Produkteditor“) zur
Erstellung von Tarifmodulen nach PKM. Anhand der Ausprägung des Tarifs
aus den Strategien lassen sich Testfälle ableiten, welche Ergebnisse bei der
Vorlage des jeweiligen Tickets erzielt werden sollen. Die Strategien werden
anschließend in Form der Produkt- bzw. Kontrollmodule realisiert, auf die
Terminals verteilt und dementsprechend von der Software des KVP-Termin-
als (z. B. einem Automat) interpretiert. Während eine Verkaufsstrategie tech-
nisch nicht zwingend notwendig ist, muss für ein DL-Kontrollmodul sowie
ein KVP-Produktmodul eine Kontroll- bzw. Produktstrategie definiert sein.
Der PV übernimmt die Definition der Kontrollstrategie. Er hat sowohl die
Verantwortung für die verschiedenen (Tarif-)Produkte (vgl. Produktstrate-
gie), als auch für die damit verbundenen Kontrollregeln. Eine Ergänzung
oder Erweiterung der vom PV erstellten Kontrollstrategie durch den DL ist in
der Regel nicht notwendig. Um einen einheitlichen Ablauf des Kontrollvor-
ENTWICKLUNG VON EIN-FÜHRUNGSSTRATEGIEN4 gangs auf allen Terminals zu gewährleisten, wird davon abgeraten, die Kon-
trollstrategie durch den DL anzupassen. Informationen wie beispielsweise
zusätzliche Haltestellenpunkte müssen dem Kontrollmodul ggf. hinzugefügt
werden.
Die Kontrollstrategie wird prinzipbedingt ausschließlich für elektronische
Fahrberechtigungen erstellt. Die Kontrollstrategie legt alle Prüfschritte zur
Feststellung der räumlichen und zeitlichen Gültigkeit einer Berechtigung
fest. Diese Prüfschritte bestehen aus sog. Fachfunktionen, die durch das
DL-Terminal in der festgelegten Reihenfolge ausgeführt werden. Hierzu
zählen folgende Schritte:
1. Produktprüfung
Bei der Produktprüfung wird festgestellt, ob das zu prüfende Produkt in der
Produktdatenbank hinterlegt ist und somit dem jeweiligen Prüfgerät „be-
kannt“ ist. Die Produkt ID des geprüften Tickets wird gelesen und mit den
hinterlegten Daten des Tarifmoduls nach PKM verglichen.
2. Räumliche Prüfung
Die Fachprüfung auf räumliche Gültigkeit gleicht die Raumdaten des Tickets
mit dem aktuellen Standort des DL-Terminals ab. Das DL-Terminal muss hier-
bei je nach Tarifmodell ggf. auch den folgenden Standort (nächste Haltestel-
le) liefern. Zu jedem Standort existiert eine Zuordnung zu einem Tarifpunkt
(z.B. einer Tarifzone), die entweder aus dem DL-Terminal geliefert oder durch
das Tarifmodul bereitgestellt wird. Daraufhin wird ermittelt, ob der aktuelle
und ggf. nächste Standort in den Raumdaten der Berechtigung enthalten ist.
3. Zeitliche Prüfung
Die zeitliche Prüfung umfasst die Kontrolle der Fahrberechtigung auf Gül-
tigkeitsbeginn und Gültigkeitsende. Wenn der Kontrollzeitpunkt des Prüf-
KONTROLLSTRATEGIE4.1
15/42
geräts in den Zeitraum der Gültigkeit der Fahrberechtigung fällt, gilt diese
Fachprüfung als gültig und der Kontrollvorgang kann fortgesetzt werden.
Liegt der Zeitpunkt der Prüfung nicht innerhalb dieses Zeitraums, so ist die
Berechtigung dementsprechend ungültig.
4. Prüfung der Zeitlage
Die Zeitlagen-Prüfung ist optional und erfolgt nur bei Tarifprodukten, die
zu bestimmten Zeiten innerhalb des Gültigkeitszeitraums nicht gültig sind
und mit den Tarifvereinbarungen des PV nicht übereinstimmen. Dabei kann
es sich beispielsweise um Bestimmungen zu Betriebszeiten handeln, wenn
eine Fahrberechtigung beispielsweise für einen gesamten Kalendertag bis
zum Ende der Betriebszeit gültig ist und als Ende der Betriebszeit durch den
PV 3:00 Uhr am Folgetag definiert wurde. Ein weiteres Beispiel stellt das
„9 Uhr Ticket“ dar. In diesem Fall ist die Geltungsdauer des Tickets insofern
eingeschränkt, dass die Berechtigung nur zwischen 9:00 Uhr und 3:00 Uhr
des Folgetages gültig ist. Bei der Prüfung der Zeitlage wird festgestellt, ob
sich das Ticket bei der Prüfung im Gültigkeitszeitraum befindet oder nicht.
5. Prüfung auf Mitnahmeregeln
Unter gewissen Umständen erlauben ausgewählte Fahrberechtigungen Mit-
nahmen. Dies können beispielsweise Personen oder auch Fahrräder sein.
Falls das geprüfte Produkt über einen solchen Zusatznutzen verfügt, muss
dieser dem Prüfenden mitgeteilt werden. Diese Zusatznutzen werden bei
einer Kontrolle auf dem Terminal visualisiert. Die Kontrollstrategie regelt in
diesem Fall die Ausgabe des entsprechenden Zusatznutzens.
6. Prüfung auf Klasse
Bei dieser Prüfung liefert das Terminal die Information, in welcher Wagen-
klasse die Prüfung stattfindet. Bei dem Fall einer Prüfung in der 1. Klasse und
ausschließlicher Gültigkeit des Tickets für die 2. Klasse bestimmt die Kon-
trollstrategie wiederum die Visualisierung auf dem Terminal. Der Prüfende
wird durch die Ausgabe aufgefordert den Ticketinhaber nach einem Zusatz-
ticket zu fragen.
7. Prüfung auf Rabattmedium
Die Prüfung auf ein Rabattmedium findet immer dann statt, wenn die Fahr-
berechtigung nur in Kombination mit einem Rabattmedium (z. B. BahnCard)
gültig ist. Auch in diesem Fall muss der PV in der Kontrollstrategie definieren,
wie dem Kontrollpersonal auf dem DL-Terminal ein entsprechender Hinweis
visualisiert wird. Dies kann beispielsweise eine Aufforderung an den Prüfen-
den sein, den Nachweis eines entsprechenden Rabattmediums zu verlangen.
Der PV sollte in der Kontrollstrategie festlegen, wie ein DL-Terminal das Prüf-
ergebnis visuell darstellt. Er muss zusätzlich festlegen, ob bei der ersten ne-
gativen Prüfung aus der Kontrollstrategie ausgestiegen wird, oder ob die
Ergebnisse nach vollständigem Durchlaufen zusammenfassend vom DL-Ter-
minal angezeigt werden.
Durch die verschiedenen Klassen von DL-Terminals (z. B. EKS, personalbe-
dientes Prüfgerät) muss der PV die Kontrollstrategie entweder für jede Klas-
se speziell definieren oder innerhalb einer gemeinsamen Kontrollstrategie
die Kontrolle hardwareabhängig differenzieren.
Um sich visuell in die Thematik einzufinden, kann die folgende Abbildung
unterstützend genutzt werden:
16/42
Wenn die Kontrollstrategie durch den PV für jede Klasse der DL-Terminals
(z. B. EKS, personalbedientes Prüfgerät/MDE-Gerät) definiert wurde, sollte
zum Abschluss eine Abstimmung mit den Herstellern der DL-Systeme über
die Interpretation, Aufbereitung und Anzeige der Daten aus dem Kontroll-
modul erfolgen. Hierbei ist eine enge Abstimmung zwischen PV und be-
teiligten DL notwendig. Formal besteht in der Regel kein Vertragsverhältnis
zwischen Hersteller (DL-Terminals) und PV. Bei Unstimmigkeiten und Anpas-
sungen der Kontrollstrategie sollte der PV trotzdem zu Rate gezogen wer-
den, um ggf. Änderungen ohne großen Zeitverzug vornehmen zu können.
Abbildung 5 zeigt eine stark vereinfachte Kontrollstrategie mit den verschie-
denen Entscheidungsschritten der Kontrolle. Einige sequentielle Berechnun-
gen und parallele Prüfschritte wurden vereinfachend kontrahiert. Durch die
in Abbildung 5 dargestellte „Stopp-Funktion“ (rotes Symbol „Ende“) soll
dargelegt werden, dass der Kontrollprozess bei einem Prüfergebnis gegen
einen Entscheidungsschritt abgebrochen wird und der im „Ausgangsschritt“
hinterlegte Text auf dem Gerät angezeigt wird. Wie und mit welchem Inhalt
die Ausgangstexte letztendlich dargestellt werden, ist vom PV zu definieren
und somit einheitlich für alle DL zu gestalten.
6Vgl. Tarifmodule nach PKM – Vortrag im Rahmen des Anwendertages vom 07.11.2017 (VDV eTicket Service)
ProduktprüfungProdukt bekannt?
Anzeigedaten DL Hardware: „Ticket unbekannt“
Anzeigedaten DL Hardware: „Ticket gesperrt“
Anzeigedaten DL Hardware: „Ticket zeitlich ungültig“
Anzeigedaten DL Hardware: „Ticket räumlich ungültig“
Anzeigedaten DL Hardware: „Ticket ungültig“
Applikation oder Berechtigung gesperrt?
[ja]
[ja]
[nein]
[nein]
[nein]
[nein]
[ja]
[ja]
Zeitliche PrüfungZeitlich gültig?
Räumliche PrüfungRäumlich gültig?
(weitere Prüfschritte...)
Abbildung 5: Kontrollstrategie
Ausgangsschritt
Entscheidungsschritt
Start
Ende
17/42
Das Pendant zur Kontrollstrategie stellt die Produktstrategie dar. Die Erstel-
lung einer Produktstrategie gehört ebenfalls zum Aufgabenbereich des PV.
Mit den ermittelten Werten aus der Verkaufsstrategie (Vgl. Kapitel 4.3) wird
die Ticketanfrage aus dem KVP-Produktmodul (Vgl. Kapitel 3.2) an das Pro-
duktmodul des PV übergeben. Die Eingangswerte werden anschließend vom
Produktmodul des PV ausgewertet und mit aktuellen Werten für die jewei-
ligen Parameter ersetzt. Für die korrekte Ermittlung der Produkte müssen
die Komponenten für das jeweilige Produkt hinterlegt sein. Hierzu gehören
je nach Tarif die Produkttabelle, die Fahrpreistafel, die TLV-EFS-Struktur, die
Drucktexte sowie die Layouts der Produkte. Nach Verarbeitung der Anfra-
ge übermittelt das PV-Produktmodul das Resultat wiederum an das Pro-
duktmodul des KVP. Nach Empfang der Daten wird das Ticket abschließend
durch den KVP erzeugt.
In der Produktstrategie gilt es für den PV dementsprechend, den Daten-
fluss nach Anfrage aus der Verkaufsstrategie abzubilden und die Schritte zur
Ausgabe der ermittelten Daten für das jeweilige Produkt zu definieren. Für
bestimmte Produkte kann die Produktstrategie aufgrund von zeitbeschränk-
ten tariflichen Regelungen, wie beispielsweise bei Abos, ein hohes Maß an
Komplexität aufweisen. Um sich mit den Logiken der Produktstrategie ver-
traut zu machen, sollte der PV die Bearbeitung von Produkten mit einfachen
Ausprägungen (z. B. Einzelticket) den komplexeren Produkten (z. B. Abos)
vorziehen.
Eine beispielhafte Produktstrategie ist in Abbildung 6 dargestellt. Durch die
Definition einer eindeutigen Produktstrategie ist der Ablauf im PV-Produkt-
modul hinterlegt und die Abfolge der verschiedenen Vorgänge bei abhängi-
gen Entscheidungen klar definiert.
PRODUKTSTRATEGIE4.2Verarbeitung Werteliste
aus Verkaufsstrategie
Ist Anfrage Bestandteil der Produktliste
Ausgabe Ticketerstellungnicht möglich
Kann Produkt mit angegebenen Parametern
erstellt werden?
Ausgabe Ticketerstellungnicht möglich
Ermittlung Anzeigedaten
Ermittlung Ticketdaten (ggf. im TLV-EFS)
Ermittlung Daten für Hintergrundsystem
Ausgabe ermittelter Daten an
Verkaufsstrategie
Ausgangsschritt
Entscheidungsschritt
Berechnungsschritt
Start
Ende
[nein]
[nein]
Abbildung 6: Produktstrategie
18/42
Abbildung 6 verdeutlicht vereinfachend beispielhaft den Ablauf einer Ticket-
anfrage und visualisiert die oben genannten Schritte. Der Start erfolgt mit
der Verarbeitung der Daten aus der Verkaufsstrategie. Mit der Rückgabe der
durch das PV-Produktmodul ermittelten Daten an das KVP-Produktmodul
ist das Ziel der Produktstrategie erreicht. Das KVP-Produktmodul beinhaltet
alle Produkte aus den eingespeisten PV-Produktmodulen (Vgl. Abbildung 4).
Aufgrund dessen ist das KVP-Terminal in der Lage, das angefragte Ticket mit
den bereitgestellten Daten zu erzeugen.
Die Verkaufsstrategie ist Bestandteil des Produktmoduls (Vgl. Kapitel 4) und
kann sowohl vom PV als auch vom KVP definiert werden. Sie regelt den
Kundendialog am Verkaufsgerät bzw. die Menüführung der personenbedien-
ten Verkaufsstellen (z. B. Abo-Counter). Da die Vertriebshoheit in der Regel
beim KVP liegt wird die Verkaufsstrategie für gewöhnlich dementsprechend
vom zuständigen KVP festgelegt. Durch das Visualisieren der Verkaufsstra-
tegie kann diese dann im entsprechenden Produktmodul technisch umge-
setzt werden.
In der Verkaufsstrategie werden die Schritte zur Ticketfindung beschrieben.
Nach dem Ermitteln der Ticketbedingungen gibt das KVP-Produktmodul
die ermittelten Daten an das zuständige PV-Produktmodul weiter. Die im
PV-Produktmodul hinterlegten Informationen (z. B. Preis, Drucktext, Hin-
weistext, etc.) zu dem Ticket erhält das KVP-Produktmodul daraufhin zurück.
Bei dem Einstieg in eine Verkaufsstrategie kann zwischen einem schnellen
Direktverkauf (Abbildung 7) von Tickets sowie einem sogenannten Verbin-
dungsverkauf (Abbildung 8) unterschieden werden.
VERKAUFSSTRATEGIE4.3
Initialisierungder Gerätedaten
InitialisierungModuldaten
Erstellung Verkaufs-bildschirm für Direktverkauf
Auswahl imStartbildschirm
AuswahlProdukt 1
AuswahlProdukt 2
AuswahlProdukt 3
AuswahlProdukt 4
Erstellung voll-ständige Anzeige für gewähltes Produkt
Erstellung voll-ständige Anzeige für gewähltes Produkt
Erstellung voll-ständige Anzeige für gewähltes Produkt
Erstellung voll-ständige Anzeige für gewähltes Produkt
Zusammenstellung notweniger Dateianfragen
für gewähltes Produkt
Zusammenstellung notweniger Dateianfragen
für gewähltes Produkt
Zusammenstellung notweniger Dateianfragen
für gewähltes Produkt
Zusammenstellung notweniger Dateianfragen
für gewähltes Produkt
Ausgangsschritt
Entscheidungsschritt
Berechnungsschritt
Start
Ende
Übergabe derDaten an
PV-Produktmodul
Ermpfang der ermittelten Daten aus
PV-Produktmodul
Ermpfang der ermittelten Daten aus
PV-Produktmodul
Ermpfang der ermittelten Daten aus
PV-Produktmodul
Ermpfang der ermittelten Daten aus
PV-Produktmodul
Übergabe derDaten an
PV-Produktmodul
Übergabe derDaten an
PV-Produktmodul
Übergabe derDaten an
PV-Produktmodul
Ausgabe Produkt 1
Ausgabe Produkt 2
Ausgabe Produkt 3
Ausgabe Produkt 4
Abbildung 7: Verkaufsstrategie Direktverkauf
19/42
Beim Kauf eines Tickets nach Verbindungsauskunft erfolgt die Ticketfindung
auf Grundlage eingegebener Haltestellen, Adressen oder Points of Interest
(POI) und der damit einhergehenden Verarbeitung durch ein Routing- oder
Fahrplanauskunftssystem. Basierend auf diesen Informationen werden, falls
vorhanden, verschiedene Fahrtalternativen ermittelt und dem Kunden vor-
geschlagen. Nach Auswahl einer Fahrtalternative werden dem Kunden an-
schließend die hierfür nutzbaren Tickets angeboten.
Beim Direktverkauf wählt der Kunde ohne Eingabe von Start- und Zielpunkt
direkt das Ticket aus. Wie letztendlich in die Verkaufsstrategie eingestie-
gen wird, hängt vom dahinterliegenden Tarif und Prozess ab. Verschiedene
Vertriebswege eines KVP können hierbei unterschieden werden, aber auch
innerhalb eines Vertriebsweges kann je nach Produkt über beide Möglich-
keiten der Einstieg in den Verkauf erfolgen.
Der Unterschied zwischen den zwei verschiedenen Verkaufsstrategien liegt
letztendlich darin, dass die Produkte beim Verbindungsverkauf auf Basis der
Verbindungseingabe bereitgestellt werden und daraufhin ein Produkt aus-
gewählt werden kann. Beim Direktverkauf wird unabhängig von Eingabe-
parametern eine Ticketauswahl direkt über eine Bildschirmmaske zur Ver-
fügung gestellt. Bei beiden Varianten ist sowohl die direkte Kommunikation
zwischen Endgerät und Kunde als auch die Kommunikation über einen Mit-
arbeiter möglich. Dies kann beispielsweise über den Busfahrer und den Bild-
schirm des Bordrechners geschehen.
Erstellung Verkaufsbild-schirm für Direktverkauf
Initialisierungder Gerätedaten
Startbildschrim verbin-dungsbasierter Verlauf
Verbindungseingabe: von – nach – über
InitialisierungModuldaten
Übergabe derStrecke an Fahrplan-
auskunftssystem
Darstellung mög-licher Produkte für
die Verbindung
AuswahlProdukt 1
AuswahlProdukt 2
AuswahlProdukt 3
AuswahlProdukt 4
Erstellung voll-ständige Anzeige für gewähltes Produkt
Erstellung voll-ständige Anzeige für gewähltes Produkt
Erstellung voll-ständige Anzeige für gewähltes Produkt
Erstellung voll-ständige Anzeige für gewähltes Produkt
Zusammenstellung notweniger Dateianfragen
für gewähltes Produkt
Zusammenstellung notweniger Dateianfragen
für gewähltes Produkt
Zusammenstellung notweniger Dateianfragen
für gewähltes Produkt
Zusammenstellung notweniger Dateianfragen
für gewähltes Produkt
Ausgangsschritt
Entscheidungsschritt
Berechnungsschritt
Start
Ende
Übergabe derDaten an
PV-Produktmodul
Ermpfang der ermittelten Daten aus
PV-Produktmodul
Ermpfang der ermittelten Daten aus
PV-Produktmodul
Ermpfang der ermittelten Daten aus
PV-Produktmodul
Ermpfang der ermittelten Daten aus
PV-Produktmodul
Übergabe derDaten an
PV-Produktmodul
Übergabe derDaten an
PV-Produktmodul
Übergabe derDaten an
PV-Produktmodul
Ausgabe Produkt 1
Ausgabe Produkt 2
Ausgabe Produkt 3
Ausgabe Produkt 4
Abbildung 8: Verkaufsstrategie Verbindungsverkauf
20/42
welche Informationen bereitzustellen sind, um elektronische Fahrberechti-
gungen (Chipkarte oder Barcode) abzubilden bzw. auszugeben und diese
dementsprechend auch zu kontrollieren.
Eine Grundvoraussetzung für die Abbildung und Kontrolle von (((eTickets ist
die Bereitstellung von vollständigen Tarifdaten. Die Abbildung der einzelnen
Produkte kann nur erfolgen, wenn das vollumfängliche Produktsortiment mit
allen tariflichen Eigenschaften zur Verfügung steht.
Der „Produkteditor“ ist ein unterstützendes Werkzeug zur einfachen Erzeu-
gung von Tarifmodulen nach PKM und ist kompatibel zum Standard Tarifmo-
dule nach PKM aus dem (((eTicket Deutschland. Der PV kann mit Hilfe dieses
Tools die Digitalisierung der Produkte nach dem Standard Tarifmodule nach
PKM vornehmen und letztendlich standardisierte Tarifmodule unterteilt nach
Produkt- und Kontrollmodulen, erzeugen. Der „Produkteditor“ kann beim
Hersteller, dem Fraunhofer-Institut für Verkehrs- und Infrastruktursysteme
IVI, im Zuge einer zu erwerbenden Lizenz bezogen werden.
Der Editor beinhaltet umfassende tarifliche Funktionen zur Pflege aller tarif-,
verkaufs- und kontrollrelevanten Daten eines Produktes. Diese beinhalten
beispielsweise Daten für die Ticketerstellung (EFS-Daten, Anzeige-/Druck-
texte etc.) und der dazugehörigen Verarbeitungslogik. Unterstützt werden
dabei sowohl konventionelle, als auch elektronische Vertriebswege. Des
Weiteren lassen sich mit dem „Produkteditor“ Testfälle für den Verkauf und
für die Kontrolle von Tickets erstellen, speichern und ausführen um die Funk-
tionsfähigkeit zu testen.
Um die einzelnen Module auch in der Praxis auf einwandfreie und korrekte
Anwendung testen zu können ist der PV dazu angehalten Testfälle zu defi-
nieren. Das Hauptaugenmerk der Testfälle liegt darauf, die einzelnen Modu-
le gegen simulierte Situationen aus der Realität zu testen und somit auf
Funktionalität zu prüfen. Der PV sollte dabei auf eine möglichst praxisnahe
sowie detaillierte Beschreibung achten. Hier ist vor allem entscheidend, bei
welchen Eingangsparametern (Produkt, Raumnummer, Prüfzeitpunkt, Prüf-
haltestelle etc.), welches Ergebnis erwartet wird.
Es sind diversifizierte Testfälle und somit auch verschiedene Berechtigun-
gen zu beschreiben. Als Orientierungspunkt sollte dabei das jeweilige Pro-
duktsortiment dienen. Es sollte aber zusätzlich darauf Wert gelegt werden,
dass die Testfälle nicht nur lokale und regionale Produkte beinhalten. Voraus-
gesetzt dem PV obliegt die Zuständigkeit für landesweit gültige Produkte,
dürfen diese in der Beschreibung der Testfälle nicht fehlen. Die Testfälle gilt
es für die Kontroll- sowie Produktstrategie zu definieren. Im Bereich der Ver-
kaufsstrategie müssen keine Produkte beschrieben, sondern abhängig von
der Verkaufsstrategie (Verbindungs- oder Direktverkauf) Verkaufslogiken
entwickelt werden.
Das Tarifmodul nach PKM fokussiert sich auf die Abbildung und Kontrol-
le von (((eTickets. In diesem Kapitel soll dem PV näher gebracht werden,
TESTFÄLLE
ABBILDUNG UND KON-TROLLE VON (((eTICKETS
ANWENDUNG „PRODUKTEDITOR“
4.4
5
5.1
21/42
raum noch Formate bereitgestellt werden sollen, die nicht dem VDV-KA-Stan-
dard entsprechen. Im Zuge des Tarifmoduls nach PKM kann der PV mit Hilfe
des vorgestellten, aber nicht verpflichtenden, „Produkteditors“ die Konfigu-
ration der einzelnen Produkte vornehmen. Des Weiteren können ggf. bereits
vorhandene Datenbestände in den Editor importiert werden und Testfälle für
die Module erstellt und ausgeführt werden. Ziel ist es, am Ende dieser Prozes-
se ein PV-Produkt- bzw. PV-Kontrollmodul gemäß VDV-KA-Standard an die
KVP bzw. DL weiterzuleiten (Vgl. Gesamtkontext Abbildung 5).
Wie in Abbildung 9 verdeutlicht, können die erzeugten Produkt- und Kon-
trollmodule in die Vertriebs- bzw. DL-Terminals implementiert werden. Falls
Datenbanken aus Drittsystemen bzw. mit anderer Datenstruktur importiert
werden sollen, ist eine Importschnittstelle (Vgl. Kapitel 6.2) des Drittsystems
zum „Produkteditor“ bereitzustellen.
Für einen KVP ohne Nutzung des Tarifmoduls nach PKM können mit Hilfe des
„Produkteditors“ ggf. Exporte von ACCESS- oder CSV-Daten erstellt werden.
Dies kann beispielsweise auch dann sinnvoll sein, falls in einem Übergangszeit-
1 23
c4
56
b7
8 9d
ö0
äk
Produktmodule
Produkteditor
Kontrollmodule
ggf. Import aus Drittsystemen (je nach Bedarf)
ggf. Export von ACCESS od. CSV-Daten an VU ohne Produktmodule
Abbildung 9: „Produkteditor“ (Quelle: Dr. Torsten Gründel (Fraunhofer IVI): Präsentation: PKM-Workflows am Beispiel des „Produkteditors“ vom 26.04.2017)
22/42
weiter zu pflegen. Die folgenden Unterkapitel beschreiben das Dokument
„Abbildung und Kontrolle von (((eTickets“.
Jedes Produkt im Sinne eines Tickettyps des ÖPV erhält bei seiner Abbil-
dung eine eindeutige Tarifproduktnummer sowie eine EFM-Produktnummer.
Die Tarifproduktnummer wird einem Produkt einmalig zugeordnet und ist
für die Verbundabrechnung des Tarifproduktes relevant. Jedem Produkt ist
eine Tarifproduktnummer sowie eine EFM-Produktnummer durch den PV
zuzuweisen.
Die EFM-Produktnummer definiert das Kontrollprodukt und fasst diejenigen
Tarifprodukte zusammen, die dieselben tariflichen Eigenschaften aufweisen.
Als Beispiel kann das Ticket2000 Abo 9 Uhr aus dem VRR gelten. Die grund-
legenden Eigenschaften des Produktes sind über all seine möglichen Aus-
prägungen identisch. Aus diesem Grund werden abgeleitete Produkte unter
der gleichen EFM-Produktnummer geführt. Unterschiede gibt es dann bei-
spielsweise in den Preisstufen (A1-A3, B, C, D) sowie in der Differenzierung
persönlich/unpersönlich. Diese Differenzierungen werden jedoch nicht über
die Produktnummer, sondern elektronisch über die Inhalte der Fahrberech-
tigung abgebildet (die Relation/Raumnummer drückt bspw. den Geltungs-
bereich aus). Über die EFM-Produktnummer findet letztlich im Rahmen des
Kontrollmoduls die Auswertung der tariflichen Regeln des Tarifproduktes
statt.
Für die Abbildung von Fahrberechtigungen werden (((eTicket-Produkte
auf verschiedenen Nutzermedien gespeichert. Im Zuge des VDV-KA-Stan-
dards besteht eine Berechtigung aus fest definierten und produktspezifi-
Dieses Kapitel soll hauptsächlich eine Empfehlung zur Erstellung eines an-
leitenden Dokuments („Abbildung und Kontrolle von (((eTickets“) für an
(((eTicket Deutschland teilnehmende PV sein. Der PV ist angehalten ein
solches Dokument mit den in Kapitel 5.2 bis 5.6 dargestellten Inhalten zu
erstellen. Mögliche Inhalte sollen im Folgenden erläutert und punktuell mit
Beispielen untermauert werden. Die Unterkapitel geben die durch den PV zu
beschreibenden Inhalte wieder und verweisen ggf. auf VDV-KA-Dokumente,
die einzelne Aspekte im Detail beschreiben.
Ein solches Dokument ist als Medium zu sehen, um alle notwendigen Infor-
mationen, Daten und Bestimmungen zusammenzuführen. Die Struktur ori-
entiert sich dabei an bereits bestehenden Dokumenten des VRS-, AVV- und
NRW-Tarifes, auf deren Grundlage bereits erste Produkt- und Kontrollmodu-
le umgesetzt wurden. Falls Beispiele der einzelnen Unterkapitel notwendig
sind, können diese Dokumente unterstützend zur Hilfe genommen werden.
Sie können über die Homepage des Kompetenzcenters für elektronisches
Fahrgeldmanagement NRW (KCEFM: www.kcefm.de) heruntergeladen und
eingesehen werden.
Sollte es zu einer vollumfänglichen Umsetzung von Tarifmodulen nach PKM
in einem Verbundraum kommen, wird das er-
stellte Dokument „Abbildung und Kontrolle von
(((eTickets“ theoretisch nicht länger benötigt.
Zur Einarbeitung neuer Mitarbeiter sowie zur
eigenen Dokumentation wird jedoch empfoh-
len das erstellte Dokument kontinuierlich
DOKUMENT „ABBILDUNG UND KONTROLLE VON (((eTICKETS“
5.2ABBILDUNG VON PRODUKTEN5.3
23/42
code natürlich kopierbar. Aus diesem Grund sollte zusätzlich ein Identifikati-
onsmedium in der Berechtigung hinterlegt werden, mit dem der Nutzer sich
bei einer Kontrolle identifiziert. Der PV sollte für seinen Tarifraum über das
VDV-KA-Format des Barcodes entscheiden und dieses in dem Dokument
„Abbildung und Kontrolle von (((eTickets“ festlegen.
Dem VDV-KA-Dokument „Spezifikation statischer Berechtigungen für 2D
Barcode-Tickets (KA STB-SPEC)“ sind die entsprechenden Details zur Defi-
nition einer statischen Berechtigung zu entnehmen.
Die räumliche Abbildung des Verbundgebietes hängt maßgeblich vom je-
weiligen Tarifmodell ab (bspw. Flächentarif oder relationsbasierte Tarifie-
rung). Der PV beschreibt in diesem Abschnitt, wie die räumliche Struktur des
Tarifes aufgebaut ist und wie die einzelnen Bezeichnungen der Tarifräume zu
interpretieren sind. Nur dadurch können die eingetragenen
Daten korrekt interpretiert werden. In diesem Unterpunkt
sollte der zuständige PV die vom Tarif abhängigen,
räumlichen Definitionen einsetzen.
Das in Abbildung 10 gezeigte Beispiel
aus dem VRR stellt eine
Lösung zur Beschreibung der
räumlichen Definition dar.
schen Teilen sowie einem Infotext. Detailliertere Informationen können dem
VDV-KA-Dokument „Spezifikation Nutzermedium“ (KA NM-SPEC) entnom-
men werden. Der Infotext sowie der produktspezifische Teil sind zur Ab-
bildung von (((eTicket-Produkten frei definierbar. In allen neuen Objekten
besteht das VDV-KA-Format aus Daten des TLV-EFS.
5.3.1 BESCHREIBUNG TLV-EFS
Aufgrund der hohen Komplexität der Tarifprodukte und deren räumlichen
Gültigkeitsstrukturen, stellt das Datenformat TLV-EFS ein Baukastensystem
zur Verfügung. Dadurch ermöglicht der TLV-EFS eine hohe Flexibilität in der
Beschreibung von Tarifprodukten.
Der Inhalt der Produkte wird mit sogenannten TAGs beschrieben. Dem PV
obliegt die Aufgabe, seine Tarife mit den dazugehörigen TAGs zu definieren
und somit festzulegen, welche TAGs für welche EFM-Produkte erforderlich
sind. Die verschiedenen TAGs legen die tarifliche und vertriebliche Nutzung
der Produkte fest.
Die einzelnen Definitionen sowie die Varianten zur Gestaltung der TAG-Be-
legung können in den VDV-KA-Dokumenten der Anlage 1 zum „Hauptdoku-
ment mit Basisobjektmodell (BOM) - Definition des TLV EFS (Anlage 1 BOM
TLV EFS)“ und in der „Spezifikation Nutzermedium (KA NM-SPEC)“ nach-
gelesen werden.
5.3.2 DIFFERENZIERUNG ZUM BARCODE-TICKET
Grundsätzlich kann der TLV-EFS auch bei statischen Berechtigungen wie
z. B. beim VDV-Barcode verwendet werden. Das Barcode-Ticket wird als ein
EFS mit einer digitalen Signatur ausgestellt. Der Barcode wird als nicht ver-
änderbarer, statischer Datensatz ausgegeben, beispielsweise in Form eines
Handytickets. Die digitale Signatur stellt einen starken Schutz gegen Fäl-
schungen und Veränderungen der Berechtigung dar. Dennoch ist ein Bar-
RÄUMLICHE DEFINITION (WABE, ZONE, RAUM-NUMMER)
5.4
35Essen
Mitte/Nord
34Mühlheima. d. Ruhr
3421 Wabe
von Mülheim
3501 Wabe
von Essen
A
45EssenSüd
Abbildung 10: Beispiel räumliche Definition im VRR (Quelle: www.ruhrbahn.de)
24/42
gen produktrelevante Informationen, die der eindeutigen Beschreibung die-
nen. Mit Hilfe dieser TAGs wird das Produkt mit Datenelementen gefüllt und
somit technisch eindeutig abgebildet.
In dem Tabellenblatt „TAG-Nutzung bei Tickets“ wird hinterlegt, welcher
TAG für das jeweilige Produkt verwendet wird. Der PV kann dabei nach „Ti-
cket-Art“, „Preisstufe“ sowie nach „Vertriebswegen/Varianten der TAG-Aus-
wahl des TLV“ unterscheiden. Zusätzlich hinterlegt der PV die zeitliche Gül-
tigkeit sowie die grundlegenden Daten (TAG DA) des jeweiligen Produkts.
Der PV hat die Aufgabe, sein Produktsortiment mit den vorhandenen TAGs
abzubilden und somit eindeutig zu definieren.
5.5.1 REFERENZBERECHTIGUNGEN
An dieser Stelle des Dokuments sollte der PV die Definition von Referenz-
berechtigungen für Testzwecke darlegen. Bei den Referenzberechtigungen
handelt es sich um fest definierte produktspezifische Datenstrukturen zur
interoperablen Nutzung einer elektronischen Fahrberechtigung für AFB
(VDV-KA-Dokument „Hauptdokument mit Basisobjektmodell (BOM) (KA
BOM-Spec)“). Die Beschreibung und Verwendung von Referenzberechtigun-
gen dient zu Testzwecken seitens der Hersteller der (Kontroll-)Infrastruktur.
Im Zuge der Entwicklung von AFB (z. B. CiBo) ist der Hersteller durch die
Integration von Referenzberechtigungen in der Lage, zielgerichtete und pra-
xisnahe Tests für die AFB durchführen.
5.5.2 TAG FAHRGAST – KÜRZUNGSREGEL ZUM FAHRGASTNAMEN
Bei Produkten, die im tariflichen Sinne persönlich ausgegeben werden so-
wie bei der Ausgabe von Barcodes wird der Name des Kunden in der Be-
rechtigung hinterlegt. Der PV gibt hier vor, in welcher Form der Name in
die Berechtigung geschrieben wird. Es besteht die Möglichkeit, den Namen
ungekürzt im Klartext einzutragen (nach Genehmigung des Datenschutzbe-
Die Preisstufe A umfasst in diesem Fall zwei aneinander liegende Waben (sy-
nonym wird in anderen Tarifgebieten der Begriff „Zonen“ verwendet). Meh-
rere Waben bilden ein Tarifgebiet. In diesem Fall gehört die Wabe 350 zum
Tarifgebiet 35 Essen Mitte/Nord. Die technische Beschreibung der Preisstu-
fen wird im vorliegenden Beispiel des VRR durch sogenannte Raumnum-
mern auf der Fahrberechtigung hinterlegt (Vgl. Kapitel 5.5.3).
Die Raumnummer stellt einen Verweis auf die abgelegte Relation dar. Alle
Flächen, in denen das ausgegebene Ticket gültig ist, werden durch die
Raumnummer in der Fahrberechtigung definiert und technisch hinterlegt.
Bei der räumlichen Definition müssen die jeweiligen Abschnitte eindeutig
zugeordnet werden können. Auf der Fahrberechtigung gilt es den räumli-
chen Geltungsbereich klar zu hinterlegen.
Für die Übersichtlichkeit und Verständlichkeit der Beschreibung von Produk-
ten hat sich eine Struktur in Tabellenform bewährt. Der Fokus liegt an die-
ser Stelle auf der Beschreibung der Produkte inklusive der entsprechenden
TAG-Nutzung durch den PV und der Abbildung in einer Tabelle.
Die Tabelle besteht aus folgenden Reitern:
• TLV Gesamtübersicht TAGs (Bsp. Anlage 2)
• TAG-Nutzung bei Tickets (Bsp. Anlage 3)
Die Reiter beschreiben im Wesentlichen die
technische Seite des Produkts bzw. die jeweiligen TAGs.
Das Tabellenblatt „TLV Gesamtübersicht TAGs“ beschreibt die jeweiligen
TAGs, welche Datenelemente dem einzelnen TAG untergeordnet sind und
wie die Datenstruktur des TAGs definiert ist. Hinter den einzelnen TAGs lie-
BESCHREIBUNG VON PRODUKTEN5.5
25/42
ge für die Layouterstellung zu nutzen. Durch eine Einführung einer solchen
Grundlage bei den KVP kann das Layout der Produkte zu einem gewissen
Maß vereinheitlicht werden.
Die weiteren TAGs sowie deren Inhalte sind den VDV-KA-Dokumenten
„Hauptdokument mit Basisobjektmodell (BOM) (KA BOM-Spec)“ und der
Anlage 1 zum „Hauptdokument mit Basisobjektmodell (BOM) - Definition
des TLV EFS“ zu entnehmen. Bei den hier dargestellten Unterkapiteln (5.5.1
– 5.5.4) handelt es sich lediglich um eine TAG-Auswahl bei der gewisse As-
pekte beachtet werden müssen, die nicht zwingend aus den hinterlegten
Dokumenten hervorgehen.
Die endgültig beschriebenen Produkte können schließlich in Form von EFS
an Vertriebsterminals ausgegeben und dementsprechend auf einem Nutzer-
medium hinterlegt werden. Abbildung 11 verdeutlicht noch einmal den (tech-
nischen) Zusammenhang zwischen der Abbildung/Beschreibung von Pro-
dukten und deren Kontrolle. Die Geräte-Software des KVP-Terminals greift
auf das XML-Produktmodul mit seiner technischen Verarbeitungsalgorith-
mik und den entsprechenden Fachdaten zu.
Der Ablauf im DL-Terminal bei der Kontrolle ist mit dem im Vertriebsterminal
vergleichbar. Das Produkt wird anfangs von der im DL-Terminal integrierten
Gerätesoftware gelesen und in der Hinsicht verarbeitet, dass mit Zugriff auf
das Kontrollmodul die produktspezifischen Kontrollregeln abgerufen und
mit den Daten des Terminals verglichen werden.
auftragten) oder diesen nach einer in der VDV-KA definierten Kürzungsregel
zu hinterlegen. Die KA stellt zwei Kürzungsregeln für Namen zur Auswahl:
» maskierter und gekürzter Name oder
» gekürzter Name im Klartext
Die Erklärung zur Systematik der Kürzungsregel sowie die Darstellung ver-
schiedenster Beispiele sind für beide Regeln im VDV-KA-Dokument „Haupt-
dokument mit Basisobjektmodell (BOM) (KA-BOM-Spec)“ hinterlegt.
Die Kürzungsregel zum Fahrgastnamen findet bei Produkten der tariflichen
Übertragbarkeit auf andere Personen keine Anwendung.
5.5.3 TAG LISTE – RÄUMLICHER GELTUNGSBEREICH
Bei der Beschreibung des räumlichen Geltungsbereichs hat der PV zu be-
achten, dass dieser über die Struktur „Liste originärer Geltungsbereich“ im
EFS abgelegt wird. Werden Gültigkeitsräume verschiedener PV angegeben,
kann das TAG „Liste“ mit entsprechenden Organisations-IDs eingetragen
werden. Der „originäre Geltungsbereich“ beschreibt die räumliche Gültigkeit
des EFS. Sie kann durch die Struktur „Liste alternativer Geltungsbereich“
erweitert werden. Der „alternative Geltungsbereich“ beschreibt den Tarif-
raum, der einem EFS außerhalb des Normalfalls (z.B. in Schwachlastzeiten)
zur Verfügung stünde.
Die Relation zum räumlichen Geltungsbereich wird normalerweise durch
entsprechende Raumnummern hinterlegt. Je nach Tarifstruktur kann es für
den PV notwendig sein auch einzelne Haltestellen als Starthaltestellen zu de-
klarieren und nummeriert in der Berechtigung zu hinterlegen.
5.5.4 LAYOUT (OPTIONAL)
Bei Verwendung von Tarifmodulen nach PKM können neben den spezifizier-
ten Datenstrukturen auch die Layouts der Fahrausweise übermittelt werden.
Bei keiner einheitlichen Vorgabe des Layouts durch den PV, wird dem PV an
dieser Stelle empfohlen, eine Definition zu erstellen und diese als Grundla-
KONTROLLE VON PRODUKTEN5.6
26/42
Der Ablauf im DL-Terminal bei der Kontrolle ist mit dem im Vertriebsterminal
vergleichbar. Das Produkt wird anfangs von der im DL-Terminal integrierten
Gerätesoftware gelesen und in der Hinsicht verarbeitet, dass mit Zugriff auf
das Kontrollmodul die produktspezifischen Kontrollregeln abgerufen und
mit den Daten des Terminals verglichen werden.
Die grundsätzliche Beschreibung des Kontrollprozesses erfolgt über die
dazugehörige Kontrollstrategie. Der PV kann über die Kontrollstrategie
hinaus weitere Erklärungen zur Kontrolle beschreiben. Diese Ergänzungen
stammen nicht aus der Verwendung des Kontrollmoduls, sondern dienen
ggf. zur Schärfung und Erläuterung des Kontrollprozesses.
Die nachfolgenden Kapitel dienen ebenfalls zum Erstellen des Dokuments
„Abbildung und Kontrolle von (((eTickets“ und sollen den Kontrollprozess
darstellen.
5.6.1 Kontrollmodule und Kundenschnittstelle
Das Kontrollmodul ist die technische Beschreibung des Prüfprozesses, wel-
cher im DL-Terminal zur Anwendung kommt. Die Visualisierung der Kontroll-
ergebnisse auf dem DL-Terminal ist geräte- und somit auch herstellerabhän-
gig. Sie wird durch die in der Kontrollstrategie definierten Ausgabekontexte
vorgegeben.
Der PV legt fest, wie das Kontrollmodul mit der Kundenschnittstelle inter-
agiert. Für (((eTicket Deutschland wurde innerhalb der VDV-KA die Schnitt-
stelle zum Kunden spezifiziert. Unter einer Kundenschnittstelle werden alle
Prozesse und Objekte verstanden, mit denen der Nutzer/Kunde bei Verkauf,
Service, Abrechnung und Nutzung in Kontakt tritt. Das VDV-Dokument „Ein-
heitliche Kundenschnittstelle für ein mehrstufiges interoperables elektro-
nisches Fahrgeldmanagement (KA KUSCH-Spec)“ beschreibt, wie die ein-
zelnen Kundenschnittstellen darzustellen sind. Durch die Vereinheitlichung
soll sichergestellt werden, dass die Kunden und Nutzer sich im gesamten
Die grundsätzliche Beschreibung des Kontrollprozesses erfolgt über die da-
zugehörige Kontrollstrategie. Der PV kann über die Kontrollstrategie hinaus
weitere Erklärungen zur Kontrolle beschreiben. Diese Ergänzungen stam-
men nicht aus der Verwendung des Kontrollmoduls, sondern dienen ggf. zur
Schärfung und Erläuterung des Kontrollprozesses.
Die nachfolgenden Kapitel dienen ebenfalls zum Erstellen des Dokuments
„Abbildung und Kontrolle von (((eTickets“ und sollen den Kontrollprozess
darstellen.
XML-Produktmodul Geräte-Software
Vertriebsterminal
Verarbeitungs-
algorithmikFunktionen zum Lesen von Fahrberechtigungsdaten
Funktionen zum Lesen von Gerätedaten
Logik- und Verarbeitungsfunktionen
Funktionen zum Nutzen von Zustandsdaten
Funktionen zum Lesen von Produktmoduldaten
Fachdaten
XML-Kontrollmodul Geräte-Software
Kontrollterminal
Verarbeitungs-
algorithmikFunktionen zum Lesen von Fahrberechtigungsdaten
Funktionen zum Lesen von Gerätedaten
Logik- und Verarbeitungsfunktionen
Funktionen zum Nutzen von Zustandsdaten
Funktionen zum Lesen von Kontrollmoduldaten
Fachdaten
Abbildung 11: Grundlegende Funktionsweise (Quelle: Einführung EFS-Produkt- & EFS-Kontrollmodule; VDV eTicket Service)
27/42
5.6.2.1 Prüfung der zeitlichen Gültigkeit
Im Zuge des Kontrollprozesses ist der PV für die Festlegung der zeitlichen
Regeln für das jeweilige Produkt zuständig und stellt somit auch die zeit-
lichen Rahmenbedingungen auf. Der KVP setzt diese bei der Ausgabe der
Fahrberechtigung um und versieht die Berechtigung mit einem Gültigkeits-
zeitraum. In diesem Abschnitt wird der Betriebsschluss definiert, welche
Unterschiede es möglicherweise im Betriebsschluss gibt, wie die Zeitgren-
zen beispielsweise für zeitbegrenzte Abos definiert sind und wie mögliche
Kulanzregelungen im Verantwortungsgebiet des PV aussehen.
Die vom PV definierten Kriterien werden gegen die Angaben der zeitlichen
Gültigkeit aus der Berechtigung geprüft und gegen die aktuellen Zeitdaten
abgeglichen.
5.6.2.2 Prüfung der räumlichen Gültigkeit
Die Prüfung der räumlichen Gültigkeit stellt einen weiteren Punkt des durch
den PV zu definierenden Kontrollprozesses dar. Grundlage für die Prüfung
der räumlichen Gültigkeit sind ebenfalls die Daten aus der Fahrberechtigung.
Der tarifliche Standort für die aktuelle und ggf. für die vorherige und nächste
Haltestelle wird durch das DL-Terminal geliefert. Auf Basis der Daten aus der
Fahrberechtigung und aus dem DL-Terminal wird schlussendlich verglichen,
ob die Fahrberechtigung für den aktuellen Tarifraum gültig oder ungültig ist.
Bei verschiedenen Produkten kann zusätzlich zur Raumnummer eine Start-
haltestelle oder eine Zielhaltestelle in der Berechtigung hinterlegt werden.
Bei der Prüfung der räumlichen Gültigkeit sind diese dann entsprechend zu
berücksichtigen. Außerdem sind die möglichen „alternativen Geltungsberei-
che“ bei der Prüfung der Fahrberechtigung vom PV zu berücksichtigen.
5.6.2.3 Ausgabedaten
Die durch den Kontrollprozess ermittelten Kontrollausgangsdaten stellen
die Ausgabedaten dar und sind durch den PV zu definieren. Die ermittelten
Anwendungsbereich des (((eTicket Deutschland auf identische Art und Wei-
se zurechtfinden. Der PV soll in diesem Kapitel den Ablauf der Gültigkeits-
prüfungen nach VDV-Standard bzw. gemäß des VDV-Dokumentes (Vgl. KA
KUSCH-Spec) festlegen.
5.6.2 Kontrollprozess
Der Kontrollprozess wird in der dazugehörigen Kontrollstrategie vom PV
beschrieben. Die ausgelesenen Daten aus dem Nutzermedium werden mit
denen des DL-Terminals inklusive des Kontrollmoduls verglichen und geprüft
(Vgl. Abbildung 11).
Durch die Kontrollstrategie wird der Ablauf des Kontrollprozesses festge-
legt. Die im Kontrollmodul hinterlegten Kontrollregeln werden mit den (aktu-
ellen) Daten des DL-Terminals verglichen. Bei den Terminaldaten spielen vor
allem aktuelle Daten wie Datum, Uhrzeit sowie die aktuelle Haltestelle eine
Rolle. Ggf. werden den Gerätedaten zusätzlich die vorherige und kommende
Haltestelle hinzugefügt.
Bei einer personenbedienten Kontrolle kann bei dem entsprechenden Pro-
dukt ein Kontrollmedium, beispielsweise ein Personalausweis, verlangt wer-
den. Der auf dem DL-Terminal visualisierte Ausgangskontext zum Nachweis
eines Kontrollmediums wird über den Kontrollprozess vorgegeben und dem
Prüfpersonal auf dem Terminal angezeigt. Die zusätzliche Kontrolle erfolgt
hauptsächlich bei einem persönlichen Ticket oder bei der Prüfung eines Bar-
codes. Im Gegensatz zu einer Prüfung durch das Kontrollpersonal erfolgt bei
einem EKS eine weitgehend autonome Prüfung der Fahrberechtigung. Hier
ist durch den PV in der Kontrollstrategie zu entscheiden, wie unklare Prüf-
ergebnisse zu handhaben sind. Beispielsweise kann ein EKS dahingehend
programmiert werden, dass auf den Nachweis eines Kontrollmediums bei
der Vorlage eines persönlichen Tickets verzichtet und sofort die Gültigkeit
des Tickets visualisiert wird. So wird der zeitliche Ablauf des Einstiegs der
Fahrgäste optimiert und die Berücksichtigung des Fahrplans gewährleistet.
28/42
Für alle Tarifmodule nach PKM sollte definiert werden, in
welchem Umfeld bzw. auf welchen Geräten sie zum Ein-
satz kommen. Der Inhalt der Module kann unterschied-
liche Ausprägungen aufweisen. Zudem ist auf die
verschiedenen Systeme und Hardware der Aus-
gangsschnittstellen Rücksicht zu nehmen. Bei-
spielsweise kann ein Produktmodul für den Ver-
trieb an den KVP-eigenen Servicestellen
das vollständige Produktsortiment
enthalten. Bei externen Verkaufsstel-
len muss dies nicht der Fall sein und
es kann beispielsweise nur ein einge-
schränktes Produktsortiment zur Verfügung stehen (z. B. keine Ausgabe von
Abos). Der PV sollte die Sortimente innerhalb des Produktmoduls für die
gegebenen Vertriebskanäle entsprechend definieren.
Es ist darauf zu achten, dass die Abstimmung zur Definition
der Geräte zwischen PV, KVP und DL stattfindet. Zur Ver-
einfachung sollte der PV eine Übersicht erstellen, welche
Gerätehersteller mit welchen Gerätetypen im Tarifgebiet
vertreten sind. Dies trägt zur Vereinfachung der Kommu-
nikation bei und gewährleistet mehreren KVP und DL den
zielgerichteten Zugriff auf die entsprechende Schnittstelle.!
Parameter werden nach den definierten Vorgaben im DL-Terminal visuali-
siert und dem Kontrollpersonal, bei einem EKS direkt dem Fahrgast selbst,
angezeigt.
Bei der Darstellung von personenbezogenen Daten sollte der PV einen
Datenschutzbeauftragten, ggf. aus einem größeren VU, als Unterstützung
zu Rate ziehen. Es ist empfehlenswert, die Datenschutzbestimmungen mit
einem Experten diesbezüglich genau abzustimmen.
Bei der Definition der Ausgangsschnittstel-
len sind durch den PV die unterschied-
lichen Geräte und Terminals zu be-
achten. Es kann sinnvoll sein, für
jeden Endgerätetypen die Aus-
gangsschnittstellen separat zu
betrachten und zu definieren, da
beispielsweise die Produktsorti-
mente der Terminals, aber auch
die Geräte selber (z.B. Display-
größe, Funktionen) variieren können.
Abhängig von der jeweiligen Variante der
Datendarstellung können erhebliche Unterschiede zwischen den Definitio-
nen auftreten. Dieses Kapitel legt die verschiedenen Ausgangschnittstellen
dar und zeigt, auf welche Aspekte der PV bei der geräteabhängigen Defini-
tion achten sollte.
AUSGANGSSCHNITT- STELLEN
AUSGANG/ZIELDEFINITION
6
6.1
29/42
te voneinander unterscheiden. Der PV sollte auf die Unter-
schiede zwischen den Geräten eingehen bzw. darlegen, wie
eine Nutzung mit der Einführung eines Tarifmoduls nach PKM
aussieht.
6.1.4 VERTRIEBSGERÄT
(Z. B. FAHRAUSWEISAUTOMAT)
Analog zu den Kontrollgeräten sind auch
hier die verschiedenen Geräteklassen zu
berücksichtigen. Bei der Einführung des
Tarifmoduls nach PKM sollte der PV die
verschiedenen Ausgangsschnittstellen der Vertriebsgeräte im
Produktmodul definieren.
Die verschiedenen Schnittstellen zwischen dem PV und den KVP können mit
der Einführung eines Tarifmoduls deutlich reduziert und vereinheitlicht wer-
den. Dennoch stellt sich vorerst die Frage, wie die aktuellen Schnittstellen
behandelt werden.
Falls Datensätze und Informationen aus älteren Systemen bei der Einführung
eines Tarifmoduls nach PKM übernommen werden sollen, ist durch den PV
sicherzustellen, dass alle Datensätze und Informationen fehlerfrei in ein Tarif-
modul nach PKM überführt werden können.
Nach der Erstellung eines Tarifmoduls nach PKM sind die einzelnen Module
in die KVP- und DL-Systeme zu implementieren.
6.1.1 HINTERGRUNDSYSTEM
An dieser Stelle soll der PV darlegen wie das Tarifmodul
nach PKM im Hintergrundsystem (HGS) zur Anwendung
kommt. Die verschiedenen Hintergrundsysteme sind
direkt mit dem Tarifmodul nach PKM verknüpft. Da
die Systemlandschaften der einzelnen KVP oder DL vonei-
nander abweichen können, gilt es, die Anwendung des Ta-
rifmoduls nach PKM zwischen PV, KVP und DL im Vorfeld abzustimmen. Die
einwandfreie Funktion des HGS unter Einbeziehung des Tarifmoduls nach
PKM sollte für alle verfügbaren Systeme gewährleistet sein.
Der PV soll in diesem Abschnitt darstellen, wie das Tarifmodul nach PKM mit
den jeweiligen HGS agiert, welche Aspekte möglicherweise zu beachten sind
und welche Besonderheiten bei der Nutzung des Tarifmoduls nach PKM mit
dem HGS ggf. zu berücksichtigen sind.
6.1.2 KONTROLLGERÄT PERSONALBEDIENT
(HANDPRÜFGERÄT)
Auch die personalbedienten DL-Terminals sind je nach DL
von unterschiedlicher Natur. Je nach Hersteller und Geräte-
typ unterscheiden sie sich hauptsächlich in den Ressourcen
der Geräte. Die Symbolik sowie die verschiedenen Signale
und Töne können beispielsweise vordefiniert sein. Der PV
sollte die Unterschiede und Besonderheiten bei den Gerä-
ten bei der Integration eines Tarifmoduls nach PKM berück-
sichtigen. In diesem Abschnitt definiert der PV die Nutzung
der DL-Terminals.
6.1.3 KONTROLLGERÄT SELBSTBEDIENT (Z. B. EKS)
Auch bei EKS bzw. selbstbedienten Kontrollgeräten können sich die Sym-
bole, die Darstellung sowie die Ausgangstöne der verschiedenen Endgerä-
1 2 3 c4 5 6 b7 8 9 dö 0 ä k
SCHNITTSTELLEN-DOKUMENT6.2
30/42
Die Einführung des Tarifmoduls nach PKM ist darauf ausgelegt, dass sämt-
liche Systeme und Terminals das standardisierte XML-Format lesen und ver-
arbeiten können. Falls Systeme den Standard „Tarifmodule nach PKM“ nicht
unterstützen, können diese nur über eine Exportfunktion (z.B. des „Produkt-
editors“) mit den notwendigen Daten versorgt werden. Die in Kapitel 3.3
beschriebenen Nachteile des Einsatzes von nicht standardisierten Wegen
bleiben bestehen.
Die Umsetzung der in diesem Dokument dargestellten Aspekte und Inhalte
liegt in den Händen des zuständigen PV. Um ein Tarifmodul nach PKM er-
stellen und einführen zu können, sind die dargestellten Punkte mit Inhalt zu
füllen und vom PV zu realisieren.
Das vorliegende Dokument hat ausschließlich allgemein anleitenden Charak-
ter. Auf Einzelheiten und tarifliche Besonderheiten kann aus diesem Grunde
nicht eingegangen werden. Vielmehr soll dieses Dokument einem struktu-
rierten Ablauf dienlich sein und sowohl zur Information, als auch unterstüt-
zend zur Einführung des Tarifmoduls nach PKM begleitend zu Rate gezogen
werden.
Die detailliertere Vorgehensweise liegt letztendlich immer bei dem zuständi-
gen PV und kann je nach Tarifgebiet und Region deutlich variieren.
Der PV ist aufgrund dieses anleitenden Dokuments in der Lage abschätzen
zu können, welche Aspekte zur Einführung eines Tarifmoduls nach PKM zu
beachten sind und in welchen Dokumenten nähere Definitionen und Hinwei-
se zur jeweiligen Thematik wiederzufinden sind.
ZUSAMMENFASSUNG7Und bei Fragen
helfen w i r immer
gerne wei ter !
31/42
ANLAGE 1Checkliste zur Einführung eines Tarifmoduls nach PKM
Bestehender Teilnahmever-trag mit VDV eTicket Service GmbH & Co KG
Kundenanmeldung im ASM-Tool
Teilnahmevertrag unterschreiben
OrgID beantragen
1
1 a
1 b
1 c
Grundvoraussetzung zur Teil-
nahme am (((eTicket Deutsch-
land ist der Teilnahmevertrag
zwischen PV, KVP sowie DL
und VDV eTicket Service
GmbH & Co KG.
Unternehmen im ASM-Tool on-
line registrieren.
Antrag stellen, ausfüllen, Aus-
druck unterschreiben.
OrgID im ASM-Tool
beantragen.
» Teilnahme an der VDV-KA
» Tarifmodul nach PKM optionaler
Bestandteil des (((eTicket Deutschland
» Voraussetzung zur Bestellung notwendiger
Sicherheitskomponenten (SAMs, Schlüssel,
Zertifikate, Nutzermedien) für Integrations-
tests und Nutzung bereitgestellter Systeme
» ASM im Webportal der VDV eTicket Service
GmbH & Co. KG (asmtool.eticket-deutschland.de)
» Vertragsabschluss durch eigenen VV bzw.
eigenes VU
» OrgID wird zugewiesen und dient in allen
Verträgen und Prozessen als Identifikation
des eigenen Unternehmens
SCHRITT ANFORDERUNG BESCHREIBUNG HINWEIS/DOKUMENT
32/42
Abschluss Werkvertrag „Public Key Infrastructure (PKI)“ mit T-Systems
Bereitstellung der bestehenden Tarifdaten
Bereitstellung nicht digitalisierter Tarif-informationen
1 d
2
2 a
Dieser Werkvertrag ist Voraus-
setzung zur Bestellung von
Zertifikaten.
Zur Einführung eines Tarif-
moduls nach PKM müssen die
bestehenden Tarifierungsdaten
bereitgestellt werden.
Falls keine digitalisierten
Datensätze vorhanden, müssen
die Tarifdaten später händisch
(Vgl. Schritt 4) in das Tool/
Werkzeug(*) zur Erstellung
eines Tarifmoduls nach PKM
eingegeben werden.
Vertragsabschluss für die:
» Nutzung der zentralen Public Key
Infrastruktur
» Dienstleistungen rund um das Keymanage-
ment
» Rahmenbedingungen bei der Bestellung
der SAMs
Detaillierte Anleitung „Checkliste
Teilnahme an der VDV KA“, Version 1.1 vom
30.06.2008
Bereitstellung nicht digitalisierter
Tarifinformationen
SCHRITT ANFORDERUNG BESCHREIBUNG HINWEIS/DOKUMENT
33/42
Beschaffung eines Tools zum Import vorhandener Datensätze
Software zur Erstellung eines Tarifmoduls nach PKM (*)
Verfügbarkeit einer Software
Softwareinstallation
evtl. Lizenzantrag und Benutzerverwaltung
2 b
3
3 a
3 b
3 c
Beschaffung eines Tools/Werk-
zeugs oder Schnittstelle zum
Import vorhandener Datenfor-
mate ohne PKM-Standard.
Geeignetes Tool/Werkzeug zur
Umsetzung von Tarifmodulen
nach PKM.
Kauf oder Lizenzantrag für
eine Software zur
Erstellung eines Produktmo-
duls nach PKM.
Installation der Software.
Wenn eine Lizenz für die Soft-
ware gebraucht wird, muss
diese beim Hersteller erwor-
ben werden. Zusätzlich müs-
sen möglicherweise Nutzer
angelegt und Rechte zugewie-
sen werden.
» Kauf/Lizenzantrag oder auch
Eigenbau einer Import-Schnittstelle
» Bereitstellung digitalisierter
Datensätze der Tarifinformationen
» Abstimmung des Schnittstellen-
formates mit Tool-Anbieter
» Kauf/Lizenzantrag je nach Software und
Hersteller
» Herstellerkontakt zur korrekten Software-
installation
» Herstellerkontakt zum Lizenzerwerb der
Software
SCHRITT ANFORDERUNG BESCHREIBUNG HINWEIS/DOKUMENT
34/42
Import der bereitgestellten Daten
digitalisierte Datensätze ohne PKM-Format
nicht digitalisierte Daten
Entwicklung von Strategien
Testfälle definieren
4
4 a1
4 a2
5
5 a
Import von vorhandenen
Daten in ein Tool/Werkzeug (*)
zur Überführung der Daten in
das PKM-Format.
Migration von vorhandenen
Datensätzen (Tarifprodukten,
-informationen etc.) zur Erstel-
lung eines Tarifmoduls nach
PKM.
Händische Eingabe der
Tarifinformationen.
Produktstrategie (PV)
Kontrollstrategie (PV)
Verkaufsstrategie (PV/KVP)
Erstellen von Testfällen zum
Test der einzelnen Modul-
funktionen.
» je nach Digitalisierungsgrad der Daten (Vgl.
Schritt 4a1 UND/ODER 4a2)
» z.B. Datensätze zu Tarifgebieten, -produkten,
Relationen
» z.B. Datensätze zu Tarifgebieten, -produkten,
Relationen, EFM-Daten
» detaillierte Beschreibung und
Erstellung der einzelnen Strategien
SCHRITT ANFORDERUNG BESCHREIBUNG HINWEIS/DOKUMENT
35/42
Erstellung des Dokuments „Abbildung und Kontrolle von (((eTickets“
Abbildung von Produkten
Differenzierung Barcode-Ticket
Räumliche Definition
6
6 a
6 b
6 c
Dokumentenerstellung mit
dem Inhalt der beschriebenen
Unterkapitel.
Bereitstellung der Tarifdaten
und Algorithmik in Tarifmodul
nach PKM-Standard (Vgl.
„Produkteditor“).
Bereitstellung der Relations-
daten in Tarifmodul nach
PKM-Standard (Vgl. „Produkt-
editor“).
Definition und Beschreibung
eines Barcode-Tickets (PV
entscheidet über KA-Format
im Tarifraum).
Eindeutige Definition des Tarif-
gebietes um den Fahrbereich
für das jeweilige Produkt ge-
nau hinterlegen zu können
(z. B. durch Codierung).
» Hauptdokument mit Basisobjektmodell
(BOM)
» Hauptdokument mit Basisobjektmodell
(BOM) - Definition des TLV EFS (Anlage 1
BOM TLV EFS)
» Spezifikation Nutzermedium (KA NM-
SPEC)
» Spezifikation statischer Berechtigungen für
2D Barcode-Tickets (KA STB-SPEC)
SCHRITT ANFORDERUNG BESCHREIBUNG HINWEIS/DOKUMENT
36/42
technische Beschreibung der Produkte
Kundenschnittstelle
Definition Kontrollprozesses
6 d
6 e
6 f
Erstellung einer Excel-Tabelle
mit den Tabellenblättern:
• TLV Gesamtübersicht TAGs
• TAG-Nutzung bei den einzel-
nen Produkten/Tickets
Beschreibung der Tarifproduk-
te mit Hilfe der TAGs.
Definition der Kundenschnitt-
stelle.
Nutzung von Gerätedaten und
Fahrberechtigungsdaten
festlegen.
Prüfung der zeitlichen
Gültigkeit festlegen.
Prüfung der räumlichen
Gültigkeit festlegen.
Ausgabedaten definieren.
» Hauptdokument mit Basisobjektmodell
(BOM) (KA-BOM-Spec)
» Beispiele AVV, VRR, NRW auf
www.kcefm.de
(bzw. https://www.kcefm.de/downloads/
technische-dokumente/)
» Einheitliche Kundenschnittstelle für ein
mehrstufiges interoperables elektronisches
Fahrgeldmanagement (KA KUSCH-Spec)
» Einheitliche Kundenschnittstelle für ein
mehrstufiges interoperables elektronisches
Fahrgeldmanagement (KA KUSCH-Spec)
SCHRITT ANFORDERUNG BESCHREIBUNG HINWEIS/DOKUMENT
37/42
SCHRITT ANFORDERUNG
Definition der Ausgangsschnittstellen
Bereitstellung von Schnittstellen
7
8
Genaue Definition, auf welchen
Geräten Tarifmodule nach PKM zum
Einsatz kommen:
» Hintergrundsysteme
» personalbedientes DL-Terminal
» automatisches DL-Terminal
» Vertriebsgeräte (Ticketsortiment
je Vertriebsort)
Geeignete Schnittstellen zur
Implementierung der Tarifmodule
nach PKM in DL-/KVP-Systeme.
BESCHREIBUNG HINWEIS/DOKUMENT
*aktuell verfügbare Software (Stand Feb. 2018): „Produkteditor“ vom Fraunhofer-Institut für Verkehrs- und Infrastruktursysteme IVI (Software und Lizenzen über Fraunhofer IVI)
38/42
ANLAGE 2Ausschnitt „TLV Gesamtübersicht TAGs“
REF.-NR. TAG DATEIELEMENT LÄNGE IN BYTE FESTE WERTE DATENQUELLE OHNE PKM
TAG85 - Separate Daten - Berechtigung
TAG DA - Grundlegende Daten
Struktur „Separate Daten - Berechtigung - Statischer produkspezifischer Teil“ (lt. Spec_Stat Ber)
11)
2
3
berBerechtigung_ID
prodProdukt_ID
berGueltigkeitsbeginn
berGueltigkeitsende
TAG 85Länge Separate Daten -
Berechtigung
TAG DALänge Grundlegende Daten -
berBezahlArt.code
efsFahrgastTyp.code
mitnahmeTyp.code4)
mitnahmeAnzahl4)
6
4
4
4
1
1
1
1
1
1
1
1
KVP-Terminal/-System
Liste der Tickettypen
(Verbunddatenaustausch)
KVP-Terminal/-System
KVP-Terminal/-System
KVP-Terminal/-System
KVP-Terminal/-System
Spec_HD_BOM, BezahlArt_CODE
Spec_HD_BOM, KundenType_CODE
Spec_HD_BOM, Profil_CODE
KVP-Terminal/-System
0x85
0xDA
0x11
(Quelle: https://www.kcefm.de/downloads/technische-dokumente/dokumente-vrs-tarif/; Dokument: Anlage Übersicht genutzte Tags beim VRS-Tarif _V_03.04: Tabellenblatt TLV Gesamtübersicht TAGs)
39/42
ANLAGE 3Ausschnitt TAG-Nutzung bei Tickets
TICKET-ART
EIN
ZE
LFA
HR
TEN
PREISSTUFE(N)NICHT ENTWERTETER VERTRIEB
VERTRIEBSWEGE / VARIANTEN DER TAG-AUSWAHL DES TLV
ENTWERTETER VERTRIEB ONLINE-TICKET
(Quelle: https://www.kcefm.de/downloads/technische-dokumente/dokumente-vrs-tarif/; Dokument: Anlage Übersicht genutzte Tags beim VRS-Tarif _V_03.04: Tabellenblatt TLV Gesamtübersicht TAGs)
EinzelTicket Erwachsene
EinzelTicket Erwachsene
EinzelTicket Erwachsene
EinzelTicket Erwachsene
EinzelTicket Erwachsene
EinzelTicket Erwachsene
Kurzstrecke
1a
1b
2a
2b
3
1 1 19 9 95 5 512a
12a
3 3 311 11 117 7 714 142 2 210 10 106 6 613 134 4 412 128 8 815 1516 1617 17
X1)
X1)
X1)
X1)
X1)
X1)
X
X
X
X
X
X
KEIN VERKAUF
KEIN VERKAUF
KEIN VERKAUF
KEIN VERKAUF
KEIN VERKAUF
KEIN VERKAUF
–
–
–
–
–
–
X
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
–2)
–3)
–3)
–3)
–3)
–3)
–
–
–
–
–
–
–
–
–
–
–
–
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
X
X
X
X
X
X
X
X
X
X
X
X
–
–
–
–
–
–
–
–
–
–
–
–
X
X
X
X
X
X
–
–
–
–
–
–
–
–
–
–
–
–
–
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
40/42
41/42
WER MACHT WAS? Das Rollenmodell der VDV-Kernapplikation
Kunden/Fahrgast
Produktverantwortlicher PV
Applikationsherausgeber AH
Dienstleister DLKundenvertragspartner KVP
Rollen
Aufgaben
HG Systeme
Front-End
Vertrag
Kunden-service
KVP-SYSTEM PV-SYSTEM
ZENTRALE VERMITTLUNG ZVM/ION
DL-SYSTEM
Vertrieb Daten-erfassung KontrolleClearing Moni-
toringTarif-
Management
Zahler
Chipkarten
POS-Terminals
ASMT Zert. Labor Schlüssel PKI KOSESVP-DiagrammeXML, XSD, WSDL
Verkaufs-automaten
Tarifmodule nach PKM(Produkt- und Kontrollmodule)
Erfassungs-geräte
Kontroll-geräte
Barcode .........Smart-phones
Nutzer Vertrags-schließender
Registrar Applikations-management
Sicherheits-managementZertifizierung Sperrlisten
Daten
Testsuite
IMPRESSUM
HERAUSGEBER
VDV eTicket Service GmbH & Co. KG
Im Mediapark 8a
50670 Köln
REDAKTION
Daniel Ackers
TEXT
Jonas Doil
rku.it GmbH
Westring 301
44629 Herne
GESTALTUNG
Yvonne Tamme
42/42