TRANSMOBIL 2. AP300 Technisches Konzept

Transkript

1 Erstellung eines funktionalen und technischen Konzeptes für ein interoperables elektronisches Fahrgeldmanagement (EFM) aus der Anforderungsdefinition (TRANSMOBIL1) unter Beachtung europäischer Referenzlösungen und internationaler Standards mit anschließender Verifizierung durch einen Piloten und Labortests AP300 Technisches Konzept Wien, Oktober 2007 Eine Initiative des Bundesministeriums für Verkehr, Innovation und Technologie - Österreich

2 2 / 40 I2 Intelligente Infrastruktur

3 I2 - Intelligente Infrastruktur I2-Intelligente Infrastruktur ist ein Forschungsförderungsprogramm zur Unterstützung österreichischer Unternehmen bei der Entwicklung und Erprobung systemintegrierter Telematikanwendungen im Verkehrssektor. Impressum Verkehrsverbund Ost-Region (VOR) Gesellschaft m.b.h. Mariahilfer Straße Wien I2- Intelligente Infrastruktur 3 / 40

4 4 / 40 I2 Intelligente Infrastruktur

5 TRANSMOBIL 2 Erstellung eines funktionalen und technischen Konzeptes für ein interoperables elektronisches Fahrgeldmanagement (EFM) aus der Anforderungsdefinition (TRANSMOBIL1) unter Beachtung europäischer Referenzlösungen und internationaler Standards mit anschließender Verifizierung durch einen Piloten und Labortests AP300 Technisches Konzept Autor/in (en/innen) Wolfgang Schneider (TEWET GmbH) Klaus Philipp (T.C.L. GmbH) I2- Intelligente Infrastruktur 5 / 40

6 6 / 40 I2 Intelligente Infrastruktur

7 Inhaltsverzeichnis 1 Summary Technische Komponenten des TRANSMOBIL-Systems KVP-Komponenten DL-Komponenten PV-Komponenten AHSM-Komponenten AHSS-Komponenten TAPRIS-Komponenten Technisches Anwendungskonzept Anwendungskonzept für KVP-Komponenten Anwendungskonzept für DL-Komponenten Anwendungskonzept für PV-Komponenten Anwendungskonzept für AHSM-Komponenten Anwendungskonzept für AHSS-Komponenten Anwendungskonzept für TAPRIS-Komponenten Technisches Schnittstellenkonzept Nutzermedium-Terminal-Schnittstelle Sicherheitsmodul-Terminal-Schnittstelle Terminal-Hintergrundsystem-Schnittstelle TAPRIS-Schnittstellenkonzept Technisches Sicherheitskonzept Sicherheitskonzept für das Nutzermedium Sicherheitskonzept für das Sicherheitsmodul Sicherheitskonzept für Terminals Sicherheitskonzept für TAPRIS Anhang 1 Beschreibung des System TAPRIS I2- Intelligente Infrastruktur 7 / 40

8 1 Summary Auf der Grundlage der Dokumente des Projektes TRANSMOBIL (TM2) - Arbeitspaket 1 Funktionales Konzept - Arbeitspaket 2 Auswahl einer Referenz-Spezifikation soll das Technische Konzept die technischen Komponenten für das TRANSMOBIL-System beschreiben. Entsprechend der gewählten technischen Plattform wird dabei auf die Dokumente der VDV- Kernapplikation Bezug genommen. Ziel des Technischen Konzeptes für das Projekt TRANSMOBIL ist es, die Einführung neuer Systemtechnologien für ein Österreichweites Fahrgeldmanagement im ÖPV zwingend mit der Umsetzung standardisierter Systemkomponenten und Datenschnittstellen zu verbinden. Um eine Österreichweite Einführung von e-ticketing Systemen auf Grundlage der Feinspezifikationen der VDV-Kernapplikation sicherzustellen, werden in diesem Technischen Konzept die erforderlichen Grundfunktionen beschrieben, die allen Unternehmen die Ausschreibung und Beschaffung von Systemkomponenten auf Basis des Standards der Kernapplikation ermöglicht. Damit werden Abweichungen vom Standard und damit ungewollte Insellösungen vermieden. Es wird damit die Interoperabilität für alle auf der Grundlage dieses Technischen Konzeptes ausgeschriebenen Systeme begründet. Das Technische Konzept umfasst: Die Beschreibung der technischen Komponenten des TRANSMOBIL-Systems Die Beschreibung des technischen Anwendungskonzeptes Die Beschreibung des technischen Schnittstellenkonzeptes Die Beschreibung des technischen Sicherheitskonzeptes Dem Technischen Konzept wird die im funktionalen Konzept TRANSMOBIL (TM2) enthaltene Beschreibung der Rollen, der Kooperationsbeziehungen zwischen den Rollen und den funktionalen Prozessen (Elementarprozesse) zugrunde gelegt. Bei allen technischen Komponenten sind in den zu erarbeitenden Pflichtenheften die technischen Anforderungen analog den Angaben in den Systemlastenheften der VDV- Kernapplikation exakt zu spezifizieren. 8 / 40 I2 Intelligente Infrastruktur

9 2 Technische Komponenten des TRANSMOBIL-Systems 2.1 KVP-Komponenten KVP-Komponenten werden in folgende Terminalgruppen unterschieden: - stationäre personalbediente KVP-Terminals - stationäre selbstbediente KVP-Terminals - mobile personalbediente KVP-Terminals - mobile selbstbediente KVP-Terminals Stationäre personalbediente KVP-Terminals sind in Verkaufs- oder Servicestellen eingesetzt. Sie können auch zur Systemadministration oder für weitergehende Geschäftsprozesse eines KVP genutzt werden. An einem stationären personalbedienten Terminal können alle beschriebenen Anwendungsfälle ausgeführt werden. Der Nutzer legitimiert sich mit seinem Nutzermedium. Bei der Bearbeitung von personenbezogenen Daten muss der Nutzer seine PIN angeben. Darüber hinaus können weitere Servicefunktionen wie z.b. Klärung von Sperrungen, Entsperrungen, Änderungen von personenbezogenen Daten durchgeführt werden. Stationäre personalbediente Terminals enthalten einen SAM, um den erforderlichen Sicherheitsstandard zu gewährleisten. Stationäre selbstbediente Terminals sind ortsfeste, selbstbediente Akzeptanzerminals, die entsprechend ihrer Aufgaben spezialisiert sein können (Berechtigungsausgabe- oder rücknahmeterminals). Der Nutzer identifiziert sich dadurch, dass er sein Nutzermedium an die Fläche des Kartenlesers hält. Nur beim Zugang zu personenbezogenen Daten wird der Nutzer zur Eingabe seiner PIN aufgefordert. Das Terminal enthält einen SAM, um den erforderlichen Sicherheitsstandard beim Datenaustausch zu gewährleisten. Mobile personalbediente KVP-Terminals sind als Fahrerterminal oder als Terminal des Zugbegleiters im Fernverkehr umgesetzt. Sie können auch für den mobilen Ticketverkauf (EFS) an Schwerpunkthaltestellen eingesetzt werden. Mobile selbstbediente KVP-Terminals sind als Verkaufsautomaten in Fahrzeugen eingesetzt. Mobile Verkaufsterminals haben eine eingeschränkte Funktionalität, da keine permanente Verbindung zum Hintergrundsystem vorhanden ist. Ein NFC-Handy (mit der VDV-Kernapplikation) kann die Funktionen eines mobilen Verkaufsterminals (evtl. mit Einschränkungen) übernehmen, wenn es über eine gesicherte Internetverbindung mit einem Referenzsystem des KVP verbunden wird. Zu den KVP-Komponenten werden auch die Hintergrundsysteme gezählt. Die Hintergrundsysteme werden unterschieden in: - Hintergrundsystem des Primär-KVP (PKVP) - Hintergrundsystem des Fremd-KVP (FKVP) I2- Intelligente Infrastruktur 9 / 40

10 Für eine eindeutige Zuordnung in der Spezifikation ist es notwendig, bei der Rolle des Kundenvertragspartners eine Spezialisierung als Primär-KVP und Fremd-KVP einzuführen. Der Primär-KVP ist derjenige KVP, der die Applikation/Berechtigung/WEB selbst an den Kunden ausgegeben hat. Im Falle der KOB führt es das zugehörige POB/PEB-Konto. Der Primar-KVP ist gegenüber dem Kunden der ständige Vertragspartner für die Teilnahme des Kunden am EFM-System. Im Gegensatz dazu ist der Fremd-KVP derjenige, bei dem der Kunde zeitweise Fahrberechtigungen erwirbt. Mit ihm entsteht nur ein temporäres Vertragsverhältnis für die Dauer der Gültigkeit der erworbenen Berechtigung. 2.2 DL-Komponenten Dienstleister-Komponenten werden in nach ihrer technischen Ausführung in Proximity- Terminals oder in Raumerfassungsterminals unterschieden. Proximity-Erfassungs-Terminals arbeiten kontaktlos mit einer Reichweite von 3 5 cm zum Nutzermedium und werden stationär im Zugangsbereich zu Verkehrsmitteln an Haltestellen und/oder auf Bahnhöfen, sowie mobil in Fahrzeugen (Bussen und Straßen- bzw. Stadtbahnen) eingesetzt. Ein Proximity-Erfassungs-Terminal wird in IN-/OUT-Systeme vor dem/beim Einstieg (CI) und beim/nach dem Ausstieg (CO) zur Datenerfassung, Auswertung und automatisierten Fahrpreiserhebung benötigt Das Terminal soll sowohl für den CI als auch den CO benutzt werden. CICO-Terminals sollen keine Tasten haben und keine zusätzlichen manuellen Bedienaktivitäten erfordern In Systemen, die den EFS umsetzen, werden sie für Entwertungsprozesse mobil (handheld oder im Fahrzeug) bzw. stationär eingesetzt. Raumerfassungs-Terminals arbeiten kontaktlos mit einer Reichweite von mehreren Metern mit den Nutzermedium. Bei Raumerfassung werden spezielle Nutzermedien benötigt, die die Kommunikation über diese Distanzen gewährleisten. Sie werden in Fahrzeugen (Busse und Straßen- bzw. Stadtbahnen, Fahrzeugen des Regional- und Fernverkehrs) eingesetzt. Raumerfassungsterminals können integriert als Bestandteil eines Fahrzeugbordrechners ausgeführt sein. Sie werden in IN-/OUT-Systemen zur Datenerfassung, -auswertung und zur automatisierten Fahrpreiserhebung benötigt. 10 / 40 I2 Intelligente Infrastruktur

11 2.3 PV-Komponenten Das Produktverantwortlichen-System, hier als Produktverantwortlichensystem-Server (PVS) bezeichnet, stellt die Hintergrundsystemkomponente eines EFM-Systems dar, die für ein oder mehrere separate KA-konforme EFM-Systeme die Aufgaben des Produktverantwortlichen ausführt. Aufgaben und Prozesse des PVS können auf einem eigenständigen Rechnersystem oder integriert in einem KA-konformen Hintergrundsystem ablaufen, das mehrere Referenzsystemkomponenten vereint. 2.4 AHSM-Komponenten Das Applikationsherausgeber-Sicherheitsmanagement-System, hier als Applikationsherausgeber-Sicherheitsmanagement--Server (AHSM) bezeichnet, stellt die Hintergrundsystemkomponente eines EFM-Systems dar, die alle sicherheitsrelevanten Aufgaben des Applikationsmanagements ausführt. Es registriert alle sicherheitsrelevanten Informationen/Daten zu den am KA Gesamtsystem beteiligten Organisationen. Aufgaben und Prozesse des AHSM können auf einem eigenständigen Rechnersystem oder integriert in einem KA-Hintergrundsystem ablaufen, das mehrere Referenzsystemkomponenten vereint. 2.5 AHSS-Komponenten Das Applikationsherausgeber-Sperrenservice-System, stellt eine spezielle Form der Hintergrundsystemkomponente eines Applikationsherausgeber-Systems dar, die alle Aufgaben des Sperrlistenmanagements ausführt. Sicherheitsrelevante Systemkomponenten und Objekte (z. B. Nutzermedium, Terminals, etc.) müssen gesperrt werden können, damit sie innerhalb der VDV-Kernapplikation nicht missbräuchlich oder zum Schaden Unbeteiligter eingesetzt werden können. Dies bedingt ein komplexes Management von Sperrungen. Da die VDV-Kernapplikation Österreichweit eingeführt werden soll, müssen unter Umständen sehr große Sperrlisten zeitgerecht erstellt und zuverlässig verteilt werden. Der Suchvorgang in der Liste soll im Akzeptanzterminal die Transaktionszeit mit einem Nutzermedium nicht unnötig verlängern. Dies bedingt ein optimiertes Sperrkonzept zur Minimierung der benötigten Sperrlisteneinträge. I2- Intelligente Infrastruktur 11 / 40

12 2.6 TAPRIS-Komponenten Das TAPRIS-System (TRANSMOBIL AUSTRIA ProzessIntegrationsSystem = TAPRIS) verbindet die Terminal- und Hintergrundsysteme der einzelnen Partner derart miteinander, dass für die einzelnen Unternehmen gesichert wird, dass die Prozesssteuerung und die Integration der Prozesse einheitlich und weitgehend automatisiert ablaufen. Die TAPRIS- Komponenten sollen es dabei ermöglichen, dass die beteiligten Unternehmen ohne komplexe IT-Systeme auskommen und kein speziell qualifiziertes IT-Personal benötigen. Alle Unternehmen müssen ihre Rollen in gleicher Weise und gleichbleibend hoher Qualität wahrnehmen, um den stabilen produktiven Betrieb des Gesamtsystems zu sichern. Um die Interoperabilität im System zu gewährleisten, müssen die Rollen gemäß der Beschreibung im Funktionalen Konzept (TM AP 200) in vielfältiger Weise miteinander kommunizieren. Jeder PKVP muss mit jedem PV, mit jedem AHSS Daten austauschen. Jeder FKVP muss mit jedem PV, mit dem AHSS Daten austauschen. Jeder DL muss mit jedem PV, mit dem AHSS Daten austauschen. Jeder PV muss zusätzlich mit dem AHSS Daten austauschen. Jeder AHSS muss darüber hinaus mit dem AH Daten austauschen. Um die Erfüllbarkeit dieser Anforderung gewährleisten zu können, müssen die potenziellen Möglichkeiten der kleinen Unternehmen als Maßstab herangezogen werden. Das technische Konzept muss so gestaltet sein, dass auch diese Unternehmen die Anforderungen erfüllen können. Die TAPRIS-Komponenten erfüllen diese Forderungen durch komplexe Integrationsprozesse: - Integration von Terminal- und Hintergrundsystemen - Integration von IT-Services - Integration der Hintergrundsysteme des AH - Integration regionaler Frameworks - Integration des AHSS Eine detaillierte Beschreibung dieser Integrationsprozesse ist in der Anlage 1 zu diesem Dokument beigefügt. 12 / 40 I2 Intelligente Infrastruktur

13 3 Technisches Anwendungskonzept 3.1 Anwendungskonzept für KVP-Komponenten An KVP-Terminals sind aus den spezifizierten Elementarprozessen des funktionalen Konzeptes (Kap. 3.2) alle relevanten Anwendungsfälle zu realisieren. Aus den Anwendungsfällen resultieren Terminalfunktionen, die in den physisch zu installierenden Terminals eines realen EFM-Systems ausgeführt werden. Die Hard- und Softwareanforderungen sind jeweils unter den Gesichtspunkten der Sicherstellung der Voraussetzung für das interoperable Zusammenwirken der EFM 1 -Systemstufen - Bargeldloses Bezahlen mit einem interoperablen ÖPV-Werteinheitenspeicher (WEB) oder Akzeptanz einer KOB (Konto-Berechtigung), d.h. Akzeptanz von Post-paid- (POB) bzw. Pre-paid-Berechtigungen (PEB) - Elektronischer Fahrschein (EFS) im Datenformat der VDV-Kernapplikation als manuell vorausgewählte, fest definierte Fahrtberechtigung - Automatisierte Fahrpreiserhebung mittels aktiver An- und Abmeldung des Fahrgastes (Check-in) oder Anwesenheitserfassung ohne aktive Fahrgasthandlung (Be-in/ Beout) Die auf den KVP-Terminals auszuführenden Anwendungsfälle sind: - Anwendungsfälle zur Applikation - Anwendungsfälle zum EFS - Anwendungsfälle zur KOB - Anwendungsfälle zum WEB - Anwendungsfälle zum Systemorganisation Eine detaillierte Beschreibung der auszuführenden Anwendungsfälle ist in den aufgeführten Dokumenten der VDV-Kernapplikation beschrieben: - Systemlastenheft Teil: Stationäre personalbediente KVP-Terminals SYSLH_SPKVP_V1.1 - Systemlastenheft Teil: Mobile personalbediente KVP-Terminals SYSLH_MPKVP_V1.1 - Systemlastenheft Teil: Stationäre selbstbediente KVP-Terminals SYSLH_SSBKVP_V1.1 - Systemlastenheft Teil: Mobile selbstbediente KVP-Terminals SYSLH_MSBKVP_V1.1 I2- Intelligente Infrastruktur 13 / 40

14 Das Kundenvertragspartner-System, auch als Kundenvertragspartnersystem-Server (KVPS) bezeichnet, stellt die Hintergrundsystemkomponente eines EFM-Systems dar, die für ein oder mehrere separate KA-konforme EFM-Systeme die Aufgaben des Kundenvertragspartners ausführt. Das KVPS übernimmt die Ausgabe und den Vertrieb der Applikation und ihrer Berechtigungen an seinen Terminals. Es sichert den Kundenservice auf Grundlage der eingehenden Informationen von den angeschlossenen Systemen und stellt sie den Kunden an seinen angeschlossenen Terminals zur Verfügung. Aufgaben und Prozesse des KVPS können auf einem eigenständigen Rechnersystem oder integriert in einem KA-Hintergrundsystem ablaufen, das mehrere Referenzsystemkomponenten vereint. 3.2 Anwendungskonzept für DL-Komponenten An den Dienstleisterterminals sind aus den spezifizierten Elementarprozessen die relevanten Anwendungsfälle zu realisieren: - Erfassung - Kontrolle - Entwertung Die auf den DL-Terminals auszuführenden Anwendungsfälle sind: - Anwendungsfälle zur Applikation - Anwendungsfälle zum EFS - Anwendungsfälle zur KOB - Anwendungsfälle zum WEB - Anwendungsfälle zus Systemorganisation Eine detaillierte Beschreibung der auszuführenden Anwendungsfälle ist in den aufgeführten Dokumenten der VDV-Kernapplikation beschrieben: - Systemlastenheft Teil: Proximity-Erfassungsterminal des DL SYSLH_ProxDL_V11 - Systemlastenheft Teil: Raumerfassungsterminals des DL SYSLH_ReDL_V11 Die in diesem Dokument beschriebenen, auf dem System eines Kundenvertragspartners zu realisierenden, Anwendungsfälle basieren auf der im Dokument Schnittstellenspezifikation der Referenzsysteme KA Spec_SST_V1.1 enthaltenen Beschreibung der im KA-Referenzsystem ablaufenden Elementarprozesse. Die Anwendungsfälle stellen die auf dem KVP-System ablaufenden Teilprozesse dar. Die Teilprozesse sind über die ebenfalls in dem o. g. Dokument beschriebenen Schnittstellen miteinander verbunden. Die über die Schnittstellen auszutauschenden Basisdatensätze sind in den Anwendungsfallbeschreibungen referenziert. 14 / 40 I2 Intelligente Infrastruktur

15 3.3 Anwendungskonzept für PV-Komponenten Das PVS übernimmt die Ausgabe von Produkten bzw. Werteinheitenspeicher und aller damit verbundener Aufgaben wie z.b. die Erstellung und Bereitstellung der dafür erforderlichen Templates, der Produktmodule, die die Tarifberechnung sicherstellen und der Kontrollmodule, die eine weitgehend automatisierte Kontrolle der Produkte mit den Kontrollterminals sicherstellen. Das PVS übernimmt das Clearing für die unter dem Produkt ausgegebenen Berechtigungen (bzw. als WES-PV für die ausgegebenen WES) auf der Basis der eingereichten Transaktionsdaten mit dem Nutzermedium. Die auf dem System eines Produktverantwortlichen zu realisierenden Anwendungsfälle basieren auf der im Dokument: Schnittstellenspezifikation der Referenzsysteme KA Spec_SST_V1.1 enthaltenen Beschreibung der im KA-Referenzsystem ablaufenden Elementarprozesse. Die Anwendungsfälle stellen die auf dem PV-System ablaufenden Teilprozesse dar. Die Teilprozesse sind über die ebenfalls in dem o. g. Dokument beschriebenen Schnittstellen miteinander verbunden. Die über die Schnittstellen auszutauschenden Basisdatensätze sind in den Anwendungsfallbeschreibungen referenziert. 3.4 Anwendungskonzept für AHSM-Komponenten Das AHSM (Applikationsherausgeber-Sicherheitsmanagement-System) regelt die Verwaltung der im System verteilten SAM und Keys für die TRANSMOBIL-Applikation und führt die relevanten Daten dazu in seinem Serversystem. Damit ist der Applikationsherausgeber verantwortlich für das Sicherheitsrisiko, das mit dem Betreiben der unter seiner Regie herausgegebenen Applikationen besteht. Die beschriebenen, auf dem System eines Applikationsherausgebers zu realisierenden, Anwendungsfälle basieren auf der im Dokument Schnittstellenspezifikation der Referenzsysteme KA Spec_SST_V1.1 enthaltenen Beschreibung der im KA-Referenzsystem ablaufenden Elementarprozesse. Die Anwendungsfälle stellen die auf dem AH-System ablaufenden Teilprozesse dar. Die Teilprozesse sind über die ebenfalls in dem o. g. Dokument beschriebenen Schnittstellen miteinander verbunden. Die über die Schnittstellen auszutauschenden Basisdatensätze sind in den Anwendungsfallbeschreibungen referenziert. I2- Intelligente Infrastruktur 15 / 40

16 3.5 Anwendungskonzept für AHSS-Komponenten Das AHSS (Applikationsherausgeber-Sperrenservice-System), stellt die Hintergrundsystemkomponente eines EFM-Systems dar, die für ein oder mehrere separate KA-konforme EFM- Systeme die Aufgaben des Sperrlistenmanagements ausführt. Das AHSS übernimmt die Sperrlistenverwaltung und- bereitstellung für die angeschlossenen Systeme. Es aktualisiert die Sperrlisten auf Grundlage der eingehenden Informationen von den angeschlossenen Systemen und stellt diese zur Abholung durch den KVP, DL und PV zur Übernahme bereit. Es registriert den Sperrlistenversand entsprechend der Abforderung durch andere KA- Systeme. Es muss durch organisatorische und vertragliche Maßnahmen geregelt werden, dass einheitliche Sperrlisten existieren. 3.6 Anwendungskonzept für TAPRIS-Komponenten Das TAPRIS-System muss neben multivalent einsetzbaren Komponenten zur Kommunikations- und Prozess-Steuerung ggf. auch anwendungsspezifische Komponenten integrieren können. Zu den anwendungsspezifischen Komponenten zählen die Integrationsprozesse und die anwendungsspezifischen Schnittstellen-Adapter. Die Kommunikation der Terminal- und Hintergrund-Systeme mit dem Integrations- Framework erfolgt direkt über die Web Service -Schnittstelle oder über einen Schnittstellen- Manager. Der Schnittstellen-Manager eines Integrations-Frameworks muss ggf. aus mehreren dezentralen Komponenten bestehen können. Der Schnittstellen-Manager muss mehrere Schnittstellen zu den Terminal-Systemen und den Hintergrund-Systemen bereitstellen können. Für diese Schnittstellen muss der Schnittstellen-Manager entsprechende Schnittstellen- Adapter bereitstellen, die eine Schnittstellen-Konvertierung zwischen den Schnittstellen der Terminal- und Hintergrund-Systeme und der einheitlichen, internen Web Service - Schnittstelle des Integrations-Frameworks realisieren. Es muss mindestens ein Schnittstellen-Adapter für den Austausch von Dateien und ein Schnittstellen-Adapter für eine externe Web Service -Schnittstelle bereitgestellt werden. Der Schnittstellen-Adapter für die externe Web Service -Schnittstelle kann auch direkter Bestandteil des Integrations-Managers sein. Es muss möglich sein, weitere, projektspezifische Schnittstellen-Adapter zu integrieren. Die Schnittstellen-Adapter sind in der Anlage 1 näher beschrieben. 16 / 40 I2 Intelligente Infrastruktur

17 4 Technisches Schnittstellenkonzept 4.1 Nutzermedium-Terminal-Schnittstelle Das Nutzermedium stellt Schnittstellen zum Zugriff von Referenz-Terminals auf die Kernapplikation bereit. Auf der Applikationsebene wird eine Schnittstelle SST_NM=RT bereitgestellt. Diese Schnittstelle wird auf technischer Ebene spezialisiert in: Kontakt-Schnittstelle SST_NM=RT_Kontakt, Proximity-Schnittstelle SST_NM=RT_Proximity Raumerfassungs-Schnittstelle SST_NM=RT_Raumerfassung. Die Transaktionen, die das Nutzermedium einbinden, sind beschrieben in Schnittstellenspezifikation der Referenzsysteme KA Spec_SST_V Sicherheitsmodul-Terminal-Schnittstelle Der SAM stellt Schnittstellen zum Zugriff von Referenz-Terminals des Kundenvertragspartners und des Dienstleisters auf die SAM-Applikation bereit. Auf der Applikationsebene wird eine Schnittstelle SST_SAM=RT-KVP bereitgestellt, über die alle Verkaufs-, Service- und Sperr-Prozesse der Referenzterminal_KVP mit dem SAM realisiert werden: - Verkauf - Erstattung - Sperrung - Entsperrung - Service - Rücknahme - Ausgabe - Änderung - Konfiguration Bei einem Zugriff auf ein Referenz-Terminal des Dienstleisters wird auf der Applikationsebene eine Schnittstelle SST_SAM=RT-DL bereitgestellt, über die alle Erfassungs- und Kontrollprozesse: - Erfassung - Entwertung - Kontrolle - Sperrung - Konfiguration der Referenzterminal_DL mit dem SAM realisiert werden. Die Transaktionen, die das SAM einbinden, sind beschrieben in Schnittstellenspezifikation der Referenzsysteme KA Spec_SST_V1.1 Die vollständige Spezifikation des SAM und dessen Schnittstellen sind zu entnehmen: Spezifikation des SAM KA SAM_SPEC_V1.1 I2- Intelligente Infrastruktur 17 / 40

18 4.3 Terminal-Hintergrundsystem-Schnittstelle Die Schnittstellen zwischen Terminal und Hintergrundsystem werden nach Art des jeweiligen Referenz-Systems unterschieden. Die Referenz-Systeme erzeugen bzw. verarbeiten die mit den anderen Referenzsystemen auszutauschenden Daten. Das ReferenzSystem_KVP nutzt folgende Schnittstellen Schnittstelle SST_AHSM=KVP SST_PV=KVP SST_AHSS=KVP Datenaustausch mit einem ReferenzSystem_AHSM einem ReferenzSystem_PV einem Referenz-System_AHSS Das ReferenzSystem_DL nutzt die folgenden Schnittstellen Schnittstelle SST_AHSM=DL SST_PV=DL SST_AHSS=DL Datenaustausch mit einem ReferenzSystem_AHSM einem ReferenzSystem_PV einem Referenz-System_AHSS Das ReferenzSystem_PV nutz folgende Schnittstellen Schnittstelle SST_AHSM=PV SST_PV=KVP SST_AHSS=PV SST_PV=DL Datenaustausch mit einem ReferenzSystem_AHSM einem ReferenzSystem_KVP einem Referenz-System_AHSS einem ReferenzSystem_DL Das ReferenzSystem_AHSM nutzt folgende Schnittstellen Schnittstelle SST_AHSM=KVP SST_AHSM=DL SST_AHSS=AHSM SST_AHSM=PV Datenaustausch mit einem ReferenzSystem_KVP einem ReferenzSystem_DL einem Referenz-System_AHSS einem ReferenzSystem_PV Das ReferenzSystem_AHSS nutzt folgende Schnittstellen Schnittstelle SST_AHSS=PV SST_AHSS=DL SST_AHSS=AHSM SST_AHSS=PV Datenaustausch mit einem ReferenzSystem_KVP einem ReferenzSystem_DL einem Referenz-System_AHSM einem ReferenzSystem_PV Referenzen: - Transmobil 2 Funktionales Konzept - Schnittstellenspezifikation der Referenzsysteme KA Spec_SST_V / 40 I2 Intelligente Infrastruktur

19 4.4 TAPRIS-Schnittstellenkonzept Für den Nachrichtenaustausch zwischen dem Integrations-Framework und den Partner- Systemen sollen verschiedene Schnittstellentypen genutzt werden können. Einerseits sollen die Partner-Systeme Schnittstellen des Integrations-Frameworks aufrufen, d.h. als Client auftreten, können. Andererseits sollen auch die Instanzen des Integrations-Frameworks Schnittstellen der Partnersysteme aufrufen können und dabei ihrerseits als Client auftreten. Das TAPRIS-Schnittstellenkonzept basiert auf den Web-Services und unterscheidet die Schnittstellen: Web-Service zum Integrationsframework WS-IF Integrationsframework zu Integrationsframework IF-IF Adapter-Engine zu Integrationsframework AE-IF Terminal-System zu Adapter-Engine TS-AE Hintergrundsystem zu Adapter-Engine HGS-AE Terminal-System zu Hintergrundsystem TS-HGS WS-IF-Schnittstellen Ein Web Service ist eine Software-Anwendung. Ein Web Service unterstützt die direkte Interaktion mit anderen Software-Komponenten unter Verwendung XML-basierter Nachrichten durch den Austausch über internetbasierte Protokolle. Bei der Anwendung von Web Services sendet im allgemeinen ein Client-Programm eine Anfrage an den Web Service und dieser antwortet mit der gewünschten Information. Ein Web Service kann somit im übertragenen Sinne für einen Rechner als das betrachtet werden, was eine Webseite für einen Menschen darstellt. Web Services sind somit nicht für menschliche Benutzer gedacht, sondern für Softwaresysteme, die automatisiert Daten austauschen und/oder Funktionen auf entfernten Rechnern aufrufen. Das Integrations-Framework soll für die Kommunikation mit Terminal-Systemen WS- Schnittstellen bereitstellen. Es soll möglich sein, dass sowohl das Terminal-System in der Konsumenten-Rolle einen Web Service des Integrations-Frameworks aufruft, als auch dass das Integrations-Framework in der Konsumenten-Rolle einen Web Service des Terminal- Systems aufruft. Es sollen sowohl synchron als auch asynchron arbeitende Web Services aufgerufen werden können. IF-IF-Schnittstellen Bei der Kommunikation über die IF-IF-Schnittstelle ist zwischen regionalem IF und Ziel-IF zu unterscheiden. Das regionale IF nimmt die Nachrichten seiner angeschlossenen Terminalund Hintergrund-Systeme entgegen und prüft, wo die Weiterverarbeitung zu erfolgen hat. Muss die Weiterverarbeitung über ein anderes IF erfolgen fungiert das regionale IF als Proxy gegenüber seinen Terminal- und Hintergrund-Systemen und als Client gegenüber dem Ziel- IF. I2- Intelligente Infrastruktur 19 / 40

20 Die Schnittstelle zwischen dem regionalen IF und dem Ziel-IF basiert immer auf Webservices. Bei der asynchronen Kommunikation werden die Nachrichten von den Terminal- und Hintergrund-Systemen auf dem regionalen IF zwischengespeichert und später mit Hilfe eines asynchronen Webservices an das Ziel-IF weitergeleitet. AE-IF-Schnittstelle Die Schnittstelle zwischen Adapter-Engine (Schnittstellen-Manager) und Integrations- Framework dient ausschließlich der asynchronen Kommunikation zwischen beiden Systemen und wird über Webservices realisiert. Je Kommunikationsrichtung existiert jeweils ein standardisierter Webservice. TS-AE-Schnittstellen Für Terminal-Systeme, die keine Web Services bereitstellen und / oder ansprechen können, muss die Kommunikation mit dem Integrations-Framework über einen Schnittstellen- Manager erfolgen. Der Schnittstellen-Manager muss eine oder mehrere Schnittstellen zu einem Terminal-System bereitstellen können. Für diese Schnittstellen muss der Schnittstellen-Manager mindestens einen Schnittstellen-Adapter zum Austausch von Dateien mit dem Terminal-System bereitstellen. HGS-AE-Schnittstellen Für Hintergrund-Systeme, die keine Web Services bereitstellen und / oder ansprechen können, muss die Kommunikation mit dem Integrations-Framework über einen Schnittstellen- Manager erfolgen. Der Schnittstellen-Manager muss eine oder mehrere Schnittstellen zu einem Hintergrund-System bereitstellen können. Für diese Schnittstellen muss der Schnittstellen-Manager mindestens einen Schnittstellen-Adapter zum Austausch von Dateien mit dem Hintergrund-System bereitstellen. TS-HGS-Schnittstellen Die Schnittstellen zwischen Terminal-Systemen und Hintergrund-Systemen sind für die Realisierung der interoperablen Integrationsprozesse nicht relevant und damit nicht Gegenstand dieses Dokuments. Im Bedarfsfall sind derartige Schnittstellen projektspezifisch zwischen dem Auftraggeber und dem Auftragnehmer abzustimmen. 20 / 40 I2 Intelligente Infrastruktur

21 5 Technisches Sicherheitskonzept 5.1 Sicherheitskonzept für das Nutzermedium Nach der Initialisierung der ÖPV-Kernapplikation muss im Nutzermedium (NM) ein asymmetrisches Schlüsselpaar vorhanden sein. Der öffentliche Teil des RSA-Schlüsselpaares muss hierbei mit dem CV-Zertifikat eines, durch den Applikationsherausgeber zur Verfügung gestellten Trustcenters, signiert sein. Der öffentliche Trustcenterschlüssel muss ebenfalls auf dem Nutzermedium vorhanden sein. Erst hiernach können die in der KA NM-SPEC beschriebenen Prozesse ausgeführt werden. Aus sicherheitstechnischen Gründen müssen die angebotenen Chipkarten diese Schlüssel selbst erzeugen können. Die Qualität des erzeugten Schlüsselpaares und der Zeitbedarf sind zu dokumentieren. Alternativ kann über einen Transportkey, der mit dem Trustcenter zu vereinbaren ist und für dessen sicherer Einbringung der Hersteller eine Akkreditierung nachweisen muss, dass Schlüsselpaar inklusive Zertifikat auf das Nutzermedium verschlüsselt übertragen werden. Das Nutzermedium hat dieses Kryptogramm zu entschlüsseln und die Schlüssel und das Zertifikat mit den entsprechenden Zugriffsberechtigungen an den entsprechenden Speicherplätzen abzulegen. Dieser Prozess kann bei entsprechender Akkreditierung entsprechend dem Hersteller unabhängigen Security Target auch ohne Transportkey erfolgen. 5.2 Sicherheitskonzept für das Sicherheitsmodul Der SAM wird bereits mit den grundlegenden Schlüsseln geliefert. Ergänzende Schlüssel müssen aus den Prozessen - gegen Manipulation gesichert (tamper proofed) - eingebracht werden können. Die Sicherheitsanforderungen und Verfahrensabläufe hierzu definieren die Dokumente Technisches Konzept Sicherheit KA_SPEC_SEC_V1.1 Spezifikation des SAM KA_SPEC_SAM_V1.1 Durch die das Terminal betreibende Organisationseinheit ist eine Verwaltungsdatei zu erstellen, aus der jederzeit lückenlos nachvollzogen werden kann, welcher SAM in welchem Terminal - identifiziert durch seine Terminal_ID - steckt (SAM Life Cycle Management). Geht ein SAM verloren, ist unverzüglich der Applikationsherausgeber mittels einer Sperranforderung zu informieren Anforderungen an die Hardware SAM SYSLH_SAM_V1.05 (s. Ablauf Anwendungsfall Sperranforderung_Terminal) Eine Online-Sperrung des SAM wird nicht vorgesehen. I2- Intelligente Infrastruktur 21 / 40

22 Bei Entfernen des SAM aus dem Terminal muss dieses durch einen sofortigen Spannungsverlust unbrauchbar gemacht werden (Reset). Es muss sichergestellt sein, dass für die Dauer der Freischaltung des SAM dieser seine Spannung nicht verliert, selbst und gerade bei ausgeschaltetem Terminal. 5.3 Sicherheitskonzept für Terminals Die Sicherheit kritischer Systemkomponenten wie z.b. Terminals, Erfassungsgeräte, Kontrollgeräte und Chipkarten basiert auf der Kombination physikalischer und logischer Sicherheitsmaßnahmen. Zu den physikalisch/technischen Maßnahmen gehört der Schutz der kryptographischen Schlüssel in allen Systemkomponenten, die für die sichere Kommunikation konzipiert sind. Es gelten folgende Anforderungen an die Hardware: 1. Alle Verschlüsselungen, Entschlüsselungen, Umschlüsselungen, die MAC-Bildung und alle kryptographischen Prüfungsprozeduren werden in gegen unberechtigte Zugriffe besonders geschützten Komponenten (Sicherheitsmodulen) durchgeführt. Die zugehörigen Schlüssel sind ebenfalls in solchen Sicherheitsmodulen abgelegt. 2. In Sicherheitsmodulen müssen sicherheitsrelevante Daten und Abläufe (z. B. Schlüssel, Programme) gegen unberechtigte Veränderung und geheime Daten (z. B. Schlüssel, PINs) gegen unberechtigtes Auslesen geschützt sein. Dies muss durch folgende Maßnahmen gewährleistet werden: Bauart des Sicherheitsmoduls, eventuell im Zusammenwirken mit Sicherheitsmechanismen der Software des Sicherheitsmoduls, Laden von Programmen in Sicherheitsmodule nur bei der Herstellung oder kryptographische Absicherung des Ladevorgangs, kryptographische Absicherung des Ladens von sicherheitsrelevanten Daten, insbesondere von kryptographischen Schlüsseln. Auch vor dem Auslesen mittels Angriffen, die die Zerstörung des Moduls in Kauf nehmen, müssen geheime Daten in Sicherheitsmodulen geschützt sein. 5.4 Sicherheitskonzept für TAPRIS Für TAPRIS existiert kein spezielles Sicherheitskonzept. Es gelten die allgemeinen Regeln des WEB sowie die Regelungen aus Technisches Konzept Sicherheit KA_SPEC_SEC_V / 40 I2 Intelligente Infrastruktur

23 Anhang 1 Beschreibung des System TAPRIS (TRANSMOBIL AUSTRIA ProzessIntegrationsSystem = TAPRIS) Allgemeine Anforderungen Das Organisations-Konzept und das Technische Konzept des TRANSMOBIL-Projektes sehen den Betrieb der technischen Komponenten bei einer Vielzahl von Unternehmen vor. Zur Sicherung der Interoperabilität zwischen allen am ÖPV beteiligten Partnern sind Unternehmen mit sehr unterschiedlicher Größe und sehr unterschiedlichen Ressourcen einzubeziehen. Alle diese Unternehmen müssen ihre Rollen in gleicher Weise und gleichbleibend hoher Qualität wahrnehmen, um den stabilen produktiven Betrieb des Gesamtsystems zu sichern. Um die Interoperabilität im System zu gewährleisten, müssen die Rollen in vielfältiger Weise miteinander kommunizieren. Jeder PKVP muss mit jedem PV, mit jedem AHSS Daten austauschen. Jeder FKVP muss mit jedem PV, mit dem AHSS Daten austauschen. Jeder DL muss mit jedem PV, mit dem AHSS Daten austauschen. Jeder PV muss zusätzlich mit dem AHSS Daten austauschen. Jeder AHSS muss darüber hinaus mit dem AH Daten austauschen. PKVP FKVP PV AHSS AHSM DL Abbildung 1: Kommunikation zwischen Rollen Um die Erfüllbarkeit dieser Anforderung gewährleisten zu können, müssen die potenziellen Möglichkeiten der kleinen Unternehmen als Maßstab herangezogen werden. Das technische Konzept muss so gestaltet sein, dass auch diese Unternehmen die Anforderungen erfüllen können. Da diese Unternehmen in der Regel über kein eigenes IT-Personal verfügen, bzw. nicht genügend qualifiziertes IT-Personal für den Betrieb komplexer IT-Systeme beschäftigen können, muss das IT-System so gestaltet werden, dass sich die Unternehmen auf ihre Kernaufgaben konzentrieren können und von der Administration und der Überwachung des IT- Systems entlastet bleiben. Im Hinblick auf die große Vielfalt der in hoher Frequenz ablaufenden Elementar- und Geschäftsprozesse muss das Systemkonzept vor allem so gestaltet sein, dass die einzelnen Unternehmen sowohl von der ständigen Administration der Kommunikationsverbindungen, als auch von der manuellen Steuerung und Überwachung der Prozessabläufe entlastet bleiben. I2- Intelligente Infrastruktur 23 / 40

24 Zu diesem Zweck ist ein Prozess-Integrations-System einzusetzen, das alle am TRANSMO- BIL-Projekt beteiligten Partner miteinander verbindet und den Ablauf der Integrationsprozesse sicherstellt. TAPRIS-Systemkonzept Das TRANSMOBIL AUSTRIA ProzessIntegrationsSystem (TAPRIS) soll gewährleisten, dass Terminal-Systeme (TS) und Hintergrund-Systeme (HGS) aller Betreiber mit unterschiedlichen Schnittstellen integriert werden können, dass für jedes Terminal-System (TS) und Hintergrund-System (HGS) nur eine Schnittstelle implementiert und betrieben werden muss und dass die Integrationsprozesse nicht manuell gesteuert werden müssen. Die im Rahmen der Systemintegration, der Nachrichtenkonvertierung und der Prozesssteuerung zu realisierenden Aufgaben sind durch eine oder mehrere Instanzen eines Integrations- Frameworks auszuführen. Die gegebenenfalls erforderliche Schnittstellenanpassung hat durch einzelne Instanzen eines Schnittstellen-Managers (einer Adapter-Engine) zu erfolgen. Die Terminal-Systeme mit herstellerspezifischen Schnittstellen sollen über ihre TS-AE- Schnittstelle mit dem Schnittstellen-Manager kommunizieren. Für den Schnittstellen- Manager muss ein entsprechender Schnittstellen-Adapter bereitgestellt werden. Die Hintergrund-Systeme mit herstellerspezifischen Schnittstellen sollen über ihre HGS-AE- Schnittstelle mit dem Schnittstellen-Manager kommunizieren. Auch hier muss für den Schnittstellen-Manager ein entsprechender Schnittstellen-Adapter bereitgestellt werden. Terminal-Systeme und Hintergrund-Systeme mit Web Service -Schnittstellen sollen direkt mit einem Integrations-Framework kommunizieren. Die Schnittstellen-Manager kommunizieren mit dem Integrations-Framework über eine AE- IF-Schnittstelle. Obwohl es in den meisten Fällen zweckmäßig ist, im Interesse der automatisierten Prozesssteuerung, den Nachrichtenaustausch zwischen Terminal-Systemen und Hintergrund- Systemen über das Integrations-Framework zu vollziehen, soll auch weiterhin die Möglichkeit bestehen, auf direktem Weg, über TS-HGS-Schnittstellen, zwischen Terminal-System und Hintergrund-System Daten auszutauschen. TS-Betreiber IF-Betreiber Terminal- System (TS) TS-AE-Schnittstelle AE AdapterEngine AE-IF-Schnittstelle TS/HGS-Betreiber Terminal- System (TS) TS-HGS-Schnittstelle TS-AE-Schnittstelle AE AE-IF-Schnittstelle Hintergrund- System (HGS) HGS-AE-Schnittstelle AdapterEngine Integrations Framework HGS-Betreiber Verbund_X Hintergrund- System (HGS) WS-IF-Schnittstelle TS-Betreiber Terminal- System (TS) WS-IF-Schnittstelle Abbildung 2: Integration von Terminal- und Hintergrund-Systemen 24 / 40 I2 Intelligente Infrastruktur

25 Neben den von einzelnen Unternehmen betriebenen Systemen, sollen auch die von IT- Service-Anbietern betriebenen, mandantenfähigen Hintergrund-Systeme mit ihren Funktionen und Web-Services über Schnittstellen-Manager oder direkt über die WS-IF-Schnittstelle integriert werden können. Damit besteht für die Unternehmen die Möglichkeit, den Betrieb von HGS-Funktionen teilweise oder vollständig auszulagern. Dieses Systemkonzept ermöglicht auch eine Verlagerung von IT-Funktionen während des operativen Betriebs des Gesamtsystems. Damit soll den sich ändernden Anforderungen an Funktionalität, Interoperabilität und Leistungsfähigkeit Rechnung getragen werden, ohne dass kostenintensive Modifikationen der Systemarchitektur, der Funktionsimplementierung und des Systembetriebs erforderlich werden. TS-Betreiber Terminal- System (TS) AE AE-IF-Schnittstelle TS/HGS-Betreiber Terminal- System (TS) Hintergrund- System (HGS) AE AE-IF-Schnittstelle HGS-Betreiber Hintergrund- System (HGS) WS-IF-Schnittstelle Integrations Framework Verbund_X TS-Betreiber Terminal- System (TS) WS-IF-Schnittstelle WS-IF-Schnittstellen AE AE-IF-Schnittstelle U1-HGS U2-HGS U3-HGS U4-HGS IT-Service Abbildung 3: Integration von IT-Services Die Hintergrund-Systeme des Applikationsherausgebers sollen über einen Schnittstellen- Manager oder direkt über WS-IF-Schnittstellen mit allen Integrations-Frameworks verbunden werden. I2- Intelligente Infrastruktur 25 / 40

26 Applikationsherausgeber AHSS-HGS AE AHSM-HGS Adapter Engine WS-IF-Schnittstelle AE-IF-Schnittstelle Integrations Framework Verbund_X Abbildung 4: Integration der Hintergrund-Systeme des Applikationsherausgebers Es soll die Möglichkeit bestehen, dass ein zentrales Integrations-Framework oder mehrere vernetzte Integrations-Frameworks zum Einsatz kommen. Werden mehrere, regionale Integrations-Frameworks implementiert, so sind diese untereinander zu verbinden, so dass jedes Integrations-Framework mit jedem anderen über eine IF-IF-Schnittstelle kommunizieren kann. Die einzelnen Betreiber verbinden ihre Terminal- oder Hintergrund-Systeme jeweils mit ihrem regionalen Integrations-Framework. Das dem Sender zugeordnete Integrations-Framework soll die Prozesssteuerung übernehmen. Hintergrund-Systeme, die Web- Services zur Verfügung stellen, sollen von jedem Integrations-Framework direkt angesprochen werden können. TS/HGS-Betreiber TS-Betreiber Terminal- System (TS) TS/HGS-Betreiber Terminal- System (TS) AE AE AE-IF-Schnittstelle IF-IF-Schnittstelle Integrations Framework Verbund_B AE-IF-Schnittstelle IF-IF-Schnittstelle AE Terminal- System (TS) Hintergrund- System (HGS) Hintergrund- System (HGS) Integrations Framework IF-IF-Schnittstellen Integrations Framework WS-IF-Schnittstelle HGS-Betreiber Verbund_A Verbund_C Hintergrund- System (HGS) TS-Betreiber Terminal- System (TS) WS-IF-Schnittstelle IF-IF-Schnittstelle Integrations Framework Verbund_Z IF-IF-Schnittstelle HGS-Betreiber WS-IF-Schnittstelle Hintergrund- System (HGS) Abbildung 5: Integration regionaler Integrations-Frameworks 26 / 40 I2 Intelligente Infrastruktur

27 Es soll möglich sein, einen zentralen oder mehrere regionale AHSS zu integrieren. Der oder die AHSS soll(en) ihre Sperrlisten-Management-Funktion als Web-Service bereitstellen, der über die WS-IF-Schnittstelle angesprochen werden kann. Die Integrationsprozesse des Sperrenmanagements sollen durch ein Integrations-Framework gesteuert werden. AHSS_A Sperrlisten- Management WS-IF- Schnittstelle WS-IF- Schnittstelle AHSS_B Sperrlisten- Management Sperrlisten IF-IF-Schnittstelle Integrations Framework Verbund_B IF-IF-Schnittstelle Sperrlisten Integrations Framework Verbund_A IF-IF-Schnittstelle Integrations Framework Verbund_C WS-IF- Schnittstelle IF-IF-Schnittstelle Integrations Framework IF-IF-Schnittstelle AHSS_Z Sperrlisten- Management WS-IF- Schnittstelle Verbund_Z AHSS_C Sperrlisten- Management Sperrlisten Sperrlisten Abbildung 6: AHSS-Integration Die durch das Integrations-Framework und den Schnittstellen-Manager bereitzustellenden Standard-Funktionen werden nachfolgend, die projektspezifischen Funktionen in Kapitel 3, dargestellt. Integrations-Framework Als Integrations-Framework (IF) ist ein System zu verwenden/entwickeln, das auf offenen Standards wie insbesondere SOA (Service Oriented Architecture), Web Services, SAML (Security Assertion Markup Language), WS-RM (Web Service Reliable Messaging) und BPEL (Business Process Execution Language) basiert und andererseits folgende Anforderungen erfüllt: - Realisierung von synchronen und asynchronen Schnittstellen zum Nachrichtenaustausch zwischen den beteiligten Komponenten von TRANSMOBIL Austria. - Routing der Nachrichten vom Sender zum Empfänger - Transformation der Nachrichten vom Quell- zum Zielformat - Gewährleistung der Sicherheit (Vertraulichkeit, Integrität und Authentizität) bei der Übertragung der Nachrichten durch Authentifizierung, Verschlüsselung und Signatur, sowie Gewährleistung einer definierten Dienstqualität (EO, EOIO) - Definition, Anstoß und Überwachung von Geschäftsprozessen - Monitoring aller Aktivitäten des Gesamtsystems (Schnittstellen, Queues und Prozesse) - Automatische Information der Administratoren des IF (Alerting) I2- Intelligente Infrastruktur 27 / 40

28 - Betriebssteuerung (Nutzerverwaltung, Prozessverwaltung, Queueverwaltung, Konfiguration usw.) - Realisierung mehrerer Mandanten auf einem System - Skalierbarkeit - Gewährleistung der Revisionssicherheit durch Logging aller Aktivitäten des IF - Automatische Archivierung durchgeführter Transaktionen Zur Umsetzung dieser Anforderungen sind folgende Bestandteile für ein IF erforderlich: Bestandteile zur Umsetzung der Grundfunktionalität: - Integrations-Manager - Geschäftsprozess-Manager - Schnittstellen-Manager - Prozessdaten-Manager - Prozessdaten-Sicherung Bestandteile zur Verwaltung und Steuerung des Systems: - Queue-Manager - Verzeichnisdienst - Monitorsystem - Konfigurations-Manager - Administrationswerkzeuge - Entwicklungssystem (für Prozesse, Datentransformationen ) Partner- System Geschäftsprozess- Manager Partner- System Partner- System Partner- System Schnittstellen- Manager Integrations- Manager Prozessdaten- Manager Prozessdaten- Sicherung Abbildung 7: Zusammenspiel der Bestandteile der Grundfunktionalität des IF Die Kommunikation des IF mit Partner-Systemen soll entweder direkt über den Integrations- Manager oder über einen Schnittstellen-Manager erfolgen. Partner-Systeme aus Sicht des IF sind die FKVP-Sysyteme, die PKVP-Systeme, die AH-Systeme, die AHSS-Systeme und die DL-Systeme. Partner-Systeme können aber auch andere IFs sein. Der Integraqtion-Manager soll mit den Partner-Systemen immer direkt über Web Services kommunizieren. Ist eine Kommunikation über Web Services nicht möglich, muss die Kommunikation über den 28 / 40 I2 Intelligente Infrastruktur

29 Schnittstellen-Manager erfolgen. Der Schnittstellen-Manager soll hierzu Schnittstellenadapter für verschiedene Protokolle (FTP, SMTP, JMS, OSCI,...) zur Verfügung stellen. Die Schnittstellenadapter sollen eingehende Nachrichten an den Integration-Manager weiterleiten. Die Kommunikation mit den Partner-Systemen kann sowohl gesichert als auch ungesichert erfolgen. Um die gesicherte Kommunikation zu gewährleisten, sollen durch das IF entsprechende Standards wie SSL V3 und SAML eingesetzt werden. Der Integration-Manager ist die Verarbeitungszentrale des IF. Er steuert in Zusammenarbeitet mit dem Prozessdaten-Manager die Konvertierung eingehender Nachrichten (u.a. mit XSLT) in vordefinierte Zielformate und leitet die konvertierten Nachrichten an definierte Empfangssysteme weiter. Dazu kommuniziert der Integration-Manager entweder direkt über Web Services mit den Empfangssystemen oder über den Schnittstellen-Manager, wenn die Kommunikation über andere Protokolle erfolgt. Zur Ermittlung der Adressinformationen für die Weiterleitung der Nachrichten an die Empfangssysteme soll sich der Integration-Manager eines replizierbaren Verzeichnisdienstes bedienen. Der Verzeichnisdienst soll auf Basis von UDDI (Universal Description, Discovery and Integration) arbeiten und über das eindeutige Kennzeichen eines jeden Empfangssystems sowie über Dienstenamen die notwendigen Daten für die Versendung ermitteln. Diese Informationen sollen in Form von WSDL (Web Service Description Language) geliefert werden. Ist die Verarbeitung der eingehenden Nachrichten komplexerer Natur (IF muss z. B. mit mehreren Empfangssystemen kommunizieren und die Informationen anschließend konsolidieren) so soll die Verarbeitung der Nachricht an den Geschäftsprozess-Manager übergeben werden. Dieser soll die Verarbeitung anhand von in BPEL definierten Geschäftsprozessen steuern. Als Bindeglied in der internen Kommunikation zwischen Schnittstellen-, Integration-, Prozessdaten- und Geschäftsprozess-Manager sollen persistente Queues dienen, die durch den Queuemanager verwaltet werden. So soll sichergestellt werden, dass das IF empfangene Nachrichten auch nach Systemneustart weiterverarbeiten kann. Gleichzeitig soll durch den Queuemanager sichergestellt werden, dass die Verarbeitung der Nachrichten in der Dienstqualität Exactly Once oder Exactly Once in Order erfolgt. Alle Aktivitäten der Komponenten des IF sollen umfangreich geloggt werden und sollen mit Hilfe des Monitorsystems durch die Systemadministratoren des IF überwacht werden können. Neben dem Monitoring sollen den Administratoren auch Werkzeuge zur Konfiguration des IF sowie zur Versionsverwaltung von Objekten des IF (Konfigurationsmanager) zur Verfügung stehen. Für die Definition von Geschäftsprozessen, Datentransformationen und anderer Objekte soll das IF den Entwicklern entsprechende Werkzeuge zur Verfügung stellen, die auch die graphische Erzeugung solcher Objekte unterstützen. I2- Intelligente Infrastruktur 29 / 40

30 Schnittstellen-Manager Der Schnittstellen-Manager ist ein Standardprozess, der auf Basis der Java Runtime über standardisierte Web Services mit dem IF kommuniziert. Der Schnittstellen-Manager kann in Kooperation mit allen TMA-Partner-Systemen, die keine Web Service-Schnittstelle zum TAPRIS zur Verfügung stellen, für die asynchrone Kommunikation zum Einsatz kommen. Als Schnittstelle zwischen Partner-System und Schnittstellen-Manager ist standardmäßig eine Datei-Schnittstelle (Transferverzeichnisse) zu verwenden, die über einen entsprechenden Schnittstellen-Adapter versorgt wird. Schnittstellen-Manager Partner- System Transferverzeichnisse Schnittstellen- Adapter Standardisierte Webservices TAPRIS Transformator Abbildung 8: Kommunikation über Schnittstellen-Manager Der Schnittstellen-Manager benutzt für die eingangsseitige externe Kommunikation mit dem IF einen Web Service-Schnittstellenadapter. Dieser Adapter besteht aus einem Mini- Webserver, der einen Web Service für die Kommunikation mit dem TAPRIS zur Verfügung stellt. Die Daten, die über diesen Web Service empfangen werden, werden in eine XML- Datei extrahiert und im jeweiligen Zielverzeichnis abgelegt. Die Identifikation des Zielverzeichnisses erfolgt über eine vom Web Service übergebene Information des Empfangsadapterkanals und einer in der Konfiguration des Schnittstellen-Managers hinterlegten Zuordnung von Adapterkanälen zu Verzeichnissen. Die Weiterverarbeitung der abgelegten Dateien soll über den Schnittstellen-Adapter des Partner-Systems erfolgen. Schnittstellen-Manager SS-WS-FP-IF File- Prozessor Loggingprozessor Konfiguraton TAPRIS Mini- Webserver SS-WS-IF-MWS Ausgangsverzeichnisse 1.. n Eingangsverzeichnisse 1.. n Abbildung 9: Bestandteile des Schnittstellen-Managers 30 / 40 I2 Intelligente Infrastruktur

31 Ausgangsseitig steuert der Schnittstellen-Manager über einen Datei-Schnittstellen-Adapter das Versenden von Nachrichten an das IF. Der Adapter ist ein File-Prozessor, der seine Ausgabeverzeichnisse regelmäßig auf zu versendende XML-Files prüft (Polling). Die gefundenen Dateien werden durch den File-Prozessor mit Hilfe eines vom IF zur Verfügung gestellten Web Service versendet. Hierzu wird die übergebene XML-Datei in die Payload des Web Service übernommen und der Web Service mit dem Ausgangsadapterkanal parametrisiert. Die Ermittlung des Ausgangsadapterkanals soll über die in der Konfiguration des Schnittstellen-Managers hinterlegte Zuordnung von Verzeichnissen zu Adapterkanälen (Abbildung 9) erfolgen. Für den Fall, dass die Partner-Systeme mit proprietären Dateiformaten arbeiten, soll es möglich sein, an die Schnittstellen-Adapter Transformatoren, die das gewünschte Dateiformat erzeugen, anzuschließen (Abbildung 8). Alle Aktivitäten des Schnittstellen-Managers sollen durch einen Loggingprozessor aufgezeichnet und durch den Administrator ausgewertet werden können. Für die Konfiguration des Schnittstellen-Managers steht ein Aministrationswerkzeug zur Verfügung. Hiermit kann der Administrator Eingangs- und Ausgangsverzeichnissen Adapterkanälen zuordnen und Schnittstellen-Adapter mit Datentransformatoren verbinden. Beim Transport der Daten über die Web Services ist zur Wahrung der Vertraulichkeit in der Transportebene SLL V3 zu benutzen. Zusätzlich können in der Payload des jeweiligen Web Services, falls erforderlich, weitere Sicherheitsstandards wie SAML, für die Authentifizierung, oder WS-RM, für die Sicherung der Dienstqualität, zur Anwendung kommen. Integrationsprozesse Die in TM2 AP100 beschriebenen Funktionalen Prozesse müssen unter Einbeziehung unterschiedlicher Komponenten des TRANSMOBIL -Systems ablaufen und dabei verschiedene Schnittstellen nutzen. In TM2 AP100 wurden nur solche Prozesse behandelt, die keine weitere logische Untergliederung zulassen. Funktionale Prozesse, die sich aus mehreren Teilprozessen durch Kombination ergeben (z.b. Verkauf eines EFS mit Abrechnung über ein KOB-Konto), wurden in TM2 AP100 nicht explizit beschrieben, sind jedoch bei der Systemeinführung in vollem Umfang zu implementieren. Dadurch werden zumindest teilweise komplexe Geschäftsprozesse zu steuern und zu überwachen sein. Angesichts der Häufigkeit des Ablaufs der einzelnen Geschäftsprozesse ist leicht zu erkennen, dass nur durch eine automatisierte Steuerung und Überwachung dieser Geschäftsprozesse die für zahlungsrelevante Transaktionen erforderliche Zuverlässigkeit zu erreichen sein wird. Damit ergibt sich die Anforderung, die Ablaufsteuerung und das Monitoring derartiger Geschäftsprozesse durch die Implementierung von Integrationsprozessen und Alerting-Regeln automatisieren zu können. Das TAPRIS-System muss deshalb die Möglichkeit bieten, derartige Integrationsprozesse definieren, implementieren und durch eingehende Nachrichten starten zu können. Die Prozesssteuerung muss alle erforderlichen Prozessschritte abarbeiten, Ergebnisse und Termine überwachen, sowie Abweichungen vom definierten Sollzustand signalisieren können. I2- Intelligente Infrastruktur 31 / 40