Elektronisches Fahrgeldmanagement

Transkript

1 Seite 1 Elektronisches Fahrgeldmanagement Technische Fragen und Antworten

2 Seite 2 0 Allgemeines 0.1 Inhaltsverzeichnis Kapitel Seite 0 Allgemeines PayCard-Chipkarten, -Sicherheitsmodule und zugehörige Schnittstellenbeschreibungen Kontroll-(Lese-)geräte und zugehörige Schnittstellenbeschreibung Personalisierungsgeräte und zugehörige Schnittstellenbeschreibung VU-Hintergrundsysteme Verbundsystem und zugehörige Schnittstellenbeschreibung Allgemeines VDV-Kernapplikations-Chipkarten, -Sicherheitsmodule und zugehörige Schnittstellenbeschreibungen Migration zur VDV-Kernapplikation - Kontroll-(Lese-)geräte und zugehörige Schnittstellenbeschreibung Migration zur VDV-Kernapplikation - Personalisierungsgeräte und zugehörige Schnittstellenbeschreibung Migration zur VDV-Kernapplikation VU-Hintergundsysteme Migration zur VDV-Kernapplikation - Allgemein Änderungsverzeichnis Der aktuelle Stand unterscheidet sich vom vorherigen durch die Antwort auf die neue Frage 7.21 (Umgang mit (((eticket-fragmenten).

3 Seite 3 1 PayCard-Chipkarten, -Sicherheitsmodule und zugehörige Schnittstellenbeschreibungen 1.1 Ist ein gesichertes Lesen der Chipkartennummer und -gültigkeit notwendig? Ein gesichertes Lesen der Chipkartennummer und -gültigkeit ist nicht notwendig, da diese Daten auch für den Schlüssel benötigt werden und es somit keinen Sinn macht sie zu fälschen. Dies würde zu einem falschen Schlüssel führen, was im weiteren Verlauf dann Fehlermeldungen beim Lesen oder Schreiben von Records zur Folge hätte. 1.2 Gibt es eine allgemeine Funktion, um festzustellen, ob die Chipkarte authentisch ist? Nein, diese Funktion gibt es nicht. Dies erfolgt über das kryptographisch abgesicherte Lesen und/oder Schreiben. 1.3 Wie ist der Initialisierungsrecord definiert? Als Initialisierungsrecord für die Paycard ist der Record zu verwenden, der in der Spezifikation der Paycard als Auslieferungszustand beschrieben ist: Record Number Data Length [Bytes] Value 1 80 E2 2E C C4 0B C5 0C C6 0E E2 2E C2 01 0A C4 0B C5 0C C6 0E Der Initialisierungsrecord ist im Terminal und nicht im Hintergrundsystem zu erzeugen. Um ein Elektronisches Ticket mit dem Initialisierungsrecord zu überschreiben, muss jeder Record dieses Tickets (Start-, Folge- und Schlussrecord) mit einem Initialisierungsrecord überschrieben werden. Dabei werden an den entsprechenden Stellen die Nullen durch die Betreiber-ID, die SAM-ID und die Laufende Nummer ersetzt. Um den oben dargestellten Initialisierungsrecord schreiben zu können, muss im Regelfall das zu überschreibende Ticket vorher auf 1998 zurückdatiert werden. Ansonsten führt der Erstellungszeitpunkt 1999 zu einer Fehlermeldung der Karte. Der Initialisierungsrecord kann z.b. am Inhalt des Tags C5 (realisiert durch Scheidt&Bachmann) oder an der Gesamtlänge 2E und der Angabe Einzelrecord (realisiert durch Systemtechnik) erkannt werden. Darüber hinaus sind auch noch andere Möglichkeiten gegeben.

4 1.4 Wie kann erkannt werden, ob die Chipkarte thermisch bedruckt werden kann? Seite 4 Es wird für die Chipkarten (White-Cards) von card.etc einen oder mehrere definierte Nummernkreise geben, aus denen dann abgeleitet werden kann, dass die Chipkarte thermisch bedruckt werden kann. Diese und weitere Informationen werden auch für die SAMs in Form einer ASCII-Datei übergeben, die die folgenden Angaben enthält: Seriennummer als Hexadezimahlzahl Kartennummer Kartentyp Beispieldatei: 65967A13, F,VRR_Test 6C280CCB, F,VRR_Test 3B1092BB, F,VRR_Test 2663A3AF, F,VRR_Test B5, F,VRR_Test 2EE8C0D4, F,VRR_Test AE1285FB, F,VRR_Test 177D8F38, F,VRR_Test 8FC6D92A, F,VRR_Test 88AEF1B9, F,VRR_Test 9D6DFB04, F,VRR_Test BC48F89B, F,VRR_Test 8A6649EF, F,VRR_Test 03E06E06, F,VRR_Test , F,VRR_Test 404A4F86, F,VRR_Test FF6824C0, F,VRR_Test 69224A8A, F,VRR_Test , F,VRR_Test 0A4744E5, F,VRR_Test 271F6B9B, F,VRR_Test Quantity= Bis zu welchem Datum sind die Chipkarten gültig, die für die Massenpersonalisierung benutzt werden (Gültigkeit des Tickets und Verfallsdatum hängen davon ab)? Alle von card.etc gelieferten Chipkarten sind bis zum gültig.

5 Seite Wie soll der Aufdruck der Daten des Elektronischen Tickets auf dem Thermodruckfeld aussehen? Wie soll das Layout des Thermodruckfeldes gestaltet werden? Welche Inhalte werden wo und in welcher Größe ausgegeben. Die Festlegung erfolgte über den Arbeitskreis Marketing Tarif Vertrieb (MTV). Näheres steht in EFM-Daten.xls, Tabellenblatt Thermodruckdaten. 1.7 Können auf einer Chipkarte mehrere Elektronische Tickets vorhanden sein? Es können grundsätzlich mehrere Elektronische Tickets auf einer Chipkarte vorhanden sein. Dies gilt auch für eine White-Card. 1.8 Wie viele Elektronische Tickets können auf eine Chipkarte geschrieben werden? Für alle Elektronischen Tickets stehen 10 Records zur Verfügung. Da ein Elektronisches Ticket auch mehrere Records beanspruchen kann, ist diese Frage nicht eindeutig zu beantworten. Näheres hierzu siehe auch Einsatz von Chipkarten und Sicherheitsmodulen. 1.9 Müssen Zusatzmerkmale in einem eigenen Elektronischen Ticket gespeichert werden? Einige Zusatzmerkmale können (z.b. 1. Klasse) können in einem Elektronischen Ticket abgebildet werden (siehe auch Einsatz von Chipkarten und Sicherheitsmodulen ) Kann die Gültigkeit einer Chipkarte ermittelt werden? Die Gültigkeit einer jeden Chipkarte kann durch Auslesen ermittelt werden Wie groß ist das Feld ZD-Info im VRR? Im VRR hat das Feld ZD-Info eine Länge von 1 Byte (siehe auch Beschreibung der Headerdaten in Einsatz von Chipkarten und Sicherheitsmodulen, Seite 8 oben:...byte 00 ) Wo ist die Größe und der Aufbau des Ticketteils beschrieben? Der Ticketteil ist in Einsatz von Chipkarten und Sicherheitsmodulen beschrieben Was ist beim Bedrucken der Rückseite der Chipkarten zu beachten? Der Bereich des Chips kann auch auf der Rückseite nicht bedruckt werden, da hier produktionstechnisch eine kleine Vertiefung vorliegen kann, die dann von der Druckrolle nicht bearbeitet wird. Dies wird jedoch beim Entwurf der Layouts für die Rückseite bereits berücksichtigt. Durch die Antenne für das kontaktlose Interface kommt es zu keiner Beeinträchtigung der Rückseite in drucktechnischer Hinsicht Können die Chipkarten mit Kartenlesern manipuliert werden? Nein, dies ist nicht möglich, da zum Manipulieren der (Schreiben in die) Chipkarten Sicherheitsmodule benötigt werden, die in den Kartenlesern nicht vorhanden sind und auch nur an Berechtigte ausgegeben werden.

6 Seite Jedes Rohkommando eines Administrierungsvorgangs beinhaltet die fünf Felder PAN des SAMs aus EF_Application/MF, Application expiration date des SAMs aus EF_Application/MF, Application effective date des SAMs aus EF_Application, Key version aus EF_Info/DF_eTicket des SAMs und eine Zufallszahl (RND) des SAMs. Aus dem Dokument Administrierung der PayCard-Sicherheitsmodule geht hervor, dass das Personalisierungsgerät nur das expiration date liefert. Woher kommen die vier weiteren Parameter? Was bedeutet MF? Sollen die Parameter vom Hintergrundsystem gesetzt werden? Die im Dokument Administrierung der PayCard-Sicherheitsmodule beschriebenen Datenformate (Kapitel 4) beziehen sich auf die Schnittstelle zwischen VU-Hintergrundsystem und Zentralem Sicherheitsmodul. Die Inhalte der erwähnten Felder werden alle im Rahmen der Erstellung des Rohkommandos vom Personalisierungsgerät ermittelt. Vom VU- Hintergrundsystem sind dann wie beschrieben nur noch die Felder mit den administrierbaren Daten auszufüllen. MF steht für Masterfile. Näheres hierzu kann der Spezifikation der PayCard und des zugehörigen Sicherheitsmoduls entnommen werden. Das Personalisierungsgerät liefert nach einer Statusanfrage und nach jedem Einbringen eines Elektronischen Tickets mindestens die im Dokument Administrierung der PayCard- Sicherheitsmodule (Kapitel 2) erwähnten Daten, die erst einmal nichts mit dem Rohkommando zu tun haben. Genaueres hierzu steht ab der Version 1.0 in der Beschreibung der Schnittstelle zum Personalisierungsgerät von Scheidt&Bachmann Ist die Nummernvergabe bei Chipkarten und SAMs eindeutig? Die 19-stellige identisch aufgebaute Nummer einer Chipkarte oder eines SAMs ist immer eindeutig. Eine Nummer, die einer Chipkarte zugewiesen wurde, kann keinem SAM zugeordnet werden und umgekehrt. Es erfolgt also keine unabhängige Nummernvergabe für Chipkarten und SAMs Bis zu welchem Datum sind die SAMs gültig und wann werden sie ausgeliefert? Alle von card.etc gelieferten SAMs sind bis zum gültig und werden in der Woche vom 04. bis zum entsprechend der beiden über die Werkskonfiguration festgelegten Varianten getrennt verpackt ausgeliefert Wie sind die Test-SAMs konfiguriert? Die Limits in den Test-SAMs werden auf das Maximum gesetzt. Es gibt keine Koppelung an einen Bezahlvorgang mit der Börse und die Funktionskontrolle erlaubt alle Funktionen. Die Betreiber-ID der Test-SAMs ist 102 hexadezimal (258 dezimal).

7 Seite Wie werden Umlaute im Chip codiert? Windows ANSI oder ASCII? Umlaute und das Zeichen ß, die in unserem Fall nur vor dem im Ticketteil vorkommen können, sind nach VDV-Mitteilung Elektronische Tickets auf Chipkarten des deutschen Kreditgewerbes, Version 1.1, November 1999 im 7-Bit-ASCII-Code darzustellen. Da die deutsche Version dieses 7-Bit-Codes in der heutigen Zeit nicht mehr unterstützt wird, ist wie folgt vorzugehen: Wenn im Rahmen unseres Projektes von ASCII-Codierung die Rede ist, sind grundsätzlich nur Zeichen gemeint, die eine Codierung kleiner 128 haben, also dem normalen 7-Bit-ASCII- Code entsprechen. Die Codierung dieser Zeichen ist beim Windows ANSI-Code gleich. Da in unserem Projekt auch nur diese Zeichen benutzt werden, ist in unserem Projekt ASCII gleich Windows ANSI. Umlaute und das Zeichen ß sind im Regelfall nach Windows-ANSI zu codieren (siehe unten stehende Tabelle). Dabei sind jedoch die beiden folgenden Ausnahmen zu beachten: 1. Die Hintergrundsystemhersteller müssen bei der Übergabe an die Scheidt&Bachmann- DLL Umlaute und das Zeichen ß bei den Daten vor dem im Ticketteil von Windows-ANSI nach ASCII umwandeln (siehe unten stehende Tabelle). Hinsichtlich der für den Thermodruck zu übergebenden Codierungen wird auf die Scheidt&Bachmann- Schnittstellenfeinspezifikation verwiesen. Das Zeichen ß ist für den Thermodruck vorausssichtlich mit 223 (dez) bzw. DF (hex) zu codieren. Verbindlich steht dies in der Version 1.4 der Scheidt&Bachmann-Schnittstellenfeinspezifikation. 2. Der Massenpersonalisierer muss vor dem Eintrag in den Chip Umlaute und das Zeichen ß bei den Daten vor dem im Ticketteil von Windows-ANSI nach ASCII umwandeln (siehe unten stehende Tabelle). Hinsichtlich des Thermodrucks muss der Massenpersonalisierer ggf. durch Umwandlung sicherstellen, dass er die Zeichen richtig druckt. ANSI ASCII Zeichen dez hex dez hex Ä 196 C E Ö 214 D Ü 220 DC 154 9A ä 228 E ö 246 F ü 252 FC ß 223 DF 225 E1 Begründung: Fast alle Hintergrundsysteme codieren Umlaute und das Zeichen ß nach Windows-ANSI. Daher macht es keinen Sinn, dass jedes Hintergrundsystem bei den Daten für die Massenpersonalisierung vor dem Datenaustausch eine Umwandlung durchführt. Hier ist es sinnvoller, diese Umwandlung an einer Stelle beim Massenpersonalisierer durchzuführen.

8 Seite Wie kann ein leerer Record erkannt werden, auch ohne dass das aktuelle Datum und die aktuelle Uhrzeit bekannt sind? Mit leerer Record ist der Zustand der Records für die Elektronischen Tickets bei Auslieferung der Chipkarte bzw. bei nachträglicher Anwendung des Initialisierungsrecords (siehe auch 1.3) gemeint. Bei der PayCard ist in diesem Fall in den ersten vier Bytes eines Records immer das Bitmuster E2 2E C2 01 vorhanden. Die 01 kennzeichnet einen Einzelrecord und die Länge 2E ist die Mindestlänge eines Einzelrecords, ohne dass sich Daten im Ticketteil vor dem befinden. Da dies bei konkreten Elektronischen Tickets jedoch immer der Fall ist, ergibt sich dann eine größere Länge als 2E. Somit kann an dem obigen Bitmuster bei der PayCard ein leerer Record erkannt werden. Prinzipiell müsste diese Verfahrensweise auch bei der ZKA-GeldKarte anwendbar sein. Jedoch muss damit gerechnet werden, dass sich der Zustand der ersten vier Bytes bei der Auslieferung und bei der Anwendung eines Initialisierungsrecords, sofern dieser überhaupt definiert ist, unterscheiden. Näheres hierzu steht im Anhang Zusatzanwendung Elektronischer Fahrschein (ZKA-Spezifikation) von VDV-Mitteilung Elektronische Tickets auf Chipkarten des deutschen Kreditgewerbes, Version 1.1, November 1999 bzw. kann beim ZKA erfragt werden Wieviele Blanks müssen vor dem im Feld Ticketdaten des Elektronischen Tickets vorhanden sein? Die Felder vor dem werden jeweils durch ein Blank (Hex 20 ) getrennt. Die Blanks werden auch für ein fehlendes (leeres) Feld eingetragen, so dass immer fünf Blanks vorhanden sind. Wenn dies nicht gegeben ist, werden die Feldinhalte und somit das gesamte Elektronische Ticket falsch interpretiert. Näheres hierzu siehe auch Kapitel 2.3 in Einsatz von Chipkarten und Sicherheitsmodulen Wie sind vom Kunden zurückgegebene Chipkarten zu behandeln, die nicht zum eigenen Bestand gehören oder, wenn sie doch zum eigenen Bestand gehören, fremde Tickets enthalten? Eigene Tickets auf einer derartigen Chipkarte sind zu löschen. Handelt es sich um eine fremde Karte, ist diese dem entsprechenden Verkehrsunternehmen zuzusenden. Der Besitzer kann gegebenenfalls über card.etc oder den VRR ermittelt werden. Handelt es sich um eine eigene Karte, können fremde markierte Tickets gelöscht und bei in Kürze ablaufenden Tickets dieser Zeitpunkt abgewartet werden. In beiden Fällen ist das betroffene Verkehrsunternehmen auf dem kurzen Dienstweg zu informieren. Bei noch länger gültigen Tickets muss die Chipkarte an das fremde Verkehrsunternehmen zum Löschen weitergeleitet werden. Was länger gültig ist, liegt im Ermessen des Verkehrsunternehmens. Vor dem Versand einer Chipkarte sollte dies ebenfalls auf dem kurzen Dienstweg abgesprochen werden.

9 2 Kontroll-(Lese-)geräte und zugehörige Schnittstellenbeschreibung Seite Warum darf bei einem Kontrollvorgang ein VU-eigenes Elektronisches Ticket nicht gleich durch Rückdatieren des Verfallsdatums zum Überschreiben freigegeben werden sondern muss auch in diesem Fall markiert werden? Beim Markieren eines Elektronischen Tickets handelt es sich um das Aufbringen eines Merkmals, dass dieses Elektronische Ticket, obwohl es den Daten nach gültig ist, doch nicht gültig ist. Um bei einem EBE-Fall entsprechende Beweise zu besitzen, dies dem Kunden darzulegen, sollte das Elektronische Ticket (noch) nicht rückdatiert und somit zum Überschreiben freigegeben werden. 2.2 Müssen bei einer Terminalsperrung alle Elektronischen Tickets auf einer Chipkarte gesperrt werden, wenn sich auf dieser Chipkarte ein Elektronisches Ticket befindet, das mit einem gesperrten Terminal erzeugt wurde? Nein, es ist wie in Rahmenvorgaben für Kontrollgeräte beschrieben zu verfahren: Wurde das Elektronische Ticket des VRR mit der Hilfe eines gesperrten Sicherheitsmoduls (SAM) gespeichert? Dies ist der Fall, falls in der Sperrliste ein Eintrag (Typ TERMINAL- SPERRUNG") existiert, in dem die Terminalnummer identisch ist mit der in dem Elektronischen Ticket gespeicherten SAM-ID und das Anfangsdatum der Sperrung in dem Eintrag vor und (sofern schon vorhanden) das Endedatum der Sperrung in dem Eintrag nach dem Ausgabezeitpunkt des Elektronischen Tickets liegt. 2.3 Muss beim Markieren eines Elektronischen Tickets ein Beleg ausgegeben werden? Nein, die Ausgabe eines Beleges ist nicht notwendig, weil der Kunde im Falle einer Sperrung durch das Verkehrsunternehmen zum Zeitpunkt des Eintrages in die Sperrliste bereits drei entsprechende Schreiben erhalten hat. Hat der Kunde die Sperrung veranlasst, weiss er selber, warum das Ticket markiert wird. 2.4 Wie ist zu verfahren, wenn ein Elektronisches Ticket aus technischen Gründen nicht markiert werden kann? In diesem Fall ist genauso zu verfahren, als wenn ein Kunde das zum Markieren notwendige Einstecken der Chipkarte in das Kontrollgerät verweigert: Das Kontrollgerät muss sich dieses Elektronische Ticket merken und als nicht gültig von weiteren Prüfungen ausschliessen. 2.5 Welche Parameter müssen für einen Kontrollvorgang im Kontrollgerät vorhanden sein? Neben der aktuellen Wabennummer (dynamisch) muss das Kontrollgerät auch über das aktuelle Datum und die aktuelle Uhrzeit verfügen. Dabei müssen Wochentage erkannt werden und Feiertage ggf. über einen Zusatzbutton einstellbar sein. Außerdem muss eine Kontrolle in der 1. Klasse und im Interregio (bei DB) eingestellt werden können.

10 Seite Wie läuft ein Kontrollvorgang prinzipiell ab? Die Vorgehensweise ist wie folgt: 1. Alle Records sowie Chipkartennummer und Chipkartengültigkeit einlesen 2. Abgelaufene Chipkarten ablehen, wenn Chipkartengültigkeit mehr als 7 Tage überschritten ist. 3. Abgelaufene Records (Elektronische Tickets) aussortieren (Vergleich mit dem Feld Verfallsdatum ) 4. Irrelevante Elektronische Tickets aussortieren (Vergleich mit Liste relevanter Servicekennungen und relevanter Betreiber-IDs) 5. Markierte Tickets ausschließen 6. Abgleich mit der Sperrliste (Automatisches Markieren) mit Information des Bedieners 7. Markierte und zu markierende Tickets ausschließen 8. Automatische Überprüfung der zeitlichen (auch die der Chipkarte selbst), räumlichen und personellen Gültigkeit 9. Kryptografische Überprüfung des bzw. der in Frage kommenden Tickets 10. Ggf. abschließende manuelle Prüfung des bzw. der in Frage kommenden Tickets durch den Kontrolleur 2.7 Muss die Markierung eines Elektronischen Tickets auf Grund einer Terminalssperrung ebenfalls über das Verbundsystem an das ausgebende verkehrsunternehmen zurückgemeldet werden? Elektronische Tickets, die auf Grund einer Terminalsperrung markiert wurden, sind dem Hintergrundsystem des jeweiligen ausgebenden Verkehrsunternehmens nicht bekannt. Da Sie auch nicht in der Sperrliste vorhanden sind, muss deren Markierung auch nicht zurückgemeldet werden. Hinzu kommt, dass bei verbundübergreifenden Tickets, die mit einem gesperrten Terminal bzw. Sicherheitsmodul erzeugt wurden, die Anzahl der Verbünde und die Verbünde selbst unbekannt sind. Nichtsdestotrotz sollte das jeweilige Verkehrsunternehmen aber auf einem anderen geeigneten Weg informiert werden. 3 Personalisierungsgeräte und zugehörige Schnittstellenbeschreibung 3.1 Welche Arten von Personalisierungsgeräten sind bestellt worden? Es sind ein einfaches Personalisierungsgerät zum Einführen einer Chipkarte, eines mit einem Stapel und eines mit vier Stapeln bestellt worden. 3.2 Besitzt das Personalisierungsgerät eine Lesefunktion? Das Personalisierungsgerät besitzt eine Lesefunktion. Näheres hierzu ist in Datenaustausch zwischen Vertriebskomponente und Initialisierungsgerät" beschrieben.

11 Seite Liefert das Personalisierungsgerät die Gültigkeit der Chipkarte? Vom Personalisierungsgerät wird im Rahmen des Lesens der Records bzw. der Elektronischen Tickets auch die Gültigkeit der Chipkarte ausgelesen und an das Hintergrundsystem übermittelt. Näheres ist ab der Version 1.0 der entsprechenden Schnittstellenbeschreibung von Scheidt & Bachmann zu entnehmen. 4 VU-Hintergrundsysteme 4.1 Kann sichergestellt werden, dass alle Hintergrundsysteme die selben Anforderungen in der Phase der Pflichtenhefterstellung implementieren und wie erfolgt der Austausch der Informationen bei der Pflichtenhefterstellung? Die im Zuge der Pflichtenhefterstellung gestellten technischen Fragen werden zentral vom VRR gesammelt und beantwortet. Sie werden, wenn neue Fragen und Antworten vorliegen, durch den VRR an alle ihm bekannten mit der Realisierung beauftragten Unternehmen (nicht nur die der Hintergrundsysteme) per verschickt. Zusätzlich werden sie wie die übrigen Fragen und Antworten auch auf der den VUs bekannten Internetseite zu deren Information eingestellt. Ein Austausch der Pflichtenhefte ist im Allgemeinen nicht möglich, da sie auch internes Know-How des jeweiligen Unternehmens beinhalten, und daher im Regelfall nicht anderen Unternehmen zugänglich gemacht werden dürfen. 4.2 Wie soll ein VU-Hintergrundsystem bei Verarbeitung der vom Verbundsystem gelieferten Listen im Fehlerfall reagieren? Die Reaktionen eines VU-Hintergrundsystems im Fehlerfall sollten mit den Auftraggebern (VUs) abgesprochen werden. Als Richtlinie hierfür könnte das VRR-Verbundsystem dienen: Dieses verarbeitet korrekte Daten und gibt bei fehlerhaften Daten eine Meldung aus, die auch in einen Nachrichtenfile an das jeweilige VU eingebracht wird. Zusätzlich kann auch der öffentlichen Ordner des Verbundsystems genutzt werden (siehe auch "Austausch von Daten zwischen den Verkehrsunternehmen und dem Verbund"). 4.3 Wie erfolgt das Auslesen der Chipkarten sowie das Anzeigen und Bearbeiten der Elektronischen Tickets durch die Hintergrundsysteme der VUs? Es dürfen aus Datenschutzgründen nicht einfach alle Elektronischen Tickets angezeigt werden. Die Vorgehensweise ist vielmehr wie folgt:

12 Seite Alle Records sowie Chipkartennummer und Chipkartengültigkeit einlesen 2. Abgelaufene Chipkarten ablehen, wenn Chipkartengültigkeit mehr als 7 Tage überschritten ist. 3. Abgelaufene Records (Elektronische Tickets) aussortieren (Vergleich mit dem Feld Verfallsdatum ) 4. Irrelevante Elektronische Tickets aussortieren (Vergleich mit Liste relevanter Servicekennungen und relevanter Betreiber-IDs) 5. Markierte Tickets ausschließen 6. Abgleich mit der Sperrliste (Automatisches Markieren) mit Information des Bedieners 7. Markierte Elektronische Tickets fremder VUs aussortieren (Auswerten der Felder Zähler und Betreiber-ID ) 8. Elektronische Tickets fremder VUs aussortieren (Vergleich mit dem Feld Betreiber-ID ) 9. Kryptografische Überprüfung der in Frage kommenden Tickets 10. Eigene Elektronische Tickets (auch markierte) anzeigen und ggf. bearbeiten Unter 10. kann ggf. ein Austragen (z. B. Rückdatieren des Verfallsdatums) eines eigenen evt. markierten Elektronischen Tickets erfolgen. Natürlich können auch neue Elektronische Tickets eingetragen werden. An dieser Stelle noch einmal eine Erläuterung bezüglich der Markierung: Markieren bedeutet, dass das Feld Zähler auf den Wert 255 dezimal (FF hex) gebracht wird. Im VRR bedeutet dieser Wert, dass das Elektronische Ticket trotz ansonsten gültiger Daten, nicht gültig ist. Es ist also eine VRR-spezifische Definition, die nach VDV-Mitteilung Elektronische Tickets auf Chipkarten des deutschen Kreditgewerbes, Version 1.1, November 1999 zulässig ist. Das Elektronische Ticket darf daher nicht einfach auf Grund dieser Markierung überschrieben werden. Auf Wunsch des Kunden müssen zusätzlich alle übrigen vorhandenen Records (Elektronische Tickets), die bereits unter 1. eingelesen wurden, angezeigt und ggf. auch ausgedruckt werden können. Damit sind auch unabhängig von der Gültigkeit der Chipkarte Elektronische Tickets gemeint, deren Verfallsdatum bereits abgelaufen ist oder die markiert und von einem anderen VU sind. Eben alle übrigen vorhandenen Elektronische Tickets. Davon ausgenommen ist nur der Initialrecord. Ebenso muss hier bei Rückgabe der Chipkarte das Überschreiben aller Records mit dem Initialrecord und das Löschen des Thermodruckfeldes möglich sein. Bedingung hierfür ist, dass keine weiteren Elektronische Tickets vorhanden sind und der Kunde schriftlich bestätigt hat, dass die Chipkarte auch ansonsten (Geldbörse, Marktplatz) leer ist. Dadurch, dass unter 1. alle Records eingelesen wurden, ist der für Elektronische Tickets zur Verfügung stehende Platz dem Hintergrundsystem des VUs bekannt. Somit kann z.b. bereits frühzeitig festgestellt werden, ob noch ein Elektronisches Ticket geschrieben werden kann.

13 Seite Muss beim Markieren eines Elektronischen Tickets ein Beleg ausgegeben werden? Nein, die Ausgabe eines Beleges ist nicht notwendig, weil der Kunde im Falle einer Sperrung durch das Verkehrsunternehmen zum Zeitpunkt des Eintrages in die Sperrliste bereits drei entsprechende Schreiben erhalten hat. Hat der Kunde die Sperrung veranlasst, weiss er selber, warum das Ticket markiert wird. 4.5 Muss die Markierung eines Elektronischen Tickets auf Grund einer Terminalssperrung ebenfalls über das Verbundsystem an das ausgebende verkehrsunternehmen zurückgemeldet werden? Elektronische Tickets, die auf Grund einer Terminalsperrung markiert wurden, sind dem Hintergrundsystem des jeweiligen ausgebenden Verkehrsunternehmens nicht bekannt. Da Sie auch nicht in der Sperrliste vorhanden sind, muss deren Markierung auch nicht zurückgemeldet werden. Hinzu kommt, dass bei verbundübergreifenden Tickets, die mit einem gesperrten Terminal bzw. Sicherheitsmodul erzeugt wurden, die Anzahl der Verbünde und die Verbünde selbst unbekannt sind. Nichtsdestotrotz sollte das jeweilige Verkehrsunternehmen aber auf einem anderen geeigneten Weg informiert werden. 4.6 Wenn Elektronische Tickets getauscht werden, muss der Eintrag des E- lektronischen Tickets auf der Chipkarte geändert werden. Bedingt das Einbringen des neuen Elektronischen Tickets das Löschen des alten E- lektronischen Tickets (physisch und logisch) oder kann der vorhandene Eintrag des Elektronischen Tickets auf der Chipkarte überschrieben werden? Mit Tauschen eines Elektronischen Tickets ist hier die Änderung der räumlichen oder zeitlichen Gültigkeit gemeint. Hierzu muß das alte Ticket in seiner zeitlichen Gültigkeit begrenzt und gegebenenfalls ein neues Ticket mit den geänderten Daten geschrieben werden. Hinsichtlich der Behandlung des alten Tickets gibt es zwei Möglichkeiten: Das alte Elektronische Ticket wird durch Rückdatieren des Verfallszeitpunktes ungültig gemacht (austragen) und kann dann durch den Initialrecord oder ein neues altes Elektronisches Ticket mit der entsprechend verkürzten zeitlichen Gültigkeit überschrieben werden. Der entsprechende interne Datensatz des Verkehrsunternehmens ist auf jeden Fall anzupassen. Das Aus- und Eintragen ist dem VRR-Verbundsystem zu melden. Anstatt ein neues Elektronisches Ticket mit der entsprechend verkürzten zeitlichen Gültigkeit zu schreiben, ist es aber auch möglich, nur den Verfallszeitpunkt des alten Elektronischen Tickets zurückzusetzen, der wie in EFM-Daten definiert, 8 Tage nach dem Ende der verkürzten zeitlichen Gültigkeit liegen muss. Der entsprechende interne Datensatz des Verkehrsunternehmens ist auf jeden Fall anzupassen. Damit der Prüfvorgang korrekt abläuft, wird als Ende der Gültigkeit eines Elektronischen Tickets der Verfallszeitpunkt ausgewertet. Ein Elektronisches Ticket muss somit generell spätestens mit dem Überschreiten des Verfallszeitpunktes von der Sperrliste genommen werden. 4.7 Kann ein VU auch Elektronische Tickets anderer VUs sperren? Ein VU kann nur eigene Elektronische Tickets sperren.

14 Seite Warum darf bei einem Kontrollvorgang ein VU-eigenes Elektronisches Ticket nicht gleich durch Rückdatieren des Verfallsdatums zum Überschreiben freigegeben werden sondern muss auch in diesem Fall markiert werden? Beim Markieren eines Elektronischen Tickets handelt es sich um das Aufbringen eines Merkmals, dass dieses Elektronische Ticket, obwohl es den Daten nach gültig ist, doch nicht gültig ist. Um bei einem EBE-Fall entsprechende Beweise zu besitzen, dies dem Kunden darzulegen, sollte das Elektronische Ticket (noch) nicht rückdatiert und somit zum Überschreiben freigegeben werden. Dies entspricht auch der Vorgehensweise beim Kontrollgerät. Es gibt jedoch natürlich eine Ausnahme: Ist der Kunde jedoch genau wegen diesem Elektronischen Ticket bei seinem Vertragspartner erschienen, sollte genau dieses Elektronische Ticket nach Überprüfung des Sachverhaltes dann auch ausgetragen, sprich mit dem neuen Elektronischen Ticket (mit neuem Ausgabedatum) überschrieben werden. 4.9 Kann es vorkommen, dass ein VU-Hintergrundsystem mehrere Meldungen über die Markierung des selben Elektronischen Tickets erhält? Ja, dies kann dann vorkommen, wenn genau dieses VU das Elektronische Ticket markiert hat und sein Hintergrundsystem dies aus der eigenen Sperrliste entfernt und zusätzlich die entsprechende Meldung auch an das zugehörige Verbundsystem geschickt hat, dass diese wiederum an dieses VU zurückschickt Müssen die Hintergrundsysteme der VUs mit den in den Personalisierungsgeräten vorhandenen SAMs kryptographisch abgesichert kommunizieren? Ja, dies gilt wahrscheinlich später auch für Fahrkartenautomaten etc.. Hierfür ist in den Hintergrundsystemen ein Sicherheitsmodul erforderlich (siehe hierzu auch Rahmenvorgaben für die Vertriebskomponente, Kapitel 2.2.4, letzter Absatz). Dieses Sicherheitsmodul wird als so genanntes Zentrales Sicherheitsmodul allen Verkehrsunternehmen in Nordrhein- Westfalen vom VRR zentral zur Verfügung gestellt (siehe hierzu auch Administrierung der PayCard-Sicherheitsmodule ) Muss das Zentrale Sicherheitsmodul genutzt werden? Die softwaremäßige Administrierung der Sicherheitsmodule über das Zentrale Sicherheitsmodul ist Bestandteil des Sicherheitskonzeptes. Der als Ersatz vorgesehene Austausch der Sicherheitsmodule in den Geräten hat nicht die gleiche Qualität. Hinzu kommt, dass die Geräte nicht für einen regelmäßigen Austausch der Sicherheitsmodule konstruiert sind, so dass mit zusätzlichen Ausfällen und Reparaturen, die wiederum mit Kosten verbunden sind, gerechnet werden muss. Da bei dieser Verfahrensweise die Sicherheitsmodule nicht jede Woche ausgetauscht werden sollen, werden mit Sicherheit die Zählerwerte entsprechend hoch angesetzt. Die Folge davon ist, dass bei einem Diebstahl allen Verkehrsunternehmen ein relativ hoher Schaden entsteht, der bei Nutzung des Zentralen Sicherheitsmoduls nicht entstanden wäre, da hier die Werte optimal angepasst werden können.

15 Seite Wie ist bei Elektronischen Tickets zu verfahren, die nach den in die Sperrliste zu übertragenden Daten identisch sind? In diesem Fall muss zwingend darauf geachtet werden, dass der Erstellungszeitpunkt unterschiedlich ist. Hierzu muss nur die Minutenstelle unterschiedlich gestaltet werden Welche Gültigkeit eines Elektronischen Tickets muss eingetragen werden? Als Gültigkeit ist vom VU-Hintergrundsystem der 1. des Monats des Beginns und der letzte Tag des Monats des Endes der Gültigkeit einzutragen. Der Monat des Endes der Gültigkeit ist dabei bei Abonemments in der Regel identisch mit dem Monat des Endes der Gültigkeit der Chipkarte. Bei begründeten Sachverhalten kann auf Wunsch des Kunden oder des VUs auch ein früheres Ende eingetragen werden. Auf keinen Fall darf die Gültigkeit eines Elektronischen Tickets über die Gültigkeit der Chipkarte hinaus reichen Wie muss eine zurückgegebene White-Card behandelt werden? Es müssen alle Records mit dem Initialrecord überschrieben und der Thermodruck gelöscht werden Welche Daten müssen für verbundübergreifende Elektronische Tickets im Hintergrundsystem hinterlegt werden? An welches Verbundsystem muß ich Elektronische Tickets melden. Als erstes muß die Zuordnung eines Tickets zu dem für den Tarif verantwortlichen Verbund ermittelt werden. Diese ergibt sich aus den vom VDV definierten Nummernkreisen, die zur Zeit folgendermaßen zugeordnet sind: VGN: bis VRR: bis VRS: bis und bis Danach muß ermittelt werden, in welchen Verbünden ein Ticket gültig ist. Näheres hierzu steht im Dokument EFM-Daten und dort im Tabellenblatt Anmerkungen. Ergänzend hierzu sei angemerkt, dass zur Zeit der VGN-Tarif hinsichtlich des Elektronischen Tickets nicht verbundübergreifend also ausschließlich in der VGN gültig ist und dass zur Zeit beim VRS-Tarif VRR-Verkehrsunternehmen die Tickets vereinfachend grundsätzlich als verbundübergreifend im VRR und VRS gültig kennzeichnen können. Letzters ist dadurch begründet, dass VRR-Verkehrsunternehmen überwiegend Tickets verkaufen, die sowohl im VRR als auch im VRS gültig sind. Der theoretisch mögliche Verkauf von Tickets, die nur im VRS gültig sind, ist dabei zur Zeit vernachlässigbar. Die so ermittelten Verbundkennungen müssen im Hintergrundsystem hinterlegt und bei verbundübergreifenden Tickets in die entsprechenden Records für das Verbundsystem eingetragen werden.

16 Seite 16 Nicht verbundübergreifende Tickets dürfen nur an den entsprechenden Verbund gemeldet werden. Bei verbundübergreifenden Tickets kann man sich für einen der Verbünde entscheiden. Zur Zeit bedeutet dies zum Beispiel, dass VRR-Verkehrsunternehmen VRR- und VRS-Tickets an das VRR-Verbundsystem und VGN-Verkehrsunternehmen VGN- und VRR-Tickets an das VGN-Verbundsystem melden können. Wenn man sich für einen Verbund entschieden hat, darf dieser für das entsprechende Ticket nicht mehr gewechselt werden In welcher Form werden die Daten für die Positionierung der bei den verschiedenen Layouts vorzunehmenden Thermodrucke zur Verfügung gestellt? Näheres steht in EFM-Daten.xls, Tabellenblatt Thermodruckdaten Wie ist zu verfahren, wenn der Thermodruck auf der Chipkarte im Laufe der Zeit verblasst? Der Thermodruck muss dann erneuert werden. Hierzu müssen die Hintergrundsysteme eine entsprechende Funktion zur Verfügung stellen Welche Daten müssen für die Kontrolle der Elektronischen Tickets im Hintergrundsystem hinterlegt werden? Die für die Kontrolle der Elektronischen Tickets erforderlichen Daten werden durch den Hersteller der Kontrollgeräte definiert und lehnen sich formal an die bereits vom VRR- Verbundsystem gelieferten Listen an. Das Hintergrundsystem muss mindestens die Sperrliste Verbundsystem, die Liste der im Verbund zusammengeschlossenen Verkehrsunternehmen und die Liste der Tickettypen beschrieben in Austausch von Daten zwischen den Verkehrsunternehmen und dem Verbund an die Kontrollgeräte übermitteln. Näheres steht in Allgemeine Beschreibung der Daten eines Kontrollgerätes Welche Daten sind in welcher Form für die Massenpersonalisierung von den Hintergrundsystemen der VUs zu liefern? Näheres hierzu steht im Dokument Austausch von Daten zwischen dem Massenpersonalisierer und den Verkehrsunternehmen" Sind bei dem im Dokument Austausch von Daten zwischen dem Massenpersonalisierer und den Verkehrsunternehmen" beschriebenen Feld TRW-Felder auch die Felder mit der Länge 0 mitzuzählen? Ja, auch diese Felder sind mitzuzählen und entsprechend anzugeben, da ansonsten die aufzudruckenden Texte verschoben werden. Das momentan definierte VRR-Layout hat z.b. immer 8 TRW-Felder.

17 Seite Müssen bei dem nun zur Anwendung kommenden Verfahren der Massenpersonalisierung mit normalen SAMs in den Feldern Terminal-Nr. und Laufende Nummer wie in EFM-Daten beschrieben zwingend Nullen vorgegeben werden? Da die Nullen nur als Platzhalter vorgesehen sind und vom normalen SAM überschrieben werden, können prinzipiell auch andere Werte als Platzhalter eingetragen werden. Insbesondere dann, wenn bereits das vorherige Verfahren der Massenpersonalisierung realisiert wurde, ist es nicht notwendig, dies wieder zu ändern. Jedoch darf das jeweilige Hintergrundsystem nicht seine Werte wieder in der Antwortdatei des Massenpersonalisierers erwarten. 5 Verbundsystem und zugehörige Schnittstellenbeschreibung 5.1 Bei der Beschreibung des Datenaustausches findet man in vielen Tabellen den Eintrag: Kartennummer, "XXXXXXXXXX", BCD, 10. Wie ist dies zu interpretieren? Es handelt sich hier immer um die 19-stellige Kartennummer zzgl. eines Halbbytes mit "D" (Hex) bei der ZKA-GeldKarte und beim ZKA-SAM bzw. "F" (Hex) bei der PayCard und beim PayCard-SAM, die in 10 Bytes BCD-codiert untergebracht wird. Näheres hierzu siehe auch Austausch von Daten zwischen den Verkehrsunternehmen und dem Verbund". 5.2 Gibt es Trennzeichen zwischen den einzelnen Records in den Dateien? Nein, es gibt keine Trennzeichen (CR und/oder LF). Da es sich im Prinzip um binäre Dateien handelt, könnten diese Zeichen immer auftauchen und zu Fehlern führen. Es gibt auch kein Dateiende-Zeichen. 5.3 Beinhaltet die Zahl der Records auch den Header-Record? Nein, die Zahl der Records beinhaltet alle dem Header folgenden Records 5.4 Es wird immer eine gesamte Sperrliste mit dem VRR-Verbundsystem ausgetauscht, nur die markierten Einträge werden entfernt. Dieses Vorgehen erzeugt einen unnötig großen Datenaustausch. Wieso werden nicht nur aktuelle Änderungen versandt? Wenn immer nur Änderungen übertragen würden, bestände die Gefahr, dass die bei der VRR GmbH und die beim Verkehrsunternehmen vorhandenen Daten auseinander laufen. Dies wäre insbesondere bei einer fehlerhaften Datenübertragung der Fall. Bei dem nun gewählten Verfahren ist jedoch sichergestellt, dass spätestens am nächsten Tag wieder ein korrekter Datenbestand vorhanden ist (selbstheilend). Darüber hinaus ist so sichergestellt, dass die Verkehrsunternehmen und nicht die VRR GmbH immer den Inhalt der Sperrliste bestimmen. 5.5 Wie häufig wird die Sperrliste aktualisiert? Die Sperrliste wird einmal täglich aktualisiert.

18 5.6 Sind die Sperrliste der Elektronischen Tickets und die Sperrliste der SAMs in einer Datei zu übertragen? Seite 18 Die Sperrliste der Fahrscheine ist mit der der SAMs und der Liste der Markierungen in einer Datei. 5.7 Wie ist die Meldungsliste genau aufgebaut? Wird mit der Zahl der Datenrekords die Summe aller Rekords z.b. 10 Fahrscheinsperrungen + 5 Terminalsperrungen Fahrscheinausträge angegeben? Wird jeder einzelne Rekord (z.b. Fahrscheinsperrung) mit dem Rekordnamen eingeleitet (in diesem Fall FAHRSCHEINSPERRUNG )? Handelt es sich bei den Listen der... um einzelne Dateien? Die Zahl der Records ist die Summe aller Records. Jeder einzelne Record wird mit dem Recordnamen eingeleitet. Bei den Listen der... handelt es sich um jeweils eigene Dateien. 5.8 Ersetzt eine neuere Datei Liste der... eine ältere Version? Ja, ab dem angegebenen Gültigkeitsdatum ist allein diese Version der Liste gültig. 5.9 Was ist der Unterschied zwischen den beiden Betreiber-IDs Kennung des ausgebenden VUs und Verbundkennung (z.b. beim Fahrscheinaustrag)? Ist es vorgesehen, dass ein anderes als das ausgebende VU einen Fahrscheinaustrag durchführen kann? Die Kennung des ausgebenden VUs ist etwas anderes als die Verbundkennung. Jedes Verkehrsunternehmen und jeder Verkehrsverbund hat eine Betreiber-ID. Es kann nur das ausgebende Verkehrsunternehmen einen Fahrschein austragen Wozu soll die beim Datenaustausch mit dem VRR-Verbundsystem vorkommende Information Anzahl der Verbünde und Verbundkennung verwendet werden? Die variable Information Anzahl der Verbünde ist ein Steuerungselement um die Länge des Records eindeutig erkennen zu können. Durch die anzugebenden Verbundkennungen, deren Anzahl in dieses Feld einzutragen ist, werden verbundübergreifende Fahrscheine in der Sperrliste gekennzeichnet. Das VRR-Verbundsystem erkennt an dieser Information, ob diese Daten an andere Verbundsysteme weiterzuleiten sind (näheres hierzu siehe Austausch von Daten zwischen den Verkehrsunternehmen und dem Verbund, Seite 3 unten). Diese Informationen müssen durch die Verkehrsunternehmen bei der Erstellung der internen Daten berücksichtigt werden. Achtung: Bei mehreren Verbünden (Anzahl der Verbünde >= 2) ist der entsprechende Record nicht entsprechend der Anzahl der Verbünde mehrmal vorhanden, sondern nur einmal mit allen Verbünden Wann muss ein Elektronisches Ticket dem VRR-Verbundsystem als ausgetragen gemeldet werden? Ein Elektronisches Ticket wird u.a. dann ausgetragen, wenn es überschrieben wird. Hierzu ist vorher das Verfallsdatum ggf. zurückzusetzen. Wann ein Fahrscheinaustrag zu melden ist, steht in Austausch von Daten zwischen den Verkehrsunternehmen und dem Verbund, Kapitel 2. Vereinfacht und zusammenfassend gesagt, ist ein Elektronisches Ticket immer dann dem VRR-Verbundsystem als Ausgetragen zu melden, wenn das Verfallsdatum über-

19 Seite 19 schritten ist oder das Ticket dem ausgebenden Verkehrsunternehmen als markiert gemeldet wurde (siehe auch 5.14). Diese Meldungen sind für die Aktualisierung der VRR-Positivliste zwingend erforderlich Wann muss eine Terminalsperrung nicht mehr dem VRR-Verbundsystem gemeldet werden? Eine Terminalsperrung darf unabhängig davon, ob ein Anfangs- und Endezeitpunkt vorliegt, erst dann nicht mehr dem VRR-Verbundsystem gemeldet werden, wenn sichergestellt ist, dass alle Elektronischen Tickets, die mit diesem Terminal illegal erstellt wurden, markiert worden sind (also wahrscheinlich nie) Wofür benötigen wir die Positivliste? Die Positivliste dient der Plausibilitätsprüfung der von den VUs übermittelten Einträgen auf der Sperrliste Welche Elektronischen Tickets sind dem VRR-Verbundsystem über die Positivliste zu melden? Über die Positivliste sind nur die momentan ausgegebenen Elektronischen Tickets zu melden. Hierzu gehören auch die gesperrten Elektronischen Tickets. Nicht gemeldet werden dürfen ausgetragene oder markierte Elektronische Tickets Wird die Liste der Tarifgebiete mit Nachbarschaftsbeziehungen auch auf die Übergangstarife erweitert, so dass alle Kombinationen im Hintergrundsystem hinterlegt werden können? Die Liste der Tarifgebiete mit Nachbarschaftsbeziehungen wird auf Übergangstarife erweitert. Für den Übergangstarif zum VRS werden alle Angaben in das Feld Preisstufe geschrieben. Näheres steht in EFM-Daten.xls, Tabellenblätter mit Teilbezeichnung...Preisstufe Gibt es die Nachrichtendateien in beide Richtungen Ja, die Nachrichtendateien gibt es sowohl in der Richtung zu den Hintergrundsystemen der VUs als auch in der Richtung zum Verbundsystem. 6 Allgemeines 6.1 Gelten die gemachten Aussagen auch für eine ZKA-Geldkarte? Die gemachten Aussagen sind kartenunabhängig, wenn auf der Karte eine Applikation Elektronische Tickets gemäß der VDV-Mitteilung Elektronische Tickets auf Chipkarten des deutschen Kreditgewerbes, Version 1.1, November 1999 vorhanden ist. Dies ist bei der ZKA-Geldkarte gegeben. Die Möglichkeit des Bedruckens der Chipkartenrückseite ist zurzeit jedoch nur bei der vom VRR eingesetzten White-Card vorhanden. Darüber hinaus wird die ZKA-Geldkarte vom VRR zurzeit noch nicht genutzt. 6.2 Wie ist mit einem ausgegebenen Elektronischen Ticket zu verfahren, das trotz seiner gültigen Daten nicht mehr gültig ist. Ein ausgegebenes Elektronisches Ticket, das auf Grund seiner Daten zwar gültig jedoch aus welchem Grund auch immer nicht mehr gültig ist, muss entweder ungültig gemacht oder

20 Seite 20 markiert oder auf die Sperrliste gesetzt werden. Welche Maßnahme durchgeführt wird, hängt davon ab, ob auf die Chipkarte, auf die es eingetragen ist, Zugriff besteht oder nicht. Wenn der Kunde z.b. nicht zahlt, ist sein Ticket nicht mehr gültig. Zugriff auf die Chipkarte bedeutet, es wird kontrolliert und die Chipkarte steckt im Kontrollgerät oder der Kunde ist im Kundencenter und die Chipkarte steckt im Personalisierungsgerät. In beiden Fällen kann z.b. markiert werden. Andernfalls kann die Karte nur auf die Sperrliste gesetzt werden. 6.3 Wie kann ein gültiges Elektronisches Ticket verändert werden, wenn der Kunde z.b sein Elektronisches Ticket auf einer andere Karte haben möchte? Ein gültiges Elektronisches Ticket darf nach VDV-Mitteilung Elektronische Tickets auf Chipkarten des deutschen Kreditgewerbes, Version 1.1, November 1999 nur von dem Verkehrsunternehmen hinsichtlich seines Verfallsdatums zurückzudatiert und somit zum Überschreiben frei gegeben werden, das ihn auch auf einer Karte eingetragen hat bzw. dieselbe Servicekennung verwendet. Hierfür ist u.u. immer eine Online-Verbindung zum Hintergrundsystem und somit zu den internen Daten eines Verkehrsunternehmens erforderlich. Dies ist somit ggf. nur in bestimmten Kundencentern möglich. Die Entscheidung über die entsprechende Vorgehensweise muss ein Verkehrsunternehmen selbst treffen. 6.4 Wie ist ein Transferieren einzelner Elektronischer Tickets von einer Chipkarte zur anderen mit der derzeitigen Spezifikation möglich, und wie soll das Transferieren fachlich ablaufen, oder ist das Transferieren überhaupt nicht vorgesehen? Ein Transferieren ist nicht vorgesehen. Um ein Elektronisches Ticket auf eine andere Chipkarte zu bekommen, muss beim Vertragspartner (Verkehrsunternehmen) ein neues Elektronisches Ticket auf der anderen Chipkarte angelegt werden (eintragen). Das alte Elektronische Ticket muss ungültig gemacht werden (austragen). Der entsprechende interne Datensatz des Verkehrsunternehmens ist anzupassen. Das Aus- und Eintragen ist dem VRR- Verbundsystem zu melden (näheres hierzu siehe Austausch von Daten zwischen dem Initialisierungsgerät und der Vertriebskomponente, Seite 6). 6.5 Wie wird mit der Sperrung und dem Wegfallen des Grundes für die Sperrung ( Entsperrung ) von Elektronischen Tickets umgegangen? Durch den verzögerten Datenabgleich ist dem Kontrollgerät noch nicht bekannt, dass der Grund für die Sperrung entfallen ist. Dies führt dazu, dass bei einem Kontrollvorgang das Elektronische Ticket markiert wird. Diese Problematik wird dadurch umgangen, dass ein einmal gesperrtes Elektronisches Ticket nicht wieder entsperrt werden kann. Das Elektronische Ticket muss grundsätzlich mit neuem Ausgabedatum neu geschrieben werden (näheres hierzu siehe Austausch von Daten zwischen dem Initialisierungsgerät und der Vertriebskomponente, Seite 6). Dadurch entstehen eine neue Daten, die nicht auf der Sperrliste stehen. Sofern das Elektronische Ticket dem Bearbeiter vorliegt, sollte beim Entsperren eines Elektronischen Tickets das eventuell markierte, gesperrte Elektronische Ticket durch Rückdatieren des Verfallsdatums überschreibbar zu machen und anschließend durch das neuen Elektronische Ticket mit neuem Ausgabedatum zu überschreiben.

21 Seite Kann eine Rückgabe einer White-Card erfolgen, auch wenn sich noch mehrere gültige Fahrscheine auf der Chipkarte befinden und diese von fremden VUs sind? Eine Rückgabe kann in diesem Fall eigentlich nicht erfolgen. Tritt dieser Fall trotzdem ein, gilt das unter 1.22 geschriebene. 6.7 Wie ist sichergestellt, dass Elektronische Tickets, die mit einem irgendwo gestohlenen SAM erzeugt wurden, erkannt werden? Um dies sicherzustellen, reichen alle Verbundsysteme ihre Terminalsperrrungen an übergeordnete Systeme weiter und erhalten im Gegenzug dann eine Liste mit den Terminalsperrrungen aller Verbundsysteme. Es wird in diesem Zusammenhang empfohlen, dass die in den Terminals vorhandenen SAMs, die wieder in den Besitz eines VUs gelangen, nicht weiter verwendet werden, da die entsprechende SAM-ID wahrscheinlich nie (siehe unter Verbundsystem) von der Liste der Terminalsperrungen entfernt werden kann. 6.8 Unterschied zwischen Fahrschein-Sperrung und -Markierung? Bei den Fahrschein-Sperrungen, die in den Meldungslisten von den VUs und in der Sperrliste des Verbundes vorhanden sind, handelt es sich genau genommen um einen Sperrauftrag. Eine Fahrschein-Markierung ist somit genau genommen die Bestätigung eines VUs, dass ein Sperrauftrag ausgeführt wurde. 6.9 Welche Testmöglichkeiten gibt es und wie sind Test-Berechtigungen definiert? Test-Berechtigungen (frühere Bezeichnung Mustertickets) können auf den Test-Chipkarten von den Daten her wie echte Berechtigungen aufgebracht werden, da die Test-Chipkarten andere Schlüssel wie die normalen Chipkarten haben. Die entsprechenden Test-SAM`s und Test-Chipkarten mit Test-Schlüsseln gibt es für die Terminalhersteller bei der VDV KA GmbH & Co KG. Im Produktivbetrieb müssen für Test-Berechtigungen Service-IDs benutzt werden, die jeweils um 1 höher liegen als die normale Service-ID. Somit können dann echte Berechtigungen an geraden und Test-Berechtigungen an ungeraden Service-IDs eindeutig erkannt werden. Zusätzlich kann auch sofern vorhanden ein Test-Hintergrundsystem eventuell im Zusammenspiel mit dem Test-VRR-Verbundsystem genutzt werden. Wenn es erforderlich ist, kann auch die im folgenden definierte Test-Berechtigung eingesetzt werden: Servicekennung: Tickettyp: Testticket Preisstufe: nach Absprache zwischen den Beteiligten Gültigkeit: nach Absprache zwischen den Beteiligten Zusätze: nach Absprache zwischen den Beteiligten Name: Testvorname Testnachname Bermerkungen: Test Geschlecht: Männlich Geburtstag:

22 Seite 22 Die übrigen Daten ergeben sich jeweils automatisch. Der Einsatz dieser Test-Berechtigung muss zwischen allen Beteiligten abgesprochen werden Das HEX-Format (HEX 2 Byte lang/ HEX 3 Byte lang) ist ein Bestandteil z.b. der Verbundschnittstelle. Die Reihenfolge der Bytes ist nicht beschrieben. Wird die UNIX- oder die Windows-Variante genommen? Generell gilt bei den vom VRR bzw. VDV definierten Datenformaten, dass bei Zahlen wie allgemein üblich die höherwertige Stelle immer zuerst kommt. Im Umfeld der Betriebssysteme interpretiert, bedeutet dies, dass wir die UNIX-Variante genommen haben Gibt es Probleme beim Öffnen der im Rahmen unseres Projektes erzeugten Dateien? Von verschiedenen Seiten wurde beobachtet, dass die im Rahmen unseres Projektes erzeugten Dateien, bei denen es sich um Binärdateien handelt, durch das Öffnen mit z.b. Wordpad verändert werden. Selbst beim Betrachten mit einem Hex-Editor, der die einzige Möglichkeit darstellt unsere Dateien zu betrachten, ist dies bereits vorgekommen. Alle Beteiligten werden daher im eigenen Interesse gebeten, nur Hex-Editoren zu verwenden, bei denen nichts passiert Wie können Probleme bei der Interpretation der bei der Gültigkeitsangabe eines Elektronischen Tickets verwendeten zweistelligen Jahreszahl umgangen werden? Bei der Nutzung von standardmäßigen Datumsroutinen können Fehler bei der Interpretation der Gültigkeitsangabe eines Elektronischen Tickets auftreten. Die hier verwendete zweistellige Jahreszahl kann jedoch mit Hilfe des Verfallsdatums interpretiert werden. Das Verfallsdatum liegt immer 8 Tage nach Ablauf der Gültigkeit (siehe auch EFM-Daten), so dass durch entsprechende Vergleiche die zweistellige Jahreszahl richtig interpretiert werden kann Wie wird sichergestellt, dass gesperrte verbundübergreifende Fahrscheine allen betroffenen Verbünden bekannt sind und wie wird eine entsprechende Markierung wieder an das ausgebende Verkehrsunternehmen geleitet? Dies ist die Aufgabe des so genannten Landessystems. Die Verbundsysteme leiten generell alle verbundübergreifenden Fahrscheinsperrungen an das Landessystem weiter, das diese wiederum an alle im Datensatz genannten Verbünde verteilt. Die verbundübergreifenden Fahrscheinmarkierungen werden von einem Verbundsystem dann an das Landessystem weitergeleitet, wenn der ausgebende Verbund ein anderer als der eigene ist. Das Landessystem leitet dann die Fahrscheinmarkierung an den ersten im Datensatz genannten Verbund weiter. Dies ist laut Definition in Austausch von Daten zwischen den Verkehrsunternehmen und dem Verbund, Seite 3 unten der ausgebende Verbund Wie ist zu verfahren, wenn bei einem SchokoTicket nachträglich die Schulträgerkennung aufgedruckt werden soll? In diesem Fall kann dies über die Definition eines speziellen Druck-Layouts geschehen. Hierzu muss nicht zwingend eine neue Chipkarte ausgegeben werden.

23 6.15 Wie ist ein FirmenTicket VRR/VRS an das VRR-Verbundsystem zu melden? Seite 23 Beim FirmenTicket VRR/VRS ist darauf zu achten, dass es auf jeden Fall als verbundübergreifend zu kennzeichnen ist. Konkret heisst das, dass in dem entsprechenden Record die Anzahl der Verbünde 2 ist und dann in dieser Reihenfolge die Verbundkennungen vom VRR und VRS folgen. 7 VDV-Kernapplikations-Chipkarten, -Sicherheitsmodule und zugehörige Schnittstellenbeschreibungen Die Antworten auf die Fragen in den vorherigen Kapiteln gelten sinngemäß soweit möglich auch für die Migration zur VDV-Kernapplikation, sofern nicht bei den folgenden Fragen anders geantwortet wird. Bei Unklarheiten bitten wir, entsprechend nachzufragen. 7.1 Wird bei der VDV-Kernapplikation nur 1 SAM benötigt und wie sehen die Abläufe beim Betriebssystem Seccos aus? Bei der VDV-Kernapplikation wird grundsätzlich nur 1 SAM benötigt. Dieses SAM berücksichtigt die beiden alternativen Möglichkeiten der Gestaltung der technischen Abläufe im Rahmen des Verkaufablaufes. Eine der beiden alternativen Möglichkeiten, die vom Betriebssystem SECCOS genutzt werden soll, muss noch genauer spezifiziert werden. Je nachdem wie die Spezifikation ausssieht, unterscheiden sich die Abläufe bei den alternativen Möglichkeiten mehr oder weniger. Die entsprechenden Terminals müssen also grundsätzlich beide Alternativen beherrschen, da sie zum Standard VDV-Kernapplikation gehören. Näheres hierzu kann den Spezifikationen von Nutzermedium und SAM entnommen werden. 7.2 Wie erkennt man an der Nummer, dass es sich um eine "neue" KA- Chipkarte handelt? Bisher entsprachen die ersten 8 Stellen der Bankleitzahl und das letzte Halbbyte war die Hexadezimalzahl F als Kennung der- Paycard. Das letzte Halbbyte wird auf Null gesetzt. Die genaue Konvertierungsregel für die "neue" Chipkartennummer steht im Dokument Aufbau des NRW-KA-EFS und Konvertierungsregeln im Kapitel 3 gleich am Anfang der Tabelle. Die Fußnoten in diesem Dokument sind unbedingt zu beachten. 7.3 Muss eine Zertifizierung des privaten SAM-Betreiberschlüssels vom VU beantragt werden? Gemäß VDV-Kernapplikation sind die VU dafür verantwortlich. Wie wird der private SAM-Betreiberschlüssel zur Freischaltung der SAM generiert? Es ist keine Zertifizierung erforderlich. Das entsprechende Schlüsselpaar (privater und öffentlicher Schlüssel) kann vom VU selbst oder im Auftrag von einem Dienstleister (z.b. durch den, der das Schlüsselmanagement für die VDV KA GmbH & Co. KG durchführt) erzeugt werden. 7.4 Wie gelangt der private SAM-Betreiberschlüssel zur Freischaltung der SAM in das Hintergrundsystem, sofern dieser nicht im eigenen VU erzeugt wurde? Er wird in einem vom Schlüsselmanagement definierten Format übergeben.

24 Seite Wird der private SAM-Betreiberschlüssel jeweils mit jeder Neulieferung von SAM gewechselt? Nein, dies liegt im Ermessen des Schlüsseleigentümers also des VU s. 7.6 Wird eine technische Realisierungsmöglichkeit verhindert, den privaten SAM-Betreiberschlüssel zu verändern und in die SAM zu übertragen? Dies ist nicht erforderlich, da im SAM nur der öffentliche Teil dieses Schlüsselpaares vorhanden ist. Der private Teil ist im Besitz des VU s. 7.7 Sind in den SAM noch Kontingente für die Produktion von Berechtigungen (Tickets) definiert, oder kann ein SAM nach Freischaltung theoretisch unbegrenzte Mengen produzieren? Es gibt beide Möglichkeiten. 7.8 Welche Besonderheiten sind beim SAM im Zusammenhang mit der Massen-/Serienpersonalisierung (VU-intern) zu beachten? Es sind keine Besonderheiten zu beachten. 7.9 Sind die SAM zur Massenpersonalisierung seitens der VU zu beschaffen oder ist dies die Aufgabe des Massenpersonalisierers? Die SAM s können nur über die VU beschafft werden Neben der Aktivierung eines SAM (nach Einschalten des KVP-Terminals) soll laut KA auch eine Deaktivierung (neben der Außerbetriebsetzung durch Abschaltung?) möglich sein. Wie wird diese angestoßen? Eine Außerbetriebsetzung erfolgt durch eine Unterbrechung der Stromversorgung oder einen Reset des SAM s. Anschließend muss sich das Terminal gegenüber dem SAM authentifizieren. Eine Deaktivierung erfolgt über das SecurityManagement der VDV-Kernapplikation Sind zur Erhöhung der Sicherheit im KVP-Terminal besondere Maßnahmen vorgesehen bzw. vorzusehen, um eine erneute Authentifizierung (nach Abschalten des Gerätes) zu umgehen? Oder sind diese unnötig? Beispiel: Gerät wird mit gepufferter Energiequelle entwendet. Es sind keine besonderen Maßnahmen notwendig. Es wird empfohlen, sicherzustellen, dass das SAM beim Abschalten wirklich von der Energieversorgung getrennt wird. Ansonsten wird das Sicherheitsfeature Authentifizierung des Terminals gegenüber dem SAM unterlaufen Welche Auswirkungen hat das Abhandenkommen von SAM? Reicht hierzu der Eintrag in der Sperrliste? Müssen hierfür neben der Meldung über den Verbundtransfer noch weitere Meldewege/Verfahren definiert werden? Im ersten Migrationsschritt bleibt es beim Eintrag in der Sperrliste Wird die Nachbeschaffung von Chipkarten jeweils durch das KC EFM/den Verbund koordiniert oder lassen sich künftig direkte Bestellungen der VU

25 Seite 25 durchführen? Sind die Verfahren für die Abstimmung mit der VDV KA GmbH & Co KG zur Produktion weiterer KA-Karten schon definiert; falls nicht, wann erfolgt dies? Ziel der koordinierten Beschaffung war ein möglichst niedriger Preis der Chipkarte auf Grund einer großen Bestellmenge. Wenn sich zukünftig mehrere KA-Chipkarten-Hersteller am Markt etabliert haben, die diese Karte als gängiges Produkt anbieten, ist es durchaus denkbar, dass die VU die Bestellung direkt durchführen. Hierzu würde das KC EFM in Abstimmung mit der VDV KA GmbH & Co KG eine Art Leitfaden zur Verfügung stellen Wie kann die Neu-/Ersatzbeschaffung von SAM sichergestellt werden, wenn im Voraus Ende-Gültigkeiten der SAM s definiert werden. Ist hier die VDV KA GmbH & Co KG zuständig? Wird die Neubeschaffung von SAM jeweils durch das KC EFM/den Verbund koordiniert? Die SAM s werden nach derzeitigem Stand nur durch die VDV KA GmbH & Co KG ausgegeben. Somit kann der Beschaffungsprozess leicht standardisiert werden. Das KC EFM strebt auch hier an, in Abstimmung mit der VDV KA GmbH & Co KG eine Art Leitfaden zur Verfügung zu stellen Werden für die zur Zeit laufende Erstbeschaffung aller beteiligten Verbünde (VRR, VRS und VGN) identische Schlüssel verwendet oder sind in einem SAM mehrere Schlüssel aller Kartentypen hinterlegt? In einem SAM können mehrere Schlüssel hinterlegt werden, so dass auch bei mehreren Verbünden (Produktverantwortlichen) nur 1 SAM erforderlich ist Müssen bei einem Kontrollvorgang auch die Kommandos Validate Transaction zum SAM und Send Receipt zum Nutzermedium verwendet werden? Bei der Realisierung der Kontrolle der Elektronischen Tickets in der VGN sowie im VRR und VRS sind die Kommandos Validate Transaction zum SAM und Send Receipt zum Nutzermedium nicht erforderlich. Diese Kommandos werden laut Spezifikation bei Produkten eingesetzt, die noch eine Konkretisierung der Gültigkeit benötigen also z.b. Check-In-Verfahren oder zu entwertende Elektronische Tickets. Dies ist bei den jetzt aktuellen Produkten in der VGN sowie im VRR und VRS nicht der Fall, da alle kontrollrelevanten Daten bei Ausgabe des Elektronischen Tickets eingebracht worden sind. Demzufolge sind in den produktiven Kontroll-SAM's auch die Schlüssel MK DL_ERF_MAC und K DL_ERF_MAC nicht vorhanden. Diese können dann später bei Bedarf per LoadKey nachgeladen werden. Die in der Spezifikation erwähnten Kommandos Transaction Request zum SAM und Execute Transaction zum Nutzermedium werden nur dann benötigt, wenn ein Elektronisches Tickets gesperrt werden soll. Im Regelfall werden also nur die Kommandos Get Entitlement zum Nutzermedium und Check Entitlement zum SAM verwendet In welcher Variante ist das Kommando Check Entitlement zum SAM zu verwenden? Das Kommando Check Entitlement zum SAM ist sowohl bei Kontroll- als auch bei Personalisierungsgeräten mit dem Parameter P1= '01' für CiCo-Verfahren durchzuführen. In dieser Form ist dieses Kommando für die Kontrolle von Elektronischen Tickets, wie sie in der VGN sowie im VRR und VRS benutzt werden, zu verwenden. Denn bei diesen Elektronischen

26 Seite 26 Tickets gibt es keinen Kontrollbedarf eines bei der Nutzung erzeugten Erfassungsdatensatzes (Check-In, Entwertung) und keine Erzeugung eines Kontrolldatensatzes zur Weiterleitung ins Hintergrundsystem In welcher Reihenfolge ist das Löschen einer Berechtigung durchzuführen? Beim Löschen von Berechtigungen mit Hilfe der Personalisierungsgeräte darf nicht vergessen werden, vor dem Löschen erst den Transaktionsdatensatz zu erzeugen (siehe auch Kapitel der Spezifikation des Nutzermediums) und dann die Berechtigung aus dem Nutzermedium zu entfernen Wieviele Organisationen können in einem SAM vorhanden sein? Zur Zeit ist es möglich, dass bis zu 20 PV s (Produktverantwortliche z.b. Verbünden) und bis zu 20 KVP s (Kundenvertragspartner z.b. Verkehrsunternehmen) in einem SAM integriert werden können Welcher Unterschied besteht zwischen SAMs der Level 1, 2 und 3 bzw. generell zwischen diesen Ebenen? Funktional besteht zwischen diesen verschiedenen Level kein Unterschied. Die Unterschiede liegen in den verwendeten Daten, das heisst konkret in den verwendeten Org-ID s und Schlüsseln. Die Schlüssel haben generell auch keine anderen Namen. Die Certificate Holder Reference (CHR) ist bei Level 2 und 3 um eine Versionsangabe ergänzt worden, die im Level 1 nicht vorhanden und auch nicht notwendig ist. Der SAM-Betreiber- Aktivierungsschlüssel ist auch im Level 1 vorhanden. Allerdings ist bei diesem bei der CHR im Level 1 eine andere Bezeichnung (Activation statt Activate) vorhanden. Weitere Informationen können auch der unten stehenden Abbildung entnommen werden.

27 Seite Umgang mit (((eticket-fragmenten Wenn beim Schreiben eines (((etickets das Kommando ExecuteTransaction nicht oder nicht korrekt durchgeführt wurde, weil z.b. das Nutzermedium vom Terminal entfernt worden ist, entstehen so genannte Ticketfragemente. Diese Ticketfragemente stellen keine gültigen (((etickets dar, weil bei ihnen die Ausgabetransaktionskennung (Tag 0x99) nicht vorhanden ist. Damit diese Ticketfragemente erkannt werden könnnen, muss die folgende Vorgehensweise eingehalten werden, die auch sinngemäß in die Systemlastenhefte der VDV- Kernapplikation eingearbeitet wird: Beim Schreiben der Berechtigung (z.b. mit PutData) ist als Status erst 0 (undefiniert) einzutragen. Erst mit ExecuteTransaction ist der Status auf 7 (OK) zu ändern. Somit ist sichergestellt, dass eine gültige Berechtigung (Status = 7) auch die entsprechende SAM- Angaben enthält. Berechtigungen, die den Status 0 haben, können vom (KVP-)Terminal (z.b. mit PutData) einfach gelöscht werden. Ein Transaktionsdatensatz wie beim normalen Löschen muss nicht gebildet werden. Dies gilt auch für Berechtigungen, die nicht die entsprechenden SAM-Angaben im Tag 0x99 haben. 8 Migration zur VDV-Kernapplikation - Kontroll-(Lese-)geräte und zugehörige Schnittstellenbeschreibung Die Antworten auf die Fragen in den vorherigen Kapiteln gelten sinngemäß soweit möglich auch für die Migration zur VDV-Kernapplikation, sofern nicht bei den folgenden Fragen anders geantwortet wird. Bei Unklarheiten bitten wir, entsprechend nachzufragen.