Distribution von etickets über das Internet. d(((eti

Transkript

1 G:\KCEFM\Projekte\d(((eti\Ausschreibung\Ausschreibungsunterlagen\Leistungsbeschreibung d(((eti 1_0.docG:\KCEFM\Projekte\d(((eti\Ausschreibung\Leistungsbeschreibung\Leistungsbeschreibung d(((eti 0_1.doc ) Distribution von etickets über das Internet d(((eti Leistungsbeschreibung

2 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 2 1 Allgemeines 1.1 Inhaltsverzeichnis Kapitel Seite 1 Allgemeines Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Abkürzungen Glossar Vorstellung des Auftraggebers: VRR und KCEFM Verkehrsverbund Rhein-Ruhr Kompetenzcenter elektronisches Fahrgeldmanagement (KCEFM) Projektbeschreibung Umfeld: Vertrieb und Elektronisches Fahrgeldmanagement Motivation Warum d(((eti? Gründe für die Realisierung als Open-Source-Software Funktion Erläuterung der drei Arbeitspakete Technische Grundlagen und Rahmenbedingungen Dokumente KA Dokumente KCEFM Allgemeine Beschreibung der Aufgabenstellung Das Rollenmodell der VDV-Kernapplikation Übersicht Systemarchitektur d(((eti Beschreibung des Pakets d(((eti-api Beschreibung des Pakets d(((eti-eticket-viewer Beschreibung des Pakets d(((eti-system Pflichtenheft Rechte an der Software / Veröffentlichung unter Open Source-Lizenz Projektabwicklung Durchführung Projektleiter Auftragnehmer Projektgespräche Protokollführung Mitwirkungsleistungen Testmaterial Abnahmeprüfungen Qualitätssicherung Vorschriften, Richtlinien, Normen Besondere Hinweise Templates, Produkt- und Kontrollmodule Benachbarte Systeme Interoperabilitätsnetzwerk Hinweise zum Datenaustausch zwischen KVPS und KVPT sowie DLS und DLT TestSuite der VDV-Kernapplikation...30

3 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 3 6 Spezifizierung der Software Allgemeine Eigenschaften der d(((eti-software Portabilität Programmierung Benutzbarkeit (usability) und Softwareergonomie Genutzte ISO Schreib-/Lesegeräte d(((eti-api Technische Eigenschaften Umfang der gesamten API-Funktionalität Hinweise zur Schnittstellenspezifikationen der Referenzsysteme [Spec_SST_V1106] und den Systemlastenheften Korrekturen bei den Elementarprozessen in der [Spec_SST_V1106] Korrekturen bei den Anwendungsfällen im Systemlastenheft KVPS [SYSLH_KVPS_V1106] Korrekturen bei den Anwendungsfällen im Systemlastenheft DLS [SYSLH_DLS_V1106] Korrekturen bei den Anwendungsfällen im Systemlastenheft KVPS [SYSLH_KVPS_V1106] hinsichtlich der Weiterleitung der Sperrnachweise ausgehend vom KOSE: Elementarprozesse Anwendungsfälle Anwendungsfälle KVP- und DL-Server Anwendungsfälle KVP-Terminal Schnittstellen Schnittstelle KVPS KVP-Terminal Schnittstelle KOSES - KVPS Schnittstelle AHS KVPS Schnittstelle PVS - KVPS Schnittstelle KVPS KVPS Schnittstelle DLS - KVPS Schnittstelle DLS DL-Terminal Schnittstelle KOSES - DLS Schnittstelle AHS - DLS Schnittstelle PVS - DLS Schnittstelle KVPS DLS Umfang der zwei Entwicklungsphasen d(((eti-eticket-viewer Funktion Bedienung Konfiguration Online-Hilfe Design d(((eti-system Funktion des Gesamtsystems Mögliche Systemarchitektur Automatisch erstellte Protokolle / Logging Kundendaten Berechtigungsdaten Chipkarten- / Nutzermediendaten Bedienung Bedienung durch Endkunden...94

4 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Bedienung durch Vertriebspersonal Bedienung durch die KVP-Verantwortlichen Bedienung durch den DL-Verantwortlichen Bedienung durch Administratoren des d(((eti-servers Hilfetexte in den Programmen Design Installation Installation des d(((eti-servers Installation der Client-Software Dokumentation Allgemeines Dokumentation d(((eti-api Dokumentation d(((eti-eticket-viewer Dokumentation d(((eti-system Installationsanleitung d(((eti-system Administrationshandbuch Handbuch für KVP-Verantwortliche Handbuch für DL-Verantwortliche Handbuch für Vertriebsmitarbeiter Handbuch für Endkunden Lieferumfang Literatur...102

5 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Abbildungsverzeichnis Abbildung 1 d(((eti als eticketserver...14 Abbildung 2 Das VDV-KA-Rollenmodell und d(((eti...18 Abbildung 3 Das d(((eti-system mit Schnittstellen...19 Abbildung 4 Schnittstellen von d(((eti zu anderen KA-Systemen...20 Abbildung 5 Die Hierarchie der d(((eti-nutzer...23 Abbildung 6 Aufteilung der Endzertifikate...34 Abbildung 7 Einstufiges Authentisierungsverfahren...35 Abbildung 8 Zweistufiges Authentisierungsverfahren...35 Abbildung 9 Weiterleitung der Sperrnachweise durch den KOSE...38 Abbildung 10 Mögliche Architektur des d(((eti-systems Tabellenverzeichnis Tabelle 1 Elementarprozesse...39 Tabelle 2 Anwendungsfälle KVP- und DL-Server...40 Tabelle 3 Anwendungsfälle KVP-Terminal...42 Tabelle 4 Anwendungsfälle KVP-Server und -Terminal...44 Tabelle 5 Anwendungsfälle KOSE und KVP-System...48 Tabelle 6 Anwendungsfälle AH und KVP-System...52 Tabelle 7 Anwendungsfälle PV- und KVP-System...56 Tabelle 8 Anwendungsfälle zwischen zwei KVP-Systemen...60 Tabelle 9 Anwendungsfälle KVP- und DL-System...64 Tabelle 10 Anwendungsfälle DL-System und -Terminal...68 Tabelle 11 Anwendungsfällle KOSE und DL-System...71 Tabelle 12 Anwendungsfälle AH-System und DL-System...74 Tabelle 13 Anwendungsfälle PV-System und DL-System...77 Tabelle 14 Anwendungsfälle KVP-System und DL-System...80

6 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Abkürzungen AFB AH AHS API AUTH CA CR d(((eti DL DLS DLT EFM EFS GPL GUI HGS ION JDK KA KCEFM KOSE KOSES KPRIV KPUB KVP KVPS KVPT KVSHA KVSHA LGPL NFC NM ÖPNV OrgID ÖV PKI PV PVS SAM Sub-CA VDV VDV-KA KG VGN VRR VRS VU Automatische Fahrtberechtigung Applikationsherausgeber AH-Server Application Programming Interface Authentisierung Certification Authority Change Request Distribution von etickets über das Internet Dienstleister DL-Server DL-Terminal elektronisches Fahrgeldmanagement elektronischer Fahrschein Gnu Public License graphische Nutzungsoberfläche Hintergrundsystem Interoperabilitätsnetzwerk Java Developement Kit VDV-Kernapplikation Kompetenzcenter elektronisches Fahrgeldmanagement Kontrollservice KOSE-Server Privater Teil eines asymmetrischen Schlüsselpaares Öffentlicher Teil eines asymmetrischen Schlüsselpaares Kundenvertragspartner KVP-Server KVP-Terminal Kreisverkehr Schwäbisch Hall Kreisverkehr Schwäbisch Hall Lesser General Public License Near Field Communication Nutzermedium Öffentlicher Personennahverkehr Organisation-ID Öffentlicher Verkehr Public Key Infrastructure Produktverantwortlicher PV-Server Security Application Module (Sicherheitsmodul) Sub-Certification Authority Verband deutscher Verkehrsunternehmen VDV Kernapplikations GmbH & Co. KG Verkehrsgemeinschaft Niederrhein Verkehrsverbund Rhein-Ruhr AöR Verkehrsverbund Rhein-Sieg Verkehrsunternehmen

7 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Glossar Die Autoren der vorliegenden Leistungsbeschreibung haben Fachsprache der Informationstechnik, des ÖPV-Vertriebs und der VDV-Kernapplikation ausgiebig gebraucht. Dies war notwendig, um ohne sprachliche Brüche auf bestehende und für d(((eti grundlegende Dokumente verweisen zu können. Im Glossar sind alle Worte dieser Fachsprachen erklärt, damit auch Leser, welche im eticketing Deutschland nicht zu hause sind, den Text erfassen können. Applikationsherausgeber Im Rollenmodell der VDV-Kernapplikation räumt der Applikationsherausgeber interessierten Unternehmen das Rechts zur Teilnahme am (((eticket-deutschland (Akkreditierung/Registrierung) ein. Er trägt die Verantwortung für die Systemsicherheit. Berechtigungen Eine Berechtigung ist in der Regel ein Fahrschein (Fahrtberechtigung) auf einem elektronischen Nutzermedium Certification Authority (CA) Im Rahmen der Public Key Infrastructure erstellt ein sogenanntes TrustCenter als Zertifizierungsdienstleister (Certification Authority, CA) Zertifikate und bestätigt damit die Zugehörigkeit eines öffentlichen Schlüssels zum Zertifikatsinhaber. Die CA dient als vertrauenswürdige Instanz. Change Request (CR) Anforderung der Änderung eines normativen technischen Textes. Debian Freies Betriebssystem. Debian verwendet den Linux-Betriebssystemkern, aber die meisten grundlegenden Systemwerkzeuge stammen vom GNU-Projekt. d(((eti Software zur Ausgabe von etickets über das Internet, Verwaltung von Daten für DL- Terminals und Auslesen von KA-Nutzermedien. d(((eti-api Programmbibliothek zur Interaktion verschiedener KA-(Sub)Systeme. d(((eti-server Der Teil des d(((eti-systems, welcher auf dem Rechner des KVP/DL läuft.

8 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 8 d(((eti-system Software zur Ausgabe von etickets über das Internet und zur Datenver- und Entsorgung von DL-Terminals (Prüfgeräten). Zum d(((eti-system gehören der d(((eti-server und die Software auf dem Client-Rechner, welche die Ausgabe von etickets ermöglicht. d(((eti-eticket-viewer Programm zum Auslesen von KA-Nutzermedien und Interpretation der Daten für Fahrgäste und Servicepersonal. Dienstleister Im Rollenmodell der VDV-Kernapplikation ist ein Dienstleister in der Regel ein Verkehrsunternehmen, das zwar Tickets kontrolliert, jedoch nicht selbst vertreibt. Elementarprozess In der Spezifikation der Kernapplikation beschriebene Interaktion zwischen (Teil)Systemen der Kernapplikation. Fedora Fedora ist ein Betriebssystem, basierend auf Linux, das freie und Open-Source-Software enthält. Hintergrundsystem Hintergrundsysteme Halten die Kundendaten vor und regeln das Sperrdatenmanagement ISO In der Norm ISO werden die physikalischen und datentechnischen Eigenschaften der Übertragungsstrecke zwischen Lesegerät und kontaktlosen Chipkarten (PICC) spezifiziert. Es handelt sich dabei um die PICC-Karten mit geringer Reichweite bis zu etwa 15 cm. Diese Chipkarten werden vorwiegend im Ticketing eingesetzt. KOSE Der Kose (Kontrollservice) ist das geplante bundesweite Sperrlistenmanagement der VDV KA KG (siehe: Sperr- und Meldedaten / Sperrnachweise). Der KOSE wird voraussichtlich Mitte 2010 seinen Betrieb aufnehmen. Kundenvertragspartner Im Rollenmodell der VDV-Kernapplikation ist ein Kundenvertragspartner in der Regel ein Verkehrsunternehmen, das neben der reinen Kontrolle auch selbst Tickets vertreibt. NFC-Handy Mobiltelefon, welches über eine NFC-Schnittstelle (Near Field Communication) verfügt, über die Daten auf einer Distanz von bis zu zehn Zentimeter übertragen werden können. Im

9 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 9 ÖPNV finden NFC-Handys derzeit Anwendung beim Handyticket des Rhein-Mainverkehrsverbundes, beim Projekt Touch&Travel der deutschen Bahn, sowie auf einer Pilotstrecke der Österreichischen Bundesbahn. Organisationen Unter Organisationen sind gemäß VDV Kernapplikationin der Regel Verkehrsunternehmen gemeint. Sie werden durch eine spezifische Organisationsnummer, der sog. OrgID gekennzeichnet. Produkte Produkte sind unterschiedliche Ticket, die zu einem Ticketsortiment zusammengefasst werden. Produktverantwortlicher Im Rollenmodell der VDV-Kernapplikation ist ein Produktverantwortlicher in der Regel ein Verkehrsverbund, der ein Ticketsortiment entwickelt. Public Key Infrastructure (PKI) Die PKI ist das Sicherheitssystem der VDV-Kernapplikation. Im Rahmen der Public Key Infrastructure erstellt ein sogenanntes TrustCenter als Zertifizierungsdienstleister (Certification Authority, CA) Zertifikate und bestätigt damit die Zugehörigkeit eines öffentlichen Schlüssels zum Zertifikatsinhaber. Die CA dient als vertrauenswürdige Instanz. Sicherheitsmodul (SAM) Die Sicherheitsmodule enthalten die symmetrischen und unsymmetrischen Schlüssel. Die SAM dienen zur Authentisierung, zur Signatur von Datensätzen und zur Ver- und Entschlüsselung von Kryptogrammen zur Konfiguration der symmetrischen Schlüssel im SAM. Sperr- und Meldedaten / Sperrnachweise Die Sperr- und Meldedaten Enthalten Informationen über gesperrte,bzw. markierte Tickets. Sie werden täglich über eine Sperrliste aus dem Hintergrundsystem in die Kontrollgeräte überspielt. Template Schema für ein Tarifprodukt, welches in einer Berechtigung abgebildet wird.

10 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 10 2 Vorstellung des Auftraggebers: VRR und KCEFM 2.1 Verkehrsverbund Rhein-Ruhr Die Verkehrsverbund Rhein-Ruhr AöR (VRR) ist einer von drei nordrhein-westfälischen ÖPNV-Kooperationsräumen und erstreckt sich vom Niederrhein über das Rhein-Ruhrgebiet bis hinein ins Bergische Land. Die Kooperationsräume sind unter Anderem Aufgabenträger und in dieser Funktion für die Planung, Organisation und Ausgestaltung des öffentlichen Nahverkehrs in den jeweiligen Räumen verantwortlich. Zum Kernverbundgebiet des VRR gehören 27 kommunale Verkehrsunternehmen und fünf Eisenbahnverkehrsgesellschaften an, für die der VRR als Verbundgesellschaft die Tarife entwickelt, die Produkte vermarktet sowie die verbundweite Presse- und Öffentlichkeitsarbeit organisiert. Außerdem wirkt der VRR im Sinne der Fahrgäste auf die Einhaltung der Qualitäts- und Servicestandards bei den Verkehrsunternehmen hin. Der VRR hat seinen Verwaltungssitz in Gelsenkirchen, der Sitz der VRR AöR ist Essen. Weitere Informationen finden sich unter Kompetenzcenter elektronisches Fahrgeldmanagement (KCEFM) Die fünf nordrhein-westfälischen Kompetenzcenter wurden zur landesweiten Koordination und Weiterentwicklung von überregionalen bzw. technisch anspruchsvollen Aufgaben des ÖPNV eingerichtet. Zur Nutzung von Synergien sind sie bei Verkehrsverbünden bzw. Verkehrsunternehmen angesiedelt. Das Kompetenzcenter Elektronisches Fahrgeldmanagement (KCEFM) ist in die Verwaltungsstruktur des VRR eingegliedert. Zentrale Aufgabe ist die Abstimmung von technischen Standards bei elektronischen Tickets. Hier setzt das KCEFM auf die VDV-Kernapplikation (KA) (siehe: Die Partner des KCEFM (Zweckverbände, Verkehrsverbünde, -gemeinschaften und -unternehmen in NRW) profitieren von der Zusammenarbeit mit dem Kompetenzcenter unter anderem durch personelle und konzeptionelle Unterstützung bei der Einführung und Weiterentwicklung des etickets. Der Internetadresse des KCEFM lautet

11 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 11 3 Projektbeschreibung 3.1 Umfeld: Vertrieb und Elektronisches Fahrgeldmanagement Seit 2003 wird in drei Verbünden in Nordrhein-Westfalen eticketing betrieben. Der VRR, der Verkehrsverbund Rhein-Sieg (VRS) und die Verkehrsgemeinschaft Niederrhein (VGN) statteten die Abonnenten ihrer Verkehrsunternehmen (VU) damals mit Chipkarten der proprietären Paycard-Technologie aus. Die Paycard verfügt über eine kontaktlose und eine kontaktgebundene Schnittstelle. Im Jahre 2005 wurde mit der VDV-Kernapplikation ein bundesweiter Standard für das elektronische Fahrgeldmanagement (EFM) geschaffen. Die drei Verbünde beschlossen, anlässlich der nächsten fälligen Beschaffung von Chipkarten zum neuen Standard zu migrieren. Dies geschah zu Beginn des Jahres Mittlerweile sind in NRW rund zwei Millionen Fahrgäste mit Chipkarten ausgestattet. Zurzeit sind sowohl Paycards als auch Chipkarten nach KA-Standard im Markt. Die Paycards sollen bis 2012 von KA-Karten komplett abgelöst werden. Hauptgrund für die Einführung des EFM war die größere Gesamtwirtschaftlichkeit des eticketings gegenüber den überkommenen Formen des Abonnements. Die Gründe für die Migration zur VDV-Kernapplikation waren vielfältig: Das bis dahin eingesetzte proprietäre Paycard-System sollte durch eine offene Technologie ersetzt werden. Die Abhängigkeit von einem einzelnen Hersteller sollte gebrochen werden. Vom Einsatz des Standards wurden mittelfristig günstigere Preise für Nutzermedien (NM, z.b. Chipkarten) und Terminals erwartet. Die Hersteller stehen in einem stärkeren Wettbewerb. Ein Standard verspricht die Möglichkeit der Interoperabilität zwischen den verschiedenen Verkehrsräumen und unternehmen, welche ihn einsetzen. Die Interoperabilität des EFM wird für Kunden erst dann erlebbar, wenn sie mit dem in ihrem Verbund verwendeten Nutzermedium (NM), auch andernorts am eticketing für den ÖV teilnehmen können. Fahrten in anderen Regionen des Landes gehören für die allermeisten ÖV-Nutzer nicht zum Alltag. Für diese Art von Reisen gewinnen Recherche von Fahrplänen und der Erwerb von Tickets über das Internet zunehmend an Bedeutung. Dies zeigt u.a. die Nutzung von Fahrplanauskünften und Vertriebssystemen z.b. für Bahn- und Flugtickets im Internet. Der Bezug von etickets via Internet stellt damit eine konsequente Erweiterung der modernen, individuellen Reise- und Fahrtplanung dar, welche den existierenden EFM-Systemen bislang fehlt.

12 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Motivation Warum d(((eti? Die Ausgabe elektronischer Tickets auf Nutzermedien ist im EFM in NRW und anderswo bisher ausschließlich an den Ausgabestellen der Verkehrsunternehmen (z.b. Kundencentern) oder bei mit Spezialgeräten ausgerüsteten Dienstleistungsunternehmen (Massenpersonalisierer) möglich. Sie ist in der Regel mit der Haltung der Kundendaten integriert. Damit sind in der Praxis eticket-ausgabegeräte immer Teile von aufwändigen Hintergrundsystemen (HGS). Dies erfordert investitionsintensive Geräte und Software sowie Sicherheitsmodule (SAMs) vor Ort. In der Konsequenz ist die Beschaffung solcher Systeme nur für Unternehmen wirtschaftlich sinnvoll, welche größere Mengen von etickets ausgeben. Ein ähnliches Bild ergibt sich bei der Kontrolle von etickets: Die Datenver- und -entsorgung der eigentlichen Kontrollgeräte ist bei existierenden Systemen stark in die oben beschriebenen Hintergrundsysteme integriert. Die Schwelle zum Einsatz von EFM nach KA, sei es als Kundenvertragspartner (KVP) oder als Dienstleister (DL), ist damit für kleinere Unternehmen sehr hoch. All diese Probleme lassen sich durch ein System lösen, welches die aufwändigen und teuren Geräte zentral vorhält und sie den Verkehrsunternehmen bei Bedarf zur Verfügung stellt. Der Aufwand für teilnehmende VU beschränkt sich auf die Beschaffung von Rechnern und ISO Schreib/Lesern, Kontrollgeräten, die per Internet Sperr- und Meldedaten austauschen können und die Internet-Verbindungskosten. Die Einführung von Chipkarten als Träger von etickets bringt für Fahrgäste eventuell eine Informationslücke mit sich: Das eigentliche Ticket ist mit bloßem Auge nicht zu überprüfen. Die Frage nach Gültigkeitsdauer und räumen ist damit für Kunden nicht mehr unbedingt zu beantworten, wenn der Inhalt des Nutzermediums nicht ausgelesen wurde. Dies behebt eine Software, welche in Verbindung mit einem Leser nach ISO Nutzermedien ausliest und die vorgefundenen Daten interpretiert. Zusätzlich zu den bisher dargestellten sind noch andere Anwendungen denkbar: Mit Hilfe von NFC-Handys können etickets von mobilem Servicepersonal nahezu überall an Kunden ausgegeben werden. NFC-Handys mit multiapplikationsfähigen SIM-Karten könnten etickets direkt über GPRS / Internet beziehen. Entsprechend ausgestattete Servicepartner der Verkehrsunternehmen könnten Nutzermedien lesen und Auskunft über etickets geben Gründe für die Realisierung als Open-Source-Software Als Open-Source-Software bezeichnet man Software, deren Quelltext (engl. Source Code) frei zugänglich ist und die von jedermann bearbeitet, weiter entwickelt, kopiert und verbreitet

13 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 13 werden darf, ohne dass Lizenzkosten anfallen. (Bekannte Produkte: Linux, OpenOffice.org, Firefox) Die Nutzung von Open-Source-Software wird wie bei vielen anderen Software-Produkten auch durch Lizenzen geregelt. Die bekannteste und zurzeit wohl bedeutendste Open- Source-Lizenz ist die GNU General Public License (GPL). Open-Source-Software wird immer dann eingesetzt, wenn Programme nach dem Willen des Autors oder seines Auftraggebers gratis und frei verfügbar sein sollen. Zusätzlich erhoffen sich Autoren bzw. deren Auftraggeber, dass andere Autoren das jeweilige Programm weiter entwickeln. Drei Gründe sprechen für die Entwicklung von d(((eti als Open-Source-Software: Bereits existierende Open-Source-Programme, wie eine Datenbank, ein CRM- System, ein Webserver oder ein Web-Shop-System können kostenlos integriert werden. Dies hält die Entwicklungskosten niedrig und die Entwicklungszeit kurz. Das resultierende System ist quelloffen und kann daher von jedem Interessenten weiterentwickelt und gepflegt werden. Wenn kommerzielle Anbieter modifizierte Versionen von d(((eti verkaufen möchten, so müssen sie die Wahl der passenden Lizenz vorausgesetzt die Veränderungen und Neuentwicklungen offen legen. Wie die meiste quelloffene Software soll auch d(((eti gratis verteilt werden. Damit beschränken sich die Kosten für den Einsatz von d(((eti auf Hardware, Administration, Telekommunikation und Anpassung (z.b. Lokalisierung, Corporate Identity). Dies bewirkt eine drastische Senkung der Schwelle zum wirtschaftlichen Betrieb eines solchen Systems. Zudem wird das Dilemma, welches staatliche Förderung in der Software-Entwicklung mit sich bringt, durch Open-Source-Software aufgehoben: Die Entwicklung verbleibt nicht im Besitz einer Herstellerfirma oder der geförderten Stelle, sondern kommt allen Interessenten und damit der Allgemeinheit zu Gute. 3.3 Funktion d(((eti ist, wie schon der Name sagt, ein System zur Ausgabe von elektronischen Fahrscheinen (EFS) nach KA über das Internet. Die eigentliche Ausgabe kann über einen preiswerten Rechner mit Internetanschluss und einem preiswerten Schreib-/Leser nach ISO geschehen. Ein Server in der Hand eines Kundenvertragspartners verwaltet ein oder mehrere SAM.

14 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 14 Abbildung 1 d(((eti als eticketserver Hinzu kommt ein komplettes Vertriebssystem für elektronische Fahrausweise, eine Software zum Lesen von Nutzermedien und eine Programmierschnittstelle, welche die Entwicklung von Software zum Lesen und Schreiben von KA-Nutzermedien stark vereinfacht. In der Terminologie der Kernapplikation heißt das, dass das d(((eti-system die Funktion eines Kundenvertragspartner-Servers, eines KVP-Terminals und eines Dienstleister-Servers integriert Dabei wird die Funktion des Kundenvertragspartner-Terminals auf verschiedene Rechner im Internet verteilt: Die Bedienelemente, wie Tastatur und Bildschirm, werden von einem internetfähigen Client-PC verkörpert. Den Rest der Terminalfunktionen steuert ein Server bei. 3.4 Erläuterung der drei Arbeitspakete Gegenstand dieser Leistungsbeschreibung ist die Entwicklung und Lieferung eines Open- Source-Software-Systems zur Distribution von elektronischen Tickets nach VDV- Kernapplikation über das Internet. Als Beiprodukte sollen eine Bibliothek für Kernapplikationsfunktionen und ein Ausleseprogramm für KA-Nutzermedien entwickelt werden. Diese Aufgabenstellung legt die Entwicklung der Software in drei Paketen nahe: Paket 1: d(((eti-api (Application Programming Interface) Erstellung einer OpenSource API mit zugehörigen Bibliotheken für alle Anwendungsfälle, welche nach KA-

15 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 15 Schnittstellenspezifikationen [Spec_SST_V1106] zwischen KVP-Server, DL-Server, KVP- Terminal, DL-Terminal, SAM, Nutzermedium, PV-Server und KOSE-Server auftreten können. Paket 2: d(((eti-eticket-viewer Erstellung eines Open-Source-Programms zum Auslesen von etickets nach Kernapplikation an einfachen ISO Leser/Schreibern. Der d(((eti- Viewer implementiert bestimmte Funktionen eines selbstbedienten KVP-Terminals. Paket 3: d(((eti-system Entwicklung und Test eines mandantenfähigen Vertriebssystems zur Distribution von etickets nach VDV-Kernapplikation über das Internet und zur Datenverund -entsorgung von Kontrollgeräten. Damit implementiert das d(((eti-system das selbst- und personalbediente KVP-Terminal. d(((eti-viewer und d(((eti-system basieren auf der d(((eti-api. Die d(((eti-api soll zunächst soweit entwickelt werden, dass der d(((eti-viewer darauf programmiert werden kann. Der Rest der d(((eti-api kann im Zuge der Entwicklung des d(((eti-systems entwickelt werden. 3.5 Technische Grundlagen und Rahmenbedingungen Die Kenntnis der folgenden Dokumente ist zum Verständnis der Leistungsbeschreibung und des Auftragsgegenstandes unerlässlich. Sollten Dokumente in mehreren Versionen vorliegen, so gelten die bei der Veröffentlichung der Ausschreibung gültigen Versionen. Zusätzlich gilt für Dokumente der VDV- Kernapplikation, dass Change Requests (CR), welche bis zur Veröffentlichung dieser Ausschreibung von der VDV Kernapplikations GmbH & Co. KG (VDV-KA KG) offiziell freigegeben und veröffentlicht worden sind, umzusetzen sind. Die Beschaffung der hier aufgeführten Dokumente obliegt dem Auftragnehmer. Einige Dokumente können lediglich gegen Schutzgebühr bezogen werden. Die Gebühren sind vom Auftragnehmer selbst zu tragen Dokumente KA d(((eti implementiert Teile eines EFM-Systems nach VDV-Kernapplikation. Daher sind die Spezifikationen und Systemlastenhefte der VDV-Kernapplikation in Gänze zu beachten. Insbesondere sind die folgenden Spezifikationen und Systemlastenhefte der VDV- Kernapplikation von besonderer Bedeutung: VDV-Kernapplikation Glossar [KA_Glossar_V1106] KA_Technische Spezifikation, Hauptdokument mit Basisobjektmodell (BOM) [Spec_HD_BOM_V1106] Erweiterung Mobiles Ticketing, Applikation und Übertragungsprotokoll [Spec_MT ServerProt_V1106]

16 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 16 Erweiterung Mobiles Ticketing, Kernapplikation als Mobile Ticketing Applikation [Spec_MT_V1106] VDV-Kernapplikation Spezifikation Nutzermedium [Spec_NM_V1106] Beschreibung der Schnittstellen zwischen der Vertriebseinheit (KVP-VE) und der Personalisierungseinheit (KVP-PE) eines KVP-Terminals [Spec_PE_V1106] VDV-Kernapplikation Spezifikation des SAM [Spec_SAM_V1106] VDV-Kernapplikation Technisches Konzept Sicherheit [Spec_SEC_V1106] Schnittstellenspezifikationen der Referenzsysteme Kundenvertragspartner (KVP), Dienstleister (DL), Produktverantwortlicher (PV), Applikationsherausgeber (AH), Kontrollservice (KOSE) [Spec_SST_V1106] Systemlastenheft, Teil: Dienstleister-System (DLS) [SYSLH_DLS_V1106] Anhang zum Hauptdokument, Systemlastenheft, Nutzung des Kundendatenspeichers - Vorläufige Verfahrensfestlegung [SYSLH_HD_Anlage_V1106] Systemlastenheft Hauptdokument [SYSLH_HD_V1106] Systemlastenheft, Teil: Kontrollservice-System (KOSES) [SYSLH_KOSES_V1106] Systemlastenheft, Teil: Kundenvertragspartner-System [SYSLH_KVPS_V1106] Systemlastenheft, Teil: Personalbediente KVP-ReferenzTerminals [SYSLH_PbRTKVP_V1106] Systemlastenheft, Teil: Produktverantwortlichen-System (PVS) [SYSLH_PVS_V1106] Systemlastenheft, Teil: Referenzterminal DL [SYSLH_RTDL_V1106] Systemlastenheft, Teil: Personalbediente KVP-Referenzterminals [SYSLH_SbRTKVP_V1106] Anlage zum Hauptdokument der Spezifikationen zur VDV-Kernapplikation Rahmenrichtlinie Elektronisches Fahrgeldmanagement (EFM) Datenschutzrechtliche Grundanforderungen [Anlage DSzuHD_SPEC_V1106] Einheitliche Kundenschnittstelle für ein mehrstufiges interoperables elektronisches Fahrgeldmanagement [SPEC_KUSCH_V1106] Die oben aufgeführten Dokumente können über die VDV KA KG bezogen werden.

17 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Dokumente KCEFM Die Berechtigungen, welche mit d(((eti ausgegeben und interpretiert werden sollen, sind der Referenz-EFS der VDV-Kernapplikation, der NRW-KA-EFS des VRR, des VRS und der VGN und die Automatische Fahrtberechtigung (AFB) des Kreisverkehr Schwäbisch Hall (KVSHA). Die spezifischen Teile des NRW-KA-EFS sind in folgender Spezifikation beschrieben: Aufbau des NRW-KA-EFS und Konvertierungsregeln [NRW_KA_EFS] Dieses Dokument ist als Anlage beigefügt.

18 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 18 4 Allgemeine Beschreibung der Aufgabenstellung 4.1 Das Rollenmodell der VDV-Kernapplikation Die Grundlage der Organisation des eticketings nach Kernapplikation bildet das zu Grunde liegende Rollenmodell. Es beschreibt, wie die Teilnehmer am EFM und damit auch deren technischen Systemkomponenten untereinander kommunizieren müssen. Das folgende Diagramm zeigt die verschiedenen Rollen der Kernapplikation: Kunden - abrechnung Kunden - Vertragspartner Produkt - Verantwortlicher Produkt - abrechnung Kontrollservice Vertrieb Service Zertifizierung (KOSE) Applikations - Entwicklung & Pflege Registrierung Herausgeber Ausgabe Sicherheits management - Nutzer - medium Dienstleister Erfassung Kontrolle Nutzer Kunde Leistungs - abrechnung Abbildung 2 Das VDV-KA-Rollenmodell und d(((eti Im Rahmen des d(((eti-systems sind also ein KVP- und DL-Server sowie ein KVP-Terminal zu realisieren.

19 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Übersicht Systemarchitektur d(((eti Abbildung 3 Das d(((eti-system mit Schnittstellen Die Abbildung Das d(((eti-system mit Schnittstellen zeigt den d(((eti-server mit seinen Schnittstellen zu anderen KA-Systemen und zu Client-Rechnern. In der nächsten Abbildung Das d(((eti-system als KA-KVP- und DL-System wird gezeigt, welche KA-Systeme das d(((eti-system implementiert.

20 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 20 Abbildung 4 Schnittstellen von d(((eti zu anderen KA-Systemen

21 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Beschreibung des Pakets d(((eti-api API ist die Abkürzung für das englische Application Programming Interface und im Deutschen mit Programmierschnittstelle zu übersetzen. Die d(((eti-api soll eine Programmierschnittstelle aller KA-Funktionen bilden, welche zur Entwicklung des d(((eti-systems und des d(((eti-eticket-viewers benötigt werden. Zudem soll die API in Form einer oder mehrerer objektorientierter Bibliotheken implementiert werden. Schließlich soll die erschöpfende Dokumentation der d(((eti-api dazu beitragen, dass dritte Entwickler die d(((eti-api und die zugehörigen Bibliotheken zur Programmierung eigener KA- Systemkomponenten nutzen können. Das d(((eti-system implementiert im Wesentlichen ein kombiniertes DL/KVP-System mit KVP-Terminal. (Siehe Abbildung 4) (Der d(((eti-eticket-viewer kann als Spezialfall eines DL- Terminals hier vernachlässigt werden.) Dabei muss das d(((eti-system mit allen notwendigen Systemen der Kernapplikation kommunizieren. Die Schnittstellen der KA-Systeme sind, mit Ausnahme der Schnittstelle DL- System <-> DL-Terminal, in der KA-Spezifikation KA SST-SPEC Schnittstellenspezifikationen der Referenzsysteme Kundenvertragspartner (KVP), Dienstleister (DL), Produktverantwortlicher (PV), Applikationsherausgeber (AH), Kontrollservice (KOSE) [Spec_SST_V1106] festgelegt. Die Entwicklung von d(((eti mündet in zwei Produkte aus Nutzer-/Kundensicht: d(((etieticket-viewer und d(((eti-system. Der Viewer benötigt weitaus weniger KA-Funktionalität als das System und soll wesentlich früher fertig gestellt werden. Beide Produkte sollen sich der d(((eti-api bedienen, um KA-Funktionen auszuführen. Da der d(((eti-eticket-viewer nur eine Untermenge der gesamten d(((eti-api benötigt, kann zunächst nur diese Untermenge entwickelt werden.

22 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Beschreibung des Pakets d(((eti-eticket-viewer Die Aufgabe des d(((eti-eticket-viewer ist es, Kernapplikation-Nutzermedien auszulesen und die Inhalte der Berechtigungen anzuzeigen. Letztendlich handelt es sich hier um die Umsetzung einiger Elementarprozesse, z,b. EP_Anzeige_EFS, EP_Anzeige_Applikationsdaten oder EP_Anzeige_Kundenprofil (siehe Kapitel ). Auf einem NM können spezifikationsgemäß mindestens acht Berechtigungen verschiedener Art abgelegt sein. Diese sind in der Spezifikation [Spec_NM_V1106] beschrieben. Dem Nutzer des d(((eti-eticket-viewers muss die Möglichkeit offen stehen, aus den vorhandenen Berechtigungen auszuwählen und die ausgewählte Berechtigung näher zu betrachten. Dazu ist eine Darstellung zur Verfügung zu stellen, welche alle Berechtigungen in Kurzform mit Berechtigungsart und ausgebender Organisation anzeigt und dem Nutzer die direkte Auswahl gestattet. Alternativ dazu muss es einen Darstellungsmodus geben, der nach dem Einlesen der Berechtigungen sofort den ersten oder die ersten beiden Berechtigungen anzeigt. Die Organisationen (in der Regel ein Verkehrsunternehmen) werden in der KA mit Hilfe von Nummern, den sog. OrgIDs bestimmt. Der d(((eti-eticket-viewer muss eine Liste aller OrgIDs und die dazugehörigen Unternehmen einlesen können, um die OrgID in einen Organisationsnamen und / oder Organisationskürzel übersetzen zu können. Die VDV KA KG hat bisher etwa hundert OrgIDs vergeben. Es ist zu erwarten, dass die Zahl in den kommenden Jahren noch um ein Vielfaches zunimmt. Die Kernapplikation definiert das Nutzermedium (siehe [Spec_NM_V1106]). Die Daten des Nutzermediums sollen dem Anwender des d(((eti-eticket-viewers ebenfalls angezeigt werden können. Die EFS-Berechtigung ist in der Kernapplikation nur bis zu einem gewissen Grad definiert: Die Spezifikation enthält einen Teil, der von Produktverantwortlichen nach Belieben gefüllt werden kann. Für VRR, VRS und VGN wird diese Struktur mit dem NRW-KA-EFS gefüllt. Der Aufbau des NRW-KA-EFS ist in der Spezifikation des KCEFM [NRW_KA_EFS] beschrieben. Generell muss der d(((eti-eticket-viewer in der Lage sein, alle in der KA möglichen Berechtigungen zu interpretieren. Dazu muss er beliebig viele Beschreibungen von Produkten einlesen, verwalten und anwenden können. Die ausgelesenen Inhalte von Nutzermedien müssen in wohlgeformten Textdateien abgespeichert werden können. Dies dient u.a. zum Zweck der Diagnose und zur Dokumentation auffälliger Berechtigungen. Eine Hilfefunktion erklärt die Bedienung des d(((eti-eticket-viewers.

23 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Beschreibung des Pakets d(((eti-system Das d(((eti-system dient unter anderem dem Vertrieb von etickets. Sowohl Kundenvertragspartner selbst, als auch deren Vertriebspartner und Kunden sollen mit d(((eti Berechtigungen auf Nutzermedien speichern können. Dies bedingt, dass d(((eti über Mechanismen verfügen muss, welche die Zuweisung von Rechten durch den KVP sowie die Dokumentation aller ausgegebenen Berechtigungen sicher stellt. Die Ausgabe von Berechtigungen ist in der Praxis fast immer an Bezahlvorgänge geknüpft. Das d(((eti-system muss diese Vorgänge und die dazu gehörigen Daten wie z.b. Bankverbindungen verwalten können. In seiner Eigenschaft als Dienstleister-Server (DLS) und Kundenvertragspartner-Server (KVPS) muss d(((eti die Verwaltung des Datentauschs mit anderen KA-Systemen bzw. Servern ermöglichen. d(((eti muss mandantenfähig sein. Daher muss ein d(((eti-system die Funktion mehrerer KVP- bzw. DL-Server übernehmen können. Um die vielfältigen Bedienhandlungen zur Verwaltung eines d(((eti-systems verschiedenen realen Personen zuordnen zu können, muss eine Hierarchie der d(((eti-system-nutzer gebildet werden können. KVP1 KVPn KVP2 DL1 DLn DL2 Abbildung 5 Die Hierarchie der d(((eti-nutzer

24 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 24 Grundsätzlich sollen übergeordnete Nutzer die Möglichkeit haben, all das zu tun, was auch die ihnen untergeordneten Nutzer im d(((eti-system tun können. Alle übergeordneten Nutzer können Systemzugänge (Konten, Accounts) für ihnen untergeordnete Nutzer einrichten. Die Bedienung des d(((eti-systems soll mit jedem modernen WWW-Browser auf einem entfernten Rechner möglich sein. Das heißt, dass d(((eti eine Web-Schnittstelle implementieren muss, welche alle Nutzerfunktionen anbietet. Die Sicherheitsmodule müssen in einem eticket-server zentral verwaltet werden. Die Schnittstelle zur Kommunikation zwischen d(((eti-server und Clientrechner (siehe auch Kapitel 4.2, Abbildung 3 Das d(((eti-system mit Schnittstellen) muss definiert und implementiert werden. Zudem dient das d(((eti-system als Dienstleister-Server (DLS). In dieser Eigenschaft speichert und verarbeitet es Bestandslisten von etickets sowie Sperrlisten und Sperrnachweise und verteilt sie auf angeschlossene DL-Terminals (Z.B. mobile Prüfgeräte, Systeme zur elektronischen Einstiegskontrolle (EKS)). Das d(((eti-system muss als KA-KVP- und DL-Server bestimmte Elementarprozesse der Kernapplikation implementieren (siehe auch Kapitel ).

25 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Pflichtenheft Das Pflichtenheft wird vom Auftragnehmer als Konkretisierung des Lastenheftes bzw. der Leistungsbeschreibung erstellt. Es beschreibt, wie der Auftragnehmer die drei Pakete von d(((eti konkret entwickeln wird. Das d(((eti-pflichtenheft weist insbesondere einen Teil auf, der beschreibt, auf welchen vorhandenen Open Source Programmen sich die weitere Entwicklung stützt. Im Pflichtenheft sind die Nutzer-Prozesse des d(((eti-systems beschrieben. Die zugehörigen Dialoge und anderen Bedienkomponenten sind grob skizziert. Ein separater Teil beschreibt alle im Rahmen der Entwicklung definierten Schnittstellen. Ein Teil des Pflichtenheftes beschreibt die Tests zur Prüfung der Funktionsfähigkeit der d(((eti-pakete. Die Tests sollen möglichst umfassend sein und so viel Funktionalität wie möglich prüfen. Sie sind Grundlage der Abnahme. Zu den Tests wird definiert, welcher Erfüllungsgrad für eine Abnahme mit Mängeln ausreicht. Die Beschreibung der Tests muss so gestaltet sein, dass sie als Abnahmeprotokoll dienen kann. Das gesamte Pflichtenheft wird zu Beginn der Entwicklung zwischen Auftraggeber und Auftragnehmer abgestimmt und abgenommen.

26 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Rechte an der Software / Veröffentlichung unter Open Source-Lizenz Der Auftragnehmer räumt dem Auftraggeber ausschließliches, unbeschränktes Nutzungsrecht an der entwickelten Software ein. Der Auftraggeber stellt die Software unter die GNU General Public License (GPL). Ausgenommen ist die d(((eti-api, welche unter die Lesser General Public License (LGPL) gestellt wird. Der Auftragnehmer gestaltet alle von ihm entwickelten Quelltexte so, dass sie den Anforderungen der GPL bzw. LGPL entsprechen. Dies gilt insbesondere bei der Kommentierung von Quelltextdateien. (Siehe bzw.

27 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 27 5 Projektabwicklung 5.1 Durchführung Projektleiter Auftragnehmer Der vom Auftragnehmer bestimmte Projektleiter ist Ansprechpartner für jedwede Kommunikation zwischen Auftraggeber und Auftragnehmer. Die direkte Kommunikation mit Entwicklern und Unterauftragnehmern pflegt der Auftraggeber nur in von ihm gebilligten Ausnahmefällen und unter Information des Projektleiters des Auftragnehmers Projektgespräche In jedem Monat findet zumindest ein Projektgespräch beim Auftraggeber statt. An den Projektgesprächen nehmen der Projektleiter des Auftragnehmers sowie der Ansprechpartner des Auftraggebers teil Protokollführung Von allen Projektgesprächen fertigt der Auftraggeber Ergebnisprotokolle an. Diese werden mit dem Auftragnehmer abgestimmt. Der Auftragnehmer legt Entwürfe der Ergebnisprotokolle möglichst schnell, spätestens aber sieben Tage nach dem entsprechenden Projektgespräch vor. Protokolle werden im jeweils nächsten Projektgespräch, eventuell nach einmütiger Korrektur, genehmigt. 5.2 Mitwirkungsleistungen Testmaterial Der Auftraggeber stellt folgende Materialien zur Entwicklung und zum Test leihweise zur Verfügung: a) Zwei Sicherheitsmodule b) Zehn Chipkarten mit Kernapplikation Vor Teilabnahmen und der Abnahme des Auftragsgegenstandes testet der Auftraggeber eigenverantwortlich die Funktionalität der gelieferten Software Abnahmeprüfungen Pflichtenheft, d(((eti-eticket-viewer und d(((eti-system werden zu verschiedenen Zeitpunkten abgenommen. Der Auftraggeber prüft im Beisein des Auftragnehmers die Gegenstände zur Abnahme und hält die Ergebnisse der Prüfung schriftlich in einem Abnahmeprotokoll fest. 5.3 Qualitätssicherung Der Auftragnehmer stellt in seinem Angebot dar, mit welchen Maßnahmen er die Qualität der gelieferten Software sicher stellen wird.

28 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Vorschriften, Richtlinien, Normen In Fragen der Benutzbarkeit und Softwareergonomie ist zu beachten: EN ISO 9241, Teile 11 bis 17, 110, 151 und Besondere Hinweise Die umfangreichen Dokumente, welche die VDV-Kernapplikation beschreiben, haben erst in Teilen ihren Praxistest bestanden. Insbesondere die für d(((eti besonders wichtigen Systemlastenhefte des KVPS und DLS sind noch nicht in einem realen System umgesetzt worden. Dies wird zum ersten Mal bei d(((eti der Fall sein. Obwohl die Dokumente von hoher Qualität sind, kann nicht ausgeschlossen werden, dass an der einen oder anderen Stelle noch Fehler oder Spezifikationslücken vorhanden sind. In Kapitel sind die Fehler und Spezifikationslücken beschrieben, welche den Autoren beim Erstellen dieser Leistungsbeschreibung aufgefallen sind. Aus diesem Grunde sind die Spezifikationen und Systemlastenhefte vom Auftragnehmer mit großer Aufmerksamkeit zu analysieren. Falls dabei weitere Fehler oder Spezifikationslücken auftauchen oder Unklarheiten wahrgenommen werden, so sind sie umgehend dem Auftraggeber zu melden. Die für d(((eti maßgebliche Interpretation wird vom Auftraggeber, eventuell nach Beratung mit der VDV KA GmbH & Co. KG, festgelegt. Es kann sich daraus ergeben, dass weitere Elementarprozesse, Anwendungsfälle oder Schnittstellenobjekte spezifiziert werden müssen. Deren Implementation gehört zum Auftragsumfang Templates, Produkt- und Kontrollmodule Die VDV-Kernapplikation ist grundsätzlich neutral hinsichtlich des angewendeten Tarifes. Um jeden Tarif umsetzen zu können, gibt es als Bestandteil der Berechtigungen zwei so genannte produktspezifische Teile und zwar den Statischen produktspezifischen Teil und den Transaktion produktspezifischen Teil. Näheres zum Aufbau von Berechtigungen kann der [Spec_NM_V1106] und dem [Spec_HD_BOM_V1106] entnommen werden. Der Aufbau dieser produktspezifischen Teile kann auf Basis der in [Spec_HD_BOM_V1106] beschriebenen Datenelemente selbst definiert werden, um die Tarifprodukte eines PVs abbilden zu können. Damit ein derartiger Aufbau einem System datengesteuert übermittelt werden kann, sind Templates vorgesehen. Um jedoch die Definition von Templates weitestgehend überflüssig zu machen, wurden so genannte Referenz-Objekte (Referenz-EFS, Referenz-AFB, etc.) definiert, die jedes System, ohne dass ein Template vorliegt, verarbeiten können muss. Auf Basis dieser Referenz-Objekte bzw. Templates können dann Tarifprodukte abgebildet werden. Um diese nun ebenfalls datengesteuert in die Systeme einbringen zu können, sind Produkt- und Kontrollmodule vorgesehen.

29 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 29 Das Produkt- und Kontrollmodul beinhaltet Daten, die sowohl für die Ausgabe als auch die Kontrolle einer Berechtigung wichtig sind. Es gibt neben statischen Daten, die feste Produkteigenschaften beschreiben, auch dynamische Daten, die letztendlich die Parameter eines Produktes darstellen. Dabei wird zwischen Daten, die die Art und Weise beschreiben, wie ein Element einer Berechtigung zu füllen ist, und denen, die beschreiben, mit welchem Algorithmus eine Element bearbeitet werden muss (z. B. bei einer Kontrolle). Darüber hinaus wird beschrieben, welches Datum aus dem Produkt- und Kontrollmodul wo und wie in einer Berechtigung abgebildet wird. Eine wichtige Eigenschaft eines Produkt- und Kontrollmoduls ist die Preisbildung. Der Preis wird durch ein entsprechendes Preismodul als Teil des Produkt- und Kontrollmoduls gebildet. Im einfachsten Fall ist dies eine Tabelle bei der sich abhängig vom Produkt und einer Preisstufe ein Preis ergibt. Bei Streckentarifen kann dieses Preismodul aber schon sehr kompliziert werden. Technisch gesehen sind sowohl Templates als auch Produkt- und Kontrollmodule XML- Strukturen, deren Aufbau durch ein entsprechendes XML-Schema beschrieben wird. Darüber hinaus gibt es Funktionen, die die benötigten Algorithmen umsetzen. Es gibt in der VDV-Kernapplikation allerdings noch keine konkrete Spezifikation von Templates und Produkt- und Kontrollmodulen. Diese wird zurzeit durch eine Arbeitsgruppe der VDV- Kernapplikation erstellt. Die aktuelle Entwicklung in diesem Bereich ist in der Pflichtenheftphase entsprechend zu berücksichtigen. Sollten während der Pflichtenheftphase Templates, Produkt- und Kontrollmodule nicht spezifiziert sein, so sind Ersatzlösungen mit dem Auftraggeber abzustimmen Benachbarte Systeme Der KOSES befindet sich zurzeit im Aufbau. PVS und AHS sind bisher noch nicht entwickelt worden. Das gilt auch für KA-konforme KVPS oder DLS. Diese Systeme kommunizieren über das standardisierte Interoperabilitätsnetzwerk (siehe Kapitel 5.5.3). Insofern muss davon ausgegangen werden, dass die Kommunikation grundsätzlich funktionieren wird. Für die Abnahme sind diese benachbarten Systeme entsprechend zu simulieren Interoperabilitätsnetzwerk Der Datenaustausch zwischen den einzelnen Systemen ist in [Spec_SST_V1106] grundsätzlich beschrieben. Allerdings fehlen noch Details hinsichtlich der in diesem Fall asynchronen Übertragung per FTPS. Diese Details werden kurzfristig noch festgelegt. Folgende Rahmenbedingungen werden zurzeit diskutiert:

30 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 30 Jede XML-Struktur (z. B. TXABER) wird in einer separaten Datei übertragen. Die möglichen Datenstrukturen können Kapitel entnommen werden. Es gibt eine Definition für den Aufbau der Dateinamen. Die Datei wird gegebenenfalls vor der Übertragung gezippt. Details der Übertragung wie Nutzername/Kennwort und eventuell erforderliche Zertifikate sind geklärt. Wegen der in Kapitel beschriebenen eventuell noch fehlenden Systeme muss es abhängig vom jeweiligen Anwendungsfall eine Möglichkeit geben, anstatt des regulären Empfängers einen Ersatz-Empfänger konfigurieren zu können. Die aktuelle Entwicklung in diesem Bereich ist in der Pflichtenheftphase entsprechend zu berücksichtigen. Allerdings werden auch noch grundsätzlich andere neuere Technologien wie EXI (Efficient XML Interchange) und Web-Services in diesem Zusammenhang diskutiert. Die Systemarchitektur muss es daher grundsätzlich gestatten, diese neuen Technologien später ebenfalls zu unterstützen. Demzufolge muss es eine klare Trennung zwischen der Erzeugung einer Datenstruktur und deren Weiterleitung geben Hinweise zum Datenaustausch zwischen KVPS und KVPT sowie DLS und DLT Basierend auf den Ausführungen im Kapitel und den dann getroffen Festlegungen ist vom KCEFM beabsichtigt, Schnittstellenbeschreibungen zwischen einem KVPS und KVPT sowie einem DLS und DLT zu erstellen und über einen CR der Spezifikation der VDV- Kernapplikation hinzuzufügen. Diese Schnittstellen werden sich grundsätzlich nicht von der Übertragung im ION unterscheiden. Die Datenstrukturen, die übertragen werden, können den Kapiteln und entnommen werden. Die aktuelle Entwicklung in diesem Bereich ist in der Pflichtenheftphase entsprechend zu berücksichtigen TestSuite der VDV-Kernapplikation Es besteht auch die Möglichkeit die Testsuite der VDV-Kernapplikation zu kaufen. Diese kann insbesondere Entwicklern den Einstieg in die VDV-Kernapplikation erleichtern. Insbesondere bei der Entwicklung der Kommunikation zum Nutzermedium und SAM im Rahmen der Realisierung des KVP-Terminals des d(((eti-systems bzw. d(((eti-viewers kann sie hilfreich sein und Entwicklungskosten sparen. Ansprechpartner hierzu ist die VDV- Kernapplikations GmbH & Co. KG, die auch Auskunft über die Kosten gibt.

31 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite 31 6 Spezifizierung der Software 6.1 Allgemeine Eigenschaften der d(((eti-software Portabilität d(((eti soll auf mindestens zwei Betriebssystem-Plattformen laufen. Deshalb sind alle Komponenten so portabel wie möglich zu gestalten. Dies gilt sowohl für die Auswahl der zu nutzenden, zu Grunde liegenden Open-Source-Programme als auch für Neuentwicklungen. Da die Förderung der Weiterentwicklung durch Dritte ein Schwerpunkt des d(((eti-projektes ist, sollten die eingesetzten Programmiersprachen frei verfügbar sein und auch über freie Entwicklungsumgebungen und möglichst viele freie Bibliotheken verfügen. Alle Komponenten sollen über beide Betriebssystemplattformen hinweg soweit möglich die gleiche Codebasis haben Programmierung Die Funktionen sind soweit möglich als Java-Bibliotheken zu entwickeln. Alle hardwarenahen Funktionen, welche nicht in Java zu realisieren sind, sollten in C geschrieben werden. Bibliotheken, welche nicht unter einer freien Lizenz stehen, können nicht eingesetzt werden. Die Quelltexte sind mit aussagekräftigen Kommentaren zu versehen. Insbesondere sind alle Quelltextdateien, alle Klassen, alle Interfaces und alle Funktionen bzw. Methoden zu kommentieren. Für alle Klassen und Interfaces ist zu beschreiben, von welchen Klassen sie erben, bzw. welche Interfaces sie implementieren. Auch die Abhängigkeiten von Bibliotheken sind zu beschreiben. Bei Methoden bzw. Funktionen sind Parameter und Rückgabewerte in Kommentaren im Quelltext zu beschreiben. Für alle Java-Entwicklungen gilt: Die Bedingungen der objektorientierten Programmierung sind einzuhalten. Die Bibliotheken sind so zu schreiben, dass sie mit dem Java Developement Kit (JDK) 6 von Sun (oder höher) kompiliert werden können. Java-Quelltexte sind Javadoc-konform zu kommentieren. C-Anteile der Bibliotheken sind in genormtem C (ISO C90) zu verfassen. Soweit möglich sollen die zur Entwicklung eingesetzten Werkzeuge Open-Source-Software sein. Zumindest sollen alle Teile mit Hilfe von Open Source Compilern vom Quelltext in ausführbaren Code übersetzt bzw. durch Open Source Interpreter ausgeführt werden können.

32 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Benutzbarkeit (usability) und Softwareergonomie Alle Komponenten von d(((eti, welche Nutzungsschnittstellen aufweisen, müssen nach den Regeln der Softwareergonomie aufgebaut werden. Generell sind grafische Nutzungsschnittstellen zu entwickeln. Wo immer möglich, sollen die neu zu entwickelnden Komponenten mit WWW-Clients (Browser) bedient werden können. Soweit möglich müssen die Anwendungen barrierefrei gestaltet sein. Dies gilt für alle Funktionen, welche von Endkunden bzw. Vertriebspartnern genutzt werden können. Insbesondere müssen die Formulare und Dialoge unabhängig von der durch Nutzer eingestellte Browserfenster-Größen sowie Schriftarten und größen ihre Funktion behalten. Alle Anwendungen müssen die Eingabemöglichkeiten der Nutzer soweit beschränken, wie es die Aufgabe zulässt. Dies bedeutet z.b. für die Gestaltung von Formularen, dass Bedienelemente so sparsam wie möglich eingesetzt werden. Für die Gestaltung von Menüs heißt dies analog, dass diese ab einer bestimmten Zahl von Einträgen (ca. fünf) in Untermenüs unterteilt werden sollen. Die Benutzungsoberfläche soll sich den Anwendern durch Einfachheit erschließen. Erfordert eine Funktion umfangreiche und komplizierte Eingaben, so ist der Benutzer durch eine Abfolge von übersichtlichen Formularen bzw. Dialogen zu führen. Durch geeignete Formen der visuellen Rückmeldung muss der Nutzer jederzeit ohne besondere Anstrengungen erkennen können, welche Bedienhandlung das System aktuell erfordert bzw. anbietet Genutzte ISO Schreib-/Lesegeräte Folgende ISO Schreib/Lesegeräte muss der d(((eti-viewer mindestens nutzen können: Omnikey 5321 RFID Baltech Engine Pad Feig OBID classic pro Dies gilt sowohl für den d(((eti-viewer als auch für die Client-Software des d(((eti-systems (Siehe Kapitel 6.4.2, Abbildung 10 Mögliche Architektur des d(((eti-systems und Kapitel 13, Abbildung 1 d(((eti als eticketserver).

33 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite d(((eti-api Technische Eigenschaften Die d(((eti-api-bibliothek soll Entwicklern eine möglichst simple Nutzung von KA-Funktionen bieten. Zudem sollen moderne Entwurfs- und Entwicklungsmethoden unterstützt werden. Daher ist die d(((eti-api objektorientiert zu modellieren. Die objektorientierte Analyse wird vom Auftragnehmer durchgeführt. Das objektorientierte Design wird mittels geeigneter graphischer Notation (z.b. UML) dokumentiert. d(((eti-eticket-viewer und das d(((eti-system sollen in entscheidenden Teilen in Java programmiert sein. Daher muss die d(((eti-api in Java implementiert sein. Systemnahe Teile, welche nicht in Java programmiert werden können, sollen in C programmiert werden. Die d(((eti-api ist als gesonderte Bibliothek bzw. Sammlung von Bibliotheken auszuführen, welche ohne weitere Teile von d(((eti nutzbar ist bzw. sind.

34 Distribution von etickets über das Internet d(((eti - Leistungsbeschreibung Seite Umfang der gesamten API-Funktionalität In den folgenden Kapiteln ist der für die d(((eti-api zu realisierende Funktionsumfang detaillierter beschrieben. An dieser Stelle soll auf zwei wichtige Eigenschaften der VDV- Kernapplikation und somit auch von d(((eti besonders hingewiesen werden: Die VDV-Kernapplikation ist ein durch Organisationskennungen (Org-IDs, Zahlen) gesteuertes System. Aus der jeweiligen Kennung ergibt sich auch die Zugehörigkeit zu einem der drei Sicherheitslevel der VDV-Kernapplikation. Org-ID == dezimal bis dezimal Security Level 1 Org-ID >= dezimal (ohne dezimal bis dezimal) Security Level 2 Org-ID < dezimal Security Level 3 Security Level 1: Öffentlich bekannte Schlüssel für einfache Funktionstests der Komponenten (fiktive Organisationen) Security Level 2: Vertrauliche Schlüssel für Systemtests (reale Organisationen) Security Level 3: Vertrauliche Schlüssel mit höchster Sicherheitsstufe für den Wirkbetrieb (reale Organisationen) Diese Eigenschaft ist bei der Systemarchitektur zu berücksichtigen. Es muss also möglich sein, gesteuert durch Organisationskennungen d(((eti durch eine entsprechende einfache (Start-)Konfiguration einem der drei Sicherheitslevel zuzuordnen. Als Folge daraus sind die für eine jeweilige Org-ID vorhandenen bzw. erzeugten Daten entsprechend zu separieren. Eine weitere Eigenschaft der VDV-Kernapplikation ist die im Rahmen der Public Key Infrastructure (PKI) erfolgte Aufteilung der Endzertifikate für Organisationen, SAMs und Nutzermedien auf mehrere Sub-CAs. Abbildung 6 Aufteilung der Endzertifikate Damit in diesem Fall die Interoperabilität gewährleistet ist, muss unter anderem im Rahmen der von einem KVP-Terminal gesteuerten Kommunikation zwischen Nutzermedium und SAM