Leistungsbeschreibung (PDF, 629 kB) - KCEFM

) 

G:\KCEFM\Projekte\d(((eti\Ausschreibung\Ausschreibungsunterlagen\Leistungsbeschreibung d(((eti 1_0.docG:\KCEFM\Projekte\d(((eti\Ausschreibung\Leistungsbeschreibung\Leistungsbeschreibung d(((eti 0_1.doc 

Distribution von eTickets 

über das Internet 

d(((eti 

Leistungsbeschreibung

Distribution von eTickets über das Internet d(((eti - Leistungsbeschreibung Seite 2 

1 Allgemeines 

1.1 Inhaltsverzeichnis 

Kapitel Seite 

1 Allgemeines.......................................................................................................................2 

1.1 Inhaltsverzeichnis ......................................................................................................2 

1.2 Abbildungsverzeichnis ...............................................................................................5 

1.3 Tabellenverzeichnis ...................................................................................................5 

1.4 Abkürzungen..............................................................................................................6 

1.5 Glossar.......................................................................................................................7 

2 Vorstellung des Auftraggebers: VRR und KCEFM..........................................................10 

2.1 Verkehrsverbund Rhein-Ruhr ..................................................................................10 

2.2 Kompetenzcenter elektronisches Fahrgeldmanagement (KCEFM).........................10 

3 Projektbeschreibung .......................................................................................................11 

3.1 Umfeld: Vertrieb und Elektronisches Fahrgeldmanagement ...................................11 

3.2 Motivation.................................................................................................................12 

3.2.1 Warum d(((eti?..................................................................................................12 

3.2.2 Gründe für die Realisierung als Open-Source-Software ..................................12 

3.3 Funktion ...................................................................................................................13 

3.4 Erläuterung der drei Arbeitspakete ..........................................................................14 

3.5 Technische Grundlagen und Rahmenbedingungen ................................................15 

3.5.1 Dokumente KA..................................................................................................15 

3.5.2 Dokumente KCEFM..........................................................................................17 

4 Allgemeine Beschreibung der Aufgabenstellung ............................................................18 

4.1 Das Rollenmodell der VDV-Kernapplikation ............................................................18 

4.2 Übersicht Systemarchitektur d(((eti..........................................................................19 

4.3 Beschreibung des Pakets d(((eti-API.......................................................................21 

4.4 Beschreibung des Pakets d(((eti-eTicket-Viewer.....................................................22 

4.5 Beschreibung des Pakets d(((eti-System.................................................................23 

4.6 Pflichtenheft .............................................................................................................25 

4.7 Rechte an der Software / Veröffentlichung unter Open–Source-Lizenz ..................26 

5 Projektabwicklung ...........................................................................................................27 

5.1 Durchführung ...........................................................................................................27 

5.1.1 Projektleiter Auftragnehmer ..............................................................................27 

5.1.2 Projektgespräche..............................................................................................27 

5.1.3 Protokollführung................................................................................................27 

5.2 Mitwirkungsleistungen..............................................................................................27 

5.2.1 Testmaterial ......................................................................................................27 

5.2.2 Abnahmeprüfungen ..........................................................................................27 

5.3 Qualitätssicherung ...................................................................................................27 

5.4 Vorschriften, Richtlinien, Normen ............................................................................28 

5.5 Besondere Hinweise ................................................................................................28 

5.5.1 Templates, Produkt- und Kontrollmodule .........................................................28 

5.5.2 Benachbarte Systeme ......................................................................................29 

5.5.3 Interoperabilitätsnetzwerk.................................................................................29 

5.5.4 Hinweise zum Datenaustausch zwischen KVPS und KVPT sowie DLS und DLT 

30 

5.5.5 TestSuite der VDV-Kernapplikation ..................................................................30 

Version 1_0 - Stand: 7.4.2009


6 Spezifizierung der Software ............................................................................................31 

6.1 Allgemeine Eigenschaften der d(((eti-Software .......................................................31 

6.1.1 Portabilität.........................................................................................................31 

6.1.2 Programmierung ...............................................................................................31 

6.1.3 Benutzbarkeit (usability) und Softwareergonomie ............................................32 

6.1.4 Genutzte ISO 14443 Schreib-/Lesegeräte........................................................32 

6.2 d(((eti-API.................................................................................................................33 

6.2.1 Technische Eigenschaften................................................................................33 

6.2.2 Umfang der gesamten API-Funktionalität.........................................................34 

6.2.2.1 Hinweise zur „Schnittstellenspezifikationen der Referenzsysteme…“ 

[Spec_SST_V1106] und den Systemlastenheften ......................................................36 

6.2.2.1.1 Korrekturen bei den Elementarprozessen in der [Spec_SST_V1106]...36 

6.2.2.1.2 Korrekturen bei den Anwendungsfällen im Systemlastenheft KVPS 

[SYSLH_KVPS_V1106] ...........................................................................................36 

6.2.2.1.3 Korrekturen bei den Anwendungsfällen im Systemlastenheft DLS 

[SYSLH_DLS_V1106]..............................................................................................37 


[SYSLH_KVPS_V1106] hinsichtlich der Weiterleitung der Sperrnachweise 

ausgehend vom KOSE: ...........................................................................................37 

6.2.2.2 Elementarprozesse....................................................................................38 

6.2.2.3 Anwendungsfälle .......................................................................................40 

6.2.2.3.1 Anwendungsfälle KVP- und DL-Server..................................................40 

6.2.2.3.2 Anwendungsfälle KVP-Terminal ............................................................42 

6.2.2.4 Schnittstellen .............................................................................................44 

6.2.2.4.1 Schnittstelle KVPS – KVP-Terminal.......................................................44 

6.2.2.4.2 Schnittstelle KOSES - KVPS .................................................................48 

6.2.2.4.3 Schnittstelle AHS – KVPS......................................................................52 

6.2.2.4.4 Schnittstelle PVS - KVPS.......................................................................56 

6.2.2.4.5 Schnittstelle KVPS – KVPS ...................................................................60 

6.2.2.4.6 Schnittstelle DLS - KVPS.......................................................................64 

6.2.2.4.7 Schnittstelle DLS – DL-Terminal............................................................68 

6.2.2.4.8 Schnittstelle KOSES - DLS ....................................................................71 

6.2.2.4.9 Schnittstelle AHS - DLS .........................................................................74 

6.2.2.4.10 Schnittstelle PVS - DLS .......................................................................77 

6.2.2.4.11 Schnittstelle KVPS – DLS ....................................................................79 

6.2.3 Umfang der zwei Entwicklungsphasen .............................................................83 

6.3 d(((eti-eTicket-Viewer...............................................................................................84 

6.3.1 Funktion ............................................................................................................84 

6.3.2 Bedienung.........................................................................................................84 

6.3.3 Konfiguration.....................................................................................................84 

6.3.4 Online-Hilfe .......................................................................................................85 

6.3.5 Design...............................................................................................................85 

6.4 d(((eti-System ..........................................................................................................86 

6.4.1 Funktion des Gesamtsystems ..........................................................................86 

6.4.2 Mögliche Systemarchitektur..............................................................................86 

6.4.3 Automatisch erstellte Protokolle / Logging........................................................88 

6.4.4 Kundendaten ....................................................................................................90 

6.4.5 Berechtigungsdaten..........................................................................................92 

6.4.6 Chipkarten- / Nutzermediendaten.....................................................................92 

6.4.7 Bedienung.........................................................................................................93 

6.4.7.1 Bedienung durch Endkunden ....................................................................94 



6.4.7.2 Bedienung durch Vertriebspersonal ..........................................................94 

6.4.7.3 Bedienung durch die KVP-Verantwortlichen .............................................94 

6.4.7.4 Bedienung durch den DL-Verantwortlichen...............................................95 

6.4.7.5 Bedienung durch Administratoren des d(((eti-Servers ..............................95 

6.4.8 Hilfetexte in den Programmen ..........................................................................96 

6.4.9 Design...............................................................................................................96 

6.4.10 Installation.........................................................................................................97 

6.4.10.1 Installation des d(((eti-Servers...................................................................97 

6.4.10.2 Installation der Client-Software..................................................................97 

7 Dokumentation ................................................................................................................98 

7.1 Allgemeines .............................................................................................................98 

7.2 Dokumentation d(((eti-API .......................................................................................98 

7.3 Dokumentation d(((eti-eTicket-Viewer .....................................................................98 

7.4 Dokumentation d(((eti-System .................................................................................99 

7.4.1 Installationsanleitung d(((eti-System.................................................................99 

7.4.2 Administrationshandbuch .................................................................................99 

7.4.3 Handbuch für KVP-Verantwortliche ................................................................100 

7.4.4 Handbuch für DL-Verantwortliche...................................................................100 

7.4.5 Handbuch für Vertriebsmitarbeiter..................................................................100 

7.4.6 Handbuch für Endkunden ...............................................................................100 

8 Lieferumfang .................................................................................................................101 

9 Literatur.........................................................................................................................102 



1.2 Abbildungsverzeichnis 

Abbildung 1 d(((eti als eTicketserver......................................................................................14 

Abbildung 2 Das VDV-KA-Rollenmodell und d(((eti ...............................................................18 

Abbildung 3 Das d(((eti-System mit Schnittstellen .................................................................19 

Abbildung 4 Schnittstellen von d(((eti zu anderen KA-Systemen...........................................20 

Abbildung 5 Die Hierarchie der d(((eti-Nutzer ........................................................................23 

Abbildung 6 Aufteilung der Endzertifikate ..............................................................................34 

Abbildung 7 Einstufiges Authentisierungsverfahren...............................................................35 

Abbildung 8 Zweistufiges Authentisierungsverfahren ............................................................35 

Abbildung 9 Weiterleitung der Sperrnachweise durch den KOSE .........................................38 

Abbildung 10 Mögliche Architektur des d(((eti-Systems.........................................................87 

1.3 Tabellenverzeichnis 

Tabelle 1 Elementarprozesse.................................................................................................39 

Tabelle 2 Anwendungsfälle KVP- und DL-Server ..................................................................40 

Tabelle 3 Anwendungsfälle KVP-Terminal.............................................................................42 

Tabelle 4 Anwendungsfälle KVP-Server und -Terminal .........................................................44 

Tabelle 5 Anwendungsfälle KOSE und KVP-System.............................................................48 

Tabelle 6 Anwendungsfälle AH und KVP-System..................................................................52 

Tabelle 7 Anwendungsfälle PV- und KVP-System.................................................................56 

Tabelle 8 Anwendungsfälle zwischen zwei KVP-Systemen...................................................60 

Tabelle 9 Anwendungsfälle KVP- und DL-System .................................................................64 

Tabelle 10 Anwendungsfälle DL-System und -Terminal ........................................................68 

Tabelle 11 Anwendungsfällle KOSE und DL-System.............................................................71 

Tabelle 12 Anwendungsfälle AH-System und DL-System .....................................................74 

Tabelle 13 Anwendungsfälle PV-System und DL-System .....................................................77 

Tabelle 14 Anwendungsfälle KVP-System und DL-System ...................................................80 



1.4 Abkürzungen 

AFB Automatische Fahrtberechtigung 

AH Applikationsherausgeber 

AHS AH-Server 

API Application Programming Interface 

AUTH Authentisierung 

CA Certification Authority 

CR Change Request 

d(((eti Distribution von eTickets über das Internet 

DL Dienstleister 

DLS DL-Server 

DLT DL-Terminal 

EFM elektronisches Fahrgeldmanagement 

EFS elektronischer Fahrschein 

GPL Gnu Public License 

GUI graphische Nutzungsoberfläche 

HGS Hintergrundsystem 

ION Interoperabilitätsnetzwerk 

JDK Java Developement Kit 

KA VDV-Kernapplikation 

KCEFM Kompetenzcenter elektronisches Fahrgeldmanagement 

KOSE Kontrollservice 

KOSES KOSE-Server 

KPRIV Privater Teil eines asymmetrischen Schlüsselpaares 

KPUB Öffentlicher Teil eines asymmetrischen Schlüsselpaares 

KVP Kundenvertragspartner 

KVPS KVP-Server 

KVPT KVP-Terminal 

KVSHA Kreisverkehr Schwäbisch Hall 

KVSHA Kreisverkehr Schwäbisch Hall 

LGPL Lesser General Public License 

NFC Near Field Communication 

NM Nutzermedium 

ÖPNV Öffentlicher Personennahverkehr 

OrgID Organisation-ID 

ÖV Öffentlicher Verkehr 

PKI Public Key Infrastructure 

PV Produktverantwortlicher 

PVS PV-Server 

SAM Security Application Module (Sicherheitsmodul) 

Sub-CA Sub-Certification Authority 

VDV Verband deutscher Verkehrsunternehmen 

VDV-KA KG VDV Kernapplikations GmbH & Co. KG 

VGN Verkehrsgemeinschaft Niederrhein 

VRR Verkehrsverbund Rhein-Ruhr AöR 

VRS Verkehrsverbund Rhein-Sieg 

VU Verkehrsunternehmen 



1.5 Glossar 

Die Autoren der vorliegenden Leistungsbeschreibung haben Fachsprache der 

Informationstechnik, des ÖPV-Vertriebs und der VDV-Kernapplikation ausgiebig gebraucht. 

Dies war notwendig, um ohne sprachliche Brüche auf bestehende und für d(((eti 

grundlegende Dokumente verweisen zu können. Im Glossar sind alle Worte dieser 

Fachsprachen erklärt, damit auch Leser, welche im eTicketing Deutschland nicht zu hause 

sind, den Text erfassen können. 

Applikationsherausgeber 

Im Rollenmodell der VDV-Kernapplikation räumt der Applikationsherausgeber interessierten 

Unternehmen das Rechts zur Teilnahme am (((eTicket-Deutschland (Akkreditierung/Registrierung) 

ein. Er trägt die Verantwortung für die Systemsicherheit. 

Berechtigungen 

Eine Berechtigung ist in der Regel ein Fahrschein (Fahrtberechtigung) auf einem elektronischen 

Nutzermedium 

Certification Authority (CA) 

Im Rahmen der Public Key Infrastructure erstellt ein sogenanntes TrustCenter als Zertifizierungsdienstleister 

(Certification Authority, CA) Zertifikate und bestätigt damit die Zugehörigkeit 

eines öffentlichen Schlüssels zum Zertifikatsinhaber. Die CA dient als vertrauenswürdige 

Instanz. 

Change Request (CR) 

Anforderung der Änderung eines normativen technischen Textes. 

Debian 

Freies Betriebssystem. Debian verwendet den Linux-Betriebssystemkern, aber die meisten 

grundlegenden Systemwerkzeuge stammen vom GNU-Projekt. 

d(((eti 

Software zur Ausgabe von eTickets über das Internet, Verwaltung von Daten für DL- 

Terminals und Auslesen von KA-Nutzermedien. 

d(((eti-API 

Programmbibliothek zur Interaktion verschiedener KA-(Sub)Systeme. 

d(((eti-Server 

Der Teil des d(((eti-Systems, welcher auf dem Rechner des KVP/DL läuft. 



d(((eti-System 

Software zur Ausgabe von eTickets über das Internet und zur Datenver- und Entsorgung von 

DL-Terminals (Prüfgeräten). Zum d(((eti-System gehören der d(((eti-Server und die Software 

auf dem Client-Rechner, welche die Ausgabe von eTickets ermöglicht. 

d(((eti-eTicket-Viewer 

Programm zum Auslesen von KA-Nutzermedien und Interpretation der Daten für Fahrgäste 

und Servicepersonal. 

Dienstleister 

Im Rollenmodell der VDV-Kernapplikation ist ein Dienstleister in der Regel ein Verkehrsunternehmen, 

das zwar Tickets kontrolliert, jedoch nicht selbst vertreibt. 

Elementarprozess 

In der Spezifikation der Kernapplikation beschriebene Interaktion zwischen (Teil)Systemen 

der Kernapplikation. 

Fedora 

Fedora ist ein Betriebssystem, basierend auf Linux, das freie und Open-Source-Software 

enthält. 

Hintergrundsystem 

Hintergrundsysteme Halten die Kundendaten vor und regeln das Sperrdatenmanagement 

ISO 14443 

In der Norm ISO 14443 werden die physikalischen und datentechnischen Eigenschaften der 

Übertragungsstrecke zwischen Lesegerät und kontaktlosen Chipkarten (PICC) spezifiziert. 

Es handelt sich dabei um die PICC-Karten mit geringer Reichweite bis zu etwa 15 cm. Diese 

Chipkarten werden vorwiegend im Ticketing eingesetzt. 

KOSE 

Der Kose (Kontrollservice) ist das geplante bundesweite Sperrlistenmanagement der VDV 

KA KG (siehe: Sperr- und Meldedaten / Sperrnachweise). Der KOSE wird voraussichtlich 

Mitte 2010 seinen Betrieb aufnehmen. 

Kundenvertragspartner 

Im Rollenmodell der VDV-Kernapplikation ist ein Kundenvertragspartner in der Regel ein 

Verkehrsunternehmen, das neben der reinen Kontrolle auch selbst Tickets vertreibt. 

NFC-Handy 

Mobiltelefon, welches über eine NFC-Schnittstelle (Near Field Communication) verfügt, über 

die Daten auf einer Distanz von bis zu zehn Zentimeter übertragen werden können. Im 



ÖPNV finden NFC-Handys derzeit Anwendung beim Handyticket des Rhein-Mainverkehrsverbundes, 

beim Projekt „Touch&Travel“ der deutschen Bahn, sowie auf einer Pilotstrecke 

der Österreichischen Bundesbahn. 

Organisationen 

Unter Organisationen sind gemäß VDV Kernapplikationin der Regel Verkehrsunternehmen 

gemeint. Sie werden durch eine spezifische Organisationsnummer, der sog. OrgID 

gekennzeichnet. 

Produkte 

Produkte sind unterschiedliche Ticket, die zu einem Ticketsortiment zusammengefasst werden. 

Produktverantwortlicher 

Im Rollenmodell der VDV-Kernapplikation ist ein Produktverantwortlicher in der Regel ein 

Verkehrsverbund, der ein Ticketsortiment entwickelt. 

Public Key Infrastructure (PKI) 

Die PKI ist das Sicherheitssystem der VDV-Kernapplikation. Im Rahmen der Public Key 

Infrastructure erstellt ein sogenanntes TrustCenter als Zertifizierungsdienstleister (Certification 

Authority, CA) Zertifikate und bestätigt damit die Zugehörigkeit eines öffentlichen Schlüssels 

zum Zertifikatsinhaber. Die CA dient als vertrauenswürdige Instanz. 

Sicherheitsmodul (SAM) 

Die Sicherheitsmodule enthalten die symmetrischen und unsymmetrischen Schlüssel. Die 

SAM dienen zur Authentisierung, zur Signatur von Datensätzen und zur Ver- und Entschlüsselung 

von Kryptogrammen zur Konfiguration der symmetrischen Schlüssel im SAM. 

Sperr- und Meldedaten / Sperrnachweise 

Die Sperr- und Meldedaten Enthalten Informationen über gesperrte,bzw. markierte Tickets. 

Sie werden täglich über eine Sperrliste aus dem Hintergrundsystem in die Kontrollgeräte 

überspielt. 

Template 

Schema für ein Tarifprodukt, welches in einer Berechtigung abgebildet wird. 



2 Vorstellung des Auftraggebers: VRR und KCEFM 

2.1 Verkehrsverbund Rhein-Ruhr 

Die Verkehrsverbund Rhein-Ruhr AöR (VRR) ist einer von drei nordrhein-westfälischen 

ÖPNV-Kooperationsräumen und erstreckt sich vom Niederrhein über das Rhein-Ruhrgebiet 

bis hinein ins Bergische Land. Die Kooperationsräume sind unter Anderem Aufgabenträger 

und in dieser Funktion für die Planung, Organisation und Ausgestaltung des öffentlichen 

Nahverkehrs in den jeweiligen Räumen verantwortlich. 

Zum Kernverbundgebiet des VRR gehören 27 kommunale Verkehrsunternehmen und fünf 

Eisenbahnverkehrsgesellschaften an, für die der VRR als Verbundgesellschaft die Tarife 

entwickelt, die Produkte vermarktet sowie die verbundweite Presse- und Öffentlichkeitsarbeit 

organisiert. Außerdem wirkt der VRR im Sinne der Fahrgäste auf die Einhaltung der Qualitäts- 

und Servicestandards bei den Verkehrsunternehmen hin. Der VRR hat seinen Verwaltungssitz 

in Gelsenkirchen, der Sitz der VRR AöR ist Essen. 

Weitere Informationen finden sich unter www.vrr.de. 

2.2 Kompetenzcenter elektronisches Fahrgeldmanagement (KCEFM) 

Die fünf nordrhein-westfälischen Kompetenzcenter wurden zur landesweiten Koordination 

und Weiterentwicklung von überregionalen bzw. technisch anspruchsvollen Aufgaben des 

ÖPNV eingerichtet. Zur Nutzung von Synergien sind sie bei Verkehrsverbünden bzw. Verkehrsunternehmen 

angesiedelt. Das Kompetenzcenter Elektronisches Fahrgeldmanagement 

(KCEFM) ist in die Verwaltungsstruktur des VRR eingegliedert. 

Zentrale Aufgabe ist die Abstimmung von technischen Standards bei elektronischen Tickets. 

Hier setzt das KCEFM auf die VDV-Kernapplikation (KA) (siehe: www.vdv-ka.de). Die Partner 

des KCEFM (Zweckverbände, Verkehrsverbünde, -gemeinschaften und -unternehmen in 

NRW) profitieren von der Zusammenarbeit mit dem Kompetenzcenter unter anderem durch 

personelle und konzeptionelle Unterstützung bei der Einführung und Weiterentwicklung des 

eTickets. 

Der Internetadresse des KCEFM lautet www.kcefm.de. 



3 Projektbeschreibung 

3.1 Umfeld: Vertrieb und Elektronisches Fahrgeldmanagement 

Seit 2003 wird in drei Verbünden in Nordrhein-Westfalen eTicketing betrieben. Der VRR, der 

Verkehrsverbund Rhein-Sieg (VRS) und die Verkehrsgemeinschaft Niederrhein (VGN) statteten 

die Abonnenten ihrer Verkehrsunternehmen (VU) damals mit Chipkarten der proprietären 

Paycard-Technologie aus. Die Paycard verfügt über eine kontaktlose und eine kontaktgebundene 

Schnittstelle. 

Im Jahre 2005 wurde mit der VDV-Kernapplikation ein bundesweiter Standard für das elektronische 

Fahrgeldmanagement (EFM) geschaffen. Die drei Verbünde beschlossen, anlässlich 

der nächsten fälligen Beschaffung von Chipkarten zum neuen Standard zu migrieren. 

Dies geschah zu Beginn des Jahres 2007. 

Mittlerweile sind in NRW rund zwei Millionen Fahrgäste mit Chipkarten ausgestattet. Zurzeit 

sind sowohl Paycards als auch Chipkarten nach KA-Standard im Markt. Die Paycards sollen 

bis 2012 von KA-Karten komplett abgelöst werden. 

Hauptgrund für die Einführung des EFM war die größere Gesamtwirtschaftlichkeit des eTicketings 

gegenüber den überkommenen Formen des Abonnements. 

Die Gründe für die Migration zur VDV-Kernapplikation waren vielfältig: 

� Das bis dahin eingesetzte proprietäre Paycard-System sollte durch eine offene Technologie 

ersetzt werden. Die Abhängigkeit von einem einzelnen Hersteller sollte 

gebrochen werden. 

� Vom Einsatz des Standards wurden mittelfristig günstigere Preise für Nutzermedien 

(NM, z.B. Chipkarten) und Terminals erwartet. Die Hersteller stehen in einem stärkeren 

Wettbewerb. 

� Ein Standard verspricht die Möglichkeit der Interoperabilität zwischen den verschiedenen 

Verkehrsräumen und –unternehmen, welche ihn einsetzen. 

Die Interoperabilität des EFM wird für Kunden erst dann erlebbar, wenn sie mit dem in ihrem 

Verbund verwendeten Nutzermedium (NM), auch andernorts am eTicketing für den ÖV teilnehmen 

können. 

Fahrten in anderen Regionen des Landes gehören für die allermeisten ÖV-Nutzer nicht zum 

Alltag. Für diese Art von Reisen gewinnen Recherche von Fahrplänen und der Erwerb von 

Tickets über das Internet zunehmend an Bedeutung. Dies zeigt u.a. die Nutzung von Fahrplanauskünften 

und Vertriebssystemen z.B. für Bahn- und Flugtickets im Internet. 

Der Bezug von eTickets via Internet stellt damit eine konsequente Erweiterung der modernen, 

individuellen Reise- und Fahrtplanung dar, welche den existierenden EFM-Systemen 

bislang fehlt. 



3.2 Motivation 

3.2.1 Warum d(((eti? 

Die Ausgabe elektronischer Tickets auf Nutzermedien ist im EFM in NRW und anderswo 

bisher ausschließlich an den Ausgabestellen der Verkehrsunternehmen (z.B. Kundencentern) 

oder bei mit Spezialgeräten ausgerüsteten Dienstleistungsunternehmen (Massenpersonalisierer) 

möglich. Sie ist in der Regel mit der Haltung der Kundendaten integriert. Damit 

sind in der Praxis eTicket-Ausgabegeräte immer Teile von aufwändigen Hintergrundsystemen 

(HGS). 

Dies erfordert investitionsintensive Geräte und Software sowie Sicherheitsmodule (SAMs) 

vor Ort. In der Konsequenz ist die Beschaffung solcher Systeme nur für Unternehmen wirtschaftlich 

sinnvoll, welche größere Mengen von eTickets ausgeben. 

Ein ähnliches Bild ergibt sich bei der Kontrolle von eTickets: Die Datenver- und -entsorgung 

der eigentlichen Kontrollgeräte ist bei existierenden Systemen stark in die oben beschriebenen 

Hintergrundsysteme integriert. 

Die Schwelle zum Einsatz von EFM nach KA, sei es als Kundenvertragspartner (KVP) oder 

als Dienstleister (DL), ist damit für kleinere Unternehmen sehr hoch. 

All diese Probleme lassen sich durch ein System lösen, welches die aufwändigen und teuren 

Geräte zentral vorhält und sie den Verkehrsunternehmen bei Bedarf zur Verfügung stellt. 

Der Aufwand für teilnehmende VU beschränkt sich auf die Beschaffung von Rechnern und 

ISO 14443-Schreib/Lesern, Kontrollgeräten, die per Internet Sperr- und Meldedaten austauschen 

können und die Internet-Verbindungskosten. 

Die Einführung von Chipkarten als Träger von eTickets bringt für Fahrgäste eventuell eine 

Informationslücke mit sich: Das eigentliche Ticket ist mit bloßem Auge nicht zu überprüfen. 

Die Frage nach Gültigkeitsdauer und –räumen ist damit für Kunden nicht mehr unbedingt zu 

beantworten, wenn der Inhalt des Nutzermediums nicht ausgelesen wurde. Dies behebt eine 

Software, welche in Verbindung mit einem Leser nach ISO 14443 Nutzermedien ausliest und 

die vorgefundenen Daten interpretiert. 

Zusätzlich zu den bisher dargestellten sind noch andere Anwendungen denkbar: 

� Mit Hilfe von NFC-Handys können eTickets von mobilem Servicepersonal nahezu 

überall an Kunden ausgegeben werden. 

� NFC-Handys mit multiapplikationsfähigen SIM-Karten könnten eTickets direkt über 

GPRS / Internet beziehen. 

� Entsprechend ausgestattete Servicepartner der Verkehrsunternehmen könnten Nutzermedien 

lesen und Auskunft über eTickets geben. 

3.2.2 Gründe für die Realisierung als Open-Source-Software 

Als Open-Source-Software bezeichnet man Software, deren Quelltext (engl. Source Code) 

frei zugänglich ist und die von jedermann bearbeitet, weiter entwickelt, kopiert und verbreitet 



werden darf, ohne dass Lizenzkosten anfallen. (Bekannte Produkte: Linux, OpenOffice.org, 

Firefox) 

Die Nutzung von Open-Source-Software wird – wie bei vielen anderen Software-Produkten 

auch – durch Lizenzen geregelt. Die bekannteste und zurzeit wohl bedeutendste Open- 

Source-Lizenz ist die GNU General Public License (GPL). 

Open-Source-Software wird immer dann eingesetzt, wenn Programme nach dem Willen des 

Autors oder seines Auftraggebers gratis und frei verfügbar sein sollen. Zusätzlich erhoffen 

sich Autoren bzw. deren Auftraggeber, dass andere Autoren das jeweilige Programm weiter 

entwickeln. 

Drei Gründe sprechen für die Entwicklung von d(((eti als Open-Source-Software: 

� Bereits existierende Open-Source-Programme, wie eine Datenbank, ein CRM- 

System, ein Webserver oder ein Web-Shop-System können kostenlos integriert werden. 

Dies hält die Entwicklungskosten niedrig und die Entwicklungszeit kurz. 

� Das resultierende System ist quelloffen und kann daher von jedem Interessenten weiterentwickelt 

und gepflegt werden. Wenn kommerzielle Anbieter modifizierte Versionen 

von d(((eti verkaufen möchten, so müssen sie – die Wahl der passenden Lizenz 

vorausgesetzt – die Veränderungen und Neuentwicklungen offen legen. 

� Wie die meiste quelloffene Software soll auch d(((eti gratis verteilt werden. Damit beschränken 

sich die Kosten für den Einsatz von d(((eti auf Hardware, Administration, 

Telekommunikation und Anpassung (z.B. Lokalisierung, Corporate Identity). Dies bewirkt 

eine drastische Senkung der Schwelle zum wirtschaftlichen Betrieb eines solchen 

Systems. 

Zudem wird das Dilemma, welches staatliche Förderung in der Software-Entwicklung mit 

sich bringt, durch Open-Source-Software aufgehoben: Die Entwicklung verbleibt nicht im 

Besitz einer Herstellerfirma oder der geförderten Stelle, sondern kommt allen Interessenten 

und damit der Allgemeinheit zu Gute. 

3.3 Funktion 

d(((eti ist, wie schon der Name sagt, ein System zur Ausgabe von elektronischen Fahrscheinen 

(EFS) nach KA über das Internet. Die eigentliche Ausgabe kann über einen preiswerten 

Rechner mit Internetanschluss und einem preiswerten Schreib-/Leser nach ISO 14443 geschehen. 

Ein Server in der Hand eines Kundenvertragspartners verwaltet ein oder mehrere 

SAM. 



Abbildung 1 d(((eti als eTicketserver 

Hinzu kommt ein komplettes Vertriebssystem für elektronische Fahrausweise, eine Software 

zum Lesen von Nutzermedien und eine Programmierschnittstelle, welche die Entwicklung 

von Software zum Lesen und Schreiben von KA-Nutzermedien stark vereinfacht. 

In der Terminologie der Kernapplikation heißt das, dass das d(((eti-System die Funktion eines 

Kundenvertragspartner-Servers, eines KVP-Terminals und eines Dienstleister-Servers 

integriert Dabei wird die Funktion des Kundenvertragspartner-Terminals auf verschiedene 

Rechner im Internet verteilt: Die Bedienelemente, wie Tastatur und Bildschirm, werden von 

einem internetfähigen Client-PC verkörpert. Den Rest der Terminalfunktionen steuert ein 

Server bei. 

3.4 Erläuterung der drei Arbeitspakete 

Gegenstand dieser Leistungsbeschreibung ist die Entwicklung und Lieferung eines Open- 

Source-Software-Systems zur Distribution von elektronischen Tickets nach VDV- 

Kernapplikation über das Internet. Als Beiprodukte sollen eine Bibliothek für Kernapplikationsfunktionen 

und ein Ausleseprogramm für KA-Nutzermedien entwickelt werden. 

Diese Aufgabenstellung legt die Entwicklung der Software in drei Paketen nahe: 

Paket 1: d(((eti-API (Application Programming Interface) – Erstellung einer OpenSource API 

mit zugehörigen Bibliotheken für alle Anwendungsfälle, welche nach KA- 



Schnittstellenspezifikationen [Spec_SST_V1106] zwischen KVP-Server, DL-Server, KVP- 

Terminal, DL-Terminal, SAM, Nutzermedium, PV-Server und KOSE-Server auftreten können. 

Paket 2: d(((eti-eTicket-Viewer – Erstellung eines Open-Source-Programms zum Auslesen 

von eTickets nach Kernapplikation an einfachen ISO 14443-Leser/Schreibern. Der d(((eti- 

Viewer implementiert bestimmte Funktionen eines selbstbedienten KVP-Terminals. 

Paket 3: d(((eti-System – Entwicklung und Test eines mandantenfähigen Vertriebssystems 

zur Distribution von eTickets nach VDV-Kernapplikation über das Internet und zur Datenver- 

und -entsorgung von Kontrollgeräten. Damit implementiert das d(((eti-System das selbst- und 

personalbediente KVP-Terminal. 

d(((eti-Viewer und d(((eti-System basieren auf der d(((eti-API. Die d(((eti-API soll zunächst 

soweit entwickelt werden, dass der d(((eti-Viewer darauf programmiert werden kann. Der 

Rest der d(((eti-API kann im Zuge der Entwicklung des d(((eti-Systems entwickelt werden. 

3.5 Technische Grundlagen und Rahmenbedingungen 

Die Kenntnis der folgenden Dokumente ist zum Verständnis der Leistungsbeschreibung und 

des Auftragsgegenstandes unerlässlich. 

Sollten Dokumente in mehreren Versionen vorliegen, so gelten die bei der Veröffentlichung 

der Ausschreibung gültigen Versionen. Zusätzlich gilt für Dokumente der VDV- 

Kernapplikation, dass Change Requests (CR), welche bis zur Veröffentlichung dieser Ausschreibung 

von der VDV Kernapplikations GmbH & Co. KG (VDV-KA KG) offiziell freigegeben 

und veröffentlicht worden sind, umzusetzen sind. 

Die Beschaffung der hier aufgeführten Dokumente obliegt dem Auftragnehmer. 

Einige Dokumente können lediglich gegen Schutzgebühr bezogen werden. Die Gebühren 

sind vom Auftragnehmer selbst zu tragen. 

3.5.1 Dokumente KA 

d(((eti implementiert Teile eines EFM-Systems nach VDV-Kernapplikation. 

Daher sind die Spezifikationen und Systemlastenhefte der VDV-Kernapplikation in Gänze zu 

beachten. 

Insbesondere sind die folgenden Spezifikationen und Systemlastenhefte der VDV- 

Kernapplikation von besonderer Bedeutung: 

� VDV-Kernapplikation Glossar [KA_Glossar_V1106] 

� KA_Technische Spezifikation, Hauptdokument mit Basisobjektmodell (BOM) 

[Spec_HD_BOM_V1106] 

� Erweiterung Mobiles Ticketing, Applikation und Übertragungsprotokoll [Spec_MT 

ServerProt_V1106] 



� Erweiterung Mobiles Ticketing, Kernapplikation als Mobile Ticketing Applikation 

[Spec_MT_V1106] 

� VDV-Kernapplikation Spezifikation Nutzermedium [Spec_NM_V1106] 

� Beschreibung der Schnittstellen zwischen der Vertriebseinheit (KVP-VE) und der 

Personalisierungseinheit (KVP-PE) eines KVP-Terminals [Spec_PE_V1106] 

� VDV-Kernapplikation Spezifikation des SAM [Spec_SAM_V1106] 

� VDV-Kernapplikation Technisches Konzept Sicherheit [Spec_SEC_V1106] 

� Schnittstellenspezifikationen der Referenzsysteme Kundenvertragspartner (KVP), 

Dienstleister (DL), Produktverantwortlicher (PV), Applikationsherausgeber (AH), Kontrollservice 

(KOSE) [Spec_SST_V1106] 

� Systemlastenheft, Teil: Dienstleister-System (DLS) [SYSLH_DLS_V1106] 

� Anhang zum Hauptdokument, Systemlastenheft, Nutzung des Kundendatenspeichers 

- Vorläufige Verfahrensfestlegung [SYSLH_HD_Anlage_V1106] 

� Systemlastenheft Hauptdokument [SYSLH_HD_V1106] 

� Systemlastenheft, Teil: Kontrollservice-System (KOSES) [SYSLH_KOSES_V1106] 

� Systemlastenheft, Teil: Kundenvertragspartner-System [SYSLH_KVPS_V1106] 

� Systemlastenheft, Teil: Personalbediente KVP-ReferenzTerminals 

[SYSLH_PbRTKVP_V1106] 

� Systemlastenheft, Teil: Produktverantwortlichen-System (PVS) [SYSLH_PVS_V1106] 

� Systemlastenheft, Teil: Referenzterminal DL [SYSLH_RTDL_V1106] 

� Systemlastenheft, Teil: Personalbediente KVP-Referenzterminals 

[SYSLH_SbRTKVP_V1106] 

� Anlage zum Hauptdokument der Spezifikationen zur VDV-Kernapplikation – Rahmenrichtlinie 

Elektronisches Fahrgeldmanagement (EFM) – Datenschutzrechtliche 

Grundanforderungen [Anlage DSzuHD_SPEC_V1106] 

� Einheitliche Kundenschnittstelle für ein mehrstufiges interoperables elektronisches 

Fahrgeldmanagement [SPEC_KUSCH_V1106] 

Die oben aufgeführten Dokumente können über die VDV KA KG bezogen werden. 



3.5.2 Dokumente KCEFM 

Die Berechtigungen, welche mit d(((eti ausgegeben und interpretiert werden sollen, sind der 

Referenz-EFS der VDV-Kernapplikation, der NRW-KA-EFS des VRR, des VRS und der VGN 

und die Automatische Fahrtberechtigung (AFB) des Kreisverkehr Schwäbisch Hall (KVSHA). 

Die spezifischen Teile des NRW-KA-EFS sind in folgender Spezifikation beschrieben: 

� Aufbau des NRW-KA-EFS und Konvertierungsregeln [NRW_KA_EFS] 

Dieses Dokument ist als Anlage beigefügt. 



4 Allgemeine Beschreibung der Aufgabenstellung 

4.1 Das Rollenmodell der VDV-Kernapplikation 

Die Grundlage der Organisation des eTicketings nach Kernapplikation bildet das zu Grunde 

liegende Rollenmodell. Es beschreibt, wie die Teilnehmer am EFM – und damit auch deren 

technischen Systemkomponenten – untereinander kommunizieren müssen. 

Das folgende Diagramm zeigt die verschiedenen Rollen der Kernapplikation: 

Kunden - 

abrechnung 

Kunden - 

Vertragspartner 

Vertrieb Service 

Nutzer - 

medium 

Nutzer Kunde 

Abbildung 2 Das VDV-KA-Rollenmodell und d(((eti 

Im Rahmen des d(((eti-Systems sind also ein KVP- und DL-Server sowie ein KVP-Terminal 

zu realisieren. 

Version 1_0 - Stand: 7.4.2009 

Zertifizierung 

Registrierung 

Kontrollservice 

(KOSE) 

Applikations - 

Herausgeber 

Sicherheits 

management 

- 

Produkt - 

Verantwortlicher 

Entwicklung 

& Pflege 

Ausgabe 

Dienstleister 

Leistungs - 

abrechnung 

Produkt - 

abrechnung 

Erfassung 

Kontrolle


4.2 Übersicht Systemarchitektur d(((eti 

Abbildung 3 Das d(((eti-System mit Schnittstellen 

Die Abbildung „Das d(((eti-System mit Schnittstellen“ zeigt den d(((eti-Server mit seinen 

Schnittstellen zu anderen KA-Systemen und zu Client-Rechnern. In der nächsten Abbildung 

„Das d(((eti-System als KA-KVP- und DL-System“ wird gezeigt, welche KA-Systeme das 

d(((eti-System implementiert. 



Abbildung 4 Schnittstellen von d(((eti zu anderen KA-Systemen 



4.3 Beschreibung des Pakets d(((eti-API 

API ist die Abkürzung für das englische Application Programming Interface und im Deutschen 

mit Programmierschnittstelle zu übersetzen. Die d(((eti-API soll eine Programmierschnittstelle 

aller KA-Funktionen bilden, welche zur Entwicklung des d(((eti-Systems und des 

d(((eti-eTicket-Viewers benötigt werden. 

Zudem soll die API in Form einer oder mehrerer objektorientierter Bibliotheken implementiert 

werden. 

Schließlich soll die erschöpfende Dokumentation der d(((eti-API dazu beitragen, dass dritte 

Entwickler die d(((eti-API und die zugehörigen Bibliotheken zur Programmierung eigener KA- 

Systemkomponenten nutzen können. 

Das d(((eti-System implementiert im Wesentlichen ein kombiniertes DL/KVP-System mit 

KVP-Terminal. (Siehe Abbildung 4) (Der d(((eti-eTicket-Viewer kann als Spezialfall eines DL- 

Terminals hier vernachlässigt werden.) 

Dabei muss das d(((eti-System mit allen notwendigen Systemen der Kernapplikation kommunizieren. 

Die Schnittstellen der KA-Systeme sind, mit Ausnahme der Schnittstelle DL- 

System DL-Terminal, in der KA-Spezifikation „KA SST-SPEC Schnittstellenspezifikationen 

der Referenzsysteme Kundenvertragspartner (KVP), Dienstleister (DL), Produktverantwortlicher 

(PV), Applikationsherausgeber (AH), Kontrollservice (KOSE)“ [Spec_SST_V1106] 

festgelegt. 

Die Entwicklung von d(((eti mündet in zwei Produkte aus Nutzer-/Kundensicht: d(((etieTicket-Viewer 

und d(((eti-System. Der Viewer benötigt weitaus weniger KA-Funktionalität 

als das System und soll wesentlich früher fertig gestellt werden. Beide Produkte sollen sich 

der d(((eti-API bedienen, um KA-Funktionen auszuführen. 

Da der d(((eti-eTicket-Viewer nur eine Untermenge der gesamten d(((eti-API benötigt, kann 

zunächst nur diese Untermenge entwickelt werden. 



4.4 Beschreibung des Pakets d(((eti-eTicket-Viewer 

Die Aufgabe des d(((eti-eTicket-Viewer ist es, Kernapplikation-Nutzermedien auszulesen und 

die Inhalte der Berechtigungen anzuzeigen. Letztendlich handelt es sich hier um die Umsetzung 

einiger Elementarprozesse, z,B. „EP_Anzeige_EFS“, „EP_Anzeige_Applikationsdaten“ 

oder „EP_Anzeige_Kundenprofil“ (siehe Kapitel 6.2.2.1). 

Auf einem NM können spezifikationsgemäß mindestens acht Berechtigungen verschiedener 

Art abgelegt sein. Diese sind in der Spezifikation [Spec_NM_V1106] beschrieben. 

Dem Nutzer des d(((eti-eTicket-Viewers muss die Möglichkeit offen stehen, aus den vorhandenen 

Berechtigungen auszuwählen und die ausgewählte Berechtigung näher zu betrachten. 

Dazu ist eine Darstellung zur Verfügung zu stellen, welche alle Berechtigungen in Kurzform 

mit Berechtigungsart und ausgebender Organisation anzeigt und dem Nutzer die direkte 

Auswahl gestattet. 

Alternativ dazu muss es einen Darstellungsmodus geben, der nach dem Einlesen der Berechtigungen 

sofort den ersten oder die ersten beiden Berechtigungen anzeigt. 

Die Organisationen (in der Regel ein Verkehrsunternehmen) werden in der KA mit Hilfe von 

Nummern, den sog. OrgIDs bestimmt. Der d(((eti-eTicket-Viewer muss eine Liste aller OrgIDs 

und die dazugehörigen Unternehmen einlesen können, um die OrgID in einen Organisationsnamen 

und / oder Organisationskürzel übersetzen zu können. Die VDV KA KG hat 

bisher etwa hundert OrgIDs vergeben. Es ist zu erwarten, dass die Zahl in den kommenden 

Jahren noch um ein Vielfaches zunimmt. 

Die Kernapplikation definiert das Nutzermedium (siehe [Spec_NM_V1106]). Die Daten des 

Nutzermediums sollen dem Anwender des d(((eti-eTicket-Viewers ebenfalls angezeigt werden 

können. 

Die EFS-Berechtigung ist in der Kernapplikation nur bis zu einem gewissen Grad definiert: 

Die Spezifikation enthält einen Teil, der von Produktverantwortlichen nach Belieben gefüllt 

werden kann. 

Für VRR, VRS und VGN wird diese Struktur mit dem NRW-KA-EFS gefüllt. Der Aufbau des 

NRW-KA-EFS ist in der Spezifikation des KCEFM [NRW_KA_EFS] beschrieben. 

Generell muss der d(((eti-eTicket-Viewer in der Lage sein, alle in der KA möglichen Berechtigungen 

zu interpretieren. Dazu muss er beliebig viele Beschreibungen von Produkten einlesen, 

verwalten und anwenden können. 

Die ausgelesenen Inhalte von Nutzermedien müssen in wohlgeformten Textdateien abgespeichert 

werden können. Dies dient u.a. zum Zweck der Diagnose und zur Dokumentation 

„auffälliger“ Berechtigungen. 

Eine Hilfefunktion erklärt die Bedienung des d(((eti-eTicket-Viewers. 



4.5 Beschreibung des Pakets d(((eti-System 

Das d(((eti-System dient unter anderem dem Vertrieb von eTickets. Sowohl 

Kundenvertragspartner selbst, als auch deren Vertriebspartner und Kunden sollen mit d(((eti 

Berechtigungen auf Nutzermedien speichern können. Dies bedingt, dass d(((eti über 

Mechanismen verfügen muss, welche die Zuweisung von Rechten durch den KVP sowie die 

Dokumentation aller ausgegebenen Berechtigungen sicher stellt. 

Die Ausgabe von Berechtigungen ist in der Praxis fast immer an Bezahlvorgänge geknüpft. 

Das d(((eti-System muss diese Vorgänge und die dazu gehörigen Daten wie z.B. 

Bankverbindungen verwalten können. 

In seiner Eigenschaft als Dienstleister-Server (DLS) und Kundenvertragspartner-Server 

(KVPS) muss d(((eti die Verwaltung des Datentauschs mit anderen KA-Systemen bzw. – 

Servern ermöglichen. 

d(((eti muss mandantenfähig sein. Daher muss ein d(((eti-System die Funktion mehrerer 

KVP- bzw. DL-Server übernehmen können. Um die vielfältigen Bedienhandlungen zur 

Verwaltung eines d(((eti-Systems verschiedenen realen Personen zuordnen zu können, 

muss eine Hierarchie der d(((eti-System-Nutzer gebildet werden können. 

KVP1 

DL1 

Abbildung 5 Die Hierarchie der d(((eti-Nutzer 


KVP2 

DL2 

DLn 

KVPn


Grundsätzlich sollen übergeordnete Nutzer die Möglichkeit haben, all das zu tun, was auch 

die ihnen untergeordneten Nutzer im d(((eti-System tun können. Alle übergeordneten Nutzer 

können Systemzugänge (Konten, Accounts) für ihnen untergeordnete Nutzer einrichten. 

Die Bedienung des d(((eti-Systems soll mit jedem modernen WWW-Browser auf einem 

entfernten Rechner möglich sein. Das heißt, dass d(((eti eine Web-Schnittstelle 

implementieren muss, welche alle Nutzerfunktionen anbietet. 

Die Sicherheitsmodule müssen in einem eTicket-Server zentral verwaltet werden. Die 

Schnittstelle zur Kommunikation zwischen d(((eti-Server und Clientrechner (siehe auch 

Kapitel 4.2, Abbildung 3 Das d(((eti-System mit Schnittstellen) muss definiert und 

implementiert werden. 

Zudem dient das d(((eti-System als Dienstleister-Server (DLS). In dieser Eigenschaft 

speichert und verarbeitet es Bestandslisten von eTickets sowie Sperrlisten und 

Sperrnachweise und verteilt sie auf angeschlossene DL-Terminals (Z.B. mobile Prüfgeräte, 

Systeme zur elektronischen Einstiegskontrolle (EKS)). 

Das d(((eti-System muss als KA-KVP- und –DL-Server bestimmte Elementarprozesse der 

Kernapplikation implementieren (siehe auch Kapitel 6.2.2.1). 



4.6 Pflichtenheft 

Das Pflichtenheft wird vom Auftragnehmer als Konkretisierung des Lastenheftes bzw. der 

Leistungsbeschreibung erstellt. Es beschreibt, wie der Auftragnehmer die drei Pakete von 

d(((eti konkret entwickeln wird. 

Das d(((eti-Pflichtenheft weist insbesondere einen Teil auf, der beschreibt, auf welchen 

vorhandenen Open Source Programmen sich die weitere Entwicklung stützt. 

Im Pflichtenheft sind die Nutzer-Prozesse des d(((eti-Systems beschrieben. Die zugehörigen 

Dialoge und anderen Bedienkomponenten sind grob skizziert. 

Ein separater Teil beschreibt alle im Rahmen der Entwicklung definierten Schnittstellen. 

Ein Teil des Pflichtenheftes beschreibt die Tests zur Prüfung der Funktionsfähigkeit der 

d(((eti-Pakete. Die Tests sollen möglichst umfassend sein und so viel Funktionalität wie 

möglich prüfen. Sie sind Grundlage der Abnahme. 

Zu den Tests wird definiert, welcher Erfüllungsgrad für eine Abnahme mit Mängeln ausreicht. 

Die Beschreibung der Tests muss so gestaltet sein, dass sie als Abnahmeprotokoll dienen 

kann. 

Das gesamte Pflichtenheft wird zu Beginn der Entwicklung zwischen Auftraggeber und 

Auftragnehmer abgestimmt und abgenommen. 



4.7 Rechte an der Software / Veröffentlichung unter Open–Source-Lizenz 

Der Auftragnehmer räumt dem Auftraggeber ausschließliches, unbeschränktes Nutzungsrecht 

an der entwickelten Software ein. 

Der Auftraggeber stellt die Software unter die GNU General Public License (GPL). Ausgenommen 

ist die d(((eti-API, welche unter die Lesser General Public License (LGPL) gestellt 

wird. 

Der Auftragnehmer gestaltet alle von ihm entwickelten Quelltexte so, dass sie den Anforderungen 

der GPL bzw. LGPL entsprechen. Dies gilt insbesondere bei der Kommentierung von 

Quelltextdateien. 

(Siehe http://www.fsf.org/licensing/licenses/gpl.html bzw. 

http://www.fsf.org/licensing/licenses/lgpl.html) 



5 Projektabwicklung 

5.1 Durchführung 

5.1.1 Projektleiter Auftragnehmer 

Der vom Auftragnehmer bestimmte Projektleiter ist Ansprechpartner für jedwede Kommunikation 

zwischen Auftraggeber und Auftragnehmer. Die direkte Kommunikation mit Entwicklern 

und Unterauftragnehmern pflegt der Auftraggeber nur in von ihm gebilligten Ausnahmefällen 

und unter Information des Projektleiters des Auftragnehmers. 

5.1.2 Projektgespräche 

In jedem Monat findet zumindest ein Projektgespräch beim Auftraggeber statt. An den Projektgesprächen 

nehmen der Projektleiter des Auftragnehmers sowie der Ansprechpartner 

des Auftraggebers teil. 

5.1.3 Protokollführung 

Von allen Projektgesprächen fertigt der Auftraggeber Ergebnisprotokolle an. Diese werden 

mit dem Auftragnehmer abgestimmt. Der Auftragnehmer legt Entwürfe der Ergebnisprotokolle 

möglichst schnell, spätestens aber sieben Tage nach dem entsprechenden Projektgespräch 

vor. Protokolle werden im jeweils nächsten Projektgespräch, eventuell nach einmütiger 

Korrektur, genehmigt. 

5.2 Mitwirkungsleistungen 

5.2.1 Testmaterial 

Der Auftraggeber stellt folgende Materialien zur Entwicklung und zum Test leihweise zur Verfügung: 

a) Zwei Sicherheitsmodule 

b) Zehn Chipkarten mit Kernapplikation 

Vor Teilabnahmen und der Abnahme des Auftragsgegenstandes testet der Auftraggeber 

eigenverantwortlich die Funktionalität der gelieferten Software. 

5.2.2 Abnahmeprüfungen 

Pflichtenheft, d(((eti-eTicket-Viewer und d(((eti-System werden zu verschiedenen Zeitpunkten 

abgenommen. Der Auftraggeber prüft im Beisein des Auftragnehmers die Gegenstände 

zur Abnahme und hält die Ergebnisse der Prüfung schriftlich in einem Abnahmeprotokoll fest. 

5.3 Qualitätssicherung 

Der Auftragnehmer stellt in seinem Angebot dar, mit welchen Maßnahmen er die Qualität der 

gelieferten Software sicher stellen wird. 



5.4 Vorschriften, Richtlinien, Normen 

In Fragen der Benutzbarkeit und Softwareergonomie ist zu beachten: 

EN ISO 9241, Teile 11 bis 17, 110, 151 und 171 

5.5 Besondere Hinweise 

Die umfangreichen Dokumente, welche die VDV-Kernapplikation beschreiben, haben erst in 

Teilen ihren Praxistest bestanden. Insbesondere die für d(((eti besonders wichtigen Systemlastenhefte 

des KVPS und DLS sind noch nicht in einem realen System umgesetzt worden. 

Dies wird zum ersten Mal bei d(((eti der Fall sein. Obwohl die Dokumente von hoher Qualität 

sind, kann nicht ausgeschlossen werden, dass an der einen oder anderen Stelle noch Fehler 

oder Spezifikationslücken vorhanden sind. In Kapitel 6.2.2.1 sind die Fehler und Spezifikationslücken 

beschrieben, welche den Autoren beim Erstellen dieser Leistungsbeschreibung 

aufgefallen sind. 

Aus diesem Grunde sind die Spezifikationen und Systemlastenhefte vom Auftragnehmer mit 

großer Aufmerksamkeit zu analysieren. Falls dabei weitere Fehler oder Spezifikationslücken 

auftauchen oder Unklarheiten wahrgenommen werden, so sind sie umgehend dem Auftraggeber 

zu melden. Die für d(((eti maßgebliche Interpretation wird vom Auftraggeber, eventuell 

nach Beratung mit der VDV KA GmbH & Co. KG, festgelegt. 

Es kann sich daraus ergeben, dass weitere Elementarprozesse, Anwendungsfälle oder 

Schnittstellenobjekte spezifiziert werden müssen. Deren Implementation gehört zum Auftragsumfang. 

5.5.1 Templates, Produkt- und Kontrollmodule 

Die VDV-Kernapplikation ist grundsätzlich neutral hinsichtlich des angewendeten Tarifes. Um 

jeden Tarif umsetzen zu können, gibt es als Bestandteil der Berechtigungen zwei so genannte 

produktspezifische Teile und zwar 

� den „Statischen produktspezifischen Teil“ und 

� den „Transaktion produktspezifischen Teil“. 

Näheres zum Aufbau von Berechtigungen kann der [Spec_NM_V1106] und dem 

[Spec_HD_BOM_V1106] entnommen werden. 

Der Aufbau dieser produktspezifischen Teile kann auf Basis der in [Spec_HD_BOM_V1106] 

beschriebenen Datenelemente selbst definiert werden, um die Tarifprodukte eines PVs abbilden 

zu können. Damit ein derartiger Aufbau einem System datengesteuert übermittelt werden 

kann, sind Templates vorgesehen. Um jedoch die Definition von Templates weitestgehend 

überflüssig zu machen, wurden so genannte Referenz-Objekte (Referenz-EFS, Referenz-AFB, 

etc.) definiert, die jedes System, ohne dass ein Template vorliegt, verarbeiten 

können muss. 

Auf Basis dieser Referenz-Objekte bzw. Templates können dann Tarifprodukte abgebildet 

werden. Um diese nun ebenfalls datengesteuert in die Systeme einbringen zu können, sind 

Produkt- und Kontrollmodule vorgesehen. 



Das Produkt- und Kontrollmodul beinhaltet Daten, die sowohl für die Ausgabe als auch die 

Kontrolle einer Berechtigung wichtig sind. Es gibt neben statischen Daten, die feste Produkteigenschaften 

beschreiben, auch dynamische Daten, die letztendlich die Parameter eines 

Produktes darstellen. Dabei wird zwischen Daten, die die Art und Weise beschreiben, wie ein 

Element einer Berechtigung zu füllen ist, und denen, die beschreiben, mit welchem Algorithmus 

eine Element bearbeitet werden muss (z. B. bei einer Kontrolle). 

Darüber hinaus wird beschrieben, welches Datum aus dem Produkt- und Kontrollmodul wo 

und wie in einer Berechtigung abgebildet wird. 

Eine wichtige Eigenschaft eines Produkt- und Kontrollmoduls ist die Preisbildung. Der Preis 

wird durch ein entsprechendes Preismodul als Teil des Produkt- und Kontrollmoduls gebildet. 

Im einfachsten Fall ist dies eine Tabelle bei der sich abhängig vom Produkt und einer Preisstufe 

ein Preis ergibt. Bei Streckentarifen kann dieses Preismodul aber schon sehr kompliziert 

werden. 

Technisch gesehen sind sowohl Templates als auch Produkt- und Kontrollmodule XML- 

Strukturen, deren Aufbau durch ein entsprechendes XML-Schema beschrieben wird. Darüber 

hinaus gibt es Funktionen, die die benötigten Algorithmen umsetzen. 

Es gibt in der VDV-Kernapplikation allerdings noch keine konkrete Spezifikation von Templates 

und Produkt- und Kontrollmodulen. Diese wird zurzeit durch eine Arbeitsgruppe der VDV- 

Kernapplikation erstellt. 

Die aktuelle Entwicklung in diesem Bereich ist in der Pflichtenheftphase entsprechend zu 

berücksichtigen. Sollten während der Pflichtenheftphase Templates, Produkt- und Kontrollmodule 

nicht spezifiziert sein, so sind Ersatzlösungen mit dem Auftraggeber abzustimmen. 

5.5.2 Benachbarte Systeme 

Der KOSES befindet sich zurzeit im Aufbau. PVS und AHS sind bisher noch nicht entwickelt 

worden. Das gilt auch für KA-konforme KVPS oder DLS. Diese Systeme kommunizieren 

über das standardisierte Interoperabilitätsnetzwerk (siehe Kapitel 5.5.3). Insofern muss davon 

ausgegangen werden, dass die Kommunikation grundsätzlich funktionieren wird. Für die 

Abnahme sind diese benachbarten Systeme entsprechend zu simulieren. 

5.5.3 Interoperabilitätsnetzwerk 

Der Datenaustausch zwischen den einzelnen Systemen ist in [Spec_SST_V1106] grundsätzlich 

beschrieben. Allerdings fehlen noch Details hinsichtlich der in diesem Fall asynchronen 

Übertragung per FTPS. Diese Details werden kurzfristig noch festgelegt. Folgende Rahmenbedingungen 

werden zurzeit diskutiert: 



� Jede XML-Struktur (z. B. TXABER) wird in einer separaten Datei übertragen. Die möglichen 

Datenstrukturen können Kapitel 6.2.2.4 entnommen werden. 

� Es gibt eine Definition für den Aufbau der Dateinamen. 

� Die Datei wird gegebenenfalls vor der Übertragung gezippt. 

� Details der Übertragung wie Nutzername/Kennwort und eventuell erforderliche Zertifikate 

sind geklärt. 

Wegen der in Kapitel 5.5.2 beschriebenen eventuell noch fehlenden Systeme muss es abhängig 

vom jeweiligen Anwendungsfall eine Möglichkeit geben, anstatt des regulären Empfängers 

einen Ersatz-Empfänger konfigurieren zu können. 


berücksichtigen. 

Allerdings werden auch noch grundsätzlich andere neuere Technologien wie EXI (Efficient 

XML Interchange) und Web-Services in diesem Zusammenhang diskutiert. 

Die Systemarchitektur muss es daher grundsätzlich gestatten, diese neuen Technologien 

später ebenfalls zu unterstützen. Demzufolge muss es eine klare Trennung zwischen der 

Erzeugung einer Datenstruktur und deren Weiterleitung geben. 

5.5.4 Hinweise zum Datenaustausch zwischen KVPS und KVPT sowie DLS 

und DLT 

Basierend auf den Ausführungen im Kapitel 5.5.3 und den dann getroffen Festlegungen ist 

vom KCEFM beabsichtigt, Schnittstellenbeschreibungen zwischen einem KVPS und KVPT 

sowie einem DLS und DLT zu erstellen und über einen CR der Spezifikation der VDV- 

Kernapplikation hinzuzufügen. 

Diese Schnittstellen werden sich grundsätzlich nicht von der Übertragung im ION unterscheiden. 

Die Datenstrukturen, die übertragen werden, können den Kapiteln 6.2.2.4.1 und 

6.2.2.4.7 entnommen werden. 


berücksichtigen. 

5.5.5 TestSuite der VDV-Kernapplikation 

Es besteht auch die Möglichkeit die Testsuite der VDV-Kernapplikation zu kaufen. Diese 

kann insbesondere Entwicklern den Einstieg in die VDV-Kernapplikation erleichtern. Insbesondere 

bei der Entwicklung der Kommunikation zum Nutzermedium und SAM im Rahmen 

der Realisierung des KVP-Terminals des d(((eti-Systems bzw. d(((eti-Viewers kann sie hilfreich 

sein und Entwicklungskosten sparen. Ansprechpartner hierzu ist die VDV- 

Kernapplikations GmbH & Co. KG, die auch Auskunft über die Kosten gibt. 



6 Spezifizierung der Software 

6.1 Allgemeine Eigenschaften der d(((eti-Software 

6.1.1 Portabilität 

d(((eti soll auf mindestens zwei Betriebssystem-Plattformen laufen. Deshalb sind alle Komponenten 

so portabel wie möglich zu gestalten. Dies gilt sowohl für die Auswahl der zu nutzenden, 

zu Grunde liegenden Open-Source-Programme als auch für Neuentwicklungen. 

Da die Förderung der Weiterentwicklung durch Dritte ein Schwerpunkt des d(((eti-Projektes 

ist, sollten die eingesetzten Programmiersprachen frei verfügbar sein und auch über freie 

Entwicklungsumgebungen und möglichst viele freie Bibliotheken verfügen. 

Alle Komponenten sollen über beide Betriebssystemplattformen hinweg soweit möglich die 

gleiche Codebasis haben. 

6.1.2 Programmierung 

Die Funktionen sind soweit möglich als Java-Bibliotheken zu entwickeln. Alle hardwarenahen 

Funktionen, welche nicht in Java zu realisieren sind, sollten in C geschrieben werden. 

Bibliotheken, welche nicht unter einer freien Lizenz stehen, können nicht eingesetzt werden. 

Die Quelltexte sind mit aussagekräftigen Kommentaren zu versehen. Insbesondere sind alle 

Quelltextdateien, alle Klassen, alle Interfaces und alle Funktionen bzw. Methoden zu kommentieren. 

Für alle Klassen und Interfaces ist zu beschreiben, von welchen Klassen sie erben, bzw. 

welche Interfaces sie implementieren. Auch die Abhängigkeiten von Bibliotheken sind zu 

beschreiben. 

Bei Methoden bzw. Funktionen sind Parameter und Rückgabewerte in Kommentaren im 

Quelltext zu beschreiben. 

Für alle Java-Entwicklungen gilt: Die Bedingungen der objektorientierten Programmierung 

sind einzuhalten. Die Bibliotheken sind so zu schreiben, dass sie mit dem Java Developement 

Kit (JDK) 6 von Sun (oder höher) kompiliert werden können. 

Java-Quelltexte sind Javadoc-konform zu kommentieren. 

C-Anteile der Bibliotheken sind in genormtem C (ISO C90) zu verfassen. 

Soweit möglich sollen die zur Entwicklung eingesetzten Werkzeuge Open-Source-Software 

sein. Zumindest sollen alle Teile mit Hilfe von Open Source Compilern vom Quelltext in ausführbaren 

Code übersetzt bzw. durch Open Source Interpreter ausgeführt werden können. 



6.1.3 Benutzbarkeit (usability) und Softwareergonomie 

Alle Komponenten von d(((eti, welche Nutzungsschnittstellen aufweisen, müssen nach den 

Regeln der Softwareergonomie aufgebaut werden. Generell sind grafische Nutzungsschnittstellen 

zu entwickeln. 

Wo immer möglich, sollen die neu zu entwickelnden Komponenten mit WWW-Clients (Browser) 

bedient werden können. 

Soweit möglich müssen die Anwendungen barrierefrei gestaltet sein. Dies gilt für alle Funktionen, 

welche von Endkunden bzw. Vertriebspartnern genutzt werden können. 

Insbesondere müssen die Formulare und Dialoge unabhängig von der durch Nutzer eingestellte 

Browserfenster-Größen sowie Schriftarten und –größen ihre Funktion behalten. 

Alle Anwendungen müssen die Eingabemöglichkeiten der Nutzer soweit beschränken, wie 

es die Aufgabe zulässt. Dies bedeutet z.B. für die Gestaltung von Formularen, dass Bedienelemente 

so sparsam wie möglich eingesetzt werden. Für die Gestaltung von Menüs heißt 

dies analog, dass diese ab einer bestimmten Zahl von Einträgen (ca. fünf) in Untermenüs 

unterteilt werden sollen. Die Benutzungsoberfläche soll sich den Anwendern durch Einfachheit 

erschließen. 

Erfordert eine Funktion umfangreiche und komplizierte Eingaben, so ist der Benutzer durch 

eine Abfolge von übersichtlichen Formularen bzw. Dialogen zu führen. 

Durch geeignete Formen der visuellen Rückmeldung muss der Nutzer jederzeit ohne besondere 

Anstrengungen erkennen können, welche Bedienhandlung das System aktuell erfordert 

bzw. anbietet. 

6.1.4 Genutzte ISO 14443 Schreib-/Lesegeräte 

Folgende ISO 14443-Schreib/Lesegeräte muss der d(((eti-Viewer mindestens nutzen können: 

� Omnikey 5321 RFID 

� Baltech Engine Pad 

� Feig OBID classic pro 

Dies gilt sowohl für den d(((eti-Viewer als auch für die Client-Software des d(((eti-Systems 

(Siehe Kapitel 6.4.2, Abbildung 10 Mögliche Architektur des d(((eti-Systems und Kapitel 13, 

Abbildung 1 d(((eti als eTicketserver). 



6.2 d(((eti-API 

6.2.1 Technische Eigenschaften 

Die d(((eti-API-Bibliothek soll Entwicklern eine möglichst simple Nutzung von KA-Funktionen 

bieten. Zudem sollen moderne Entwurfs- und Entwicklungsmethoden unterstützt werden. 

Daher ist die d(((eti-API objektorientiert zu modellieren. 

Die objektorientierte Analyse wird vom Auftragnehmer durchgeführt. Das objektorientierte 

Design wird mittels geeigneter graphischer Notation (z.B. UML) dokumentiert. 

d(((eti-eTicket-Viewer und das d(((eti-System sollen in entscheidenden Teilen in Java programmiert 

sein. Daher muss die d(((eti-API in Java implementiert sein. Systemnahe Teile, 

welche nicht in Java programmiert werden können, sollen in C programmiert werden. 

Die d(((eti-API ist als gesonderte Bibliothek bzw. Sammlung von Bibliotheken auszuführen, 

welche ohne weitere Teile von d(((eti nutzbar ist bzw. sind. 



6.2.2 Umfang der gesamten API-Funktionalität 

In den folgenden Kapiteln ist der für die d(((eti-API zu realisierende Funktionsumfang detaillierter 

beschrieben. An dieser Stelle soll auf zwei wichtige Eigenschaften der VDV- 

Kernapplikation und somit auch von d(((eti besonders hingewiesen werden: 

Die VDV-Kernapplikation ist ein durch Organisationskennungen (Org-IDs, Zahlen) gesteuertes 

System. Aus der jeweiligen Kennung ergibt sich auch die Zugehörigkeit zu einem der drei 

Sicherheitslevel der VDV-Kernapplikation. 

� Org-ID == 34968 dezimal bis 35067 dezimal � Security Level 1 

� Org-ID >= 32768 dezimal (ohne 34968 dezimal bis 35067 dezimal) � Security Level 2 

� Org-ID < 32768 dezimal � Security Level 3 

Security Level 1: Öffentlich bekannte Schlüssel für einfache Funktionstests der Komponenten 

(fiktive Organisationen) 

Security Level 2: Vertrauliche Schlüssel für Systemtests (reale Organisationen) 

Security Level 3: Vertrauliche Schlüssel mit höchster Sicherheitsstufe für den Wirkbetrieb 

(reale Organisationen) 

Diese Eigenschaft ist bei der Systemarchitektur zu berücksichtigen. Es muss also möglich 

sein, gesteuert durch Organisationskennungen d(((eti durch eine entsprechende einfache 

(Start-)Konfiguration einem der drei Sicherheitslevel zuzuordnen. Als Folge daraus sind die 

für eine jeweilige Org-ID vorhandenen bzw. erzeugten Daten entsprechend zu separieren. 

Eine weitere Eigenschaft der VDV-Kernapplikation ist die im Rahmen der Public Key 

Infrastructure (PKI) erfolgte Aufteilung der Endzertifikate für Organisationen, SAMs und Nutzermedien 

auf mehrere Sub-CAs. 

Abbildung 6 Aufteilung der Endzertifikate 

Damit in diesem Fall die Interoperabilität gewährleistet ist, muss unter anderem im Rahmen 

der von einem KVP-Terminal gesteuerten Kommunikation zwischen Nutzermedium und SAM 



(siehe [Spec_SAM_V1106] und [Spec_NM_V1106]) sowohl ein einstufiges als auch ein zweistufiges 

Authentisierungsverfahren realisiert werden. Beim einstufigen Verfahren sind die 

Zertifikate der Kommunikationspartner von derselben Sub-CA, beim zweistufigen Verfahren 

von unterschiedlichen Sub-CAs. 

Abbildung 7 Einstufiges Authentisierungsverfahren 

Abbildung 8 Zweistufiges Authentisierungsverfahren 



6.2.2.1 Hinweise zur „Schnittstellenspezifikationen der Referenzsysteme…“ 

[Spec_SST_V1106] und den Systemlastenheften 

Bei der Analyse der Elementarprozesse und der Anwendungsfälle für diese Leistungsbeschreibung 

sind Unstimmigkeiten aufgefallen, die gemäß der folgenden Kapitel zu interpretieren 

sind und noch durch einen CR in die Spezifikation der VDV-Kernapplikation einzubringen 

sind. Es kann davon ausgegangen werden, dass der CR letztendlich das unten stehende 

bestätigt. 

6.2.2.1.1 Korrekturen bei den Elementarprozessen in der [Spec_SST_V1106] 

Elementarprozess fehlt: Applikation_Sperrauskunft erteilen: Zu den Anwendungsfällen 

1.1.2.4 in den Systemlastenheften [SYSLH_AHS_V1106] und 

[SYSLH_KVPS_V1106], 1.1.2.1 im [SYSLH_DLS_V1106], 

1.1.2.15 im [SYSLH_PbRTKVP_V1106] und 1.1.2.5 im 

[SYSLH_RTDL_V1106] wird noch ein entsprechender Elementarprozess 

ergänzt. 

Tabelle 4.3: Bei der SST_KVP=KVP (Sonderfall Empfänger- 

Referenzsystem = Sender-Referenzsystem) wird die Rückrichtung 

ergänzt, da jeder KVPS die Sende- und Empfangsrichtung 

für die jeweilige Schnittstellenklasse vorsehen muss. 


[SYSLH_KVPS_V1106] 

Anwendungsfall 1.1.2.1: Die konkrete Umsetzung, wie der Kunde angelegt und das 

Kundenprofil erfasst wird, kann durch den KVP selbst entschieden 

werden und ist nicht standardisiert. Die benutzten Datenelemente 

können durch den Kunden und/oder den KVP bestimmt 

werden. (siehe auch fehlender Anwendungsfall Kundenprofil 

ändern) 

Anwendungsfall 1.1.2.14: Es muss KVP-Mitarbeiter anstatt KVPT heissen. 

Anwendungsfall fehlt: Gesperrte oder ungültige Applikation erfassen: Im Prinzip ist 

der Datensatz nur für statistische Zwecke zu speichern. 

Anwendungsfall fehlt: Applikation_Entsperrnachweis an AH melden: Im Prinzip ist hier 

der gleiche Ablauf wie im Anwendungsfall 1.2.2.17 

EFS_Entsperrnachweis an PV melden umzusetzen. 

Anwendungsfall fehlt: Kundenprofil ändern: siehe Anwendungsfall 1.1.2.1 

Anwendungsfall fehlt: Entgegennahme des Kontrollnachweises aus dem 

EP_Kontrolle: Im Prinzip ist der Datensatz nur für statistische 

Zwecke zu speichern. Im PVS wird der entsprechende Anwendungsfall 

1.2.2.4 hinsichtlich der Weiterleitung an den KVPS 

erweitert. 

Anwendungsfall 1.2.2.14: Es muss KVP-Mitarbeiter anstatt KVPT heissen. 



Anwendungsfall 1.2.2.20: Die Datenstruktur heißt TXQEFS und nicht TXQBERLN. 

Anwendungsfall 1.2.2.23: Die Datenstruktur heißt grundsätzlich TXVPROD und nicht 

TXVTPROD wie in den SysLH der KVP-Terminals. 

Anwendungsfall fehlt: Gesperrten oder ungültigen EFS erfassen: Im Prinzip ist der 

Datensatz nur für statistische Zwecke zu speichern. 

Anwendungsfall 1.4.2.5. Die Datenstruktur heißt TXGWEB und nicht TXEBER 

Anwendungsfall fehlt: SAM_Sperrnachweis einreichen: Im Prinzip ist hier der gleiche 

Ablauf wie im Anwendungsfall 1.7.2.9 beim DLS umzusetzen. 

Anwendungsfall fehlt: ORG_Sperrnachweis einreichen: Im Prinzip ist hier der gleiche 

Ablauf wie im Anwendungsfall 1.7.2.10 beim DLS umzusetzen. 

Anwendungsfall 1.8.2.17 Es handelt sich um das Einspielen von Kryptogrammen des 

Sicherheitsmanagementes, um Schlüssel zu laden, Kontingente 

zu ändern und Schlüssel zu löschen. 

6.2.2.1.3 Korrekturen bei den Anwendungsfällen im Systemlastenheft DLS 

[SYSLH_DLS_V1106] 

Anwendungsfall fehlt: Gesperrte oder ungültige Applikation erfassen: Im Prinzip ist 

der Datensatz nur für statistische Zwecke zu speichern. 

Anwendungsfall 1.2.2.10: Die Datenstruktur heißt grundsätzlich TXVPROD und nicht 

TXVTPROD wie im SysLH des DL-Terminals. 

Anwendungsfall fehlt: Gesperrten oder ungültigen EFS erfassen: Im Prinzip ist der 

Datensatz nur für statistische Zwecke zu speichern. 

Anwendungsfall fehlt: EFS_Template aktivieren: Im Prinzip ist hier der gleiche Ablauf 

wie im Anwendungsfall 1.2.2.21 beim KVPS umzusetzen. Im 

PVS wird der entsprechende Anwendungsfall 1.2.2.14 hinsichtlich 

der Weiterleitung an den DLS erweitert. 

Anwendungsfall fehlt: EFS_Template deaktivieren: Im Prinzip ist hier der gleiche Ablauf 

wie im Anwendungsfall 1.2.2.22 beim KVPS umzusetzen. 

Im PVS wird der entsprechende Anwendungsfall 1.2.2.15 hinsichtlich 

der Weiterleitung an den DLS erweitert. 

Anwendungsfall 1.7.2.17 Es handelt sich um das Einspielen von Kryptogrammen des 

Sicherheitsmanagementes, um Schlüssel zu laden, Kontingente 

zu ändern und Schlüssel zu löschen. 


[SYSLH_KVPS_V1106] hinsichtlich der Weiterleitung der Sperrnachweise 

ausgehend vom KOSE: 

Die entsprechenden Anwendungsfälle hinsichtlich WES/BER müssen noch korrigiert werden. 



Bei der Weiterleitung der Sperrnachweise gelten folgende Grundsätze: 

APP 

Abbildung 9 Weiterleitung der Sperrnachweise durch den KOSE 

NM-Sperren (WES/BER) werden vom KOSE an den zugehörigen PV und von dort aus an 

den sperrbeauftragenden KVP weitergeleitet. Von dort aus werden die sperranfordernden 

Instanzen (AH/PV/KVP/DL) informiert. Ist der zugehörige PV auch eine sperranfordernde 

Instanz, muss der Sperrnachweis nicht noch einmal an diesen weitergeleitet werden. 

NM-Sperren (APP) werden vom KOSE an den sperrbeauftragenden KVP weitergeleitet. Von 

dort aus werden die sperranfordernden Instanzen (AH/PV/KVP/DL) informiert. 

Org-/SAM-Sperren (APP/WES/BER) werden vom KOSE an 

� den AH (bei APP quasi als PV der Applikation) und 

� den PV (bei WES und BER) 

weitergeleitet. Von dort aus wird der zugehörige KVP informiert. Sperranfordernde Instanzen 

werden nicht informiert. 

6.2.2.2 Elementarprozesse 

In der folgenden Tabelle sind alle Elementarprozesse aufgeführt, die umgesetzt werden 

müssen. Diese Elementarprozesse, die in [Spec_SST_V1106] beschrieben sind und sich 

über mehrere Systeme erstrecken, schlagen sich in den verschiedenen Anwendungsfällen 


NM-Sperren 

KVP 

Anfordernde 

Instanzen 

PV 

WES/BER 

KOSE 

Sperr- 

DBase 

Org-/ 

SAM-Sperren 

AH PV 

APP 

KVP 

WES/BER


der einzelnen Systeme nieder und sind daher ebenfalls bei der Realisierung der Funktionen 

der d(((eti-API-Bibliothek zu berücksichtigen. 


Tabelle 1 Elementarprozesse 

Kapitel Spec-SST Elementarprozess 

3.1.1.1 EP_Ausgabe_Applikation (Personalisierung) 

3.1.1.3 EP_Ausgabe_Berechtigung 

3.1.2.3 EP_Belastung_WEB_KVP 

3.1.2.4 EP_Belastung_POB/PEB-Konto_KVP 

3.1.2.6 EP_Bezahlung_gesZahl 

3.1.3.1 EP_Rücknahme_Applikation 

3.1.3.2 EP_Rücknahme_Berechtigung 

3.1.5.1 EP_Rückzahlung_gesZahl 

3.1.5.2 EP_Rückzahlung_POB/PEB-Konto 

3.1.5.4 EP_Rückzahlung_WEB 

3.1.6.4 EP_Änderung_EFS 

3.1.6.5 EP_Änderung_Applikation 

3.1.6.6 EP_Änderung_Kundenprofil 

3.1.6.7 EP_Änderung_PIN 

3.2.2 EP_Kontrolle 

3.2.3 EP_Entwertung 

3.3.1.1 EP_Sperranforderung_Applikation 

3.3.1.2 EP_Sperranforderung_Berechtigung 

3.3.1.4 EP_Sperranforderung_SAM 

3.3.1.5 EP_Sperranforderung_Organisation 

3.3.1.6 EP_Sperranforderung_Key 

3.3.2.1 EP_Sperrauftrag_Applikation 

3.3.2.2 EP_Sperrauftrag_SAM 

3.3.2.3 EP_Sperrauftrag_Organisation 

3.3.2.4 EP_Sperrauftrag_Key 

3.3.2.5 EP_Sperrauftrag_Berechtigung 

3.3.3.1 EP_Sperrlistenanforderung 

3.3.3.2 EP_Sperrlistenversand 

3.3.4.1 EP_Sperrung_Applikation 

3.3.4.2 EP_Sperrung_SAM 

3.3.4.3 EP_Sperrung_Organisation 

3.3.4.4 EP_Sperrung_Berechtigung 

3.3.5.1 EP_Sperraufhebungsanforderung_Applikation 

3.3.5.2 EP_Sperraufhebungsanforderung_Berechtigung 

3.3.5.4 EP_Sperraufhebungsanforderung_SAM 

3.3.5.5 EP_Sperraufhebungsanforderung_Organisation 

3.3.5.6 EP_Sperraufhebungsanforderung_Key 

3.3.6.1 EP_Sperrfreigabeauftrag_Applikation 

3.3.6.2 EP_Sperrfreigabeauftrag_SAM 

3.3.6.3 EP_Sperrfreigabeauftrag_Organisation 

3.3.6.4 EP_Sperrfreigabeauftrag_Key 

3.3.6.5 EP_Sperrfreigabeauftrag_Berechtigung 

3.3.7.1 EP_Entsperrung_Applikation 

3.3.7.2 EP_Entsperrung_Berechtigung



Kapitel Spec-SST Elementarprozess 

3.4.1.1.1 EP_Anzeige_EFS 

3.4.1.1.2 EP_Auskunft_EFS 

3.4.1.1.3 EP_Belegdruck_EFS 

3.4.1.1.4 EP_Priorisierung_EFS 

3.4.2.1 EP_Anzeige_Applikationsdaten 

3.4.2.2 EP_Anzeige_Kundenprofil 

3.4.2.3 EP_Anzeige_Kundenpräferenzen 

3.5.2 EP_Verteilung_Keys 

3.5.3 EP_Aktivierung_NotfallKey 

3.5.4 EP_Verteilung_SAM 

3.5.5.2 EP_Verteilung_Template_BER 

3.5.6.2 EP_Deaktivieren_Template_BER 

3.5.7 EP_Verteilung_Produktmodul 

3.5.8.2 EP_Deaktivieren_EFMProd 

3.5.9 EP_Verteilung_Kontingente_BER 

6.2.2.3 Anwendungsfälle 

In den folgenden Tabellen sind alle Anwendungsfälle, für welche die d(((eti-API-Bibliothek 

Funktionen bereit stellen soll, aufgeführt. Diese Anwendungsfälle sind Bestandteile der in 

[Spec_SST_V1106] beschriebenen übergeordneten Elementarprozesse. 

Es sind alle Anwendungsfälle zur Applikation, zum EFS, zur Systemorganisation und die aus 

den Sperrprozessen resultierenden Anwendungsfälle zu den anderen Berechtigungsarten 

(WES, WES_AFB, POB/PEB und WEB) zu berücksichtigen. 

Von der Systemarchitektur her muss es grundsätzlich möglich sein, später die anderen Anwendungsfälle 

noch umzusetzen. 

6.2.2.3.1 Anwendungsfälle KVP- und DL-Server 

Um deutlich zu machen, dass bestimmte Anwendungsfälle in beiden Servern enthalten sind, 

beinhaltet die Tabelle alle Anwendungsfälle des KVP- und DL-Servers. Insofern bedeutet 

keine Angabe in der Spalte Kapitel, dass es diesen Anwendungsfall im jeweiligen Server 

nicht gibt. 

Tabelle 2 Anwendungsfälle KVP- und DL-Server 

Kapitel in 


Kapitel in 


Anwendungsfall 

1.1.2.1 Applikation ausgeben 

1.1.2.2 Applikation zurücknehmen 

1.1.2.3 Applikation ändern 

1.1.2.4 1.1.2.1 Applikation_Sperrauskunft einholen 

1.1.2.5 1.1.2.2 Applikation_Sperranforderung erzeugen 

1.1.2.6 Applikation_Sperranforderung bearbeiten 

1.1.2.7 

Applikation_Sperrauftrag und Sperrrmitteilung 

erzeugen 

1.1.2.8 1.1.2.3 Applikation_Sperrmitteilung entgegennehmen 

1.1.2.9 1.1.2.4 Applikation_Sperrnachweis einreichen


Kapitel in 


Kapitel in 



1.1.2.10 Applikation_Sperrnachweis verarbeiten 

1.1.2.11 1.1.2.5 Applikation_Sperrnachweis entgegennehmen 

1.1.2.12 1.1.2.7 

Applikation_Sperraufhebungsanforderung erzeugen 

1.1.2.13 

Applikation_Sperraufhebungsanforderung bearbeiten 

1.1.2.14 

Applikation_Sperrfreigabeauftrag und Sperrfreigabemitteilung 

erzeugen 

1.1.2.15 1.1.2.8 

Applikation_Sperrfreigabemitteilung entgegennehmen 

1.1.2.16 Applikation_Entsperrnachweis erzeugen 

1.1.2.17 1.1.2.6 Applikation_Entsperrnachweis entgegennehmen 

1.1.2.18 Applikation_TransaktionsMAC prüfen 

Fehlt noch Fehlt noch Gesperrte oder ungültige Applikation erfassen 

Fehlt noch Applikation_Entsperrnachweis an AH melden 

Fehlt noch Kundenprofil ändern 

1.2.2.1 EFS_Leistungserfassung weiterleiten 

1.2.2.2 EFS_Kontrolldaten verarbeiten 

1.2.2.1 EFS_Berechtigung ausgeben 

1.2.2.2 EFS_Berechtigung zurücknehmen 

1.2.2.3 EFS_Leistungserfassung verarbeiten 

1.2.2.4 EFS_Entwertung bearbeiten 

1.2.2.5 1.2.2.3 EFS_Sperranforderung erzeugen 

1.2.2.6 EFS_Sperranforderung bearbeiten 

1.2.2.7 EFS_Sperrauftrag und Sperrmitteilung erzeugen 

1.2.2.8 1.2.2.4 EFS_Sperrmitteilung entgegennehmen 

1.2.2.9 1.2.2.5 EFS_Sperrnachweis einreichen 

1.2.2.10 EFS_Sperrnachweis verarbeiten 

1.2.2.11 1.2.2.6 EFS_Sperrnachweis entgegennehmen 

1.2.2.12 1.2.2.7 EFS_Sperraufhebungsanforderung erzeugen 

1.2.2.13 EFS_Sperraufhebungsanforderung bearbeiten 

1.2.2.14 

EFS_Sperrfreigabeauftrag und Sperrfreigabemitteilung 

erzeugen 

1.2.2.15 1.2.2.8 EFS_Sperrfreigabemitteilung entgegennehmen 

1.2.2.16 EFS_Entsperrnachweis erzeugen 

1.2.2.17 EFS_Entsperrnachweis an PV melden 

1.2.2.18 1.2.2.9 EFS_Entsperrnachweis entgegennehmen 

1.2.2.19 EFS_Auskunftsdaten anfordern 

1.2.2.20 EFS_Quittungsdruck melden 

1.2.2.21 EFS_Template aktivieren 

1.2.2.22 EFS_Template deaktivieren 

1.2.2.23 1.2.2.10 EFS_Produktmodul aktivieren 

1.2.2.24 1.2.2.11 EFS_Produktmodul deaktivieren 

1.2.2.25 EFS_Kontingent anfordern 

1.2.2.26 EFS_Kontingent aktivieren 

1.2.2.27 EFS_TransaktionsMAC prüfen 

Fehlt noch Fehlt noch Gesperrten oder ungültigen EFS erfassen 



Kapitel in 



Kapitel in 



1.3.2.5 POB/PEB_Konto_Belastung durch KVP melden 

1.3.2.10 POB/PEB_WE -Gutschrift melden 

1.3.2.19 1.3.2.5 POB/PEB_Sperrnachweis einreichen 

1.4.2.2 WEB_Belastung durch KVP melden 

1.4.2.5 WEB_WE-Gutschrift melden 

1.4.2.15 1.4.2.5 WEB_Sperrnachweis einreichen 

1.5.2.7 1.5.2.3 WES-AFB_Sperrnachweis einreichen 

1.6.2.12 1.6.2.4 WES_Sperrnachweis einreichen 

1.8.2.1 1.7.2.1 SAM_Sperranforderung erzeugen 

1.8.2.2 1.7.2.2 ORG_Sperranforderung erzeugen 

1.8.2.3 1.7.2.3 Key_Sperranforderung erzeugen 

1.8.2.4 1.7.2.5 Organisation_Sperrmitteilung entgegennehmen 

1.8.2.5 1.7.2.6 Key_Sperrmitteilung entgegennehmen 

1.8.2.6 1.7.2.4 SAM_Sperrmitteilung entgegennehmen 

1.8.2.7 1.7.2.7 Sperrlisten anfordern 

1.8.2.8 1.7.2.8 Sperrlisten empfangen und aktivieren 

Fehlt noch 1.7.2.9 SAM_Sperrnachweis einreichen 

Fehlt noch 1.7.2.10 ORG_Sperrnachweis einreichen 

1.8.2.9 ORG_Sperrnachweis verarbeiten 

1.8.2.10 SAM_Sperrnachweis verarbeiten 

1.8.2.11 1.7.2.13 Key_Sperraufhebungsanforderung erzeugen 

1.8.2.12 1.7.2.12 ORG_Sperraufhebungsanforderung erzeugen 

1.8.2.13 1.7.2.11 SAM_Sperraufhebungsanforderung erzeugen 

1.8.2.14 1.7.2.15 

Organisation_Sperrfreigabemitteilung entgegennehmen 

1.8.2.15 1.7.2.16 Key_Sperrfreigabemitteilung entgegennehmen 

1.8.2.16 1.7.2.14 SAM_Sperrfreigabemitteilung entgegennehmen 

1.8.2.17 1.7.2.17 Key verteilen und aktivieren 

1.8.2.18 1.7.2.18 SAM verteilen 

6.2.2.3.2 Anwendungsfälle KVP-Terminal 

Die folgende Tabelle stellt alle Anwendungsfälle eines personalbedienten KVP-Terminals 

dar. Die Anwendungsfälle eines selbstbedienten KVP-Terminals sind eine Untermenge dieser 

Anwendungsfälle. Insofern können mit diesen Anwendungsfällen alle Ausprägungen eines 

KVP-Terminals realisiert werden. Innerhalb des KVP-Terminals ist auf jeden Fall die 

Schnittstelle KVP-VE – KVP-PE (siehe [SPEC-PE]) umzusetzen. 

Kapitel in 

[SYSLH_PbRTKVP_V1106] 1 

Tabelle 3 Anwendungsfälle KVP-Terminal 


(kursiv = Anwendungsfall ohne NM) 

1.1.2.1 Applikation ausgeben (Personalisierung) 

1.1.2.2 APP mit gesZahl bezahlen 


1.1.2.4 APP gegen gesetzliches Zahlungsmittel zurückzahlen 


1 Den Anwendungsfall 1.1.2.8 gibt es im KVP-Terminal nicht.


Kapitel in 

[SYSLH_PbRTKVP_V1106] 1 


1.1.2.6 Kundenprofil ändern 

1.1.2.7 PIN ändern 


(kursiv = Anwendungsfall ohne NM) 

1.1.2.7 

(SYSLH_SbRTKVP) 

PIN prüfen 

1.1.2.9 Applikation sperren 

1.1.2.10 Applikation entsperren 

1.1.2.11 Applikationsdaten anzeigen 

1.1.2.12 Kundenprofil anzeigen 

1.1.2.13 Kundenpräferenzen anzeigen 

1.1.2.14 Gesperrte oder ungültige Applikation erfassen 

1.1.2.15 Defektes Medium erfassen 

1.2.2.1 EFS-Berechtigung ausgeben 

1.2.2.2 EFS mit gesZahl bezahlen 

1.2.2.3 EFS-Berechtigung zurücknehmen 

1.2.2.4 EFS erstatten 

1.2.2.5 EFS gegen gesetzliches Zahlungsmittel zurückzahlen 

1.2.2.6 EFS ändern 

1.2.2.7 EFS-Berechtigung sperren 

1.2.2.8 EFS-Berechtigung entsperren 

1.2.2.9 Gesperrten oder ungültigen EFS erfassen 

1.2.2.10 EFS anzeigen 

1.2.2.11 EFS als Kundenpräferenz festlegen 

1.2.2.12 EFS_Auskunft erteilen (nur für Post-priced-Produkte) 

1.2.2.13 EFS_Beleg drucken (pre-priced) 

1.2.2.14 EFS_Beleg drucken (post-priced) 

1.2.2.15 EFS priorisieren 

1.3.2.6 POB-/PEB-Konto belasten 

1.3.2.8 POB/PEB_Gutschrift realisieren 

1.3.2.12 POB-/PEB sperren 

1.4.2.5 WEB belasten 

1.4.2.8 WEB_WE-Gutschrift realisieren 

1.4.2.12 WEB sperren 

1.5.2.15 WES sperren 

1.5.2.17 WES-AFB sperren 

1.6.2.1 SAM-Konfiguration prüfen 

1.6.2.2 Sperrlisten aktualisieren 

1.6.2.3 BER_Template entgegennehmen 

1.6.2.4 EFMProduktmodul entgegennehmen 

1.6.2.5 EFMProduktmodul aktivieren 

1.6.2.6 BER_Template deaktivieren 

1.6.2.7 EFMProduktmodul deaktivieren 

1.6.2.8 BER_Kontingente anfordern und aktualisieren 

1.6.2.15 Key laden 

1.6.2.16 Notfall_Key aktivieren/Schlüssel löschen

Distribution von eTickets über das Internet d(((eti – Leistungsbeschreibung Seite 44 

6.2.2.4 Schnittstellen 

KVP- und DL-Server sowie das KVP-Terminal sind über Schnittstellen untereinander und mit den benachbarten Systemen verbunden. Die folgenden 

Tabellen geben die Zuordnung der Anwendungsfälle in den jeweiligen Systemen und die zwischen diesen Systemen zu übertragenden 

Datenstrukturen wieder. Dabei sind für den KVP- und DL-Server als Kern des ganzen immer alle Anwendungsfälle unabhängig davon aufgeführt, 

ob sie für die jeweilige Schnittstelle relevant sind oder nicht. Alle Anwendungsfälle des KVP-Terminals können ausschließlich Kapitel 

6.2.2.3.2 entnommen werden. 

6.2.2.4.1 Schnittstelle KVPS – KVP-Terminal 

Tabelle 4 Anwendungsfälle KVP-Server und -Terminal 

Kapitel im 

[SYSLH_KVPS_V1106] Anwendungsfall Datenstruktur 

Kapitel in 

[SYSLH_PbRTKVP_V1106] Anwendungsfall 

1.1.2.1 Applikation ausgeben


Kapitel im 


1.1.2.14 

bearbeiten 

Applikation_Sperrfreigabeauftrag und Sperr- 

1.1.2.15 


freigabemitteilung erzeugen 


Kapitel in 



1.1.2.16 Applikation_Entsperrnachweis erzeugen


Kapitel im 


1.2.2.12 EFS_Sperraufhebungsanforderung erzeugen 

1.2.2.13 EFS_Sperraufhebungsanforderung bearbeiten 

1.2.2.14 

EFS_Sperrfreigabeauftrag und Sperrfreiga- 

1.2.2.15 


bemitteilung erzeugen 

EFS_Sperrfreigabemitteilung entgegennehmen 

Kapitel in 


1.2.2.16 EFS_Entsperrnachweis erzeugen TXDEABER 1.6.2.6 

1.2.2.23 EFS_Produktmodul aktivieren 

>TXVTPROD 1.6.2.4 

1.6.2.5 

1.2.2.24 EFS_Produktmodul deaktivieren >TXDEABER 1.6.2.7 


EFS-Berechtigung entsperren 

EFS_Auskunft erteilen 

(nur für Post-priced- 

Produkte) 

EFS_Beleg drucken 

(post-priced) 

BER_Template entgegennehmen 

BER_Template deaktivieren 

EFMProduktmodul entgegennehmen 

EFMProduktmodul aktivieren 

EFMProduktmodul deak- 

tivieren 

1.2.2.25 

1.2.2.26 

EFS_Kontingent anfordern 

EFS_Kontingent aktivieren 

TXUEBERKON 

1.6.2.8 

BER_Kontingente anfordern 

und aktualisieren 


Fehlt noch Gesperrten oder ungültigen EFS erfassen


Kapitel im 


Kapitel in 

[SYSLH_PbRTKVP_V1106] Anwendungsfall 

gen EFS erfassen 

1.3.2.5 

POB/PEB_Konto_Belastung durch KVP melden 


Kapitel im 




1.8.2.11 Key_Sperraufhebungsanforderung erzeugen 

1.8.2.12 ORG_Sperraufhebungsanforderung erzeugen 

1.8.2.13 SAM_Sperraufhebungsanforderung erzeugen 

1.8.2.14 


1.8.2.15 

Key_Sperrfreigabemitteilung entgegenneh- 

1.8.2.16 


men 

SAM_Sperrfreigabemitteilung entgegennehmen 

1.8.2.17 Key verteilen und aktivieren 

1.8.2.18 SAM verteilen 

6.2.2.4.2 Schnittstelle KOSES - KVPS 

Tabelle 5 Anwendungsfälle KOSE und KVP-System 

Kapitel im 

[SYSLH_KOSES_V1106] Anwendungsfall Datenstruktur 

1.1.2.1 

Applikation_Sperrauftrag bearbeiten 

Kapitel in 



Kryptogramm 1.6.2.15 Key laden 

Kryptogramm 1.6.2.16 

Notfall_Key aktivieren/Schlüssel 

löschen 


Kapitel im 


Kapitel im 



1.1.2.8 

Applikation_Sperrmitteilung entgegennehmen 

1.1.2.2 

Applikation_Sperrnachweis bearbeiten 

TXSNAWA 

1.1.2.9 

1.1.2.10 

Applikation_Sperrnachweis einreichen 

Applikation_Sperrnachweis verarbeiten 

1.1.2.11 

Applikation_Sperrnachweis entgegennehmen 

1.1.2.12 

Applikation_Sperraufhebungsanforderung 

erzeugen 

1.1.2.13 


bearbeiten 

1.1.2.3 

Applikation_Sperrfreigabeauftrag 

bearbeiten 


Kapitel im 


Kapitel im 



1.2.2.7 

EFS_Sperrauftrag und Sperrmitteilung erzeugen 

1.2.2.8 EFS_Sperrmitteilung entgegennehmen 

1.2.2.2 EFS_Sperrnachweis bearbeiten 

TXSNAWB 

1.2.2.9 

1.2.2.10 

EFS_Sperrnachweis einreichen 

EFS_Sperrnachweis verarbeiten 

1.2.2.11 EFS_Sperrnachweis entgegennehmen 

1.2.2.12 

EFS_Sperraufhebungsanforderung erzeugen 

1.2.2.13 

EFS_Sperraufhebungsanforderung bearbeiten 

1.2.2.3 

EFS_Sperrfreigabeauftrag bearbeiten 

< TXSFREIB 1.2.2.14 

EFS_Sperrfreigabeauftrag und Sperrfreigabemitteilung 

erzeugen 

1.2.2.15 




1.2.2.18 EFS_Entsperrnachweis entgegennehmen 







1.2.2.24 EFS_Produktmodul deaktivieren 




Fehlt noch Gesperrten oder ungültigen EFS erfassen 

1.3.2.5 POB/PEB_Konto_Belastung durch KVP


Kapitel im 


1.3.2.2 


POB/PEB_Sperrnachweis bearbeiten 

Kapitel im 



1.3.2.10 

melden 

POB/PEB_WE -Gutschrift melden 


Kapitel im 


6.2.2.4.3 Schnittstelle AHS – KVPS 


Kapitel im 


1.8.2.11 

1.8.2.12 

1.8.2.13 

1.8.2.14 

1.8.2.15 

1.8.2.16 

Tabelle 6 Anwendungsfälle AH und KVP-System 

Kapitel in 

[SYSLH_AHS_V1106] Anwendungsfall Datenstruktur 


Key_Sperraufhebungsanforderung erzeugen 

ORG_Sperraufhebungsanforderung erzeugen 

SAM_Sperraufhebungsanforderung erzeugen 


Key_Sperrfreigabemitteilung entgegennehmen 




Kapitel in 



1.1.2.1 Applikation ausgeben


Kapitel in 


Kapitel in 



men und registrieren teilung erzeugen 

1.1.2.8 


1.1.2.9 Applikation_Sperrnachweis einreichen 

1.1.2.7 


TXSAANFA 1.1.2.13 


bearbeiten 

1.1.2.9 

Appliktion_Sperrfreigabemitteilung entgegennehmen 

und registrieren 


Kapitel in 



Kapitel in 



1.2.2.5 EFS_Sperranforderung erzeugen 

1.2.2.6 EFS_Sperranforderung bearbeiten 

1.2.2.7 

EFS_Sperrauftrag und Sperrmitteilung 

erzeugen 


1.2.2.9 EFS_Sperrnachweis einreichen 



1.2.2.12 


1.2.2.13 


1.2.2.14 

EFS_Sperrfreigabeauftrag und Sperrfrei- 

gabemitteilung erzeugen 

1.2.2.15 












1.2.2.26 EFS_Kontingent aktivieren


Kapitel in 



Kapitel in 





1.3.2.5 

POB/PEB_Konto_Belastung durch KVP 

melden 


1.3.2.19 POB/PEB_Sperrnachweis einreichen 



1.4.2.15 WEB_Sperrnachweis einreichen 

1.5.2.7 WES-AFB_Sperrnachweis einreichen 

1.6.2.12 WES_Sperrnachweis einreichen 

1.7.2.1 SAM_Sperranforderung bearbeiten TXSMITK 1.8.2.6 SAM_Sperrmitteilung entgegennehmen 

1.8.2.7 Sperrlisten anfordern 

1.8.2.8 Sperrlisten empfangen und aktivieren 

Fehlt noch SAM_Sperrnachweis einreichen 

Fehlt noch ORG_Sperrnachweis einreichen 

1.7.2.8 Organisation_Sperrnachweis bearbeiten >TXSNAWA 1.8.2.9 ORG_Sperrnachweis verarbeiten 

1.7.2.7 SAM_Sperrnachweis bearbeiten >TXSNAWA 1.8.2.10 SAM_Sperrnachweis verarbeiten 

1.7.2.11 

Key_Sperraufhebungsanforderung bearbei- 


Kapitel in 


1.7.2.9 

SAM_Sperraufhebungsanforderung bear- 

1.7.2.13 

beiten 


Organisation_Sperrfreigabeauftrag erzeugen 

Kapitel in 


TXSFREIMITO 1.8.2.14 

1.7.2.14 Key_Sperrfreigabeauftrag erzeugen >TXSFREIMITK 1.8.2.15 

1.7.2.12 SAM_Sperrfreigabeauftrag erzeugen >TXSFREIMITS 1.8.2.16 

6.2.2.4.4 Schnittstelle PVS - KVPS 

Kapitel im 

[SYSLH_PVS_V1106] 



Organisation_Sperrfreigabemitteilung 

entgegennehmen 





Tabelle 7 Anwendungsfälle PV- und KVP-System 

Anwendungsfall Datenstruktur 

Kapitel im 






1.1.2.4 Applikation_Sperrauskunft einholen 

1.1.2.5 Applikation_Sperranforderung erzeugen 

1.1.2.6 Applikation_Sperranforderung bearbeiten 

1.1.2.7 

Applikation_Sperrauftrag und Sperrrmitteilung 

erzeugen 

1.1.2.8 



1.1.2.10 Applikation_Sperrnachweis verarbeiten


Kapitel im 



Kapitel im 



1.1.2.11 


1.1.2.12 


erzeugen 

1.1.2.13 


bearbeiten 

1.1.2.14 

Applikation_Sperrfreigabeauftrag und 

Sperrfreigabemitteilung erzeugen 

1.1.2.15 


1.1.2.16 Applikation_Entsperrnachweis erzeugen 

1.1.2.17 

Applikation_Entsperrnachweis entgegennehmen 


Fehlt noch 

Gesperrte oder ungültige Applikation erfassen 

Fehlt noch 

Applikation_Entsperrnachweis an AH melden 


1.2.2.1 EFS_Berechtigung ausgeben TXSANFB 1.2.2.6 EFS_Sperranforderung bearbeiten 

1.2.2.6 

EFS_Sperrmitteilung entgegennehmen 



Kapitel im 




Kapitel im 





1.2.2.7 EFS_Sperrnachweis bearbeiten >TXSNAWB 


1.2.2.12 


1.2.2.8 

EFS_Sperraufhebungsanforderung 

erzeugen 

>TXSAANFB 1.2.2.13 


1.2.2.9 



TXVPROD 1.2.2.23 EFS_Produktmodul aktivieren 

1.2.2.18 EFS_Produkt deaktivieren >TXDEABER 1.2.2.24 EFS_Produktmodul deaktivieren 


TXUEBERKON 

1.2.2.25 

1.2.2.26 

EFS_Kontingent anfordern 

EFS_Kontingent aktivieren 



1.3.2.3 POB/PEB_Konto_Belastung durch


Kapitel im 




Kapitel im 



KVP melden melden 

1.3.2.6 POB/PEB_WE-Gutschrift melden TXSNAWB 

>TXSNAWW 


1.8.2.11 


1.8.2.12 

ORG_Sperraufhebungsanforderung erzeugen


Kapitel im 


6.2.2.4.5 Schnittstelle KVPS – KVPS 



Dies ist die Schnittstelle zwischen einem Fremd-KVP und dem des d(((eti-Systems. 

Kapitel im 


1.8.2.13 

1.8.2.14 

1.8.2.15 

1.8.2.16 








Tabelle 8 Anwendungsfälle zwischen zwei KVP-Systemen 

Kapitel im 


Kapitel im 







1.1.2.6 Applikation_Sperranforderung bearbeiten TXSANFA 1.1.2.6 Applikation_Sperranforderung bearbeiten 

1.1.2.8 


TXSMITA 1.1.2.8 

Applikation_Sperrmitteilung entgegennehmen


Kapitel im 


Kapitel im 




1.1.2.11 


TXSNAWA 1.1.2.11 


1.1.2.13 


bearbeiten 



bearbeiten 

1.1.2.15 


TXSFREIMITA 1.1.2.15 


1.1.2.17 


TXSNAWA 1.1.2.17 



Fehlt noch 


Fehlt noch 

Applikation_Entsperrnachweis an AH 

melden 


1.2.2.1 EFS_Berechtigung ausgeben 

1.2.2.2 EFS_Berechtigung zurücknehmen 

1.2.2.3 EFS_Leistungserfassung verarbeiten 

1.2.2.4 EFS_Entwertung bearbeiten 

1.2.2.6 EFS_Sperranforderung bearbeiten


Kapitel im 


Kapitel im 



1.2.2.5 EFS_Sperranforderung erzeugen >TXSANFB 1.2.2.6 EFS_Sperranforderung bearbeiten 

1.2.2.8 EFS_Sperrmitteilung entgegennehmen TXSMITB 1.2.2.8 EFS_Sperrmitteilung entgegennehmen 


1.2.2.11 EFS_Sperrnachweis entgegennehmen TXSNAWB 1.2.2.11 EFS_Sperrnachweis entgegennehmen 

1.2.2.13 


TXSAANFB 1.2.2.13 


1.2.2.15 


TXSFREIMITB 1.2.2.15 


1.2.2.18 EFS_Entsperrnachweis entgegennehmen TXSNAWB 1.2.2.18 EFS_Entsperrnachweis entgegennehmen 









1.2.2.26 EFS_Kontingent aktivieren


Kapitel im 



Kapitel im 





1.3.2.5 


melden 








1.8.2.1 SAM_Sperranforderung erzeugen 

1.8.2.2 ORG_Sperranforderung erzeugen 

1.8.2.3 Key_Sperranforderung erzeugen 

1.8.2.4 

Organisation_Sperrmitteilung entgegennehmen 

1.8.2.5 Key_Sperrmitteilung entgegennehmen 

1.8.2.6 SAM_Sperrmitteilung entgegennehmen 







1.8.2.11 


1.8.2.12 

ORG_Sperraufhebungsanforderung erzeugen


Kapitel im 


6.2.2.4.6 Schnittstelle DLS - KVPS 


Kapitel im 


1.8.2.13 

1.8.2.14 

1.8.2.15 

1.8.2.16 









Dies ist die Schnittstelle zwischen einem Fremd-DL und dem KVP des d(((eti-Systems. Diese Schnittstelle ist auch innerhalb des d(((eti- 

Systems für die Kommunikation zwischen dem KVP- und DL-Server relevant. 

Tabelle 9 Anwendungsfälle KVP- und DL-System 

Kapitel im 

[SYSLH_DLS_V1106] Anwendungsfall Datenstruktur 

Kapitel im 








1.1.2.2 Applikation_Sperranforderung erzeugen >TXSANFA 1.1.2.6 Applikation_Sperranforderung bearbeiten 

1.1.2.3 



Kapitel im 


1.1.2.5 

1.1.2.7 

1.1.2.8 

1.1.2.6 




erzeugen 



Kapitel im 



1.1.2.9 

nehmen 

Applikation_Sperrnachweis einreichen 



Kapitel im 


Kapitel im 



1.2.2.3 EFS_Sperranforderung erzeugen >TXSANFB 1.2.2.6 EFS_Sperranforderung bearbeiten 

1.2.2.4 EFS_Sperrmitteilung entgegennehmen


Kapitel im 



Kapitel im 


1.3.2.5 



melden 











1.8.2.4 










1.8.2.11 


1.8.2.12 

ORG_Sperraufhebungsanforderung er- 

1.8.2.13 

zeugen 

SAM_Sperraufhebungsanforderung erzeugen


Kapitel im 


6.2.2.4.7 Schnittstelle DLS – DL-Terminal 


Kapitel im 


1.8.2.14 

1.8.2.15 

1.8.2.16 








Tabelle 10 Anwendungsfälle DL-System und -Terminal 

Kapitel im 


Kapitel im 

[SYSLH_RTDL_V1106] Anwendungsfall 

1.1.2.1 Applikation_Sperrauskunft einholen


Kapitel im 


Kapitel im 


sen kation erfassen 

1.2.2.1 EFS-Berechtigung erfassen 

1.2.2.2 

Sonderfall: Erfassung EFS und 

AFB mit Anrechnung des EFS 

Fall 1: EFS mit ergänzender 

1.2.2.2.1 Berechnung eines Fahrtanteils 

auf eine AFB 

1.2.2.1 

1.2.2.2 

EFS_Leistungserfassung weiterleiten 

EFS_Kontrolldaten verarbeiten 

TXVTPROD 1.6.2.4 

EFMProduktmodul entgegennehmen 

1.6.2.5 EFMProduktmodul aktivieren 

>TXVKON 1.6.2.7 EFMKontrollmodul entgegen- 



Kapitel im 


Kapitel im 


nehmen 

1.2.2.11 EFS_Produktmodul deaktivieren >TXDEABER 

1.6.2.6 

1.6.2.8 

EFMProduktmodul deaktivieren 

EFMKontrollmodul deaktivieren 

Fehlt noch Gesperrten oder ungültigen EFS erfassen


Kapitel im 


1.7.2.11 


1.7.2.12 



1.7.2.14 

1.7.2.15 

1.7.2.16 







6.2.2.4.8 Schnittstelle KOSES - DLS 

Kapitel im 

[SYSLH_RTDL_V1106] 


Kryptogramm 1.6.2.13 Key laden 

Kryptogramm 1.6.2.14 

Notfall_Key aktivieren/Schlüssel 

löschen 

Tabelle 11 Anwendungsfällle KOSE und DL-System 

Kapitel im 


1.1.2.2 

Applikation_Sperrnachweis 

bearbeiten 

Kapitel im 





1.1.2.3 



Kapitel im 


1.2.2.2 


EFS_Sperrnachweis bearbeiten 

Kapitel im 


1.1.2.6 

1.1.2.7 

1.1.2.8 

Fehlt noch 

1.2.2.1 

1.2.2.2 


men 



erzeugen 








Kapitel im 


1.3.2.2 

1.4.2.2 

1.6.2.2 

1.7.2.5 

1.7.2.6 


POB/PEB_Sperrnachweis bearbeiten 

WEB_Sperrnachweis bearbeiten 

WES-AFB_Sperrnachweis bearbeiten 

WES_Sperrnachweis bearbeiten 

Angeforderte Sperrliste versenden 

SAM_Sperrnachweis bearbeiten 

Kapitel im 







Kapitel im 


1.7.2.7 

6.2.2.4.9 Schnittstelle AHS - DLS 


Organisation_Sperrnachweis 

bearbeiten 


Kapitel im 



Kapitel im 




1.1.2.5 


1.1.2.6 


1.1.2.7 


erzeugen 

1.1.2.8 

Applikation_Sperrfreigabemitteilung ent- 

Fehlt noch 

1.2.2.1 

1.2.2.2 

gegennehmen 








1.2.2.7 

EFS_Sperraufhebungsanforderung er- 

zeugen 

1.2.2.8 



1.2.2.10 EFS_Produktmodul aktivieren


Kapitel im 



Kapitel im 









1.7.2.1 SAM_Sperranforderung bearbeiten TXSMITK 1.7.2.6 Key_Sperrmitteilung entgegennehmen 



1.7.2.9 SAM_Sperrnachweis einreichen 

1.7.2.9 

1.7.2.10 

1.7.2.11 

SAM_Sperraufhebungsanforderung bearbeiten 

Organisation_Sperraufhebungsanforderung 

bearbeiten 

Key_Sperraufhebungsanforderung bearbeiten 

1.7.2.10 ORG_Sperrnachweis einreichen 


Kapitel im 



Kapitel im 


1.7.2.12 SAM_Sperrfreigabeauftrag erzeugen >TXSFREIMITS 1.7.2.14 

1.7.2.13 

Organisation_Sperrfreigabeauftrag erzeugen 

>TXSFREIMITO 1.7.2.15 

1.7.2.14 Key_Sperrfreigabeauftrag erzeugen >TXSFREIMITK 1.7.2.16 

6.2.2.4.10 Schnittstelle PVS - DLS 

Kapitel im 

[SYSLH_PVS_V1106] Anwendungsfall Datenstruktur 

Tabelle 13 Anwendungsfälle PV-System und DL-System 








Kapitel im 





1.1.2.3 Applikation_Sperrmitteilung entgegennehmen 


1.1.2.5 Applikation_Sperrnachweis entgegennehmen 

1.1.2.6 Applikation_Entsperrnachweis entgegennehmen 

1.1.2.7 

Applikation_Sperraufhebungsanforderung erzeu- 

gen 

1.1.2.8 


Fehlt noch Gesperrte oder ungültige Applikation erfassen


Kapitel im 


1.2.2.3 



TXDEABER 1.2.2.11 EFS_Produktmodul deaktivieren 








1.7.2.3 Key_Sperranforderung erzeugen


Kapitel im 


6.2.2.4.11 Schnittstelle KVPS – DLS 


Kapitel im 




1.7.2.5 Organisation_Sperrmitteilung entgegennehmen 





1.7.2.10 ORG_Sperrnachweis einreichen 

1.7.2.11 SAM_Sperraufhebungsanforderung erzeugen 

1.7.2.12 ORG_Sperraufhebungsanforderung erzeugen 


1.7.2.14 SAM_Sperrfreigabemitteilung entgegennehmen 

1.7.2.15 


1.7.2.16 Key_Sperrfreigabemitteilung entgegennehmen 



Diese Schnittstelle entspricht der Schnittstelle im Kapitel 6.2.2.4.6. Nur die Darstellung ist an die konkrete Situation angepasst worden.



Tabelle 14 Anwendungsfälle KVP-System und DL-System 

Kapitel im 


Kapitel im 




1.1.2.6 Applikation_Sperranforderung bearbeiten TXSNAWA 1.1.2.5 

1.1.2.16 Applikation_Entsperrnachweis erzeugen >TXSNAWA 1.1.2.6 

1.1.2.13 

1.1.2.14 


bearbeiten 

Applikation_Sperrfreigabeauftrag und 

Sperrfreigabemitteilung erzeugen 

>TXSMITA 1.1.2.3 





TXSFREIMITA 1.1.2.8 

Applikation_Sperrfreigabemitteilung ent- 

Fehlt noch 

1.2.2.1 

1.2.2.2 

gegennehmen 




1.2.2.6 EFS_Sperranforderung bearbeiten TXSMITB 1.2.2.4 EFS_Sperrmitteilung entgegennehmen 


1.2.2.10 EFS_Sperrnachweis verarbeiten >TXSNAWB 1.2.2.6 EFS_Sperrnachweis entgegennehmen


Kapitel im 


Kapitel im 



1.2.2.13 


TXSFREIMITB 1.2.2.8 


1.2.2.16 EFS_Entsperrnachweis erzeugen >TXSNAWB 1.2.2.9 EFS_Entsperrnachweis entgegennehmen 













1.7.2.5 






1.7.2.10 ORG_Sperrnachweis einreichen


Kapitel im 



Kapitel im 


1.7.2.11 

1.7.2.12 

1.7.2.13 

1.7.2.14 

1.7.2.15 

1.7.2.16 










1.7.2.18 SAM verteilen


6.2.3 Umfang der zwei Entwicklungsphasen 

Zur Entwicklung des d(((eti-eTicket-Viewers ist lediglich eine Untermenge der Anwendungsfälle 

notwendig. Es kommen nur Anwendungsfälle in Frage, die in der Schnittstelle KVP- 

Server KVP-Terminal und im Systemlastenheft Selbstbediente KVP-Referenzterminals 

[SYSLH_SbRTKVP_V1106] beschrieben sind. 

Diese sind zunächst zu entwickeln und zu implementieren. 



6.3 d(((eti-eTicket-Viewer 

6.3.1 Funktion 

Der d(((eti-eTicket-Viewer dient primär der kundenorientierten Anzeige von Berechtigungen 

auf einem Nutzermedium nach Kernapplikation. Minimalfunktion ist die Interpretation des 

Referenz-EFS, von EFS, wie sie in VGN, VRR und VRS sowie von AFB wie sie in Schwäbisch-Hall 

eingesetzt werden. 

Zusätzlich sollen für eher technisch orientierte Nutzer die kompletten Berechtigungen ausgegeben 

werden können, wobei unspezifizierte Teile uninterpretiert im Hexadezimalformat 

ausgegeben werden müssen (Experten- bzw. Entwicklermodus). 

6.3.2 Bedienung 

Der d(((eti-eTicket-Viewer soll primär von Endkunden und Servicepersonal benutzt werden. 

Dies bedingt, dass die Bedienung möglichst einfach und selbsterklärend sein muss. Er soll 

unter Windows und Linux in einer graphischen Umgebung laufen. Die Funktionen sollen über 

eine graphische Nutzungsoberfläche (GUI) bedient werden. 

Das Programm soll nach dem Start ein Fenster zur Darstellung der Nutzermedien- und Berechtigungsdaten 

zeigen. 

Zur Anpassung an ein möglichst großes Spektrum von Bildschirmauflösungen sollte Scrolling 

in horizontaler und vertikaler Richtung möglich sein, wenn die Bedienelemente bzw. Ausgaben 

des Programms nicht im aktuellen Fensterareal zu sehen sind. 

Am unteren Rand des Fensters sollte eine Statuszeile Auskunft über den aktuellen Betriebszustand 

des Programms geben. 

Eine Menüleiste muss Menüs zur Bedienung des d(((eti-eTicket-Viewers aufnehmen. 

Mindestens die Menüs „Datei“, „Ansicht“, „Einstellungen“ und „Hilfe“ muss vorhanden sein. 

Das Auslesen von Nutzermedien soll durch den Benutzer ausgelöst werden. Dazu dient eine 

eindeutig gekennzeichnete Schaltfläche im Hauptfenster. Alternativ ist das Auslesen durch 

die Auswahl eines Menüpunktes „Nutzermedium auslesen“ bzw. „Chipkarte auslesen“ vorzusehen. 

Über das „Datei“-Menü sollen Nutzermedieninhalte als Text abgespeichert werden können. 

Zudem sollen Dateien im gleichen Format eingelesen und im d(((eti-eTicket-Viewer angezeigt 

werden können. 

Andere Darstellungs- und Bedienungsformen können nach Absprache zwischen Auftragnehmer 

und Auftraggeber hinzukommen. 

6.3.3 Konfiguration 

Zur Interpretation der Berechtigungen von Nutzermedien soll der d(((eti-eTicket-Viewer KA- 

Produkt- und Kontrollmodule nutzen. Mechanismen zur Verwaltung dieser Module sind vorzusehen. 



Darstellungsmodus und andere Einstellungen, insbesondere Informationen über den genutzten 

Schreib-/Leser müssen automatisch beim Programmstart geladen und beim Programmstop 

abgespeichert werden. 

Alle zur Konfiguration notwendigen Dateien sind als Textdateien auszuführen. 

6.3.4 Online-Hilfe 

Alle Funktionen des d(((eti-eTicket-Viewers sind in einer Online-Hilfe beschrieben. 

6.3.5 Design 

Das Design ist an den Veröffentlichungen der VDV-KA KG zur Kundenschnittstelle (z.B. 

[SPEC_KUSCH_V1106]) anzulehnen. Im Erscheinungsbild des d(((eti-eTicket-Viewers ist 

Raum für ein Logo eines Verkehrsunternehmens vorzusehen. Das konkret angezeigte Logo 

soll durch Konfiguration leicht austauschbar sein. 



6.4 d(((eti-System 

6.4.1 Funktion des Gesamtsystems 

Das d(((eti-System weist aus Nutzersicht eine Fülle von Funktionen auf: 

a) Speicherung und Verarbeitung von Kundendaten 

b) Speicherung und Verarbeitung von Produktdaten 

c) Speicherung und Verarbeitung von Sperrdaten 

d) Speicherung und Verarbeitung von KVP-Daten 

e) Ausgabe und Änderung von eTickets 

f) Sperrung von eTickets 

g) Personalisierung von Nutzermedien 

h) Datenaustausch mit KA-Systemen KOSES, AHS, PVS, andere KVP- und DL- 

Systeme. 

Einen Teil der Funktionen muss das d(((eti-System automatisch bzw. zeitgesteuert ohne 

Auslösung durch einen Benutzer wahrnehmen. Dies gilt insbesondere für die Speicherung 

und Verarbeitung von Sperrdaten sowie die Speicherung und Verarbeitung von Daten anderer 

KA-Systeme. 

6.4.2 Mögliche Systemarchitektur 

In der folgenden Abbildung ist eine mögliche Systemarchitektur für das d(((eti-System zu 

sehen. 



Abbildung 10 Mögliche Architektur des d(((eti-Systems 

Die einzelnen Programmmodule ergeben sich im Wesentlichen aus der Bedienung von KA- 

Schnittstellen und den Besonderheiten der Webschnittstelle. 

Zur Ablage von Daten sollte auf ein relationales Datenbanksystem zurück gegriffen werden. 

Der Datenaustausch mit dem DL-Terminal sollte in der unteren Protokollschicht per ftps geschehen. 

Ein entsprechender ftps-Server sollte in den d(((eti-Server integriert sein. 

Die Nutzerfunktionen werden per Web-Zugriff ausgelöst. Ein entsprechender Webserver 

sollte zum d(((eti-Server gehören. 

Die hier gezeigte interne Architektur ist nicht zwingend zu implementieren, sondern als ein 

möglicher Lösungsweg zur Bereitstellung der in der Leistungsbeschreibung geforderten 

Funktionalität des d(((eti-Servers zu verstehen. 



6.4.3 Automatisch erstellte Protokolle / Logging 

Viele Funktionen des d(((eti-Systems sollen automatisch (zeitgesteuert oder durch andere 

Systeme ausgelöst) ablaufen. Der Ablauf solcher Automatismen sollte vom Administrator 

und von Entwicklern zur Fehlersuche nachvollzogen werden können. 

Etliche Funktionen, die durch Bedienhandlungen von Benutzern ausgelöst werden, können 

so wichtig für die Funktion des Systems oder die gesamte Organisation des EFM sein, dass 

ihr Aufruf ebenfalls nachvollzogen werden können muss. 

Zur Lösung der beiden geschilderten Aufgaben muss das d(((eti-System über eine automatisierte 

Protokollierung verfügen. Die erzeugten Protokolle sollen in einfache Textdateien abgelegt 

werden, damit sie im Fehlerfall auch ohne ein laufendes d(((eti-System interpretiert 

werden kann. 

Grundsätzlich soll jedes zu loggende Ereignis in nur einer Zeile protokolliert werden. Dies 

erleichtert die Sortierung einer Logdatei nach anderen Kriterien als der Zeit des Loggings. 

Alle Einträge in die Logdateien sind mit einem Zeitstempel zu versehen. Die Logdateien sollen 

Einträge für einen bestimmten, durch die Administratoren einstellbaren Zeitraum enthalten. 

Nach Ablauf dieses Zeitraums sollen die alten Logdateien archiviert und neue angelegt 

werden. 

Die Logdateien sollen so angelegt und verwaltet werden, dass sie nur vom d(((eti-System 

geschrieben werden können. Alle Nutzer des Server-Rechners sollen die Dateien lediglich 

lesen können. 

Das d(((eti-System muss eine Möglichkeit bieten, die Logdateien über eine Web- 

Nutzungsschnittstelle von entfernten Rechnern einzusehen. 

Das d(((eti-System muss mehrere Protokolle, zumindest aber drei, führen: 

1. Ein Systemlog zur Protokollierung sämtlicher wichtiger Funktionen des Systems, als da 

wären 

� Systemstart und –Stopp, 

� Einrichtung neuer Administratoren, 

� Einrichtung von Zugängen für KVP- und DL-Verantwortlichen 

� Einrichtung von neuen Kundenvertragspartnern sowie 

� Datentausch mit anderen KA-Systemen. 

2. Ein KVP-Log pro KVP mit der Erfassung von wichtigen Vorgängen wie 

� Anlegen neuer Vertriebsmitarbeiter, 

� Anlegen neuer Kunden und 



� Anlegen neuer Verträge. 

3. Ein DL-Log mit der Protokollierung von wichtigen Ereignissen, wie den folgenden: 

� Datenver- und Entsorgung der Prüfgeräte 

� Datentausch mit dem KOSES 

Dazu sind grundsätzlich Logging-Mechanismen für alle Schnittstellen vorzusehen, welche 

nach der VDV-KA Spezifikation den Datenaustausch zwischen den Systemen regeln (siehe 

dazu [Spec_SST_V1106], Kapitel 4.2.2 und die dazu gehörige Abbildung 13). Das Logging 

muss für jede dieser Schnittstellen separat ein- und ausgeschaltet werden können. 

Die Logging-Funktionen müssen über einen eigenen Web-Dialog gesteuert werden können. 



6.4.4 Kundendaten 

Damit Kunden Berechtigungen erwerben können und die Kundenvertragspartner Leistungen 

abrechnen können, müssen die Daten der Kunden gespeichert und verarbeitet werden können. 

(Dies gilt nicht für den Personalbedienten Einzelverkauf in bar.) 

Folgende Daten müssen unter anderem verarbeitet werden können: 

� OrgID 

� Kundennummer 

� Vorname(n) 

� Name 

� Geburtsname 

� Geschlecht [männlich|weiblich] 

� Geburtsdatum [tt.mm.jjjj] 

� Adresse mit 

o Straße 

o Hausnummer 

o Postleitzahl 

o Ort 

o Staat 

� Telefonnummer 

� Handynummer 

� Fax 

� E-Mail-Adresse 

� Bemerkungen 

� Bankverbindung mit 

o Geldinstitut 

o Bankleitzahl 

o Kontonummer 



o IBAN 

o BIC 

� Bankeinzugsermächtigung erteilt [ja|nein] 

� Ausweisnummer (z.B. Personalausweis) 



6.4.5 Berechtigungsdaten 

Den Kunden sollen mit dem d(((eti-System Berechtigungen verkauft und auf Nutzermedien 

aufgebracht werden. 

Der KVP oder die Vertriebsmitarbeiter legen dabei fest, welche Berechtigungen welchen 

Kunden verkauft werden können. 

Über Produktmodule wird definiert, welche Berechtigungen von welchen KVP angeboten 

werden können. Diese Produktmodule muss das d(((eti-System aufnehmen und speichern 

können. Zudem muss das d(((eti-System die Versionierung der Produktmodule beachten. 

Eine Sonderform der Berechtigung ist das Abonnement. Ein Abonnement muss im Datenbestand 

stets über einen Vertrag mit einem Kunden verknüpft sein. Wenn der Vertrag gekündigt 

wird, muss das d(((eti-System die zugehörige Berechtigung unter Umständen sperren 

können. 

Das System muss dazu Verträge speichern und verwalten können. Insbesondere müssen 

die aus der Verwaltung der Verträge resultierenden Transaktionen mit den Berechtigungen 

durchgeführt werden können, welche sich in den entsprechenden Anwendungsfällen (siehe 

6.2.2.3.2) wieder finden. Die Lebensdauer des Nutzermediums bzw. der zugehörigen Applikation 

muss mit der Laufzeit von Abonnement-Verträgen synchronisiert werden können. 

6.4.6 Chipkarten- / Nutzermediendaten 

Folgende Daten von Nutzermedien müssen unter anderem verwaltet werden: 

� Mediennummer 

� Kennung der auf dem Nutzermedium aufgebrachten VDV-Kernapplikation 

� Gültigkeitsdauer des Mediums 

Die oben genannten Daten müssen auch über die KA-Lieferliste des Nutzermedienherstellers 

in das System eingebracht werden können. Die Spezifikation der KA-Lieferliste ist Bestandteil 

des KA-XML-Schemas. 



6.4.7 Bedienung 

Die Bedienung des d(((eti-Systems kann nach den verschiedenen Klassen von Nutzern unterteilt 

werden. Folgende typische Nutzer können unterschieden werden: 

� Endkunde (Fahrgast) 

� Vertriebspersonal (Personal im Kundencenter, Schaffner, Kontrolleur, Busfahrer) des 

KVP oder eines Vertriebspartners 

� KVP-Verantwortlicher (für den Vertrieb eines KVP (meist eines Verkehrsunternehmens) 

verantwortliche Person) 

� DL-Verantwortlicher (Verantwortlich für die Weiterleitung von Sperr- und Meldungsdaten 

sowie für die Aktualisierung des Datenbestandes der zugehörigen DL-Terminals) 

� Administrator des d(((eti-Servers 

(Siehe dazu auch Kapitel 4.5 und Abbildung 5 Die Hierarchie der d(((eti-Nutzer.) 

Für diese Nutzertypen sind eigene Nutzungsoberflächen zu entwickeln, welche den Nutzern 

lediglich die Funktionen zeigt, die sie tatsächlich ausführen können. Dies kann auch eine 

einzige Nutzungsoberfläche sein, welche bestimmte Bedienelemente je nach Nutzertyp ein- 

bzw. ausblendet. 

Alle Nutzer müssen sich beim d(((eti-Server authentifizieren können, damit sie die ihnen erlaubten 

Bedienhandlungen ausführen können. Die Authentifizierung geschieht über Nutzernamen 

und Kennworte. Alle Nutzer können ihr Kennwort eigenständig ändern. Dazu stellt 

das d(((eti-System einen Dialog bereit. 

Den KVP-Verantwortlichen, dem Vertriebspersonal und den Endkunden muss das d(((eti- 

System als ein eigenständiges System des zugehörigen KVP erscheinen. Daher ist es notwendig, 

das die Adressierung über das WorldWideWeb über eine eigenständige url geschieht. 

(Beispiel: http://www.generichost.de/verkehrsunternehmen1/) Eine gemeinsame 

Oberfläche bei der Anmeldung muss vermieden werden. 

Die gesamte Nutzungsoberfläche wird zwischen Auftragnehmer und Auftraggeber abgestimmt. 



6.4.7.1 Bedienung durch Endkunden 

Endkunden können ihre Daten einsehen. Insbesondere sollen sie ihre Vertragsdaten einsehen 

können. 

Spezielle Daten, welche vom d(((eti-System oder vom Vertriebspersonal verwaltet werden 

(z.B. OrgID, Kundennummer, Personalausweisnummer, Bankeinzugermächtigung) sollen 

vom Kunden nicht geändert und evtl. auch nicht eingesehen werden können. 

Nach Maßgabe des KVP-Verantwortlichen können sie Teile ihrer Daten ändern und Berechtigungen 

auf Nutzermedien schreiben und ändern. 

Endkunden sollen ihre Berechtigungen auch sperren können. 

6.4.7.2 Bedienung durch Vertriebspersonal 

Das Vertriebspersonal bedient das KVP-Terminal. 

Vertriebsmitarbeiter können die Daten von Endkunden einsehen und nach Maßgabe des 

KVP-Verantwortlichen ändern. Sie können Berechtigungen auf Nutzermedien von Endkunden 

schreiben oder sie ändern. 

Zudem können sie eTickets sperren. Insbesondere soll er alle Berechtigungen, welche sich 

auf einem Nutzermedium befinden, in einem Arbeitsschritt sperren können. 

Vertriebsmitarbeiter sollen Kunden im d(((eti-System anlegen und auch wieder löschen können. 

Vertriebsmitarbeiter sollen Nutzermedien personalisieren können. 

Ein Vertriebsmitarbeiter soll Gruppen von Endkunden bilden und alle Operationen, welche er 

auf einzelne Endkunden anwenden kann, auch auf Gruppen anwenden können. 

Vertriebsmitarbeiter sollen durch Berichte über fällige Zahlungen, auslaufende Verträge und 

ähnliche kundenbezogene Daten informiert werden können. 

Vertriebspersonal kann Endkunden den Zugang zum d(((eti-System ermöglichen. 

6.4.7.3 Bedienung durch die KVP-Verantwortlichen 

Der KVP-Verantwortliche bedient den KVP-Server. 

Der KVP-Verantwortliche zeichnet sich dadurch aus, dass er Vertriebsmitarbeitern und Endkunden 

Rechte verleihen und Zugänge zum System verschaffen kann. Er soll festlegen können, 

welche Funktionen Endkunden und Vertriebspersonal ausführen können. 

Der KVP-Verantwortliche legt fest, welche Endkunden welche Berechtigungen kaufen können. 

Zudem legt er fest, welche Vertriebsmitarbeiter welche Produkte verkaufen können. 



Der KVP-Verantwortliche soll Gruppen von Vertriebsmitarbeitern bzw. Endkunden bilden und 

alle Operationen, welche er auf einzelne Vertriebsmitarbeiter und Endkunden anwenden 

kann, auch auf Gruppen anwenden können. 

Der KVP-Verantwortliche kann Endkunden und Vertriebspersonal den Zugang zum d(((eti- 

System ermöglichen. 

Zusätzlich müssen den KVP-Verantwortlichen alle Funktionen zur Verfügung stehen, welche 

für das Vertriebspersonal vorgesehen sind. 

6.4.7.4 Bedienung durch den DL-Verantwortlichen 

Der DL-Verantwortliche bedient den DL-Server. 

Dem DL-Verantwortlichen obliegen alle Einstellungen des Systems, welche den Datentausch 

seines DL-Systems mit den übrigen KA-Systemen betreffen. 

Dem DL-Verantwortlichen stehen Protokolle und Statistiken über Frequenz und Häufigkeit 

des Datenaustausches zur Verfügung, welche die Daten seiner Organisation betreffen. 

Der DL-Verantwortliche kann einen Bericht betreffs aller aktuellen Sperrungen des Kundenbestandes 

seiner Organisation abrufen. 

6.4.7.5 Bedienung durch Administratoren des d(((eti-Servers 

Der Administrator muss das gesamte System verwalten können. 

Der Administrator eines d(((eti-Systems soll KVP- und DL-Verantwortlichen den Zugang zum 

System geben können. Alle Einstellungen und Konfigurationen des Systems sollen vom Administrator 

vorgenommen werden können. 

Zudem muss der Administrator Kundenvertragspartner und Dienstleister (siehe Abbildung 

Abbildung 5 Die Hierarchie der d(((eti-Nutzer) einrichten können, welchen KVP/DL- 

Verantwortliche zugeordnet werden können. 

Eine Instanz des d(((eti-Systems kann über mehrere Administratoren verfügen. Notwendig 

zum Betrieb ist jedoch zumindest ein Administrator. Nutzername und Kennwort des ersten 

Administrators sollen bei der Installation gesetzt werden müssen. 

Jeder Administrator kann Zugänge für andere Administratoren schaffen. 

Jeder Administrator hat Zugriff auf die System-Logdateien. 

Administratoren sollen folgende Eigenschaften des d(((eti-Systems festlegen können: 

� Art und Umfang des Loggings 

� Alle Einzelheiten des Datenaustauschs mit anderen KA-Systemen 

Für diese Einstellungen sind Formulare mit graphischer Nutzungsoberfläche zu entwickeln. 



6.4.8 Hilfetexte in den Programmen 

Alle Funktionen sind in Hilfetexten in den Programmen zu beschreiben. Für alle Nutzertypen 

(s.o.) sind spezifische Hilfstexte zu verfassen und in der Online-Hilfe anzubieten. Die Online- 

Hilfe muss jederzeit in Dialogen und Fenstern der graphischen Nutzungsoberfläche des 

d(((eti-Systems angeboten werden. 

6.4.9 Design 

Das Design ist an den Veröffentlichungen der VDV-KA KG zur Bedienung von personalbedienten 

bzw. kundenbedienten Terminals anzulehnen. 

Im Erscheinungsbild der Benutzerfunktionen ist Raum für ein Logo eines Verkehrsunternehmens 

vorzusehen. Das konkret angezeigte Logo soll leicht austauschbar sein. In der gelieferten 

Version muss das Logo des KCEFM zu sehen sein. 



6.4.10 Installation 

6.4.10.1 Installation des d(((eti-Servers 

Das d(((eti-System soll in zwei Varianten weiter gegeben werden: Als Programmpaket für 

Windows-Rechner und als Live-CD/DVD im Bündel mit einem Linux-Betriebssystem. 

Die Windowsversion muss über einen Installer verfügen, welcher alle Komponenten auf den 

Zielrechner kopiert und dort betriebsbereit einrichtet. 

Die Live-CD/DVD muss das d(((eti-System nach dem Booten starten und betriebsbereit einrichten. 

Die Live-CD/DVD muss die Installation des Linux-Systems mit betriebsbereitem 

d(((eti-System erlauben. 

6.4.10.2 Installation der Client-Software 

Neben dem Treiber für das Schreib-/Lesegerät muss auf einem Client-Rechner die Clientsoftware 

installiert sein. 

Für Windows-Clients muss eine Installationsroutine entwickelt werden, welche die Software 

installiert. 

Für die Linux-Distributionen Debian und Fedora muss ein entsprechendes Paket erstellt werden. 

In beiden Versionen müssen alle Open Source Treiber für Schreib-/Lesegeräte mit installiert 

werden. 



7 Dokumentation 

7.1 Allgemeines 

Der Dokumentation kommt im d(((eti-Projekt eine besondere Rolle zu. Um dem geplanten 

Zweck zu entsprechen, muss d(((eti über eine besonders gute Nutzungsanleitung verfügen. 

Die Nutzungs-, Installations- und Konfigurationsanleitungen sind in Form einer Sammlung 

von HTML-Texten zu liefern. Bei der Gestaltung ist ein Schwerpunkt auf die Erzeugung guter 

Ausdrucke zu legen. 

Die Nutzerhandbücher sind mit beispielhaften Screenshots zu illustrieren, wenn der Dialog 

mit der d(((eti-Software beschrieben wird. Bei Web-Frontends ist exemplarisch ein aktueller 

Internet-Explorer unter Windows XP oder Vista abzubilden. 

Die Absicht, möglichst viele Interessenten zur Abwandlung und Weiterentwicklung 

anzuregen, macht eine gute und ausführliche Dokumentation der Quelltexte und der 

Funktionsweise des Systems notwendig. 

Der entstehende Sourcecode wird mittels HTML-Texten dokumentiert. Vorbild ist die 

Dokumentation, wie sie mit dem javadoc-Programm halbautomatisch aus Java-Quelltexten 

erzeugt werden kann. (Siehe Dokumentation der Java-API z.B. unter 

http://java.sun.com/javase/6/docs/api/index.html ) 

7.2 Dokumentation d(((eti-API 

Alle Objekte und Funktionen, welche der Entwicklung von Applikationen der d(((eti-API dienen, 

sind in einer Sammlung von HTML-Texten zu dokumentieren. 

Für Java-Klassen und Methoden muss auf Javadoc zurückgegriffen werden. 

Die Unterschiede zwischen Windows- und Linux-Version sind in gesonderten Abschnitten zu 

beschreiben. 

7.3 Dokumentation d(((eti-eTicket-Viewer 

Der d(((eti-eTicket-Viewer benötigt wegen seiner auf IT-Laien ausgerichteten Funktionalität 

ein besonders gutes Benutzungshandbuch. Insbesondere die Installation, die Auswahl des 

Schreib-/Leser-Treibers bzw. Gerätes ist ausführlich und leicht nachvollziehbar zu beschreiben. 



7.4 Dokumentation d(((eti-System 

Das d(((eti-System wird von mehreren Klassen von Nutzern benutzt werden: IT-Administratoren, 

KVP-Verantwortliche, DL-Verantwortliche, Vertriebsmitarbeiter und Endkunden. Nicht alle 

Arten dieser Nutzer müssen auf alle Teile der d(((eti-System-Dokumentation zurückgreifen. 

Die Besonderheiten der Versionen für die verschiedenen Betriebssysteme sind ausführlich 

zu schildern. 

7.4.1 Installationsanleitung d(((eti-System 

In der Installationsanleitung ist beschrieben, wie das d(((eti-System auf einem Rechner installiert 

werden kann. 

Dabei ist besonderes Gewicht auf Schilderung der Voraussetzungen des Rechners zu legen. 

Die Beschreibung der Installation muss auch für IT-Laien verständlich sein. 

7.4.2 Administrationshandbuch 

Im Administrationshandbuch wird beschrieben, welcher Bedienhandlungen ein installiertes 

d(((eti-System bedarf um problemlos zu laufen. 

Themen sind u.a.: 

� Vorbedingungen bzw. Anforderungen an die Systemumgebung 

� Start, Herunterfahren sowie Konfiguration des d(((eti-Servers 

� Backup der d(((eti-Daten 

� Beschreibung sämtlicher Konfigurationsdateien 

� Einrichtung von Mandanten / KVP und KVP-Verantwortlichen 

� Einrichtung von Mandanten / DL und DL-Verantwortlichen 

� Fehlerbehebung 



7.4.3 Handbuch für KVP-Verantwortliche 

Das Nutzerhandbuch für KVP-Verantwortliche erklärt alle Bedienhandlungen, welche ein 

KVP-Verantwortlicher vornehmen kann. Dies gilt nicht für diejenigen Bedienhandlungen, 

welche auch ein Vertriebsmitarbeiter ausführen kann. 

Ein besonderer Schwerpunkt soll die Einrichtung von Zugängen für Vertriebsmitarbeiter sein. 

7.4.4 Handbuch für DL-Verantwortliche 

Das Nutzerhandbuch für den DL-Verantwortlichen erklärt alle Bedienhandlungen, welche ein 

DL-Verantwortlicher vornehmen kann. 

7.4.5 Handbuch für Vertriebsmitarbeiter 

Das Nutzerhandbuch für Vertriebsmitarbeiter erklärt alle Bedienhandlungen, welche ein Vertriebsmitarbeiter 

vornehmen kann. Dies gilt nicht für diejenigen Bedienhandlungen, welche 

auch ein Endkunde ausführen kann. 

Ein besonderer Schwerpunkt soll die Einrichtung von Zugängen für Endkunden sein. 

7.4.6 Handbuch für Endkunden 

Das Handbuch für Endkunden beschreibt alle für die Nutzung durch den Endkunden vorgesehenen 

Funktionen des d(((eti-Systems. 

Zudem wird in ausführlich erklärt, was ein Endkunde tun muss, um seinen heimischen Rechner 

zum Download von eTickets zu ertüchtigen. Dazu gehört insbesondere die ausführliche 

Beschreibung des Downloads, der Installation und der Inbetriebnahme der eTicket-Client- 

Software. 



8 Lieferumfang 

Folgende Gegenstände sind zu liefern: 

2 Datenträger (CD oder DVD) d(((eti-System Linux (bootbar) mit Source Code und elektronischer 

Dokumentation 

2 Datenträger (CD oder DVD) d(((eti-System Windows mit Source Code und elektronischer 

Dokumentation 

2 Dokumentation d(((eti-System in Papierform (Ausdruck der elektronischen Dokumentation) 

2 Datenträger (CD oder DVD) d(((eti-eTicket-Viewer Windows mit Source Code und elektronischer 

Dokumentation 

2 Datenträger (CD oder DVD) d(((eti-eTicket-Viewer Linux mit Source Code und elektronischer 

Dokumentation 

2 Dokumentation d(((eti-eTicket-Viewer in Papierform (Ausdruck der elektronischen Dokumentation) 

2 Datenträger (CD oder DVD) d(((eti-API Windows & Linux mit Source Code und elektronischer 

Dokumentation 

2 Dokumentation d(((eti-API in Papierform (Ausdruck der elektronischen Dokumentation) 

Alle Datenträger sind in geeigneten Schutzhüllen zu liefern. Die Dokumentation sollte in Aktenordnern 

oder Ringbüchern geliefert werden. Das Format sollte DIN A4 nicht überschreiten. 



9 Literatur 

Kürzel Titel Herausgeber 

[KA_Glossar_V1106] VDV-Kernapplikation Glossar VDV KA KG 

[Spec_HD_BOM_V1106] KA_Technische Spezifikation, Hauptdokument mit 

Basisobjektmodell (BOM) – Version 1.106 

[Spec_MT ServerProt_V1106] Erweiterung Mobiles Ticketing, Applikation und 

Übertragungsprotokoll 

[Spec_MT_V1106] Erweiterung Mobiles Ticketing, Kernapplikation als 

Mobile Ticketing Applikation 


VDV KA KG 

VDV KA KG 

VDV KA KG 

[Spec_NM_V1106] VDV-Kernapplikation Spezifikation Nutzermedium VDV KA KG 

[Spec_PE_V1106] Beschreibung der Schnittstellen zwischen der Vertriebseinheit 

(KVP-VE) und der Personalisierungseinheit 

(KVP-PE) eines KVP-Terminals 

VDV KA KG 

[Spec_SAM_V1106] VDV-Kernapplikation Spezifikation des SAM VDV KA KG 

[Spec_SEC_V1106] VDV-Kernapplikation Technisches Konzept Sicherheit 

[Spec_SST_V1106] Schnittstellenspezifikationen der Referenzsysteme 

Kundenvertragspartner (KVP), Dienstleister (DL), 

Produktverantwortlicher (PV), Applikationsherausgeber 

(AH), Kon-trollservice (KOSE) 

[SYSLH_AHS_V1106] Systemlastenheft, Teil: Applikationsherausgeber - 

System (AHS) 

VDV KA KG 

VDV KA KG 

VDV KA KG 

[SYSLH_DLS_V1106] Systemlastenheft, Teil: Dienstleister-System (DLS) VDV KA KG 

[SYSLH_HD_Anlage_V1106] Anhang zum Hauptdokument, Systemlastenheft, 

Nutzung des Kundendatenspeichers - Vorläufige 

Verfahrensfestlegung 

VDV KA KG 

[SYSLH_HD_V1106] Systemlastenheft Hauptdokument VDV KA KG 

[SYSLH_KOSES_V1106] Systemlastenheft, Teil: Kontrollservice-System 

(KOSES) 

[SYSLH_KVPS_V1106] Systemlastenheft, Teil: Kundenvertragspartner- 

System 

[SYSLH_PbRTKVP_V1106] Systemlastenheft, Teil: Personalbediente KVP- 

ReferenzTerminals 

[SYSLH_PVS_V1106] Systemlastenheft, Teil: Produktverantwortlichen- 

System (PVS) 

VDV KA KG 

VDV KA KG 

VDV KA KG


[SYSLH_RTDL_V1106] Systemlastenheft, Teil: Referenzterminal DL VDV KA KG 

[SYSLH_SbRTKVP_V1106] Systemlastenheft, Teil: Selbstbediente KVP- 

Referenzterminals 

[Anlage 

DSzuHD_SPEC_V1106] 


Anlage zum Hauptdokument der Spezifikationen 

zur VDV-Kernapplikation – Rahmenrichtlinie Elektronisches 

Fahrgeldmanagement (EFM) – Datenschutzrechtliche 

Grundanforderungen 

[SPEC_KUSCH_V1106] Einheitliche Kundenschnittstelle für ein mehrstufiges 

interoperables elektronisches Fahrgeldmanagement 

[NRW_KA_EFS] Aufbau des NRW-KA-EFS und Konvertierungsregeln 

VDV KA KG 

VDV KA KG 

VDV KA KG 

KCEFM

Leistungsbeschreibung (PDF, 629 kB) - KCEFM

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?