E Anlage 27a EFM Teilnvertrag (((eTicketDeutschl_mAnl_Muster_Stand 170801_MVU.pdf

[Seite 1]

Anlage 27

(((eTicket Deutschland

(((eTicket-Teilnahmevertrag

Vertrag über die Teilnahme am (((eTicket-Deutschland

zwischen

VDV eTicket Service GmbH & Co. KG Im Mediapark 8a 50670 Köln

• nachstehend „VDV-ETS“ genannt -

und

• nachstehend „Teilnehmer“ genannt -

Vertragsnummer: _____

Seite 1 von 8

[Seite 2]

Anlage 27

(((eTicket Deutschland

Stand: 01.08.2017

Seite 2 von 8

[Seite 3]

Anlage 27

(((eTicket Deutschland

Präambel

1. Auf Initiative des Verbandes deutscher Verkehrsunternehmen (VDV) wurde gemeinsam mit Verkehrsunternehmen und der Industrie die VDV-Kernapplikation entwickelt und in die VDV-Kernapplikations Verwaltungsgesellschaft mbH eingebracht. Die Umsetzung des (((eTicket-Deutschland durch die VDV-eTicket Service GmbH & Co. KG und die Verkehrsunternehmen und Verbünde soll die Fahrgäste im ÖPV in die Lage versetzen, unter Nutzung nur noch eines einzigen elektronischen Nutzermediums (z.B. einer Chipkarte oder eines Mobiltelefons), bundesweit Beförderungsleistungen im ÖPV bargeldlos bezahlen und Fahrberechtigungen für die Nutzung des ÖPV erwerben zu können. Durch die Wahrung der Interoperabilität sind die von unterschiedlichen Verkehrsunternehmen und –verbünden herausgegebenen Nutzermedien in allen teilnehmenden (((eTicket- Deutschland-Regionen nutzbar. Das (((eTicket-Deutschland überwindet Grenzen zwischen Tarifen und Verkehrsunternehmen bzw. –verbünden. Damit wird dem Fahrgast der Zugang zum ÖPV erleichtert und die Nutzung öffentlicher Verkehrsmittel insgesamt attraktiver und einfacher gestaltet.

2. Technische und organisatorische Basis des (((eTicket-Deutschland ist die VDV- Kernapplikation, die den technischen Daten- und Schnittstellenstandard bildet und damit die Voraussetzung für das interoperable Zusammenwirken der jeweiligen (((eTicket-Systeme der Teilnehmer ist. Wesentlicher Bestandteil des (((eTicket- Deutschland ist das Rollenmodell der VDV-Kernapplikation.

3. Der Teilnehmer möchte am (((eTicket-Deutschland teilnehmen und wird im Rahmen des Rollenmodells die in § 1 dieses (((eTicket-Teilnahmevertrages (nachfolgend auch „TNV“) gekennzeichnete(n) Rolle(n) einnehmen.

4. Die in diesem (((eTicket-Teilnahmevertrag verwendeten Begriffe und Abkürzungen sind in der jeweils gültigen Fassung des Glossars in Kapitel 1 des (((eTicket- Regelwerks definiert.

§ 1 Vertragsgegenstand

1. Der Teilnehmer wird in den nachfolgend gekennzeichnete(n) Rolle(n) am (((eTicket- Deutschland teilnehmen (Mehrfachnennungen sind möglich):

 Produktverantwortlicher

 Dienstleister

 Kundenvertragspartner

2. Der Teilnehmer beabsichtigt grundsätzlich, die gemäß § 1 Abs. 3 gewählte(n) Ausbauvariante(n) vollständig umzusetzen. Die Ausbauvarianten sind in KA KUSCH- SPEC (vgl. Kapitel 3 Ziffer 10 des (((eTicket-Regelwerks) beschrieben. Vollständige Umsetzung im Sinne des Satzes 1 bedeutet den Einsatz der Ausbauvariante(n) im

Seite 3 von 8

[Seite 4]

Anlage 27

(((eTicket Deutschland

Wirkbetrieb bei Umsetzung sämtlicher der jeweils pro Ausbauvariante seitens des Standards geforderten Anwendungsfälle und Elementarprozesse. Die Ausgabe des gesamten Tarifangebotes als elektronischer Fahrschein und das Angebot elektronischer Fahrscheine über sämtliche Vertriebskanäle sind keine notwendige Voraussetzung für eine vollständige Umsetzung.

3. Der Teilnehmer beabsichtigt, folgende Ausbauvariante(n) umzusetzen:

 (((eBezahlen (Ausbauvariante 1)

 (((eFahrschein mit (((eKontrolle (Ausbauvariante 2)

 Automatisierte Fahrpreisermittlung (Ausbauvariante 3)

4. Für die Teilnahme am (((eTicket-Deutschland gilt das als Anlage zu diesem (((eTicket-Teilnahmevertrag beigefügte (((eTicket-Regelwerk in seiner jeweils gültigen Fassung. Die VDV-ETS und der Teilnehmer verpflichten sich zur Einhaltung der in dem (((eTicket-Regelwerk enthaltenen Anforderungen. Soweit in dem (((eTicket- Regelwerk auf andere Dokumente verwiesen wird (insbesondere in Kapitel 3), sind auch diese Dokumente in ihrer jeweils gültigen Fassung Bestandteil des (((eTicket- Regelwerks und damit auch Bestandteil dieses (((eTicket-Teilnahmevertrages. Bei Widersprüchen zwischen den Regelungen dieses (((eTicket-Teilnahmevertrages und den Regelungen des (((eTicket-Regelwerks gehen die Regelungen dieses (((eTicket- Teilnahmevertrages vor.

5. Mit dem Abschluss dieses (((eTicket-Teilnahmevertrages erhält der Teilnehmer das Recht zum Bezug von Leistungen des Sicherheitsmanagementdienstleisters im Hinblick auf das Sicherheitsmanagement (vgl. (((eTicket-Regelwerk, Kapitel 2, § 4 Abs. 4). Die VDV-ETS verpflichtet sich, für den gesamten Vertragszeitraum die Erfüllung der Aufgabe des zentralen Sicherheitsmanagements durch einen von Ihr ausgewählten und beauftragten Sicherheitsmanagementdienstleister zu gewährleisten.

6. Das Angebot bzw. die Nutzung von alternativen Fahrscheinprodukten (Papierfahrscheinen, Handytickets, etc.) bleibt von der Teilnahme am (((eTicket- Deutschland unberührt.

7. Der Teilnehmer beantragt mit Unterzeichnung dieses Vertrags die Zuteilung einer Org-ID (Identifikationsnummer), sofern diese ihm nicht bereits erteilt wurde.

Ansprechpartner bei dem Verwender im Zusammenhang mit der Org-ID sind:

1.Ansprechpartner

Name, Vorname: ________________________________________

Telefon: ________________________________________

E-Mail-Adresse: ________________________________________

Seite 4 von 8

[Seite 5]

Anlage 27

(((eTicket Deutschland

2.Ansprechpartner

Name, Vorname: ________________________________________

Telefon: ________________________________________

E-Mail-Adresse: ________________________________________

Änderungen bezüglich Namen des Unternehmens, Adresse und Ansprechpartner sind der VDV-ETS unverzüglich und unaufgefordert mitzuteilen. Dies gilt auch für den Fall, wenn das Unternehmen aufgelöst wird.

§ 2 Dauer des (((eTicket-Teilnahmevertrages / Kündigung

1. Dieser (((eTicket-Teilnahmevertrag wird zunächst für die Dauer von 24 Monaten geschlossen. Soweit der (((eTicket-Teilnahmevertrag nicht von dem Teilnehmer mit einer Frist von drei Monaten zum Ablauf der ersten Laufzeit nach Satz 1 gekündigt wird, verlängert er sich auf unbestimmte Zeit und kann anschließend von dem Teilnehmer mit einer Frist von drei Monaten zum Ende eines Kalenderjahres gekündigt werden. Ein ordentliches Kündigungsrecht der VDV-ETS gegenüber dem Teilnehmer ist ausgeschlossen. Die Kündigung bedarf der Schriftform unter Ausschluss der telekommunikativen Übermittlung.

2. Der (((eTicket-Teilnahmevertrag endet grundsätzlich, wenn der Teilnehmer nicht mehr Partei des Clearingvertrages ist.1 Die Parteien vereinbaren, sich gegenseitig rechtzeitig über Ihre Bestrebungen und evtl. vorgesehenen Maßnahmen zu informieren, um einvernehmliche Lösungsmöglichkeiten unter Berücksichtigung der beiderseitigen Interessen finden zu können.

3. Darüber hinaus bleibt das Recht der Parteien zur außerordentlichen Kündigung des (((eTicket-Teilnahmevertrages aus wichtigem Grund unberührt. Ein wichtiger Grund, der die VDV-ETS zu einer außerordentlichen Kündigung des (((eTicket- Teilnahmevertrages aus wichtigem Grund berechtigt, ist insbesondere jede wiederholte, nicht nur unerhebliche Verletzung der dem Teilnehmer nach dem (((eTicket-Teilnahmevertrag obliegenden Pflichten. Eine solche Pflichtverletzung liegt insbesondere vor, sobald sie geeignet ist, Schäden bei anderen Teilnehmern hervorzurufen oder die Systemintegrität zu beeinflussen. Ein wichtiger Grund für den Teilnehmer liegt insbesondere vor, wenn ein Verkehrsverbund, in dem der Teilnehmer beteiligt ist den Austritt aus dem (((eTicket-Deutschland beschlossen hat. Insofern ist es dem Teilnehmer auch möglich, eine Teilkündigung in Bezug auf einzelne Tarifgebiete auszusprechen.

4. Die in dem (((eTicket-Regelwerk enthaltenen Kündigungsrechte der Parteien bleiben unberührt.

1 Diese Regelung tritt erst in Kraft, sobald der Teilnehmer dem Clearingvertrag beigetreten ist.

Seite 5 von 8

[Seite 6]

Anlage 27

(((eTicket Deutschland

5. Jeder außerordentlichen Kündigung in Folge von Pflichtverletzungen einer der Parteien hat eine schriftliche Abmahnung, in der das vertragswidrige Verhalten benannt ist, vorauszugehen. Die Kündigung bedarf der Schriftform unter Ausschluss der telekommunikativen Übermittlung.

6. Nach Kündigung des (((eTicket-Teilnahmevertrags ist dem Teilnehmer die reine Nutzung des Standards, bzw. von Teilen des Standards grundsätzlich weiterhin möglich. Dies erfolgt jedoch zu dann zu verhandelnden und entsprechend geänderten kaufmännischen Bedingungen, sofern der Teilnehmer nicht mehr die Public-Key- Infrastruktur (PKI) des Sicherheitsmanagementdienstleisters nutzt. Der nicht interoperable Weiterbetrieb darf zudem nicht mehr unter Nutzung der Marken und Geschmacksmuster des (((eTicket-Deutschland (i.S.d. (((eTicket-Regelwerks Kap. 4, § 1) stattfinden. Die VDV-ETS wird die technische Unterstützung weiterhin gewährleisten. Sofern der VDV-ETS im Rahmen der Umstellung, bzw. im Rahmen des nicht interoperablen Weiterbetriebs ohne Weiternutzung der PKI Kosten entstehen, sind diese vom ausscheidenden Teilnehmer zu tragen. Diese Kosten sind dem Teilnehmer jederzeit auf Anfrage verbindlich durch die VDV-ETS mitzuteilen.

§ 32 Beitritt zum Clearingvertrag

1. Der Teilnehmer erklärt seine Absicht, zum Zeitpunkt der Aufnahme des interoperablen Betriebs dem Clearingvertrag beitreten zu wollen. Die VDV-ETS wurde von den übrigen Teilnehmern bevollmächtigt, in deren Namen Beitrittserklärungen von künftigen Teilnehmern entgegenzunehmen und gegenüber diesen Teilnehmern die rechtsverbindliche Annahme der Beitrittserklärungen abzugeben.

2. Durch den Beitritt zum Clearingvertrag wird der Teilnehmer nicht gehindert, mit einzelnen oder allen übrigen Teilnehmern Vereinbarungen zu treffen, die von den Regelungen des Clearingvertrages abweichen und in deren Verhältnis dann vorrangig gelten. In diesem Fall entfaltet der Clearingvertrag keine Rechte und Pflichten für den Teilnehmer.

§ 4 Abweichungen von den Regelungen des (((eTicket-Teilnahmevertrags und des (((eTicket-Regelwerks während des Migrationszeitraums

Zur Erreichung der Interoperabilität verfolgen der Teilnehmer und die VDV-ETS das Ziel, dass in jeder Ausbauvariante eine (((eBezahlberechtigung an jeden Kunden ausgegeben wird, die jedem Kunden den Erwerb von Fahrscheinen bei Teilnehmern mit den Ausbauvarianten „(((eBezahlen“ und „(((eFahrschein mit (((eKontrolle“ und die Inanspruchnahme von Beförderungsleistungen bei Teilnehmern mit der Ausbauvariante „Automatisierte Fahrpreisermittlung“ ermöglicht.

2 § 3 gilt nur für Teilnehmer, die den (((eTicket-Teilnahmevertrag abschließen, nachdem der nach Maßgabe von Kapitel 7, Ziffer 3 des (((eTicket-Regelwerks verabschiedete Clearingvertrag vorliegt.

Seite 6 von 8

[Seite 7]

Anlage 27

(((eTicket Deutschland

Die Parteien vereinbaren nachfolgende Abweichungen von den Regelungen des (((eTicket- Teilnahmevertrags und den (((eTicket-Teilnahmebedingungen (Kapitel 2 des (((eTicket- Regelwerks):

1. § 3 Abs. 3 h) und l) und § 3 Nr. 4 k) der (((eTicket-Teilnahmebedingungen findet erst Anwendung, wenn der Teilnehmer dem Clearingvertrag beigetreten ist.

§ 5 Nutzung des KOSE und der zentralen Vermittlungsstelle (ZVM)

1. Die Nutzung des Sperrlistenservices (KOSE) und der zentralen Vermittlungsstelle ist für den Teilnehmer kostenlos. Dies gilt für die Dauer der Vertragslaufzeit des mit dem derzeitigen Dienstleister geschlossenen Werk- und Betriebsvertrages vom 20.07.2010 (Anlage 8 zum (((eTicket-Regelwerk, siehe dort § 26). Sollten sich die kommerziellen Bedingungen in einem etwaigen Folgevertrag nach Kündigung für die VDV-ETS in nicht unerheblichem Maße nachteilig entwickeln, werden sich der Teilnehmer und die VDV-ETS um eine einvernehmliche Lösung bzgl. einer interessensgerechten Kostenbeteiligung bemühen, deren Realisierung auf Wunsch des Teilnehmers erst mit einem Jahr Verzögerung einsetzen kann. Eine Kündigung des Werk- und Betriebsvertrags durch die VDV-ETS darf erst nach Zustimmung der Gesellschafterversammlung erfolgen. Änderungen des Werk- und Betriebsvertrags bedürfen der Zustimmung der Teilnehmerversammlung.

2. Die VDV-ETS wird im Bedarfsfall sämtliche ihr gegen den KOSE-Dienstleister zustehenden Gewährleistungs- und Schadensersatzansprüche an den betroffenen Teilnehmer abtreten und den Teilnehmer bei der Verfolgung seiner Rechte unterstützen. Die VDV-ETS haftet nach der Maßgabe des Werk- und Betriebsvertrages anstelle des KOSE-Dienstleisters, soweit dieser aufgrund von Insolvenz vollständig oder teilweise mit der Erfüllung der Gewährleistungs- und Schadensersatzansprüche gegenüber dem Teilnehmer ausfällt.

3. Der Teilnehmer ist darüber unterrichtet, dass die Herstellung der Schnittstelle zum KOSE, bzw. zur zentralen Vermittlungsstelle im eigenen Hintergrundsystem auf eigene Kosten zu erfolgen hat. Hierzu wird die VDV-ETS beim KOSE-Dienstleister darauf hinwirken, dass dieser eine vereinfachte, standardisierte Lösung zur Anschlusserleichterung zur Verfügung stellen wird. Des Weiteren wird die VDV-ETS sicherstellen, dass der von ihr beauftragte Anbieter des KOSE eine Service-Hotline für alle laufenden und projektbezogenen Abstimmungen und Tests mit dem Anbieter des Hintergrundsystems des jeweiligen Teilnehmers anbietet.

§ 6 Schlussbestimmungen

1. Erfüllungsort ist Köln. Ausschließlicher Gerichtsstand für alle Streitigkeiten, die aus diesem (((eTicket-Teilnahmevertrag resultieren, ist Köln.

2. Dieser (((eTicket-Teilnahmevertrag unterliegt deutschem Recht.

Seite 7 von 8

[Seite 8]

Anlage 27

(((eTicket Deutschland

3. Soweit in dem (((eTicket-Regelwerk nichts anderes geregelt ist, bedürfen Änderungen oder Ergänzungen dieses (((eTicket-Teilnahmevertrages sowie dessen Aufhebung zu ihrer Wirksamkeit der Schriftform (keine elektronische Form, telekommunikative Übermittlung nur per Telefax). Gleiches gilt für die Aufhebung des Schriftformerfordernisses.

4. Sollten in diesem (((eTicket-Teilnahmevertrag einzelne Bestimmungen rechtsunwirksam sein oder werden, so sind die Vertragsparteien darüber einig, dass dadurch die Gültigkeit der übrigen Bestimmungen nicht beeinträchtigt werden soll. Die unwirksame Bestimmung ist durch eine rechtswirksame Regelung zu ersetzen, die dem wirtschaftlichen Zweck der unwirksamen Bestimmung am nächsten kommt. Dasselbe gilt, wenn bei Durchführung dieses (((eTicket-Teilnahmevertrages eine ergänzungsbedürftige Regelungslücke offenbar wird.

§ 7 Vertragsbestandteile

1. Folgende Anlagen werden Bestandteile dieses Teilnahmevertrages:

Anlage 1: (((eTicket-Regelwerk Anlage 2: Migrationsszenarien in den Ausbauvarianten des (((eTicket Deutschland Anlage 3: Muster-Kundenverträge nebst Allgemeinen Geschäftsbedingungen Anlage 4: Muster Datenschutz-Hinweise Anlage 5: Geschäftsordnung für die Teilnehmerversammlung Anlage 6: Geschäftsordnung für die AG Standardisierung

2. Bei Widersprüchen zwischen den Bestimmungen dieses Teilnahmevertrages und den Bestandteilen (Anlagen) gehen die Bedingungen dieses Teilnahmevertrages vor; die Bestandteile gelten bei Widersprüchen unabhängig von der Anlagennummerierung in der angegebenen Reihenfolge.

______________, den Köln, den

Teilnehmer VDV eTicket Service GmbH & Co. KG

Jozef A.L. Janssen, Geschäftsführer

Seite 8 von 8

[Seite 9]

Anlage 27 VDV-KERNAPPLIKATION

(((eTicket-Regelwerk

zur Teilnahme am (((eTicket-Deutschland

auf Basis der VDV-Kernapplikation

Anlage 1 zum

(((eTicket-Teilnahmevertrag

V 1.27 Stand: 16.05.2018

VDV eTicket Service GmbH & Co. KG

[Seite 10]

Anlage 27

(((eTicket Deutschland

Versionsverwaltung

II

[Seite 11]

Anlage 27

(((eTicket Deutschland

III

[Seite 12]

Anlage 27

(((eTicket Deutschland

Inhaltsverzeichnis

Kapitel 1: Glossar ................................................................................................... 6

Kapitel 2: (((eTicket-Teilnahmebedingungen ......................................................13 § 1 Gegenstand der (((eTicket-Teilnahmebedingungen ..........................................13 § 2 Verantwortungsbereich der VDV-ETS ...............................................................13 § 3 Pflichten der Teilnehmer ....................................................................................14 § 4 Technische Anforderungen an die von den Teilnehmern verwendeten (((eTicket-Systemkomponenten ..........................................................................17 § 5 Beauftragung mit Leistungen des KOSE; Pflichten der Teilnehmer im Zusammenhang mit der Erfüllung der Systemintegrität ......................................20 § 6 Änderungen der technischen Anforderungen und der Pflichten im Zusammenhang mit der Erhaltung der Systemintegrität .....................................21 § 7 Einräumung von Nutzungsrechten an (((eTicket-Zeichen .................................23 § 8 Informationspflichten, Kontroll- und Betretungsrechte .......................................24 § 9 Teilnahmebeitrag ...............................................................................................25 § 10 Gewährleistung ................................................................................................25 § 11 Haftung ............................................................................................................25 § 12 Änderungen des (((eTicket-Regelwerks einschließlich der VDV-KA- Dokumentation ....................................................................................................26

Kapitel 3: VDV-KA-Dokumentation ......................................................................27

Kapitel 4: Markenbuch ..........................................................................................31 Präambel .................................................................................................................31 § 1 Definition ...........................................................................................................31 § 2 Anwendungsbereich ..........................................................................................33 § 3 Allgemeine Anforderungen an die Nutzung der (((eTicket-Zeichen ...................33 § 4 Nutzung im Zusammenhang mit Wort- oder Bildbezeichnungen .......................34 § 5 Nutzung im Zusammenhang mit anderen Bezahlvarianten ...............................34

Kapitel 5: Beschreibung des Sperrsystems ........................................................35 Präambel .................................................................................................................35 § 1 Organisation des Sperrsystems.........................................................................35 IV

[Seite 13]

Anlage 27

(((eTicket Deutschland

§ 2 Sperrobjekte ......................................................................................................35 § 3 Sperrnachrichten ...............................................................................................36 § 4 Sperrprozesse ...................................................................................................37 § 5 Entsperrprozesse ..............................................................................................42 § 6 Sperrfreigabeprozesse ......................................................................................44 § 7 Sperrgründe ......................................................................................................46 § 8 Konfigurationsprozesse .....................................................................................47

Kapitel 6: Datenschutz-Grundsätze .....................................................................49

Kapitel 7: Clearingvertrag .....................................................................................51

Kapitel 8: KOSE-Vertrag .......................................................................................53

Kapitel 9: Release Management .......................................................................... 83

V

[Seite 14]

Anlage 27

(((eTicket Deutschland

Kapitel 1: Glossar

6

[Seite 15]

Anlage 27

(((eTicket Deutschland

1 Dieser Begriff wird nur im vertraglichen Innenverhältnis verwendet. Im Außenverhältnis gegenüber dem Kunden ist weiterhin der gem. KUSCH-Spec, Kap. 1.5, vorgesehene Begriff „(((eTicket“ zu verwenden.

2 Gilt auch bei der Inanspruchnahme einer eBezahlberechtigung für den Erwerb von Papierfahrscheinen (Variante (((eBezahlen) 7

[Seite 16]

Anlage 27

(((eTicket Deutschland

8

[Seite 17]

Anlage 27

(((eTicket Deutschland

9

[Seite 18]

Anlage 27

(((eTicket Deutschland

10

[Seite 19]

Anlage 27

(((eTicket Deutschland

11

[Seite 20]

Anlage 27

(((eTicket Deutschland

12

[Seite 21]

Anlage 27

(((eTicket Deutschland

Kapitel 2: (((eTicket-Teilnahmebedingungen

§ 1 Gegenstand der (((eTicket-Teilnahmebedingungen

1. Gegenstand dieser (((eTicket-Teilnahmebedingungen ist die Festlegung der Rechte und Pflichten, die sich für die Teilnehmer aus ihrer Teilnahme am (((eTicket- Deutschland ergeben.

2. Durch die Teilnahme am (((eTicket-Deutschland wird kein gesellschaftsrechtliches Verhältnis und hieraus entstehende Rechte und Pflichten begründet, weder zwischen den Teilnehmern untereinander noch zwischen den Teilnehmern und der VDV eTi- cket Service GmbH & Co. KG (VDV-ETS).

3. Die VDV-ETS kann auch andere Unternehmen zur Teilnahme am (((eTicket- Deutschland zulassen. Alle weiteren Unternehmen dürfen nur zu Bedingungen auf- genommen werden, die für alle Teilnehmer gleichermaßen gelten. Ausgenommen hiervon sind befristete Migrationsvereinbarungen.

4. Die Teilnehmer können im Rahmen des (((eTicket-Deutschland durch Vereinbarung im (((e-Ticket-Teilnahmevertrag entscheiden, welche Rollen im Rollenmodell sie ein- nehmen möchten. Möglich sind die Übernahme der Rollen PV, KVP und/oder DL. Ein Teilnehmer kann auch mehrere Rollen gleichzeitig übernehmen.

5. Durch die Teilnahme am (((eTicket-Deutschland erwerben die Teilnehmer weder (((eTicket-Systemkomponenten noch Rechte oder Lizenzen daran. Soweit dies zur Erfüllung ihrer vertraglichen Pflichten gegenüber der VDV-ETS, gegenüber anderen Teilnehmern, gegenüber den Nutzern oder gegenüber den Kunden erforderlich ist, haben sich die Teilnehmer erforderliche (((eTicket-Systemkomponenten bzw. Rechte oder Lizenzen daran zu beschaffen.

6. Der Teilnehmer ist berechtigt, neben den Komponenten des (((eTicket-Deutschland auch den VDV-Barcode gem. VDV-Mitteilung 9718 („Empfehlungen zur Anwendung des VDV-Barcode-Standards“), bzw. der Spezifikation Statischer Berechtigungen (KA STB-Spec) einzusetzen und zu nutzen. Die in diesem Regelwerk enthaltenen Rege- lungen gelten, sofern der Teilnehmer den VDV-Barcode einsetzt und die Regelungen nicht (((eTicket-spezifisch sind, analog auch für die Anwendung des VDV-Barcodes.

§ 2 Verantwortungsbereich der VDV-ETS

1. Der Verantwortungsbereich der VDV-ETS umfasst die in Ziff. 4.6 des Dokuments „KA_Technische Spezifikation Hauptdokument mit Basisobjektmodell (KA BOM- SPEC)“ (siehe Kapitel 3, Ziffer 2 des (((eTicket-Regelwerks) aufgeführten Tätigkeiten. Die VDV-ETS wird die in ihrem Verantwortungsbereich liegenden Tätigkeiten unter Berücksichtigung der berechtigten Interessen aller Teilnehmer ausüben.

2. Darüber hinaus ist die VDV-ETS verpflichtet, eine über das Internet unter http://www.eticket-deutschland.de oder unter einer anderen, den Teilnehmern jeweils mitzuteilenden Internet-Adresse einsehbare, zentrale, aktuelle Informationsdatenbank vorzuhalten, die folgende Informationen enthält:

13

[Seite 22]

Anlage 27

(((eTicket Deutschland

 Informationen zu Stand und Entwicklung der von den Teilnehmern umgesetzten oder zur Umsetzung beabsichtigten Ausbauvarianten;

 Liste der Teilnehmer mit der/den von diesen übernommene(n) Rolle(n) im Rol- lenmodell;

 Liste der Unternehmen, bei denen die Teilnehmer die von der VDV-ETS zertifi- zierten (((eTicket-Systemkomponenten oder Rechte oder Lizenzen daran erwer- ben können;

 die vollständige und konsistente VDV-KA-Dokumentation in ihrer jeweils aktuellen Fassung, inklusive XML-Schemata.

Die Informationsdatenbank ist in einem geschützten Bereich anzulegen, der nur für Teilnehmer zugänglich ist.

3. Die VDV-ETS ist verpflichtet, im Falle von Verstößen von Teilnehmern gegen deren Pflichten aus dem (((eTicket-Teilnahmevertrag, einschließlich des (((eTicket- Regelwerks, nach entsprechender Ankündigung und angemessener Fristsetzung ge- genüber dem verstoßenden Teilnehmer geeignete Maßnahmen zu ergreifen. Die VDV-ETS wird bei der Auswahl der Maßnahmen die wirtschaftlichen Interessen des Betroffenen sowie die berechtigten Interessen aller Teilnehmer berücksichtigen.

4. Die VDV-ETS kann zur Pflege und Weiterentwicklung des Standards eigenständige Gremien (Arbeitsgruppen) bilden. Diese Gremien dienen der fachlichen Begleitung der Arbeit der VDV-ETS.

Die Gremien setzen sich zusammen aus von der VDV-ETS ausgewählten Experten aus der Verkehrsbranche und Mitarbeitern der VDV-ETS. Die organisatorische Be- treuung sowie die Leitung übernehmen Mitarbeiter der VDV-ETS. Ein genereller An- spruch auf Mitgliedschaft in einer AG besteht für Teilnehmer am (((eTicket Deutsch- land nicht. Die Gremien geben sich eine Geschäftsordnung.

5. Zur Wahrung der Interessen und der Mitbestimmungsrechte der Teilnehmer am (((eTicket-Deutschland und zur Gewährleistung von Investitionsschutz und Rechtssi- cherheit richtet die VDV-ETS ein eigenständiges Gremium unter Beteiligung aller Teilnehmer, die Teilnehmerversammlung (TV), ein. Änderungen des Standards und des (((eTicket-Regelwerks bedürfen der vorherigen Zustimmung der TV. Die TV er- hält eine Geschäftsordnung, die Bestandteil dieses Regelwerkes wird.

§ 3 Pflichten der Teilnehmer

1. Die Teilnehmer verpflichten sich, die im (((eTicket-Teilnahmevertrag gewählte(n) Ausbauvariante(n) gemäß KA KUSCH-SPEC (siehe Kapitel 3 Ziffer 10 des (((eTicket- Regelwerks) nach den Vorschriften dieses (((eTicket-Regelwerkes und nach Maßga- be des (((eTicket-Teilnahmevertrags umzusetzen.

Darüber hinaus haben die Teilnehmer die VDV-ETS schriftlich zu informieren, zu wel- chen Zeitpunkten sie noch nicht umgesetzte Ausbauvarianten umsetzen, d.h. in den Wirkbetrieb nehmen möchten oder bereits umgesetzte Ausbauvarianten einstellen

14

[Seite 23]

Anlage 27

(((eTicket Deutschland

wollen. Die Teilnehmer haben der VDV-ETS auf Anfrage Auskunft über den Stand der Umsetzung einer Ausbauvariante zu erteilen.

Die Teilnehmer haben die VDV-ETS zudem unverzüglich über den Vollzug einer Maßnahme im Sinne von Satz 2 zu informieren.

2. Die Teilnehmer haben im Rahmen der Teilnahme am (((eTicket-Deutschland alle ein- schlägigen öffentlich-rechtlichen Vorschriften, insbesondere die bankaufsichtsrechtli- chen, personenbeförderungsrechtlichen, gewerberechtlichen, steuer- und daten- schutzrechtlichen Bestimmungen zu erfüllen. Die VDV-ETS wird die Teilnehmer im Rahmen ihrer Möglichkeiten auf Gesetzesänderungen von größerer Relevanz hinwei- sen.

Gilt nur für Teilnehmer in der Rolle des KVP

3. Jeder KVP ist verpflichtet, a) dem Kunden eine (((eBezahlberechtigung (POB oder WEB oder PEB-Auto- load) auszugeben, die eine AFB beinhaltet; b) pro NM nur eine (((eBezahlberechtigung auszugeben; c) alle (((eBezahlberechtigungen zu Bezahlzwecken zu akzeptieren; d) zur Erfüllung der ihm obliegenden Servicefunktionen ein geeignetes Kunden- beziehungsmanagement, z. B. Kundenservicecenter, Call-Center, stationäre und mobile Lade-, Ticketverkaufs-, Chipkartenausgabe-, Chipkartenrücknah- me- und Informationsterminals einzurichten und vorzuhalten, mit dessen Hilfe Servicewünsche, Anfragen, Beschwerden und Probleme von Nutzern und Kunden zeitnah erfüllt, beantwortet und geklärt werden können. Inwieweit die bereitgestellte Infrastruktur hinreichend und geeignet ist, steht im Ermessen des Teilnehmers; e) Transaktionen (TX-Nachrichten) gemäß VDV-KA-Dokumentation von Teil- nehmern entgegen zu nehmen und weiterzuleiten; f) die Transaktionen (TX-Nachrichten) zu den Fahrtberechtigungen gemäß Vor- gaben der VDV-KA-Dokumentation auf Unverfälschtheit und Authentizität zu prüfen und bei Unregelmäßigkeiten Sperraufträge nach Maßgabe des Kapitel 5 des (((eTicket-Regelwerks zu erstellen; g) bei Unregelmäßigkeiten in Transaktionen (TX-Nachrichten), die von einem Teilnehmer eingereicht werden, nach Maßgabe des Kapitel 5 des (((eTicket-Regelwerks in Abstimmung mit der VDV-ETS eine Organisations- sperre anzufordern; h) den Zahlungsausgleich im Falle von AFB-Einnahmen auf der Grundlage der mithilfe des PV ermittelten Forderungen durchzuführen. i) die jeweils gemäß KA-KUSCH-SPEC (siehe Kapitel 3, Ziffer 10 des (((eTicket- Regelwerks) anwendbaren (((eTicket-Zeichen in seinen Geschäftsräumen sowie an allen Verkaufsstellen deutlich sichtbar anzubringen; k) potentielle Kunden über die Nutzung des (((eTicket-Deutschland zu informieren; l) sämtliche Rechnungen, die er dem Kunden gegenüber im Namen und für Rechnung eines anderen Teilnehmers auszustellen hat, gemäß den hierauf anwendbaren gesetzlichen Vorschriften (insbesondere den Regelungen des UStG) auszustellen.

Die übrigen sich aus dem (((eTicket-Regelwerk, der VDV-KA-Dokumentation (Kapitel 3 des (((eTicket-Regelwerks) und dem jeweiligen (((eTicket-Teilnahmevertrag ergebenden Ver- pflichtungen bleiben unberührt.

15

[Seite 24]

Anlage 27

(((eTicket Deutschland

Gilt nur für Teilnehmer in der Rolle des PV

4. Jeder PV ist verpflichtet, a) sofern er Tarifverantwortlicher in einer Region ist, alle anderen potentiellen Teilnehmer in dieser Region beim Aufbau und bei der Umsetzung des (((eTi- cket-Systems angemessen zu unterstützen und zu informieren; b) seine Produkte beim AH registrieren zu lassen und dem KOSE Konfigurati- onsdaten auf elektronischem Wege zur Verfügung zu stellen; c) allen Teilnehmern in der Rolle des DL, die seine Produkte akzeptieren, alle erforderlichen Informationen für eine ggf. stattfindende On-Trip- Preisbe- rechnung im Rahmen der automatisierten Fahrpreisermittlung sowie für die Kontrolle der Fahrberechtigungen im Rahmen der automatisierten Fahrpreis- ermittlung in Form von Produktmodulen, Kontrollmodulen und Templates zur Verfügung zu stellen; d) allen Teilnehmern in der Rolle des KVP, die seine Produkte in Form von Be- rechtigungen ausgeben, alle erforderlichen Informationen für eine ggf. statt findende Preisermittlung in Form von Produktmodulen, Templates und Kontin- genten zur Verfügung zu stellen; e) die Post-Trip-Preisberechnung in seiner Verantwortung durchzuführen; f) seine Produkte mit (((eBezahlberechtigungen interoperabel zu gestalten. Dies bedeutet, dass alle (((eBezahlberechtigungen in allen am (((eTicket teilneh- menden Regionen/Unternehmen zum Erwerb von Papier- oder (((eTickets und zur Nutzung in Systemen zur automatisierten Fahrpreisfindung eingesetzt werden können müssen, soweit (((eBezahlberechtigungen am jeweiligen Ter- minal als Bezahlverfahren akzeptiert werden. Die Nutzung geschieht zu dem vom jeweiligen Tarifverantwortlichen festgelegten Tarif. g) Transaktionen (TX-Nachrichten) gemäß VDV-KA-Dokumentation von Teil nehmern entgegen zu nehmen und weiterzuleiten; h) die Transaktionen (TX-Nachrichten) zu den Berechtigungen gemäß Vorga- ben der VDV-KA-Dokumentation auf Vollständigkeit, Unverfälschtheit, Authen- tizität und Lückenlosigkeit zu prüfen und bei Unregelmäßigkeiten Sperranfor- derungen nach Maßgabe des Kapitel 5 des (((eTicket-Regelwerks zu erstel- len; i) bei Unregelmäßigkeiten in Transaktionen (TX-Nachrichten), die von einem Teilnehmer eingereicht werden, nach Maßgabe des Kapitel 5 des (((eTicket-Regelwerks in Abstimmung mit der VDV-ETS eine Organisations- sperre anzufordern; k) die Aufteilung und Weiterleitung von Forderungen, z.B. Prepaid- Aufladebeträge, EFS-Einnahmen oder Einnahmen aus der automatisierten Fahrpreisermittlung, die die Teilnehmer im Rahmen der Teilnahme am (((eTi- cket-Deutschland erhalten sowie die Erbringung von Datenverarbeitungsleis- tungen im Zusammenhang mit der Ermittlung der Höhe der entsprechenden Forderungen, durchzuführen. l) sicherzustellen, dass seine zur Ausgabe von Berechtigungen notwendigen PV-Schlüssel rechtzeitig (bei Einbringung neuer Produkte ins (((eTicket- System bzw. bei Austausch von Schlüsseln) in jedem SAM, das seine Berech- tigungen ausgibt, verfügbar sind. Dazu sind die jeweiligen Schlüssel rechtzei- tig für die im Verantwortungsbereich des PV operierenden KVP´s freizugeben, damit deren Einbringung in die SAM´s möglich ist. Die übrigen sich aus dem (((eTicket-Regelwerk, der VDV-KA-Dokumentation (Kapitel 3 des (((eTicket-Regelwerks) und dem jeweiligen (((eTicket-Teilnahmevertrag ergebenden Ver- pflichtungen bleiben unberührt.

16

[Seite 25]

Anlage 27

(((eTicket Deutschland

Gilt nur für Teilnehmer in der Rolle des DL

5. Jeder DL ist verpflichtet,

a) die Nutzer bei der Inanspruchnahme der Beförderungsleistungen nach eige- nem Ermessen auf das Vorhandensein einer gültigen Fahrberechtigung hin zu kontrollieren. Im Rahmen der Kontrolle ist jeder DL insbesondere zur Vorhal- tung und zum Einsatz von ausreichendem und geeignetem Personal sowie zur Vorhaltung, Wartung und zum Einsatz von ausreichenden (((eTicket- Sys- temkomponenten (z. B. Lesegeräte für NM, Einstiegskontrollterminal, Check- in-/Check-out-Terminal, Be-in-Be-Out-Erfassungsgeräte) verpflichtet, die für die Durchführung der elektronischen Kontrolltätigkeiten nach VDV-KA- Standard zertifiziert sind. Der Teilnehmer hat das Recht, diese Pflicht auf Drit- te zu übertragen; b) die jeweils gemäß KA-KUSCH-SPEC (siehe Kapitel 3, Ziffer 10 des (((eTicket- Regelwerks) anwendbaren (((eTicket-Zeichen in, bzw. an den für die Beförde- rung der Nutzer vorgesehenen Verkehrsmitteln, an den eingesetzten (((eTik- ket-Systemkomponenten, z.B. an allen Terminals, sowie an allen sonst zu ihrem Bereich gehörenden, der Information der Nutzer dienenden Stellen deutlich sichtbar anzubringen; c) sämtliche (((eBezahlberechtigungen als Fahrtberechtigungen (in Ausbauvari- ante AFB) zu akzeptieren.

Es wird Teilnehmern in der Rolle des DL empfohlen, die Transaktionen (TX-Nachrichten) zu den Fahrtberechtigungen gemäß Vorgaben der VDV-KA-Dokumentation auf Integrität und Authentizität zu prüfen. Eine Verpflichtung hierzu besteht jedoch nicht.

Die übrigen sich aus dem (((eTicket-Regelwerk, der VDV-KA-Dokumentation (Kapitel 3 des (((eTicket-Regelwerks) und dem jeweiligen (((eTicket-Teilnahmevertrag ergebenden Ver- pflichtungen bleiben unberührt.

§ 4 Technische Anforderungen an die von den Teilnehmern verwendeten (((eTicket- Systemkomponenten

1. Die Teilnehmer haben alle im Rahmen des (((eTicket-Deutschland durchzuführenden technischen Prozesse unter Beachtung der nach Maßgabe des Releasemanage- ments (Kapitel 9 des (((eTicket-Regelwerks) jeweils gültigen Fassung (Release) der VDV-KA-Dokumentation (Kapitel 3 des (((eTicket-Regelwerks) und den in den sonsti- gen Kapiteln des (((eTicket-Regelwerks enthaltenen Vorgaben abzuwickeln. Die Re- gelung des § 6 Abs. 2 bleibt hiervon unberührt. Zur Sicherstellung der verbund-, bzw. landes-, bzw. bundesweiten Interoperabilität hat jeder Teilnehmer bei Neubeschaf- fungen von (((eTicket-Systemkomponenten -mit Ausnahme der Nutzermedien- ab dem 01.01.2015 zusätzlich zur aktuell gültigen Version auch die jeweils vorherige Version der VDV-KA mit umzusetzen. Bereits bestehende Systeme müssen sich in- tern auf eine einheitliche Anwendung einer Version einigen, um die landes- oder ver- bundweite Interoperabilität nicht zu beeinträchtigen. Die VDV-ETS ist verpflichtet, ei- nen Releasekalender zu führen, diesen regelmäßig fortzuschreiben, bzw. zu aktuali- sieren und ihn auf Wunsch jedem Teilnehmer zur Verfügung zu stellen.

2. Um sicher zu stellen, dass die Funktionalitäten sämtlicher Teilnehmersysteme fach- lich korrekt umgesetzt sind und auch um den geforderten Qualitätsanforderungen in Bezug auf die Kommunikation mit den zentralen Systemen und dem gesamten ION 17

[Seite 26]

Anlage 27

(((eTicket Deutschland

zu entsprechen, sind vor Aufnahme des Wirkbetriebs und vor Anschluss an die Pro- duktivsysteme von ZVM und KOSE-S Tests der eingesetzten Hard- und Software er- forderlich. Hierbei ist jedoch zu berücksichtigen, dass bei Gemeinsamen Servicestel- len (GSS) oder bei Mandantensystemen die Anbindungstests nur für diese Systeme erforderlich sind, d.h. zusätzliche Tests für die angebundenen VU-Systeme sind hier- für nicht notwendig. Es wird jedoch empfohlen, dass bei den an der GSS / dem Man- dantensystem angeschlossenen VU-Systemen ebenfalls entsprechende Test durch- geführt werden. Dies obliegt den Systembetreibern und nicht VDV ETS.

Der Nachweis eines erfolgreichen Tests ist die Voraussetzung für die durch die VDV ETS zu erteilende Zulassung zum Wirkbetrieb. VDV ETS kann bis zum Vorliegen des entsprechenden Nachweises, der auch durch den Systemanbieter des Teilnehmers erbracht werden kann, den Zugang zum ION verweigern. Das erfolgreiche Absolvie- ren der erforderlichen Testfälle wird mit einem Testreport für den jeweiligen Teilneh- mer nachgewiesen. Es müssen dabei jedoch nur die Testfälle innerhalb der Migrati- onsstufe umgesetzt werden, in der sich das jeweilige System befindet. Der Teilneh- mer ist verpflichtet, im Falle einer teilweisen Umsetzung der Migrationsstufe die VDV ETS bei jeder Erweiterung zu informieren. Bei einer Systemerweiterung müssen die für die Erweiterung notwendigen Tests ebenfalls nachgewiesen werden. Sofern eine neue KA-Version oder ein neues System eingesetzt werden soll, ist der Nachweis er- neut zu erbringen.

Für die Zulassungstests zum Anschluss an das ION stehen die Betreiber der ZVM, des KOSES und des AHS mit ihren Level2-Testsystemen zur Verfügung. Tests in Produktivsystemen sind nicht zulässig, da hierdurch Schäden im Wirkbetrieb verur- sacht werden können. Die zur Durchführung eines erfolgreichen Anschalttest erfor- derlichen Schritte und Testfälle sind in einem separaten Dokument „Testvorschrift zum Anschluss an das KA-ION“ als Kapitel 10 zum (((eTicket-Regelwerk geregelt. Dieses ist in der jeweils aktuellen Fassung über das WEB-Portal (ASM) der VDV ETS zu beziehen.

3. Die von den Teilnehmern eingesetzten Terminals, die von ihnen ausgegebenen bzw. für die Ausgabe der VDV-Kernapplikation verwendeten NM sowie das von ihnen ein- gesetzte Hintergrundsystem müssen die für die VDV-Kernapplikation geltenden tech- nischen Anforderungen erfüllen, die für die gewählte(n) Ausbauvariante(n) erforderli- chen Anwendungsfälle abbilden und die dafür notwendigen Kommunikationsschnitt- stellen bedienen. Die technischen Anforderungen, Kommunikationsschnittstellen und Anwendungsfälle sind in der in Kapitel 3 des (((eTicket-Regelwerks genannten VDV- KA-Dokumentation niedergelegt.

Werden die technischen Anforderungen, die Anforderungen an die Kommunikations- schnittstellen und die Anwendungsfälle von einer (((eTicket-Systemkomponente (SAM, Terminal, NM, Hintergrundsystemschnittstelle) durch den Hersteller erfüllt, hat die VDV-ETS diesem für die jeweilige (((eTicket-Systemkomponente eine Zertifizie- rung zu erteilen. Soweit eine Zertifizierung erteilt wurde, gelten sämtliche zum Zeit- punkt der Zertifizierung geltenden technischen Anforderungen des (((eTicket- Regelwerks als erfüllt. Eine Zertifizierung des (((eTicket-Systems vor Ort ist nicht Ge- genstand dieser Regelung. (((eTicket-Systemkomponenten, die ab Unterzeichnung des (((eTicket-Teilnahmevertrages in Betrieb genommen werden, dürfen nur dann eingesetzt werden, wenn sie zuvor von dem KA-Prüflabor zertifiziert wurden. Die er- teilte Zertifizierung gilt vorbehaltlich des nachfolgenden Satzes, solange die zertifizier- te (((eTicket-Systemkomponente keine technische Änderung (Hard- bzw. Software) erfährt. Ändert sich die der Zertifizierung zugrunde liegende Version der relevanten Spezifikation/Spezifikationen, so dass sich daraus technische Änderungen an der 18

[Seite 27]

Anlage 27

(((eTicket Deutschland

(((eTicket-Systemkomponente ergeben, wird nach Maßgabe des § 6 auf Vorschlag der AG Standardisierung ein angemessener Übergangszeitraum definiert, in dem für die (((eTicket-Systemkomponente eine Nachzertifizierung durch das KA-Prüflabor er- folgen muss.

Im Rahmen von Migrationsszenarien ist die Zertifizierung der tatsächlich vorhande- nen Hard- und Softwarekomponenten, bzw. der tatsächlich umgesetzten Elementar- prozesse und Anwendungsfälle ausreichend. Die VDV-ETS wird mit dem Dienstleister des Zertifizierungslabors eine angemessene Kostenreduktion für derartige Teilzertifi- zierungen vereinbaren.

4. Alle von den Teilnehmern im Rahmen des (((eTicket-Deutschland einzusetzenden Terminals sind mit einem Hardware-SAM zu bestücken, welches auf der Grundlage eines gesonderten Vertragsverhältnisses von einem hierzu lizenzierten Unternehmen zur Verfügung gestellt wird. Die SAM-Bestellungen der Teilnehmer werden seitens VDV-ETS zunächst geprüft und werden nach erfolgreicher Prüfung zur Produktion an den Sicherheitsmanage- ment-Dienstleister weitergeleitet. VDV-ETS prüft, ob bestellte SAMs grundsätzlich geeignet sind, ihre bestellte Funktion wahrzunehmen. Ist dies nicht der Fall, so wird der bestellende Teilnehmer darauf hin- gewiesen mit der Bitte um Korrektur oder Bestätigung. VDV-ETS kann jedoch nicht prüfen, ob alle benötigten Schlüssel vorhanden sind, da hierzu detaillierte Kenntnisse der regionalen Umsetzung erforderlich sind. Somit kann VDV-ETS keine Gewährleis- tung dafür übernehmen, ob mit dem bestellten SAM alle notwendigen Berechtigungen ausgegeben werden können, respektive alle notwendigen Berechtigungen kontrolliert werden können. ETS kann daher nicht für fehlerhaft bestellte Schlüsselzusammen- stellungen haftbar gemacht werden. Dies betrifft sowohl die Kosten für die SAMs selbst wie auch alle damit verbundenen Folgekosten.

Es bleibt dem bestellenden Teilnehmer vorbehalten, SAMs zu bestellen, die in der bestellten Form weder zum Verkauf noch zur Kontrolle jedweder Produkte eingesetzt werden können, da ihnen die notwendigen Schlüssel teilweise oder vollständig feh- len, z.B. weil der bestellende Teilnehmer diese nach der Produktion selbst mit ent- sprechenden Schlüsseln versehen möchte.

Nach erfolgter Weiterleitung der SAM-Bestellung durch VDV-ETS an den Dienstleis- ter kann eine Bestellung nicht mehr storniert werden. Der Zeitpunkt des Eingangs der Bestellung beim Sicherheitsmanagement-Dienstleister ist der für das Zustandekom- men des Werkvertrags relevante Zeitpunkt im Sinne der SLA´s des Sicherheitsma- nagement-Dienstleisters.

Die SAMs sind für alle mit dem Nutzermedium ausgeführten Transaktionen zu nut- zen. Die Teilnehmer müssen gegenüber der VDV-ETS jederzeit einen Nachweis dar- über erbringen können, wo sich jedes einzelne SAM des Teilnehmers befindet. SAMs dürfen an nicht autorisierte Dritte nicht weitergegeben werden. SAMs dürfen nicht manipuliert, modifiziert oder zerstört werden. SAMs, die sich nicht im Einsatz befin- den, müssen an einem sicheren Ort und vor Zugriffen Unbefugter geschützt aufbe- wahrt werden. SAMs dürfen nach Ablauf ihrer Gültigkeit nicht mehr verwendet wer- den. Sollte ein SAM nicht mehr zur Verwendung kommen (z.B. nach Ablauf der Gül- tigkeit oder bei Fehlfunktion), muss das SAM zur gemäß der folgenden Regelungen entsorgt werden. Unter Entsorgung ist das dauerhafte unbenutzbar Machen durch Schreddern, Zerschneiden, Lochen o.ä. des Chips zu verstehen. Jeder Teilnehmer ist für die ordnungsgemäße Entsorgung von seinen SAMs verantwortlich. Die Entsor- gung eines SAMs muss innerhalb von 2 Monaten nach dem Verfalldatum des SAMs

19

[Seite 28]

Anlage 27

(((eTicket Deutschland

erfolgen. Der Teilnehmer muss schriftlich innerhalb von 2 Wochen nach der Entsor- gung gegenüber ETS eine Eigenerklärung über die Entsorgung jedes einzelnen SAMs abgeben. Die Erklärung kann auch für eine Gruppe von SAMs abgegeben werden. Für die Selbsterklärung stellt ETS ein entsprechendes Muster bereit. Der Ei- generklärung ist eine vollständige Liste der betreffenden SAMs beizulegen. Diese SAM-Liste kann als Excel- oder XML-Datei bereitgestellt werden und muss für jedes SAM die SAM_ID (bestehend aus: Verfalldatum, Gültigkeitsbeginn, Org-ID, SAM- Nummer entsprechend gültiger KA SAM Spec) enthalten. Die abgegebenen Eigener- klärungen und zugehörigen SAM-Listen werden durch ETS archiviert. Bei Verlust ei- nes SAMs muss das SAM gesperrt werden und der Verlust an die VDV-ETS gemel- det werden. Die Aktivierungsschlüssel zu SAMs müssen sicher und vor Zugriffen Un- befugter geschützt aufbewahrt werden.

5. Die Teilnehmer dürfen nur solche NM ausgeben bzw. die VDV-Kernapplikation (im Folgenden als Applikation bezeichnet) nur auf solche NM aufspielen, bei denen das Sicherheitsmanagement (Public-Key-Infrastruktur, Schlüsselmanagement der zentra- len Schlüssel, Schlüsselmanagement der dezentralen Schlüssel sowie Beschaffung des Secure Application Module) von dem Sicherheitsmanagementdienstleister vorge- nommen wird.

§ 5 Beauftragung mit Leistungen des KOSE; Pflichten der Teilnehmer im Zusam- menhang mit der Erfüllung der Systemintegrität

1. Die VDV-ETS ist verpflichtet, in eigenem Namen im Wege des weitergeleiteten Auf- trages auf der Grundlage des in Kapitel 8 des (((eTicket-Regelwerks enthaltenen Ver- trages einen geeigneten Dritten mit der Durchführung von Leistungen im Rahmen des KOSE zu beauftragen. Der Umfang der von dem Dritten zu erbringenden Leistungen ergibt sich aus Kapitel 8 des (((eTicket-Regelwerks. Die Leistungspflicht der VDV- ETS beschränkt sich hinsichtlich der in Satz 1 und 2 genannten Tätigkeiten auf die sorgfältige Auswahl und Unterweisung des Dritten. Insofern beschränkt sich die Haf- tung der VDV-ETS auf die sorgfältige Auswahl und Unterweisung des Dritten nach Maßgabe von § 11 sowie auf die Abtretung der bestehenden Mängel- und Schadens- ersatzansprüche der VDV-ETS gegen den Dritten. Für ein Verschulden des Dritten haftet die VDV-ETS nicht.

2. Die Teilnehmer sind verpflichtet, der VDV-ETS sonstige Umstände unverzüglich nach Kenntniserlangung bekannt zu geben, die auf einen tatsächlichen oder drohenden Missbrauch der (((eTicket-Produkte, der (((eTicket-Systemkomponenten oder des (((eTicket-Systems schließen lassen.

3. Soweit ein Teilnehmer Aktivitäten oder Prozesse, die im Zusammenhang mit dem (((eTicket-Deutschland stehen, ganz oder teilweise an einen Dritten auslagern möch- te, hat er in dem hierzu mit dem Dritten abzuschließenden Auslagerungsvertrag alle diesbezüglichen Pflichten aus dem (((eTicket-Teilnahmevertrag an den Dritten weiter- zugeben. Dieses gilt nicht für untergeordnete Aktivitäten und Prozesse wie die Kon- trolle von Kunden/Nutzer. Der Teilnehmer hat für eventuelle Pflichtverletzungen des Dritten einzustehen. Auf Verlangen hat der Teilnehmer der VDV-ETS eine Kopie des Auslagerungsvertrages auszuhändigen. Darüber hinaus hat dieser Teilnehmer in den Auslagerungsvertrag durch geeignete vertragliche Regelungen folgende Pflichten des Dritten gegenüber diesem Teilnehmer aufzunehmen:

 Verpflichtung des Dritten zur Umsetzung von Änderungen in Bezug auf die VDV- KA Dokumentation (insbesondere nach Maßgabe von § 6); 20

[Seite 29]

Anlage 27

(((eTicket Deutschland

 Verpflichtung des Dritten, den auslagernden Teilnehmer über Fehler im Zusam- menhang mit dem ausgelagerten Bereich unverzüglich zu informieren;

 Verpflichtung des Dritten, Weisungen des auslagernden Teilnehmers im Zusam- menhang mit dem ausgelagerten Bereich zu beachten, etwaige Kontrollen dieses Teilnehmers gemeinsam mit der VDV-ETS vor Ort in seinen Geschäftsräumen zu dulden und diesem Teilnehmer und der VDV-ETS auf Verlangen Informationen zu erteilen und Unterlagen herauszugeben, soweit im Hinblick auf die Systemintegri- tät ein berechtigtes Interesse der Teilnehmer an solchen Kontrollen bzw. Informa- tionen und Unterlagen besteht. Die Kontrollen sollen dem Teilnehmer schriftlich angekündigt und begründet werden.

4. Die Teilnehmer haben durch geeignete Maßnahmen sicherzustellen, dass in ihrem Einflussbereich sowie im Einflussbereich der von ihnen eingeschalteten Dritten keine missbräuchliche Verwendung von (((eTicket-Systemkomponenten, der (((eTicket- Produkte und des (((eTicket-Systems möglich ist.

§ 6 Änderungen der technischen Anforderungen und der Pflichten im Zusammen- hang mit der Erhaltung der Systemintegrität

1. Die VDV-ETS ist berechtigt, die in § 4 Abs. 1 bis 4 und § 5 Abs. 1 Satz 2 genannten Anforderungen sowie die Dokumente der in Kapitel 3 des (((eTicket-Regelwerks be- zeichneten VDV-KA-Dokumentation durch Mitteilung in Textform gegenüber den Teilnehmern nach Maßgabe dieses Regelwerks zu ändern oder zu ergänzen. Ände- rungen sind zunächst von der AG Standardisierung in fachlicher Hinsicht zu beraten und der VDV-ETS zur Freigabe zu empfehlen. Die VDV-ETS wird im Falle von Unei- nigkeit mit der AG Standardisierung über einzelne Freigabeentscheidungen im Aus- tausch mit dem Fachbeirat einen Lösungsvorschlag unterbreiten. Bei erneutem Dis- sens wird die Freigabeentscheidung dem Aufsichtsrat vorgelegt. Im Anschluss an die Freigabe durch die VDV-ETS werden die Änderungsvorschläge der Teilnehmerver- sammlung und bei entsprechender Relevanz i.S. von Abs. 3b) der Gesellschafterver- sammlung zur Beschlussfassung vorgelegt. Nach Vorhandensein sämtlicher notwen- diger Beschlüsse wird der Änderungsvorschlag durch die VDV-ETS endausgefertigt und kann dann zum festgelegten Datum in Kraft treten.

2. Bei Änderungen, die Anpassungen erfordern, sind die Teilnehmer verpflichtet, ab dem in der Änderungsmitteilung vorgesehenen Zeitpunkt, der zumindest 5 Jahre nach dem Mitteilungstermin liegen muss, die geänderten oder ergänzten Anforderun- gen einzuhalten. Eine längere Dauer des jeweiligen Umsetzungszeitraums wird durch die AG Standardisierung vorgeschlagen und von der Teilnehmerversammlung be- schlossen. Dem Teilnehmer steht es frei, die Änderung vorzeitig umzusetzen. Die VDV-ETS hat dafür Sorge zu tragen, dass bei Änderungen, die Veränderungen an im Einsatz befindlichen (((eTicket-Systemkomponenten zur Folge haben, eine Abwärts- kompatibilität für den Umsetzungszeitraum gewährleistet ist. Der Teilnehmer, der die Änderung vor Ablauf der Umsetzungsfrist umsetzt, ist daher verpflichtet, für diese Zeiträume neben der aktuell verabschiedeten Version der VDV-Kernapplikation auch die vorherige Version zu unterstützen.

3. Es wird zwischen zwei Formen von Änderungen unterschieden:

21

[Seite 30]

Anlage 27

(((eTicket Deutschland

a) Änderungen innerhalb einer Versionsnummer, bzw. Änderung der Versionsnum- mer nach dem Komma/Punkt der Ziffernfolge des jeweiligen Dokuments der VDV- KA-Dokumentation. Hierbei handelt es sich um Änderungen, die zuvor durch die AG Standardisierung beraten und durch die VDV-ETS zur Freigabe empfohlen werden und die keine zwingenden Veränderungen an im Einsatz befindlichen (((eTicket-Systemkomponenten erfordern. Hierunter sind Änderungen zu verste- hen, die nur fakultativ umzusetzen sind, im wesentlichen Service-Pakete und Kor- rekturen.

b) Änderungen, die zu einer Erweiterung der Versionsnummer des jeweiligen Do- kuments der VDV-KA-Dokumentation führen. Eine Erweiterung der Versions- nummer im Sinne des vorstehenden Satzes liegt bei einer Änderung von Ziffern vor, die sich vor dem Komma/Punkt der Ziffernfolge befinden. Diese Änderungen, die zuvor durch die AG Standardisierung beraten und durch die VDV-ETS zur Freigabe empfohlen werden, können auch Veränderungen an im Einsatz befindli- chen (((eTicket-Systemkomponenten zur Folge haben. Die Umsetzung dieser Änderungen nach Ablauf des Umsetzungszeitraums gem. Abs. 2 ist für die Erhal- tung der Interoperabilität zwingend erforderlich.

4. Änderungen i.S.d. Abs. 3 b) sowie die in diesem Zusammenhang ggf. zu bestimmen- den Übergangszeiträume müssen sowohl die Teilnehmerversammlung, als auch die Gesellschafterversammlung der VDV-ETS mit einer Mehrheit von 3/4 der abgegebe- nen Stimmen beschließen. Eine Änderung i.S.d. Abs. 3 b) ist maximal einmal jährlich zulässig. Änderungen i.S.d. Abs. 3 a) sind nur durch die Teilnehmerversammlung zu beschließen. Die Gesellschafterversammlung der VDV-ETS kann zudem jeweils je- derzeit mit einfacher Mehrheit der abgegebenen Stimmen ihr Zustimmungserfordernis zu einer Änderung i.S.d. Abs. 3 a) beschließen.

5. Im Falle von Änderungen i.S.d. Abs. 3 b) sind durch den Teilnehmer vor Beschluss- fassung der Teilnehmerversammlung und der Gesellschafterversammlung die finan- ziellen Auswirkungen der Änderung zu prüfen und das Ergebnis in der Teilneh- merversammlung zu beraten. Sofern das Volumen der Änderungen nach Ansicht des Teilnehmers unzumutbar hoch ist oder Rückzahlungsverpflichtungen von in Anspruch genommenen Fördermitteln drohen, sind im Bedarfsfall auf Antrag des betroffenen Teilnehmers durch die Teilnehmerversammlung vor der Beschlussfassung geeignete Finanzierungslösungen unter der Berücksichtigung von Fördermöglichkeiten und So- lidaritätsmodellen zu prüfen und ggf. zu erarbeiten.

6. Die Einholung eines Beschlusses der Gesellschafterversammlung der VDV-ETS im Sinne von Abs. 4 ist entbehrlich, wenn die Änderungen aus rechtlichen Gründen oder zur Erhaltung der Integrität des (((eTicket-Systems oder des (((eTicket-Deutschland erforderlich sind und kumulativ hierzu ein Beschluss aufgrund von Eilbedürftigkeit vor Abgabe der Änderungsmitteilung nach Abs. 1 nicht einholbar ist. Der Beschluss wird in diesem Fall unverzüglich nachgeholt.

7. Alle Teilnehmer können der VDV-ETS Änderungsanregungen („Change Requests“) zu den Dokumenten der VDV-KA-Dokumentation vortragen. Die VDV-ETS wird die Änderungsanregungen der AG Standardisierung zur Beratung vorlegen. Die AG Standardisierung trifft eine Empfehlung an die VDV-ETS über die Annahme oder die Ablehnung der Änderungsanregung. Die Teilnehmerversammlung und die Gesell- schafterversammlung der VDV-ETS werden -soweit nach Abs. 4 erforderlich- über solche Änderungsanregungen auf einer der beiden zeitlich nächsten anstehenden Sitzungstermine (spätestens jedoch innerhalb von 8 Monaten) beraten und beschlie- ßen. 22

[Seite 31]

Anlage 27

(((eTicket Deutschland

§ 7 Einräumung von Nutzungsrechten an (((eTicket-Zeichen

1. Mit Abschluss des (((eTicket-Teilnahmevertrages räumt die VDV-ETS jedem Teil- nehmer das nicht-ausschließliche (einfache), zeitlich auf die Laufzeit des jeweiligen (((eTicket-Teilnahmevertrages beschränkte unentgeltliche Recht zur Nutzung der (((eTicket-Zeichen ein. Lizenzgebiet ist das Gebiet der Bundesrepublik Deutschland, Diese territoriale Beschränkung gilt nicht für die Nutzung der (((eTicket-Zeichen im In- ternet. Die Teilnehmer dürfen die (((eTicket-Zeichen nur nach Maßgabe der Bestim- mungen dieser (((eTicket-Teilnahmebedingungen und nach Maßgabe des in Kapitel 4 des (((eTicket-Regelwerks beigefügten Markenbuchs nutzen. Die Teilnehmer dürfen die (((eTicket-Zeichen nur in unveränderter Form nutzen, um die VDV-Kernapplikation zu bewerben und zu vermarkten. Durch Verwendung der einheitlichen Marken und Zeichen wird dem Fahrgast signalisiert, dass er dort, wo diese abgebildet sind, sein Nutzermedium interoperabel einsetzen kann.

2. Jeder Teilnehmer ist berechtigt, nach Maßgabe dieser (((eTicket- Teilnahmebedingungen den von ihm gem. § 5 Abs. 3 eingeschalteten Dritten das Recht nach vorstehendem Abs. 1 einzuräumen, die (((eTicket-Zeichen zu nutzen, soweit dies für ein Tätigwerden des Dritten erforderlich ist. Die Teilnehmer sind ver- pflichtet, die in diesen (((eTicket-Teilnahmebedingungen und dem in Kapitel 4 des (((eTicket-Regelwerks beigefügten Markenbuch niedergelegten Vorgaben zum Um- gang mit den (((eTicket-Zeichen auf den Dritten zu übertragen und bei Kenntnisnah- me einer Verletzung dieser Vorgaben geeignete Maßnahmen unter Berücksichtigung der wirtschaftlichen Interessen des Dritten und der Interessen der übrigen Teilnehmer gegenüber diesem Dritten zu ergreifen. Bei einem besonders schweren und/oder wiederholten Verstoß gegen die Bestimmungen dieser (((eTicket- Teilnahmebedingungen oder dem in Kapitel 4 des (((eTicket-Regelwerks niedergeleg- ten Markenbuch zum Umgang mit den (((eTicket-Zeichen durch diesen Dritten ist der Teilnehmer verpflichtet, den entsprechenden Vertrag mit dem Dritten ohne Einhaltung einer Kündigungsfrist zu kündigen. Ein besonders schwerer Verstoß ist insbesondere darin zu sehen, dass der Dritte als Erfüllungsgehilfe des Teilnehmers vorsätzlich ge- gen § 3 Abs. 5 b) verstößt.

3. Die Teilnehmer haben die VDV-ETS über jede ihnen bekannt gewordene Schutz- rechtsverletzung unverzüglich schriftlich zu unterrichten.

4. Kommt ein Teilnehmer den in diesen (((eTicket-Teilnahmebedingungen und dem in Kapitel 4 des (((eTicket-Regelwerks beigefügten Markenbuch geregelten Pflichten zur Nutzung der (((eTicket-Zeichen nicht oder nur unzureichend nach und stellt er diese vom ihm zu vertretende, nicht unerhebliche Vertragsverletzung trotz schriftlicher Ab- mahnung innerhalb einer Frist von einem Monat ab Zugang der Abmahnung nicht ein oder beseitigt er die Folgen dieser Vertragsverletzung nicht innerhalb dieser Frist, so ist die VDV-ETS berechtigt, diesem Teilnehmer die Teilnahme am (((eTicket- Deutschland so lange zu untersagen, wie die Vertragsverletzung andauert oder wie die Folgen der Vertragsverletzung nicht vollumfänglich beseitigt sind. Für den Fall, dass dieser Teilnehmer eine nicht unerhebliche Vertragsverletzung und deren Folgen im Nachgang zu einer solchen Abmahnung innerhalb eines Zeitraums von drei Mona- ten nach Zugang der Abmahnung nicht beseitigt hat, hat die VDV-ETS das Recht, den (((eTicket-Teilnahmevertrag mit diesem Teilnehmer ohne Einhaltung einer Kün- digungsfrist zu kündigen. Weitergehende Rechte der VDV-ETS bleiben hiervon unbe- rührt. Die vorstehenden Regelungen gelten entsprechend für den Fall, dass ein Teil- 23

[Seite 32]

Anlage 27

(((eTicket Deutschland

nehmer nicht oder in nicht ausreichendem Maße gegen eine Verletzung der Regelun- gen dieser (((eTicket-Teilnahmebedingungen oder des in Kapitel 4 des (((eTicket- Regelwerks beigefügten Markenbuchs durch einen von ihm gem. § 5 Abs. 3 einge- schalteten Dritten vorgeht.

5. Wird ein Teilnehmer von Dritten wegen der Verletzung von Rechten an (((eTicket- Zeichen in Anspruch genommen, hat er die VDV-ETS unverzüglich und umfassend schriftlich zu unterrichten. Dieser Teilnehmer wird der VDV-ETS soweit möglich die Verteidigung gegen diese Ansprüche überlassen. Dabei wird dieser Teilnehmer die VDV-ETS unentgeltlich und bestmöglich unterstützen und ihr die zur Rechtsverfol- gung erforderlichen Informationen rechtzeitig zur Kenntnis geben. Die VDV-ETS wird unverzüglich geeignete Schritte zur Abwehr ergreifen. Soweit diese für diesen Teil- nehmer nicht ausreichend sind oder nicht schnell genug greifen, ist er berechtigt, sei- nerseits die nötigen Schritte vorzunehmen. Die VDV-ETS ersetzt diesem Teilnehmer sämtliche Kosten, die daraus entstehen, dass dieser Teilnehmer von dritter Seite auf- grund einer Schutzrechtsverletzung bezüglich der von der VDV-ETS in diesen (((eTi- cket-Teilnahmebedingungen eingeräumten Rechte an den (((eTicket-Zeichen in An- spruch genommen wird sowie den Schaden, der berechtigt aus einer Schutzrechts- verletzung entsteht.

§ 8 Informationspflichten, Kontroll- und Betretungsrechte

1. Die Teilnehmer haben dem Registrar der VDV-ETS Änderungen ihrer Kontaktdaten unverzüglich schriftlich anzuzeigen.

2. Die Teilnehmer haben auf Anforderung der VDV-ETS unverzüglich Auskünfte zur Organisation ihres Geschäftsbetriebs in Bezug auf das (((eTicket-System zu erteilen. In einem solchen Fall wird eine Vertraulichkeitsvereinbarung geschlossen, welche den Verwendungszweck der Auskünfte auf die Lösung von technischen oder sicher- heitsrelevanten Problemen beschränkt.

3. Wird ein Teilnehmer von Dritten wegen der Verletzung von sonstigen, nicht in § 7 geregelten, gewerblichen Schutzrechten in Bezug auf das (((eTicket-Deutschland in Anspruch genommen, hat er die VDV-ETS unverzüglich und umfassend schriftlich zu unterrichten. Bei der Verteidigung gegen solche Ansprüche werden der Teilnehmer und die VDV-ETS sich gegenseitig, unentgeltlich und bestmöglich unterstützen.

4. Die VDV-ETS ist darüber hinaus gegenüber allen Teilnehmern berechtigt und ver- pflichtet, durch das Verlangen von Auskünften und Unterlagen anlassbezogen zu prü- fen, ob die Teilnehmer die ihnen aufgrund des (((eTicket-Regelwerks obliegenden Pflichten einhalten und für die Einhaltung dieser Pflichten eine ordnungsgemäße und angemessene Prozessorganisation vorhalten. Die VDV-ETS hat anlassbezogene Prüfungshandlungen in Bezug auf SAM´s und Terminals in dem jeweils erforderlichen Umfang immer dann vorzunehmen, wenn Tatsachen die Annahme rechtfertigen, dass ein Teilnehmer gegen die im (((eTicket-Regelwerk genannten Pflichten verstoßen hat bzw. ein solcher Verstoß droht und anderen Teilnehmern, den Nutzern, den Kunden oder dem (((eTicket-System hierdurch ein Schaden entstehen könnte (im Folgenden: „relevante Pflichtverletzung“). Die Teilnehmer haben die VDV-ETS über solche Tat- sachen in Kenntnis zu setzen. Ergibt eine von der VDV-ETS vorgenommene anlass- bezogene Prüfungshandlung, dass ein Teilnehmer eine relevante Pflichtverletzung begangen hat, so hat die VDV-ETS die anderen Teilnehmer hierüber unverzüglich in

24

[Seite 33]

Anlage 27

(((eTicket Deutschland

Kenntnis zu setzen. Das Gleiche gilt, wenn die VDV KA-KG auf andere Weise Kennt- nis von relevanten Pflichtverletzungen erhält.

Der VDV-ETS oder einer einvernehmlich bestimmten vertrauenswürdigen dritten Par- tei ist unter diesen Voraussetzungen innerhalb der üblichen Betriebs- und Geschäfts- zeiten auf Verlangen Zugang zu den beim Teilnehmer befindlichen SAM´s und Ter- minals sowie zu den Geschäftsräumen, in denen die Verwaltung dieser Systemkom- ponenten stattfindet, zu verschaffen.

5. Die Teilnehmer sind verpflichtet, der VDV-ETS auf Anfrage im Rahmen des Zumutba- ren Daten von Transaktionen zur Verfügung zu stellen, die im (((eTicket-System ab- gewickelt wurden, sofern dies zum Auffinden oder zur Beseitigung von Sicherheitslü- cken dienlich ist (Sicherheitsmonitoring).

§ 9 Teilnahmebeitrag

Für die Teilnahme am (((eTicket-Deutschland nach dem (((eTicket-Teilnahmevertrag zahlen die Teilnehmer an die VDV-ETS keinen Teilnahmebeitrag.

§ 10 Gewährleistung

Das (((eTicket-Regelwerk sowie die in Kapitel 3 des (((eTicket-Regelwerks genannte VDV-KA-Dokumentation und das darin enthaltene technische Konzept (im Folgenden: „Know-how“) wurden mit größter Sorgfalt von der VDV-ETS mit technischen und kaufmännischen Beratern entwickelt. Die Umsetzung des Know-how im Rahmen des (((eTicket-Systems vor Ort obliegt den Teilnehmern. Die VDV-ETS haftet nicht für die individuelle Umsetzung des (((eTicket-Systems durch den Teilnehmer, jedoch dafür, dass die Spezifikationen an sich nicht mit Mängeln behaftet sind.

§ 11 Haftung

1. Die Parteien haften einander für Vorsatz und grobe Fahrlässigkeit in vollem Umfang.

2. Im Falle einfach fahrlässigen Handelns haften die Parteien ausschließlich für

 Personenschäden,

 Schäden, für die die Parteien aufgrund zwingender gesetzlicher Vorschriften (z. B. nach dem Produkthaftungsgesetz) einzustehen hat sowie

 Schäden wegen der Verletzung von wesentlichen Pflichten, die die Erreichung des Zwecks des (((eTicket-Teilnahmevertrages gefährden bzw. deren Erfüllung die ordnungsgemäße Durchführung des (((eTicket-Teilnahmevertrages erst er- möglichen und auf die der Teilnehmer regelmäßig vertrauen darf (Kardinalpflich- ten).

25

[Seite 34]

Anlage 27

(((eTicket Deutschland

Im Falle der Verletzung von Kardinalpflichten ist die Haftung für einfach fahrlässiges Handeln der Parteien auf vertragstypische und bei Abschluss des jeweiligen (((eTi- cket-Teilnahmevertrages vorhersehbare Schäden begrenzt.

§ 12 Änderungen des (((eTicket-Regelwerks einschließlich der VDV-KA- Dokumentation

1. Änderungen des (((eTicket-Regelwerks einschließlich der in Kapitel 3 des (((eTicket- Regelwerks genannten Dokumente werden den Teilnehmern in Textform bekannt ge- geben. Sie gelten für den jeweiligen Teilnehmer als genehmigt, wenn dieser nicht schriftlich Widerspruch erhebt. Auf diese Folge wird ihn die VDV-ETS bei der Be- kanntgabe besonders hinweisen. Der Teilnehmer muss den Widerspruch innerhalb von zwei Monaten nach Bekanntgabe der Änderungen an die VDV-ETS absenden.

2. Im Falle einer Änderung nach Abs. 1 kann jeder Teilnehmer den jeweiligen (((eTicket- Teilnahmevertrag vor dem vorgeschlagenen Zeitpunkt des Wirksamwerdens der Än- derung fristlos kündigen. Die VDV-ETS wird die Teilnehmer bei der Bekanntgabe der Änderung auf dieses Recht besonders hinweisen.

3. Widerspricht ein Teilnehmer einer wesentlichen Änderung des (((eTicket-Regelwerks oder der in Kapitel 3 des (((eTicket-Regelwerks genannten Dokumente, die bei der Bekanntgabe der Änderung ausdrücklich als wesentlich bezeichnet wurde, so stellt dies einen wichtigen Grund dar, der die VDV-ETS zur außerordentlichen Kündigung des jeweiligen (((eTicket-Teilnahmevertrages berechtigt. Wesentlich sind solche Än- derungen, die für alle Teilnehmer einheitlich gelten müssen, um die Interoperabilität, die Funktionsfähigkeit, die Systemintegrität oder ein einheitliches Erscheinungsbild des (((eTicket-Deutschland zu gewährleisten. Vor einer Kündigung nach Satz 1 wird die VDV-ETS mit dem betroffenen Teilnehmer einen Einigungsversuch unternehmen. Für den Fall, dass im Rahmen dieses Versuchs keine Einigung zwischen der VDV- ETS und dem Teilnehmer erzielt werden sollte, erklären sich die Parteien dazu bereit, ein Schlichtungsverfahren gemäß der Schlichtungsordnung der Deutschen Institution für Schiedsgerichtsbarkeit e.V. (DIS) in der bei Einleitung des Verfahrens gültigen Fassung durchzuführen und das daraus hervorgehende Votum zu akzeptieren.

4. Die Regelungen des § 6 bleiben hiervon unberührt. Die für Fälle des § 6 Abs. 3) nie- dergelegten Regelungen zur Beteiligung und zum Zustimmungserfordernis der Ge- sellschafterversammlung und der Teilnehmerversammlung finden entsprechende Anwendung bei Änderungen dieses Regelwerks.

5. Änderungsvorschläge zum Regelwerk werden im SharePoint veröffentlicht. Die Teil- nehmer haben die Möglichkeit, sich dort innerhalb einer angemessenen Frist über vorgeschlagene Änderungen zu informieren und Kommentare/Anmerkungen einzu- stellen. Wenn es aus dem Diskussionsverlauf im SharePoint erkennbaren Abstim- mungsbedarf gibt, kann die VDV-ETS bei Bedarf ein Gremium einberufen, welches einen endgültigen Beschlussvorschlag berät und entwirft. Die Besetzung des Gremi- ums wird in jedem Einzelfall durch die Geschäftsführung der VDV-ETS festgelegt. Die Ergebnisse des Gremiums werden ebenfalls im SharePoint veröffentlicht und auf die- ser Basis der Teilnehmerversammlung vorgeschlagen.

6. Für Änderungen des Clearingvertrages gelten abweichend von den Absätzen 1 bis 4 die dort für Änderungen des Vertragsinhalts vorgesehenen Regelungen.

26

[Seite 35]

Anlage 27

(((eTicket Deutschland

Kapitel 3: VDV-KA-Dokumentation

Nachfolgend sind die zur VDV-KA-Dokumentation gehörenden Dokumente (Spezifikationen, Lastenhefte und Verfahrensanweisungen) aufgeführt.

Die Dokumente können im Webportal www.eticket-Deutschland.de abgerufen werden.

27

[Seite 36]

Anlage 27

(((eTicket Deutschland

28

[Seite 37]

Anlage 27

(((eTicket Deutschland

29

[Seite 38]

Anlage 27

(((eTicket Deutschland

30

[Seite 39]

Anlage 27

(((eTicket Deutschland

Kapitel 4: Markenbuch

Präambel

Die Gesamtheit der interoperablen(((eTicket-Systeme firmiert in Deutschland unter dem Na- men (((eTicket-Deutschland. In anderen Ländern wird ein dem jeweiligen Land entsprechen- der Name gewählt. Das (((eTicket-Logo, die Piktogramme und das Corporate Design sowie die einheitlichen Handlungsanweisungen und Verfahren erhöhen die Wiedererkennbarkeit, den Komfort und die Akzeptanz des (((eTicket-Deutschland. Durch Verwendung der einheitlichen Marken und Zeichen wird dem Fahrgast signalisiert, dass er dort, wo diese abgebildet sind, sein Nutzermedium interoperabel einsetzen kann. Damit werden Zugangshemmnisse zum ÖPV gesenkt. Die VDV-ETS hat die (((eTicket-Marken markenrechtlich und die (((eTicket- Geschmacksmuster geschmacksmusterrechtlich schützen sowie die Webseite www.eticket- deutschland.de registrieren lassen. Die Verwendung der (((eTicket-Zeichen ist sowohl Recht als auch Pflicht der Teilnehmer. Das lokale Corporate Design und das regionale Branding stehen dabei gleichwertig neben den (((eTicket-Zeichen.

Die Verwendung der (((eTicket-Zeichen ist ausschließlich Teilnehmern und der VDV-ETS erlaubt. Der jeweils vorgesehene Einsatzzweck und die Vorschriften zur Einsatzweise sind im „eTicket_Design_Manual“ (Anlage zur KA KUSCH-Spec, siehe Kapitel 3, Ziffer 10 des (((eTicket-Regelwerks) näher beschrieben.

§ 1 Definition

1. (((eTicket-Marken sind

• die Wortmarke „(((eTicket Deutschland“ (nachfolgend „Wortmarke“) und

• die Wort-/Bildmarke (((eTicket-Logo: (nachfolgend „Wort-/Bildmarke“)

2. (((eTicket-Geschmacksmuster sind folgende (((eTicket-Zeichen:

a) das Symbol “Terminal-Akzeptanzfläche”:

b) die Piktogramme:

31

[Seite 40]

Anlage 27

(((eTicket Deutschland

aa) Variante 1: (((eBezahlen:

bb) Variante 2: (((eTicket:

cc) Variante 2+: (((eKontrolle:

dd) Variante 3a: Check-in / Check-out:

ee) Variante 3b: Automatische Ticketerfassung (Be-In/Be-Out):

3. Bei den Zeichen des VDV-Barcodes handelt es sich um folgende Piktogramme:

a) Barcode-Piktogramm:

32

[Seite 41]

Anlage 27

(((eTicket Deutschland

b) Barcode-Akzeptanzfläche horizontal:

c) Barcode-Akzeptanzfläche vertikal:

§ 2 Anwendungsbereich

Dieses Kapitel findet bei jeglicher Nutzung der (((eTicket-Zeichen Anwendung, gleichgültig in welcher Form und gleichgültig in welchen Medien.

§ 3 Allgemeine Anforderungen an die Nutzung der (((eTicket-Zeichen

1. Die Teilnehmer sind nur zur Nutzung jener (((eTicket-Zeichen berechtigt, die im vor- handenen (((eTicket-System tatsächlich Verwendung finden.

2. Die Teilnehmer sind nicht berechtigt, die (((eTicket-Zeichen in irgendeiner Weise zu variieren. Sie dürfen ausschließlich so verwendet werden, wie sie durch die VDV-ETS beim Deutschen Patent- und Markenamt eingetragen worden sind und wie sie in § 1 dargestellt sind.

3. Die Wortmarke darf nicht um zusätzliche Wortzwischenräume ergänzt werden und auch nicht um Kapitälchen. Die Wortmarke darf in Fließtexten kursiv hervorgehoben werden.

4. Die verwendeten Standardfarben dürfen nicht verändert werden. Weitere Einzelheiten ergeben sich aus der Anlage „eTicket_Design_Manual“ zur KA KUSCH-SPEC (siehe Kapitel 3, Ziffer 10 des (((eTicket-Regelwerks).

5. Bei der Verwendung der (((eTicket-Zeichen innerhalb einer Broschüre oder sonstigen Erläuterungen (z. B. Leporello, Internet-Seite) sind diese mit einem Hinweis zu verse- hen, aus dem sich ergibt, dass es sich dabei um eingetragene Marken bzw. Ge- schmacksmuster der VDV-ETS handelt. Dieser Hinweis muss sich auf der gleichen Seite befinden, auf der auch die (((eTicket-Zeichen verwendet werden. Die konkrete Ausgestaltung dieser Kennzeichnung wird den Teilnehmern überlassen.

33

[Seite 42]

Anlage 27

(((eTicket Deutschland

§ 4 Nutzung im Zusammenhang mit Wort- oder Bildbezeichnungen

1. Jegliche Verwendung der (((eTicket-Zeichen, die dazu geeignet ist, die Unterscheid- barkeit der (((eTicket-Zeichen negativ zu beeinträchtigen, ist zu unterlassen.

2. Im Falle einer Verlinkung der (((eTicket-Zeichen im Internet darf nur auf http://www.eticket-deutschland.de und nicht auf eine Unterseite oder eine andere Website verlinkt werden.

§ 5 Nutzung im Zusammenhang mit anderen Bezahlvarianten

1. Werden die (((eTicket-Zeichen neben anderen Bezahlvarianten oder anderen Ticket- Systemen angeboten, muss die Abstandsregelung gemäß des „eTi- cket_Design_Manual“ (Anlage zur KA KUSCH-Spec, siehe Kapitel 3, Ziffer 10 des (((eTicket-Regelwerks) eingehalten werden.

2. Die (((eTicket-Zeichen müssen mindestens als den anderen Bezahlvarianten oder anderen Ticket-Systemen gleichwertiges Verfahren dargestellt werden. Dabei ist ins- besondere zu beachten, dass die (((eTicket-Zeichen in der gleichen Größe und Häu- figkeit wie die Hinweise auf andere Bezahlvarianten oder andere Ticket-Systeme ge- braucht werden. Dies gilt nicht für die Nutzung der (((eTicket-Zeichen zu Werbe- und Marketingzwecken.

34

[Seite 43]

Anlage 27

(((eTicket Deutschland

Kapitel 5: Beschreibung des Sperrsystems

Präambel

Dem Sperrsystem des (((eTicket Deutschland kommt eine maßgebliche Bedeutung zu, weil es in erheblichem Maße zur Sicherheit und Funktionsfähigkeit des (((eTicket-Deutschland beiträgt. Auch zur Vermeidung von wirtschaftlichen Risiken (z. B. Bonitätsrisiken und Miss- brauchsrisiken) ist ein effizientes Sperrsystem unabdingbar. Daher werden die nachfolgen- den verbindlichen Regelungen vereinbart.

§ 1 Organisation des Sperrsystems

1. Das (((eTicket-Deutschland sieht vor, dass die Rolle des KOSE in einem gemeinsa- men System der Teilnehmer, das zentral gesteuert wird und auf dezentralen Kompo- nenten abgewickelt werden kann, durchgeführt wird. Jeder mit der Übernahme von Funktionen des KOSE beauftragte Dritte ist zur Einhaltung der in diesem Kapitel be- schriebenen Regelungen vertraglich zu verpflichten und die Einhaltung der Regelun- gen ist durch geeignete Kontrollverfahren sicherzustellen.

2. Soweit nachfolgend auf die Rolle des KVP in Verbindung mit dem KOSE-System Be- zug genommen wird, handelt es sich hierbei um den jeweiligen KVP, der die Applika- tion (ggf. zusammen mit einem NM) und/oder eine Berechtigung auf diese ausgege- ben hat.

3. Jeder KVP hat eine Sperrannahmestelle zu unterhalten, die er selbst oder durch ei- nen Dritten nach Maßgabe von § 5 Abs. 3 der (((eTicket-Teilnahmebedingungen be- treiben kann.

§ 2 Sperrobjekte

Das Sperrsystem des (((eTicket-Deutschland unterscheidet zwischen verschiedenen Sper- robjekten, abhängig davon, ob sich eine Sperre auf ein Nutzermedium bezieht oder nicht.

1. Nutzermedium bezogene Sperren (NM-Sperren):

 Sperre der Applikation als Gesamtheit (damit sind auch alle (((eBezahlberechti- gungen, die sich in der Applikation befinden nicht mehr nutzbar);

 Sperre einzelner (((eBezahlberechtigungen.

 Sperre einzelner EFS In Folge eines ORG- oder SAM-Sperrlisteneintrags werden die durch diese ORG bzw. diesen SAM ausgegebenen Berechtigungen gesperrt werden.

2. Nicht Nutzermedium bezogene Sperren (OSK-Sperren):

35

[Seite 44]

Anlage 27

(((eTicket Deutschland

 Sperre eines Teilnehmers;  Sperre einzelner SAMs;  Sperre einzelner symmetrischer und asymmetrischer Schlüssel.

§ 3 Sperrnachrichten

Das Sperrsystem des (((eTicket-Deutschland unterscheidet zwischen verschiedenen Sperr- nachrichten, die in den unterschiedlichen Prozessen des Sperrsystems relevant sind.

1. Sperrmeldung: Meldung des Nutzers oder des Kunden an eine Sperrannahmestelle, dass ein Sachverhalt vorliegt, der möglicherweise eine Sperrung erforderlich macht.

2. Sperranforderung: Anforderung der Sperrannahmestelle eines Teilnehmers an den KVP oder den AH (VDV-ETS) oder einen Schlüsseleigentümer, aus der sich ergibt, dass aufgrund der Prüfung durch den jeweiligen Teilnehmer ein Sperrgrund vorliegt.

3. Sperrauftrag: Auftrag des KVP oder des AH (VDV-ETS) oder eines Schlüsseleigen- tümers an den KOSE, dass eine NM-Sperre oder eine OSK-Sperre vorzunehmen ist.

4. Sperrmitteilung: Mitteilung des KVP oder des AH (VDV-ETS) oder eines Schlüsse- leigentümers an die Stelle(n), die eine Sperranforderung abgegeben hat/haben, ob die Sperranforderung zu einem Sperrauftrag geführt hat oder nicht.

5. Sperrlistenanforderung: Anforderung eines Teilnehmers an den KOSE zur Über- mittlung der für ihn konfigurierten Komplett- bzw. Differenzsperrlisten

6. Sperrlisten: von dem KOSE zu erstellende Listen, auf der die jeweils beauftragten NM-Sperren und OSK-Sperren enthalten sind.

7. Sperrnachweisanforderung: Anforderung eines KVP oder des A (VDV-ETS) an den KOSE zur Übermittlung der für sie vorliegenden Sperrnachweise

8. Sperrnachweis: Bestätigung eines (((eTicket-Terminals eines KVP oder eines DL über sein Hintergrundsystem an den KOSE und von dort an den PV bzw. den KVP oder AH, dass ein auf den Sperrlisten enthaltener Eintrag zu einer Markierung auf dem NM (des adressierten Objektes) geführt hat.

9. Sperraufhebungsmeldung: Meldung des Nutzers oder des Kunden an eine Sper- rannahmestelle, dass ein Sachverhalt vorliegt, der möglicherweise die Aufhebung ei- ner Sperrmeldung erforderlich macht.

10. Sperraufhebungsanforderung: Anforderung der Sperrannahmestelle eines Teil- nehmers an den KVP oder den AH (VDV-ETS) oder eines Schlüsseleigentümers, aus der sich ergibt, dass aufgrund der Prüfung des jeweiligen Teilnehmers der Sperr- grund entfallen ist.

11. Sperrfreigabeauftrag: Auftrag des KVP oder des AH (VDV-ETS) oder eines Schlüs- seleigentümers an den KOSE, den Eintrag einer Sperre aus der jeweiligen Sperrliste zu entfernen.

36

[Seite 45]

Anlage 27

(((eTicket Deutschland

12. Sperrfreigabemitteilung: Mitteilung des KVP oder des AH (VDV-ETS) oder eines Schlüsseleigentümers an die Stelle(n), die eine Sperraufhebungsanforderung abge- geben hat/haben, ob die Sperraufhebungsanforderung zu einem Sperrfreigabeauftrag geführt hat oder nicht.

13. Entsperrnachweis: Bestätigung eines KVP an den PV oder AH, dass eine auf dem Nutzermedium enthaltene Sperrung wieder von diesem entfernt wurde, nachdem der Sperrgrund entfallen ist.

14. Sperrlistenkonfigurationsdaten: Information eines PV an den KOSE, welche Pro- dukte des PV bei welchem KVP verkauft und bei welchem DL akzeptiert werden

15. Sperrinformationsanforderung: Anforderung eines PV oder des AH (VDV-ETS) an den KOSE zur Übermittlung der Sperrinformation

16. Sperrinformation: Liste derjenigen KVP bzw. DL, die ihrer Verpflichtung zur Abho- lung von Sperrlisten und Sperrnachweisen nicht nachgekommen sind

§ 4 Sperrprozesse

Im Rahmen des Sperrsystems des (((eTicket-Deutschland fallen folgende Sperrprozesse an, die von den Teilnehmern nach Maßgabe dieses § 4 durchzuführen sind:

1. Sperrprozesse bei dem KVP (nur NM-Sperren)

 Entgegennahme der Sperrmeldung durch die Sperrannahmestelle;

 Erstellen und Senden der Sperranforderung durch die Sperrannahmestelle an den KVP

 Entgegennahme der Sperrmitteilung für erteilte Sperranforderungen;

 Entgegennahme der Sperranforderung;

 Erstellen und Senden des Sperrauftrages an den KOSE; Eine Sperranforderung mit dem Sperrgrund „Zertifikatssperre“ muss immer zu ei- nem Sperrauftrag führen.

 Erstellen und Senden der Sperrmitteilung an den/die sperranfordernden Teil- nehmer, ob die Sperranforderung zu einem Sperrauftrag geführt hat (oder nicht);

 Weiterleitung von Sperrnachweisen nach erfolgter Markierung auf dem NM an den KOSE

 Entgegennahme von Sperrnachweisen vom PV für erteilte (((eBezahlberechti- gungs- und EFS-Sperren

 Erstellen und Senden der Sperrnachweisanforderung an den KOSE für Ap- plikationssperren

 Entgegennahme von Sperrnachweisen vom KOSE für Applikationssperren

37

[Seite 46]

Anlage 27

(((eTicket Deutschland

2. Sperrprozesse bei PV (nur NM-Sperren)

 Erstellen und Senden der Sperranforderung an den KVP ;

 Entgegennahme der Sperrmitteilung für erteilte Sperranforderungen;

 Erstellen und Senden der Sperrnachweisanforderung an den KOSE für (((eBezahlberechtigungen und EFS;

 Entgegennahme von Sperrnachweisen vom KOSE für (((eBezahlberechtigun- gen und EFS;

 Weiterleitung von Sperrnachweisen an den KVP für (((eBezahlberechtigungen und EFS.

3. Sperrprozesse bei DL (nur NM-Sperren)

 Erstellen und Senden der Sperranforderung an den KVP ;

 Entgegennahme der Sperrmitteilung für erteilte Sperranforderungen;

 Weiterleitung von Sperrnachweisen nach erfolgter Markierung auf dem NM an den KOSE

4. Sperrprozesse beim AH (VDV-ETS) bei NM-Sperren; nur bezogen auf die Applikation

 Erstellen und Senden der Sperranforderung an den KVP

 Entgegennahme der Sperrmitteilung vom KVP für erteilte, bzw. nicht erteilte Sperranforderungen;

5. Sperrprozesse bei KVP, DL und PV (nur OSK-Sperren)

 Erstellen und Senden der Sperranforderung an den AH (für die Sperrobjekte OS), bzw. an den Schlüsseleigentümer (für das Sperrobjekt Key)

 Erstellen und Senden der Sperrmitteilung an den/die sperranfordernden Teil- nehmer, ob die Sperranforderung in einen Sperrauftrag umgesetzt wurde oder nicht

 Entgegennahme der Sperrmitteilung für erteilte Sperranforderungen

 Erstellen und Senden des Sperrauftrages als Schlüsseleigentümer an den KOSE zur Sperrung eines Schlüssels

38

[Seite 47]

Anlage 27

(((eTicket Deutschland

6. Sperrprozesse beim AH (nur OSK-Sperren)

 Entgegennahme der Sperranforderung;

 Erstellen und Senden des Sperrauftrages an den KOSE (für Sperrobjekte OS und AH-Schlüssel);

 Erstellen und Senden der Sperrmitteilung an den/die sperranfordernden Teil- nehmer, ob die Sperranforderung in einen Sperrauftrag umgesetzt wurde oder nicht;

 Erstellen und Senden der Sperrnachweisanforderung an den KOSE für erteil- te OS-Sperren der Applikation

 Entgegennahme von Sperrnachweisen vom KOSE für erteilte OS-Sperren der Applikation;

 Weiterleitung von Sperrnachweisen (für OS-Sperren mit einer Applikation) an den KVP, der die Applikation ausgegeben hat.

7. Sperrprozesse bei dem KOSE (bei NM-Sperren und OSK-Sperren)

 Entgegennahme des Sperrauftrages vm KVP (NM-Sperren) bzw. AH (OS- Sperren) bzw. Schlüsseleigentümer (K-Sperren)

 Generierung bzw. Aktualisierung der Sperrlisteneinträge unter Berücksichti- gung neuer Sperraufträge bzw. der Löschung einer Sperre nach eingehendem Sperrnachweis für NM-Sperren und nach Ablauf der Gültigkeit des Sperrobjektes, bzw. nach Abgleich des Zertifikat-Sperrbestandes des AH-Trustcenters;

 Bereitstellung der auf Teilnehmer bezogenen Sperrlistendateien unter Be- rücksichtigung der Sperrlistenkonfigurationsdaten zur Abholung durch die Teilnehmer;

 Entgegennahme der Sperrlistenanforderungen von den Teilnehmern;

 Übertragung der auf Teilnehmer bezogenen Sperrlistendateien unmittelbar nach der Sperrlistenanforderung durch die Teilnehmer;

 Speicherung der Anforderungs- und Auslieferungstransaktionen für spätere Nachweise;

 Entgegennahme der Sperrnachweise von KVP bzw. DL;

 Entgegennahme der Sperrnachweisanforderung vom KVP, AH bzw. PV

 Weiterleitung von Sperrnachweisen an den beauftragenden KVP (bei Applika- tionssperren) bzw. an den AH (bei OS-Sperren zur Applikation) sowie an den zu- ständigen PV bei Sperren zu (((eBezahlberechtigungen und EFS;

 Erstellen und Senden eines Sperr-Requestes für Sperrobjekte mit Sperrgrund 39

[Seite 48]

Anlage 27

(((eTicket Deutschland

Zertifikatssperre an das AH-Trustcenter (AH-TC)

 Entgegennahme des Zertifikat-Sperrbestandes vom AH-TC und Abgleich mit den beauftragten Applikationssperren bzw. SAM-Sperren mit Sperrgrund „Zertifi- katssperre“

8. Sperrprozesse bei allen Teilnehmern

 Anforderung und Entgegennahme der für Teilnehmer vorgesehenen Sperr- listendateien bei dem KOSE;

 Speicherung der Anforderungs- und Auslieferungstransaktionen für spätere Nachweise.

 Aufspielen der Sperrlistendateien in die Hintergrundsysteme und auf Termi- nals (gilt nur für KVP und DL)

 Prüfung aller gelesenen NM gegen die Sperrliste_NM und Sperrliste_OS und Sperrung (Markierung) des Sperrobjektes auf dem NM bei Sperrlistenein- trag mit Erzeugung des Sperrnachweises, der durch das NM signiert ist (gilt nur für KVP und DL)

 Prüfung aller gelesenen NM gegen die Sperrliste_K und ggf. Abweisung ohne Erzeugung eines Sperrnachweises (gilt nur für KVP und DL)

 Prüfung aller in den Hintergrundsystemen bearbeiteten Sperrobjekte gegen die die Sperrliste_K und ggf. Abweisung des Objektes bei Sperrlisteneintrag

9. Bei der Durchführung der Sperrprozesse haben die Teilnehmer die nachfolgend ge- nannten Zeitvorgaben einzuhalten:

40

[Seite 49]

Anlage 27

(((eTicket Deutschland

41

[Seite 50]

Anlage 27

(((eTicket Deutschland

Für die zeitgerechte Auftragserteilung und Gültigkeit von temporären Sperren, ist der KVP verantwortlich, der die Berechtigung ausgegeben hat, zu der eine temporäre Sperrung erteilt wird. Er definiert die Regeln für die Handhabung der temporären Sper- ren in den Terminals.

§ 5 Entsperrprozesse

Im Rahmen des Sperrsystems des (((eTicket-Deutschland fallen folgende Entsperrprozesse an, die von den Teilnehmern nach Maßgabe dieses § 5 durchzuführen sind:

1. Entsperrprozesse bei dem KVP

 Entgegennahme der Sperraufhebungsmeldung durch die Sperrannahmestelle;

 Entsperrung des Sperrobjektes auf dem NM und Erzeugung des Entsperr- nachweises, der durch das NM signiert ist; bei Vorsprache des Nutzers bzw. des Kunden bei dem KVP unter Vorlage des NM, sofern auf dem NM eine Sperre (Markierung) erfolgt ist, der Sperrgrund jedoch entfallen ist; Eine Entsperrung von Sperrobjekten auf dem NM, die mit dem Sperrgrund „Zerti- fikatssperre“ gesperrt wurden, darf nicht durchgeführt werden.

 Weiterleitung von Entsperrnachweisen an den sperranfordern- den/sperraufhebungsanfordernden Teilnehmer und den zuständigen PV (im Falle der Entsperrung einer Berechtigung) bzw. an den AH (im Falle der Entsperrung einer Applikation; nur Option)

2. Entsperrprozesse bei KVP, DL, PV, AH

42

[Seite 51]

Anlage 27

(((eTicket Deutschland

 Entgegennahme von Entsperrnachweisen durch den sperranfordernden/ sperrsperrfreigebenden Teilnehmer, den zuständigen PV (immer im Falle der Entsperrung einer Berechtigung) bzw. den AH (im Falle der Entsperrung einer Applikation; nur Option)

3. Bei der Durchführung der Entsperrprozesse haben die Teilnehmer die nachfolgend genannten Zeitvorgaben einzuhalten:

43

[Seite 52]

Anlage 27

(((eTicket Deutschland

§ 6 Sperrfreigabeprozesse

Im Rahmen des Sperrsystems des (((eTicket-Deutschland fallen folgende Sperrfreigabepro- zesse an, die von den Teilnehmern nach Maßgabe dieses § 6 durchzuführen sind:

1. Sperrfreigabeprozesse bei dem KVP (nur bei NM-Sperren)

 Entgegennahme der Sperraufhebungsmeldung durch die Sperrannahmestelle;

 Erstellen und Senden der Sperraufhebungsanforderung an den KVP

 Entgegennahme der Sperraufhebungsanforderung vom Teilnehmer;

 Erstellung und Senden des Sperrfreigabeauftrages an den KOSE, sofern auf dem NM noch keine Sperre (Markierung) erfolgt, der Sperrgrund jedoch entfallen ist;

 Erstellung und Senden der Sperrfreigabemitteilung an den/die freigabeanfor- dernden Teilnehmer mit dem Ergebnis der Entscheidung zur Sperraufhebungsan- forderung.

2. Sperrfreigabeprozesse bei DL bzw. PV und VDV-ETS (NM-Sperren)

 Erstellung und Senden der Sperraufhebungsanforderung an den KVP

 Entgegennahme der Sperrfreigabemitteilung für erteilte Sperraufhebungsan- forderungen mit der Information über das Ergebnis der Entscheidung zur Sper- raufhebungsanforderung.

3. Sperrfreigabeprozesse bei KVP, DL und PV (nur OS-Sperren)

 Erstellung und Senden der Sperraufhebungsanforderung an den AH (VDV- ETS) ;

 Entgegennahme der Sperrfreigabemitteilung für erteilte Sperraufhebungsan- forderungen mit der Information über das Ergebnis der Entscheidung zur Sper- raufhebungsanforderung. 

4. Sperrfreigabeprozesse bei KVP, DL und PV (nur K-Sperren)

 Erstellung und Senden des Sperrfreigabeauftrages an den KOSE, nachdem der Schlüssel aus dem SAM gelöscht wurde

5. Sperrfreigabeprozesse beim AH(nur bei OSK-Sperren)

 Entgegennahme der Sperraufhebungsanforderung für OS-Sperrobjekte;

 Erstellung und Senden des Sperrfreigabeauftrages an den KOSE, sofern der Sperrgrund entfallen ist;

 Erstellung und Senden der Sperrfreigabemitteilung an den/die freigabeanfor-

44

[Seite 53]

Anlage 27

(((eTicket Deutschland

dernden Teilnehmer, dass die Sperraufhebungsanforderung für eine OS-Sperre zu einer Sperrfreigabe geführt hat oder nicht.

6. Sperrfreigabeprozesse bei dem KOSE (bei NM-Sperren und OSK-Sperren)

 Entgegennahme des Sperrfreigabeauftrages von dem KVP (NM-Sperren) bzw. dem AH (OS-Sperren), bzw. dem Schlüsseleigentümer (K-Sperren);

 Generierung bzw. Aktualisierung der Sperrlisteneinträge unter Berücksichti- gung neuer Sperrfreigabeaufträge (= Löschung des betreffenden Sperrlistenein- trages).

7. Bei der Durchführung der Sperrfreigabeprozesse haben die Teilnehmer die nachfol- gend genannten Zeitvorgaben einzuhalten:

45

[Seite 54]

Anlage 27

(((eTicket Deutschland

genommenen Sperrfreigabeauf- träge

§ 7 Sperrgründe

1. Ein Sperrgrund liegt immer dann vor, wenn die der VDV-ETS oder einem Teilnehmer vorliegenden Informationen die Annahme rechtfertigen, dass einem Teilnehmer, ei- nem Nutzer, einem Kunden, der VDV-ETS oder dem (((eTicket-Deutschland ein ma- terieller oder ein immaterieller Schaden entstehen würde, wenn nicht unverzüglich ein Sperrauftrag erteilt werden würde.

2. Im Zusammenhang mit NM-Sperren besteht insbesondere ein Sperrgrund, wenn:

 das Zertifikat der Applikation auf dem Nutzermedium von dem AH gesperrt wor- den ist (die Sperranforderung des AH (VDV-ETS) muss vom KVP in einen Sper- rauftrag umgesetzt werden), oder

 das Nutzermedium als defekt, gestohlen oder als abhanden gekommen gemeldet wurde, oder

 der Kunde seinen Zahlungspflichten gegenüber dem KVP nicht oder nicht voll- ständig nachgekommen ist oder

 der begründete Verdacht besteht, dass ein Nutzermedium oder der Inhalt eines Nutzermediums (Applikation, Berechtigung) gefälscht oder manipuliert wurde, o- der

 das Nutzermedium bei Beendigung des Kundenvertrages vor Ablauf der Gültigkeit der im Nutzermedium gespeicherten Berechtigungen nicht zurückgegeben wurde, oder

 ein NM elektronisch nicht lesbar ist und das NM nicht zurückgegeben wurde, oder

 die Prüfungen zu Transaktionen der (((eBezahlberechtigungen bezüglich Voll- ständigkeit, Unverfälschtheit und Lückenlosigkeit Unregelmäßigkeiten aufweisen.

Weitere Sperrgründe können in Abstimmung mit der VDV-KA-KG festgelegt werden.

3. Im Zusammenhang mit OSK-Sperren besteht ein Sperrgrund, wenn:

 ein Teilnehmer (in der Rolle des KVP) seine Zahlungsverpflichtungen nicht nur unerheblich nicht erfüllt hat, oder

 ein Teilnehmer seine sonstigen Verpflichtungen aus dem (((eTicket- Teilnahmevertrag nicht nur unerheblich nicht erfüllt hat, oder

 ein Hardware-SAM als gestohlen oder abhanden gekommen gemeldet wurde, oder

46

[Seite 55]

Anlage 27

(((eTicket Deutschland

 ein Terminal mit einem Hardware-SAM als gestohlen oder abhanden gekommen gemeldet wurde, oder

 ein Teilnehmer aus dem Clearingvertrag ausgeschieden ist, oder

 mit einem Teilnehmer kein (((eTicket-Teilnahmevertrag (mehr) besteht, oder

 ein Schlüssel eines Teilnehmers gelöscht werden soll (der Sperrgrund entfällt, wenn die Schlüssel aus allen relevanten SAMs entfernt wurden, zu diesem Zeit- punkt ist die Sperraufhebungsanforderung zu erteilen), oder

 das Sicherheitsmanagement der VDV-ETS die Kompromittierung oder den Miss- brauch eines Schlüssels/eines Zertifikates festgestellt hat oder der begründete Verdacht einer Kompromittierung oder eines Missbrauches besteht, oder

 die Transaktionen, die von einem Teilnehmer eingereicht werden, Unregelmäßig- keiten aufweisen.

§ 8 Konfigurationsprozesse

Sperrlisten werden bezogen auf Teilnehmer und bezogen auf (((eTicket-Produkte erstellt.

Im Rahmen des Sperrsystems des (((eTicket-Deutschland fallen folgende Konfigurationspro- zesse an, die von den Teilnehmern in der Rolle eines PV und KOSE nach Maßgabe dieses § 8 durchzuführen sind:

1. Konfigurationsprozesse bei dem PV:

 Erstellung und Pflege der Konfigurationsdaten zum Produkt (DL, die ausge- gebene Berechtigungen zum Produkt des PV akzeptieren; KVP, die Berechtigun- gen zum Produkt des PV akzeptieren oder selbst Berechtigungen dazu ausge- ben);

 Weiterleitung der Konfigurationsdaten an den KOSE. Dies können Neuauf- nahmen oder Ergänzungen bzw. Löschungen zu bestehenden Teilnehmern aus dem Verantwortungsbereich des PV sein.

 Erstellen und Senden der Sperrinformationsanforderung an den KOSE

 Entgegennahme der Sperrinformation vom KOSE

2. Konfigurationsprozesse bei dem KOSE:

 Entgegennahme der Konfigurationsdaten von dem PV;

 Generierung bzw. Aktualisierung der Sperrlistenkonfigurationsdatei;

 Speicherung der Konfigurationsdatenentgegennahme für spätere Nachwei-

47

[Seite 56]

Anlage 27

(((eTicket Deutschland

se.

 Entgegennahme der Sperrinformationsanforderung von dem PV bzw. AH

 Bereitstellung der Sperrinformation

3. Konfigurationsprozesse beim AH (VDV-ETS)

 Erstellen und Senden der Sperrinformationsanforderung an den KOSE

 Entgegennahme der Sperrinformation vom KOSE

4. Bei der Durchführung der Konfigurationsprozesse haben die Teilnehmer die nachfol- gend genannten Zeitvorgaben einzuhalten:

48

[Seite 57]

Anlage 27

(((eTicket Deutschland

Kapitel 6: Datenschutz-Grundsätze

1. Die Teilnehmer sind auch gegenüber der VDV-ETS verpflichtet, die in diesem Kapitel festgelegten Datenschutz-Grundsätze einzuhalten. Im Falle einer nicht-anonymen Nutzung des NM haben die Teilnehmer sicherzustellen, dass die für die Abrechnung erforderlichen Daten, die Stammdaten der Nutzer und Kunden von den ansonsten über die Fahrt erhobenen Daten den datenschutzrechtlichen Vorschriften entspre- chend zugriffssicher getrennt gespeichert und verarbeitet werden. Die zu Zwecken der Statistik, zu Planungszwecken und zur Optimierung von Reiseangeboten dienen- den Daten dürfen nur ohne jeden Bezug zur Person des Nutzers bzw. des Kunden gespeichert und weiterverarbeitet werden. Das Erstellen personenbezogener Bewe- gungsprofile ist unzulässig. Die Kundenstammdaten und die Rechnungsdaten dürfen ausschließlich zum Zwecke der Abrechnung oder Reklamationsbearbeitung zusam- mengeführt werden.

2. Zwischen den Teilnehmern dürfen nur pseudonyme Daten (auf die (((eBezahlberech- tigungen bezogene Daten) zu Abrechnungszwecken ausgetauscht werden. Bei nicht- anonymer Nutzung des NM darf grundsätzlich nur der KVP, der mit dem Kunden den Kundenvertrag geschlossen hat, mit Einverständnis des Kunden auf die Kundeniden- tität zurückgreifen. Nur auf ausdrücklichen Wunsch und Veranlassung des Kunden dürfen auch andere KVP´s auf die Kundendaten zugreifen.

3. Jeder Teilnehmer hat sicherzustellen, dass auf personenbezogene Daten, die auf dem NM gespeichert sind, ein autorisiertes Terminal nur nach PIN-Eingabe oder asymmetrischer Authentisierung zugreifen kann. Auf im Hintergrundsystem (HGS) gespeicherte Daten ist autorisierten Mitarbeitern der Teilnehmer im Rahmen ihrer Tä- tigkeit im erforderlichen Umfang der Zugriff ohne PIN-Eingabe oder asymmetrischer Authentisierung zu ermöglichen. Für Auskünfte aus dem HGS, die an kundenbedien- ten Terminals erteilt werden, ist eine PIN-Autorisierung sicherzustellen.

4. Die Teilnehmer haben dafür Sorge zu tragen,

• dass Fehlermeldungen an Kundenschnittstellen zu (((eTicket- Systemkomponenten nicht so signalisiert werden, dass die Betroffenen öffent- lich diskreditiert werden können

und,

• dass Fehlermeldungen an der Kundenschnittstelle nicht den ursächlichen Grund für die Fehlermeldung, bzw. die Sperrung (z.B. Säumnis, Vertragsbe- endigung, Diebstahl, u.a.) offenbaren können.

5. Soweit nicht gesetzliche Aufbewahrungsfristen für personenbezogene oder pseudo- nyme Abrechnungsdaten bestehen, oder es zur Bearbeitung von Reklamationen oder zur Geltendmachung von Rechten erforderlich ist, haben die Teilnehmer alle bei einer Fahrt entstandenen personenbezogenen oder pseudonymen Daten nach Wegfall des Aufbewahrungszwecks unverzüglich zu löschen oder vollständig zu anonymisieren. Aufstellungen von Einzelfahrten dürfen nur so lange aufbewahrt werden, wie sie zur Verfolgung von Reklamationen erforderlich sind.

49

[Seite 58]

Anlage 27

(((eTicket Deutschland

Gilt nur für Teilnehmer in der Rolle des KVP

6. Die von der VDV-ETS zur Verfügung gestellten Muster-Kundenverträge nebst Allge- meinen Geschäftsbedingungen (Anlage 3 zum (((eTicket-Teilnahmevertrag) sind datenschutzrechtlich geprüft und mit Datenschutzbeauftragten abgestimmt worden. Der Teilnehmer ist berechtigt, die Klauseln des Mustervertrages für eigene Zwecke zu verwenden. Die Teilnehmer sind verpflichtet, den Kunden über die Erhebung, Spei- cherung und Verarbeitung seiner Daten sowie über die dem Kunden zustehenden Widerspruchsrechte sowie Folgen des Widerspruchs zu informieren. Die VDV-ETS stellt dazu die in der Anlage 4 zum (((eTicket-Teilnahmevertrag beigefügten Mus- ter-Datenschutzhinweise zur Verfügung, welche der Teilnehmer dem Kunden vor der erstmaligen Bereitstellung eines (((eTicket-Produktes aushändigen kann.

7. Jeder Nutzer und jeder Kunde hat einen gesetzlichen Anspruch darauf zu erfahren, welche personenbezogenen Daten auf seinem NM und im Hintergrundsystem des KVP gespeichert sind und zu welchen Zwecken diese Daten verarbeitet werden. Die Teilnehmer haben dafür Sorge zu tragen, dass die zur Wahrnehmung dieses Aus- kunftsanspruchs erforderlichen technischen Geräte oder Einrichtungen in angemes- senem Umfang zum unentgeltlichen Gebrauch zur Verfügung stehen.

8. Die Teilnehmer sind verpflichtet, jedem Kunden bei Abschluss des Kundenvertrages die Möglichkeit zu geben, sich schriftlich dazu zu erklären, ob er der Übermittlung und Nutzung personenbezogener Daten zu Zwecken der Werbung und der Markt- und Meinungsforschung zustimmen möchte oder nicht. Die Teilnehmer haben darüber hinaus sicherzustellen, dass alle in die Verarbeitung personenbezogener Daten invol- vierte Stellen diese Beschränkung beachten.

9. Die Teilnehmer haben jeden Kunden darüber aufzuklären, welche Möglichkeiten der anonymen Bezahlung und Nutzung des NM zur Verfügung stehen. Es ist zumindest eine anonym nutzbare Form der Fahrberechtigung bereit zu stellen. Diese muss nicht zwingend in elektronischer Form vorliegen, sondern kann auch im herkömmlichen Papierfahrschein gesehen werden.

10. Die Teilnehmer haben dafür Sorge zu tragen, dass

• bei der Nutzung von Terminals für die bargeldlose Zahlung Unbefugte daran gehindert werden, die Eingabedaten, vor allem die Authentisierungsdaten zur Kenntnis zu nehmen und
• Fahrgäste in angemessener Weise die Möglichkeit erhalten, den Inhalt des NM auslesen zu können (§ 6c Abs. 2 BDSG).
• das Personal des Teilnehmers, welcher personenbezogene Daten erhebt, verarbeitet oder nutzt, zur Einhaltung der anwendbaren datenschutzrechtli- chen Anforderungen, insbesondere auf das Datengeheimnis nach § 5 BDSG, zu verpflichten.

11. Im Rahmen einer Vorabkontrolle (§ 4d Abs. 5, 6 BDSG) haben die betrieblichen Da- tenschutzbeauftragten der Teilnehmer zu prüfen, ob die unter Ziff. 1. – 10. beschrie- benen Anforderungen erfüllt werden und ob die in der VDV-KA-Dokumentation spezi- fizierten technischen und organisatorischen Maßnahmen zur Absicherung der Nut- zermedien gegen unbefugte Datenzugriffe (z. B. beim Zugriff durch Kontrollpersonal, bei Verlust) zuverlässig umgesetzt worden sind. Die Vorabkontrolle ist für Revisions- zwecke (z. B. durch die zuständigen Datenschutzkontrollbehörden) zu dokumentie- ren.

50

[Seite 59]

Anlage 27

(((eTicket Deutschland

Kapitel 7: Clearingvertrag

Die Interoperabilität des (((eTicket-Deutschland setzt eine vertragliche Struktur voraus, auf deren Grundlage ein Forderungsausgleich zwischen den Teilnehmern stattfinden kann. Der Forderungsausgleich soll auf der Grundlage eines zwischen den Teilnehmern abzuschlie- ßenden Clearingvertrags erfolgen, sofern und soweit zwischen den von einem Forderungs- ausgleich betroffenen Teilnehmern nicht bereits anderweitig (z.B. im Rahmen von Einnah- menaufteilungsverträgen) eine abschließende Regelung hinsichtlich des Forderungsaus- gleichs besteht. Zum derzeitigen Zeitpunkt besteht mangels konkretem Bedarf noch kein zentrales Clearing-System. Demzufolge liegt auch noch kein abschlussreifer Entwurf eines Clearingvertrags vor. Die Entwicklung und der Abschluss des finalen Clearingvertrags soll nach Maßgabe der folgenden Regelungen erfolgen:

1. Es bleibt dem Teilnehmer sowohl vor, als auch nach dem Vorhandensein einer zent- ralen Clearingstelle freigestellt, selbständig mit anderen Teilnehmern am interoperab- len Betrieb durch dezentrale bilaterale oder multilaterale Vereinbarungen den Forde- rungsausgleich selbst zu regeln. Derartige Regelungen werden gegenüber dem Ver- trag über das zentrale Clearing des (((eTicket-Deutschland immer vorrangig gelten.

2. Die Parteien stimmen darin überein, dass der Anschluss an eine zentrale Clearing- stelle als Rückfallebene im interoperablen Betrieb erforderlich ist, um Forderungsaus- fälle bei einzelnen Teilnehmern im Falle des Nichtbestehens dezentraler Vereinba- rungen ausschließen zu können. Es wird daher die Notwendigkeit eines generellen Anschlusses an die zentrale Clearingstelle gesehen. Der Teilnehmer erklärt seine grundsätzliche Absicht, zum Zeitpunkt der Aufnahme des interoperablen Betriebs dem Clearingvertrag beitreten zu wollen.

3. Die VDV-ETS wird einen Vorschlag für einen Clearingvertrag (nachfolgend „Clea- ringvertrag-Vorschlag“) erarbeiten, sobald die Notwendigkeit für eine zentrale Clea- ringstelle feststeht.

4. Die VDV-ETS wird den Clearingvertrag-Vorschlag sämtlichen Teilnehmern unverzüg- lich nach Fertigstellung zur Kenntnis geben. Jeder Teilnehmer hat innerhalb eines Zeitraums von 6 Monaten nach Erhalt des Clearingvertrag-Vorschlags das Recht, der VDV-ETS inhaltliche Fragen zu dem Clearingvertrag-Vorschlag zu stellen und gegen- über der VDV-ETS Änderungsanregungen zu dem Clearingvertrag-Vorschlag zu äu- ßern. Die VDV-ETS ist verpflichtet, die an sie gerichteten Fragen innerhalb eines Mo- nats nach Eingang zu beantworten und die Änderungsanregungen unter Berücksich- tigung der berechtigten Interessen aller Teilnehmer auf deren Umsetzbarkeit zu prü- fen. Die VDV-ETS wird sämtliche Änderungsanregungen, die sie für umsetzbar und sinnvoll hält, in den Clearingvertrag-Vorschlag einarbeiten und sämtlichen Teilneh- mern den dann aktuellen Stand des Clearingvertrag-Vorschlags zur Kenntnis geben.

5. Für den Fall, dass im Rahmen der Abstimmung des Clearingvertrag-Vorschlags in- nerhalb von 12 Monaten nach Bekanntmachung des Clearingvertrag-Vorschlags kei- ne Einigung zwischen den Teilnehmern erzielt werden sollte, erklären sich die Partei- en dazu bereit, ein Schlichtungsverfahren gemäß der Schlichtungsordnung der Deut- schen Institution für Schiedsgerichtsbarkeit e.V. (DIS) in der bei Einleitung des Ver- fahrens gültigen Fassung durchzuführen. Sofern innerhalb von 6 Monaten nach dem Schiedsspruch erneut keine Einigung hergestellt werden konnte, wird der streitige Sachverhalt dem Aufsichtsrat zur Entscheidung vorgelegt. Der Teilnehmer erklärt

51

[Seite 60]

Anlage 27

(((eTicket Deutschland

sich dazu bereit, das daraus hervorgehende Votum des Aufsichtsrats zu akzeptieren. Die Regelung des § 2, Abs. 6 Teilnahmevertrag bleibt hiervon unberührt.

6. Die VDV-ETS wird nach Durchführung des Verfahrens gemäß Ziffer 4 den Clearing- vertrag-Vorschlag der Teilnehmerversammlung und der Gesellschafterversammlung der VDV-ETS zur Entscheidung vorlegen. Der Clearingvertrag-Vorschlag ist ange- nommen, wenn die Gremien diesem mit einer Mehrheit von 3/4 der abgegebenen Stimmen zustimmen.

7. Der gemäß Ziffer 6 angenommene Clearingvertrag-Vorschlag (nachfolgend „verab- schiedeter Clearingvertrag“) wird den Teilnehmern in Textform bekannt gegeben.

8. Die Regelungen der Ziffer 3-7 gelten nicht für die Teilnehmer, die einen (((eTicket- Teilnahmevertrag erst nach Vorliegen des verabschiedeten Clearingvertrags ab- schließen. Diese treten dem Clearingvertrag unmittelbar durch Unterzeichnung des (((eTicket-Teilnahmevertrages bei. Die VDV-ETS wird bereits jetzt von den Teilneh- mern bevollmächtigt, in deren Namen Beitrittserklärungen von den jeweils anderen Teilnehmern entgegenzunehmen und gegenüber diesen Teilnehmern die rechtsver- bindliche Annahme der Beitrittserklärungen abzugeben. Insoweit wird die VDV-ETS vom Verbot des § 181 BGB befreit.

52

[Seite 61]

Anlage 27

(((eTicket Deutschland

Kapitel 8: KOSE-Vertrag

Im Folgenden wird der Inhalt des zwischen der VDV-ETS und dem KOSE- Dienstleister geschlossenen Werk- und Betriebsvertrags zur Kenntnis gegeben:

Vertrag über die Erstellung, Pflege und den Betrieb des zentralen Sperrlistenservices „KOSE“ und der Anwendung „Vermitt- lungsstelle“ im Rahmen des (((eTicket-Deutschland

zwischen

der

Atos Worldline GmbH Pascalstr. 19 52076 Aachen

(im Folgenden: ,,Auftragnehmer“)

und

der

VDV eTicket Service GmbH & Co. KG Hohenzollernring 103 50672 Köln

(im Folgenden: ,,Auftraggeber“)

A) Präambel

Der Auftraggeber hat gemeinsam mit technischen und kaufmännischen Beratern ei- nen interoperablen, elektronischen Fahrgeldmanagementstandard entwickelt, der auf der VDV-Kernapplikation beruht und verschiedene Ausbauvarianten umfasst (im Fol- genden: „(((eTicket-Deutschland“). Dieser soll die Fahrgäste im öffentlichen Perso- nenverkehr (im Folgenden: „ÖPV“) in Deutschland und weiteren Ländern in die Lage versetzen, unter Nutzung nur noch eines einzigen elektronischen Nutzermediums (z. B. einer Chipkarte oder eines Mobiltelefons) interoperabel und bundesweit Beförde- rungsleistungen im ÖPV bargeldlos bezahlen und Fahrberechtigungen für die Nut- zung des ÖPV erwerben zu können. Technische Basis des (((eTicket-Deutschlands ist die VDV-Kernapplikation, die den technischen Daten- und Schnittstellenstandard für die (((eTicket-Systeme vor Ort bildet und die Voraussetzung für das interoperable 53

[Seite 62]

Anlage 27

(((eTicket Deutschland

Zusammenwirken dieser Systeme ist. Wesentlicher Bestandteil des (((eTicket- Deutschlands ist das Rollenmodell der VDV-Kernapplikation. Nach diesem Rollen- modell nehmen Unternehmen, die mit dem Auftraggeber einen Vertrag über die Teil- nahme am (((eTicket-Deutschland geschlossen haben (im Folgenden: „Teilnehmer“), in den Rollen des Produktverantwortlichen, des Dienstleisters und/oder des Kunden- vertragspartners am (((eTicket-Deutschland teil.

Um eine weitreichende Akzeptanz des (((eTicket-Deutschlands bei den Teilnehmern und den Fahrgästen zu erreichen ist es notwendig, eine umfassende Sicherheit zu er- reichen. Teil des Gesamtkonzeptes des (((eTicket-Deutschlands ist daher ein Sicher- heitssystem. Zu diesem Sicherheitssystem gehört ein Sperrsystem, über das bei Vor- liegen von definierten Sperrgründen definierte Sperrobjekte im Rahmen des (((eTi- cket-Deutschlands gesperrt werden können (im Folgenden: „Sperrsystem“).

Grundlage für das Sperrsystem sind Sperrlisten, die die jeweiligen Sperrdatensätze enthalten und die den Teilnehmern und dem Auftraggeber zur Abholung zur Verfü- gung gestellt werden. Wichtigstes Element des Sperrsystems ist der zentrale Sperrlis- tenservice KOSE (im Folgenden: „KOSE“). Der KOSE übernimmt sämtliche Aufgaben und Prozesse im Zusammenhang mit dem Sperrlistenmanagement. Hierzu bedient sich der KOSE einer speziell zu diesem Zweck zu erstellenden Software (im Folgen- den: Anwendung „KOSES“).

Verkehrsunternehmen und –verbünde sind sich darüber einig, dass der KOSE zentral organisiert und beim Applikationsherausgeber angesiedelt sein soll, weil die Zuteilung von Teilnehmern zu dezentralen Sperrlistenservices unnötig hohen Aufwand an die Kommunikation erzeugt hätte und daher wirtschaftlich Erwägungen für die Zentralisie- rung sprachen.

Zur Unterstützung der im Rahmen des (((eTicket-Deutschlands erforderlichen Kom- munikation zwischen den Teilnehmern soll zudem ein interoperables Netzwerk (im Folgenden: „ION“) zwischen den Teilnehmern geschaffen werden. Zu diesem Zweck soll eine Software erstellt werden, über die die Teilnehmer Daten in unterschiedlichen Datenformaten austauschen können (im Folgenden: „Anwendung Vermittlungsstel- le“). Für die Kommunikation müssen alle Teilnehmer im ION adressiert werden kön- nen. Die Verwaltung der erforderlichen Netzadressen und ihre Zuordnung zu den Or- ganisations_IDs der Teilnehmer sollen zentral erfolgen. Die Anwendung „Vermitt- lungsstelle“ muss die Nachrichten aller Teilnehmer entgegennehmen können und auf der Grundlage dieses Adressregisters die Vermittlung der Nachrichten aller Teilneh- mer übernehmen bzw. diese zukünftig auch an weitere Vermittlungsstellen im ION weitervermitteln.

Die Anwendung „KOSES“ und die Anwendung „Vermittlungsstelle“ sollen auf einem zentralen Rechenzentrum betrieben werden, an das sämtliche Teilnehmer und der Auftraggeber im Wege einer Internet-Verbindung angebunden sind (im Folgenden: „Anbindung“).

Der Auftragnehmer übernimmt nach Maßgabe dieses Vertrags die Funktion des KOSE und wird in dieser Funktion mit der Planung, Erstellung, Lieferung und fortlau- fenden Pflege und Weiterentwicklung der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ sowie deren Installation und Betrieb in einem eigenem Rechen- zentrum beauftragt. Er wird sein Rechenzentrum für die Anbindung des Auftragge- bers und sämtlicher Teilnehmer verfügbar halten.

Dem Auftragnehmer ist bekannt, dass der Auftraggeber den Vertrag im Auftrag der 54

[Seite 63]

Anlage 27

(((eTicket Deutschland

Teilnehmer schließt. Der Auftraggeber ist jedoch alleiniger Vertragspartner des Auf- tragnehmers. Die Teilnehmer werden aus diesem Vertrag daher nicht verpflichtet.

Dem Auftragnehmer ist bekannt, dass er mit der Übernahme der Funktion des KOSE eine maßgebliche Verantwortung für den Schutz des Auftraggebers und sämtlicher Teilnehmer vor dem Missbrauch des (((eTicket-Deutschland übernimmt. Ihm ist ferner bekannt, dass die Verletzung von Vertragspflichten zu erheblichen wirtschaftlichen Schäden bei dem Auftraggeber und den Teilnehmern führen kann. Die ordnungsge- mäße Erfüllung der vertraglichen Pflichten durch den Auftragnehmer liegt somit nicht nur im unmittelbaren Interesse des Auftraggebers, sondern auch im unmittelbaren In- teresse sämtlicher Teilnehmer.

Die Entwicklung und der Aufbau des KOSE und der Vermittlungsstelle sind Bestand- teil des vom BMVBS geförderten Forschungsprojektes „Rules & Regulations-Pilot“. Der Betrieb der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ wird jedenfalls bis Mitte 2011 als Fortsetzung des Erprobungsbetriebs zur Beschaffung neuer Erkenntnisse und Daten aus dem Betrieb der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ fortgeführt und so lange mit Mitteln des BMVBS fi- nanziert. Im Anschluss daran schließt sich unmittelbar der endgültige Wirkbetrieb der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ an, der voraussichtlich ausschließlich aus Mitteln des Auftraggebers finanziert wird.

Dies vorausgeschickt vereinbaren die Parteien folgendes:

B) Vertragsgegenstand

Gegenstand dieses Vertrags ist die Planung und Erstellung der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ durch den Auftragnehmer nach Maßgabe der Bestimmungen im Abschnitt C) dieses Vertrags, die fortlaufende Pflege und Wei- terentwicklung der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ durch den Auftragnehmer nach Maßgabe der Bestimmungen im Abschnitt D) dieses Vertrags sowie die Installation und der Betrieb der Anwendung „KOSES“ und der An- wendung „Vermittlungsstelle“ in einem eigenen Rechenzentrum des Auftragnehmers (im Folgenden: „Rechenzentrumsbetrieb“) nach Maßgabe der Bestimmungen im Ab- schnitt E) dieses Vertrags. Der Abschnitt F) dieses Vertrages enthält allgemeine Best- immungen, die für alle Leistungen gelten, die der Auftragnehmer auf der Grundlage dieses Vertrages zu erbringen hat.

C) Besondere Bestimmungen für die Planung und Erstellung der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“

§ 1 Planungsphase

(1) Der Auftragnehmer ist nach Maßgabe der folgenden Absätze zur Erstellung eines Pflichtenhefts (im Folgenden: „Pflichtenheft“) verpflichtet, auf dessen Grundlage die Anwendung „KOSES“ und die Anwendung „Vermittlungsstelle“ erstellt werden soll.

(2) Das Pflichtenheft ist auf Basis der Rahmenbedingungen (Teil A der Verdingungsun- terlagen), des Lastenhefts (Teil B der Verdingungsunterlagen), des Kriterienkatalogs 55

[Seite 64]

Anlage 27

(((eTicket Deutschland

(Teil C der Verdingungsunterlagen), des Angebots des Auftragnehmers und der VDV KA-Dokumentation zu erstellen. Die Rahmenbedingungen sind dem Vertrag als An- lage 1a, das Lastenheft KOSES als Anlage 1b, das Lastenheft Vermittlungsstelle als Anlage 1c, der Kriterienkatalog als Anlage 1d und das Angebot des Auftragnehmers als Anlage 2 beigefügt. Die VDV KA-Dokumentation ist in Anlage 3 zu diesem Ver- trag beschrieben. Die in Anlage 1a, 1b, 1c und 1d beigefügten Dokumente werden nachfolgend gemeinsam auch als „Verdingungsunterlagen“ bezeichnet.

Die vorgenannten Dokumente gelten für die Erstellung des Pflichtenhefts in der fol- genden Reihenfolge, es sei denn, die Parteien haben schriftlich etwas anderes ver- einbart:

a) VDV KA-Dokumentation (Anlage 3) b) Lastenhefte (Anlage 1b+c) c) Kriterienkatalog (Wertungsmatrix Qualität / Preis, Anlage 1d) d) Rahmenbedingungen (Anlage 1a) e) Angebot des Auftragnehmers (Anlage 2)

Bei der Erstellung des Pflichtenhefts hat der Auftragnehmer zudem die in der Pla- nungsphase zusätzlich gewonnenen Erkenntnisse zu berücksichtigen.

(3) Der Auftragnehmer berät und unterstützt den Auftraggeber kontinuierlich hinsichtlich der Ermittlung der für den Sollzustand der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ wesentlichen Informationen. Der Auftragnehmer wird die Ergeb- nisse aus Projektbesprechungen gemäß § 17 Absatz 5 und aus sonstigen Bespre- chungen, die er mit dem Auftraggeber und/oder mit seinen technischen und kauf- männischen Beratern im Zusammenhang mit der Erstellung des Pflichtenhefts wäh- rend der Planungsphase führt, sowie sonstige von dem Auftragnehmer erhaltene diesbezügliche Informationen schriftlich aufzeichnen. Diese Aufzeichnungen werden nach jeweiliger schriftlicher Bestätigung durch den Auftraggeber diesem Vertrag als Anlage 4 beigefügt und sind bei der Erstellung des Pflichtenhefts zu berücksichtigen.

(4) Der Auftragnehmer ist verpflichtet, auf Grundlage der jeweils verfügbaren Informatio- nen einschließlich der Erkenntnisse aus Parallelprojekten im Rahmen des (((eTicket- Deutschlands die Anforderungen des Auftraggebers an die Anwendung „KOSES“ und an die Anwendung „Vermittlungsstelle“ auf Logik und Durchführbarkeit zu überprüfen. Erkennt der Auftragnehmer, dass die vorgesehene Konfiguration der Anwendung „KOSES“ und/oder der Anwendung „Vermittlungsstelle“ im Hinblick auf die Funktio- nen, Leistungsmerkmale und Programmeigenschaften modifiziert werden muss, wird er den Auftraggeber hierauf unverzüglich hinweisen und ihm Alternativvorschläge un- terbreiten. Die gleiche Hinweispflicht besteht, wenn der Auftragnehmer erkennt, dass Informationen oder Anforderungen des Auftraggebers (insbesondere Vorgaben der VDV KA-Dokumentation; Anlage 3) fehlerhaft, unvollständig, nicht eindeutig oder ob- jektiv zur Ausführung nicht geeignet sind. Der Auftraggeber wird über eventuelle Än- derungen, die sich aufgrund solcher Hinweise für die Erarbeitung und den Inhalt des Pflichtenhefts ergeben, innerhalb einer angemessenen Überlegungsfrist entscheiden. Der Auftraggeber wird seinerseits den Auftragnehmer unterrichten, wenn sich für ihn Abweichungen gegenüber den als Anlage 1a, 1b, 1c und 1d beigefügten Verdin- gungsunterlagen – insbesondere dem Lastenheft-, der als Anlage 3 beigefügten VDV KA-Dokumentation oder den als Anlage 4 beigefügten Aufzeichnungen oder den sonstigen zwischen den Vertragsparteien abgestimmten Anforderungen abzeichnen.

(5) Der Auftragnehmer ist verpflichtet, für den Auftraggeber vorteilhafte, für den Auftrag- nehmer erkennbar gewordene Änderungen der Anforderungen des Auftraggebers an 56

[Seite 65]

Anlage 27

(((eTicket Deutschland

die Anwendung „KOSES“ und/oder an die Anwendung „Vermittlungsstelle“ vorzu- schlagen (im Folgenden: „Verbesserungsvorschläge“). Der Auftraggeber hat über Verbesserungsvorschläge jeweils innerhalb einer angemessenen Überlegungsfrist zu entscheiden und dem Auftragnehmer mitzuteilen, ob die Erstellung des Pflichtenhef- tes mit oder ohne Umsetzung des betreffenden Verbesserungsvorschlags erfolgen soll.

(6) Das Pflichtenheft hat die bei der Erstellung der Anwendung „KOSES“ und der An- wendung „Vermittlungsstelle“ von dem Auftragnehmer zu erbringenden Leistungen detailliert und umfassend zu beschreiben. Das Pflichtenheft hat insbesondere die fol- genden Bestandteile zu enthalten:

 Detaillierte Beschreibung der Anforderungen, die zur Erfüllung der Bedürfnisse des Auftraggebers erforderlich sind,  detaillierte Beschreibung der einzelnen Funktionen, Leistungsmerkmale und Pro- grammeigenschaften der Anwendung „KOSES“ und der Anwendung „Vermitt- lungsstelle“,  Festlegung der speziellen Anforderungen an die Entwicklungsumgebung und an die technische Produktumgebung (Software, Hardware, Schnittstellen) sowie  Informationen zu sonstigen Eigenschaften der Anwendung „KOSES“ und der An- wendung „Vermittlungsstelle“ (u. a. Pflegefreundlichkeit, Übertragbarkeit).

Im Rahmen des Pflichtenhefts hat auch eine detaillierte Terminplanung zu erfolgen, die die einzelnen Schritte der Erstellung der Anwendung „KOSES“ und der Anwen- dung „Vermittlungsstelle“ bis zur abnahmefähigen Fertigstellung und zur anschlie- ßenden Installation der Anwendung „KOSES“ und der Anwendung „Vermittlungsstel- le“ auf dem Rechenzentrum des Auftragnehmers enthält.

(7) Der Auftragnehmer hat einen vollständigen Entwurf des Pflichtenhefts innerhalb von zwölf Wochen nach Abschluss dieses Vertrags zu erstellen und an den Auftraggeber zu übergeben. Der Auftraggeber prüft den vom Auftragnehmer übergebenen Entwurf des Pflichtenhefts innerhalb einer angemessenen Prüfungsfrist und teilt dem Auftrag- nehmer etwaige Änderungs- und Ergänzungswünsche schriftlich mit. Nach Überarbei- tung des Entwurfs durch den Auftragnehmer, der innerhalb von vier Wochen nach Mitteilung des Auftraggebers i. S. v. Satz 2 zu erfolgen hat, legt dieser dem Auftrag- geber den aus seiner Sicht endgültigen Entwurf des Pflichtenhefts zur abschließen- den Überprüfung und Verabschiedung vor. Sofern der Auftraggeber keine Änderungs- oder Ergänzungswünsche an dem überarbeiteten Entwurf hat, verabschiedet er den Inhalt des Pflichtenhefts durch schriftliche Anzeige (im Folgenden: „Verabschie- dungsanzeige“) an den Auftragnehmer innerhalb einer angemessenen Frist. In dieser Fassung bildet das Pflichtenheft die Grundlage für die Erstellung der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“. Das Pflichtenheft wird diesem Vertrag nachträglich als Anlage 5 beigefügt. Die Vertragsparteien stellen klar, dass es sich bei der Verabschiedungsanzeige nicht um eine (Teil-)Abnahme handelt.

(8) Der Auftraggeber erhält mit Zugang der Verabschiedungsanzeige an den Auftrag- nehmer ein Nutzungsrecht an dem erstellten Pflichtenheft gemäß § 6 Absatz 1.

§ 2 Realisierungsphase

(1) Der Auftragnehmer ist verpflichtet, auf der Basis des Pflichtenhefts eine den allge- mein anerkannten Regelungen ordnungsgemäßer Berufsausübung entsprechende voll funktionsfähige Anwendung „KOSES“ und voll funktionsfähige Anwendung „Ver- 57

[Seite 66]

Anlage 27

(((eTicket Deutschland

mittlungsstelle“ zu erstellen.

(2) Der Auftragnehmer unterrichtet den Auftraggeber im Abstand von zwei Wochen und darüber hinaus jederzeit auf dessen Anforderung über den Stand der Programmie- rungsarbeiten und die Einhaltung der Anforderungen an die Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“. Sich abzeichnende Verzögerungen und Än- derungserfordernisse werden dem Auftraggeber unverzüglich mitgeteilt. § 1 Absatz 4 und Absatz 5 finden entsprechende Anwendung.

§ 3 Änderungsverlangen

(1) Solange der Auftragnehmer dem Auftraggeber nicht die voll funktionsfähige Anwen- dung „KOSES“ gemäß § 4 übergeben hat, kann der Auftraggeber nach Maßgabe der nachfolgenden Bestimmungen jederzeit schriftlich Änderungen gegenüber dem Pflichtenheft oder den sonstigen abgestimmten Anforderungen an die Anwendung „KOSES“ verlangen (im Folgenden: „Änderungsverlangen“).

(2) Der Auftragnehmer wird jeweils unverzüglich mit der Prüfung des Änderungsverlan- gens beginnen. Der Auftragnehmer hat gegebenenfalls innerhalb von einer Woche nach Zugang des jeweiligen Änderungsverlangens gegenüber dem Auftraggeber schriftlich darzulegen und zu begründen, dass ihm die Umsetzung des betreffenden Änderungsverlangens unzumutbar ist bzw. hierfür die Anpassung der Regelungen dieses Vertrags erforderlich ist.

(3) Eine Anpassung der Regelungen dieses Vertrags ist erforderlich, sofern die Umset- zung eines Änderungsverlangens erhebliche Auswirkungen auf das vertragliche Leis- tungsgefüge (insbesondere Fristen oder die Vergütung - in Bezug auf die Vergütung sind ein Änderungsaufwand pro Einzelfall bis 5 Mannstunden; insgesamt pro Jahr bis zu 5 Manntage als vom Angebot umfasst anzusehen) hat. In diesem Fall werden die Parteien unverzüglich eine schriftliche Anpassung der vertraglichen Regelungen unter Zugrundelegung der in Ziffer 1. b) der Anlage 9 für die Durchführung von Änderungs- verlangen vorgesehenen Vergütungssätze vornehmen.

(4) Ist das Änderungsverlangen dem Auftragnehmer zumutbar und kommt eine einver- nehmliche Anpassung der Regelungen dieses Vertrags nicht innerhalb von zwei Wo- chen zustande, nachdem der Auftragnehmer die Erforderlichkeit einer Anpassung der Regelungen dieses Vertrags zu Recht geltend gemacht hat, so kann der Auftraggeber die Umsetzung des Änderungsverlangens gleichwohl verlangen. Die Vergütung wird in diesem Fall unter Zugrundelegung der in Ziffer 1. b) der Anlage 9 für die Durchfüh- rung von Änderungsverlangen vorgesehenen Vergütungssätze angemessen erhöht. Die Fristen des in dem Pflichtenheft enthaltenen Terminplans bzw. nach diesem Ver- trag verlängern sich in diesem Fall um die Zahl der Tage, an denen infolge des Ände- rungsverlangens die Arbeiten unterbrochen waren, und verschieben sich im Übrigen angemessen.

(5) Die Änderungsverlangen sowie etwaige damit verbundene Anpassungen der Rege- lungen dieses Vertrags werden jeweils in einem Änderungsprotokoll dokumentiert. Die Änderungsprotokolle werden dem Vertrag als Anlage 6 beigefügt.

(6) Für Änderungsverlangen, die die Anwendung „Vermittlungsstelle“ betreffen, gelten die Absätze 1 bis 5 entsprechend.

58

[Seite 67]

Anlage 27

(((eTicket Deutschland

§ 4 Übergabe der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ und Dokumentation

Der Auftragnehmer stellt dem Auftraggeber bis spätestens zu dem in Anlage 7 genannten Termin die voll funktionsfähige Anwendung „KOSES“ und die voll funktionsfähige Anwen- dung „Vermittlungsstelle“ jeweils als Quellcode und als Objektcode auf einem maschinenles- baren Datenträger (z. B. Daten-CD, Daten-DVD) zur Verfügung. Er liefert zu diesem Termin ferner eine ausführliche, für den Einsatz der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ (einschließlich deren Pflege und Weiterentwicklung) geeignete Doku- mentation in deutscher Sprache (im Folgenden: „Anwendungsdokumentation“). Der Auftrag- geber erhält an allen Fassungen der Quellcodes und der Quellcode-Dokumentationen ein Nutzungsrecht gem. § 6 Absatz 1.

§ 5 Abnahme

(1) Der Auftragnehmer kann vom Auftraggeber die Abnahme der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ unter den Voraussetzungen gem. Kapitel 5 des Angebotes vom 02.06.2010 verlangen, wenn der Auftragnehmer die voll funkti- onsfähige Anwendung „KOSES“ und die voll funktionsfähige Anwendung „Vermitt- lungsstelle“ gemäß § 4 übergeben und deren Funktionsfähigkeit gemäß Absatz 2 nachgewiesen hat und wenn im Anschluss daran die Anwendung „KOSES“ und die Anwendung „Vermittlungsstelle“ einen Monat ohne wesentliche Störung gelaufen sind. Die Abnahmekriterien für die Anwendung „KOSES“ und für die Anwendung „Vermittlungsstelle“ einschließlich der Definition der Testfälle, die für einen vollständi- gen Funktionstest nach Absatz 2 erforderlich sind, sind in der Planungsphase (§ 1) durch den Auftragnehmer in Abstimmung mit dem Auftraggeber zu erarbeiten und in dem als Anlage 5 beigefügten Pflichtenheft zu dokumentieren.

Die Abnahme umfasst die Abnahme der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“. Sonstige nach diesem Vertrag zu erbringende Leistungen wer- den von der Abnahme nicht erfasst.

(2) Zur Abnahme weist der Auftragnehmer das Vorliegen der vertraglich vereinbarten Eigenschaften sowie die einwandfreie und ordnungsgemäße Funktionsfähigkeit der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ im Rahmen eines Testbetriebs nach.

(3) Der Auftraggeber hat innerhalb von einem Monat nach Zugang des berechtigten Ab- nahmeverlangens des Auftragnehmers beim Auftraggeber entweder die Abnahme zu erklären oder die Abnahme zu verweigern. Als Abnahmedatum gilt der Termin der vorbehaltlosen Unterzeichnung des Abnahmeprotokolls durch den Auftraggeber. Die Abnahme darf nicht unbillig verweigert werden. Soweit im Abnahmeprotokoll Mängel bzw. fehlende Funktionen oder Störungen festgehalten werden, so gilt als Abnahme- datum der erste Tag, an dem der letzte nicht nur unwesentliche Mangel beseitigt bzw. die letzte nicht nur unwesentliche fehlende Funktion fehlerfrei integriert wurde. Das Abnahmeprotokoll muss von beiden Parteien unterschrieben werden. Sofern der Auf- traggeber vor der Abnahme den Empfang einzelner Teilleistungen (z.B. Testprotokol- le, Funktionsnachweise) bestätigt hat, stellt dies keine Abnahme dieser Leistungen dar.

59

[Seite 68]

Anlage 27

(((eTicket Deutschland

(4) Die Abnahme nach § 5 Absatz 3 dieses Vertrages und die Abnahme nach § 13 Ab- satz 3 dieses Vertrages können zeitlich zusammenfallen.

§ 6 Nutzungsrechte

(1) Der Auftraggeber erwirbt mit der Abnahme der Anwendung „KOSES“ und der An- wendung „Vermittlungsstelle“ das ausschließliche, zeitlich und räumlich unbeschränk- te, sich auf alle bekannten und unbekannten Nutzungsarten erstreckende Nutzungs- recht an den fertiggestellten Werken „KOSES“ und „Vermittlungsstelle“ ausgenom- men der Nutzungsrechte an den vom Auftraggeber beigestellten OSS-Komponenten, insbesondere das Recht, die Anwendung „KOSES“ und die Anwendung „Vermitt- lungsstelle“ zu speichern und zu laden, sie ablaufen zu lassen, zu vervielfältigen, zu verbreiten, vorzuführen, öffentlich zugänglich zu machen und wiederzugeben, zu be- arbeiten, umzugestalten und zu verwerten. Sofern es sich bei der Nutzung der An- wendung „KOSES“ und/oder der Anwendung „Vermittlungsstelle“ um die Ausübung einer zum Zeitpunkt des Vertragsschlusses unbekannten Nutzungsart gemäß § 31a Absatz 1 UrhG handelt, wird der Auftraggeber dem Auftragnehmer die beabsichtigte Aufnahme dieser Nutzung an die ihm zuletzt bekannte Adresse des Auftragnehmers mitteilen; der Auftragnehmer kann innerhalb einer Frist von drei Monaten nach Ab- sendung der Mitteilung die Einräumung der für die Ausübung dieser Nutzungsart er- forderlichen Nutzungsrechte widerrufen. Im Übrigen ist die Einräumung des Nut- zungsrechts an der Anwendung „KOSES“ und an der Anwendung „Vermittlungsstelle“ unwiderruflich. Das Nutzungsrecht bezieht sich auf die Anwendung „KOSES“ und die Anwendung „Vermittlungsstelle“ jeweils im Objektcode- sowie in Quellcodeformat ein- schließlich der dazugehörigen Daten und Datenschutzstrukturen in allen Entwick- lungs-, Zwischen- und Endstufen sowie auf die zugehörige Anwendungsdokumentati- on und auf sonstige für die Ausübung des Nutzungsrechts notwendigen Materialien wie beispielsweise Analysen, Lasten- bzw. Pflichtenhefte, Konzepte und Beschrei- bungen (im Folgenden für alles Vorgenannte: „Lizenzgegenstand“).

(2) Der Auftraggeber ist frei, ohne Zustimmung des Auftragnehmers hinsichtlich einzelner oder sämtlicher ihm eingeräumten Rechte einfache oder ausschließliche Lizenzen an Dritte zu vergeben oder die erworbenen Rechte ganz oder teilweise auf Dritte zu übertragen.

(3) Der Auftragnehmer stellt sicher, dass eventuelle Rechte nach § 12, 13 Satz 2 und 25 UrhG nicht geltend gemacht werden.

(4) Nach erfolgter Abnahme der Anwendung „KOSES“ und der Anwendung „Vermitt- lungsstelle“ kann der Auftraggeber vom Auftragnehmer jederzeit verlangen, dass die- ser sämtliche Originale und Kopien der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ (einschließlich Quellcodes), der Anwendungsdokumentation und der sonstigen während der Programmerstellung entstandenen Unterlagen herausgibt und die vollständige Erfüllung dieser Verpflichtung schriftlich versichert; soweit die Kopien auf maschinenlesbaren Datenträgern des Auftragnehmers aufgezeichnet sind, tritt an die Stelle der Herausgabe das Löschen der Aufzeichnungen. Der Auftraggeber kann dieses Verlangen auch mit der Einschränkung aussprechen, dass der Auftrag- nehmer berechtigt bleibt, je eine an einem sicheren Ort zu verwahrende und aus- schließlich zu Beweiszwecken und zur Erfüllung der sonstigen Pflichten aus diesem Vertrag dienende Kopie zurückzubehalten.

60

[Seite 69]

Anlage 27

(((eTicket Deutschland

D) Besondere Bestimmungen für die Pflege und Weiterentwicklung der Anwen- dung „KOSES“ und der Anwendung „Vermittlungsstelle“

§ 7 Gegenstand der Pflegeleistungen

(1) Der Auftragnehmer erbringt Wartungsleistungen und Änderungsleistungen im Hinblick auf den Lizenzgegenstand (im Folgenden gemeinsam: „Pflegeleistungen“) nach den nachfolgenden Bestimmungen.

(2) Die Pflege umfasst Wartungsleistungen gemäß § 8 zur Aufrechterhaltung der Be- triebsbereitschaft der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle und zur Beseitigung von auftretenden Softwaremängeln und im Rahmen des Zumut- baren von sonstigen Softwarefehlern. Ein Softwaremangel liegt vor, wenn die Anwen- dung „KOSES“ und/oder die Anwendung „Vermittlungsstelle“ die nach Maßgabe die- ses Vertrags festgelegten Leistungen nicht erfüllt, falsche Ergebnisse liefert, ihren Lauf unkontrolliert abbricht oder sich in anderer Weise nicht funktionsgerecht verhält. Sonstige Softwarefehler sind Unvollkommenheiten der Anwendung „KOSES“ und/oder der Anwendung „Vermittlungsstelle, die deren Funktionen nicht beeinträch- tigen.

(3) Die Pflege umfasst auch die Erbringung von Änderungsleistungen zur Anpassung des Lizenzgegenstandes an die Belange des Auftraggebers nach Maßgabe des § 9.

§ 8 Wartungsleistungen

(1) Der Auftragnehmer erbringt Wartungsleistungen zur Behebung von Softwaremängeln der Anwendung „KOSES“ und/oder der Anwendung „Vermittlungsstelle und von sons- tigen Softwarefehlern (im Folgenden: „Fehlerbehebung“). Zur Fehlerbehebung gehö- ren die Eingrenzung der Mangel- bzw. Fehlerursache, die Mangel- bzw. Fehlerdiag- nose sowie die Behebung des Softwaremangels bzw. des sonstigen Softwarefehlers. Die Behebung eines Softwaremangels bzw. eines sonstigen Softwarefehlers in der Anwendung „KOSES“ und/oder in der Anwendung „Vermittlungsstelle“ umfasst auch die Berichtigung der übrigen, hiervon betroffenen Bestandteile des Lizenzgegenstan- des.

(2) Der Auftragnehmer hat Softwaremängel und sonstige Softwarefehler innerhalb der in Anlage 7 geregelten Wiederherstellungsfristen zu beheben. Mit den Wartungsleis- tungen im Rahmen der Fehlerbehebung gemäß Absatz 1 wird durch den Auftrag- nehmer unverzüglich nachdem der Softwaremangel bzw. der sonstige Softwarefehler dem Auftragnehmer bekannt geworden ist, begonnen. Sofern Softwaremängel bzw. sonstige Softwarefehler nicht innerhalb der in der Anlage 7 vereinbarten Wiederher- stellungsfristen beseitigt werden können, sind sie durch vorübergehende Umge- hungslösungen abzustellen.

(3) Der Auftragnehmer setzt zur effizienten Ausführung der Wartungsleistungen geeigne- te, den allgemein anerkannten Regelungen ordnungsgemäßer Berufsausübung ent- sprechenden Werkzeuge wie Testprogramme, Testdaten-Generatorprogramme, Feh- lersuchprogramme und andere Diagnosehilfen ein.

61

[Seite 70]

Anlage 27

(((eTicket Deutschland

§ 9 Änderungsleistungen

(1) Der Auftragnehmer führt nach Abnahme außerhalb der Gewährleistung soweit zu- mutbar in einer Größenordnung von 10 Manntagen pro Kalenderjahr an der Anwen- dung „KOSES“ und/oder an der Anwendung „Vermittlungsstelle“ Änderungen auf An- forderung des Auftragnehmers durch. Der Auftragnehmer hat die Anwendungs- dokumentation entsprechend anzupassen oder zu ergänzen.

(2) Für darüber hinausgehende Änderungswünsche werden in einem Nachtrag oder in einem gesonderten Vertrag die von dem Auftraggeber verlangten Änderungsleistun- gen im Einzelnen vereinbart. Die Vergütung erfolgt nach Aufwand zu den in Ziffer 3. b) der Anlage 9 festgelegten Vergütungssätzen.

§ 10 Nutzungsrechte an den Pflegeleistungen

Der Auftraggeber erhält an allen Arbeitsergebnissen der Pflegeleistungen ein Nutzungsrecht gemäß § 6 Absatz 1. Die Regelungen des § 6 Absatz 2 – Absatz 4 gelten entsprechend.

E) Besondere Bestimmungen für den Rechenzentrumsbetrieb

§ 11 Leistungsumfang des Auftragnehmers im Rahmen des Rechenzentrumsbetriebs

(1) Der Auftragnehmer hat nach näherer Maßgabe von §§ 11, 14 bis 16 dieses Vertrages die Anwendung „KOSES“ und die Anwendung „Vermittlungsstelle“ dem Auftraggeber sowie sämtlichen Teilnehmern auf seiner eigenen IT-Infrastruktur rund um die Uhr und an allen Tagen der Woche („24/7-Betrieb“) nach den jeweils allgemein anerkann- ten Regelungen ordnungsgemäßer Berufsausübung mit bestmöglicher Performance zur Verfügung zu stellen, seine IT-Infrastruktur dafür stets technisch aktuell, zuverläs- sig und ausfallsicher zu gestalten und zu erhalten sowie geeignete Vorkehrungen zu treffen, um unvermeidbare Ausfälle abzufangen (im Folgenden: „KOSES-Betrieb und Vermittlungsstelle-Betrieb“). Im Rahmen des KOSES-Betriebs und des Vermittlungs- stelle-Betriebs hat der Auftragnehmer sicherzustellen, dass die in dem als Anlage 5 beigefügten Pflichtenheft beschriebenen Anforderungen unter Einhaltung der in der Anlage 7 vereinbarten Leistungsparameter rechtzeitig und vollumfänglich erfüllt wer- den.

(2) Der Auftragnehmer hat nach näherer Maßgabe von § 13 dieses Vertrages sämtliche Leistungen zu erbringen, die zur Aufnahme des KOSES-Betriebs und des Vermitt- lungsstelle-Betriebs erforderlich sind, einschließlich aller Tests, der Übernahme von Daten an den in der Anlage 5 (Pflichtenheft) vereinbarten Übergabepunkten und der Durchführung der erforderlichen Konsistenztests. Der Auftragnehmer hat sicherzu- stellen, dass der KOSES-Betrieb und der Vermittlungsstelle-Betrieb spätestens an dem in Anlage 7 vereinbarten Termin in vollem Umfang aufgenommen werden.

(3) Der Auftragnehmer hat sämtliche Leistungen zu erbringen, die im Falle einer Beendi- gung dieses Vertrags für die erfolgreiche Rückübertragung der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ erforderlich sind, einschließlich der Übertra-

62

[Seite 71]

Anlage 27

(((eTicket Deutschland

gung der dann aktuellen Datenbestände an die in der Anlage 5 (Pflichtenheft) verein- barten Übergabepunkte.

§ 12 Allgemeine Leistungspflichten des Auftragnehmers im Rahmen des Rechenzentrums- betriebs

(1) Der Auftragnehmer schuldet ohne gesondertes Entgelt alle Nebenleistungen, die für die nach diesem Abschnitt E) zu erbringenden Leistungen erforderlich sind. Diese Nebenleistungen umfassen die Vorleistungen sowie betriebsbegleitende Maßnah- men. Zu den Vorleistungen zählen insbesondere die Beschaffung von Hardware, Software (unbeschadet der Abschnitte C) und D) dieses Vertrages) und Verbrauchs- materialien. Zu den betriebsbegleitenden Maßnahmen gehören:  Service Delivery (Service-Level-Management, IT-Continuity-Management, Availa- bility-Management, Performance-Monitoring und -Reporting und das Capacity- Management);  Service Support (Incident- und Problem-Management, Help-Desk-Support. Con- figuration Management, Change-Management und Release-Management);  Sonstige Leistungen (System Management, Optimierung der Betriebsprozesse, Datensicherung, Security-Management).

(2) Der Auftragnehmer ist verpflichtet, bei der Erbringung der Leistungen nach dem Ab- schnitt E) die vom Bundesministerium der Finanzen aufgestellten „Grundsätze ord- nungsgemäßer datenverarbeitungsgestützter Buchführungssysteme – GoBS“, die von dem Institut der Wirtschaftsprüfer in Deutschland e.V. aufgestellten Grundsätze ord- nungsmäßiger Buchführung bei Einsatz von Informationstechnologie – IDW RS FAIT 1 sowie den Prüfungsstandard PS 330 für die Abschlussprüfung bei Einsatz von IT – IDW PS 330, jeweils in ihrer aktuellen Fassung zu beachten und – soweit anwendbar – einzuhalten.

(3) Der Auftragnehmer wird darüber hinaus – sofern nicht etwas Abweichendes verein- bart wird – bei seinen Leistungen die folgenden Qualitätsvorgaben einhalten: DIN/ISO 9001:2008, ISO/IEC 27001, Information Technology Infrastructure Library (ITIL), Con- trol Objectives IT (COBIT) und die IT-Grundschutz-Standards des BSI.

(4) Der Auftragnehmer hat innerhalb von zwölf Wochen nach der Aufnahme des KOSES- Betriebs und des Vermittlungsstelle-Betriebs ein Betriebshandbuch zu erstellen. Er wird dieses Betriebshandbuch pflegen und bei Änderungen laufend aktualisieren. In dem Betriebshandbuch sind sämtliche Informationen zu erfassen, die für den fehler- freien und vertragsgemäßen Rechenzentrumsbetrieb erforderlich sind, insbesondere die technische Beschreibung der einzelnen Leistungen, die Darstellung der Katastro- phenfallmaßnahmen sowie der Schnittstellen. Der Inhalt, die Systematik und die Dar- stellungstiefe müssen es einem fachkundigen Dritten erlauben, den vom Auftragneh- mer durchgeführten Rechenzentrumsbetrieb vollständig zu verstehen, zu prüfen und zu übernehmen.

(5) Der Auftragnehmer hat keine Nutzungsrechte an der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“. Die Regelungen des § 6 und des § 10 bleiben unbe- rührt.

63

[Seite 72]

Anlage 27

(((eTicket Deutschland

§ 13 Aufnahme des Rechenzentrumsbetriebs / Abnahme

(1) Der Auftragnehmer hat sich über die Beschaffenheiten der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ und deren Einsatzweise sorgfältig zu informieren. Der Auftragnehmer hat die Anwendung „KOSES“ und die Anwendung „Vermittlungs- stelle“ testweise auf seiner IT-Infrastruktur aufzuspielen und mit Echtdaten als Test- material ablaufen zu lassen, um die ausreichende Dimensionierung seiner IT- Infrastruktur zu prüfen und um sicherzustellen, dass die Werte, die zur Ermittlung der Einhaltung der in der Anlage 7 vereinbarten Leistungsparameter heranzuziehen sind, gemessen werden können. Dabei ist auch zu testen, ob die Übernahme der Daten von dem Auftraggeber und den Teilnehmern sowie die Übergabe von Daten von dem Auftragnehmer an den Auftraggeber und die Teilnehmer reibungslos funktionieren. Der Auftragnehmer weist dem Auftraggeber spätestens drei Monate vor der Aufnah- me des KOSES-Betriebs und des Vermittlungsstelle-Betriebs gemäß § 11 Absatz 2 die volle Funktionsfähigkeit des Ablaufs der Anwendung „KOSES“ und der Anwen- dung „Vermittlungsstelle“ auf den IT-Systemen des Auftragnehmers in der vorgese- henen Umgebung einschließlich der dabei vorgesehenen Sicherheitsvorkehrungen nach und belegt die Erreichung der in der Anlage 7 vereinbarten Leistungsparameter im Rahmen des Testbetriebs.

Das Abnahmekonzept einschließlich der Definition der Testfälle, die für einen voll- ständigen Funktionstest erforderlich sind, ist in der Planungsphase (§ 1) durch den Auftragnehmer in Abstimmung mit dem Auftraggeber zu erarbeiten und in dem als Anlage 5 beigefügten Pflichtenheft zu dokumentieren.

(2) Sobald der Auftragnehmer die volle Funktionsfähigkeit gemäß Absatz 1 nachgewie- sen hat und wenn im Anschluss daran die Anwendung „KOSES“ und die Anwendung „Vermittlungsstelle“ einen Monat unter hinreichender Auslastung ohne wesentliche Störung auf den IT-Systemen des Auftragnehmers gelaufen ist, kann der Auftrag- nehmer vom Auftraggeber die Abnahme verlangen. Die Abnahme umfasst lediglich die nach Absatz 1 zu erbringenden Leistungen. Sonstige nach diesem Vertrag zu er- bringende Leistungen werden von der Abnahme nicht erfasst.

(3) Der Auftraggeber hat innerhalb von einem Monat nach Zugang des berechtigten Ab- nahmeverlangens des Auftragnehmers beim Auftraggeber entweder die Abnahme zu erklären oder die Abnahme zu verweigern. Als Abnahmedatum gilt der Termin der vorbehaltlosen Unterzeichnung des Abnahmeprotokolls durch den Auftraggeber. Die Abnahme darf nicht unbillig verweigert werden. Soweit im Abnahmeprotokoll Mängel bzw. fehlende Funktionen oder Störungen festgehalten werden, so gilt als Abnahme- datum der erste Tag, an dem der letzte nicht nur unwesentliche Mangel beseitigt bzw. die letzte nicht nur unwesentliche fehlende Funktion fehlerfrei integriert wurde. Das Abnahmeprotokoll muss von beiden Parteien unterschrieben werden. Sofern der Auf- traggeber vor der Abnahme den Empfang einzelner Teilleistungen (z.B. Testprotokol- le und Funktionsnachweise) bestätigt hat, stellt dies keine Abnahme dieser Leistun- gen dar.

(4) Der Auftragnehmer hat sicherzustellen, dass spätestens mit der Aufnahme des KOSES-Betriebs und des Vermittlungsstelle-Betriebs gemäß § 11 Absatz 2 vorhan- dene Datenbestände vollständig übernommen werden (im Folgenden: „Übernahme- arbeiten“). Bis zu diesem Zeitpunkt müssen sämtliche Übernahmearbeiten erfolgreich abgeschlossen werden. Gelingt dies dem Auftragnehmer nicht, wird er den Auftrag- geber hierüber unverzüglich unter Angabe der Gründe und die Dauer der voraussicht- lichen Verzögerung informieren. Der Auftraggeber wird dann einen neuen Termin für 64

[Seite 73]

Anlage 27

(((eTicket Deutschland

die Erledigung der Übernahmearbeiten benennen; dies stellt zugleich eine Nachfrist für die Bewerkstelligung des Erfolgs der Übernahme dar. Alle darüber hinausgehen- den Ansprüche des Auftraggebers gegen den Auftragnehmer bleiben hiervon unbe- rührt.

(5) Die Abnahme nach § 5 Absatz 3 dieses Vertrages und die Abnahme nach § 13 Ab- satz 3 dieses Vertrages können zeitlich zusammenfallen.

§ 14 Betrieb des Rechenzentrums

(1) Die Betriebsphase beginnt nach der Erklärung der Abnahme nach Maßgabe von § 13 Absatz 3 mit der Aufnahme des KOSES-Betriebs und des Vermittlungsstelle-Betriebs gemäß § 11 Absatz 2. Ab diesem Zeitpunkt ist der Auftragnehmer bis zur Beendigung dieses Vertrages verpflichtet, den Betrieb mit den in der Anlage 7 vereinbarten Leis- tungsparametern zu unterhalten und insbesondere im Falle von auftretenden Funkti- onsstörungen innerhalb der in Anlage 7 vereinbarten Wiederherstellungsfristen für die Wiederherstellung des uneingeschränkten KOSES-Betriebs und Vermittlungsstel- le-Betriebs zu sorgen. § 26 Absatz 5 bleibt unberührt.

(2) Der Auftragnehmer ist verpflichtet, mindestens täglich von 6h bis 19h einen bedienten Betrieb vorzuhalten.

§ 15 Technologische Weiterentwicklungen

(1) Der Auftragnehmer hat die ihm nach diesem Abschnitt E) obliegenden Leistungen nach den Grundsätzen der allgemein anerkannten Regelungen ordnungsgemäßer Berufsausübung zu erbringen. Er wird seine Leistungen im Übrigen den jeweiligen Marktstandards anpassen.

(2) Der Auftragnehmer hat – soweit dies für eine ordnungsgemäße Leistungserbringung erforderlich ist – für eine Erneuerung der eingesetzten IT-Systeme zu sorgen.

(3) Der Auftragnehmer wird die im Betriebshandbuch beschriebenen Prozesse regelmä- ßig analysieren, einem ständigen Optimierungsprozess unterziehen und dem Auf- traggeber etwaige Verbesserungsmöglichkeiten mitteilen. Dies gilt insbesondere für Kosteneinsparungspotentiale.

§ 16 Geänderte Anforderungen an den Rechenzentrumsbetrieb

(1) Der Auftragnehmer hat die jeweils aktuelle Version der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ auf seinen IT-Systemen zu betreiben. Der Auftrag- nehmer hat durch vorherige Testläufe sicherzustellen, dass sich hierdurch keine ne- gativen Auswirkungen auf die Performance und/oder die Stabilität des Betriebs erge- ben.

65

[Seite 74]

Anlage 27

(((eTicket Deutschland

(2) Der Auftragnehmer hat seine IT-Systeme stets so auszugestalten, dass die in der Anlage 7 vereinbarten Leistungsparameter auch dann noch eingehalten werden, wenn neue Teilnehmer an das (((eTicket-Deutschland angebunden werden und Leis- tungen in Anspruch nehmen, die nach diesem Vertrag zu erbringen sind.

(3) Der Auftraggeber kann von dem Auftragnehmer auch darüber hinausgehend Ände- rungen und Ergänzungen im Zusammenhang mit den nach diesem Abschnitt E) zu erbringenden Leistungen verlangen. § 3 Absätze 2 – 5 gelten mit der Maßgabe ent- sprechend, dass die in Ziffer 1. b) der Anlage 9 vorgesehenen Vergütungssätze kei- ne Anwendung finden.

F) Allgemeine Bestimmungen für die Planung und Erstellung der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“, die Pflege und Weiterent- wicklung der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ sowie den Rechenzentrumsbetrieb

§ 17 Grundsätze der Zusammenarbeit / Projektmanagement

(1) Beide Parteien werden spätestens bei Vertragsschluss jeweils einen Projektleiter, dessen Stellvertreter, einen Eskalationsmanager sowie ggf. weitere Mitglieder des Projektteams benennen (im Folgenden für alle vorgenannten Personen: „Projekt- team“). Ist ein Mitglied des Projektteams auf absehbar unangemessen lange Zeit ver- hindert oder scheidet es aus dem Unternehmen der jeweiligen Partei aus, ist rechtzei- tig eine Ersatzperson zu benennen.

(2) Die Mitglieder des Projektteams dürfen nur aus wichtigem Grund (z. B. Krankheit, Ausscheiden aus dem Unternehmen) ausgewechselt werden.

(3) Das Projektteam des Auftragnehmers muss für die nach diesem Vertrag zu erbrin- genden Leistungen besonders qualifiziert sein und über ausreichende Projekterfah- rung bei der Realisierung vergleichbarer Projekte verfügen. Der Auftraggeber kann einen Nachweis hierüber verlangen und in Ermangelung dessen einen Austausch des hiervon betroffenen Mitglieds des Projektteams verlangen.

(4) Die Projektleiter der Parteien und deren Stellvertreter sind zur Entgegennahme sämt- licher Erklärungen im Zusammenhang mit diesem Vertrag befugt. Sie bereiten not- wendige Entscheidungen der jeweiligen Partei zügig vor und sorgen, soweit sie nicht selbst vertretungsbefugt sind, für eine rasche Herbeiführung der Entscheidung. Dem Eskalationsmanager ist zur Abgabe von Willenserklärungen im Zusammenhang mit diesem Vertrag Einzelvertretungsberechtigung einzuräumen. Der Eskalationsmana- ger soll anstehende Entscheidungen selbst treffen.

(5) Die Projektleiter treffen sich zu regelmäßigen Projektbesprechungen in Köln. Der Auf- traggeber kann darüber hinaus jederzeit nach billigem Ermessen mit angemessener Frist Projektbesprechungen einberufen.

(6) In den Projektbesprechungen sollen sämtliche Fragen im Zusammenhang mit diesem Vertrag geklärt werden. Gelingt dies nicht, werden die Projektleiter auf eine Einigung hinwirken. Kommt es zu keiner Einigung, kann sich jede Partei unmittelbar an den Eskalationsmanager der jeweils anderen Partei wenden. Dieser ist verpflichtet, un-

66

[Seite 75]

Anlage 27

(((eTicket Deutschland

verzüglich eine Entscheidung über die ungeklärte Frage zu treffen und der anderen Partei diese mitzuteilen.

(7) Der Auftraggeber kann jederzeit nach billigem Ermessen verlangen, dass der Projekt- leiter des Auftragnehmers zu Abstimmungszwecken an Besprechungen zu Parallel- projekten im Rahmen des (((eTicket-Deutschlands teilnimmt.

(8) Beide Parteien haben den Projektleiter der jeweils anderen Partei bzw. – falls dieser nicht erreichbar ist – dessen Stellvertreter über alle Umstände aus ihrer Sphäre zu in- formieren, die Auswirkungen auf die nach diesem Vertrag zu erbringenden Leistun- gen haben können.

(9) Der Auftragnehmer hat die für die vertragsgegenständlichen Leistungen einschlägi- gen gesetzlichen Bestimmungen und behördlichen Anweisungen sowie Vorgaben zu beachten und umzusetzen. Die Parteien haben einander unverzüglich über insoweit erforderliche Änderungen zu informieren.

§ 18 Qualifikation von Erfüllungsgehilfen / Einschaltung von Subunternehmern

(1) Der Auftragnehmer hat sicherzustellen, dass sämtliche Personen, die von ihm mit der Erbringung von Leistungen nach diesem Vertrag betraut werden, für die Leistungen, für die sie hinzugezogen werden, hinreichend qualifiziert sind.

(2) Der Auftragnehmer ist nicht berechtigt, für die Erbringung der nach diesem Vertrag zu erbringenden Leistungen ohne vorherige schriftliche Zustimmung des Auftraggebers Subunternehmer einzusetzen. Hiervon ausgenommen sind dem Auftragnehmer zu- zuordnende legale Einheiten (Atos Worldline Processing GmbH, Atos Worldline Bel- gium S.A., Atos Worldline France S.A., etc.).

§ 19 Leistungsparameter

(1) Die Parteien vereinbaren in der Anlage 7 für Leistungen, die nach diesem Vertrag zu erbringen sind, Leistungsparameter, die die Qualität der zu erbringenden Leistungen messbar beschreiben. Es muss gewährleistet sein, dass man über Logeinträge (so- wohl fachlich als auch technisch) in der Lage ist, nachträglich Auswertungen bezüg- lich des Zeitverhaltens machen zu können.

Die Anwendung „KOSES“ und die Anwendung „Vermittlungsstelle“ muss in der Lage sein, laufend Daten entgegenzunehmen und weiterzuvermitteln.

(2) Die Messung der Werte der Leistungsparameter erfolgt kalendermonatlich. Sofern kein abweichender Messpunkt vereinbart wurde, erfolgt die Messung an dem jeweili- gen in der Anlage 5 (Pflichtenheft) vereinbarten Übergabepunkt. Der Auftragnehmer hat den Auftraggeber kalendermonatlich ausführliche Berichte über die Messungen und Ergebnisse sowie sonst erfasste Informationen über die Leistungsparameter in einem von dem Auftraggeber vorgegebenen Format zur Verfügung zu stellen. Der Auftragnehmer hat im Rahmen dieser Berichte über den Grad der Erreichung der Leistungsparameter zu informieren. Die Berichte sind dem Auftraggeber jeweils am fünften Arbeitstag des jeweils folgenden Kalendermonats zu übermitteln. Darüber 67

[Seite 76]

Anlage 27

(((eTicket Deutschland

hinaus hat der Auftragnehmer die gemessenen Daten während der gesamten Ver- tragsdauer zu speichern und dem Auftraggeber auf Wunsch Zweitschriften der Be- richte zukommen lassen.

(3) Werden Leistungsparameter nicht erreicht, hat der Auftragnehmer unverzüglich die hierfür maßgeblichen Gründe zu analysieren, diese Gründe abzustellen und dem Auf- traggeber hierüber Bericht zu erstatten.

(4) Der Auftraggeber kann die für die Erstellung der Berichte und für die Messung der Leistungsparameter eingesetzten Tools, Softwarelösungen und Messzyklen, –größen und –verfahren selbst oder durch einen Sachverständigen überprüfen. Sofern hierbei Defizite festgestellt werden, kann der Auftraggeber vom Auftragnehmer die Vornahme von Änderungen verlangen, die zur Beseitigung dieser Defizite erforderlich sind.

§ 20 Hotlineservice

Der Auftragnehmer stellt dem Auftraggeber und allen Teilnehmern für Störungsmel- dungen und Fragen zur Anwendung „KOSES“ und zur Anwendung „Vermittlungsstel- le“ einen First-Level-Support über einen telefonischen Hotlineservice und über E-Mail zur Verfügung, der von Montag bis Freitag von 06.00-19.00 Uhr, sowie Samstags und an Sonn- und Feiertagen von 09.00-14.00 Uhr unter Einhaltung der in der Anlage 7 vereinbarten Leistungsparameter erreichbar ist. Die Telekommunikationskosten für diesen Hotlineservice dürfen nicht über den Kosten liegen, die für 01803- Rufnummern entstehen. Außerhalb der vorgenannten Zeiten hat der Auftragnehmer eine telefonische Rufbereitschaft sicherzustellen. Die Rufbereitschaft ist so auszuge- stalten, dass der Auftragnehmer in der Lage ist, die Wiederherstellungsfristen nach Maßgabe der Anlage 7 einzuhalten.

§ 21 Mitwirkungspflichten des Auftraggebers

(1) Der Auftraggeber wird den Auftragnehmer im Rahmen der allgemeinen vertragsrecht- lichen Förderpflicht bei der Erfüllung seiner vertraglichen Verpflichtungen angemes- sen unterstützen. Der Auftraggeber stellt dem Auftragnehmer auf dessen Anforderung innerhalb einer angemessenen Frist alle zur Durchführung dieses Vertrages benötigte Informationen und Unterlagen zur Verfügung, soweit diese beim Auftraggeber vor- handen sind. Der Auftragnehmer hat die Mitwirkungsleistungen des Auftraggebers rechtzeitig abzurufen. Kommt der Auftraggeber seinen Mitwirkungspflichten nicht oder nicht rechtzeitig nach, so ist der Auftragnehmer für die Zeit der Nichterfüllung zuzüg- lich einer angemessenen Wiederanlauffrist von seinen Leistungspflichten befreit.

(2) Soweit nichts anderes vereinbart ist, erbringt der Auftraggeber die ihm obliegenden Mitwirkungspflichten für den Auftragnehmer unentgeltlich.

§ 22 Vergütung

(1) Die Vergütung für die nach diesem Vertrag zu erbringenden Leistungen ergibt sich aus der Anlage 9. Die Preise sind Festpreise in Euro und verstehen sich zuzüglich 68

[Seite 77]

Anlage 27

(((eTicket Deutschland

der jeweils geltenden gesetzlichen Umsatzsteuer. Mit der Zahlung der Vergütung sind sämtliche Aufwendungsersatzansprüche des Auftragnehmers gegen den Auftragge- ber abgegolten.

(2) Werden einzelne oder alle der in der Anlage 7 vereinbarten Termine und / oder Leis- tungsparameter nicht eingehalten, reduziert sich die von dem Auftraggeber an den Auftragnehmer zu zahlende Vergütung nach Maßgabe der Anlage 8. Die Vergütung reduziert sich nicht, sofern und soweit der Auftragnehmer nachweist, dass er die Nichteinhaltung der Termine und oder der Leistungsparameter nicht zu vertreten hat. Übersteigt der jeweilige Reduzierungsbetrag das zum maßgeblichen Zeitpunkt fällige Entgelt, wird der Reduzierungsbetrag von künftig zu zahlenden Entgelten in Abzug gebracht. Durch die Reduzierung der Vergütung bleiben etwaige Schadensersatzan- sprüche sowie sonstige Rechte des Auftraggebers gegen den Auftragnehmer unbe- rührt.

(3) Sämtliche Rechnungen sind dem Auftraggeber in zweifacher Ausfertigung vorzule- gen. Liefermengen und die erbrachten Leistungen sind übersichtlich und tabellarisch zu erfassen.

(4) Sofern es sich bei dem Auftragnehmer um eine Personenmehrheit aus mehreren Un- ternehmen handelt, werden Zahlungen mit befreiender Wirkung für den Auftraggeber auf das in der Rechnung genannte Konto geleistet. Dies gilt auch nach einer eventu- ellen Auflösung des Zusammenschlusses.

(5) Zahlungsverzögerungen, die darauf beruhen, dass der Auftragnehmer nicht prüffähi- ge oder sonst nicht vollständige Rechnungen einreicht sind vom Auftraggeber nicht zu vertreten.

(6) Die Vertragsparteien werden die Höhe der Vergütung neu festlegen, sobald die Kos- ten für die Erbringung der zugrunde liegenden Leistung des Auftragnehmers durch die Neueinführung oder Änderung von Steuern, anderen Abgaben oder sonstigen ge- setzlichen Bestimmungen oder Verordnungen, durch behördliche Maßnahmen, infol- ge eines Anstieges von Lohn-, Material-, oder sonstigen Kosten derart ansteigen, dass die Vertragsparteien für den Fall eines gedachten Neuabschlusses des Vertra- ges eine mehr als nur unwesentliche Anpassung des bestehenden Vergütungsni- veaus vornehmen würden. § 3 Abs. 3 findet in diesen Fällen entsprechende Anwen- dung, wenn und soweit mit der Anpassung ein Aufwand auf Seiten des Auftragneh- mers entsteht. Können sich die Vertragsparteien nicht innerhalb einer Frist von 4 Wo- chen auf die Höhe der neu festzusetzenden Vergütung einigen, wird die Vergütung (durch einen von den Vertragsparteien zu ernennenden Schlichter) unter Berücksich- tigung des jeweils marktüblichen Preisniveaus bestimmt.

Eine Preisanpassung kann erstmals mit Wirkung ab dem 48. Monat nach Vertragsbe- ginn verlangt werden.

§ 23 Gewährleistung

(1) Der Auftragnehmer gewährleistet, dass die von ihm nach diesem Vertrag zu erbrin- genden Leistungen die vereinbarte Beschaffenheit haben und nicht mit Mängeln be- haftet sind, die die Eignung für die nach dem Vertrag vorausgesetzte Verwendung beeinträchtigen. Sofern eine Abnahme vorgesehen ist, können sämtliche Rechte we- gen Mängeln auch dann noch geltend gemacht werden, wenn diesbezüglich bei der 69

[Seite 78]

Anlage 27

(((eTicket Deutschland

Abnahme kein Vorbehalt gemacht wird. Sofern sich der Auftragnehmer darauf beruft, dass etwaige Mängel auf einer nicht von ihm vorgenommenen Schlecht- oder Nicht- leistung bzw. der fehlerhaften Weiterverarbeitung bzw. -benutzung beruhen, ist der Auftragnehmer hierfür beweispflichtig.

(2) Ansprüche wegen Mängeln bezüglich der von dem Auftragnehmer zu erbringenden Leistungen verjähren innerhalb von drei Jahren seit der Abnahme. Ist keine Abnahme vorgesehen, tritt an deren Stelle die Leistungserbringung. Sämtliche Verjährungsfris- ten für Mängelansprüche beginnen erst mit der Erklärung der Abnahme. Die Verjäh- rungsfristen für Mängelansprüche in Bezug auf die Erstellung einerseits, die Pflege und Weiterentwicklung andererseits sowie den Betrieb laufen in Bezug auf die An- wendung KOSE und die Anwendung Vermittlungsstelle jeweils einheitlich. Der Lauf der Verjährungsfrist verlängert sich um die Zeit, während der die von dem Auftrag- nehmer zu erbringenden Leistungen wegen eines Mangels der Anwendung KOSE und der Anwendung Vermittlungsstelle nicht bestimmungsgemäß genutzt werden konnten.

(3) Werden Mängel vom Auftragnehmer nicht innerhalb einer vom Auftraggeber gesetz- ten Frist behoben oder durch eine angemessene Zwischenlösung aufgefangen, kann der Auftraggeber nach fruchtlosem Fristablauf die Vergütung angemessen herabset- zen (über eine Herabsetzung nach § 22 Absatz 2 hinaus) oder diesen Vertrag insge- samt oder den hiervon betroffenen Vertragsteil außerordentlich kündigen. Darüber hinaus bestehende Rechte und Ansprüche des Auftraggebers bleiben unberührt.

§ 24 Schadensersatz

(1) Schadensersatzansprüche des Auftraggebers gegen den Auftragnehmer werden im Falle von einfacher und grober Fahrlässigkeit nach Maßgabe der Anlage 10 der Hö- he nach beschränkt.

(2) Für die Ermittlung von Schadensersatzansprüchen des Auftraggebers gegen den Auftragnehmer gelten Schäden der Teilnehmer aufgrund einer schuldhaften Verlet- zung der Pflichten des Auftragnehmers aus diesem Vertrag als Schäden des Auftrag- gebers.

(3) Sofern der Auftragnehmer eine Personenmehrheit aus mehreren Unternehmen ist, haften diese gesamtschuldnerisch.

§ 25 Freiheit von Rechten Dritter

(1) Der Auftragnehmer steht dafür ein, dass die im Rahmen dieses Vertrags erbrachten Leistungsergebnisse (im Folgenden: „Leistungsergebnisse“) frei von Schutzrechten Dritter sind und dass nach seiner Kenntnis auch keine sonstigen Rechte bestehen, die eine Nutzung nach Maßgabe dieses Vertrags einschränken oder ausschließen.

(2) Der Auftragnehmer stellt insbesondere durch entsprechende Vereinbarungen mit sei- nen Arbeitnehmern oder Beauftragten sicher, dass der gemäß diesem Vertrag vorge- sehene Nutzungsumfang an den Leistungsergebnissen nicht durch eventuelle Mitur- heber- oder sonstige Rechte beeinträchtigt wird. Auf Verlangen des Auftraggebers

70

[Seite 79]

Anlage 27

(((eTicket Deutschland

wird der Auftragnehmer diesem den Abschluss entsprechender Vereinbarungen mit den zur Erfüllung seiner Vertragspflichten eingesetzten Personen nachweisen.

(3) Der Auftragnehmer stellt den Auftraggeber von allen Ansprüchen frei, die von Dritten gegen den Auftraggeber wegen der Verletzung von Schutzrechten durch die Benut- zung der Leistungsergebnisse geltend gemacht werden. Der Auftraggeber benach- richtigt den Auftragnehmer unverzüglich schriftlich, wenn derartige Ansprüche Dritter wegen der Verletzung von Schutzrechten gegen ihn geltend gemacht werden. § 24 Absatz 1 dieses Vertrages findet für Ansprüche des Auftraggebers nach diesem § 25 Absatz 3 nach Maßgabe der Anlage 10 Anwendung. Diese Regelung gilt entspre- chend auch gegen den Auftraggeber in Bezug auf seine Beistellungen.

(4) Wenn es dem Auftragnehmer nicht gelingt, Beeinträchtigungen durch Rechte Dritter auszuräumen, gilt § 23 Absatz 3 entsprechend.

§ 26 Laufzeit / Abwicklung nach Vertragsbeendigung

(1) Dieser Vertrag hat eine unbestimmte Laufzeit. Der Vertrag kann frühestens nach Ab- lauf von vier Jahren seit der Aufnahme des KOSES-Betriebs und des Vermittlungs- stelle-Betriebs gemäß § 14 Abs. 1 mit einer Kündigungsfrist von einem Jahr zum En- de eines jeden Kalenderjahres gekündigt werden.

(2) Das Recht der Parteien zur außerordentlichen Kündigung dieses Vertrages bei Vor- liegen eines wichtigen Grundes bleibt unberührt. Ein wichtiger Grund, der den Auf- traggeber zur außerordentlichen Kündigung berechtigt, liegt insbesondere vor, wenn

• sich der Auftragnehmer an wettbewerbsbeschränkenden Absprachen beteiligt,

• der Auftragnehmer oder einer seiner Erfüllungsgehilfen Mitarbeitern des Auf- traggebers, die mit der Vorbereitung, dem Abschluss oder der Durchführung dieses Vertrages befasst sind, Vorteile anbietet, verspricht oder gewährt,

• der Auftragnehmer die Anforderungen an die Sicherheit des Rechenzent- rumsbetriebes gemäß Anlage 7 in nicht nur unerheblichem Maße nicht erfüllt.

• der Auftragnehmer unzulässigerweise zur Erfüllung seiner Verpflichtungen aus diesem Vertrag oder aus sonstigen Gründen einzelne Teilleistungen oder Ver- richtungen auf Dritte überträgt oder

• gegen den Auftragnehmer ein Insolvenzverfahren eröffnet oder die Eröffnung eines Insolvenzverfahrens mangels Masse abgelehnt wird. Der Auftragnehmer hat den Auftraggeber über den Eintritt eines solchen Sachverhalts unverzüg- lich schriftlich zu unterrichten.

Ein wichtiger Grund, der den Auftragnehmer zur außerordentlichen Kündigung be- rechtigt, liegt insbesondere vor, wenn der Auftraggeber mit Zahlungen in Verzug ist, die insgesamt dem Doppelten der monatlichen Betriebskostenpauschale (Software- pflege- und RZ-Entgelt) entsprechen.

(3) Die Parteien stellen klar, dass eine Kündigung nach Absatz 2 nicht die Rechtsfolgen des § 649 BGB auslöst. Im Übrigen ist der Auftraggeber auch während der Mindest- 71

[Seite 80]

Anlage 27

(((eTicket Deutschland

laufzeit nach Absatz 1 Satz 2 berechtigt, auch ohne Vorliegen eines wichtigen Grun- des den Vertrag nach § 649 BGB zu kündigen. Im Falle einer ordentlichen Kündigung durch den Auftraggeber gem. § 649 BGB beträgt die Kündigungsfrist drei Monate zum Ablauf eines Kalendermonats. Für den Fall einer ordentlichen Kündigung sehen beide Parteien eine Vergütung der bis zum Wirksamwerden der Kündigung erbrach- ten Leistungen vor. Ferner sehen die Parteien zudem eine pauschale Abgeltung der dem Auftragnehmer durch die Kündigung entstehenden Aufwände und Kosten vor. Diese Pauschale beträgt die Vergütung in Höhe der Summe aus dem Softwarepfle- geentgelt und dem RZ-Entgelt, die der Auftragnehmer für die ersten beiden Monate nach dem Beginn der Betriebsphase im Sinne des § 14 Absatz 1 erhalten hätte.

(4) Im Falle einer bevorstehenden Beendigung dieses Vertrages haben die Parteien die technische und organisatorische Abwicklung dieses Vertrages in angemessener Wei- se durchzuführen. Der Auftragnehmer ist insbesondere verpflichtet, an einem ord- nungsgemäßen Übergang auf Folgesysteme in angemessener Form mitzuwirken und den Auftraggeber hierbei in dem erforderlichen Umfang nach besten Kräften zu un- terstützen. Dabei müssen die Sperrdatenbank und alle übrigen zum Weiterbetrieb er- forderlichen Daten an den nachfolgenden Betreiber übergeben werden. Im Rahmen der vorgenannten Unterstützungshandlungen wird der Auftragnehmer dem Auftrag- geber die Daten der Sperrdatenbank in einem datenbanküblichen Format kostenfrei zur Verfügung stellen. Darüber hinaus gehende Leistungen sind gesondert zu beauf- tragen und zu vergüten.

(5) Der Auftragnehmer verpflichtet sich, auch nach der Beendigung dieses Vertrages bis zur Migration des Rechenzentrumsbetriebs auf ein anderes Rechenzentrum, maximal jedoch bis zwölf Monate nach Vertragsende zu dulden, dass der Auftraggeber die nach diesem Vertrag zu erbringenden Leistungen nach Maßgabe der nach diesem Vertrag getroffenen Regelungen weiter in Anspruch nimmt. Für diesen Fall zahlt der Auftraggeber an den Auftragnehmer die bislang vereinbarte Vergütung.

(6) Im Falle der Beendigung dieses Vertrags soll weder der Auftraggeber noch ein Dritter wegen der etwaigen Fortführung der nach diesem Vertrag geschuldeten Leistungen damit belastet sein, Vertragsverhältnisse von Personal des Auftragnehmers über- nehmen oder dessen Personal auf anderer rechtlicher Grundlage beschäftigen zu müssen. Der Auftragnehmer verpflichtet sich zu diesem Zweck, rechtzeitig das zur Er- reichung dieses Ziels Notwendige (etwa die einvernehmliche Auflösung der Arbeits- verträge oder der Einsatz des Personals für andere Aufgaben) zu veranlassen und si- cherzustellen. Soweit aus der Vertragsbeendigung gleichwohl ein Teil-/ Betriebsüber- gang auf den Auftraggeber und/oder einen für ihn tätigen Dritten resultiert und der Auftraggeber und/oder der Dritte das entsprechende Personal des Auftragnehmers weiter beschäftigen muss, verpflichtet sich der Auftragnehmer, den Auftraggeber und/oder Dritten von den hiermit verbundenen, insbesondere von den seitens des Auftraggebers und/oder des Dritten für die Beendigung der Arbeitsverhältnisse erfor- derlichen Aufwendungen freizustellen.

§ 27 Geheimhaltung/Datenschutz

(1) Jede Partei wird alle Informationen oder Unterlagen, die sie von der jeweils anderen Partei (im Folgenden: „Informationsgeber“) vor oder nach Inkrafttreten dieses Vertra- ges erhalten oder anderweitig durch diese erlangt hat und die sich auf diesen Vertrag oder seine Bedingungen oder auf das Geschäft, die finanzielle Lage, die Produkte und Erwartungen, Prozesse und Methoden, Kunden und Angestellte der jeweils ande- 72

[Seite 81]

Anlage 27

(((eTicket Deutschland

ren Partei (insbesondere Betriebs- oder Geschäftsgeheimnisse) beziehen, sowie jeg- liche anderen Informationen und Unterlagen streng vertraulich behandeln (im Folgen- den: „vertrauliche Informationen“). Der Auftragnehmer hat alle Personen (insbesonde- re Mitarbeiter und Beauftragte), an die er vertrauliche Informationen weitergibt, ent- sprechend den Regelungen dieses Absatzes 1 zur Verschwiegenheit zu verpflichten und dem Auftraggeber dies auf Verlangen nachzuweisen.

(2) Keine Partei darf vertrauliche Informationen an Dritte übermitteln. Dritter im Sinne von Satz 1 sind nicht die Teilnehmer sowie im Zusammenhang mit der Vorbereitung, dem Abschluss oder der Durchführung des Vertrags in zulässiger Weise eingesetzte Bera- ter oder Mitarbeiter der Konzernunternehmen der Parteien, die vertraglich genauso zu Verschwiegenheit verpflichtet werden wie die Parteien selbst.

(3) Die Vertraulichkeitsverpflichtung gilt nicht in Bezug auf vertrauliche Informationen, soweit diese (a) der empfangenden Partei bereits unabhängig vom Abschluss oder der Umsetzung dieses Vertrags bekannt waren, (b) auf andere Weise als durch die Verletzung dieses § 28 durch die empfangende Partei bereits allgemein bekannt sind oder werden oder (c) durch eine der Parteien kraft Gesetzes oder aufgrund einer gerichtlichen oder be- hördlichen Verfügung offen gelegt werden müssen. In den unter (c) genannten Um- ständen wird die offen legende Partei die andere Partei vor Offenlegung umgehend und unter Vorlage von Nachweisen von dieser gesetzlichen Pflicht bzw. Verfügung in Kenntnis setzen, so dass die andere Partei einstweiligen Rechtsschutz oder andere geeignete Rechtsbehelfe ergreifen kann. Die offen legende Partei wird die andere Partei hierbei in angemessenem Umfang unterstützen. Sofern eine der Offenlegung vorangehende Unterrichtung nicht zulässig ist, hat eine entsprechende Unterrichtung nach Offenlegung zu erfolgen, sobald diese rechtlich zulässig ist oder d) selbst und unabhängig durch die preisgebende Partei entwickelt worden ist.

(4) Die vertraulichen Informationen verbleiben im Eigentum des Informationsgebers und dürfen nur mit dessen vorheriger schriftlicher Zustimmung kopiert oder vervielfältigt werden. Auf Verlangen des Informationsgebers muss die andere Partei die vertrauli- chen Informationen und ihre Verkörperung zurückgeben oder vernichten und die Ver- nichtung schriftlich bestätigen.

(5) Die Parteien gehen gegenwärtig nicht davon aus, dass der Auftragnehmer im Rah- men der Durchführung dieses Vertrages personenbezogene Daten i.S.v. § 3 Absatz 1 BDSG erhebt, verarbeitet oder nutzt. Sollte sich herausstellen, dass der Auftragneh- mer personenbezogene Daten erheben, verarbeiten oder nutzen muss, um seine ihm aus diesem Vertrag obliegenden Pflichten ordnungsgemäß erfüllen zu können, ver- pflichten sich die Parteien bereits jetzt, diesen Vertrag so abzuändern, dass eine ge- setzeskonforme Erhebung, Verarbeitung und Nutzung personenbezogener Daten gewährleistet werden kann. Sofern dem Auftragnehmer hieraus Kosten entstehen, werden die Parteien eine angemessene Vergütung hierüber vereinbaren.

(6) Die vorstehenden Pflichten gelten auch nach Kündigung oder Ablauf dieses Vertra- ges 3 Jahre lang fort.

§ 28 Informations- und Kontrollrecht

73

[Seite 82]

Anlage 27

(((eTicket Deutschland

(1) Hat der Auftraggeber Anhaltspunkte für eine Vertragsverletzung durch den Auftrag- nehmer ist er berechtigt, eine Prüfung der durch den Auftragnehmer zu erbringenden Leistungen während der Geschäftszeiten des Auftragnehmers durchzuführen, in der er vom Auftragnehmer Auskünfte und Einsicht in Unterlagen zu verlangen kann. Während einer Prüfung hat der Auftraggeber auf den laufenden Betrieb des Auftrag- nehmers Rücksicht zu nehmen. Die Parteien sind sich darüber einig, dass die Ab- wicklung des laufenden Geschäftsbetriebes des Auftragnehmers stets vorrangig vor einer Prüfung des Auftraggebers ist. Dem Auftraggeber wird im Rahmen der Prüfung nur Zugriff auf die Daten (keine finanziellen Daten) gewährt, die ausschließlich die Leistung des Auftragnehmers für den Auftraggeber nach diesem Vertrag betreffen. In keinem Fall hat der Auftraggeber ein Einsichts- oder sonstiges Prüfungsrecht in Be- zug auf Daten etc. anderer Kunden des Auftragnehmers. Die Prüfung hat durch Mit- arbeiter des Auftraggebers selbst oder durch einen unabhängigen, zugunsten des Auftragnehmers zur Geheimhaltung verpflichteten Dritten zu erfolgen, der in keinem Fall für ein Konkurrenzunternehmen des Auftragnehmers tätig sein darf.

(2) Sollten dem Auftragnehmer im Zusammenhang mit den vorstehenden Regelungen Kosten oder sonstige Aufwendungen entstehen, ist der Auftraggeber verpflichtet, die- se in voller Höhe zu vergüten.

§ 29 Schlussbestimmungen

(1) Der ausschließliche Gerichtsstand für alle Streitigkeiten aus oder in Zusammenhang mit diesem Vertrag ist Köln.

(2) Dieser Vertrag unterliegt deutschem Recht. Allgemeine Geschäfts-, Liefer- oder Zah- lungsbedingungen des Auftragnehmers werden nicht Vertragsbestandteil.

(3) Treten im Zusammenhang mit den vertragsgegenständlichen Leistungen Meinungs- verschiedenheiten auf, werden die Vertragsparteien angemessene Anstrengungen unternehmen, um eine außergerichtliche Einigung zu erzielen. Können die Vertrags- parteien Meinungsverschiedenheiten auf der jeweiligen Arbeitsebene nicht klären, findet eine Eskalation auf die nächst höhere Managementebene statt und lässt sich auch auf dieser Ebene keine einvernehmliche Lösung finden, erfolgt eine Eskalation auf die Geschäftsführungsebene. Jede Vertragspartei ist frühestens 60 Tage nach Einleitung des vorgenannten Streit- beilegungsverfahrens berechtigt, den ordentlichen Rechtsweg zu beschreiten. Das Recht der Vertragsparteien, um einstweiligen Rechtsschutz nachzusuchen, bleibt von der Pflicht, ein Streitbeilegungsverfahren durchzuführen, unberührt.

(4) Sollte eine der jetzt oder in Zukunft in diesem Vertrag enthaltenen Bestimmungen unwirksam oder nicht durchsetzbar sein oder werden, berührt dies nicht die Wirksam- keit der übrigen Bestimmungen. Dies gilt entsprechend im Fall von Vertragslücken. Anstelle der unwirksamen oder nicht durchsetzbaren Bestimmung bzw. zur Ausfül- lung einer Lücke gilt eine angemessene Bestimmung, die dem am nächsten kommt, was die Parteien entsprechend dem Vertragszweck gewollt hätten, wenn sie diesen Umstand bei Abschluss dieses Vertrages bereits berücksichtigt hätten.

(5) Änderungen dieses Vertrages sowie Kündigungserklärungen bedürfen der Schriftform unter Ausschluss der telekommunikativen Übermittlung. Dies gilt auch für die Abän- derung des Schriftformerfordernisses.

74

[Seite 83]

Anlage 27

(((eTicket Deutschland

§ 30 Anlagen

(1) Folgende Anlagen sind integrale Bestandteile dieses Vertrages:

• Anlage 1a: Rahmenbedingungen
• Anlage 1b: Lastenheft KOSES
• Anlage 1c: Lastenheft Vermittlungsstelle Anlage 1d: Kriterienkatalog
• Anlage 2: Angebot des Auftragnehmers vom 02.06.2010, inkl. Überarbeitung vom 23.06.2010 und vom 05.07.2010 nebst Nachreichung vom 06.07.2010 Anlage 3: VDV KA-Dokumentation
• Anlage 4: Aufzeichnungen zum Pflichtenheft für die Anwendung „KOSES“ und die Anwendung „Vermittlungsstelle“ (Platzhalter)
• Anlage 5: Pflichtenheft zur Anwendung „KOSES“ und zur Anwendung „Vermittlungsstelle“ (Platzhalter)
• Anlage 6: Änderungsprotokolle zur Anwendung „KOSES“ und zur Anwendung „Vermittlungsstelle“ (Platzhalter)
• Anlage 7: Service Levels und nichtfunktionale Anforderungen
• Anlage 8: Reduzierung der Vergütung bei der Verfehlung von Leistungsparametern und / oder Terminen
• Anlage 9: Vergütung
• Anlage 10: Haftung

(2) Im Falle von Widersprüchen zwischen den Regelungen dieses Vertrages und der Anlagen gehen die Regelungen dieses Vertrages vor.

Köln, 20. Juli 2010 Aachen, 20. Juli 2010

VDV eTicket Service GmbH & Co. KG Auftragnehmer

75

[Seite 84]

Anlage 27

(((eTicket Deutschland

Anlage 3 zum Vertrag über die Erstellung, Pflege und den Betrieb des zentralen Sperrlistenser- vices KOSE und der Anwendung „Vermittlungsstelle“ im Rahmen des (((eTicket- Deutschlands

Die VDV KA-Dokumentation besteht aus den nachfolgend genannten Dokumenten in ihrer jeweils gültigen Fassung:

76

[Seite 85]

Anlage 27

(((eTicket Deutschland

77

[Seite 86]

Anlage 27

(((eTicket Deutschland

Anlage 7 zum Vertrag über die Erstellung, Pflege und den Betrieb des zentralen Sperrlistenser- vices KOSE und der Anwendung „Vermittlungsstelle“ im Rahmen des (((eTicket- Deutschlands

Service Levels und nichtfunktionale Anforderungen

I. Übergabe der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“

Der Auftragnehmer stellt dem Auftraggeber bis spätestens zum 03.01.2011 die voll funktionsfähige Anwendung „KOSES“ und die voll funktionsfähige Anwendung „Ver- mittlungsstelle“ gemäß § 4 zur Verfügung.

II. Aufnahme des KOSES-Betriebs und des Vermittlungsstelle-Betriebs gemäß § 11 Abs. 2

Der Auftragnehmer hat sicherzustellen, dass der KOSES-Betrieb und der Vermitt- lungsstelle-Betrieb spätestens am 03.01.2011, 0 Uhr, in vollem Umfang aufgenom- men wird.

III. Leistungsparameter

1. Begriffsbestimmungen

Ausfall Jeder zusammenhängende Zeitraum von min- destens 300 Sekunden, in dem keine Transakti- onen entgegen genommen oder beantwortet werden können, beginnend mit der letzten ent- gegen genommenen bzw. beantworteten Trans- aktion und endend mit dem Wiederherstellungs- zeitpunkt.

Ausfallzeit Die Summe aller Ausfälle, die während einer Zeitperiode auftreten.

Funktionsstörung / Softwaremangel Kategorie A Jede(r) betriebsverhindernde(r) Funktionsstörung / Softwaremangel, bei der / dem die Nutzung der Anwendung „KOSES“ und/oder der Anwendung „Vermittlungsstelle“ für den Auftraggeber und/oder einzelne oder alle Teilnehmer unmög- lich ist oder schwerwiegend eingeschränkt wird (z. B. aufgrund von Fehlfunktionen, falschen Ar- beitsergebnisses, Antwortzeiten).

Funktionsstörung / Softwaremangel Kategorie B Jede(r) nicht nur unerhebliche(r) betriebsbehin- dernde(r) Funktionsstörung / Softwaremangel, bei der / dem die Nutzung der Anwendung „KOSES“ und/oder der Anwendung „Vermitt- 78

[Seite 87]

Anlage 27

(((eTicket Deutschland

lungsstelle“ für den Auftraggeber und/oder ein- zelne oder alle Teilnehmer zwar nicht unmöglich ist oder schwerwiegend eingeschränkt wird, die Nutzungseinschränkungen aber zugleich auch nicht nur unerheblich sind und mit zumutbaren organisatorischen oder sonstigen wirtschaftlich zumutbaren Mitteln nicht umgangen werden kön- nen.

Funktionsstörung / Softwaremangel / Sonstiger Softwarefehler Kategorie C Funktionsstörung / Softwaremangel / Sonstiger Softwarefehler, die/der nicht einer der Kategorien A oder B zuzuordnen ist.

Monat Jeder beliebige zusammenhängende Zeitraum von 720 Stunden.

Tag Jeder beliebige zusammenhängende Zeitraum von 24 Stunden.

Transaktion Jeder Transaktionsdatensatz im Sinne des Las- tenheftes Sperrlistenservice-System (KOSES) (Anlage 1b) bzw. jede die Anwendung „Vermitt- lungsstelle“ betreffende Datentransaktion im Sin- ne des Lastenheftes Vermittlungsstelle (Anlage 1c).

Transaktionsentgegennahme Der Vorgang der automatisierten Bestätigung des Eingangs einer Transaktion durch das IT- System des Auftraggebers.

Transaktionsbearbeitung Der Vorgang der Verarbeitung einer Transaktion durch das IT-System des Auftraggebers und an- schließender Übermittlung des Verarbeitungser- gebnisses an die dafür vorgesehene Empfänger- adresse.

Wiederherstellungsfrist Die Zeitspanne zwischen dem Beginn des Aus- falls bzw. dem Auftreten des Softwaremangels oder des sonstigen Softwarefehlers und dem Wiederherstellungszeitpunkt.

Wiederherstellungszeitpunkt Der Zeitpunkt, in dem nach einem vorhergehen- den Ausfall wieder eine Transaktion entgegen genommen bzw. beantwortet wird bzw. ein Soft- waremangel oder ein sonstiger Softwarefehler behoben ist.

Woche Jeder beliebige zusammenhängende Zeitraum von 168 Stunden.

79

[Seite 88]

Anlage 27

(((eTicket Deutschland

2. Mindestverfügbarkeit

Die Verfügbarkeit eines technischen Systems ist das Maß, in dem das System be- stimmte Anforderungen innerhalb eines vereinbarten Zeitrahmens erfüllt. Sie wird nach folgender Formel berechnet:

Verfügbarkeit = (Gesamtbetriebszeit – Gesamtausfallzeit) / Gesamtbetriebszeit,

wobei die Gesamtbetriebszeit definiert ist als die Betriebszeit abzüglich der War- tungsfenster (s.u.).

Die Mindestverfügbarkeit der Anwendung „KOSES“ und der Anwendung „Ver- mittlungsstelle“ darf 98% pro Tag nicht unterschreiten.

Zusätzlich dürfen folgende Parameter nicht überschritten werden:  Maximal-Anzahl von Ausfällen pro Tag: 6 Stück  Maximal-Ausfallzeit pro Tag: 30 Minuten

3. Servicezeit

Die Servicezeit beträgt Montag bis Freitag, 08.00 - 18.00 Uhr, sowie Samstag, Sonn- und Feiertage 09.00 – 14.00 Uhr

4. Betriebszeit

Die Betriebszeit beträgt grundsätzlich 7x24h (ausgenommen Wartungsfenster)

5. Wartungsfenster

Das Wartungsfenster liegt jeweils außerhalb der Servicezeiten von Montag bis Donnerstag vor 24 Uhr.

6. Reaktionszeiten

Pro Tag müssen 100% aller eingehenden Transaktionen innerhalb von max. 5 Sekunden entgegen genommen werden (Transaktionsentgegennahme).

7. Antwortzeiten

Die Server für die Anwendung „KOSES“ und die Anwendung “Vermittlungsstelle“ müssen mit hinreichender Kapazität (mindestens 10 MBit/s) an das Internet ange- bunden sein. Diese Kapazität muss mit steigendem Teilnehmeraufkommen erforderli- chenfalls erweiterbar sein.

Die synchronen Antwortzeiten der Anwendung „KOSES“ und der Anwendung „Ver- mittlungsstelle“ gegenüber einer Online-Anfrage dürfen maximal 5 Sekunden betra- gen.

Pro Tag müssen 100% aller eingehenden Transaktionen innerhalb 80

[Seite 89]

Anlage 27

(((eTicket Deutschland

von max. 5 Sekunden beantwortet werden (Transaktionsbearbeitung).

8. Anforderungen an die Sicherheit des Rechenzentrumsbetriebes

Das Serversystem ist in einem Sicherheitsraum oder Sicherheitsgehäuse mit Ein- bruchschutz unterzubringen, das folgende Anforderungen erfüllt: • Mittlerer Schutz gegen Feuer, Wasser, Rauchgase und Diebstahl, insbesondere Brandschutzwertigkeit (C 60 D), geprüft in Anlehnung an EN 1047-2 mit Löscheinrichtung • Unterbrechungsfreie Stromversorgung (mind. 30 min) • Vollklimatisierung mit Klimaredundanz

Der Zugriff durch ausschließlich autorisiertes Personal muss organisatorisch und technisch sicher gestellt sein.

a) Gefordertes Sicherheitsniveau

Das insgesamt geforderte Sicherheitsniveau ist „Mittel“. In der Anwendung „KOSES“ und in der Anwendung „Vermittlungsstelle liegen keine Daten vor, die es ermöglichen irgendeinen Bezug zu einem Endkunden oder einem Mitarbeiter eines beteiligten Unternehmens herzustellen. Sämtliche Erkennungs- merkmale sind über externe Identifier gekennzeichnet, zu denen diese Systeme nicht über Referenzdaten verfügen.

b) Katastrophenfall

Die geforderte Wiederherstellungsklasse im Katastrophenfall ist „Cold Standby“ mit einer zulässigen Ausfallzeit von 5 Tagen.

c) Wiederherstellbarkeit

Ein Systemausfall darf nicht zum Verlust von Daten führen. Es dürfen keine Nachrichten verloren gehen oder doppelt zugestellt werden, eine einzelne Nachricht darf also nur genau einmal zugestellt werden. Die Güte für diesen Dienst der Zustellung von Nachrichten trägt die Bezeichnung ' Exactly Once'. Desweiteren sollen die Nachrichten in der Reihenfolge ihres Eingangs verarbeitet und zugestellt werden (FIFO).

9. Wiederherstellungsfristen Funktionsstörung, Softwaremangel / Sonstiger Soft- warefehler

 Funktionsstörung / Softwaremangel Kategorie A: 240 Minuten 81

[Seite 90]

Anlage 27

(((eTicket Deutschland

 Funktionsstörung / Softwaremangel Kategorie B: 24 Stunden  Funktionsstörung / Softwaremangel Kategorie C: 48 Stunden

10. Kapazität

Mittlere Anzahl Transaktionen pro Teilnehmer und Tag: 5.000 Transaktionen Max. Anzahl gleichzeitiger Transaktionen pro Teilnehmer: 20 Sessions

Mengengerüst (geschätzt):

Es ist durch technische oder organisatorische Maßnahmen sicherzustellen, dass die Systeme der Teilnehmer in ihrem Zeitverhalten so koordiniert werden, dass intern keine wesentlichen Peaks entstehen.

11. Verbrauchsverhalten Generell ist zu gewährleisten, dass wenn die Anwendung „KOSES“ und die Anwendung “Vermittlungsstelle“ nicht erreichbar sind, die Systeme der Teil- nehmer (beispielsweise AH-, PV-, KVP- und DL-Systeme) davon unabhängig wei- ter arbeiten können.

12. Skalierbarkeit Die Anwendung „KOSES“ und die Anwendung „Vermittlungsstelle“ müssen „gut“ skalierbar sein. Begründung: a) Es ist mit einer zunehmenden Nutzung von (((eTickets beim Endverbraucher zu rechnen. b) Die Anwendung „KOSES“ und die Anwendung „Vermittlungsstelle“ müssen zusätzliche Verbünde und Verkehrsunternehmen mit anbinden können.

13. Wartbarkeit

Zu beachten sind die möglichen Erweiterungen für zukünftige Releases.  Es ist davon auszugehen, dass das KOSES insbesondere in den nächsten 2-3 Jahren noch erweitert und angepasst wird.  Es sind max. 2 wesentliche Releases pro Jahr geplant. Somit ist über die Dauer von vier Jahren von maximal 8 Releases auszugehen.

82

[Seite 91]

Anlage 27

(((eTicket Deutschland

14. Schnittstellen

Implementierung der Außenschnittstellen erfolgt nach Spezifikation VDV-KA (Stand V1.107). Interne Schnittstellen müssen nicht VDV-KA konform sein, sofern zum Zeit punkt der Angebotsabgabe keine Spezifikation nach VDV-KA hierfür vorliegt.

15. Archivierung

Außerhalb der Systemsicherungen (Backup) werden im Archivierungssinn keine Daten archiviert, d.h. Daten werden nicht auf externen Medien archiviert. Der Auftragnehmer hat Logfiles und Daten für die Dauer von 12 Monaten aufzubewahren. Nach 12 Monaten hat er die Daten unwiederbringlich aus dem System zu entfernen. Die Aufbewahrung der Daten dient lediglich einer späteren Nachvollziehbarkeit und evtl. Beweisführung. Statistische Nachweise werden entweder über das Standardmonitoring der Anwen- dungen „KOSES“ und “Vermittlungsstelle“ erbracht, auf das der Auftraggeber mittels einer geeigneten Benutzeroberfläche zugreifen kann oder durch zusätzliche Abfragen gegen die Daten in einem zu vereinbarenden Zeitraum erzeugt.

83

[Seite 92]

Anlage 27

(((eTicket Deutschland

Anlage 8 zum Vertrag über die Erstellung, Pflege und den Betrieb des zentralen Sperrlistenser- vices KOSE und der Anwendung „Vermittlungsstelle“ im Rahmen des (((eTicket- Deutschlands

Höhe der Minderung bei Pflichtverletzungen

I. Reduzierung der Vergütung bei verspäteter Übergabe der Anwendung „KOSES“ und/oder der Anwendung „Vermittlungsstelle“

Für jeden Tag des Überschreitens des in der Anlage 7 vereinbarten Termins zur Übergabe der Anwendung „KOSES“ und/oder der Anwendung „Vermittlungsstelle“ nach § 4 reduziert sich das von dem Auftraggeber an den Auftragnehmer zu zahlende Softwareerstellungs-Entgelt um 0,1 % des Softwareerstellungs-Entgelts (netto), höchstens jedoch um 5 % des Softwareerstellungs-Entgelts (netto).

II. Reduzierung der Vergütung bei verspäteter Aufnahme des KOSES-Betriebs und/oder des Vermittlungsstellen-Betriebs

Für jeden Tag des Überschreitens des in der Anlage 7 vereinbarten Termins zur Auf- nahme des KOSES-Betriebs und/oder des Vermittlungsstellen-Betriebs nach § 11 Abs. 2 reduziert sich das von dem Auftraggeber an den Auftragnehmer zu zahlende RZ-Entgelt um 1 % des jährlichen RZ-Entgelts (netto) für bis zu 500 angebundenen Teilnehmern, höchstens jedoch um 10 % des RZ-Entgelts, das im Falle von bis zu 500 angebundenen Teilnehmern für ein volles Jahr der Betriebsphase im Sinne des § 14 Abs. 1 Satz 1 geschuldet wäre.

III. Reduzierung der Vergütung bei der Verfehlung von Leistungsparametern

Für jede verschuldete Nichteinhaltung der vereinbarten Leistungsparameter (Service- Levels) für die Mindestverfügbarkeit, die Wiederherstellungsfristen, die Softwaremän- gel (der jeweiligen Kategorien A, B und C) sowie für die Reaktionszeiten gemäß An- lage 7 reduziert sich das monatliche Betriebsentgelt nach Maßgabe der nachfolgen- den Staffelung:  Unterschreitung eines/mehrerer Service Levels bis 10%: 0,1 % des Betriebsent- gelts der letzten zwölf Monate (netto)  Unterschreitung eines/mehrerer Service Levels über 10% bis 50%: 0,2 % des Be- triebsentgelts der letzten zwölf Monate (netto)  Unterschreitung eines/mehrerer Service Levels über 50% bis 100%: 1 % des Be- triebsentgelts der letzten zwölf Monate (netto)  Unterschreitung eines/mehrerer Service Levels über 100%: 2 % des Betriebsent- gelts der letzten zwölf Monate (netto) (pro angefangene 100% Unterschreitung)

Nichteinhaltung mehrerer Service Levels

Sofern durch ein einzelnes Ereignis mehrere Service Levels nicht eingehalten wer- den, wird jeweils nur diejenige Nichteinhaltung berücksichtigt, für die die höchste Ver- gütungsreduzierung anfällt.

84

[Seite 93]

Anlage 27

(((eTicket Deutschland

Anlage 9 zum Vertrag über die Erstellung, Pflege und den Betrieb des zentralen Sperrlistenser- vices KOSE und der Anwendung „Vermittlungsstelle“ im Rahmen des (((eTicket- Deutschlands

Vergütungszusammenfassung

1. Softwareerstellung

a) Für die nach Abschnitt C) zu erbringenden Leistungen hat der Auftraggeber an den Auftragnehmer ein Pauschalentgelt (im Folgenden: „Softwareerstellungs-Entgelt“) in Höhe von _______ Euro zu bezahlen.

Hiervon sind Personalkosten: Euro.

Durch die Zahlung des Softwareerstellungs-Entgelts werden sämtliche Leistungen, die der Auftragnehmer nach Abschnitt C) erbracht hat, abgegolten.

Das Softwareerstellungs-Entgelt ist in folgenden Teilbeträgen zu bezahlen:  Vorlage des Pflichtenheftes (§ 1 Absatz 7) 20% des Softwareerstellungs-Entgeltes = _______ Euro  Erteilung der Verabschiedungsanzeige (§ 1 Absatz 7) 10% des Softwareerstellungs-Entgeltes = _______ Euro  Übergabe der Anwendungen „KOSES“ und „Vermittlungsstelle“ und Dokumentati- on (§ 4) 20% des Softwareerstellungs-Entgeltes = _______ Euro  Abnahme der Anwendungen „KOSES“ und „Vermittlungsstelle“ und Dokumentati- on (§ 5) 50% des Softwareerstellungs-Entgeltes = _______ Euro

Der Auftragnehmer wird dem Auftraggeber den jeweils fälligen Teilbetrag des Soft- wareerstellungs-Entgelts am Ende des jeweiligen Kalendermonats in Rechnung stel- len, in dem der vergütungsauslösende Umstand eintritt. Der in Rechnung gestellte Teilbetrag ist innerhalb von 30 Tagen nach Zugang der Rechnung beim Auftraggeber zur Zahlung fällig.

b) Sofern und soweit gemäß § 3 Absatz 3 ggf. in Verbindung mit Absatz 6 infolge eines Änderungsverlangens eine Anpassung der vertraglichen Vergütung erforderlich wird, wird ein Vergütungssatz in Höhe von ____ Euro pro Manntag zugrunde gelegt. Ein Manntag umfasst 8 Arbeitsstunden. Mit der Vergütung sind sämtliche Aufwendungen des Auftragnehmers abgegolten.

c) Option: Web-fähige Bedienoberfläche für 1st-Level-Support durch Teilnehmer (s. Rahmenbedingungen, Ziffer 12)

Für die Erstellung einer Web-fähigen Bedienoberfläche hat der Auftraggeber an den Auftragnehmer ein Pauschalentgelt in Höhe von _______ Euro zu bezahlen.

Hiervon sind Personalkosten: Euro.

85

[Seite 94]

Anlage 27

(((eTicket Deutschland

2. Betriebsentgelt

Das jährliche Betriebsentgelt bemisst sich nach dem Zwölffachen des monatlichen Softwarepflege-Entgelts (s.u. Ziff. 3 a)) addiert mit dem Zwölffachen des durchschnitt- lichen monatlichen RZ-Entgelts (s.u. Ziff. 4) der vergangenen 12 Monate Vertrags- laufzeit. Besteht der Vertrag noch nicht 12 Monate, so ist auf das RZ-Entgelt abzu- stellen, das im Falle von bis zu 500 angebundenen Teilnehmern für ein volles Jahr der Betriebsphase im Sinne des § 14 Abs. 1 Satz 1 geschuldet wäre.

3. Softwarepflege

a) Für die nach Abschnitt D) zu erbringenden Wartungsleistungen gemäß § 8 und Ände- rungsleistungen gemäß § 9 Abs. 1 hat der Auftraggeber an den Auftragnehmer ein kalendermonatliches Pauschalentgelt (im Folgenden: „Softwarepflege-Entgelt“) zu bezahlen. Durch die Zahlung des Softwarepflege-Entgelts werden sämtliche War- tungsleistungen gemäß § 8 und sämtliche Änderungsleistungen gemäß § 9 Abs. 1, die der Auftragnehmer nach Abschnitt D) erbracht hat, abgegolten. Der Auftragneh- mer wird dem Auftraggeber das Softwarepflege-Entgelt am Ende eines jeden Kalen- dermonats in Rechnung stellen, beginnend mit dem Ende des Kalendermonats, der auf die Abnahme der Anwendung „KOSES“ und der Anwendung „Vermittlungsstelle“ nach § 5 des Vertrages erfolgt. Das Softwarepflege-Entgelt ist innerhalb von 30 Ta- gen nach Zugang der Rechnung beim Auftraggeber zur Zahlung fällig.

Softwarepflege-Entgelt (pro Kalendermonat): _______ Euro.

Hiervon sind Personalkosten: Euro.

b) Der Vergütungssatz für zusätzliche Änderungsleistungen gemäß § 9 Absatz 2 beträgt _____ Euro pro Manntag. Ein Manntag umfasst 8 Arbeitsstunden. Mit der Vergütung sind sämtliche Aufwendungen des Auftragnehmers abgegolten.

4. Rechenzentrumsbetrieb

Für die nach Abschnitt E) zu erbringenden Leistungen hat der Auftraggeber an den Auftragnehmer ein kalendermonatliches Pauschalentgelt (im Folgenden: „RZ- Entgelt“) zu bezahlen. Durch die Zahlung RZ-Entgelts werden sämtliche Leistungen, die der Auftragnehmer nach Abschnitt E) erbracht hat, abgegolten. Davon ist auch der Aufwand, der durch den Anschluss der Teilnehmer an das System entsteht, um- fasst. Der Auftragnehmer wird dem Auftraggeber das RZ-Entgelt am Ende eines je- den Kalendermonats in Rechnung stellen, beginnend mit dem Ende des Kalender- monats, in dem der KOSES-Betrieb und der Vermittlungsstelle-Betrieb gemäß § 14 Absatz 1 aufgenommen wurde. Das RZ-Entgelt ist innerhalb von 30 Tagen nach Zu- gang der Rechnung beim Auftraggeber zur Zahlung fällig. Maßgeblich für die Berech- nung des RZ-Entgelts ist die Anzahl der angebundenen Teilnehmer am Ende des je- weiligen Kalendermonats.

86

[Seite 95]

Anlage 27

(((eTicket Deutschland

RZ-Entgelt (pro Kalendermonat):

Bis zu 500 Teilnehmer: _______ Euro; hiervon sind Personalkosten: €;

500 - 900 Teilnehmer: _______ Euro; hiervon sind Personalkosten: €;

900 - 1100 Teilnehmer: _______ Euro; hiervon sind Personalkosten: €;

1100-1300 Teilnehmer: _______ Euro; hiervon sind Personalkosten: €;

Über 1300 Teilnehmer: _______ Euro; hiervon sind Personalkosten: €;

Alle Preise in dieser Vergütungszusammenfassung verstehen sich zzgl. der geltenden gesetzlichen Mehrwertsteuer.

Hinweis bezüglich der Abrechnung der Personalkosten:

Die vorstehenden Leistungen werden teilweise als Teil eines Forschungs- und Entwick- lungsvorhaben in Auftrag gegeben. Für diesen Teil der Gesamtleistung gelten deshalb die nachfolgenden Regelungen des BEBF 98 bezüglich aller Personalkosten.

Auszug BEBF 98:

87

[Seite 96]

Anlage 27

(((eTicket Deutschland

Anlage 10 zum Vertrag über die Erstellung, Pflege und den Betrieb des zentralen Sperrlistenser- vices KOSE und der Anwendung „Vermittlungsstelle“ im Rahmen des (((eTicket- Deutschlands

Haftung

1. Haftungshöchstbeträge

 Haftungshöchstbetrag pro Schadensfall: 20 % der zum Zeitpunkt des Schadens- falles aktuellen monatlichen Betriebskostenpauschale (Softwarepflege- und RZ- Entgelt)  Maximal jedoch pro Kalenderjahr: 30 % der zum Zeitpunkt des Schadensfalles ak- tuellen jährlichen Betriebskostenpauschale (Softwarepflege- und RZ-Entgelt eines Jahres)  In Fällen des § 25 III, IV beträgt der maximale Haftungshöchstbetrag pro Kalen- derjahr 70% der zum Zeitpunkt des Schadensfalles aktuellen jährlichen Betriebs- kostenpauschale (Softwarepflege- und RZ-Entgelt eines Jahres)

88

[Seite 97]

Anlage 27

(((eTicket Deutschland

Kapitel 9: KA Release Management

1. Einführung

1.1. ITIL als Grundlage

Das in der 2. Hälfte des 20. Jahrhunderts entstandene IT-Betriebsmodell kannte die Informa- tionstechnik als zentrale Back Office-Funktion. Die Geschwindigkeit der Prozessänderungen, der technische Fortschritt und die Tatsache, dass IT-Services heute ortsunabhängig 7x24 Stunden bereit gestellt werden müssen, verlangt nach einer effektiveren Organisation von IT- Services als bisher.

Ende der 80er Jahre des 20. Jahrhunderts entstand aus ähnlichen Anforderungen der briti- schen Regierung eine Sammlung von Good Practices und Best Practices, wie IT-Services bereitgestellt und gemanagt werden sollten. Diese Sammlung wurde unter dem Acronym „ITIL“ bekannt, welches in Langform „IT Infrastructure Library“ bedeutet.

ITIL beschreibt die für den Betrieb einer IT-Infrastruktur notwendigen Prozesse, die Aufbau- organisation und die Werkzeuge. Sie orientiert sich an dem durch den IT-Betrieb zu erbrin- genden wirtschaftlichen Mehrwert für den Kunden. Dabei werden Planung, Erbringung, Un- terstützung und Effizienz-Optimierung von IT-Serviceleistungen als relevante Faktoren zur Erreichung der Geschäftsziele des Unternehmens betrachtet.

ITIL hat sich mittlerweile zum internationalen De-facto-Standard für den IT-Betrieb entwickelt. Mit der Aufnahme des Wirkbetriebes von zentralen IT-Systemen für das (((eTicket Deutsch- land sowie der steigenden Anzahl von Umsetzungsprojekten des (((eTicket Deutschland stellt sich auch für die VDV eTicket Service GmbH & Co. KG (VDV-ETS) die Frage nach ei- nem IT-Betriebsmodell. Da es sich bei der VDV-Kernapplikation um den nationalen Standard in Deutschland für elektronisches Fahrgeldmanagement handelt, erscheint es logisch, für dessen nun beginnenden Betrieb den internationalen De-facto-Standard zu verwenden.

1.2. Release Management als Teil der ITIL

Die ITIL gliedert sich in zwei 2 Kernbereiche: Service Support und Service Delivery.

Der Bereich Service Support umfasst den Betrieb und die Aufrechterhaltung von IT-Services. Der Bereich Service Delivery umfasst die Erreichung und Verbesserung solcher Services. Beide Bereiche umfassen jeweils fünf 5 Schlüsselprozesse.

In den Bereich Service Support fallen die Prozesse  Incident-Management,  Problem-Management,  Change-Management,  Release-Management und  Configuration-Management.

Nachdem von Beginn der Entwicklung der KA an sämtliche Änderungen und Weiterentwick- lungen durch den Change Management-Prozess gesteuert werden, macht jetzt die zuneh- mende Anzahl von Umsetzungsprojekte sowie die Einführung zentraler, operativer Systeme die Einführung des Release Managements erforderlich.

89

[Seite 98]

Anlage 27

(((eTicket Deutschland

Das Configuration Management wird durch die VDV-ETS für die KA-Spezifikationen zu dem Zeitpunkt aufgenommen, in dem die ersten Planungen für die nächsten KA-Releases begin- nen. Über KA-internes Incident Management und Problem Management ist noch zu beraten. Für die operativen Systeme der VDV-ETS werden die Service Support- und Service De- livery-Prozesse durch die Systembetreiber abgedeckt.

90

[Seite 99]

Anlage 27

(((eTicket Deutschland

2. Release Management der KA

2.1 Allgemeine Festlegungen

Die Releases der Kernapplikation werden in drei Kategorien unterteilt. Es handelt sich dabei um die Kategorien:

• Version,
• Servicepaket und
• Korrektur.

Um eine einheitliche Namenskonvention zu gewährleisten, enthält die Angabe der Release- nummer immer 3 Zifferngruppen. Die erste Zifferngruppe beschreibt die Version, die zweite das Servicepaket, die dritte mögliche Korrekturen. Alle Zifferngruppen werden ohne führende Null verwendet, um unnötige Beschränkungen zu vermeiden und eine einfache Nutzung in den Releasemanagementwerkzeugen der technischen Systeme zu ermöglichen.

Ein Release bzw. eine Releasenummer ist somit eine Zusammenfassung von Version, Ser- vicepaket und Korrektur.

Die Definitionen der drei Kategorien werden in diesem Kapitel umfassend erläutert.

Vorab soll bereits hier eine Kurzdefinition gegeben werden:

• Eine neue Version wird frühestens alle 5 Jahre in Betrieb genommen und wird charakterisiert durch Änderungen, die die Interoperabilität (vgl. KA-Glossar In- teroperabilität Punkt a) aller KA-Systeme und -Komponenten betreffen. Die Re- leasenummer ändert sich in der Zifferngruppe vor dem ersten Punkt und die fol- genden Zifferngruppen beginnen wieder mit „0“, z.B. von „4.4.9“ auf „5.0.0“.

• Ein Servicepaket erscheint in der Regel einmal jährlich und umfasst Änderungen, die keinen Einfluss auf die Interoperabilität aller KA-Systeme und -Komponenten haben. Die Releasenummer ändert sich an der Zifferngruppe hinter dem ersten Punkt und die letzte Zifferngruppe wird auf „0“ gesetzt, z.B. von „4.4.9“ auf „4.5.0“.

• Korrekturen stellen in der Regel Fehlerbehebungen dar, die dringend für den kor- rekten Betrieb der Systeme erforderlich sind. Sie können jederzeit erfolgen. Die Versionsnummer wird in der dritten Zifferngruppe hochgezählt, z.B. von „5.1.8“ auf „5.1.9“.

2.1.1 Basisrelease

Das Basisrelease ist immer das erste Release der neuen Version. Für Version 3 ist das das Release 3.0.0. Werden später Fehlerkorrekturen eingeführt, handelt es sich immer noch um die Funktionalität des Basisreleases, dann aber mit dem Namenszusatz „Fehlerkorrektur X“; also z.B. Release 3.0.2: Basisrelease 3 Fehlerkorrektur 2.

91

[Seite 100]

Anlage 27

(((eTicket Deutschland

2.1.2 Die Kompatibilitätsmatrix

Diese Matrix geht auf die möglichen Änderungen innerhalb von ION- Schnittstellenkomponenten ein und legt fest, wann es sich um eine abwärtskompatible Er- weiterung (Fehlerkorrektur oder Service-Pack) handelt und bei welcher Änderung die Einfüh- rung einer neuen Version notwendig wird.

Tabelle 1: Kompatibilitätsmatrix

2.1.3 Syntax der Nummerierung der KA-Spezifikationsdokumente

Bezüglich der Nummerierung der Dokumente während der Erstellung, also für die Arbeits- versionen, wird die Festlegung getroffen, dass die entsprechenden Dokumente als Entwurf gekennzeichnet werden und zusätzlich zur neuen Releasenummer eine fortlaufend aufstei- gende Nummer im Dateinamen führen, z.B. KA SPEC-NM_2.1.10_1.

Sobald ein Dokument für ein neues Release abgeschlossen ist, entfällt die Entwurfsangabe und es wird nur noch die neue Releasenummer geführt. Zusätzlich wird, wie bisher und ne- ben anderen Angaben, das Datum der Veröffentlichung auf dem Deckblatt des Dokumentes angegeben.

92

[Seite 101]

Anlage 27

(((eTicket Deutschland

Sobald ein KA-Dokument durch eine neue Version, ein neues Servicepaket oder eine Kor- rektur eine neue Releasenummer erhält, werden die Releasenummern aller KA-Dokumente angeglichen, auch wenn in einem Dokument keine Änderungen vorgenommen wurden. Sol- che Änderungen werden, wie bisher, gesondert in der Sektion „Versionsverwaltung“ des Do- kumentes vermerkt.

2.1.4 CR-Verfahren

Gemäß Teilnahmevertrag ist das CR-Verfahren wie folgt festgelegt:

• Empfehlung eines CR durch die AG-S mit Zuordnung zum Release

• Weiterleitung des empfohlenen CR an die Geschäftsführung der VDV-ETS zur Freigabe

• Freigabe zur Beschlussfassung durch die Geschäftsführung der VDV-ETS

• Beschlussfassung durch die Teilnehmerversammlung und bei Einführung einer neuen Version im Anschluss daran zusätzlich Beschlussfassung durch die Ge- sellschafterversammlung der VDV-ETS

• Ausfertigung und Inkraftsetzung3 des CR durch die Geschäftsführung der VDV- ETS

2.1.5 Ablauf und Fristen

Damit ergibt sich für die Umsetzung der Beschlüsse der Teilnehmerversammlung bzw. Ge- sellschafterversammlung folgender Ablauf für das Releasemanagement:

• „Ankündigung“ eines oder mehrerer Releases mit den zugeordneten CR unmit- telbar nach der Teilnehmerversammlung bzw. Gesellschafterversammlung

• „Veröffentlichung“ der Dokumente zum Release, sobald alle dem Release zuge- ordneten CR eingearbeitet und im zugehörigen Release-Letter dokumentiert sind;

• ggf. gleichzeitig „Abkündigung“ einer alten Version

• mit Veröffentlichung beginnen die Fristen des Releasemanagements zu laufen

• mit Veröffentlichung ist ein neues Release gültig.

3 Inkraftsetzen wird im Sinne von Verbindlichmachen verstanden. 93

[Seite 102]

Anlage 27

(((eTicket Deutschland

94

[Seite 103]

Anlage 27

(((eTicket Deutschland

Abbildung 1: Release Management - Ablauf

Der Prozess „Release ankündigen“ ist in Abbildung 2 dargestellt.

95

[Seite 104]

Anlage 27

(((eTicket Deutschland

Abbildung 2: Release Management – Release ankündigen

Die Ankündigung eines neuen Releases, sowie die Abkündigung einer bestehenden Version und die Veröffentlichung der Dokumente zum neuen Release erfolgt durch die VDV-ETS durch Information auf ihrer Web-Seite http://www.eticket-deutschland.de und per Newsletter.

Die Releaseplanung und die sich daraus für alle am (((eTicket Deutschland Beteiligten erge- benden Aktivitäten sind dem veröffentlichten Releasekalender zu entnehmen. Der Release- kalender kann auf der o.g. Web-Seite eingesehen werden.

96

[Seite 105]

Anlage 27

(((eTicket Deutschland

2.2 Version

Ein CR, der die Interoperabilität (vgl. KA-Glossar Interoperabilität Punkt a)) betrifft, führt zwingend zu einer neuen Version. Hierzu wird auch auf die Kompatibilitätsmatrix in Kap. 2.1.2 verwiesen.

Alle Beteiligten müssen diese neue Version in ihren Systemen und Komponenten ein- führen, damit die Interoperabilität gewährleistet bleibt.

Jedes KA kompatible System muss damit zwei Versionen zur gleichen Zeit unterstützen. Durch die Abwärtskompatibilität der Schnittstellenänderungen ist gewährleistet, dass für die- se Anforderung für die letzten zwei Versionen jeweils immer nur ein Release unterstützt wer- den muss. Für die alte Version ist es idealerweise das letzte Release, dies ist aber nicht ver- pflichtend. Die Umsetzung bleibt den Systemverantwortlichen vorbehalten.

Eine neue Version wird spätestens 2 Jahre vor offizieller Inbetriebnahme der benötigten, zentralen Systeme veröffentlicht. In dieser sind alle bis zum Zeitpunkt der Ankündigung der neuen Version vorhergehenden Servicepakete und Korrekturen der Vorversion sowie die dieser Version zugeordneten CRs enthalten.

Mit Veröffentlichung erfolgt die Abkündigung der Version n-2.

Zwischen zwei Versionen ist gemäß (((eTicket--Teilnahmevertrag die Abwärtskompatibilität4 nicht gewährleistet. Daher ist die Einführung einer neuen Version im gemäß Teilnahmever- trag, Anlage 1 §6 (Regelwerk) festgelegten Umsetzungszeitraum (spätestens 5 Jahre ab Veröffentlichung) für alle verpflichtend. Das heißt, dass jedes Teilnehmersystem innerhalb dieser 5 Jahre die neue Version einführen muss.

Im Übergangszeitraum bis zur kompletten Einführung der neuen Version durch alle KA- Systeme wird die Interoperabilität der Systeme durch Nutzung der Vorversion sichergestellt.

Zum Zeitpunkt der Veröffentlichung einer neuen Version n (in Abbildung 3 Release BLAU) wird die Version n-2 (in Abbildung 3 Release GRAU) abgekündigt. Dies bedeutet, dass die Version n-2 ab diesem Zeitpunkt noch mindestens 2 Jahre betrieben wird, allerdings wird sie ab dann nicht mehr weiterentwickelt (s. Abbildung 3).

4 Abwärtskompatibilität bedeutet die Verträglichkeit einer neueren Version mit einer älteren Version, so dass die störungsfreie Austauschbarkeit von Daten über die Schnittstellen der Komponenten von KA-Systemen erhalten bleibt. Bei gleicher Version ist eine kleinere Releasenummer immer ei- ne Untermenge einer größeren Releasenummer. Nur innerhalb der gemeinsamen Untermenge ist der Betrieb der Releases einer Version uneingeschränkt möglich. 97

[Seite 106]

Anlage 27

(((eTicket Deutschland

1 Dies sind Zeitmonate keine Kalendermonate!

Abbildung 3: Release Management - Versionen

Die nachfolgende Abbildung 4 veranschaulicht beispielhaft das Release Management sowie die darin vorgesehene Unterstützung von jeweils zwei Versionen.

Version Version Version

GRAU GRÜN BLAU

Abbildung 4: Release Management – Unterstützung von jeweils 2 Versionen

2.3 Servicepaket

Ein Servicepaket umfasst ausschließlich CRs, die keinen Einfluss auf die Interoperabilität haben. Das sind neue Funktionalitäten und die Behebung von Fehlern vorhandener Funktio- nalitäten, die nicht in allen Systemen umgesetzt werden müssen.

Die Einführung der neuen Funktionalitäten muss ein PV mit seinen KVP und DL abstimmen und ggf. vertraglich regeln. Die Behebung von Fehlern vorhandener Funktionalitäten ist nur verpflichtend bei der Nutzung der korrigierten Funktionalität.

98

[Seite 107]

Anlage 27

(((eTicket Deutschland

Eine neues Servicepaket muss spätestens 9 Monate vor offizieller Inbetriebnahme veröffent- licht werden. Dieser Zeitraum von 9 Monaten ergibt sich aus der benötigten Vorlaufzeit von der Veröffentlichung bis zur Inbetriebnahme der benötigten zentralen VDV-ETS-Systeme ZVM, KOSES, ASM. In einem neuen Servicepaket sind alle bis zum Zeitpunkt der Ankündi- gung des neuen Servicepaketes vorhergehenden Servicepakete und Korrekturen enthalten, sowie die diesem Servicepaket zugeordneten CRs.

Im Servicepaket ist Abwärtskompatibilität gewährleistet.

2.4 Korrektur

Eine Korrektur umfasst ausschließlich CRs, die die dringende Behebung von Fehlern vor- handener Funktionalitäten zum Anlass haben.

Die Umsetzung der Korrektur ist nur verpflichtend bei der Nutzung der korrigierten Funktio- nalität.

Eine Korrektur wird nur für das jeweils neueste Servicepaket innerhalb einer Version erstellt.

Diese Korrekturen dürfen nicht die Interoperabilität aller am eTicket Deutschland beteiligten Systeme betreffen. Ist die Interoperabilität durch die Fehlerbehebung betroffen, führt dies zu einer neuen Version. Tritt dieser Fall ein, ist eine außerordentliche Teilnehmerversammlung einzuberufen. Diese entscheidet über die Umsetzung der Änderung und damit auch über ggf. verkürzte Fristen zur Einführung einer neuen Version.

3. Content Management der Releases

Die Einordnung der CR in die Releaseplanung wird gemäß ITIL als Content Management bezeichnet. Der zugehörige Entscheidungspfad für die AG-S ist in Abbildung 5 dargestellt.

99

[Seite 108]

Anlage 27

(((eTicket Deutschland

Start: CR

Nein, Änderung vorhandener Funktionalität Ja Neue KA- Funktionalität, keine Auswirkung auf vorhandene?

Ja Interoperabilität Nein aller KA-Systeme betroffen?

Ja Dringend? Nein

Version Korrektur Servicepaket

Abbildung 5: Entscheidungspfad für die Einordnung eines CR in ein Release

Die Releaseplanung der VDV-Kernapplikation wird in einem Releasekalender festgelegt.

Die aktuelle Fassung ist diesem Dokument als Anlage beigefügt. Die jeweils aktuelle Fas- sung kann im Webportal der VDV-ETS eingesehen werden.

100

[Seite 109]

Anlage 27

(((eTicket Deutschland

4. Technische Umsetzung des Release Managements für XSD und WSDL

Im Folgenden wird die Beschreibung der technischen Umsetzung des Release Manage- ments in die technischen Schnittstellen auf XSD- und WSDL-Basis dargestellt.

Diese Erklärung gibt einen kurzen Überblick über die Semantik des eingeführten Versions- und Releasemanagements und die Begriffsverwendung innerhalb dieses Kapitels. Im späte- ren Verlauf des Dokuments wird auf die einzelnen Bestandteile nochmal im Detail eingegan- gen.

Unter Komponente ist hier eine technische Einheit in XML zu verstehen, die ein Stück der Schnittstellendefinition auf technischer Ebene enthält. Dies sind

• WSDL-Dateien, die die Servicevereinbarungen enthalten

• XSD-Dateien, die die Elemente und Datenstrukturen für die fachlichen Nachrich- ten enthalten

• XSD-Dateien, die allgemeine Datenstrukturen und Aufzählungen enthalten, die für die Zusammensetzung der fachlichen Nachrichten benötigt werden.

4.1 Hierarchischer Aufbau der technischen Schnittstellen

Tabelle 2: Hierarchischer Aufbau der Schnittstellen

101

[Seite 110]

Anlage 27

(((eTicket Deutschland

Tabelle 2 zeigt den hierarchischen Aufbau der Schnittstellen. Dabei ist die Servicevereinba- rung (WSDL) als oberste Schicht anzusehen.

Oberhalb der Operationen in der WSDL ist das Binding zu finden, welches die Operation auf eine entsprechende SOAP Action bindet und die Policy für die Webservice Security einbin- det.

Die Operationen wiederum nutzen die definierten Nachrichten, welche eingehend und aus- gehend sind. Bis hier verbleibt die Hierarchie innerhalb der WSDL. Die Nachrichten wiede- rum nutzen die in den externen XSDs definierten Elemente.

Die Elemente verweisen auf die Datentypen, welche den Aufbau der fachlichen Nachricht definieren. Diese Datentypen verwenden meistens weitere einfachere Datentypen, die dann in allgemeinen XSDs definiert sind.

4.2 Allgemeine Festlegungen

An dieser Stelle wird festgelegt, wie die Erweiterungen im Allgemeinen in die Schnittstellen, bestehend aus XSD Dateien und WSDL Dateien einfließen. Änderungen werden grundsätzlich über sogenannte Vertragserweiterungen (Contract Exten- sion) oder aus serviceorientierte Erweiterungen (siehe Kap. 4.3.6) durchgeführt, d.h. Ände- rungen definieren sich über die Erweiterung der WSDL und dort über die Operationen und nicht über die Erweiterung der Nachrichtenstrukturen. Durch die ausschließliche Verwendung von Contract Extensions können die Namensräume beibehalten werden, was viele Kompatibilitätsprobleme vermeidet. Um die Erweiterungen eindeutig zu identifizieren gelten folgende Regeln:

• Die Erweiterungen müssen eigene XSD-Dateien verwenden. Damit können die Erweiterungen trotz gleichen Namensraumes in eigene Dateien mit spezifikati- onskonformen Namen (XSD-Dateiname + Releasenummer) ausgelagert werden.

• Für das Hinzufügen von Komponenten aus einem neuen Namensraum werden in XSDs und WSDLs die import Anweisungen genutzt

• Für das Zusammenführen von Komponten desselben Namensraumes aus unter- schiedlichen XSDs werden in XSDs und WSDLs die include Anweisungen ge- nutzt.

• Fehlerkorrekturen erhalten immer den Releasenamen als Suffix im Typ und Ele- ment (XSD) sowie in der Operation und den dazugehörigen Komponenten

• Service Packs können Releasenamen als Suffix im Typ oder Element enthalten, wenn es die Art der Erweiterung erfordert. Bei neuer Funktionaliät ist das i.d.R. nicht notwendig.

• Das Versionsattribut in allen XSDs und WSDLs der Schnittstellen wird gesetzt, um die Zugehörigkeit der Komponenten zu einem bestimmten Release zu kenn- zeichnen.

102

[Seite 111]

Anlage 27

(((eTicket Deutschland

• Die WSDL ist das Dokument, in dem alle Änderungen zusammenlaufen. Daher wird vereinbart, unterschiedliche Namensraumkürzel einzuführen. Diese Kürzel helfen dann innerhalb der WSDL zu identifizieren, welche Komponenten mit welchem Release in die WSDL eingeflossen sind.

Diese Regeln werden in den nachfolgenden Kapiteln näher erläutert.

4.3 Konventionen und Definitionen

Die folgenden Definitionen bauen aufeinander auf, d.h. z.B. die Definition von Release wird in den nachfolgenden Kapiteln ebenfalls benötigt.

4.3.1 Release

Die Konvention hierfür ist in EBNF (erweiterte Backus-Naur Form):

Releasenummer = Version, ".", Service-Pack, ".", Korrektur ;

ReleasenummerSuffix = Version, "", Service-Pack, "", Korrektur ;

Version = ZifferAußerNull, [Ziffer] ;

Service-Pack = ZifferAußerNull, [Ziffer] ;

Korrektur = ZifferAußerNull, [Ziffer] ;

ZifferAußerNull = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;

Ziffer = "0" | ZifferAußerNull ;

Version, Service-Pack und Fehlerkorrektur sind zweistellig ausgelegt, wobei führende Nullen nicht erlaubt sind. Die zweite Stelle kommt erst zum Tragen wenn „9“ erreicht wurde.

Jedes KA kompatible System muss zwei Schnittstellenversionen (s. Kap. 2.2) zur gleichen Zeit unterstützen. Durch die Abwärtskompatibilität der Schnittstellenänderungen ist gewähr- leistet, dass für diese Anforderung für die letzten zwei Versionen jeweils immer nur ein Re- lease unterstützt werden muss. Für die neue Version ist es idealerweise das letzte Release, dies ist aber nicht verpflichtend.

Beispiel: Version 3 existiert als Release 3.1.2, Version 4 existiert als Version 4.0.2. In diesem Fall sollte ein KA kompatibles System, welches 2 Versionen unterstützt, sowohl Release 4.0.2 als auch Release 3.1.2 unterstützen. Damit würden alle Releases der Vorgän- gerversion unterstützt. Für die neue Version hingegen ist es zulässig, dass ein System nur Release 4.0.1 unterstützt, weil 4.0.2 (noch) nicht umgesetzt wurde.

4.3.1.1 Einführung einer neuen Version

Mit der Einführung einer neuen Version entfällt der alte Namensraum, und wird in den Hauptnamensraum der neuen Version integriert. Operationsnamen5, die Releasenummern

5 Transaktionen (TX-Nachrichten) sind Operationen. Jede Operation trägt einen Namen. 103

[Seite 112]

Anlage 27

(((eTicket Deutschland

enthalten (i.d.R. bei Fehlerkorrekturen), werden zum Standardoperationsnamen zurückkon- vertiert, während die fehlerhaften Operationen, die zuvor nicht sinnvoll ausgeführt werden konnten, entfallen.

Alle bisher entstandenen Änderungen durch Korrekturen und Service-Packs müssen in die Software übernommen werden, soweit dies noch nicht geschehen ist. Für die neue Version arbeitet die Software dann vollständig und einheitlich mit dem neuen Namensraum. Für die jetzt entstandene Vorversion bleiben alle eingeführten Namensräume bestehen. Mit der neuen Version entsteht das Basisrelease. Mit diesem werden die Standard Schnitt- stellenkomponenten für diese Version eingeführt zusammen mit dem neuen Namensraum des Basisrelease. Für diesen gilt:

= <alter Namensraum + 1>.

Das Basisrelease ist das einzige Release, bei dem der Namensraum in den Komponenten lediglich die Versionsnummer enthält (Beispiel 4.0.0 -> Namensraum ist „4“) und bei dem alle Komponenten ohne die Releasenummer in Definition oder Dateinamen erstellt werden.

Beispiel Es wird eine neue Version 4 eingeführt, damit entsteht Release 4.0.0

Die Vorgängerversion war 3.1.2 und es gab 2 Änderungen im Basisrelease der Version 3 (vor dem ersten Service-Pack gab es also das Release 3.0.2).

Der alte Namensraum ist einheitlich auf 3 geblieben, allerdings müssen alle entstandenen Erweiterungen in die Standard XSDs und WSDLs überführt werden.

Folgende Erweiterungen existieren für Release 3.1.2, die sich in verschiedenen XSD Dateien und im Namen von Typen und Elementen befinden:

• Erweiterungen 3.0.1
• Erweiterungen 3.0.2
• Erweiterungen 3.1.0
• Erweiterungen 3.1.1
• Erweiterungen 3.1.2

Nun wird eine neue Version eingeführt. Diese Version trägt dann als erstes neues Basis- release die Releasenummer 4.0.0. Mit dieser neuen Version darf nur noch der neue Na- mensraum 4 existieren, alle o.g. Erweiterungen fließen in die Standard-Schnittstellen ein und Namenserweiterungen für Typen, Elemente und Operationen entfallen für die neue Version.

Jetzt gilt es noch, einen besonderen Fall zu betrachten: Wird eine neue Version eingeführt, ist ein betroffenes System nicht unbedingt auf dem letz- ten Stand der Vorversion (in unserem Beispiel 3.1.2). Wir nehmen für unser Beispiel an, dass das System zuletzt das Release 3.0.2 unterstützt hat. Damit kennt das System die Er- weiterungen :

• Erweiterung 3.0.1
• Erweiterung 3.0.2

104

[Seite 113]

Anlage 27

(((eTicket Deutschland

In dem Fall wurde das Service-Pack 1 nicht umgesetzt und auch nicht die letzten beiden Kor- rekturen.

• Das alte System muss nicht mehr angepasst werden, sollte aber bei Erhalt von Nachrichten aus den Erweiterungen ein TXA bzw. VX senden, das die Informati- on der fehlenden Funktionalität aus Release 3.1.0, 3.1.1 und 3.1.2 an ein sen- dendes System übermittelt.

4.3.1.2 Einführung eines neuen Releases

Mit der Einführung eines neuen Release endet der Support für das Vorrelease. Das Vor- release darf weiterhin verwendet werden, Fehlerkorrekturen werden aber nur innerhalb des neuen Release weitergeführt.

Das gilt insbesondere, wenn ein Service-Pack eingeführt wurde und so z.B. aus Release 3.0.4 das Release 3.1.0 wird. Alle bisherigen Fehlerkorrekturen werden dann übernommen und somit auch die aus 3.0.1, 3.0.2, 3.0.3 und 3.0.4 entstandenen Namenserweiterungen an Typen, Elementen und Operationen entfallen. Sollten durch Korrekturen Typen, Elemente oder Operationen entstanden sein, die nicht mehr benötigt werden, so entfallen diese.

Es wird kein neuer Namensraum eingeführt. Wird nun eine notwendige Korrektur identifiziert, so fließt diese nur noch in Release 3.1.0 ein. Dieses Release wird dann zu 3.1.1 und für 3.1.1 werden die notwendigen Änderungen (Typen, Elemente, Operationen, eigene XSDs) mit der neuen Namenserweiterung eingeführt.

Es wird dann aber definitiv kein Release 3.0.5 und keine Erweiterungen hierfür mehr geben. Die Nummer des Releases ist verbindlich für alle zugehörigen Komponenten (WSDLs und XSDs für alle Bereiche) der Schnittstellen und Spezifikationen und wird durchgehend ver- wendet. Dabei müssen nicht zwingend Änderungen in allen Anteilen von Spezifikation oder technischen Schnittstellen erfolgt sein. Die Einführung eines neuen Release beinhaltet im- mer

• Ein überarbeitetes bzw. erweitertes Spezifikationspaket (Spec ION, Spec SST, Spec BOM, etc.)

• Überarbeitete bzw. erweiterte Servicevereinbarungen (WSDL)

• Überarbeitete bzw. erweiterte Datenstrukturen (XSDs)

• Überarbeitete bzw. erweiterte Dokumentation der Schnittstellen (in PDF bzw. HTML)

• Ausführliche Release Notes zu den Änderungen

4.3.1.3 Wegfall einer Version

Durch die Einführung einer neuen Version entfällt die älteste Version, da nur zwei Versionen zur gleichen Zeit unterstützt werden können.

105

[Seite 114]

Anlage 27

(((eTicket Deutschland

4.3.1.4 Wegfall eines Releases

Der Wegfall eines Release bedeutet, dass der Support für dieses Release eingestellt wird. Das Release kann weiter verwendet werden, allerdings ergeben sich einige zu beachtende Punkte:

• Die technischen Schnittstellen sind nicht länger online auf der ZVM verfügbar. Nur auf dem Schnittstellen Portal kann ein nicht mehr unterstütztes Release in- klusive Dokumentation heruntergeladen werden.
• Korrekturen oder Erweiterungen fließen nicht mehr in dieses Release ein
• Fehlverhalten, welches durch bekannte Probleme im Release hervorgerufen wird, kann nicht durch die Systemverantwortlichen behoben werden. Innerhalb einer Version sind die Releases hinsichtlich des gemeinsamen Namensraumes kompatibel.

Beispiel: Sendet ein System mit einem höheren Release 3.1.1 an ein System mit dem niedrigeren Release 3.0.2, so können maximal Operationen (inklusive benötigten Komponenten) bis zum Release 3.0.2 verwendet werden. Durch den einheitlichen Namensraum treten keine In- kompatibilitäten auf. Es können damit Transaktionen aus der Basisversion 3, dem ersten Korrekturrelease 3.0.1 und dem zweiten Korrekturrelease 3.0.2 ausgetauscht werden. Der Versuch, Transaktionen aus Release 3.1.0 oder 3.1.1 auszutauschen, führt in diesem Beispiel zu einem Laufzeitfehler, weil im System mit Release 3.0.2 die zugehörigen Operati- onen nicht definiert sind.

4.3.2 Dateinamen der Schnittstellenkomponenten

4.3.2.1 XML Schema Dateien

Die Konvention hierfür ist in EBNF:

Basis-XSD-Dateiname = Basis-XSD-Name, ".xsd" ;

Basis-XSD-Name = "XML-Schema_", XSD-Bereich, "_", [Funktion] ;

XSD-Bereich = "KA_COMMON" | "COMMON" | "KVP_DL_PV" | "KOSE" | "AH" | "ALISE" | "PE" | "STATBER" | "FREMD" | "RVS" | "ZVM" ;

Funktion = "Types" | "Attachments" ;

Erweiterungs-XSD-Dateiname = Basis-XSD-Name, "_ext-", Releasenummer, ".xsd";

4.3.2.2 WSDL Dateien

Die Konvention hierfür ist in EBNF:

WSDL-Name = WSDL-Bereich, "_Services", ".wsdl" ;

106

[Seite 115]

Anlage 27

(((eTicket Deutschland

WSDL-Bereich = "KOSE" | "AH" | "PV" | "KVP" | "DL" | "PV_ALISE" | "KVP_ALISE" | "PV_STATBER" | "KVP_STATBER" | "DL_STATBER" ;

4.3.3 Namensräume

Die Konvention hierfür ist in EBNF:

Namensraumdefinition = Namensraumkürzel, "=", Namensraum ;

Namensraumkürzel = "ah" | "kose" | "dl" | "kvp" | "pv" | "kvp-dl-pv" | "pv- alise" | "kvp-alise" | "dl-statber" | "kvp-statber" | "pv-statber" | "alise" | "ion" | "ct" | "ka" ;

NamensraumBereich = "ah" | "kose" | "dl" | "kvp" | "pv" | "kvp-dl-pv" | "pv-alise" | "kvp-alise" | "dl-statber" | "kvp-statber" | "pv-statber" | "ion" | "common" ;

Namensraum = NamensraumPräfix, NamensraumBereich, ["types"], "/", Version ;

NamensraumPräfix = "http://vdv/ka/" ;

Erweiterung der Namensraumkürzel (bei Fehlerkorrektur und Service-Pack):

Bei Einführung eines Service-Packs oder einer Korrektur bleibt der Namensraum bestehen. Allerdings wird das Namensraumkürzel durch NamensraumkürzelErweiterung erweitert, um innerhalb einer WSDL die einzelnen Erweiterungen kennzeichnen zu können, ohne die Na- mensraum selber zu erweitern. In EBNF:

NamensraumkürzelErweiterung = Namensraumkürzel, "-ext-", Releasenummer ;

4.3.4 Definitionen in der WSDL

Wie bereits in 4.1 beschrieben, ist die WSDL in einer Hierarchie aufgebaut. Zuerst werden die Nachrichten definiert. Diese Nachrichten werden dann in der Definition der Operationen als ein- oder ausgehende Nachrichten verwendet. Die Operationen wiederum werden dann an einen Endpunkt gebunden, wobei in diesem so- genannten „Binding“ zusätzlich Policy-Vereinbarungen (Webservice Security) und SOAP Actions definiert werden. Für jede dieser Hierarchien wurde eine bestimmte Namenskonvention eingeführt, um sicher- zustellen, dass in allen WSDLs die gleiche Vorgehensweise bei der Definition angewandt wird.

4.3.4.1 Nachrichten

107

[Seite 116]

Anlage 27

(((eTicket Deutschland

Hierzu wird in dieser Spezifikation eine Konvention festgelegt (EBNF):

BasisElementNachricht = BasisNameNachricht | BasisPartNachricht ;

BasisNameNachricht = XSDElementNameNachricht, BasisSuffixNachricht ;

BasisSuffixNachricht = "ReqMsg" | "ResMsg" ;

BasisPartNachricht = BasisPartPräfix, BasisPartSuffix ;

BasisPartSuffix = "Req" | "Res" ;

Auch hier kann die EBNF nicht vollständig definiert werden, weil BasisPartPräfix fehlt. BasisPartPräfix entspricht der folgenden Regel (in Pseudonotation):

BasisPartPräfix = XSDElementNameNachricht ohne Präfix "TX" in Kleinbuchstaben ;

Die Auswahl des BasisPartPräfix hängt davon ab, ob der Empfänger die gesendete Nachricht nur weiterverarbeiten soll (sogenannte Request-orientierte Nachricht  “Entge- gennahme“), d.h. der Sender erwartet nur eine Bestätigung jedoch keine fachlichen Informa- tionen in der Antwort. In dem Fall hat BasisPartSuffix den Wert "Req". Beispiel ist ein Sperrauftrag Berechtigung an KOSES (TXSAUFB), hier wird nur ein TXB als Antwort erwar- tet. Alle relevanten fachlichen Informationen stehen im Request. BasisPartNachricht wür- de dann saufbReq lauten. Im anderen Fall fordert der Sender fachliche Daten über einen Request an, d.h. der Request enthält nur Anfrageinformation, jedoch keine fachlichen Informationen (sogenannte Respon- se-orientierte Nachricht  “Anfordern von/ Bereitstellen von“). In dem Fall soll das Empfän- gersystem die Anfrage verarbeiten und fachliche Informationen in der Antwort bereitstellen. In dem Fall hat BasisPartSuffix den Wert "Res". Beispiel ist eine Anfrage für die Informa- tion über eine Fahrberechtigung an das PV System (TXASBERAFB/TXANLN), hier wird die Information als Antwort erwartet. Im Request stehen nur die Identifikationsdaten des Senders und der Berechtigung. BasisPartNachricht würde dann anlnRes lauten. Analog gilt dies jeweils für BasisSuffixNachricht. Für die Request-orientierte Nachricht wird das Suffix ReqMsg verwendet, für die Response-orientierte Nachricht ResMsg.

Erweiterung (i.A. nur bei Fehlerkorrektur oder Verwendung erweiterter Listen, 4.3.7):

ErweiterungElementNachricht = ErweiterungNameNachricht | ErweiterungPartNachricht ;

ErweiterungNameNachricht = BasisNameNachricht, "_", ReleasenummerSuffix ;

ErweiterungPartNachricht = BasisPartNachricht, "_", ReleasenummerSuffix ;

4.3.4.2 Operationen

Hierzu wird in dieser Spezifikation eine Konvention festgelegt (EBNF):

BasisnameOperation = OperationPräfix, BasisXSDElementNameNachricht ; OperationPräfix = "req" | "res" ;

Das Präfix wiederum ist abhängig davon, ob die gesamte Operation fachliche Daten zum Empfänger anliefert ("req") oder fachliche Daten vom Sender angefordert werden ("res"). 108

[Seite 117]

Anlage 27

(((eTicket Deutschland

Erweiterung (nur bei Fehlerkorrektur oder Verwendung erweiterter Listen, 4.3.7):

ErweiterungsnameOperation = BasisnameOperation, "_", ReleasenummerSuffix ;

4.3.4.3 Binding Für das Bindung wird ebenfalls BasisnameOperation verwendet. Zusätzlich wird die SOAP Action definiert. Hierzu wird in dieser Spezifikation eine Konvention festgelegt (EBNF). Die bereits definierten Anteile finden sich in Kap. 4.3.3..

SOAPAction = Namensraum, "/", BasisnameOperation ;

Erweiterung (i. A. nur bei Fehlerkorrektur oder Verwendung erweiterter Listen, 4.3.7):

NamensraumErweiterung = Namensraum, "/ext/", Releasenummer ;

ErweiterungSOAPAction = Namensraum , ErweiterungsnameOperation ;

4.3.5 Kennzeichnung der Schnittstellen Komponenten für ein Release

Um die Releasenummer in allen Komponenten zu dokumentieren, werden die vorhandenen Möglichkeiten in XSD und WSDL genutzt. Diese sehen ein Namensattribut (WSDL) oder ein Versionsattribut (XSD) vor. Diese Attribute dienen nur der Dokumentation und haben keinen technischen Einfluss auf XSD Validierung oder Code-Generierung (Stub) auf Basis der Komponenten. Sowohl im Namensattribut der WSDL als auch im Versionsattribut der XSD wird die Relea- senummer eingesetzt. Das folgende Code-Beispiel (für den Produktverantwortlichen, PV) illustriert die Vorgehensweise.

<wsdl:definitions name="PV_Services-[Release]" …>

Code-Beispiel 1 Einbringen der Releasenummer in den Namen der WSDL

<xs:schema version="[Release]" … >

Code-Beispiel 2: Einbringen der Releasenummer in das Versionstag der XSD

Wichtig hierbei ist: Die Inhalte und Namen der bisherigen Komponenten (bezogen auf eine Version) bleiben unverändert, auch wenn Versionsattribut und Namensattribut gesetzt wer- den. Die genaue Umsetzung ist in den nachfolgenden Kapiteln zu finden.

4.3.6 Serviceorientierte Erweiterungen

109

[Seite 118]

Anlage 27

(((eTicket Deutschland

Abbildung 6: Übersicht serviceorientierte Erweiterungen

Serviceorientierte Erweiterungen sind für Fehlerkorrekturen oder Service-Packs sehr ähnlich. In beiden Fällen ist die Vorgehensweise wie in Abbildung 6 gezeigt. Neu eingeführte Opera- tionen bleiben innerhalb des vorhandenen Namensraumes, werden aber mit neuem Na- mensraumkürzel eingeführt, während die vorhandenen Operationen (im Bespiel 1.1.09) das bereits vorhandene Namensraumkürzel behalten. Dies gilt auch bei mehrfachen Erweiterun- gen (in Abbildung 6 angedeutet durch ein Service-Pack 1.2.0 und eine Fehlerkorrektur 1.2.1).

Pro Erweiterung kommt somit ein Namensraumkürzel hinzu. Dieses Namensraumkürzel be- inhaltet immer die gesamte Releasenummer.

110

[Seite 119]

Anlage 27

(((eTicket Deutschland

<wsdl:definitions name="PV_Services-[Release]" ... xmlns:pv-ext-[Release]=http://vdv/ka/kvp-dl-pv/[Version] ...

wsdl:types <xsd:schema targetNamespace="http://vdv/ka/kvp-dl-pv/[Version]"> ... <xsd:include schemaLocation="../../../ka/pv/[Version]/XML-Schema_KVP_DL_PV.xsd" /> <xsd:include schemaLocation="../../../ka/pv/[Version]/XML-Schema_KVP_DL_PV_ext-[Release].xsd" /> ... </xsd:schema> </wsdl:types> ... </wsdl:definitions>

Code-Beispiel 3 Änderungen der WSDL bei Serviceerweiterungen

Alle Datenstrukturen, die für die neue Operation benötigt werden, sind in eine eigene XSD ausgelagert. Diese XSD heißt wie die ursprüngliche XSD mit der Konvention aus Erweiterungs-XSD-Dateiname.

siehe auch Code-Beispiel 3

Anmerkung: Nur das Basisrelease verwendet ausschließlich Basis-XSD-Dateiname. Alle anderen fol- genden Releases verwenden Erweiterungs-XSD-Dateiname für neue eingeführte Datenty- pen und Elemente.

Für die exakte Definition in EBNF, siehe Kapitel 0.

Diese XSD muss der WSDL mit der benötigten Erweiterung per Import bekannt gemacht werden. Da dort Erweiterungen für den bereits vorhandenen Namensraum enthalten sind, muss die include statt der import Anweisung verwendet werden.

Sind durch die Serviceerweiterung mehrere XSDs oder WSDLs betroffen, so gelten o.g. Aussagen analog zu den zusätzlich betroffenen Komponenten.

Werden z.B. Erweiterungen von Datenstrukturen benötigt, die in zwei XSDs liegen, so wird jeweils eine eigene XSD erstellt, die nur die notwendigen Erweiterungen des neuen Release enthält.

111

[Seite 120]

Anlage 27

(((eTicket Deutschland

4.3.6.1 Verwenden einer neuen Operation mit korrigierter Nachricht

Für diesen Fall wird eine weitere Operation eingeführt, welche mit einer korrigierten Nach- richt arbeitet. Da das Überladen von Operationen (gleicher Name, andere Argumente) in der WSDL nicht möglich ist, muss sich der Name der neuen Operation vom Namen der beste- henden Operation unterscheiden. Nachfolgendes Beispiel geht von einem Release 1.2.1 aus

<wsdl:definitions name="PV_Services-1.2.1" ... xmlns:pv-ext-1.2.1=http://vdv/ka/kvp-dl-pv/1 ...

wsdl:types <xsd:schema targetNamespace="http://vdv/ka/kvp-dl-pv/1 /> <xsd:include schemaLocation="../../../ka/pv/1/XML-Schema_KVP_DL_PV.xsd" /> <xsd:include schemaLocation="../../../ka/pv/1/XML-Schema_KVP_DL_PV_ext-1.2.1.xsd" /> </xsd:schema> </wsdl:types> ...

<wsdl:message name="TXAEBERReqMsg_1_2_1"> wsdl:documentation Request fuer Aenderung Berechtigung. Korrektur. </wsdl:documentation> <wsdl:part name="aeberReq_1_2_1" element="pv-ext-1.2.1:TXAEBER_1_2_1" /> </wsdl:message> </wsdl:definitions>

Abbildung 7: Änderung WSDL bei Fehlerkorrektur Teil 1: Nachricht

In der WSDL wird die Nachricht, die Operation und das Binding (binden der Operation an eine SOAP-Action) getrennt voneinander definiert. Im Falle einer Erweiterung ist jeder dieser Definitionsanteile betroffen. Daher wird auf jeden Teil einzeln eingegangen. Abbildung 7 zeigt die Definition der Nachricht im Falle der Serviceerweiterung. Bei der Fehlerkorrektur wird immer die Releasenummer in die definierten Namen eingefügt.

<wsdl:operation name="reqAEBER_1_2_1"> wsdl:documentation Aenderung einer Berechtigung. Korrektur. Asychron. </wsdl:documentation> <wsdl:input message="tns:TXAEBERReqMsg_1_2_1" /> <wsdl:output message="tns:VXMsg" /> </wsdl:operation>

<wsdl:operation name="reqAEBER_1_2_1"> <soap:operation soapAction="http://vdv/ka/pv/1/reqAEBER_1_2_1" /> wsdl:input 112

[Seite 121]

Anlage 27

(((eTicket Deutschland

<wsp:PolicyReference URI="#KAPolicy" /> <soap:body use="literal" /> </wsdl:input> wsdl:output <soap:body use="literal" /> </wsdl:output> </wsdl:operation>

Abbildung 8: Änderung WSDL bei Fehlerkorrektur Teil 2: Operation und Binding

Abbildung 8 zeigt für den Fall der Serviceerweiterung die Vorgehensweise bei der Definition von Operation und Binding. Bei der Fehlerkorrektur wird immer die Releasenummer in die definierten Namen eingefügt.

<xs:schema version="1.2.1“ targetNamespace="http://vdv/ka/kvp-dl-pv/1" xmlns:tns="http://vdv/ka/kvp-dl-pv/1" xmlns:ion="http://vdv/ka/ion/1"…> ... <xs:complexType name="TXAEBER_Type"> xs:annotation xs:documentationTyp: Aenderung einer Berechtigung. </xs:documentation> </xs:annotation> xs:complexContent <xs:extension base="ion:TX_BASE_Type"> xs:sequence <xs:element name="tx_ber" type="ion:TX_BER_Type" /> <xs:element name="berechtigungTarifbereich" type="xs:hexBinary" /> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

<xs:element name="TXAEBER" type="tns:TXAEBER_Type"> xs:annotation xs:documentationElement:Aenderung einer Berechtigung.</xs:documentation> </xs:annotation> </xs:element> ... </xs:schema>

Abbildung 9: Ausschnitt aus der XSD des Basisrelease ohne Korrekturen mit Release Information

<xs:schema version="1.2.1" targetNamespace="http://vdv/ka/kvp-dl-pv/1" xmlns:tns="http://vdv/ka/kvp-dl-pv/1" xmlns:ion="http://vdv/ka/ion/1"…> ... <xs:complexType name="TXAEBER_Type_1_2_1"> xs:annotation xs:documentationTyp: Aenderung einer Berechtigung. Korrektur. </xs:documentation> </xs:annotation> xs:complexContent <xs:extension base="ion:TX_BASE_Type"> xs:sequence <xs:element name="tx_ber" type="ion:TX_BER_Type" /> <xs:element name="berechtigungTarifbereich" type="xs:hexBinary" /> <xs:element name="berBerechtigung_ID" type="ion:Berechtigung_ID_Type" /> </xs:sequence> </xs:extension> </xs:complexContent> 113

[Seite 122]

Anlage 27

(((eTicket Deutschland

</xs:complexType>

<xs:element name="TXAEBER_1_2_1" type="tns:TXAEBER_Type_1_2_1"> xs:annotation xs:documentationElement:Aenderung einer Berechtigung. Korrektur.</xs:documentation> </xs:annotation> </xs:element> </xs:schema>

Abbildung 10: XSD mit Erweiterungen für Fehlerkorrekturen

Abbildung 9 zeigt den originalen Inhalt der XSD des Basisrelease (welcher als einzige Ände- rung ein Versions-Tag mit Releasenamen erhält) im Vergleich zu Abbildung 10, welche für die Korrektur das Vorgehen auf der Ebene der XSD zeigt. Datentyp und Element werden im Namen mit der Releasenummer versehen. Im neu definierten Datentyp wurden die fehlen- den Anteile (Berechtigungs-ID) ergänzt.

<tns:TXAEBER_1_2_1 xmlns:tns="http://vdv/ka/kvp-dl-pv/1" …> <transEmpfaenger_ID>4711</transEmpfaenger_ID> 3 <transTransaktion_ID> 42 1 <transSender_ID>4712</transSender_ID> </transTransaktion_ID> 2014-02-07T12:00:00 tns:tx_ber 2014-02-07T12:00:00 2015-02-07T12:00:00 0 0 FFFFFFFFFFFFFFFFFFFFF </tns:tx_ber> tns:berechtigungTarifbereich0F00</tns:berechtigungTarifbereich>

</tns:TXAEBER_1_2_1>

Abbildung 11: XML-Nachricht Fehlerkorrektur als Ergebnis von XSD- und WSDL Änderung

Abbildung 11 zeigt die XML-Nachricht, die (im Rahmen des SOAP Protokolls) aufgrund von Definition in XSD und WSDL entstehen würde. Der Name des Elements in der XSD gibt hier den Namen der XML Nachricht vor (TXAEBER_1_2_1).

114

[Seite 123]

Anlage 27

(((eTicket Deutschland

4.3.6.2 Verwenden einer neu eingeführten Operation (Service-Pack)

Wird eine neue Operation nicht zur Fehlerkorrektur verwendet, sondern zum Abbilden von weiterer fachlicher Funktionalität, so handelt es sich um ein Service-Pack. Die Vorgehens- weise ist dabei der der Fehlerkorrektur sehr ähnlich, es gibt aber einige Unterschiede. Der Hauptunterschied liegt darin, dass die neue Operation noch nicht existiert, weil neue Fachlichkeit abgebildet wird. Damit ist – außer beim Namensraumkürzel – keine weitere Konvention hinsichtlich der Definition der Namen von Nachricht und Operation notwendig. Insbesondere enthalten die Namen von Nachricht und Operation dann i.d.R. nicht die Re- leasenummer. Dies gilt ebenfalls für die die Datenstruktur und das Element in der XSD. Aber auch beim Service-Pack wird eine neue XSD eingeführt und in der WSDL importiert.

Abbildung 12: Änderung WSDL bei Service-Pack Teil 1

Abbildung 12 zeigt die Definitionen in der WSDL im Rahmen eines Service-Packs. Die Nach- richtendefinition erhält hier nicht die Releasenummer im Namen, da es sich um eine neue Nachricht handelt.

115

[Seite 124]

Anlage 27

(((eTicket Deutschland

Abbildung 13: Änderung WSDL bei Service-Pack Teil 2

Abbildung 13 zeigt die Operationen und das Binding im Falle eines Service-Packs. Auch hier ist zu sehen, dass die Releasenummer nicht mit in die definierten Namen mit einfließt.

116

[Seite 125]

Anlage 27

(((eTicket Deutschland

Abbildung 14: XSD mit Erweiterungen für Service-Packs

Abbildung 14 zeigt die Definition von Datentyp und Element in der XSD, die im Rahmen der Erweiterung durch ein Service-Pack entsteht. In der jeweiligen Namensdefinition ist die Re- leasenummer nicht enthalten. Nach der Konvention hätte dieses Schema den Namen XML- Schema_KOSE_ext-1.2.0.xsd.

4.3.6.3 Fehlerbehandlung

Die Fehlerbehandlung ist wiederum für den Fall der Fehlerkorrektur und des Service-Packs gleich, da in beiden Fällen eine Serviceerweiterung innerhalb der WSDL erfolgt und eine Auslagerung der neuen Strukturen in eine eigene XSD. Daher unterscheidet sich auch das Fehlerszenario nicht.

Allerdings gibt es grundsätzlich andere Voraussetzungen für entstehende Laufzeitfehler, ab- hängig davon, ob es sich beim Nachrichtenaustausch um ein zentrales System oder VU/VV- System handelt. Bei dem zentralen System wird direkt durch das Routing der ZVM vorgege- ben, ob eine Operation unterstützt wird oder nicht, da ein zentrales System nur einmal exis- tiert. Beim VU/VV System ist aufgrund der mehrfachen Implementierung der Serviceverein- barung zum Zeitpunkt der Nachrichtenübermittlung nicht klar, ob die Gegenseite die Nach- richt verarbeiten kann.

Zusätzlich spielt es eine Rolle, ob ein System komplett unverändert mit dem vorherigen Re- lease läuft oder Teile des neuen Release umgesetzt wurden (und somit ebenfalls die ggf. fehlende Unterstützung bestimmter Anteile im System sauber abgebildet ist). Folgende Aussagen gelten im Rahmen der Umsetzung und im Hinblick auf mögliche Feh- lerszenarien:

117

[Seite 126]

Anlage 27

(((eTicket Deutschland

• Automatische XSD-Validierung der neuen Anteile ist möglich (wenn die Umset- zung erfolgt ist)

• Ein System kann gezielt die Implementierung der neuen Operation(en) auslassen und einen festgelegten Fehlercode senden. Dieser ist für TXA (synchrone Nach- richten) der Code 254 und für VX (asynchrones Acknowledgement) der Code

• Die Softwareänderung (inklusive Test) für „Unbeteiligte“ ist sehr gering (eine Zei- le Code pro Operation!) und umfasst lediglich das Senden der oben beschriebe- nen Ablehnung.

• Allerdings: Wenn ein unverändertes System, welches die Erweiterungen nicht un- terstützt, mit der neuen Operation aufgerufen wird, so muss der Aufrufer mit ei- nem Laufzeitfehler rechnen. Das ist insbesondere bei Service-Packs zu beach- ten, da hier keine Filterung über die ZVM erfolgen kann (siehe nächster Absatz).

• Bei der Fehlerkorrektur kommt noch eine Möglichkeit hinzu, die für das Service- Pack nicht existiert: Die durch die Fehlerkorrektur ungültig gewordene, alte Ope- ration kann in der ZVM ausgeblendet werden, was dazu führt, dass bei Aufruf dieser Operation eine VX-Nachricht mit dem Fehlercode 3 („Für diese Operation existiert kein Routing“) zurückgeliefert wird. Das ist möglichen Laufzeitfehlern von Systemen, die die Fehlerkorrektur nicht umsetzen, in jedem Fall vorzuziehen und geschieht unter Absprache mit der VDV ETS.

4.3.7 Erweiterung von Aufzählungen in der XSD

Aufzählungen in XSDs haben den Vorteil, eine wohldefinierte Menge an möglichen Werten zu liefern, die direkt bei der Validierung einer XML Nachricht genutzt werden kann.

Problematisch wird es, wenn nicht alle Werte zur Zeit der Definition bekannt sind oder im Laufe der Zeit notwendige Werte (Fehlercodes, etc.) hinzukommen sollen oder aber auch entfallen sollen. Leider ist dies ein allgemeines Problem, welches sich nicht zufriedenstellend lösen lässt, ohne eine neue Schnittstellenversion einzuführen.

Für diesen Fall gibt es zwar mehrere Lösungsansätze (zumindest für das Hinzufügen von Werten), die unter [2] beschrieben sind. Für den speziellen Fall der KA-Schnittstellen wurden jedoch keine Ideen aus [2] übernommen.

Durch die Anforderungen des Release-Managements der KA (Robustheit, Fehlerverhalten, etc.) war dies nicht möglich.

Ziel ist, pro Release (falls es notwendig wird) eine bestimmte Aufzählung erweitern zu kön- nen und zwar in der gleichen Art und Weise wie auch mit anderen Erweiterungen umgegan- gen wird.

Aber auch die Erweiterung kann nicht vor Laufzeitfehlern schützen, wenn bestimmte, unver- änderte Systeme die neuen Aufzählungselemente nicht kennen. Die im Folgenden beschrie- bene Vorgehensweise dient dazu, die originalen Datentypen der Aufzählungen nicht zu ver- ändern und wohldefiniert pro Release zu kennzeichnen, wann welche Erweiterungen hinzu- gekommen sind.

118

[Seite 127]

Anlage 27

(((eTicket Deutschland

Ein weiteres Problem sind allgemeine Aufzählungen, die in vielen oder sogar in allen Daten- strukturen benötigt werden. In dem Fall kann die Erweiterung nicht durch „Duplizieren“ der vorhandenen Datenstrukturen unter Verwendung der neuen Aufzählung erreicht werden, da alle Datenstrukturen dupliziert werden müssten, was technisch der Einführung einer neuen Version gleichkäme.

Für diese Spezifikation wurde folgender Ansatz gewählt, welcher auch in den nachfolgenden Kapiteln näher beschrieben wird.

Tabelle 3: Codelisten-Erweiterungen

4.3.7.1 Duplizieren der vorhandenen Liste

Unabhängig davon, ob es sich um eine Fehlerkorrektur oder einen Service-Pack handelt, muss die zu erweiternde Liste dupliziert werden. Wichtig ist, dass das Duplizieren gekenn- zeichnet wird. Dies geschieht durch Anhängen der Releasenummer an alle duplizierten An- teile (Datenstrukturen, Elemente). Das gilt sowohl für Service-Pack als auch Fehlerkorrektur, da die notwendigen Schritte absolut gleich sind und unbedingt durchgängig erkennbar sein muss, dass es sich um eine im Rahmen eines neuen Releases eingeführte Maßnahme zum Erweitern einer vorhandenen Liste handelt. Damit ist sofort erkennbar, welche Komponenten noch abwärtskompatibel sind (jene, die die alte Liste verwenden) und welche Komponenten bereits eine erweiterte Liste verwenden. Als fiktives Beispiel dient ServiceKlasse_CODE_Type aus dem Schema XML- Schema_KVP_DV_PV.xsd. Diese Liste wird nur in zwei weiteren Datenstrukturen verwendet und ist somit im Sinne dieser Spezifikation erweiterbar. Es wird angenommen, dass neben 1. Klasse und 2. Klasse eine 3. Klasse eingeführt werden soll. Inhaber einer solchen Berechtigung hätten nur Anspruch auf einen Stehplatz. Dies soll für unser Beispiel im Rahmen eines Service-Packs eingeführt werden. Bei einer Fehlerkor- rektur ist das Vorgehen gleich, hier wäre lediglich die Releasenummer anders. Damit entsteht eine neue Liste Namens ServiceKlasse_CODE_Type_1_3_0, die als Kopie von ServiceKlasse_CODE_Type entsteht und zusätzlich das neue Listenelement enthält.

<xs:simpleType name="ServiceKlasse_CODE_Type_1_3_0"> xs:annotation xs:documentation Erweiterung von ServiceKlasse_CODE_Type. </xs:documentation> </xs:annotation> <xs:restriction base="ct:INT1"> <xs:enumeration value="0"> xs:annotation 119

[Seite 128]

Anlage 27

(((eTicket Deutschland

xs:documentationnicht spezifiziert/unbestimmt</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="1"> xs:annotation xs:documentation1. Klasse</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="2"> xs:annotation xs:documentation2. Klasse</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="3"> xs:annotation xs:documentation3. Klasse (nur Stehplatz)</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType>

Code-Beispiel 4 Duplizierte und erweiterte Liste

4.3.7.2 Duplizieren der abhängigen Datenstrukturen und Elemente

Diese Liste wird von zwei weiteren Datenstrukturen verwendet, TX_AFBLOG_Type und TX_EFSLOG_Type. Zur Vereinfachung wird nun nur noch die Struktur TX_AFBLOG_Type betrach- tet. Diese wiederum wird von der Struktur TXANLN_Type mit dem Element TXANLN verwendet. Diese Komponenten müssen, wenn sie mit der erweiterten Liste arbeiten sollen, ebenfalls dupliziert werden. Auch hier wird die Releasenummer an den Namen der Komponente an- gehängt, unabhängig von Fehlerkorrektur oder Service-Pack. Damit entsteht TX_AFBLOG_Type_1_3_0, TXANLN_Type_1_3_0 und TXANLN_1_3_0, siehe Code-Beispiel 5, Code-Beispiel 6 und Code-Beispiel 7.

<xs:complexType name="TX_AFBLOG_Type_1_3_0"> xs:annotation xs:documentation Typ:Basisdatensatz zur Anzeige von Log-Informationen einer AFB, inkl. 3. Klasse </xs:documentation> </xs:annotation> xs:sequence … <xs:element name="afbLogServiceKlasse" type="tns:ServiceKlasse_CODE_Type_1_3_0" /> … </xs:sequence> </xs:complexType>

Code-Beispiel 5 Basisdatentyp, der die neue Liste verwendet

<xs:complexType name="TXANLN_Type_1_3_0"> xs:annotation xs:documentation Typ:Anzeige Leistungsnachweise einer Berechtigung, inkl. 3. Klasse </xs:documentation>

120

[Seite 129]

Anlage 27

(((eTicket Deutschland

</xs:annotation> xs:complexContent <xs:extension base="ion:TX_BASE_Type"> xs:sequence … <xs:element name="txafblog" type="tns:TX_AFBLOG_Type_1_3_0" …/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

Code-Beispiel 6 Datentyp, der den neuen Basisdatentyp verwendet

<xs:element name="TXANLN_1_3_0" type="tns:TXANLN_Type_1_3_0"> xs:annotation xs:documentation Element: Antwort auf Anforderung der Daten zur Anzeige einer Berechtigung aus dem PV System, inkl. 3. Klasse </xs:documentation> </xs:annotation> </xs:element>

Code-Beispiel 7 Element, welches den neuen Datentyp verwendet

Diese neuen Komponenten werden in eine eigene XSD ausgelagert, die wiederum die Re- leasenummer enthält wie bereits weiter oben beschrieben, in unserem Beispiel XML-Schema_KVP_DL_PV-ext-1.3.0.xsd.

4.3.7.3 Serviceerweiterung für die neuen Nachrichten mit erweiterter Liste

Werden diese Nachrichten per WSDL veröffentlicht, so müssen neue Operationen eingeführt werden, die dann parallel zu den vorhandenen Operationen existieren. Hierbei ist die Relea- senummer als Suffix zu verwenden (unabhängig von Fehlerkorrektur oder Service-Pack), es wird also exakt verfahren wie in Kapitel 4.3.6.1. beschrieben.

4.3.8 Übernahme von Fehlerkorrekturen in Service-Packs

Wie auch in Kapitel 4.3.1.2 beschrieben, beinhaltet ein Service-Pack abwärtskompatibel alle bisherigen Fehlerkorrekturen. Abwärtskompatibel bedeutet, dass alle eingeführten Änderun- gen in das aktuelle Service-Pack übernommen werden. Die Änderungen bleiben hierbei be- stehen (z.B. Namenserweiterungen bei Operationen, Elementen und Typen mit der Release- nummer eines Vorgängerreleases). Anders als bei Einführung einer neuen Version bleiben also bestehende Änderungen von der Einführung des Service-Packs unberührt. Als Beispiel dient ein Release 3.1.1 welches gegenüber einer Version 3.1.0 eingeführt wer- den soll. Die nachfolgende Tabelle führt alle Änderungen auf, die Release 3.1.1 mitbringt. In der nachfolgenden Tabelle wird angenommen, dass es bereits eine Fehlerkorrektur auf dem Basisrelease gab (3.0.1), bevor das erste Service-Pack (3.1.0) eingeführt wurde.

121

[Seite 130]

Anlage 27

(((eTicket Deutschland

Tabelle 4: Namensraumkürzel und XSDs für Beispielrelease 3.1.1

Tabelle 4 zeigt die entstandenen Namensraumkürzel und XSDs. Für ein Release 3.1.1 sind 4 Namensraumkürzel im Einsatz mit 3 zusätzlichen Komponentenschemas. Hinweis: Die neuen Namensraumkürzel treten in i.d.R. nur in der WSDL auf, da dort die Än- derungen zusammenfließen. In den XSDs ist das nicht notwendig, da für alle Änderungen innerhalb eines Releases eigene Schemas verwendet werden.

4.3.9 Mitgeltende Dokumente

[1] Zentrale Webseite der technischen Schnittstellen: http://ion.vm.eticket-deutschland.de [2] Abhandlung: Erweiterung von Aufzählungen in XML Schema Definitionen http://www.ibm.com/developerworks/library/x-extenum/ [3] Versionierung von XML/XSD Schnittstellen, eine Abhandlung http://msdn.microsoft.com/en-us/library/ms954726.aspx [4] W3C Schools http://www.w3schools.com/schema/schema_complex_any.asp und W3C http://www.w3.org/TR/xmlschema11-1/

122

[Seite 131]

Anlage 27

Kapitel 10: Testvorschrift gem. Kap. 2, § 4 Abs.2

Testvorschrift für die Zulassung von VU/VV zum KA-ION-

Wirkbetrieb

Thema: Anschluss an ZVM und KOSES Dateiname/Version: Testvorschrift zum Anschluss an das KA-ION v20.doc Erstellt am: 08.02.2012 Zuletzt geändert am: 05.06.2018 15:00 Ersteller: Elke Fischer, Hartmut Loerch

[Seite 132]

Anlage 27

Versionsverwaltung

Version Bearbeiter Datum Bemerkung 1.0 Fischer, 14.12.2015 Fertigstellung der Testvorschrift Loerch 2.0 Fischer, 21.03.2017 Entfernung der Fehlerfälle, Loerch Ergänzung Kap. 3 um Schritttabelle zur Vorgehens- weise 25.04.2017 Tabellenverzeichnis ergänzt

Seite 124 von 136

[Seite 133]

Anlage 27

Inhaltsverzeichnis

Inhaltsverzeichnis ............................................................................................... 125 Abbildungsverzeichnis ...................................................................................... 125 1 Zulassung von VU/VV zum ION-Wirkbetrieb ................................................ 127 2 Erläuterungen zu den jeweiligen KVP-, DL- und PV-Tests ......................... 130 3 Operativer Prozess ......................................................................................... 131

Anlage 1: Anwendungsfälle zum Basiskonzept gemäß KA SysLHKVPS im jeweils aktuellen Release 134 Anlage 2: Anwendungsfälle zum Basiskonzept gemäß KA SysLHPVS im jeweils aktuellen Release 135 Anlage 3: Anwendungsfälle zum Basiskonzept gemäß KA SysLHDLS im jeweils aktuellen Release 136

Abbildungsverzeichnis

Abbildung 1: Grafische Darstellung des Zulassungsverfahrens zum Anschalten neuer KA-Teilnehmersysteme ................................................................................. 129

Tabellenverzeichnis

Tabelle 1: Ablauf Testdurchführung ............................................................................... 132

Seite 125 von 136

[Seite 134]

Anlage 27

Tabelle 2: Beispiel für den abschließenden Report ........................................................ 132

Seite 126 von 136

[Seite 135]

Anlage 27

1 Zulassung von VU/VV zum ION-Wirkbetrieb

Die erforderliche Schritte zur Anbindung an ZVM und KOSES sind im Dokument „Anleitung Anschluss ZVM KOSES“ geregelt. Die jeweils aktuelle Fassung dieses Dokumentes ist Bestandteil des „Starter Kit“ und kann im ASM abgerufen werden. Ergänzend zu den bisher in diesem Dokument beschriebenen Schritten 16, 17 und 18 (siehe Kapitel 3) wird im Folgenden das Ver- fahren zum Nachweis der erfolgreichen Tests zur Zulassung zum Wirkbetrieb festgelegt.

Mit dem vorgeschlagenen Prozedere wird Ihnen als (((eTicket-Teilnehmersystembetreiber eine aussagekräftige Abnahmeprüfung durch ihre Systemhersteller vor Auslieferung des bestellten Systems an Sie an die Hand gegeben. Der Hersteller testet seine Sys- teme vor Auslieferung an Sie sowieso. Die Testfälle helfen ihm dabei, die Funktionsfähigkeit sicher zu stellen. Die Testdurchführung legt in den Händen von Worldline und Ihrem Systemhersteller. VDV-ETS begleitet den Prozess informativ wie bei der Zertifizierung und unterstützt bei der Findung von Lösungen in Problemfällen. Sie als (((eTicket-Teilnehmersystembetreiber haben mit den Tests aufwandsmäßig nichts zu tun, können aber natürlich jederzeit das Geschehen begleiten bzw. sich aktiv einbringen. Zum Abschluss der Test wird ein Testprotokoll erzeugt, dass der Hersteller Ihnen bei Übergabe des Systems als Bestandteil der Abnahmedokumente vorlegen kann.

Grundlage für die Zulassung ist folgendes Verfahren:

1. Erfolgreiches Absolvieren der im Anhang für die jeweiligen KA-Referenzsysteme festgelegten Testfälle im L2-Testsystem ohne WSS (Webservice Security). Dies ist die Voraussetzung für Tests im L2-Testsystem mit WSS.

2. Nachweis erfolgt durch einen L2-Testreport für die testende Organisation (L2-ORG_ID). Dieser wird dem Tester von World- line bereitgestellt.

3. Erfolgreiches Absolvieren der im Anhang für die jeweiligen KA-Referenzsysteme festgelegten Testfälle im L2-Testsystem verschlüsselt. Dies ist die Voraussetzung für die Zulassung zum Wirkbetrieb.

Seite 127 von 136

[Seite 136]

Anlage 27

4. War der Test in beiden L2-Test-Systemen erfolgreich, wird durch VDV-ETS per Jira-Eintrag die Freigabe zur Kommunikati- on im Wirksystem erteilt. Grundlage dafür ist ein durch Worldline erzeugter Testreport, indem die erfolgreich ausgeführten Testfälle des Systems (Abbildung 2) gekennzeichnet sind.

Worldline: Testsystem ohne WSS Worldline: Testsystem mit WSS Worldline: Produktionssystem

Erstellung eines Jira-Users (OrgID, Name, Email) Erstellung eines Jira-Users (OrgID, Name, Email) Einrichtung im Test-ZVM/KOSE mit WSS (OrgID) Einrichtung im Test-ZVM/KOSE ohne WSS (OrgID) Einrichtung im Produktions-ZVM/KOSE (OrgID)

13. Jira-Eintrag

14. Jira-Eintrag Bei korrekter Or 1 g . E I J D m i - r a T a i e - l, s E t R i , n o N t ll r a e a m g e, Rüc 2 k . m Ji e r l a d - ung Freig R B a ü e c b i k k e m o f r e ü r l e r d k u S t n t e u g r fe 2 Rüc 8 k . m Ji e r l a d - ung F O r r e g i I g D a , R b N ü e a c m k fü m e r e , P l E d r m u o n a d g i u l, k R t o io ll n e Rü 1 ck 4 m . J e i l r d a u - ng

15. Rückmeldung des Systems

16. Kontrolle ETS: Steuerung ETS: Steuerung ETS: Steuerung eines ZVM des Prozesses des Prozesses des Prozesses Reports

17. Kontrolle

18. Rückmeldung eines ZVM des Systems Reports

19. Freigabe: 9. Freigabe: Testbeginn 6. Übersendung Testbeginn 12. Übersendung 15. Freigabe: ohne WSS des ZVM Reports mit WSS des ZVM Reports Produktion

Verkehrsunternehmen/-verbünde Verkehrsunternehmen/-verbünde Verkehrsunternehmen/-verbünde Verbindungstest ohne WSS Verbindungstest mit WSS Produktion

Verkehrsunternehmen/ VDV ETS Worldline -verbünde

Seite 128 von 136

[Seite 137]

Anlage 27

Abbildung 15: Grafische Darstellung des Zulassungsverfahrens zum Anschalten neuer KA-Teilnehmersysteme

Seite 129 von 136

[Seite 138]

Anlage 27

VDV-

2 Erläuterungen zu den jeweiligen KVP-, DL- und PV-Tests

Für die Zulassung sind je KA-Referenzsystem definierte Testfälle auszuführen. Die Testfälle sind jeweils für die Rollen der Teilnehmersysteme

 PV

 KVP

 DL gesondert auszuführen, auch wenn ein System mehrere Rollen umfasst. Die Testfallauflistung findet sich in den Anlagen 1,2 bzw. 3.

Rollenspezifisch sind unterschiedliche Anzahlen von Testfällen auszuführen. Diese sind jeweils abgestimmt mit den ETS-Dienstleistern (Worldline für ZMV/KOSES und IVU für AHS).

Für die Tests gegen KOSE und AHS sind die jeweiligen L2-Testsysteme immer ver- fügbar  Level 2 Testsystem ohne WSS https://test2-ion.vm.eticket- deutschland.de/zvm/1,  Level 2 Testsystem mit WSS https://test-ion.vm.eticket-deutschland.de/zvm/1.

An beide URLs kann man die im Testsystem umgesetzte Schnittstellenversion der TX-Nachrichten senden. Hinweis: Für den unverschlüsselten Test gegen AHS ist eine vorherige Abstimmung mit IVU erforderlich.

Die Testfälle sind im Umfang als Minimalanforderung in jedem Migrationsszenario verpflichtend. Nur falls das im Teilnahmevertrag eines KA-Teilnehmers vereinbarte Migrationsszenario Testfälle explizit ausschließt, müssen sie für die Zeit des Aus- schlusses nicht absolviert werden.

Wenn die Tests erfolgreich absolviert wurden, ist damit nachgewiesen worden, dass der Anschluss an das ION und die generelle Kommunikation mit der ZVM funktioniert und auch mit KOSES und AHS erfolgreich kommuniziert werden kann.

Die Testfälle wurden aus Anwendungsfällen der Systemlastenhefte abgeleitet. Dabei wurden solche Anwendungsfälle ausgewählt, die bei korrekter Ausführung TXB- Nachrichten erzeugen. Im Falle z.B. der Sperrmitteilung wird die VX-Nachricht der ZVM bewertet.

Seite 130 von 136

[Seite 139]

Anlage 27

VDV-

3 Operativer Prozess Für die Testdurchführung ist folgender Ablauf einzuhalten:

 Tests rechtzeitig konzipieren und Testzeitraum planen.

 Mittels Jira-Ticket-Typ „Vorgang“ Tests frühzeitig anmelden - Mindestvorlauf 14 Tage.

 Testbeginn erfolgt erst nach Abstimmung und Jira-Bestätigung durch World- line und IVU.

 Die Aufnahme der Tests sowie das Testende müssen durch den Tester offizi- ell über Jira kommuniziert werden.

 Der Tester erhält von Worldline automatisch tägliche Reports zur Kontrolle.

 Der Tester erhält einen abschließenden Report als Vollnachweis (siehe.

 Nach abschließendem Report als Vollnachweis erfolgt die Freigabe für Level 3, d.h. für das Produktionssystem, durch ETS.

Im Einzelnen laufen die Schritte wie folgt ab:

Seite 131 von 136

[Seite 140]

Anlage 27

VDV-

Tabelle 1: Ablauf Testdurchführung

Ein Beispiel für den Testreport finden sie in der folgenden Tabelle:

Tabelle 2: Beispiel für den abschließenden Report

Seite 132 von 136

[Seite 141]

Anlage 27

VDV-

Anlage 1: Anwendungsfälle zum Basiskonzept gemäß KA SysLHKVPS im jeweils aktuellen Release

Seite 133 von 136

[Seite 142]

[Seite 143]

Anlage 27

Anlage 2: Anwendungsfälle zum Basiskonzept gemäß KA SysLHPVS im jeweils aktuellen Release

[Seite 144]

Anlage 27

Anlage 3: Anwendungsfälle zum Basiskonzept gemäß KA SysLHDLS im jeweils aktuellen Release

[Seite 145]

Anlage 27

VDV-Kernapplikation

Migrationsszenarien in den Ausbauvarianten des (((eTicket Deutschland

Anlage 2 zum (((eTicket-Teilnahmevertrag

Stand: 30. August 2017

Thema: VDV-Kernapplikation Migrationsszenarien in den Aus- bauvarianten des (((eTicket Deutschland (KA Migrationsszenarien)

Dateiname: Anlage_2_KA Migrationsszenarien_V160.docx

Erstellt am: 10.02.2010

Zuletzt geändert am: 08.09.2017 11:16:15

Ersteller: VDV eTicket Service GmbH & Co. KG

[Seite 146]

Anlage 27

Releaseverwaltung

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 2 von 104

[Seite 147]

Anlage 27

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 3 von 104

[Seite 148]

Anlage 27

Inhaltsverzeichnis

Releaseverwaltung ................................................................................................................ 2 Inhaltsverzeichnis .................................................................................................................. 4 Tabellenverzeichnis ............................................................................................................... 8 Abbildungsverzeichnis ......................................................................................................... 11 Referenzen .......................................................................................................................... 12

Abkürzungsverzeichnis ........................................................................................................ 13

Vorwort ................................................................................................................................ 14

1. Die Ausbauvarianten des (((eTicket Deutschland ................................................ 17 1.1. Ausbauvariante 1: (((eBezahlen ........................................................................... 18 1.2. Ausbauvariante 2 (((eFahrschein /(((eKontrolle EFS + Akzeptanz von POB/PEB+WEB ................................................................................................... 20 1.3. Ausbauvariante 2a (((eFahrschein Abo / (((eKontrolle EFS .................................. 23 1.4. Ausbauvariante 2b-1 - (((eFahrschein / (((eKontrolle EFS + Akzeptanz POB/PEB ............................................................................................................................ 25 1.5. Ausbauvariante 2b-2 - (((eFahrschein / (((eKontrolle EFS + Akzeptanz WEB ...... 27 1.6. Ausbauvariante 3 Automatisierte Fahrpreisermittlung .......................................... 29

1.7. Ausbauvariante 3a-1 - Check-In/Check-Out räumlich begrenzt mit POB/PEB ...... 33

1.8. Ausbauvariante 3a-2 - Check-In/Check-Out räumlich begrenzt mit WEB ............. 35

2. Optionale Ergänzungen ....................................................................................... 38

2.1. Multiberechtigung ................................................................................................ 38 2.2. Aktionsmanagement ............................................................................................ 38 2.3. Produkt- und Kontrollmodule ................................................................................ 38 2.4. Statische Berechtigung ........................................................................................ 39 2.5. Tarifliche Besonderheiten .................................................................................... 39 3. Pakete ................................................................................................................. 40 3.1. Basispaket ........................................................................................................... 40

3.2. Pakete für Ausbauvarianten ................................................................................. 40

3.3. Pakete für optionale Ergänzungen ....................................................................... 41

3.4. Grafische Darstellung der Pakete der Ausbauvarianten inklusive der optionalen Ergänzungen ....................................................................................................... 42

4. Anwendungsfälle für die Systemkomponenten ..................................................... 47

4.1. Anwendungsfälle für das Kundenvertragspartner-System (KVPS) ....................... 47

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 4 von 104

[Seite 149]

Anlage 27

4.1.1. Ausbauvariante 1 ................................................................................................. 47 4.1.2. Ausbauvariante 2 ................................................................................................. 49 4.1.3. Ausbauvariante 2a ............................................................................................... 51 4.1.4. Ausbauvariante 2b-1 ............................................................................................ 53 4.1.5. Ausbauvariante 2b-2 ............................................................................................ 55 4.1.6. Ausbauvariante 3 ................................................................................................. 57 4.1.7. Ausbauvariante 3a-1 ............................................................................................ 59 4.1.8. Ausbauvariante 3a-2 ............................................................................................ 61

4.2. Anwendungsfälle für Kundenvertragspartner-Terminals (KVPT) .......................... 64

4.2.1. Ausbauvariante 1 ................................................................................................. 64 4.2.2. Ausbauvariante 2 ................................................................................................. 65 4.2.3. Ausbauvariante 2a ............................................................................................... 66 4.2.4. Ausbauvariante 2b-1 ............................................................................................ 67 4.2.5. Ausbauvariante 2b-2 ............................................................................................ 68 4.2.6. Ausbauvariante 3 ................................................................................................. 69 4.2.7. Ausbauvariante 3a-1 ............................................................................................ 70 4.2.8. Ausbauvariante 3a-2 ............................................................................................ 71

4.3. Anwendungsfälle für das Dienstleister-System (DLS) .......................................... 73

4.3.1. Ausbauvariante 1 ................................................................................................. 73 4.3.2. Ausbauvariante 2 ................................................................................................. 74 4.3.3. Ausbauvariante 2a ............................................................................................... 75 4.3.4. Ausbauvariante 2b-1 ............................................................................................ 75 4.3.5. Ausbauvariante 2b-2 ............................................................................................ 75 4.3.6. Ausbauvariante 3 ................................................................................................. 76 4.3.7. Ausbauvariante 3a-1 ............................................................................................ 77 4.3.8. Ausbauvariante 3a-2 ............................................................................................ 78

4.4. Anwendungsfälle für Dienstleister-Terminals (DLT) ............................................. 80

4.4.1. Ausbauvariante 1 ................................................................................................. 80 4.4.2. Ausbauvariante 2 ................................................................................................. 80 4.4.3. Ausbauvariante 2a ............................................................................................... 80 4.4.4. Ausbauvariante 2b-1 ............................................................................................ 81 4.4.5. Ausbauvariante 2b-2 ............................................................................................ 81 4.4.6. Ausbauvariante 3 ................................................................................................. 81 4.4.7. Ausbauvariante 3a-1 ............................................................................................ 81 4.4.8. Ausbauvariante 3a-2 ............................................................................................ 82

4.5. Anwendungsfälle für das Produktverantwortlichen-System (PVS) ........................ 83

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 5 von 104

[Seite 150]

Anlage 27

4.5.1. Ausbauvariante 1 ................................................................................................. 83 4.5.2. Ausbauvariante 2 ................................................................................................. 84 4.5.3. Ausbauvariante 2a ............................................................................................... 86 4.5.4. Ausbauvariante 2b-1 ............................................................................................ 87 4.5.5. Ausbauvariante 2b-2 ............................................................................................ 88 4.5.6. Ausbauvariante 3 ................................................................................................. 89 4.5.7. Ausbauvariante 3a-1 ............................................................................................ 91 4.5.8. Ausbauvariante 3a-2 ............................................................................................ 92

5. Anwendungsfälle für die optionalen Ergänzungen ............................................... 95

5.1. Anwendungsfälle der optionalen Ergänzungen für das Kundenvertragspartner- System (KVPS) .................................................................................................... 95

5.1.1. Optionale Ergänzung Multiberechtigung .............................................................. 95

5.1.2. Optionale Ergänzung Aktionsmanagement .......................................................... 95

5.1.3. Optionale Ergänzung Produkt- und Kontrollmodul................................................ 96

5.1.4. Optionale Ergänzung Statische Berechtigung ...................................................... 96

5.1.5. Optionale Ergänzung tarifliche Besonderheiten ................................................... 96

5.2. Anwendungsfälle der optionalen Ergänzungen für das Kundenvertragspartner- Terminal (KVPT) .................................................................................................. 97

5.2.1. Optionale Ergänzung Multiberechtigung .............................................................. 97

5.2.2. Optionale Ergänzung Aktionsmanagement .......................................................... 97

5.2.3. Optionale Ergänzung Produkt- und Kontrollmodul................................................ 97

5.2.4. Optionale Ergänzung Statische Berechtigung ...................................................... 97

5.2.5. Optionale Ergänzung tarifliche Besonderheiten ................................................... 98

5.3. Anwendungsfälle der optionalen Ergänzungen für das Dienstleister-System (DLS) ............................................................................................................................ 99

5.3.1. Optionale Ergänzung Multiberechtigung .............................................................. 99

5.3.2. Optionale Ergänzung Aktionsmanagement .......................................................... 99

5.3.3. Optionale Ergänzung Produkt- und Kontrollmodul................................................ 99

5.3.4. Optionale Ergänzung Statische Berechtigung ...................................................... 99

5.3.5. Optionale Ergänzung tarifliche Besonderheiten ................................................... 99

5.4. Anwendungsfälle der optionalen Ergänzungen für das Dienstleister-Terminal (DLT) .......................................................................................................................... 100

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 6 von 104

[Seite 151]

Anlage 27

5.4.1. Optionale Ergänzung Multiberechtigung ............................................................ 100

5.4.2. Optionale Ergänzung Aktionsmanagement ........................................................ 100

5.4.3. Optionale Ergänzung Produkt- und Kontrollmodul.............................................. 100

5.4.4. Optionale Ergänzung Statische Berechtigung .................................................... 100

5.4.5. Optionale Ergänzung tarifliche Besonderheiten ................................................. 100

5.5. Anwendungsfälle der optionalen Ergänzungen für das Produktverantwortlichen- System (PVS) .................................................................................................... 102

5.5.1. Optionale Ergänzung Multiberechtigung ............................................................ 102

5.5.2. Optionale Ergänzung Aktionsmanagement ........................................................ 102

5.5.3. Optionale Ergänzung Produkt- und Kontrollmodul.............................................. 103

5.5.4. Optionale Ergänzung Statische Berechtigung .................................................... 103

5.5.5. Optionale Ergänzung tarifliche Besonderheiten ................................................. 103

6. Elementarprozesse ............................................................................................ 104

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 7 von 104

[Seite 152]

Anlage 27

Tabellenverzeichnis

Tabelle 1: Ausbauvarianten und Pakete............................................................................... 40

Tabelle 2: Optionale Ergänzungen und Pakete .................................................................... 41

Tabelle 3: Ausbauvariante 1 für das Kundenvertragspartner-System (KVPS) ...................... 49

Tabelle 4: Ausbauvariante 2 für das Kundenvertragspartner-System (KVPS) ...................... 51

Tabelle 5: Ausbauvariante 2a für das Kundenvertragspartner-System (KVPS) .................... 53

Tabelle 6: Ausbauvariante 2b-1 für das Kundenvertragspartner-System (KVPS) ................. 55

Tabelle 7: Ausbauvariante 2b-2 für das Kundenvertragspartner-System (KVPS) ................. 57

Tabelle 8: Ausbauvariante 3 für das Kundenvertragspartner-System (KVPS) ...................... 59

Tabelle 9: Ausbauvariante 3a-1 für das Kundenvertragspartner-System (KVPS) ................. 61

Tabelle 10: Ausbauvariante 3a-2 für das Kundenvertragspartner-System (KVPS) ............... 63

Tabelle 11: Ausbauvariante 1 für die Kundenvertragspartner-Terminals (KVPT) ................. 65

Tabelle 12: Ausbauvariante 2 für die Kundenvertragspartner-Terminals (KVPT) ................. 66

Tabelle 13: Ausbauvariante 2a für die Kundenvertragspartner-Terminals (KVPT) ............... 67

Tabelle 14: Ausbauvariante 2b-1 für die Kundenvertragspartner-Terminals (KVPT) ............ 68

Tabelle 15: Ausbauvariante 2b-2 für die Kundenvertragspartner-Terminals (KVPT) ............ 69

Tabelle 16: Ausbauvariante 3 für die Kundenvertragspartner-Terminals (KVPT) ................. 70

Tabelle 17: Ausbauvariante 3a-1 für die Kundenvertragspartner-Terminals (KVPT) ............ 71

Tabelle 18: Ausbauvariante 3a-2 für die Kundenvertragspartner-Terminals (KVPT) ............ 72

Tabelle 19: Ausbauvariante 1 für das Dienstleister-System (DLS) ....................................... 74

Tabelle 20: Ausbauvariante 2 für das Dienstleister-System (DLS) ....................................... 75

Tabelle 21: Ausbauvariante 3 für das Dienstleister-System (DLS) ....................................... 77

Tabelle 22: Ausbauvariante 3a-1 für das Dienstleister-System (DLS) .................................. 78

Tabelle 23: Ausbauvariante 3a-2 für das Dienstleister-System (DLS) .................................. 79

Tabelle 24: Ausbauvariante 1 für die Dienstleister-Terminals (DLT) ..................................... 80

Tabelle 25: Ausbauvariante 2 für die Dienstleister-Terminals (DLT) ..................................... 80

Tabelle 26: Ausbauvariante 3 für die Dienstleister-Terminals (DLT) ..................................... 81

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 8 von 104

[Seite 153]

Anlage 27

Tabelle 27: Ausbauvariante 3a-1 für die Dienstleister-Terminals (DLT) ............................... 82

Tabelle 28: Ausbauvariante 3a-2 für die Dienstleister-Terminals (DLT) ............................... 82

Tabelle 29: Ausbauvariante 1 für das Produktverantwortlichen-System (PVS)..................... 84

Tabelle 30: Ausbauvariante 2 für das Produktverantwortlichen-System (PVS)..................... 85

Tabelle 31: Ausbauvariante 2a für das Produktverantwortlichen-System (PVS)................... 87

Tabelle 32: Ausbauvariante 2b-1 für das Produktverantwortlichen-System (PVS) ............... 88

Tabelle 33: Ausbauvariante 2b-2 für das Produktverantwortlichen-System (PVS) ............... 89

Tabelle 34: Ausbauvariante 3 für das Produktverantwortlichen-System (PVS)..................... 91

Tabelle 35: Ausbauvariante 3a-1 für das Produktverantwortlichen-System (PVS) ............... 92

Tabelle 36: Ausbauvariante 3a-2 für das Produktverantwortlichen-System (PVS) ............... 94

Tabelle 37: Multiberechtigung für das Kundenvertragspartner-System (KVPS).................... 95

Tabelle 38: Aktionsmanagement für das Kundenvertragspartner-System (KVPS) ............... 95

Tabelle 39: Produkt- und Kontrollmodule für das Kundenvertragspartner-System (KVPS) ... 96

Tabelle 40: Statische Berechtigung für das Kundenvertragspartner-System (KVPS) ........... 96

Tabelle 41: tarifliche Besonderheiten für das Kundenvertragspartner-System (KVPS) ......... 96

Tabelle 42: Multiberechtigung für das Kundenvertragspartner-Terminal (KVPT) .................. 97

Tabelle 43: Aktionsmanagement für das Kundenvertragspartner-Terminal (KVPT) ............. 97

Tabelle 44: Produkt- und Kontrollmodule für das Kundenvertragspartner-Terminal (KVPT) . 97

Tabelle 45: Statische Berechtigung für das Kundenvertragspartner-Terminal (KVPT) ......... 98

Tabelle 46: tarifliche Besonderheiten für das Kundenvertragspartner-Terminal (KVPT) ....... 98

Tabelle 47: Multiberechtigung für das Dienstleister-System (DLS) ....................................... 99

Tabelle 48: Produkt- und Kontrollmodule für das Dienstleister-System (DLS) ...................... 99

Tabelle 49: Statische Berechtigung für das Dienstleister-System (DLS) .............................. 99

Tabelle 50: tarifliche Besonderheiten für das Dienstleister-System (DLS) ............................ 99

Tabelle 51: Multiberechtigung für das Dienstleister-Terminal (DLT) ................................... 100

Tabelle 52: Produkt- und Kontrollmodule für das Dienstleister-Terminal (DLT) .................. 100

Tabelle 53: Statische Berechtigung für das Dienstleister-Terminal (DLT) ........................... 100

Tabelle 54: tarifliche Besonderheiten für das Dienstleister-Terminal (DLT) ........................ 100

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 9 von 104

[Seite 154]

Anlage 27

Tabelle 55: Multiberechtigung für das Produktverantwortlichen-System (PVS) .................. 102

Tabelle 56: Aktionsmanagement für das Produktverantwortlichen-System (PVS) .............. 102

Tabelle 57: Produkt- und Kontrollmodule für das Produktverantwortlichen-System (PVS) . 103

Tabelle 58: Statische Berechtigung für das Produktverantwortlichen-System (PVS) .......... 103

Tabelle 59: tarifliche Besonderheiten für das Produktverantwortlichen-System (PVS) ....... 103

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 10 von 104

[Seite 155]

Anlage 27

Abbildungsverzeichnis

Abbildung 1: KA-Teilnehmersicht - Ausbauvariante 1 .......................................................... 18 Abbildung 2: KA-Teilnehmersicht - Ausbauvariante 2 .......................................................... 20 Abbildung 3: KA-Teilnehmersicht - Ausbauvariante 2a ........................................................ 23 Abbildung 4: KA-Teilnehmersicht - Ausbauvariante 2b-1 ..................................................... 25 Abbildung 5: KA-Teilnehmersicht - Ausbauvariante 2b-2 ..................................................... 27 Abbildung 6: KA-Teilnehmersicht - Ausbauvariante 3 .......................................................... 29 Abbildung 7: KA-Teilnehmersicht - Ausbauvariante 3a-1 ..................................................... 33 Abbildung 8: KA-Teilnehmersicht - Ausbauvariante 3a-2 ..................................................... 35 Abbildung 9: KA-Herstellersicht - Ausbauvariante 1 ............................................................. 42 Abbildung 10: KA-Herstellersicht - Ausbauvariante 2 ........................................................... 43 Abbildung 11: KA-Herstellersicht - Ausbauvariante 2a ......................................................... 43 Abbildung 12: KA-Herstellersicht - Ausbauvariante 2b-1 ...................................................... 44 Abbildung 13: KA-Herstellersicht - Ausbauvariante 2b-2 ...................................................... 44 Abbildung 14: KA-Herstellersicht - Ausbauvariante 3 ........................................................... 45 Abbildung 15: KA-Herstellersicht - Ausbauvariante 3a-1 ...................................................... 45 Abbildung 16: KA-Herstellersicht - Ausbauvariante 3a-2 ...................................................... 46

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 11 von 104

[Seite 156]

Anlage 27

Referenzen

[1] VDV-Kernapplikation, Einheitliche Kundenschnittstelle für ein mehrstufiges interope- rables elektronisches Fahrgeldmanagement (KA KUSCH-SPEC)

[2] VDV-Kernapplikation, Verfahrensanweisung zur Prüfung der NM_Transaktionen in

EFM-Referenzsystemen (KA Tx_Prüfungs-ANW)

[3] (((eTicket-Teilnahmevertrag - Vertrag über die Teilnahme am (((eTicket-Deutschland

[4] (((eTicket-Regelwerk zur Teilnahme am (((eTicket-Deutschland auf Basis der VDV- Kernapplikation

[5] VDV-Kernapplikation Systemlastenheft mit den Teilen: Hauptdokument Teil: Dienstleister-System (DLS) Teil: Kundenvertragspartner-System (KVPS) Teil: Produktverantwortlichen-System (PVS) Teil: Personalbediente KVP-ReferenzTerminals (PbKVPT) Teil: Selbstbediente KVP-ReferenzTerminals (SbKVPT) Teil: DL-ReferenzTerminals (DLT)

[6] VDV-Kernapplikation, Schnittstellenspezifikationen der Referenzsysteme Kundenver- tragspartner (KVP), Dienstleister (DL), Produktverantwortlicher (PV), Applikations- herausgeber (AH), Sperrlistenservice (KOSE) (KA SST-SPEC)

[7] VDV-Kernapplikation, Aktionsmanagement (KA AktM-SPEC)

[8] VDV-Kernapplikation, Multiberechtigung (KA MultiBER-SPEC)

[9] VDV-Kernapplikation, Statische Berechtigung (KA STB-SPEC )

[10] VDV-Kernapplikation, Technische Spezifikation EFS-Produkt- & EFS-Kontrollmodule (KA EFS-PKM-Tech-SPEC) und die weiteren Spezifikationen zu PKM

[11] VDV-Kernapplikation, Glossar (KA Glossar)

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 12 von 104

[Seite 157]

Anlage 27

Abkürzungsverzeichnis

siehe KA-Glossar [11]

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 13 von 104

[Seite 158]

Anlage 27

Vorwort

Zielstellung des (((eTicket Deutschland ist es, den Fahrgästen ein elektronisches Medium in die Hand zu geben, das deutschlandweit funktioniert. Dieses, in einem Verkehrsunterneh- men in Deutschland ausgegebene Medium mit der VDV-Kernapplikation kann der Fahrgast auch in allen anderen (((eTicket-Deutschland-Regionen einsetzen, die die VDV- Kernapplikation anwenden und die zur Gewährleistung der interoperablen Nutzung auch vertraglich zusammenarbeiten. Dies wird durch den (((eTicket-Teilnahmevertrag [3] und das dazugehörige Regelwerk [4] festgelegt.

Die Verkehrsunternehmen oder -verbünde entscheiden sich frei für die Ausbauvariante(n),

die sie in ihrem elektronischen Fahrgeldmanagementsystem (EFM) einführen. Diese Ent-

scheidung bleibt den Verkehrsunternehmen und -verbünden in den einzelnen Regionen vor- behalten und wird aus Wirtschaftlichkeitsgesichtspunkten vor Ort getroffen.

Die Einführung von (((eTicket Deutschland erfolgt schrittweise, so dass die Kunden in unter-

schiedlichen Regionen durchaus auf verschiedene Ausbauvarianten treffen können. Inner-

halb der Ausbauvarianten können Migrationsszenarien vereinbart werden. Auch für diese

sind jeweils Mindestanforderungen einzuhalten, um Funktionalität, Sicherheit und Interope-

rabilität des (((eTicket Deutschland für alle Kunden und Teilnehmer gleichsam zu garantie- ren.

Das EFM-System (((eTicket Deutschland untergliedert sich in insgesamt fünf logische Rol-

len, die zur Erfüllung der Aufgaben im System eng miteinander verknüpft sind. Folgende logische Rollen sind definiert:

• Kundenvertragspartner (KVP)
• Nutzer / Kunde (N/K)
• Dienstleister (DL)
• Produktverantwortlicher (PV)
• Applikationsherausgeber (AH)

Nur im Zusammenspiel der fünf logischen Rollen funktioniert ein EFM-System im (((eTicket Deutschland.

Die Systeme, die Funktionen der logischen Rollen ausführen, sind über das Interoperabili-

tätsnetzwerk (ION) untereinander und mit den zentralen Systemen verbunden.

Um die Übersichtlichkeit bezüglich des Handelns für Kunden, die sich in verschiedenen

EFM-Systemen bewegen, zu bewahren, wurden für die einzelnen, per Spezifikation definier- ten Ausbauvarianten Migrationsregelungen (im Folgenden zur Vereinfachung der Begriffs-

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 14 von 104

[Seite 159]

Anlage 27

verwendung ebenfalls als Ausbauvarianten bezeichnet) entwickelt. Jede zulässige Migrati-

onsregelung ist jeweils einer Vollausbauvariante gemäß KA KUSCH-Spec [1] zugeordnet und durch eine Erweiterung in der Nummerierung gekennzeichnet.

Unter Berücksichtigung der Migrationsregelungen werden folgende Ausbauvarianten defi- niert:

• Ausbauvariante 1: (((eBezahlen

• Ausbauvariante 2: (((eFahrschein / (((eKontrolle EFS + POB/PEB+WEB o Ausbauvariante 2a: (((eFahrschein Abo / (((eKontrolle EFS o Ausbauvariante 2b-1: (((eFahrschein / (((eKontrolle EFS+POB/PEB o Ausbauvariante 2b-2: (((eFahrschein / (((eKontrolle EFS+WEB

• Ausbauvariante 3: IN-OUT mit POB/PEB + WEB o Ausbauvariante 3a-1: IN-OUT räumlich begrenzt mit POB/PEB

o Ausbauvariante 3a-2: IN-OUT räumlich begrenzt mit WEB

Zu einzelnen Ausbauvarianten können darüber hinaus folgende optionale Ergänzungen zu-

gewählt werden:

• Multiberechtigungen (MultiBER; nur in Verbindung mit Ausbauvariante 2, 2a, 2b-1, 2b-2)
• Aktionsmanagement (AktM; nur in Verbindung mit Ausbauvariante 2, 2a, 2b-1, 2b-2)
• Produkt- und Kontrollmodule (PKM; in Verbindung mit allen Ausbauvarianten)
• Statische Berechtigung (STB, VDV-Barcode; kann im Bereich des Handy- und/oder Onlinetickets auch als "autarke Lösung" eingesetzt werden)
• Tarifliche Besonderheiten

Um für die jeweilige Ausbauvariante die notwendigen Anwendungsfälle einfach und über-

sichtlich durch den (((eTicket Deutschland Teilnehmer auswählen zu können, werden diese

in funktionsorientierten Paketen zusammengefasst, die gemeinsam ein funktionsfähiges Sys-

tem oder eine funktionsfähige Systemkomponente beschreiben. Der Funktionsumfang dieser Ausbauvarianten in Form von Paketen wird in diesem Dokument beschrieben.

Damit ist durch definierte Lieferumfänge eine Vereinheitlichung der Anforderungen an die Systemhersteller gegeben und die Anpassung und Pflege der Systeme wird vereinfacht. Die Systemhersteller können einfach ermitteln, welche Pakete für die Realisierung einer Aus- bauvariante erforderlich sind und ob sie diese schon im Zusammenhang mit einer anderen Ausbauvariante realisiert haben.

Das Dokument stellt darüber hinaus das Bindeglied zwischen dem (((eTicket- Teilnahmevertrag nebst Regelwerk und den Systemlastenheften mit Anforderungen an Sys-

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 15 von 104

[Seite 160]

Anlage 27

temkomponenten der VDV-Kernapplikation (KA SysLH) sowie den Schnittstellenspezifikatio- nen der Referenzsysteme für elektronisches Fahrgeldmanagement (KA SST-Spec) dar. Der

jeweilige Funktionsumfang ist bei Prüfung zur Komponentenzertifizierung nachzuweisen und

somit unerlässlich für eine Zertifikatserteilung.

Laut (((eTicket- Teilnahmevertrag ist es Aufgabe der Teilnehmer am (((eTicket Deutschland die vorgegebenen Anforderungen einzuhalten.

Das Dokument umfasst keine Angaben, in welchem Umfang (Anzahl, Orte,…) ein EFM- System aufzubauen ist. Dies obliegt der Entscheidung des jeweiligen EFM-Projektes.

Im (((eTicket Deutschland kommen kontaktlos arbeitende Nutzermedien (NM) zum Einsatz, die über eine ISO/IEC 14443-Schnittstelle Typ A oder B verfügen. Die Nutzung von Handys

mit NFC-Schnittstelle ist möglich, wenn diese die für ein KA-NM geforderten und sicherheits-

relevanten technischen Eigenschaften erfüllen. Technische Anforderungen an NM, die in Wide Range (Bi-/Bo-) Systemen einsetzbar sind, werden derzeit nicht gestellt.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 16 von 104

[Seite 161]

Anlage 27

1. Die Ausbauvarianten des (((eTicket Deutschland

Die VDV-Kernapplikation ermöglicht dem Kunden, unterschiedliche EFM-Produkte in Form

von Berechtigungen auf seine ÖPV-Applikation auf dem Nutzermedium zu laden und diese in drei unterschiedlichen Ausbauvarianten des (((eTicket Deutschland zu benutzen.

Zur Erreichung der Interoperabilität verfolgen die (((eTicket Deutschland Teilnehmer und die VDV-ETS KG das Ziel, dass durch einen Kundenvertragspartner eine (((eBezahlberechti- gung an seinen Kunden ausgegeben wird, die den Erwerb von Fahrscheinen in allen Syste- men der Ausbauvarianten „(((eBezahlen“ und „(((eFahrschein mit (((eKontrolle“ und die Inan-

spruchnahme von Beförderungsleistungen in allen Systemen der Ausbauvariante „Automati-

sierte Fahrpreisermittlung“ ermöglicht.

Da die Einführung von EFM-Systemen wirtschaftlich darstellbar erfolgen muss, ist es erfor-

derlich, Migrationsschritte auf dem Weg zu einem Vollausbau der einzuführenden Ausbauva-

riante(n) zuzulassen. Diese müssen dem Kunden gegenüber kommunizierbar sein, da wäh-

rend der Migration eventuell geltende Einschränkungen (z.B. am Vertriebsort, Schalter oder

Automat sind nur ausgewählte Produkte als Elektronischer Fahrschein (EFS) erhältlich oder

es existiert eine eingeschränkte Interoperabilität der (((eBezahlberechtigung) erklärbar und

an jedem Ort nachvollziehbar gehalten werden müssen.

Dafür ist es erforderlich, die möglichen Migrationsschritte auf ein für Kunden und Teilnehmer

gleichermaßen praktikables Minimum zu beschränken.

Im Folgenden werden die Ausbauvarianten definiert.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 17 von 104

[Seite 162]

Anlage 27

1.1. Ausbauvariante 1: (((eBezahlen

Abbildung 1: KA-Teilnehmersicht - Ausbauvariante 1

Die (((eBezahlberechtigungen beinhalten die Möglichkeit, im (((eTicket Deutschland Leistun-

gen des ÖPV bargeldlos zu bezahlen. Sie enthalten aber auch die zur Tariffindung notwen- digen Informationen, die eine Teilnahme des Nutzers im (((eTicket Deutschland in der Aus- bauvariante 3 mit automatisierter Fahrpreisfindung ermöglichen.

Mit seiner (((eBezahlberechtigung kann der Kunde die jeweils in der Ausbauvariante angebo- tenen Leistungen in (((eTicket-Deutschland-Systemen in Anspruch nehmen. Diese werden über seine (((eBezahlberechtigung und seinen Kundenvertragspartner abgerechnet und be- zahlt.

Die Ausbauvariante 1 (bargeldlos Bezahlen mit der (((eBezahlberechtigung) muss den Ein- satz der (((eBezahlberechtigungen (Post-Paid-Konto-Berechtigung (POB), Prepaid-Autoload- Kontoberechtigung (PEB) und Werteinheitenberechtigung (WEB)) zur Bezahlung von Papier- fahrscheinen (herkömmliche Papierfahrscheine oder mit VDV-Barcode) unterstützen.

Innerhalb der Ausbauvariante 1 wird kein Migrationsschritt vorgesehen.

Der Fahrgast muss alle (((eBezahlberechtigungen zum Bezahlen benutzen und Werteinhei- ten (WE) aufladen können.

Es muss mindestens eine (((eBezahlberechtigung ausgegeben werden. Zu den ausgegebe- nen (((eBezahlberechtigungen sind die zugehörigen Serviceprozesse anzubieten.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 18 von 104

[Seite 163]

Anlage 27

Die (((eBezahlberechtigung wird vom Primär-KVP (pKVP) an den Kunden ausgegeben, der

dafür auch die Abrechnung gegenüber dem Kunden vornimmt. Die Ausgabe der Nutzerme-

dien mit Applikation und (((eBezahlberechtigung kann direkt über Postversand von einem beauftragten Massenpersonalisierer an den Kunden erfolgen.

Die Abrechnung der per (((eBezahlberechtigung gekauften Papiertickets erfolgt dann zwi- schen dem das Papier-Ticket ausgebenden KVP und dem pKVP der (((eBezahlberechti- gung.

Die Plausibilitätsprüfung aller Transaktionen der Bezahlberechtigungen wird im PV-System

des für die ausgegebene (((eBezahlberechtigung zuständigen PV ausgeführt.

Der gegenüber dem Kunden abzurechnende Betrag liegt mit Ausgabe des Tickets fest. Er ist

in der Bezahltransaktion ausgewiesen. Er ist von allen an diesem Geschäftsprozess beteilig-

ten KA-Teilnehmern auf Unversehrtheit und Authentizität prüfbar und kann nicht unterschla- gen werden. Die Abrechnung erfolgt durch den pKVP.

Für den Einsatz von (((eBezahlberechtigungen in dieser Systemausbauvariante muss keine automatisierte Fahrpreisermittlung im PV-System umgesetzt werden.

Dem Kunden muss die Möglichkeit geboten werden, seine Daten auf dem Nutzermedium an

einem KVP-Terminal auszulesen. Dabei müssen sowohl die Daten der Applikation als auch

der Berechtigung ausgelesen und angezeigt werden können. Darüber hinaus muss für den

Kunden die Möglichkeit geschaffen sein, seine gespeicherten Daten im System des pKVP

einsehen zu können. Eine onlinebasierte Auskunft ist hierfür auch umsetzbar.

Die Möglichkeit der Entladung von Werteinheiten muss mindestens an einem Verkaufstermi- nal, z.B. in einem Kundencenter, angeboten werden.

Die Ausbauvariante 1 bietet sich vorrangig als ergänzender Migrationsschritt beim Aufbau

von (((eTicket-Systemen der Ausbauvariante 2, insbesondere für den Verkauf von Tickets, die nicht oder noch nicht als EFS ausgegeben werden, an. Der alleinige Aufbau von Syste- men der Ausbauvariante 1 in einer Region wird in der Regel nicht erwartet.

In dieser Ausbauvariante können Statische Berechtigungen (s. Pkt. 2.4) ausgegeben wer- den, die analog zu den EFS in den Akzeptanzterminals und (((eTicket-Deutschland- Systemen verarbeitet werden. Die ausgegebenen Papierfahrscheine oder HandyTickets sind in diesem Fall mit einem VDV-Barcode auf Basis der Statischen Berechtigung (s. KA STB- SPEC [9]) gekennzeichnet, der die elektronische Kontrolle der Fahrscheine ermöglicht.

Die umzusetzenden Elementarprozesse und Anwendungsfälle für eingesetzte Systemkom- ponenten sind Kapitel 3 und 4, Paket Ausbauvariante 1 zu entnehmen.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 19 von 104

[Seite 164]

Anlage 27

1.2. Ausbauvariante 2 (((eFahrschein /(((eKontrolle EFS + Akzeptanz von POB/PEB+WEB

Abbildung 2: KA-Teilnehmersicht - Ausbauvariante 2

Das (((eTicket in Form eines EFS ist der Ersatz der heute als Papierfahrschein ausgegebe- nen ÖPV-Tickets.

Ausbauvariante 2 bedeutet, dass der Kunde im Vollausbau der Ausbauvariante die meisten Ticketarten als elektronischen Fahrschein (EFS) gegen (((eBezahlberechtigungen (Post- Paid-Konto-Berechtigung (POB), Prepaid-Autoload-Kontoberechtigung (PEB) und Wertein- heitenberechtigung (WEB)) bzw. auch mit gesetzlichen Zahlungsmitteln1 erwerben kann.

Die vollständige Einführung dieser Ausbauvariante ist also immer mit der Ausgabe einer (((eBezahlberechtigung (s. (((eTicket Teilnahmevertrag [3]) durch KA-Teilnehmer in der Rolle pKVP und mit der Durchführung einer (((eKontrolle durch KA-Teilnehmer in der Rolle DL verbunden. Die Ausgabe der Nutzermedien mit Applikation, (((eBezahlberechtigung und EFS2 kann direkt über Postversand von einem beauftragten Massenpersonalisierer an den Kunden erfolgen.

1 Welche gesetzlichen Zahlungsmittel an einem KVP-Terminal angeboten werden, entscheidet der KVP.

2 Sinnvoll, wenn langfristig gültige EFS an den Kunden mit ausgegeben werden sollen (wie z.B. Abo-EFS oder Jahreskarte).

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 20 von 104

[Seite 165]

Anlage 27

Die (((eKontrolle stellt sicher, dass die ausgegebenen EFS-Berechtigungen im Feld in genü- gendem Umfang erfasst und damit im Rahmen des Sicherheitskonzeptes der KA in den Hin- tergrundsystemen geprüft werden (s. KA TXx_Prüfungs-ANW).

Im Vollausbau dieser Variante muss der Kunde aus Datenschutzgründen die Möglichkeit

haben, bei seinem pKVP eine anonyme (((eBezahlberechtigung zu wählen. Das heißt, dass die alleinige Ausgabe von POB oder mit Autoload verbundener PEB oder WEB in einem re- gionalen EFM-System nicht hinreichend und damit nicht zulässig ist. Es muss immer auch

ein anonymer WEB angeboten werden. In diesem Fall wird der Kunde nur noch als „Nutzer“ bezeichnet, da seine Kundendaten dem pKVP nicht vorliegen.

Der Fahrgast muss alle (((eBezahlberechtigungen zum Bezahlen von EFS benutzen und Werteinheiten (WE) aufladen können.

Ein EFS muss vom Kunden entweder im Kundenservicecenter oder am Verkaufsterminal (KVPT personalbedient) oder am Automaten (KVPT kundenselbstbedient) erworben werden können.

Die Abrechnung der mit (((eBezahlberechtigung gekauften EFS erfolgt zwischen dem EFS ausgebenden KVP und dem pKVP der (((eBezahlberechtigung. Der pKVP verantwortet die Abrechnung gegenüber dem Kunden.

Bei der (((eBezahlberechtigung sind die Nutzungs- und finanzielle Regelung mit dem Kunden über den Vertragsabschluss beim pKVP vereinbart. Die Plausibilitätsprüfung aller Transakti-

onen der (((eBezahlberechtigung wird bei dem zuständigen PV im PV-System durchgeführt

(s. KA TXx_Prüfungs-ANW).

Der gegenüber dem Kunden über dessen pKVP abzurechnende Betrag steht mit Ausgabe des EFS fest. Er ist in der Bezahltransaktion ausgewiesen. Er ist von allen an diesem Ge- schäftsprozess beteiligten KA-Teilnehmern auf Unversehrtheit und Authentizität prüfbar und kann nicht unterschlagen werden.

Für den Einsatz von (((eBezahlberechtigungen in dieser Systemausbauvariante muss keine automatisierte Fahrpreisermittlung im PVS umgesetzt werden.

Es ist sicherzustellen, dass in einem System der Ausbauvariante 2 EFS-Berechtigungen elektronisch an Kontrollterminals (Dienstleisterterminal (DLT)) über die kontaktlose Schnitt-

stelle kontrolliert werden können. Das Kontrollergebnis wird dem Kunden optisch und akus-

tisch gemäß KA KUSCH-Spec [1] angezeigt. Die Anzeige an personalbedienten Kontrollge-

räten kann der DL eigenständig vorgeben.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 21 von 104

[Seite 166]

Anlage 27

Inwieweit über die (((eKontrolle hinaus zusätzlich eine elektronische Entwertung erforderlich

ist (die relevanten Anwendungsfälle werden als tarifliche Besonderheit zugefügt), hängt ins- besondere davon ab, ob in einer EFM-Region EFS im Vorverkauf oder elektronische Mehr- fahrtenkarten angeboten werden sollen. In dem Fall sind ausreichend viele elektronische Entwertungsmöglichkeiten vorzuhalten. Die Entscheidung zur Umsetzung der Entwertung obliegt den Teilnehmern eines EFM-Projektes.

Es müssen Quittungen beim Kauf von EFS ausgestellt werden können.

Erkennt das Terminal bei Erwerb der Fahrtberechtigung, dass bereits andere gültige Fahrt-

berechtigungen gespeichert sind, muss der für die nächste Benutzung vorgesehene EFS

gemäß Kundenfestlegung auszuwählen (priorisierbar) sein.

Es wird empfohlen, dass dem Kunden Ticket-Favoriten angeboten werden können. Dies kann entweder durch erneutes Angebot des zuletzt gespeicherten EFS (Tickets) realisiert werden oder durch den Kunden selbst angelegte häufig genutzte Fahrtrelationen im Kun- denprofil in der Applikation des Nutzermediums.

Der Kunde muss aus Datenschutzgründen die Möglichkeit haben, die Daten auf der mit dem

Nutzermedium bereitgestellten ÖPV-Applikation an geeigneten KVP-Terminals auszulesen.

Er muss außerdem die zu seiner Applikation und/oder zu seinen Berechtigungen im EFM-

System gespeicherten Kundendaten bei seinem Primär-Kundenvertragspartner, der die Ap-

plikation ausgegeben hat, einsehen und soweit zulässig auch löschen können. Das kann

auch über einen Internetzugang realisiert werden. Wird die Dateneinsicht an kundenselbst-

bedienten KVP-Terminals angeboten, ist die Datenausgabe PIN-geschützt durchzuführen.

Die Möglichkeit der Entladung von Werteinheiten muss mindestens an einem Verkaufstermi- nal, z.B. in den Kundencentern, angeboten werden.

Die Prüfung der bei der Ausgabe und der Kontrolle erzeugten Transaktionen bei allen am

jeweiligen Geschäftsprozess beteiligten Teilnehmern ist ein wichtiger Bestandteil des KA-

Sicherheitskonzeptes. Die relevanten Prüfungen sind in KA Tx_Prüfungs-ANW [2] beschrie- ben.

Ein System der Ausbauvariante 2 gilt als interoperabel, wenn EFS für ausgewählte Tarifpro- dukte gegen jede ausgegebene interoperable (((eBezahlberechtigungen in die Applikation auf dem Nutzermedium ausgegeben werden können.

Kombinierte KVP-/DL-Terminals, die sowohl für die (((eKontrolle als auch für den Verkauf

von (((eFahrscheinen eingesetzt werden (z. B. personalbediente MDE-Geräte im SPNV oder

Elektronische Fahrscheindrucker in den Bussen), müssen die entsprechenden Anwendungs-

fälle der betreffenden Ausbauvariante beider Referenzterminaltypen umsetzen.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 22 von 104

[Seite 167]

Anlage 27

Die für den Vollausbau umzusetzenden Elementarprozesse und Anwendungsfälle für einge- setzte Systemkomponenten sind Kapitel 3 und 4, Paket Ausbauvariante 2 zu entnehmen.

1.3. Ausbauvariante 2a (((eFahrschein Abo / (((eKontrolle EFS

Abbildung 3: KA-Teilnehmersicht - Ausbauvariante 2a

Die gewählte und vorstehend beschriebene Ausbauvariante „(((eFahrschein Abo / (((eKon-

trolle EFS“ wird nur im Hinblick auf „Produkte für Stammkunden“ (z.B. elektronische Abon-

nement-Zeitfahrausweise (Abo-EFS) und ggf. Verkauf von Jahreskarten) ausgeführt. Damit reduziert sich insbesondere der Aufwand zur Umsetzung von Verkaufsinfrastruktur bei den KVP. Es besteht demnach keine zwingende Forderung, Infrastruktur in Form von mobilen personalbedienten KVP-Terminals bzw. kundenselbstbedienten stationären oder kunden- selbstbedienten mobilen KVP-Terminals ins Feld zu bringen.

Insofern gelten für die Ausbauvariante 2a grundsätzlich die Vorgaben zur Ausbauvariante 2 wie vorstehend in Kapitel 1.2 beschrieben, sofern nicht nachstehend etwas Abweichendes definiert wird.

Die Ausgabe der Nutzermedien mit Applikation und EFS-Berechtigung kann z. B. direkt über Postversand von einem beauftragten Massenpersonalisierer an den Kunden erfolgen.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 23 von 104

[Seite 168]

Anlage 27

Darüber hinaus wird empfohlen dass dies auch in mindestens einer Verkaufs- oder Service-

stelle im Tarifgebiet an KVP-Terminals möglich ist. Es empfiehlt sich diese auch für Service- funktionen zu nutzen.

Es wird empfohlen, alle in dieser Ausbaustufe ausgegebenen (((eTickets mit konkretem Gül-

tigkeitsbeginn auszugeben, so dass sie ohne zusätzliche elektronische Entwertung gültig

sind. Dabei kann der im EFS eingetragene Gültigkeitsbeginn vor dem Ausgabezeitpunkt und

auch nach dem Ausgabezeitpunkt liegen. Damit ist der Anwendungsfall „EFS entwerten“ entbehrlich.

Eine Ausgabe, Rücknahme bzw. Entsperrung des (((eFahrschein über Aktionslisten kann

vereinbart werden. In diesem Falle gelten die Aussagen zum Aktionsmanagement gemäß Kapitel 2.2.

Der Kunde muss aus Datenschutzgründen die Möglichkeit haben, die Daten auf der mit dem

Nutzermedium bereitgestellten ÖPV-Applikation an geeigneten KVP-Terminals auszulesen.

Er muss außerdem die zu seiner Applikation und/oder zu seinen Berechtigungen im EFM-

System gespeicherten Kundendaten bei seinem Primär-Kundenvertragspartner, der die Ap-

plikation ausgegeben hat, einsehen und soweit zulässig auch löschen können. Wird die Da- teneinsicht an kundenselbstbedienten KVP-Terminals angeboten, ist die Datenausgabe PIN- geschützt durchzuführen. Das kann auch über einen Internetzugang realisiert werden. Die (((eKontrolle der (((eTickets beim Vordereinstieg in Busse wird in dieser Migrationsstufe empfohlen, weil nur eine häufige Kontrolle der EFS die Vorteile der höheren Sicherheit (z. B.

der Sperrmöglichkeiten) von (((eTickets zum Tragen bringt.

Die Ausgabe einer (((eBezahlberechtigung durch einen KVP für einen Einsatz des NM in

einem EFM-System einer anderen Ausbauvariante ist zulässig.

Die umzusetzenden Elementarprozesse und Anwendungsfälle für eingesetzte Systemkom- ponenten sind Kapitel 3 und 4, Paket Ausbauvariante 2a zu entnehmen.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 24 von 104

[Seite 169]

Anlage 27

1.4. Ausbauvariante 2b-1 - (((eFahrschein / (((eKontrolle EFS + Akzeptanz POB/PEB

Abbildung 4: KA-Teilnehmersicht - Ausbauvariante 2b-1

Die gewählte Ausbauvariante „(((eFahrschein / (((eKontrolle EFS + Akzeptanz POB/PEB“

wird zunächst nur für ausgewählte Tarifprodukte, die als EFS ausgegeben werden, ausge-

führt. Weitere Tarife werden als Papierfahrschein (mit oder ohne VDV-Barcode) ausgege-

ben. POB/PEB müssen in diese Ausbauvariante nicht interoperabel akzeptierte (((eBezahl- berechtigungen sein.

Für die Ausbauvariante 2b-1 gelten grundsätzlich die Vorgaben zur Ausbauvariante 2 wie vorstehend in Kapitel 1.2 beschrieben, sofern nicht nachstehend etwas Abweichendes defi- niert wird.

Es besteht die Verpflichtung, jedem Kunden, der ein KA-Nutzermedium erhält, auf diesem eine (((eBezahlberechtigung als POB oder PEB auszugeben, die er zum Erwerb von elektro- nischen Fahrscheinen einsetzen kann. Diese (((eBezahlberechtigungen können noch regio-

nal begrenzt akzeptiert werden und müssen nicht in Systemen der Ausbauvariante 3 (Voll- ausbau) mit automatisierter Fahrpreisermittlung akzeptiert werden.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 25 von 104

[Seite 170]

Anlage 27

Die Ausgabe der Nutzermedien mit Applikation und (((eBezahlberechtigung kann z. B. direkt über Postversand von einem beauftragten Massenpersonalisierer an den Kunden erfolgen.

Die Ausgabe von EFS muss an hinreichend vielen Verkaufsgeräten möglich sein.

Eine Ausgabe, Rücknahme bzw. Entsperrung von EFS über Aktionslisten kann vereinbart

werden. In diesem Falle gelten die Aussagen zum Aktionsmanagement gemäß Kapitel 2.2.

Der Kunde muss aus Datenschutzgründen die Möglichkeit haben, die Daten auf der mit dem

Nutzermedium bereitgestellten ÖPV-Applikation an geeigneten KVP-Terminals auszulesen.

Er muss außerdem die zu seiner Applikation und/oder zu seinen Berechtigungen im EFM-

System gespeicherten Kundendaten bei seinem Primär-Kundenvertragspartner, der die Ap-

plikation ausgegeben hat, einsehen und soweit zulässig auch löschen können. Wird die Da- teneinsicht an kundenselbstbedienten KVP-Terminals angeboten, ist die Datenausgabe PIN- geschützt durchzuführen. Das kann auch über einen Internetzugang realisiert werden.

Die umzusetzenden Elementarprozesse und Anwendungsfälle für eingesetzte Systemkom- ponenten sind Kapitel 3 und 4, Paket Ausbauvariante 2b-1 zu entnehmen.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 26 von 104

[Seite 171]

Anlage 27

1.5. Ausbauvariante 2b-2 - (((eFahrschein / (((eKontrolle EFS + Akzeptanz WEB

Abbildung 5: KA-Teilnehmersicht - Ausbauvariante 2b-2

Die gewählte Ausbauvariante „(((eFahrschein / (((eKontrolle“ wird zunächst nur für ausge-

wählte Tarifprodukte, die als EFS ausgegeben werden, ausgeführt. Weitere Tarife werden

als Papierfahrschein (mit oder ohne VDV-Barcode) ausgegeben WEB müssen in diese Aus- bauvariante nicht interoperabel akzeptierte (((eBezahlberechtigungen sein.

Für die Ausbauvariante 2b-1 gelten grundsätzlich die Vorgaben zur Ausbauvariante 2 wie vorstehend in Kapitel 1.2 beschrieben, sofern nicht nachstehend etwas Abweichendes defi- niert wird.

Es besteht die Verpflichtung, jedem Kunden, der ein KA-Nutzermedium erhält, auf diesem eine (((eBezahlberechtigung als WEB auszugeben, die er zum Erwerb von elektronischen Fahrscheinen einsetzen kann. Die WEB kann mit einer Autoloadfunktion ausgegeben wer- den, wenn der pKVP ein entsprechendes Angebot bereitstellt. Die (((eBezahlberechtigungen können noch regional begrenzt akzeptiert werden und müssen nicht in Systemen der Aus- bauvariante 3 (Vollausbau) mit automatisierter Fahrpreisermittlung akzeptiert werden.

Die Ausgabe der Nutzermedien mit Applikation und (((eBezahlberechtigung kann z. B. direkt über Postversand von einem beauftragten Massenpersonalisierer an den Kunden erfolgen.

Die Ausgabe von EFS muss an hinreichend vielen Verkaufsgeräten möglich sein.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 27 von 104

[Seite 172]

Anlage 27

Der Kunde, der eine anonyme (((eBezahlberechtigung benutzt (Werteinheitenberechtigung ohne Autoload-Funktion), muss hinreichende Möglichkeiten erhalten, Werteinheiten im Ein- satzgebiet nachzuladen. Dies soll mindestens in Verkaufs- oder Servicestellen im Tarifgebiet an dort eigesetzten KVPT möglich sein. Das Laden von Werteinheiten an kundenselbstbe- dienten KVP-Terminals (z.B. Automaten) ist freigestellt.

Eine Ausgabe, Rücknahme bzw. Entsperrung von EFS über Aktionslisten kann vereinbart

werden. In diesem Falle gelten die Aussagen zum Aktionsmanagement gemäß Kapitel 2.2.

Der Kunde muss aus Datenschutzgründen die Möglichkeit haben, die Daten auf der mit dem

Nutzermedium bereitgestellten ÖPV-Applikation an geeigneten KVP-Terminals auszulesen.

Er muss außerdem die zu seiner Applikation und/oder zu seinen Berechtigungen im EFM-

System gespeicherten Kundendaten bei seinem Primär-Kundenvertragspartner, der die Ap-

plikation ausgegeben hat einsehen und soweit zulässig auch löschen können. Wird die Da- teneinsicht an kundenselbstbedienten KVP-Terminals angeboten, ist die Datenausgabe PIN- geschützt durchzuführen. Das kann auch über einen Internetzugang realisiert werden.

Die umzusetzenden Elementarprozesse und Anwendungsfälle für eingesetzte Systemkom- ponenten sind Kapitel 3 und 4, Paket Ausbauvariante 2b-2 zu entnehmen.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 28 von 104

[Seite 173]

Anlage 27

1.6. Ausbauvariante 3 Automatisierte Fahrpreisermittlung

Abbildung 6: KA-Teilnehmersicht - Ausbauvariante 3

IN-OUT-Systeme mit automatisierter Fahrpreisermittlung stellen insbesondere für ausge-

wählte Kundenzielgruppen (vor allem Selten- und Gelegenheitsnutzer; auch Stammkunden

sind außerhalb ihres ständig genutzten Tarifbereiches Gelegenheitsnutzer) einen hohen Komfort dar, da sie vom Nutzer keine Tarifkenntnisse erfordern und ihm damit den Zugang zum ÖPV erleichtern.

Für die Kunden bedeutet dies, sich bei Fahrtantritt im System anzumelden und bei Fahrten- de im System abzumelden (Check-In bzw. Check-Out; Ausbauvariante 3a) oder dass sein Medium während der Fahrt automatisch erfasst wird (Be-In/Be-Out; Ausbauvariante 3b), ohne dass eine aktive Handlung vom Kunden verlangt wird.

Da derzeit noch keine Be-In/Be-Out-Systeme im Einsatz sind, erfolgt die Beschreibung des Funktionsumfanges der Ausbauvariante 3 einschließlich eines Migrationsszenarios im Weite-

ren ausschließlich für Check-In-/Check-Out-Systeme (CICO), obwohl es keine grundsätzli-

chen Unterschiede hinsichtlich der auszuführenden Elementarprozesse und Anwendungsfäl- le gibt.

Für die Einführung der Ausbauvariante „Automatisierte Fahrpreisermittlung" ist immer die Ausgabe einer (((eBezahlberechtigung an die Kunden notwendig. Sie ist in dieser Systemva- riante gleichzeitig Grundlage für die Fahrberechtigung, die verbunden mit der Durchführung

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 29 von 104

[Seite 174]

Anlage 27

von Check-in und Check-Out beim Zugang/Einstieg zum bzw. Abgang/Ausstieg vom Ver- kehrsmittel, das zur Leistungsinanspruchnahme benutzt wurde, realisiert wird. Die Ausgabe der Nutzermedien mit Applikation und (((eBezahlberechtigung kann direkt über Postversand von einem beauftragten Massenpersonalisierer an den Kunden erfolgen.

Im Vollausbau muss der Kunde aus Datenschutzgründen die Möglichkeit haben, eine ano-

nyme (((eBezahlberechtigung zu wählen. Das heißt, dass die alleinige Ausgabe von POB oder mit Autoload verbundener PEB und WEB durch im Gesamtsystem integrierte pKVP nicht hinreichend und damit nicht zulässig ist.

Da im Vollausbau der Systemvariante 3 auch anonyme Werteinheitenberechtigungen akzep- tiert werden müssen, ist es verpflichtend, dass alle Terminals beim Check-Out ontrip Fahr-

preise berechnen können. In Regionen, wo parallel EFS in Form von EFS-Berechtigungen an Kunden verkauft und bei den DL akzeptiert werden, ist die Anrechnung von EFS zu ge- währleisten (die relevanten Anwendungsfälle werden als tarifliche Besonderheit zugefügt).

Der Fahrgast muss alle (((eBezahlberechtigungen per Check-In als Fahrtberechtigung be- nutzen und Werteinheiten (WE) aufladen können.

Die Plausibilitätsprüfung aller Transaktionen der (((eBezahlberechtigungen wird im PV-

System des für die ausgegebene (((eBezahlberechtigung zuständigen PV ausgeführt, der

dafür Nutzungs- und finanzielle Regelungen vereinbart hat (s. KA TXx_Prüfungs-ANW).

In dieser Ausbauvariante kommt dem Clearing aller Transaktionen einer Berechtigung im PV-System eine entscheidende Rolle zu. Das PV-System muss auf Grund der eintreffenden Transaktionen die Leistungsabrechnungen ausführen und das Forderungsmanagement für

die am EFM-Produkt beteiligten KVP und DL mit Daten versorgen können. Dieses bildet die

Grundlage für den Einnahmen-Finanzausgleich zwischen den beteiligten KA-Teilnehmern.

Der gegenüber dem Kunden über dessen pKVP abzurechnende Betrag für eine Fahrt oder

Fahrtenkette liegt entweder beim fahrtbeendenden Ausstieg fest (zwingend für die WEB- Nutzung) oder wird nach der Fahrt auf Grundlage der eintreffenden Fahrttransaktionen nach vorgegebenen Regeln im PV-System ermittelt. Er ist in den vom PV an den pKVP übermittel- ten Transaktionen auszuweisen.

Die zur Leistungsermittlung empfangenen Transaktionen sind von allen am Geschäftspro-

zess beteiligten KA-Teilnehmern auf Unversehrtheit und Authentizität prüfbar und können nicht unterschlagen werden.

Für den Einsatz von (((eBezahlberechtigungen in dieser Systemausbauvariante ist die auto- matisierte Fahrpreisermittlung im PVS umgesetzt. Die DL-Terminals erhalten die entspre- chenden Berechnungsvorgaben zur automatisierten Fahrpreisermittlung aus dem PV- System.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 30 von 104

[Seite 175]

Anlage 27

Bei Einführung eines CICO-Systems muss gewährleistet werden, dass am CICO-Terminal

über den An- und Abmeldevorgang hinaus keine zusätzlichen Bedienhandlungen für den Nutzer erforderlich sind, damit der Durchsatz (Fahrgaststrom) nicht verlangsamt wird.

Beim Einsatz in Ballungsgebieten mit hohem Fahrgastaufkommen ist sicherzustellen, dass die Abfertigung durch eine hinreichend große Anzahl von CICO-Terminals (ggf. auch als

stationäre Terminals auf den Bahnsteigen) gewährleistet wird.

Für den Nutzer muss eindeutig erkennbar sein, an welcher Stelle, welche Handlung durchzu-

führen ist (im Fahrzeug/an der Haltestelle/beides), um Fehlverhalten zu vermeiden.

Ist die Mitnahme von tarifrelevanten Gegenständen oder eine Klassenänderung in den Tarif- bestimmungen des Systems mit Automatisierter Fahrpreisermittlung vorgesehen, muss die Einstellung der Mitnahme an geeigneten KVP-Terminals an jedem Systemzugang möglich sein.

Mitnahme und/oder Klassenänderung kann auch an mit Teilfunktionalitäten eines KVPT aus-

gestatteten Nutzermedien (z. B. über eine App auf einem mobilen Endgerät mit Kontaktlos- schnittstelle) einstellbar sein.

Die Nutzungsregeln für Berechtigungen in CICO-Systemen, einschließlich der Regelung ei-

nes Verfahrens zum „Vergessenen CO“ müssen dem Nutzer eindeutig mitgeteilt werden.

Eine (((eBezahlberechtigung (POB oder PEB-Autoload bzw. WEB) wird durch die Erfassung des Fahrtantritts am CICO-Terminal validiert und für die aktuelle Fahrt gültig gemacht. Der

dabei erzeugte Transaktionsdatensatz stellt die für die Kontrolle relevante Fahrtberechtigung

dar und wird bei dieser geprüft. Die An- und Abmeldung und deren Ergebnis muss dem Kun- den angezeigt werden.

Im Fall, dass für das NM ein Sperrvermerk vorliegt oder das Guthaben nicht mehr ausrei-

chend ist, muss der Nutzer gemäß KA KUSCH-SPEC [1] informiert werden.

Ein fehlender Check-Out wird dem Kunden angezeigt. Im Falle eines fehlenden Check-Out müssen in den AGB des Dienstleiters geeignete Reglungen zur Ermittlung des Fahrpreises einer nicht mit Check-Out abgeschlossenen Fahrt vorhanden sein.

Der Kunde muss aus Datenschutzgründen die Möglichkeit haben, die Daten auf der mit dem

Nutzermedium bereitgestellten ÖPV-Applikation an geeigneten KVP-Terminals auszulesen.

Er muss außerdem alle zu seiner Applikation und/oder zu seinen Berechtigungen im EFM-

System gespeicherten Kundendaten bei seinem Primär-Kundenvertragspartner, der die Ap-

plikation ausgegeben hat, einsehen und soweit zulässig auch löschen können. Das kann

auch über einen Internetzugang realisiert werden. Wird die Dateneinsicht an kundenselbst-

bedienten KVP-Terminals angeboten, ist die Datenausgabe PIN-geschützt durchzuführen.

Die Möglichkeit der Entladung von Werteinheiten muss mindestens an Verkaufsterminals, z.B. in Kundencentern, angeboten werden.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 31 von 104

[Seite 176]

Anlage 27

Ein EFM-System der Ausbauvariante 3 (CICO) ist KA-konform, wenn Nutzer mit KA-Medien aus oder in anderen EFM-Systemen:

• ihre (((eBezahlberechtigung mittels CICO für die Inanspruchnahme der gewünschten

ÖPV-Leistung einsetzen können,

oder

• im Voraus erworbene EFS für gewünschte ÖPV-Leistungen nutzen können, wenn

dies in den Beförderungsbedingungen vereinbart ist

sowie

• ihre (((eBezahlberechtigungen grundsätzlich zum Bezahlen benutzen und Wertein-

heiten aufladen können.

Kombinierte KVP-/DL-Terminals, die sowohl für die Erfassung von Fahrtberechtigungen als

auch für Verkaufsfunktionen eingesetzt werden (z. B. Elektronische Fahrscheindrucker in

den Bussen), müssen die entsprechenden Anwendungsfälle der betreffenden Ausbauvarian- te beider Referenzterminaltypen umsetzen.

Die für den Vollausbau umzusetzenden Elementarprozesse und Anwendungsfälle für einge- setzte Systemkomponenten sind Kapitel 3 und 4, Paket Ausbauvariante 3 zu entnehmen.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 32 von 104

[Seite 177]

Anlage 27

1.7. Ausbauvariante 3a-1 - Check-In/Check-Out räumlich begrenzt mit POB/PEB

Abbildung 7: KA-Teilnehmersicht - Ausbauvariante 3a-1

Die gewählte Ausbauvariante „Check-In/Check-Out räumlich begrenzt mit POB/PEB“ wird für

ausgewählte Kundengruppen bzw. Tarifprodukte eingeführt. Alle weiteren Tarifprodukte wer- den als Papierfahrschein (mit oder ohne VDV-Barcode) oder ggf. als elektronischer Fahr- schein (EFS) ausgegeben.

Insofern gelten für die Ausbauvariante 3a-1 grundsätzlich die Vorgaben zur Ausbauvariante 3 wie vorstehend in Kapitel 1.6 beschrieben, sofern nicht nachstehend etwas Abweichendes definiert wird.

Die ausgegebenen (((eBezahlberechtigungen beschränken sich auf kontogebundene und

personalisierte Berechtigungen (POB/PEB-Autoload), für die die Fahrpreisermittlung im Postpricing-Verfahren, also im Hintergrundsystem des produktausgebenden PV erfolgt. Der Ausgleich der (((eBezahlberechtigungen wird über ein kreditwirtschaftliches Konto des Kun-

den abgewickelt. Dabei können sowohl Prepaid-Autoload als auch Postpaid-Zahlungen mit dem Kunden vereinbart werden.

Es wird zugelassen, dass in den Akzeptanzgebieten für die automatisierte Fahrpreisfindung nur die (((eBezahlberechtigungen (POB oder PEB-Autoload ) durch die DL akzeptiert wer-

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 33 von 104

[Seite 178]

Anlage 27

den, für die der PV die automatisierte Fahrpreisermittlung durchführen kann. Das heißt, es

werden nur (((eBezahlberechtigungen akzeptiert, für die ein entsprechendes Preisberech- nungsmodul im Akzeptanzgebiet verfügbar ist. Das Preisberechnungsmodul3 müssen die Tarifverantwortlichen der Akzeptanzgebiete dem PV, der das zur (((eBezahlberechtigung gehörende EFM-Produkt zur Verfügung stellt, zur Nutzung überlassen.

Die Preisberechnung kann auch vorverarbeitet in einem „Konvertersystem“ im Akzeptanzge- biet unter Regie des dort Tarifverantwortlichen bzw. eines in der Region arbeitenden PV er- folgen. Der „regionale PV“ stellt dann dem die (((eBezahlberechtigung verantwortenden PV

bereits bepreiste Leistungsdatensätze gemäß gegenseitiger Vereinbarung zur Verfügung.

Es besteht die Verpflichtung, jedem Kunden, der ein KA-Nutzermedium erhält, eine (((eBe- zahlberechtigung (in diesem Falle POB oder PEB-Autoload) auszugeben, die er in anderen Systemvarianten zum Erwerb von EFS oder auch von Papierfahrscheinen einsetzen kann, sofern der pKVP dies zulässt. Wenn von dem zuständigen PV zugelassen, kann er damit

außerdem in anderen ausgewählten Systemen der Ausbauvariante 3a-1 mit automatisierter

Fahrpreisermittlung (Preisberechnung beim produktausgebenden PV ist möglich) Leistungen in Anspruch nehmen.

Für die Ausgabe der Nutzermedien mit Applikation und (((eBezahlberechtigung müssen noch

keine KVP-Terminals im Kundenzugang bereit gestellt werden, sie kann hier ausschließlich

über Postversand von einem beauftragten Massenpersonalisierer an den Kunden erfolgen.

Der Kunde muss aus Datenschutzgründen die Möglichkeit haben, die Daten auf der mit dem

Nutzermedium bereitgestellten ÖPV-Applikation an geeigneten KVP-Terminals auszulesen.

Er muss außerdem die zu seiner Applikation und/oder zu seinen Berechtigungen im EFM- System gespeicherten Kundendaten bei seinem pKVP, der die Applikation ausgegeben hat, einsehen und soweit zulässig auch löschen können. Wird die Dateneinsicht an kunden-

selbstbedienten KVP-Terminals angeboten, ist die Datenausgabe PIN-geschützt durchzufüh-

ren. Das kann auch über einen Internetzugang realisiert werden.

Es besteht in dieser Ausbauvariante keine zwingende Forderung, Infrastruktur in Form von kundenselbstbedienten KVP-Terminals ins Feld zu bringen. Eine ins Feld gebrachte Infra- struktur an kundenselbstbedienten KVP-Terminals muss noch nicht dem Vollausbau ent- sprechen.

Die Möglichkeit des Check-In und Check-Out muss bei jedem Einstieg in und beim Ausstieg

aus Bussen sowie beim Zugang und Abgang an Haltestellen des SPNV uneingeschränkt

3 Dies kann auch in Form von Preisberechnungsregeln zur Verfügung gestellt werden, die der PV in seinem PV-System anwendet, um im Akzeptanzgebiet auf Grundlage der dort erzeugten Fahrttransaktionen die Fahr- preise zu berechnen.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 34 von 104

[Seite 179]

Anlage 27

möglich sein. Der Kunde muss durch eine ausreichende Terminalausstattung in die Lage

versetzt werden, jede mit Check-In begonnene Fahrt beim Ausstieg aus dem für die Fahrt

benutzen Verkehrsmittel auch mit einem Check-Out beenden zu können.

Anderenfalls ist der Kunde bereits beim Einstieg ausdrücklich darauf hinzuweisen, dass er sich mit einen Fahrschein im Vorverkauf (EFS oder Papier) versorgen muss.

Eine Anrechnung von Fahrscheinen (EFS) auf Fahrten mit automatisierter Fahrpreisermitt- lung muss nicht unterstützt werden.

Die für den Vollausbau umzusetzenden Elementarprozesse und Anwendungsfälle für einge- setzte Systemkomponenten sind Kapitel 3 und 4, Paket Ausbauvariante 3 zu entnehmen.

1.8. Ausbauvariante 3a-2 - Check-In/Check-Out räumlich begrenzt mit WEB

Abbildung 8: KA-Teilnehmersicht - Ausbauvariante 3a-2

Die gewählte Ausbauvariante „Check-In/Check-Out räumlich begrenzt mit WEB“ wird für

ausgewählte Kundengruppen bzw. Tarifprodukte eingeführt. Alle weiteren Tarifprodukte wer- den als Papierfahrschein (mit oder ohne VDV-Barcode) oder ggf. als elektronischer Fahr- schein (EFS) ausgegeben.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 35 von 104

[Seite 180]

Anlage 27

Insofern gelten für die Ausbauvariante 3a-2 grundsätzlich die Vorgaben zur Ausbau-

variante 3 wie vorstehend in Kapitel 1.6 beschrieben, sofern nicht nachstehend etwas Ab- weichendes definiert wird.

Es wird zugelassen, dass in den Akzeptanzgebieten für die automatisierte Fahrpreisfindung

nur die (((eBezahlberechtigungen (WEB) durch die DL akzeptiert werden, für die der PV die

automatisierte Fahrpreisermittlung durchführen kann. Das heißt, es werden nur (((eBezahl-

berechtigungen akzeptiert, für die ein entsprechendes Preisberechnungsmodul im Akzep- tanzgebiet verfügbar ist. Das Preisberechnungsmodul4 müssen die Tarifverantwortlichen der

Akzeptanzgebiete dem PV, der das zur (((eBezahlberechtigung gehörende EFM-Produkt zur

Verfügung stellt, zur Nutzung überlassen.

Die Preisberechnung kann auch vorverarbeitet in einem „Konvertersystem“ im Akzeptanzge- biet unter Regie des dort Tarifverantwortlichen bzw. eines in der Region arbeitenden PV er- folgen. Der „regionale PV“ stellt dann dem die (((eBezahlberechtigung verantwortenden PV

bereits bepreiste Leistungsdatensätze gemäß gegenseitiger Vereinbarung zur Verfügung.

Es besteht die Verpflichtung, jedem Kunden, der ein KA-Nutzermedium erhält, eine (((eBe- zahlberechtigung (in diesem Falle WEB) auszugeben, die er in anderen Systemvarianten zum Erwerb von EFS oder auch von Papierfahrscheinen einsetzen kann, sofern der pKVP dies zulässt. Wenn von dem zuständigen PV zugelassen, kann er damit außerdem in ande-

ren ausgewählten Systemen der Ausbauvariante 3a mit automatisierter Fahrpreisermittlung

(Preisberechnung beim produktausgebenden PV ist möglich) Leistungen in Anspruch neh- men.

Für die Ausgabe der Nutzermedien mit Applikation und (((eBezahlberechtigung müssen noch

keine KVP-Terminals im Kundenzugang bereit gestellt werden, sie kann hier ausschließlich

über Postversand von einem beauftragten Massenpersonalisierer an den Kunden erfolgen.

Der Kunde muss aus Datenschutzgründen die Möglichkeit haben, die Daten auf der mit dem

Nutzermedium bereitgestellten ÖPV-Applikation an geeigneten KVP-Terminals auszulesen.

Er muss außerdem die zu seiner Applikation und/oder zu seinen Berechtigungen im EFM- System gespeicherten Kundendaten bei seinem pKVP, der die Applikation ausgegeben hat, einsehen und soweit zulässig auch löschen können. Wird die Dateneinsicht an kunden-

selbstbedienten KVP-Terminals angeboten, ist die Datenausgabe PIN-geschützt durchzufüh-

ren. Das kann auch über einen Internetzugang realisiert werden.

4 Dies kann auch in Form von Preisberechnungsregeln zur Verfügung gestellt werden, die der PV in seinem PV-System anwendet, um im Akzeptanzgebiet auf Grundlage der dort erzeugten Fahrttransaktionen die Fahr- preise zu berechnen.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 36 von 104

[Seite 181]

Anlage 27

Es besteht in dieser Ausbauvariante keine zwingende Forderung, Infrastruktur in Form von kundenselbstbedienten KVP-Terminals ins Feld zu bringen. Eine ins Feld gebrachte Infra- struktur an kundenselbstbedienten KVP-Terminals muss noch nicht dem Vollausbau ent- sprechen.

Die Möglichkeit des Check-In und Check-Out muss bei jedem Einstieg in und beim Ausstieg

aus Bussen sowie beim Zugang und Abgang an Haltestellen des SPNV uneingeschränkt

möglich sein. Der Kunde muss durch eine ausreichende Terminalausstattung in die Lage

versetzt werden, jede mit Check-In begonnene Fahrt beim Ausstieg aus dem für die Fahrt

benutzen Verkehrsmittel auch mit einem Check-Out beenden zu können.

Anderenfalls ist der Kunde bereits beim Einstieg ausdrücklich darauf hinzuweisen, dass er sich mit einen Fahrschein im Vorverkauf (EFS oder Papier) versorgen muss.

Eine Anrechnung von Fahrscheinen (EFS) auf Fahrten mit automatisierter Fahrpreisermitt- lung muss nicht unterstützt werden.

Die für den Vollausbau umzusetzenden Elementarprozesse und Anwendungsfälle für einge- setzte Systemkomponenten sind Kapitel 3 und 4, Paket Ausbauvariante 3 zu entnehmen.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 37 von 104

[Seite 182]

Anlage 27

2. Optionale Ergänzungen

2.1. Multiberechtigung

EFS können in den Ausbauvarianten 2, 2a, 2b-1 und 2b-2 zur Beschleunigung des Ausga- beprozesses als MultiBerechtigung (MultiBER) ausgegeben werden. Diese werden in Ver- bindung mit den vorab in einem Schlüsselregister gespeicherten Schlüsseln ausgegeben.

Damit entfällt für die Ausgabe der Multiberechtigung die asymmetrische Authentisierung. Die

als Multiberechtigung ausgegebenen EFS können auch ohne vorheriges Löschen sofort

überschrieben werden, wenn die dafür festgelegten Kriterien erfüllt sind.

Die Nutzung von Multiberechtigungen muss im jeweiligen EFM-Projekt zwischen den Teil- nehmern vereinbart werden. In diesem Falle gilt KA MultBER-SPEC [8]. Eine bundesweite interoperable Umsetzung der Multiberechtigungen wird nicht gefordert.

2.2. Aktionsmanagement

Eine Ausgabe, Rücknahme bzw. Entsperrung von EFS kann in den Ausbauvarianten 2, 2a,

2b-1 und 2b-2 über Aktionslisten vereinbart werden. Das dazu erforderliche Aktionsma- nagement (AktM) muss im jeweiligen EFM-Projekt zwischen den Teilnehmern vereinbart werden. In diesem Falle gilt KA AktM-SPEC [7]. Eine bundesweite interoperable Umsetzung des Aktionsmanagements wird nicht gefordert.

2.3. Produkt- und Kontrollmodule

Produkt- und Kontrollmodule (PKM) beinhalten standardisierte Datenstrukturen, die der ein- heitlichen technischen Abbildung von Tarifprodukten einschließlich ihrer tariflichen Verarbei-

tung dienen. Sie tragen dazu bei, dass Tarife standardisiert in die Terminals übertragen wer- den.

Die so abgelegten Tarifdaten sind durch die Gerätesoftware eines Verkaufs- bzw. Kontroll- terminals verarbeitbar und somit zur Erzeugung von Fahrberechtigungen sowie zur Kontrolle von Fahrberechtigungen nutzbar.

Die Anwendung von PKM muss im jeweiligen EFM-Projekt zwischen den Teilnehmern ver- einbart werden. In diesem Falle gilt KA PKM-Tech-SPEC [10].

Sollte im jeweiligen EFM-Projekt die Entscheidung fallen, dass keine Produkt- und Kontroll- module nach VDV-KA eingesetzt werden, so müssen in diesem EFM-Projekt die notwendi-

gen Informationen zu Produkten und Kontrollen als eine eigene proprietäre Lösung bereitge- stellt werden.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 38 von 104

[Seite 183]

Anlage 27

2.4. Statische Berechtigung

In (((eTicket-Deutschland-Systemen können Berechtigungen als Statische Berechtigungen (STB) ausgegeben werden, die analog zu EFS in den (((eTicket-Deutschland- Hintergrundsystemen verarbeitet werden. Der Begriff Statische Berechtigung drückt aus,

dass die Berechtigung nach ihrer Ausgabe nicht mehr verändert werden kann.

Statische Berechtigungen können insbesondere mit dem VDV-Barcode auf Papier (Normal-

papier oder Fahrscheinpapier) oder als HandyTickets auf mobilen Endgeräten abgebildet werden. Statische Berechtigungen unterscheiden sich von EFS dadurch, dass zur Integri- tätssicherung eine digitale Signatur (RSA) verwendet wird, statt der Bildung von MAC bei EFS.

Die STB kann in zwei Varianten realisiert werden:

• Variante 1: nicht sperrbar / nicht stornierbar
• Variante 2: sperrbar / stornierbar

STB können ergänzend zu jeder Ausbauvariante des (((eTicket Deutschland für die dafür

relevanten Tarifprodukte bzw. Vertriebskanäle angeboten werden Die STB schließt damit die

Lücke zwischen konventionellen Papierfahrscheinen und EFS. Eine Ausgabe von Statischen

Berechtigungen in Verbindung mit der Belastung von (((eBezahlberechtigungen ist möglich.

Im Bereich des Handy- und/oder Online-Tickets kann die statische Berechtigung als „autar-

ke" Lösung ohne Umsetzung einer Ausbauvariante angewendet werden.

Die Anwendung der STB muss im jeweiligen EFM-Projekt zwischen den Teilnehmern ver- einbart werden. In diesem Falle gilt KA STB-SPEC [9].

2.5. Tarifliche Besonderheiten

Sollten im Tarif eines EFM-Projektes die folgend aufgeführten tariflichen Besonderheiten

vorgesehen sein, sind die dafür relevanten Pakete mit ihren Anwendungsfällen umzusetzen:

• Entwertung EFS
• Postprice-EFS
• Anrechnung EFS

Die Umsetzung dieser tariflichen Besonderheiten sind im Rahmen des jeweiligen EFM- Projektes abzustimmen und zu verantworten.

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 39 von 104

[Seite 184]

Anlage 27

3. Pakete

Um für die Ausbauvarianten den Funktionsumfang in Form der notwendigen Anwendungsfäl-

le einfach und übersichtlich durch den (((eTicket Deutschland Teilnehmer auswählen zu

können, werden diese in funktionsorientierten Paketen wie folgt zusammengefasst.

3.1. Basispaket

Das Basispaket umfasst alle Anwendungsfälle, die die Grundlage für den Aufbau eines EFM- Systems nach (((eTicket Deutschland darstellen (vgl. Tabelle 1: Ausbauvarianten und Pake- te). Die im Basispaket enthaltenen Anwendungsfälle sind gemäß Vorgabe in jeder KA- Systemkomponente zu realisieren.

Ohne die Realisierung des Basispaketes kann keine Ausbauvariante umgesetzt werden.

3.2. Pakete für Ausbauvarianten

Gemäß 3.1 enthalten alle Ausbauvarianten immer das Basispaket (vgl. Tabelle 1: Ausbauva-

rianten und Pakete). Für die jeweils zu realisierende Ausbauvariante sind zusätzliche Pakete

mit den dafür erforderlichen Anwendungsfällen nötig. Die Ausbauvarianten setzen sich aus folgenden Paketen zusammen:

Tabelle 1: Ausbauvarianten und Pakete

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 40 von 104

[Seite 185]

Anlage 27

3.3. Pakete für optionale Ergänzungen

Die folgende Tabelle gib an, welche optionalen Ergänzungen in welchen Ausbauvarianten

verwendet werden können. Die Paketnamen entsprechen hier den Namen der optionalen

Ergänzungen.

Tabelle 2: Optionale Ergänzungen und Pakete

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 41 von 104

[Seite 186]

Anlage 27

3.4. Grafische Darstellung der Pakete der Ausbauvarianten inklusive der opti- onalen Ergänzungen

Die folgenden Abbildungen zeigen die Pakte der Ausbauvarianten mit den möglichen optio-

nelen Ergänzungen aus Sicht der Hersteller.

Abbildung 9: KA-Herstellersicht - Ausbauvariante 1

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 42 von 104

[Seite 187]

Anlage 27

Abbildung 10: KA-Herstellersicht - Ausbauvariante 2

Abbildung 11: KA-Herstellersicht - Ausbauvariante 2a

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 43 von 104

[Seite 188]

Anlage 27

Abbildung 12: KA-Herstellersicht - Ausbauvariante 2b-1

Abbildung 13: KA-Herstellersicht - Ausbauvariante 2b-2

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 44 von 104

[Seite 189]

Anlage 27

Abbildung 14: KA-Herstellersicht - Ausbauvariante 3

Abbildung 15: KA-Herstellersicht - Ausbauvariante 3a-1

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 45 von 104

[Seite 190]

Anlage 27

Abbildung 16: KA-Herstellersicht - Ausbauvariante 3a-2

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 46 von 104

[Seite 191]

Anlage 27

4. Anwendungsfälle für die Systemkomponenten

In dem folgenden Kapiteln sind für die einzelnen Systemkomponenten die Anwendungsfälle nach den Ausbauvarianten sortiert aufgelistet.

4.1. Anwendungsfälle für das Kundenvertragspartner-System (KVPS)

In den folgenden Tabellen sind die Anwendungsfälle nach Pakten geordnet aufgelistet, wel-

che zu der jeweiligen Ausbauvarianten des KVPS gehören. Diese Anwendungsfälle sind

Grundlage für die Zertifizierung.

4.1.1. Ausbauvariante 1

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 47 von 104

[Seite 192]

Anlage 27

KVPS: POB/PEB ausgeben Grundfunktionen POB/PEB

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 48 von 104

[Seite 193]

Anlage 27

Tabelle 3: Ausbauvariante 1 für das Kundenvertragspartner-System (KVPS)

4.1.2. Ausbauvariante 2

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 49 von 104

[Seite 194]

Anlage 27

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 50 von 104

[Seite 195]

Anlage 27

Tabelle 4: Ausbauvariante 2 für das Kundenvertragspartner-System (KVPS)

4.1.3. Ausbauvariante 2a

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 51 von 104

[Seite 196]

Anlage 27

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 52 von 104

[Seite 197]

Anlage 27

KVPS: Transaktionsprüfungen durchführen Basispaket

KVPS: EFS_Berechtigung ausgeben Grundfunktionen EFS

Tabelle 5: Ausbauvariante 2a für das Kundenvertragspartner-System (KVPS)

4.1.4. Ausbauvariante 2b-1

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 53 von 104

[Seite 198]

Anlage 27

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 54 von 104

[Seite 199]

Anlage 27

KVPS: Transaktionsprüfungen durchführen Basispaket

KVPS: EFS_Berechtigung ausgeben Grundfunktionen EFS

Tabelle 6: Ausbauvariante 2b-1 für das Kundenvertragspartner-System (KVPS)

4.1.5. Ausbauvariante 2b-2

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 55 von 104

[Seite 200]

Anlage 27

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 56 von 104

[Seite 201]

Anlage 27

KVPS: Transaktionsprüfungen durchführen Basispaket

KVPS: EFS_Berechtigung ausgeben Grundfunktionen EFS

Tabelle 7: Ausbauvariante 2b-2 für das Kundenvertragspartner-System (KVPS)

4.1.6. Ausbauvariante 3

Anlage_2_KA Migrationsszenarien_V160.docx/Stand: September 2016 Seite 57 von 104

[Seite 202]

Anlage 27