IoP - Bus Operational Services User Requirements

Doc. No. 9459-67054 Rev. B IoP - Bus Operational Services User Requirements

AFC House Honeycrock Lane

Salfords Surrey RH1 5LA

Tel: +44(0)1737 782200

Fax: +44(0)1737 789759

ITSO on Prestige BUS OPERATIONAL SERVICES USER REQUIREMENTS CATALOGUE

Document Number: 9459-67054 Revision: B Date: nn December 2010 UNCONTROLLED PRINT - Unless Release Approval Signature present below Date of Release Release Authority Released by Document Control

nn December 2010 ECN 9459-90026

Copyright © 2010 Transport for London. All rights reserved. This information is confidential. of 14


0. PRELIMINARIES 0.1 PUBLISHED BY Cubic Transportation Systems Limited, AFC House, Honeycrock Lane, Salfords, Surrey, RH1 5LA. Tel: +44(0)1737 782200, Fax: +44 (0)1737 789759

0.2 COPYRIGHT Copyright © 2010 Transport for London.

All rights reserved. This information is confidential. You may not reproduce, adapt or disclose this information, or any part of this information, for any purpose without TfL’s written permission. TfL makes no warranties or representations, and expressly disclaims all liability, concerning this information.

0.3 DOCUMENT HISTORY First issued @ revision A, on 21st July 2010, by Steve Godwin under ECN 9459-90026

Second issue @ revision B, on nn December 2010, by Name under ECN 9459-900nn

Note: Refer to the applicable ECN (Engineering Change Note) for approval authorities, signatures and document distribution.

0.4 CHANGE MARKING Where implemented, a vertical line in the left margin has marked changes since the latest revision of this document adjacent to the change.

0.5 REFERENCED REPORTS

Reference Document Number Document Title

[1] FR001 FTA Required Variation for ITSO on Prestige

[2] Not used

[3] eB 02566 FTA Contract including Clause 7 - New Services and Interfacing Parties and Clause 27 - Variation

[4] 1005-18116 Correspondence agreeing changes to FTA Schedule 1.11

[5] 9459-67048 IoP Interface Specification Cellular Requirements

[6] FR091 FTA Required Variation 091 for the Initial Bus Launch of the Future Ticketing Project

[7] TTL Draft provided for information OSS Functional Specification

[8] Cubic Draft Gap Analysis between v1.02 and v1.05 Reader Specifications

[9] IBL FRS Payment Card Extension V1.1

[10] TTL Draft provided for information Asset Management System Requirements (for LBSL)

[11] Cubic Draft Version 0.4 provided for information

Proposal detailing LBSL 3G Service Provision



0.6 EFFECTIVE PAGES

Document: 14 Plus one attached MS Excel Workbook.



0.7 GLOSSARY

3G Third generation wireless digital technology standards. BOC Bus Operating Company Bus Service Area Geographic area covering all TfL bus routes and Garage Areas

including potential re-routes. Cellular Data Service The service to be provided by a third party contracted by TTL for the

transmission of data between Bus RTDs and UVs to the Prestige Back Office.

Diagnostic Code Codes generated by the system for the purpose of analysing a fault or the operation of the system

EMV EMV typically refers to a set of payment standards developed by EMVCo (EMV is short for Europay, MasterCard, Visa). In particular this is used in the context of contactless payments.

ETM Electronic Ticket Machine. A type of staff-operated ticketing device, installed on a bus and used by the driver to monitor validation of NTM cards and issue paper bus tickets

Fault Code Codes generated by the system indicating the failure or degraded mode of operation for the following devices, ETM, RTD, MRTD, UV, ETM Tray, RTD Tray, Driver Module, Modem, ISAM, SIM, 3G Communications, GPC, GT and ISDN Lines

FTA Future Ticketing Agreement (Ref [3]) FTA Contract Period Four weekly Period as defined in the FTA (Ref [3]) Garage Area Location where all buses must start and end for data transfer purposes.

Including but not limited to garages and their surrounding areas, stands and remote parking facilities.

GPC Garage Computer GT Garage Terminal iBus Third party on bus system for the provision of vehicle location using

GPS and communication services ICCID Integrated Circuit Card Identifier - Electronic serial number of a SIM IoP ITSO on Prestige ISDN Integrated Service Digital Network digital communications service ISAM ITSO Security Access Module ITSO The UK national transport smart card standard currently in

development (formerly Integrated Transport Smartcard Organisation) KPI Key Performance Indicator LBSL London Bus Services Limited MRTD Master RTD – variant of RTD fitted when UVs are present MSISDN Mobile telephone number NFWT Non Fair Wear and Tear - equipment that has been damaged outside of

the contractual requirements NTM New Ticketing Medium. The Oyster® card Open Boarding Bus Articulated buses and their scheduled replacements where passengers

are allowed to board the bus through multiple points and validate NTM



cards on UVs and MRTDs PBO Prestige Back Office PC Personal Computer used by some Bus Operating Companies Prestige Name of programme covering Procurement of Revenue Services,

Ticketing Information, Gates and Electronics Prestige Service For the purposes of this document references are made to the Prestige

Service represents the FTA contracted services relevant to the Bus Sub-System.

PSU Power Supply Unit used for Garage Terminals RAG Red - Amber - Green for highlighting system status RTD Remote Ticketing Device SIM Subscriber Identity Module SLA Service Level Agreement TfL Transport for London TTL Transport Trading Limited, a subsidiary of TfL UPS Uninterruptible Power Supply used for GTs and GPCs UV Universal Ticket Validator VO FTA Variation Order as per Clause 27 requirements (Ref [3])



CONTENTS

0. PRELIMINARIES 2 0.1 PUBLISHED BY 2 0.2 COPYRIGHT 2 0.3 DOCUMENT HISTORY 2 0.4 CHANGE MARKING 2 0.5 REFERENCED REPORTS 2 0.6 EFFECTIVE PAGES 3 0.7 GLOSSARY 4

1. INTRODUCTION 7 1.1 SCOPE 7 1.2 ABOUT THIS VERSION 7

2. OVERVIEW OF THE IOP BUS SUB-SYSTEM TO BE SUPPORTED BY THE OPERATIONAL SERVICES USER REQUIREMENTS 8

2.1 EXECUTIVE SUMMARY 8 2.2 BACKGROUND 9 2.3 IOP BUS SUB-SYSTEM SOLUTION 9 2.4 ASSUMPTIONS 10 2.5 DOCUMENT STRUCTURE 10

3. BUS OPERATIONAL SERVICES SYSTEM AND STAKEHOLDER TOP LEVEL STRUCTURE 13

4. GENERAL, SERVICE SUPPORT AND STAKEHOLDER REQUIREMENTS 14



1. INTRODUCTION 1.1 PURPOSE The purpose of this document is to set out the high level stakeholder user requirements for all stakeholder operational services to support the operation of the new Bus Sub-System IoP services introduced under FTA Required Variation FR001 (Ref [1]) and Required Variation FR091 (Ref [6]).

1.2 SCOPE Thisis document defines the stakeholder operational services user requirements for the Bus Sub-System excluding the Central System and other Sub-System requirements. The scope of this document pertains to the final solution after the full introduction of IoP. The document notes where the inclusion of a new initiative is subject to the identification of further funding. This document does not intend to define the final system design solution or what parts of the system deliver the specific operational services user requirements. The document does not define the service performance regime. The service performance regime is being taken forward under FR091 (Ref [6]).

1.3 APPROACH This document has been created from a number of different source documents, existing service requirements and information captured during future service provision workshops. Where these requirements have been extracted from a previous document a cross reference has been added for traceability. These documents include but are not limited to:-

Document Title Ref

FTA Required Variation 091 for the Initial Bus Launch of the Future Ticketing Project [6]

OSS Functional Specification [7]

Asset Management System Requirements (for LBSL) [10]

Draft Proposal Version 0.4 detailing LBSL 3G Service Provision [11]

The requirements have been logically mapped into a number of delivery phases that have been created to realise TTL’s roadmap for the provision of fare revenue services over the next 3-5 years.

1.4 ABOUT THIS VERSION This version is the second draft following assurance, review and response by TTL. It now separates the Microsoft Word tables originally in sections 4 to 7 and has migrated them to a Microsoft Excel table for more flexible data manipulation, sorting and filtering.



2. OVERVIEW OF THE IOP BUS SUB-SYSTEM TO BE SUPPORTED BY THE OPERATIONAL SERVICES USER REQUIREMENTS

2.1 EXECUTIVE SUMMARY The introduction of IoP across the Bus Sub-System gives the opportunity to provide improved operational services to TTL and TTL’s client LBSL. This is provided through a number of changes possible as a result of new technology combined with improved operational services management. These Operational Service User Requirements set out the proposed improvements. The user requirements have been created by taking into account a combination of:-

1. The current operational services and supporting systems 2. The operational services and supporting system changes contracted under the FTA and

specifically under FR001 (Ref [1]) and FR091 (Ref [6]). 3. Additional operational services and supporting system improvements that can be funded through

the benefits that it gives the Contractor and its Subcontractors 4. Potential operational services and supporting systems improvements that TTL and or its client

LBSL could benefit from that could possibly be funded through a variation to the FTA if TTL and or LBSL see sufficient benefit to do so.

This document indicates Cubic’s and TTL’s understanding of which of the above categories apply to each of the user requirements documented.

In creating these user requirements Cubic has considered what it understands to be TTL’s and its client LBSL’s main operational services business objectives together with the requirements of the other Bus Sub-System stakeholders to make these possible. TTL’s and its client LBSL’s main objectives are understood to be:-

• Increase reliability of on bus equipment thereby increasing LBSL’s ability to collect revenue • Reduce reliance on garage staff reporting faults • Introduce remote engineering diagnosis via fault codes and status monitoring • Enable remote software and data downloads • Improve management information, including monitoring of garage performance • Improve asset tracking

2.3 Service Solution Support

The operational services solution will be run by the following Cubic Customer Services divisions:-

o Call Centre o Field Services (mainly supported by Parkeon) o Workshop o Stores o System Support (including Back Office System Support) o Directors, Management and Administration

The operational services solution for the stakeholders will be supported by the following operational services system architecture:-

• Web and network based portals (otherwise known as Bus ERC) for the visibility of operational services information to the relevant operational stakeholders

• Web and network based portals for the management of operational services by the relevant operational stakeholders

• Web and network based portals for the visibility of the asset database by the relevant operational stakeholders

• Web and network based portals for the management of the asset database by the relevant stakeholders

• Web based portals and inin-garage peripheral device access for the visibility of operational services information to the relevant operational stakeholders



• Web based portals and in-garage peripheral device and technician portable device access for the management of operational services information to the relevant operational stakeholders

• Fault codes automatically generated by Bus Sub-System devices and collated by the Bus Sub-System servers

• System servers including the LBSLCC and LBSL DGC, containing operational system data • Access to and management of operational information stored within Metrix by Cubic Customer

Services

2.2 BACKGROUND The IoP project will add ticketing services based on ITSO standards (See ITSO website: www.itso.org.uk) to the existing Oyster Card system. To support the extra data required for ITSO, and to avoid the constraints of the current bus driver memory modules, a wireless data communications link is being introduced for transferring transaction data and providing the necessary updates to each bus smartcard validator. This additional functionality will be exploited to provide improved monitoring of faults and therefore faster service response times.

The IoP Bus Sub-System Services will be subject to a new Service Level Agreements (SLAs) which should be supported by the stakeholders’ operational services and interfaces in such a way that the requirements of the new IoP SLAs can be satisfied.

The introduction of the IoP Bus Sub-System Services and infrastructure provides the foundation for the introduction of EMV. New Service Level Agreements for EMV will be added under change control to meet the stakeholders’ operational services and data availability requirements as they are developed. Some known EMV requirements are included in this document and are coded in the Sort Keywords column so that they can be filtered out and or used as necessary.

2.3 IOP BUS SUB-SYSTEM SOLUTION

Figure 1 - IoP Solution Based on the Cellular Data Service

The IoP solution will retain the existing drivers’ memory module and the GT/GPC will be retained to transfer ETM data through the existing infrastructure, however the current mechanism for transferring Oyster data will be replaced by 3G communications using cellular data modems that are integrated with the RTDs and UVs on board the buses, allowing direct communication with the Prestige Back Office (PBO). There will be up to



approximately 12,000 devices that are required to be connected to a dedicated back office in the data centres via a Cellular Data Service. Data traffic will be transferred in both directions.

A cellular data modem will be fitted into each M/RTD and UV. All Oyster and ITSO configuration data, transactions and status events and EMV transactions once introduced will be passed across the Cellular Data Service directly into the PBO systems, completely bypassing the existing driver’s module, garage computers and Bus back office systems. During IBL the system will pass limited Oyster and EMV transaction data via the Driver’s Data Module to maintain the integrity of the LBSL reporting by BCMS.

2.4 ASSUMPTIONS No constraints are put explicitly on the underlying technology used for the provision of the operational services user requirements.

The operational services system requirements and architecture should clarify how the proposed operational services solution will operate and meet the user requirements of this document.

Some of the requirements in this document are new initiatives and are outside of the scope of the FTA and current variations. Some of the new initiatives may be provided by Cubic as an investment giving improved performance SLAs where the benefits can be justified. Other requirements would necessitate TTL variations to cover the specific user requirements identified.

It is assumed that TTL will incorporate suitable allowances in its contracts with third party stakeholders (including the iBus service provider and Cellular Data Communications service provider) to cover the user requirements in this document. [Cubic recommends that TTL include provision in its iBus and cellular communications subcontracts for adequate support to Cubic (and TTL) to enable Cubic (and TTL) to perform its obligations in accordance with Clause 7 of the FTA (Ref [3])].

2.5 DOCUMENT STRUCTURE The supporting Microsoft Excel workbook is structured in a tabular format. This enables the user requirements to be sorted and filtered in different ways using the Sort Keywords and other column fields.

The columns fields support the following requirement headings:-

Column Title Description Ref A unique user requirement reference

Main Output This defines the top level output requirements against each stakeholder

Sub-Output This defines any further output requirements supporting the main output against each stakeholder

Constraints/Performance This identifies any key constraints or performance requirements against each output

Users/Stakeholders The stakeholder groups who will use the functionality to be delivered under this requirement

TTL Ref Cross reference of the requirements in document(s) raised by TTL that are covered by the specific requirement in this document

Source The change or project from which this requirement has arisen or if it is a new initiative

Phase This column is used to define the phasing of each specific requirement against the main delivery program

Notes This is used for any other notes relevant to the output requirements specified

TTL Section Ref Now that the tables have been merged this defined the original table that the requirements belonged to for traceability



Column Title Description Sort Keywords This column is used toflag specific keywords against each requirement to

assist in filtering specific requirement categories

Obsolete/New This column is used to flag changed requirements. T = Requirement added by TTL; C = Requirement added by Cubic and O = Obsolete requirement

Changed Flag to indicate if the main content of the requirement have changed for traceability

Duplicate Flag to indicate if the requirement is or has become duplicated due to merging with a similar requirement

Orig Order Original order of requirements for traceability

Note that some of the above columns may not be shown as they are for administration purposes only.

Source

Content Description

Existing Continuation of existing Operational Services functionality

FTA Required to enable Cubic to meet its obligations under the FTA

IBL Required to enable Cubic to meet its obligations under FR091

IOP Required to enable Cubic to meet its obligations under FR001

LBSL Additional functionality requested by LBSL

??? High level requirement that includes contractual requirements (to be delivered) and some new . initiatives. These requirements will be split once fully defined and agreed

New Initiative New Initiative - not yet instructed including additional functionality requested by TTL and or LBSL

Phase

Content Description

0. Current The requirement is already implemented and is to be retained

1. Van A+B Rollout of new hardware including Vanguards A and B July 2011

2. V C+IBL Vanguard C for IOP and IBL Base functionality Jan 2012

3. Enhn IBL IBL – Enhanced July 2012

4. IOP IOP Vanguard D Jan 2013

5. Final Full BOS July 2013

6. Future TBA Future Phase(s) to be agreed

All Impacts all phases



Content Description

Split Impacts a number of phases as indicated in the cell comments (these will be eventually be split and allocated to the correct phase once details are defined)

Rail An item identified as a ‘Phase 2’ requirement in the OSS Functional Specification (Ref [7])

Dates from July 2012 onwards are indicative.



3. BUS OPERATIONAL SERVICES SYSTEM AND STAKEHOLDER TOP LEVEL STRUCTURE The following diagram shows the structure for the implementation of the Bus Operational Services User Requirements set out in this document.

ISDN and Comms Service Provider

Garage Services

Cellular Data Service Provider

OPO Buses

External SystemBus Company Site.

Open Boarding Buses

Cubic Services

Cubic , Directors Dashboard

CS Hosting Locations

LBSL, Palestra, Southwark

Bus Operating Company Garages

Garage Terminals 01.02.01

Bus ETM 01.02.04(RTD 01.02.XX.XX)

Garage Computer01.02.02

Driver'sModules

Universal Validators 01.02.XX (RTD 01.02.XX.XX)

serial link

LTBCCWorkstations

01.02.05

CS Client Users01.04.01

(application only)

External Systems,

TTL, Butler Place

BOC Computer

Bus ETM 01.02.04(MRTD 01.02.XX.XX)

Optional Other Users

Other Web Access Portal

Router

Router

Router

ISDNnetwork

BCMS

Router

Note: Other servers omitted for clarity. Layout not topologically equivalent to 2 hosting locations.

LTBCC01.02.03

Router

Document Number: 9403-XXXXXDocument Name: IOP BUS OPERATIONAL SERVICE USER REQUIREMENTS DIAGRAMVersion: B

CROSS-REFERENCE toFuture Ticketing Agreement

ITSO ON PRESTIGEBUS OPERATIONAL SERVICE USER REQUIREMENTS DIAGRAM

(DRAFT FOR DISCUSSION PURPOSES ONLY)

Copyright © 2010 Transport for London. All rights reserved. This information is confidential.

Caveats: 1) Some requirements may not be feasible or cost effective TBA.2) The network equipment representation is not accurate.3) The dual hosting locations are represented as one for simplicity.

Router

Parkeon Services

Cubic , Call Centre

Cubic , Workshop

Router

Cubic , System Support

Cubic, Management and Admin Cubic , Field Services

Parkeon, Field Services

ParkeonUsers

(web access, terminal not

supplied)

TTL, Prestige

TTL Users(web access, terminal not

supplied)

Router

Parkeon, Workshop

LBSL DGC01.02.0X

Router

CELLULAR COMMS

TTL HOPS01.04.XX

CS Database 01.04.02Actuate Reporting 1.04.03KMS 01.04.04

Hub

Customer Services and PDA Servers

(as required)01.02.0X

External Systems,

Cellular CommsFault Reporting

Systems

Router

Main RequirementsContracted vs Actual services in operationContracted bus performance statisticsRepeat Failure statisticsBus system RAG statusCellular SLA performance statisticsCellular SLA RAG statusiBus I/F performance statisticsiBus I/F RAG statusBOC performance statisticsBOC RAG statusBus exclusions due to cellular SLA failuresBus exclusions due to iBus I/F failuresBus exclusions due to BOC performanceChurn status

Main RequirementsNotification of equipment needing exchangeEquipment exchange reportingSpares level reportingBOC performance statisticsBOC RAG statusChurn instruction status

Main RequirementsNotification of equipment statusNotification of equipment needing exchange

Main RequirementsNotification of equipment statusNotification of equipment needing exchange

Main RequirementsOptional to meet future requirementsTBD subject to variation

Main RequirementsContracted vs Actual services in operationRepeat Failure statisticsBus system RAG statusEquipment exchange reportingSpares level reportingiBus I/F performance statistics*iBus I/F RAG status*BOC performance statistics*BOC RAG status** To assist in mitigation

Main RequirementsContracted vs Actual services in operationContracted bus performance statisticsRepeat Failure statisticsBus system RAG statusCellular SLA performance statisticsCellular SLA RAG statusiBus I/F performance statisticsiBus I/F RAG statusBOC performance statisticsBOC RAG statusBus exclusions due to cellular SLA failuresBus exclusions due to iBus I/F failuresBus exclusions due to BOC performanceChurn requests and status

Main RequirementsContracted vs Actual services in operationContracted bus performance statisticsRepeat Failure statisticsBus system RAG statusiBus I/F performance statistics*iBus I/F RAG status*BOC performance statisticsBOC RAG status*Notification of equipment status (incl SIM, Modem and ISAMs)* To assist in mitigation

Main RequirementsNotification of equipment needing exchangeEquipment exchange reportingSpares level reportingChurn requests and statusI/F to asset database for updatesIncident statistics (subset of contracted performance)Parkeon SLA performance statisticsParkeon SLA RAG statusGarage change controlData extraction facilities

Main RequirementsNotification of equipment statusNotification of equipment needing exchangeChurn requests and statusAsset management updatesI/F to asset database for updatesParkeon SLA performance statisticsParkeon SLA RAG statusGarage change control

LBSL, Prestige

LBSL Users(web access, terminal not

supplied)

Router

COMMS

Garage Services

BOC Users(web or cellularaccess TBD, terminal not

supplied)

BOC UsersPeripheral Device(cellular access)

Router

COMMS

CubicUsers

CubicUsers

CubicUsers

CubicUsers

CubicUsers

CubicUsers

ParkeonUsers

(web access, terminal not

supplied)

General notes: Equipment status comprises operational, faulty, unknown or degraded for:-1) ETMs2) RTDs/MRTDs/UVs3) SIMS4) ISAMs 5) Cellular comms6) iBus interface

Service Engineers

ParkeonUsers

Portable Device(cellular access)

Main RequirementsCellular billing (for TTL)Reporting of cellular data volumesReporting of Contracted vs Actual SIM services in operationReporting of cellular SLA performance statisticsReporting of planned cellular maintenance activitiesCellular change control

iBus Service Provider

Main RequirementsiBus interface performance

Main RequirementsProvision of ISDN performance statisticsEscalation of comms failuresComms change control

iBus

TTL, Prestige

COMMSSP Users

(notification by email, terminal not

supplied)

Router

Router

iBus Users(web access, terminal not

supplied)

iBus Service Provider

Router

iBus Back Office



4. GENERAL, SERVICE SUPPORT AND STAKEHOLDER REQUIREMENTS

The requirement tables are separately contained in a Microsoft Excel workbook titled IOP Bus Operational Service User Requirements Revision B. This enables more flexible data manipulation, sorting and filtering of the requirements.


IoP - Bus Operational Services User Requirements

Documents

Transcript of IoP - Bus Operational Services User Requirements