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