[Seite 1]
[RMV KA 1.3.0 inkl. Multiberechtigung im eTicket
RheinMain]
Kurztitel: RMV KA 1.3.0 MBER
Version: 1.3
erarbeitet für:
RMV
vorgelegt am 18.12.2017 aktualisiert am 07.09.2023 durch:
Rhein-Main-Verkehrsverbund Servicegesellschaft mbH (rms GmbH) Am Hauptbahnhof 6 60329 Frankfurt am Main
[Seite 2]
Änderungsnachweis
| Version | Stand | Bearbeiter | Änderungen | Bemerkungen |
|---|---|---|---|---|
| 1.0 | 18.07.2016 | C. Gumbert | Erstversion | |
| 1.1 | 18.12.2017 | C. Gumbert | Kap.“1.1.1 MB.Modus“: Konkretisierung (optiona- le Änderung). Kap. „1.1.2 MB.Keyregister“: Konkretisierung (Option bei Drucker-Einstiegskontrolle). Kap. „1.1.4 MACTR.Stichtag“ und Kap. „2 MAC TR Bildung und Validierung“: Änderung der Vor- gehensweise zur Transaktionsausführung ab 1.1.2018 Kap. „4 KA 1.3.0 + CRs“: Ergänzung um „Ab- stimmung mit RMV (/rms)“. Kap. „5 Offene Punkte“ gelöscht. Wenige Fehlerkorrekturen. | |
| 1.2 | 21.01.2020 | C. Gumbert, S. Fuhrmann | Verteilerliste gelöscht Alle den „Migrationspfad“ beschreibende Prozes- se sowie das Kapitel Rollout wurden dem Doku- ment entnommen, da das MBER-Verfahren seit Q1 2020 im eTRM flächendeckend aktiv ist. Parameter „MACTR.Stichtag“ ist nun nicht mehr relevant. Das Kapitel 3 „Integration“ wurde hinzugefügt mit Verweis auf den erforderlichen Integrationstest und die Testfälle. | |
| 1.3 | 07.09.2023 | C. Gumbert, S. Fuhrmann | Anpassung Kapitel „1 PV - RMV - Regeln zum Multiberechtigungsverfahren“ auf aktuell im Be- trieb relevante Regeln und Anforderungen. Entfall folgender Kapitel: „1.1 ff. Regeln aus der Konfigurationsdatei“, „1.2 ff. Konfigurationsdatei RMV_KA130_MBER“, „1.3 Kommunikation, Umsetzung und Wirksam- keit“ und „3.3 Aktivmodus und Passivmodus“. Entfall Anlage 1 (Konfigurationsdatei). |
[Seite 3]
Inhaltsverzeichnis Seite
1 PV - RMV - Regeln zum Multiberechtigungsverfahren 1
2 MAC TR Bildung und Validierung 1
3 Integration 2 3.1 Anbindung vHGS-Schnittstelle 2 3.2 Integrationstest 2
4 KA 1.3.0 + CRs 2
[Seite 4]
1 PV - RMV - Regeln zum Multiberechtigungsverfahren Nachdem die Migration des MBER-Verfahrens durchgeführt wurde und dieses im eTicket RheinMain (eTRM) flächendeckend seit mehreren Jahren im praktischen Einsatz ist, sind nicht mehr benötigte Konfigurations-Anforderungen und Regeln zum Einsatz des Multiberechtigungsverfahrens im laufenden Betrieb entfallen. Im Folgen- den Abschnitt werden die aktuell geltenden Regeln/Anforderungen beschrieben.
Im Zuge der Nutzung ab KA-Version 1.3.0 ist das MBER-Verfahren zur Ausgabe von EFS im eTRM des RMV über alle EFM-Produkte anzuwenden. Das Aktionsmanagement ist im gesamten eTicket RheinMain und über alle Ver- triebskanäle an allen Gerätetypen anzuwenden.
Wird bei einer Ausgabe im MBER-Verfahren festgestellt, dass das Schlüsselregister des Nutzermediums (NM) noch nicht befüllt ist bzw. fehlen erforderliche Schlüssel zur Anwendung des MBER-Verfahrens und lassen die technischen Voraussetzungen des NM1 ein Befüllen bzw. Bearbeiten zu, soll das Schlüsselregister vor der MBER- Ausgabe befüllt bzw. bearbeitet werden.
Die Bearbeitung des Schlüsselregisters sowie die Ausgabe im MBER-Verfahren sind auch auf NM anzuwenden, deren Applikation durch einen anderen KVP als den RMV (36) ausgegeben wurde („RMV-fremdes“ NM bzw. sogenanntes „Fremd-NM“). Gleichermaßen gilt dies für die Ausgabe von interoperablen Produkten, wie bspw. das Deutschland-Ticket.
Fehlende Schlüssel werden in das Schlüsselregister des NM eingebracht bzw. hin- zugefügt. Bei Platzmangel werden Schlüssel, die zum Zeitpunkt der Ausgabe nicht benötigt werden, gelöscht, um so Platz zu schaffen für das Hinzufügen der erforderlichen Schlüssel. Dies gilt gleichermaßen bei „Fremd-NM“. Grundsätzlich soll das Terminal während der Gesamtdauer des Vorgangs zur Bear- beitung des NM-Schlüsselregisters am Display darüber informieren - bspw. anhand einer Sanduhr oder/und Textinformation „Bearbeitung Schlüsselregister“. Eine erfor- derliche Wartezeit soll erkennbar und das Risiko des personenbedingten Abbruchs minimiert werden. Bei einem Abbruch soll über diesen sowie den Nichterfolg der durchzuführenden Ak- tivität informiert werden.
2 MAC TR Bildung und Validierung Seit 1.1.2018 gelten zur Transaktionsausführung und zur Validierung einer MAC TR die Regeln:
1 Vor der Bearbeitung des Schlüsselregisters sowie der Ausgabe von Berechtigungen im MBER- Verfahren soll das NM auf dessen Tauglichkeit (bspw. erforderliche KA-Version) überprüft werden.
RMV_KA130_MBER.docx; Stand 07.09.2023, Version 1.3 Planung • Beratung • Service Seite 1
[Seite 5]
• Die MACTR wird konform der Verfahrensanweisung „ANW_Nutzung TR_KEY_V130“ gebildet. • Die Prüfung der MACTR ist abzuschalten. Im Rahmen der Kontrolle ist das Kommando SAM.CHECK ENTITLEMENT mit dem Parameter P1 = 01 („Mit Prüfung der Reihenfolge der Transaktionsverarbeitung (Vorgänger- Kommando ist GET CHALLENGE).“ ohne MACTR Prüfung zu verwenden. Dies gilt bis zu einem Stichtag, der vom RMV/der RMS bekannt gegeben wird, wonach die Prüfung wieder konform nach der Verfahrensanweisung „ANW_Nutzung TR_KEY“ gebildet werden muss.
3 Integration
3.1 Anbindung vHGS-Schnittstelle Das vHGS bedient die HGS an seiner Schnittstelle nach KA v1.3.0.
Die Zugangsdaten werden, in der Gerätehersteller spezifischen Tabelle „jjjjmmtt_Hersteller-TMS-ORG-Integration.xls“ auf der Informationsplattform vHGS- üfB“ (SharePoint-Server der rms) bereitgestellt.
3.2 Integrationstest Die produktive Nutzung eines HGS auf KA v1.3.0 mit Einsatz des MBER-Verfahrens kann nur nach erfolgreich durchgeführtem Integrationstest und der Freigabe dessen durch den RMV (rms) erfolgen. Dieser wird gemeinsam mit dem VU sowie der rms geplant und durchgeführt.
Die Testfälle leiten sich aus der Tabelle „Testprotokoll“ der Anlage 25 ab und sind mit dem RMV (rms) abzustimmen.
4 KA 1.3.0 + CRs KA 1.3 - Optionen, die mit KA 3.0 verpflichtend werden, sollen aus Gründen der In- vestitionssicherheit bereits bei diesem Rollout mit umgesetzt werden.
Diese sind in der Kategorie 2 „Korrekturen“: • CR 133: Korrektur der Größenangaben des VDV-Barcode-Symbols gemäß ISO/IEC 24778:2008 E (Barcode bei HandyTicket) • CR 135: Korrektur von Anwendungsfällen zur Ausgabe der Applikation • CR 139: Konkretisierung der Vorgehensweise bei abgebrochenen Transaktionen • CR 150: Beseitigen von Inkonsistenzen bei der Behandlung von EFS-Kontrollnachweisen im KVPS • CR 151: Konkretisierung der Nutzung der Berechtigungs-ID und der generellen Abläufe mit dem Nutzermedium (Wiederverwendung von Berechtigungs-IDs) • CR 155: Verzicht auf SECCOS (hieraus entsteht kein ToDo, nur zur Info)
RMV_KA130_MBER.docx; Stand 07.09.2023, Version 1.3 Planung • Beratung • Service Seite 2
[Seite 6]
• CR 165: Erweiterung des KVPT Kundenservice in Bezug auf Löschen des Applikationslogbuches (Löschen des App-Logbuches auf Kundenwunsch) • CR 168: Fehlende Anwendungsfälle im PVS/KVPS ergänzen: PVS: SAM_Ausgabe registrieren PVS: BER_Rückgabe melden KVPS: BER_Rücknahme entgegennehmen, und in der Kategorie 3 (optionale Serviceerweiterungen)“: • CR 146: Zusätzlicher Validation Code (abweichender Transportmit- teltyp-Code).
Details, Abweichungen und eine Konkretisierung zu den jeweiligen CRs sind mit dem RMV (rms) abzustimmen und festzulegen.
RMV_KA130_MBER.docx; Stand 07.09.2023, Version 1.3 Planung • Beratung • Service Seite 3