The objective of this task is to define and implement the validation use-case according to the architecture and designs specified in the preceding tasks. This demanding use case is produced in order to carry out the proofs of concept and is also used to gather requirements necessary to the task 1. Reports are produced in order to provide clear feedback on and evaluation of elements.
This use case, which is based on every-day-life scenarios, targets the subsequent assessment of the technology w.r.t real requirements and industrial needs for a shorter time-to-market delay.
The following figure picture the context of the use case:
During the design phase, real systems and simulators for independent systems are identified and selected. These systems/simulators may include:
* Central Clearing House Systems (CCHS), which are in charge of redistributing revenues collected by the ticketing and merchant systems between the different participants
* Ticketing Systems, which are usually operated by transport companies. The CCHS downloads operating parameters to ticketing systems, e.g. ticketing keys, topology, timetables, fare products, tariffs, blacklists of cards and equipments, action lists regarding Internet sales… The CCHS receives from the ticketing systems transaction files, audit registers, event logs, and real-time warnings and alarms from on-line sales and validation devices…
* ERPs, which are operated by transport companies. The CCHS receives from each transport company ERP the operating data applicable to this transport company but also to some other transport companies in case of interoperability between transport networks. Usually ERPs are providing data resulting from resource management and allocation, e.g. network topology, timetables, vehicles, drivers, and other company employees such as maintenance agents, cashiers, and account managers… The CCHS can export to the transport company ERP the same kind of data with or without company-related filtering.
* Accounting Systems, which are operated by transport companies. The CCHS exports to the transport company accounting system reports related to sales and refunds, drivers and agents accounts, bank transfers, reconciliation audits…
- Banks and Credit Card Companies, which are dependent on national regulations. The CCHS provides facility for on-line payments, debit of bank accounts and credit cards resulting from card top-ups and auto-renewal of fare products… The CCHS can also initiate bank transfers (resulting from revenue distribution) between transport company bank accounts.
- Customer Website, which allows the registration of customers and the ordering of transport cards and fare products with on-line payment and/or deferred debit on bank accounts or credit cards. The customer website also provides information related to the card (history of transactions), claims, refunds, orders and company-related general data (lines, timetables, events, discounts…).
- Merchant Acquirer Systems, which are operated by merchant acquirers in charge of collecting transactions carried out in shops by the cardholder. The latter can purchase goods in shops and pay for them with the card e-purse. All these transactions are collected by the Merchant Acquirer System and forwarded to the CCHS. On its side the CCHS can manage a catalogue of goods that cardholders can purchase in shops managed by the Merchant Acquirer. This catalogue of products is downloaded to the Merchant Acquirer System.
- Card Production Systems, which are operated by the card manufacturers or by CCHS agents (if the CCHS is equipped with a card production equipment). The CCHS receives from the card manufacturer production files containing data related to batches of cards supplied by the manufacturer.
- Sales Devices such as Customer Service Centres, Retailers’ sales terminals, ticket vending machines and so forth, which can be directly managed by the CCHS. In that case, the CCHS plays itself the role of the Service Provider (or Transport Operator). The CCHS downloads the equipment operating data to the sales devices (e.g., ticketing keys, topology, timetables, fare products, tariffs, blacklists of cards and equipments, action lists regarding Internet sales…), and receives from the sales devices transaction files, audit registers, event logs, and real-time warnings and alarms from on-line sales and validation devices…
This subtask defines the scopes of the actual scenarios within the previous use case provides these scenarios to Task1 and the subtasks 5.2 and 5.3.
More details on this use case are provided within this document [^ITEmISTicketingUC-v0.doc][ITEmISTicketingUC-v0.docD5.1: Use case demonstrator design|^ITEmISTicketingUC-v0.doc]
This task implements and deploys the assessment environment, using the ITEmIS methods and tools. This includes the configuration and customization of all simulators and devices, the implementation of the test cases, and the integration of the simulator manager. The output of this stage is a deployed assessment environment, based on the implementation and/or customization of all artefacts.
The main aim of this task is to assess project results based on feedbacks from the use case. Scenarios allow validating main concepts and technologies developed during the project. A deep analysis of these results is critical in order to Estimate technologies that have been developed in term of usability. Such work allows to identify best practices and to scope potential weak points.