Migration zur VDV-Kernapplikation

Transkript

1 Seite 1 Migration zur VDV-Kernapplikation Aufbau des NRW-KA-EFS und Konvertierungsregeln C:\Dokumente und Estellungen\merten\temp\Aufbau des NRW-KA-EFS und Konvertierungsregeln_1_8.doc

2 Seite 2 0 Allgemees 0.1 Inhaltsverzeichnis Kapitel Seite 0 Allgemees Inhaltsverzeichnis Änderungsverzeichnis Eleitung Defition des NRW-KA-EFS Konvertierungsregeln Luhn-Algorithmus Referenzen Änderungsverzeichnis Die Version 1_8 unterscheidet sich von der Version 1_7 durch die folgenden Änderungen: Fußnote 9: Kapitel 5: Der zweite Nummernkreis des VRS geht bedgt durch die Aufnahme des NRW-Tarifes nun bis Die Referenzen wurden aktualisiert. C:\Dokumente und Estellungen\merten\temp\Aufbau des NRW-KA-EFS und Konvertierungsregeln_1_8.doc

3 Seite 3 1 Eleitung Ab Anfang 2003 haben die Verkehrsunternehmen im VGN/VRR/VRS ihre Abonnement- Tickets auf elektronische Fahrschee umgestellt. Als Trägermedium für den Kunden dient ee Prozessor-Chipkarte mit dem Datenmodell EFS-Manager ÖPV des VDV. Zum Start des elektronischen Fahrgeldmanagements im VGN/VRR/VRS und der Folgezeit wurden sgesamt circa drei Millionen Chipkarten beschafft. Die Verkehrsunternehmen haben nun die Weiterentwicklung des bestehenden Systems gefordert. Um dieser Forderung gerecht zu werden, hat das KC EFM für die jetzt anstehende Chipkartenausschreibung die verschiedenen Möglichkeiten untersucht. Als zu erfüllender technischer Standard für die Ausschreibung wurde die VDV-Kernapplikation gewählt, weil nur die Anwendung ees allgemeen offenen (und damit für alle Hersteller zugänglichen) Standards als Rahmenbedgung für ee Ausschreibung vergaberechtlich zulässig ist und zugleich langfristig das technische Zusammenspiel (Kompatibilität) mit dem Gesamtsystem sichert. Der ezige derzeit verfügbare Standard dieser Art ist die VDV-Kernapplikation. Als Konsequenz aus dieser Entscheidung ist unter Beachtung der Vorgaben der VDV- Kernapplikation e regional verwendeter Elektronischer Fahrsche zu defieren (NRW-KA- EFS). Dies ist erforderlich, da der sogenannte Referenz-EFS (Beispiel-EFS) der VDV- Kernapplikation für die Verkehrsunternehmen Nordrhe-Westfalen, die zur Zeit een Elektronischen Fahrsche esetzen, auf Grund der umgesetzten Tarife und der für die automatische Prüfung der räumlichen Gültigkeit erforderlichen Angaben nicht geeignet ist. Darüber haus sd die zur Zeit verwendeten Daten die Datenformate der VDV- Kernapplikation zu konvertieren. In dem vorliegenden Dokument wird zum een der NRW-KA-EFS defiert und zum andern werden die Konvertierungsregeln zwischen dem NRW-EFS und dem NRW-KA-EFS aufgestellt. Dieses Dokument ist, um die Interoperabilität Nordrhe-Westfalen zu gewährleisten, zwgend zu beachten. 2 Defition des NRW-KA-EFS Die Verbünde Nordrhe-Westfalen verwenden zur Zeit ee eheitliche Struktur bei dem Format, dem die Elektronischen Tickets auf der Chipkarte gespeichert werden. Diese Struktur wird als NRW-EFS bezeichnet. Näheres hierzu kann [1] entnommen werden. Die Strukturen, die bei den Elektronischen Tickets der VDV-Kernapplikation verwendet werden und die eige Datenfelder aus dem NRW-EFS behalten, können unter anderem im Detail [2] und [3] entnommen werden. Abweichend von den [2] defierten Strukturen des Referenz-EFS gelten für den so genannten NRW-KA-EFS der Ausprägung für die Abonements die folgenden Defitionen, die die übrigen Datenfelder aus dem NRW-EFS behalten: C:\Dokumente und Estellungen\merten\temp\Aufbau des NRW-KA-EFS und Konvertierungsregeln_1_8.doc

4 Seite 4 Datenelement Wert Codierung Länge Tag Separate Daten Berechtigung Statischer produktspezifischer Teil Länge Separate Daten Berechtigung NRW- KA-EFS Statischer produktspezifischer Teil 0x85 Octet Strg(SIZE(1)) 1 variabel 1 Octet Strg(SIZE(1)) 1 bererstellungszeitpunkt DateTimeCompact 4 berlaengeticketteil_nrw (1. Hälfte vor dem ) berticketteil_nrw (1. Hälfte vor dem ) variabel 2 Octet Strg(SIZE(1)) 1 PrtableStrg( 2 ) variabel 2 kundegeschlecht 3 Geschlecht_CODE 1 kundegeburtsdatum 3 Datef 4 Datenelement Wert Codierung Länge Tag Transaktion Produktspezifischer Teil 0x8a Octet Strg(SIZE(1)) 1 Länge Transaktion Produktspezifischer Teil NRW-KA-EFS 0x00 Octet Strg(SIZE(1)) 1 Datenelement Wert Codierung Länge Tag Infotext 0xc7 Octet Strg(SIZE(1)) 1 Länge Infotext 0x00 Octet Strg(SIZE(1)) 1 Die Datenelemente Transaktion Produktspezifischer Teil und Infotext werden also nicht genutzt. Bei den oben beschriebenen Abweichungen vom Referenz-EFS der VDV-Kernapplikation handelt es sich um erlaubte Abweichungen. Der Referenz-EFS ist nichts anders als e Beispiel für een EFS. Um alle denkbaren Tarife abbilden zu können, sieht die VDV- Kernapplikation ausdrücklich vor, dass jeder Produktverantwortliche przipiell für jedes Produkt den Statischen produktspezifischen Teil und den Transaktion Produktspezifischen Teil selbst defieren muss sofern er nicht den Referenz-EFS verwenden kann. Darüber haus kann zum Zweck der Kundenformation das Datenelement Infotext genutzt werden. 3 Konvertierungsregeln C:\Dokumente und Estellungen\merten\temp\Aufbau des NRW-KA-EFS und Konvertierungsregeln_1_8.doc Die folgende Tabelle zeigt, wie die Daten des NRW-EFS und des NRW-KA-EFS zu konvertieren sd. Es sd die Konvertierungsregeln für alle benötigten Daten aufgelistet. Je nach Art der Implementierung eem Termal oder Htergrundsystem kann es aber se, dass nicht alle Regeln angewendet werden müssen. Bei eigen Daten sd die vorhandenen Die Länge hängt von der Größe des Ticketteils und dem Vorhandense von Geschlecht und Geburtstag ab. Die Länge hängt von der Größe des Ticketteils ab. Die Felder Geschlecht und Geburtstag existieren nur Elektronischen Fahrscheen, die im Ticketteil vor dem auch das Feld Name enthalten.

5 Seite 5 Unterschiede je nach Konvertierungsrichtung zu beachten. Die Basis der Tabelle ist das Datenformat, dass zur Zeit an die Scheidt&Bachmann-DLL übergeben wird. Das Feld Verfallszeitpunkt wird, da es zum een beim zur Zeit verwendeten Datenmodell EFS- Manager ÖPV nur dem Speichermanagement dient und zum andern aus dem Ende der Gültigkeit abgeleitet werden kann, ebenso nicht konvertiert wie die Felder Fahrpreis, ZD-Info und Haltestelle, die gar nicht genutzt werden. Es müssen zusätzlich die folgenden Daten für den NRW-KA-EFS generiert werden: berechtigungnummer Beim Esatz des Konverters gemäß [4] muß beim Schreiben eer Berechtigung Form ees Elektronischen Tickets diese bei auf (0xFFFFFFFF) gesetzt werden, um zu erkennen, dass es sich um e Ticket handelt, dass mit der NRW-Sperrliste abzugleichen ist. Es wird jedoch empfohlen, auch beim Esatz des Konverters durch ee entsprechende Anpassung des Htergrundsystems ee edeutige berechtigungnummer ezutragen, um bei Esatz der KA-Sperrliste een Parallelbetrieb von zwei Sperrlisttypen zu vermeiden. Bei der Anpassung des Htergrundsystems gemäß [5] muss bereits ee berechtigungnummer gemäß [2] egetragen werden. Diese Nummer kann dann zusammen mit weiteren Datenelementen bei eer späteren Migration zu eer KA-konformen-Sperrliste zur Identifizierung eer zu sperrenden Berechtigung Form ees Elektronischen Tickets verwendet werden. Hierzu ist der Verzeichnisteil eer Berechtigung, der die entsprechenden Datenelemente enthält, im Htergrundsystem zu speichern. Der Vorteil liegt dar, dass dadurch die NRW-Sperrliste schneller auslaufen kann, dem diese Berechtigungen von der NRW-Sperrliste auf die KA-konforme Sperrliste gesetzt werden. prodkeyorganisation_id Hier kommt die Nummer der Region zum Tragen, deren Schlüssel für Erfassung und Kontrolle verwendet werden muss. Beim NRW-KA-EFS ist die ID des Erfassungsbereiches WEST (dezimal) bzw. 0x170E (hexadezimal) ezutragen. bergueltigkeitsbegn Beim Esatz des Konverters ist dieses Feld aus der ersten Hälfte des Feldes Gültigkeit im Ticketteil bis '-' (Bdestrich) zu generieren (Uhrzeit auf 00:00:00) und die Jahresangabe mit Hilfe des Feldes Verfallsdatums ergänzen. Bei der Anpassung des Htergundsystems ist dieses Feld direkt vom Htergrundsystem zu füllen. bergueltigkeitsende C:\Dokumente und Estellungen\merten\temp\Aufbau des NRW-KA-EFS und Konvertierungsregeln_1_8.doc Beim Esatz des Konverters ist dieses Feld aus der zweiten Hälfte des Feldes Gültigkeit im Ticketteil nach '-' (Bdestrich) zu generieren (Uhrzeit auf 23:59:58) und die Jahresangabe mit Hilfe des Verfallsdatums ergänzen. Bei der Anpassung des Htergundsystems ist dieses Feld direkt vom Htergrundsystem zu füllen. bersynchronnummer Beim Schreiben eer Berechtigung Form ees Elektronischen Tickets muß diese auf 1 gesetzt werden.

6 Seite 6 Elektronischer Fahrsche Nordrhe-Westfalen (NRW-EFS) Feld Inhalt Codierung Länge Chipkartennummer XXX...XXX BCD Konvertieren 15 4 Verfallsdatum der Chipkarte Aktivierungsdatum der Chipkarte Verfallsdatum des SAM s Aktivierungsdatum des SAM s Konvertierungsrichtung VDV-Kernapplikation konformer NRW-KA-EFS Datenelement Codierung Länge Die ersten 8 Dezimalstellen (4 ) sd nach Organisation_ID.organisationsN ummer zu konvertieren. Die Dezimalstellen 9 bis 18 (5 ) sd nach NmAppInstanznummer zu konvertieren. JJMM BCD 2 Konvertieren (Höchste Stellen des Jahresangabe ergänzen, Tag ist letzter Tag des Monats, Uhrzeit ist 23:59:58) JJMMTT BCD 3 Konvertieren (Höchste Stellen des Jahresangabe ergänzen, Uhrzeit ist 00:00:00) Konvertieren Die NmAppInstanznummer ist gegebenenfalls unter Hzufügen von führenden Nullen die Dezimalstellen 9 bis 18 (5 ) zu konvertieren. Die Organisation_ID.organisationsN ummer ist unter Hzufügen von führenden Nullen die ersten 8 Dezimalstellen (4 ) zu konvertieren. Konvertieren (Höchste Stellen der Jahresangabe, Tag und Uhrzeit entfallen) Konvertieren (Höchste Stellen der Jahresangabe und Uhrzeit entfallen) JJMMTT BCD 3 Konvertieren (Tag entfällt) Konvertieren (Tag ist letzter Tag des Monats) NmAppInstanznummer 5 Organisation_ID.organi sationsnummer 5 ReferenceNumber Four ReferenceNumber Two appgueltigkeitsende DateTimeCompact 4 appgueltigkeitsbegn DateTimeCompact 4 SAM- Identifikation.Verfalldat um des SAM JJMMTT BCD 3 1:1 1:1 SAM- Identifikation.Gültigkeit sbegn des SAM 4 2 BCD 2 BCD Die jetzt festgelegte Regel zur Konvertierung von Chipkartennummer sowie NmAppInstanznummer und Organisation_ID.organisationsNummer hat Auswirkungen auf die Materialverwaltung. Bitte beachten Sie die entsprechenden Hweise den Dokumenten Rahmenlastenheft Anpassung Htergrundsystem und Rahmenlastenheft Konverter jeweils ab Version 1_1. Ist Bestandteil des übergeordneten Datenelementes NmApplikationInstanz_ID (siehe Spezifikation des Nutzermediums).

7 Seite 7 Elektronischer Fahrsche Nordrhe-Westfalen (NRW-EFS) Feld Inhalt Codierung Länge Verfallszeitpunkt JJJJMMTTHHMM BCD 6 Kee Konvertierung, nur Prüfung, ob Inhalt gemäß 6 Betreiber-ID Servicekennung Kennung des ausgebenden VUs Codierung des Tickettyps Konvertierungsrichtung VDV-Kernapplikation konformer NRW-KA-EFS Datenelement Codierung Länge sonst Fehler Kee Konvertierung, aus bergueltigkeitsende gemäß 6 berechnen HEX 2 1:1 1:1 Organisaton_ID.organi sationsnummer 7 HEX 3 ReferenceNumber Two Servicekennung produktnummer produktnummer 8 ReferenceNumber Two Wenn VGN-Nummernkreis(e) 9, dann 151 Wenn VRR-Nummernkreis(e) 9, dann 70 Wenn VRS-Nummernkreis(e) 9, dann 102 Kee Konvertierung Fahrpreis EEEEEECC BCD 4 Kee Konvertierung Auf setzen Erstellzeitpunkt JJJJMMTTHHMM BCD 6 Konvertieren (Sekunden auf Null) Organisation_ID.organi sationsnummer 8 ReferenceNumber Two Konvertieren (Sekunden entfallen) bererstellungszeitpunkt DateTimeCompact Als Verfallszeitpunkt ist vom VU-Htergrundsystem der achte Tag nach Ablauf der Gültigkeit des Elektronischen Tickets 00:00 Uhr ezutragen. Zum Beispiel hat der Ablauf der Gültigkeit am den Verfallszeitpunkt :00 zur Folge. Ist Bestandteil des übergeordneten Datenelementes Berechtigung_ID (siehe Spezifikation des Nutzermediums). Ist Bestandteil des übergeordneten Datenelementes EFMProdukt_ID (siehe Spezifikation des Nutzermediums). Zur Zeit sd die Nummernkreise bis der VGN, bis dem VRR sowie bis und bis dem VRS zugeordnet.

8 Seite 8 Elektronischer Fahrsche Nordrhe-Westfalen (NRW-EFS) Feld Inhalt Codierung Länge Entwertungszähler Zählerstand HEX 1 0xFE 7 dez (OK) und 0xFF 19 dez (Blocked) gemäß EN1545-1, Kapitel Status Code konvertieren, ansonsten Fehler Länge ZD-INFO ZD-INFO Länge Ticketteil Ticketteil 1. Hälfte vor dem Länge des Feldes ZD-INFO Entwertungsmerkma l Länge des Feldes Ticketteil Tickettyp/Preisstufe/ Gültigkeit/Zusätze/ Name/Bemerkungen Konvertierungsrichtung VDV-Kernapplikation konformer NRW-KA-EFS Datenelement Codierung Länge HEX 1 Kee Konvertierung, wenn!= 1, dann Fehler HEX 255 Kee Konvertierung, wenn!= 0 Fehler 7 dez (OK) 0xFE und 19 dez (Blocked) 0xFF gemäß EN1545-1, Kapitel Status Code konvertieren, ansonsten Fehler Kee Konvertierung, auf 1 setzen Kee Konvertierung, auf 0 setzen HEX 1 Kee Konvertierung Aus der Länge der Datenelemente des Ticketteils ermitteln ASCII siehe Fußnote 10 Trenner '@' (Klammeraffe) ASCII 1 Kee Konvertierung '@' (Klammeraffe) setzen berstatus Octet Strg(SIZE(1)) 1:1 11 1:1 berticketteil_nrw PrtableStrg ( 10 ) siehe Fußnote Die Länge hängt von der Größe des Ticketteils ab. 11 Die Gesamtlänge der 1. Hälfte vor dem also auch letztendlich die Länge des Datenelementes berticketteil_nrw darf 85 Byte nicht überschreiten. Er ist also wie bisher aufzubauen (siehe auch [1]).

9 Seite 9 Elektronischer Fahrsche Nordrhe-Westfalen (NRW-EFS) Feld Inhalt Codierung Länge Termal- (SAM-)ID Konvertierungsrichtung VDV-Kernapplikation konformer NRW-KA-EFS Datenelement Codierung Länge XXX...XXX 12 BCD Konvertieren Konvertieren SAM_ID.samNummer 18 ReferenceNumber Three 3 Laufende Nummer SAM-Zählerstand 19 HEX 3 1:1 1:1 (Höchstwertiges Byte entfällt) SamSequenznummer 18 SequenceNumber Four 4 Haltestelle 0x HEX 4 Kee Konvertierung Auf 0x setzen Geschlecht 'M', 'W' oder 0x00 (optional, nur falls Feld Name vorhanden) HEX 1 'M' 0x01, W' 0x02 und 0x00 0x00 gemäß EN1545 konvertieren, ansonsten Fehler 0x01 'M', 0x02 W' und 0x00 0x00 gemäß EN1545 konvertieren, ansonsten Fehler kundegeschlecht Geschlecht_COD E 1 12 Die Termal-(SAM-)ID wird vom SAM egetragen. Das VU-Htergrundsystem trägt hier erst emal Nullen e. 13 Das letzte Halbbyte ist HEX-codiert. 14 Da das VU-Htergrundsystem hier erst emal Nullen eträgt, gibt es kee Probleme wegen des möglichen Größenbereiches. 15 Die beiden letzten Halbbytes (Prüfziffer und Füllzeichen) entfallen. 16 Bei der Umwandlung ist das letzte Halbbyte auf Null zu setzen (Füllzeichen). 17 Die Prüfziffer ist gemäß Kapitel 4 zu berechnen (vorletztes Halbbyte). 18 Ist Bestandteil des übergeordneten Datenelementes Ausgabetransaktionskennung (Struktur NM_Transaktion_ID, siehe Spezifikation des Nutzermediums). 19 Die Laufende Nummer wird vom SAM egetragen. Das VU-Htergrundsystem trägt hier erst emal Nullen e. 20 Die SamSequenznummer darf wegen der Größe der Laufenden Nummer maximal ee Größe von (0xFFFFFF) haben. 21 E Überlauf der SamSequenznummer bzw. der Laufenden Nummer muß vom VU-Htergrundsystem verwaltet werden.

10 Seite 10 Elektronischer Fahrsche Nordrhe-Westfalen (NRW-EFS) Feld Inhalt Codierung Länge Geburtstag TTMMJJ oder 0x (optional, nur falls Feld Name vorhanden) Konvertierungsrichtung VDV-Kernapplikation konformer NRW-KA-EFS Datenelement Codierung Länge BCD 3 konvertieren, Tausender- und Hunderter-Stelle der Jahreszahl ist Null 22 konvertieren, Tausender- und Hunderter-Stelle der Jahreszahl entfallen 23 kundegeburtsdatum Datef 4 22 Bei Anpassung des Htergrundsystems kann das Datum auch gleich im Zielformat mit kompletter Jahresangabe geliefert werden. 23 Bei entsprechender Anpassung von Htergundsystem oder Kontrollgerät kann das Datum auch mit kompletter Jahresangabe verarbeitet werden.

11 Seite 11 4 Luhn-Algorithmus Die letzte Ziffer, d.h. das vorletzte Halbbyte eer Chipkarten- oder SAM-Nummer stellt ee Prüfziffer dar, die aus der eigentlichen 18-stelligen Nummer nach dem "Luhn mod 10"- Algorithmus errechnet wird. Der Algorithmus funktioniert wie folgt: 1. Von der ganz rechten Zahl der Chipkarten- oder SAM-Nummer (ohne Prüfziffer) ausgehend wird jede zweite Zahl mit 2 multipliziert. 2. Alle so erhaltenen Zahlen klusive der nicht multiplizierten werden ihrer direkten Reihenfolge addiert. 3. Das Ergebnis wird von der nächsthöheren Zahl, die auf 0 endet, subtrahiert (modulo 10). 4. Das Ergebnis stellt die Prüfziffer dar. Beispiel anhand der Chipkartennummer (ohne Prüfziffer): *2 *2 *2 *2 *2 *2 *2 *2 * = = 2 Die komplette 19-stellige Chipkartennummer mit Prüfziffer lautet somit Referenzen Bei den Referenzen sd die zum Zeitpunkt der Erstellung dieses Dokumentes aktuellen Versionen angegeben. Letztendlich sd aber die zum Zeitpunkt der Realisierung aktuellen Versionen verbdlich. [1] Esatz von Chipkarten und Sicherheitsmodulen, VRR-Richtlie, Version 1_4, VRR GmbH [2] VDV-Kernapplikation, Spezifikation Nutzermedium, Version [3] VDV-Kernapplikation, KA SST-SPEC - Schnittstellenspezifikationen der Referenzsysteme - Kundenvertragspartner (KVP) - Dienstleister (DL) - Produktverantwortlicher (PV) - Applikationsherausgeber (AH) - Kontrollservice (KOSE), Version [4] Migration zur VDV-Kernapplikation, Rahmenlastenheft Konverter, Version 1_1, KompetenzCenter Elektronisches Fahrgeldmanagement NRW C:\Dokumente und Estellungen\merten\temp\Aufbau des NRW-KA-EFS und Konvertierungsregeln_1_8.doc [5] Migration zur VDV-Kernapplikation, Rahmenlastenheft Anpassung Htergrundsystem, Version 1_1, KompetenzCenter Elektronisches Fahrgeldmanagement NRW