view - City of Fort Collins Public Records

Transcription

Fare collection
systems
Scheidt & Bachmann Tender 001.13.0109.C.1
City of Fort Collins
Request for Proposal – 7472 MAX BRT
Ticket Vending System
Technical Proposal
Contains Trade Secret and/or Confidential, Commercial, or Financial Information
SCHEIDT & BACHMANN © 2013. All rights reserved.
Fare collection
systems
Table of Contents
1
METHODS AND APPROACH ............................................................................................................ 1
INTRODUCTION ........................................................................................................................... 1
1.1
1.2
APPROACH AND INTERACTION .................................................................................................. 5
1.2.1
Levels of Organization ............................................................................................ 6
1.2.2
Project Stage Setup within S&B .............................................................................. 6
DRAFT PROJECT SCHEDULE (CDRL 702) ................................................................................ 7
1.3
2
DELIVERABLES ............................................................................................................................... 8
2.1
FAREGO SALES ST|70 TICKET VENDING MACHINE ................................................................ 8
2.1.1
General Function TVM ............................................................................................ 8
2.1.2
Design Requirements TVM ................................................................................... 11
2.1.2.1
2.1.2.2
2.1.2.3
2.1.2.4
2.1.2.5
2.1.2.6
2.1.2.7
2.1.2.8
2.1.3
2.1.3.1
2.1.3.2
2.1.3.3
2.1.3.4
2.1.3.5
2.1.4
2.1.5
2.1.5.1
2.1.5.2
2.1.5.3
2.1.5.4
2.1.6
2.1.6.1
2.1.6.2
2.1.6.3
2.1.6.4
2.1.6.5
2.1.6.6
2.1.7
2.1.7.1
Circuit Breaker ..........................................................................................11
Light Fixture ..............................................................................................11
Display Screen .........................................................................................11
Security.....................................................................................................12
Cabinet .....................................................................................................13
Lock and Key ............................................................................................14
Local Alarm...............................................................................................14
Ventilation .................................................................................................15
Control System TVM ............................................................................................. 15
Cancel Functionality .................................................................................16
Time Out Functionality ..............................................................................16
Audit Functionality ....................................................................................16
Data Storage and Transfer .......................................................................17
Alarm and Event Transmission .................................................................17
Auxiliary Power TVM............................................................................................. 18
Bill Handling TVM ................................................................................................. 18
General Requirements..............................................................................18
Bill Validator..............................................................................................19
Bill Escrow ................................................................................................19
Bill Vault....................................................................................................20
Coin Handling TVM ............................................................................................... 21
General Requirements..............................................................................21
Coin Slot ...................................................................................................22
Coin Validator ...........................................................................................22
Coin Recirculation ....................................................................................23
Coin Vault .................................................................................................24
Auxiliary Change Storage Units ................................................................24
Credit / Debit (TVM) .............................................................................................. 25
Card Reader .............................................................................................25
001.13.0109 - Fort Collins Technical Description Final
Contains Trade Secret and/or Confidential, Commercial, or Financial Information – SCHEIDT & BACHMANN © 2013. All rights reserved.
Page ii
Fare collection
systems
2.1.7.2
2.1.8
2.1.8.1
2.1.8.2
2.1.9
2.1.10
2.1.10.1
2.1.11
2.1.11.1
2.1.12
2.1.13
Receipt Printing ........................................................................................27
Fare Media Issuance TVM .................................................................................... 28
Fare Media Inventory ................................................................................30
Fare Media Jams ......................................................................................31
Report Journals (TVM) .......................................................................................... 31
Customer User Interface TVM............................................................................... 31
Display Screen Interface...........................................................................31
Servicing and Maintenance TVM .......................................................................... 32
Revenue Servicing ...................................................................................32
Environmental Conditions TVM ............................................................................. 33
Installation Requirements TVM ............................................................................. 34
2.2
MANAGEMENT CONTROL SYSTEM ......................................................................................... 34
2.2.1
Introduction ........................................................................................................... 34
2.2.2
System architecture .............................................................................................. 35
2.2.3
System overview ................................................................................................... 36
2.2.4
Software architecture ............................................................................................ 37
2.2.4.1
2.2.5
2.2.5.1
2.2.5.2
2.2.5.3
2.2.5.4
2.2.5.5
2.2.5.6
2.2.6
2.2.6.1
2.2.6.2
2.2.6.3
2.2.7
2.2.7.1
2.2.8
2.2.8.1
2.2.8.2
2.2.9
2.2.9.1
2.2.9.2
2.2.9.3
2.2.9.4
2.2.10
2.2.10.1
2.2.10.2
2.2.10.3
2.2.10.4
2.2.10.5
Supported system environments ..............................................................37
Hardware architecture and server models ............................................................. 38
Application server .....................................................................................39
File server .................................................................................................39
Database server .......................................................................................39
Backup server...........................................................................................39
Archive and purge server..........................................................................40
Storage area networks..............................................................................40
Database licensing................................................................................................ 40
FareGo Data Integration license ...............................................................40
Database administration ...........................................................................40
Database maintenance .............................................................................40
Network components and band width ................................................................... 41
Communication with external services .....................................................41
FareGo Data CS ................................................................................................... 41
Introduction ...............................................................................................41
Operating concept of FareGo Data ...........................................................42
Administration ....................................................................................................... 44
Program manager .....................................................................................44
Master data administration .......................................................................46
Audit Trail .................................................................................................48
Archiving data ...........................................................................................48
Configuration ........................................................................................................ 49
Device administration ...............................................................................49
Operating data management ....................................................................51
Version administration ..............................................................................51
Release Management...............................................................................53
Basic tariff data management ...................................................................54
Page iii
Fare collection
systems
2.2.10.6
2.2.11
Barcode tracking.......................................................................................55
Device monitoring ................................................................................................. 55
2.2.11.1
2.2.11.2
2.2.11.3
2.2.11.4
2.2.12
Communication with the field devices .......................................................55
Job Scheduler...........................................................................................56
Direct commands......................................................................................58
Alarm management ..................................................................................59
Reporting .............................................................................................................. 61
2.2.12.1
2.2.13
2.2.14
2.2.15
Standard evaluations ................................................................................63
FareGo Data add-ons ........................................................................................... 64
FareGo Data Monitor+ .......................................................................................... 65
FareGo Data Tariff+ .............................................................................................. 67
2.2.15.1
2.2.15.2
2.2.16
2.2.17
2.2.18
Editing print layouts ..................................................................................67
Screen layout editor ..................................................................................67
FareGo Data Archive+ .......................................................................................... 70
FareGo Data Paper+............................................................................................. 72
FareGo Data Transfer+ ......................................................................................... 73
2.2.18.1
2.2.18.2
Export interfaces .......................................................................................73
Import interfaces .......................................................................................73
2.3
QUALITY & TESTING ............................................................................................................... 74
2.3.1
Test Methodology ................................................................................................. 79
First Article Test (FAT) ..............................................................................................79
Reliability, Maintainability and Accuracy Test (RMAT) ..............................................81
2.3.2
Test Plan and Procedure ...................................................................................... 82
2.4
INSTALLATION .......................................................................................................................... 82
2.4.1
City of Fort Collins Requirements.......................................................................... 83
2.4.2
Installation Rate .................................................................................................... 83
2.5
TRAINING .................................................................................................................................. 83
2.6
WARRANTY ............................................................................................................................... 84
2.7
ELECTRONIC DELIVERABLES SPREADSHEET APPENDIX A ................................................... 87
2.8
ELECTRONIC DELIVERABLES SPREADSHEET APPENDIX B ................................................... 88
2.9
BUY AMERICA CERTIFICATE .................................................................................................. 89
2.10
LOBBYING CERTIFICATE ......................................................................................................... 90
3
QUALIFICATIONS AND EXPERIENCE ........................................................................................... 91
3.1
MBTA (BOSTON)...................................................................................................................... 91
3.2
UTA (SALT LAKE CITY, UT) ................................................................................................... 93
3.3
REGIONAL TRANSPORTATION DISTRICT (DENVER, CO) ...................................................... 94
3.4
PAAC (PITTSBURGH, PA)........................................................................................................ 95
Page iv
Fare collection
systems
4
LIST OF PROJECT PERSONNEL .................................................................................................... 96
Project Manager ........................................................................................................96
Technical Project Manager ........................................................................................97
Hardware Development Lead .............................................................................................. 97
Software Development Lead .....................................................................................98
Maintenance Service Manager ..................................................................................98
Documentation Manager ...........................................................................................99
Manufacturing Manager.............................................................................................99
Contracts Manager ....................................................................................................99
Quality Assurance ...................................................................................................100
5
ORGANIZATION CHART / PROPOSED PROJECT TEAM ............................................................. 101
6
AVAILABILITY ............................................................................................................................ 102
7
ESTIMATED HOURS BY TASK..................................................................................................... 104
8
SCHEDULE OF RATES AND COST BY TASK................................................................................ 105
9
ADDENDUM ................................................................................................................................. 106
10
ATTACHMENTS ........................................................................................................................... 107
10.1
SAMPLE SERVICE AGREEMENTS ........................................................................................... 107
10.2
SOFTWARE LICENSES............................................................................................................. 108
10.3
ESCROW AGREEMENT ........................................................................................................... 109
10.4 CDRLS.................................................................................................................................... 110
10.4.1 CDRL 704 – Monthly Report (Draft) .................................................................... 110
10.4.2 CDRL 601 – Technical Overview ........................................................................ 111
Page v
Fare collection
systems
1
Methods and Approach
1.1
Introduction
Scheidt & Bachmann is pleased to present this proposal to the City of Fort Collins for a
Ticket Vending System, featuring Scheidt & Bachmann’s FareGo Sales ST|70 Ticket
Vending Machines as well as our FareGo Data backend system.
Scheidt & Bachmann’s proposed Ticket Vending System is comprised of various user
friendly and modular components that are reliable, flexible, and expandable and field
proven, including:
•
•
FareGo Data backend system, Software Only, used for:
•
Management of Ticket Vending System
•
Managing the configuration of the devices
•
Monitoring system performance
•
Storing and processing transaction and event records
•
Reporting
21, plus an optional 15, FareGo Sales ST| 70 Ticket Vending Machines
The foundation for the proposed system is our FareGo Sales ST|70 TVM. The TVM
operations are controlled by sophisticated software that is highly configurable, reducing
the need to make software code changes to meet the City of Fort Collins’ operational
requirements.
The proposed Ticket Vending System supports the following functionality:
•
Accepts cash and coins
•
Vends, validates and revalues Magnetic Stripe Tickets
•
Creates a record of each transaction associated with the time and location of the
fare
•
Provides secure storage of fares and records
•
Provides secure processing of revenues collected at various City of Fort Collins
locations and the compilation of transactional records to permit a complete audit
of revenues collected
•
Manages and downloads software versions as well as operational parameters for
fare collection equipment
•
Option - Validates and revalues Smart Media through the integrated Smart Media
Reader
As we understand that our system has little value if it does not work with existing City of
Fort Collins infrastructure, we are committed to providing a seamless integration. Our
Page 1
Fare collection
systems
ticket vending machines will be configured to encode magnetic media in the GFI format
provided by the City of Fort Collins. To allow for the communication of data between
the two systems, an export function is available to provide the necessary data in a flat
file which can be easily imported into existing systems.
Scheidt & Bachmann is the best company to deliver this system due to our extensive
specialized technical capability, robust and reliable Ticket Vending Machines and an
established track record both globally and in the North American Market including
Canada and the United States.
In 2003 Scheidt & Bachmann USA was awarded a project with MBTA Boston to provide
a new Automated Fare Collection System (“The Charlie Card”) to serve the greater
Boston metropolitan area. The contract included the supply and installation of 1600
VARE-point fareboxes, Smart Media readers, 600+ TVMs, and Fare Gates. Scheidt &
Bachmann has made a long term commitment to the United States market by setting up
both administration and manufacturing facilities in Burlington MA creating over 160 jobs
and growing. We are committed to meeting all Buy America requirements for our
complete product line; as we grow so will the employment opportunities for the United
States market.
To prepare this response to the City of Fort Collins request for proposals (RFP) for a
Ticket Vending Machines, Scheidt & Bachmann undertook a thorough review of the City
of Fort Collins’ requirements, current installed equipment and typical operating
conditions. We found that our FareGo Sales ST|70 Ticket Vending Machines meets all
the requirements. For system management,
Scheidt & Bachmann’s FareGo Data
backend system meets the functionality as
described in the RFP. The FareGo Data
family of systems is a well-established and
proven application with many years in
service and multiple implementations
throughout the United States and the world.
Scheidt
&
Bachmann
designs,
manufactures, implements, supports and
where requested, maintains and operates,
fare collection systems consisting of
products such as fareboxes, standalone
validators, ticket vending machines, faregates and Customer Service Terminals, all
of which are capable of supporting multiple
types of fare media currently used by transit
agencies around the world: paper (bar
code), magnetic stripe and smart media. All
these devices are managed through fixed
and wireless network connections to Scheidt
& Bachmann’s FareGo Data system.
Page 2
Fare collection
systems
The Ticket Vending System is field proven over a wide range of operating conditions
and transaction volumes. This field experience is what drives Scheidt & Bachmann’s
continuous product improvement process leading to product evolution. Scheidt &
Bachmann has years of experience in the design and supply of fare collection field
devices and as a result, Scheidt & Bachmann fare collection components have evolved
throughout the years to incorporate both technological changes and customer trends.
These changes have addressed ease of use and improved functionality and
performance without sacrificing security aspects. Scheidt & Bachmann customers
benefit by receiving the most advanced versions of our products available at the time of
proposal and design.
However, hardware is only one part of today’s advanced fare collection systems.
Software is what runs Scheidt & Bachmann’s Ticket Vending Systems and provides the
functionality that the City of Fort Collins requires. While Scheidt & Bachmann field
devices on their own are self-contained to accept fare payments and keep track of such
transactions, the full data processing capabilities of the system are founded on the
power of the Scheidt & Bachmann’s FareGo Data system. FareGo Data is a powerful
system management application that is at the core of every Scheidt & Bachmann fare
collection system. It supports fareboxes, on-board and platform smart card processors,
ticket office machines, ticket vending machines and fare gates.
FareGo Data is comprised of various software applications, and networking components
that assist in the operation and management of the fare collection equipment. It is
effectively the universal remote control for all devices, providing a large number of
maintenance, statistical, monitoring, scheduling and controlling functions.
FareGo Data provides access to and the ability to configure and present a wealth of
data available from the devices and associated user functions. All transactions,
maintenance activities, system and device events, and device and system alarms
generated are transmitted to and stored at the FareGo Data system. This data can be
retrieved and reported through appropriately configured the City of Fort Collins
workstations, through the Scheidt & Bachmann standard reports provided with FareGo
Data.
Application software for FareGo Data consists of software programs supplied by Scheidt
& Bachmann, configuration files used to customize user interfaces and other operational
characteristics of FareGo Data, prepared reports and queries, special software tools,
other commercially available software packages, and any other special functions
resulting from software provided as part of FareGo Data.
FareGo Data software includes modules for revenue accounting, module tracking,
configuration, event, and alarm management, ticket vending machine, farebox and
smart media reader control, transaction data, status visualization, tariff data and version
control. All application data is subject to version control and configuration management.
It is critical that the Ticket Vending System protect data from unauthorized access and
modification, as the ability to accurately compare the revenue reported by the Ticket
Vending Machines and the manual counts is a critical function allowing a high level of
Page 3
Fare collection
systems
cash revenue security. FareGo Data access is protected for all system elements based
on the used standard operating system as well as through additional methods
implemented by the system software. The same strategy is used to ensure a high
degree of traceability and security for all data stored within the system.
Technology is only one part of the City of Fort Collins’ project. To ensure success,
effective project management, quality controlled product configuration and development
and capable service delivery are essential. The company’s organizational structure is
project team oriented which eliminates hierarchical impediments to good design and
efficient project management. Developers/engineers are organized within the project
business teams and function as a single unit throughout the project which assures that
the goals are aligned in the same direction.
Scheidt & Bachmann will only designate key individuals to this project that are both
highly qualified and experienced with the Ticket Vending Machine industry to fill the
project management, support and maintenance positions. The processes, procedures
and documentation used for project management will be the same or updated versions
to those used in previous Scheidt & Bachmann projects. Manufacturing and installation
quality and compliance to contract requirements will be managed using Scheidt &
Bachmann’s Quality Management System, which has been certified according to ISO
9001:2000 by Lloyd´s Register Quality Assurance.
To ensure quality software development, the processes and procedures described in
Scheidt & Bachmann’s Software Quality Assurance Program (SQAP) will be followed.
The SQAP provides a disciplined approach needed to reduce the risk of software errors
and major reword and corrections.
Scheidt & Bachmann has a well established, proven training program designed to
provide customers with the knowledge and expertise they need to operate, service,
support and maintain their Scheidt & Bachmann equipment and systems. It is delivered
by a highly qualified and experienced training staff who are thoroughly familiar with
Scheidt & Bachmann’s equipment and systems. The training program proposed for this
system procurement will be based on standard courses and training modules already
available to any of our customers.
Scheidt & Bachmann historically excels in minimizing the Total Cost of Ownership
(TCO) over the lifetime of the systems. Part of this TCO benefit is price leadership
based upon its annual production volume. However, even larger gains are due to design
and quality assurance factors. The historically high reliability reduces maintenance
costs. Upgradeability minimizes customer needs for future investments. The software
design eliminates much of the traditional need for customization. The intuitive, easy-touse approach significantly reduces employee training costs.
The proposed Ticket Vending System generates extensive transaction records,
diagnostic and operational records, allowing for the creation of a wide range of reports
that can be used to manage and control the Ticket Vending System.
The use of standards, both internal Scheidt & Bachmann standards and international
standards, coupled with the modular design methodology is an important aspect relating
Page 4
Fare collection
systems
to the cost effective long-term support of the system Scheidt & Bachmann is proposing.
All programming is done in standard languages, and data communications use standard
interfaces and protocols. In the future, such system aspects as central computers can
be upgraded with a minimum of difficulty due to the use of standard operating systems
and interfaces.
We believe that selecting Scheidt & Bachmann to deliver, install, commission and
support the proposed system will result the following benefits for the City of Fort Collins:
•
•
•
•
A reliable, easy to use yet highly secure Ticket Vending System for Fort Collins’
customers
Cost containment and reduction of project risk through field proven yet innovative
design
Highly responsive technical support for the life of the system
Proven engineering capability to enable system evolution over time.
These benefits will be achieved by:
•
•
Scheidt & Bachmann hardware and software that has a low cost of operation,
support and expansion
Use of field proven equipment, with a known track record of reliable performance
We look forward to the opportunity to work with the City of Fort Collins to implement this
new system
1.2
Approach and Interaction
Scheidt & Bachmann operates to the international standard ISO9001 across our organization
and as such our project management methodology used for ETS Delivery and ETS Operational
Services will conform to our own proven standards. Scheidt & Bachmann applies PRINCE2
methodology throughout its Project Management department with all PM’s being certified
PRINCE2 practitioners.
Scheidt & Bachmann will ensure that all aspects of the project are correctly managed including
planning, resources, safety, quality, monitoring, control, measurement, quality management, risk
management, rectification and reporting on all aspects.
The project manager leads the project organization at Scheidt & Bachmann premises in
Burlington, MA and coordinates customer requirements with the engineering and manufacturing
departments.
Through the design phase and the production release, the project managers of the City of Fort
Collins and of Scheidt & Bachmann will meet at least bi-weekly. As necessary, an ad-hoc
meeting can be held on short notice. Meetings will take place on-site at the customer’s
premises or at the local Scheidt & Bachmann premises, as agreed.
Within each project meeting, the deliverables (hardware, software, documents) for the upcoming
month will be defined and maintained within the project plan as necessary. This degree of detail
shall prevent the project timeline slipping away from its milestones. For each deliverable,
acceptance criteria will be defined. Delivery and acceptance of each deliverable will be reported
to the project management team of both parties. Non-acceptance of a deliverable will be
Page 5
Fare collection
systems
reported to the project management team without delay and with indication of the denial
reasons. The project management team will decide the next action with respect this deliverable.
1.2.1
Levels of Organization
A project management team is a temporary structure specifically designed to manage the
project to its successful conclusion. The project management structure has four levels, three of
which represent the project management team and the fourth which sits outside of the project.
At Scheidt & Bachmann we understand the importance of the City of Fort Collins in the
successful completion of this project, and as such, the project manager for the City of Fort
Collins is a member of the Project Board.
Project Board
Customer
Senior User
Supplier
Senior Supplier
Executive
Change Authority
Project Assurance for
executive, senior
user and senior
supplier
Project Manager
Project Suppport
Team Manager
Team Manager
Project Management Team
Corporate Management
Team Members
1.2.2
Project Stage Setup within S&B
One of the main principles of PRINCE2 is to split a project into defined stages, where the
end of each stage, respectively the entrance into the next stage is subject to an
authorization process under the direction setting of the Project Board. The main stages
are: Starting up, Initiation, Project delivery, and Closeout.
The Starting up stage of the City of Fort Collins’ project is understood to be managed
under the responsibility of S&B’s Bid-Management, closing with the formal set of
handover documents including the Business Case and the Project Brief to outline the
scope of the project.
S&B’s project management takes over responsibility for the project with the approval of
the Project Board to start the Initiation Stage and do a detailed planning of the project.
As part of the Initiation the Project Initiation Documentation (PID) will be created and the
Project Plan will be setup. There will also be a decision how many delivery stages will be
needed to enable the Project Board to take control on the project. At the end of the stage
the Project Board will authorize the updated Project Plan and Business Case to start the
delivery of the products.
The Project delivery can be done in one stage but in most projects will be divided into
sub-stages defined via timely intervals. Delivery stages should not take longer than 5
Page 6
Fare collection
systems
months and it should be shown which major products will be delivered during a stage.
Stage boundaries of this sub-stages are subject to Project Board meetings and direction
settings. The delivery itself will be performed by Team Managers who get Work Packages
detailing the products to be created and agreements on planned time and effort. In case
the agreed tolerances (time, cost, scope) for the stage are in danger the Project Manager
needs to inform the Project Board by an Exception Report in order to decide on corrective
actions immediately.
As part of the Closeout Stage the handover of products to the City of Fort Collins is
finalized, also the handover documentation for the Service is prepared. An End Project
Report including the lessons learned during the project should be prepared.
1.3
Draft Project Schedule (CDRL 702)
Page 7
ID
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Task Name
Duration
City of Fort Collins - Draft Schedule
1 Start of project - NTP
2 Project mobilization phase
2.1 S&B internal project mobilization
2.1.1 Handover from Bid to PM inklusive hand
2.2 Project mobilization with customer
2.2.1 Project mobilization with customer includ
2.3 S&B internal project evaluation phase
2.3.1 Project evaluation
2.4 Completion of project mobilization phase
2.5 Master Schedule of Work Completed
2.6 Project Binder Completed
3 Design phase
3.1 Hardware
3.1.1 Provision by customer
3.1.1.1 Customer to provide all required I
3.1.2 Generation of design descriptions
3.1.2.1 S&B to generate design designde
3.1.3 Design review of design descriptions
3.1.3.1 Customer to review submitted De
3.1.4 Design review meeting
3.1.4.1 Customer and S&B will held desig
3.1.5 Resubmittal of design descriptions
3.1.5.1 S&B to resubmit design submittals
3.1.6 Approval of design descriptions
3.1.6.1 Customer to approve and release
3.1.7 Final design Approval HW by customer
3.2 Software
3.2.1 Provision by customer
3.2.1.1 Customer to provide all required I
3.2.2 Generation of design descriptions
3.2.2.1 S&B to generate design design de
3.2.3 Design review of design descriptions
3.2.3.1 Customer to review submitted De
3.2.4 Design review meeting
3.2.4.1 Customer and S&B will held desig
3.2.5 Resubmittal of design descriptions
3.2.5.1 S&B to resubmit design submittals
3.2.6 Approval of design descriptions
Projekt: City of Fort Collins - Draft Sch
Datum: Wed 2/27/13
Start
1, 2013
F M A
M
J
Half 2, 2013
J A S O
N
D
Half 1, 2014
J F M A
436 d? Fri 3/15/13
0d
4d
2d
2d
3d
3d
4d
4d
0d
0d
0d
65 d
40 d
5d
5d
10 d
10 d
10 d
10 d
5d
5d
5d
5d
5d
5d
0d
65 d
10 d
10 d
25 d
25 d
10 d
10 d
5d
5d
10 d
10 d
5d
Fri 3/15/13
Fri 3/15/13
Fri 3/15/13
Fri 3/15/13
Fri 3/15/13
Fri 3/15/13
Fri 3/15/13
Fri 3/15/13
Wed 3/20/13
Fri 3/15/13
Fri 3/15/13
Thu 3/21/13
Thu 3/21/13
Thu 3/21/13
Thu 3/21/13
Thu 3/28/13
Thu 3/28/13
Thu 4/11/13
Thu 4/11/13
Thu 4/25/13
Thu 4/25/13
Thu 5/2/13
Thu 5/2/13
Thu 5/9/13
Thu 5/9/13
Wed 5/15/13
Thu 3/21/13
Thu 3/21/13
Thu 3/21/13
Thu 4/4/13
Thu 4/4/13
Thu 5/9/13
Thu 5/9/13
Thu 5/23/13
Thu 5/23/13
Thu 5/30/13
Thu 5/30/13
Thu 6/13/13
3/15
3/20
3/15
3/15
5/15
Vorgang
Meilenstein
Externe Vorgänge
Unterbrechung
Sammelvorgang
Externer Meilenstein
In Arbeit
Projektsammelvorgang
Stichtag
Seite 1
M
J
Half 2, 2014
J A S O
N
D
Hal
J
ID
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
Task Name
Duration
3.2.6.1 Customer to approve and release
3.2.7 Final design Approval SW by customer
3.3 Completion of Design phase (HW plus SW)
4 Procurement and Sub Contracts
4.1 Procurement of Initial Long lead items
4.1.1 Definition of Long lead items
4.1.2 Purchasing of immediatly needed Long l
4.2 Definition Scope of Work for Subcontracts
4.2.1 Scope of Work for Subcontracts defined
4.3 Subcontract generation and execution
4.3.1 Subcontracts finalised
5 Development
5.1 Hardware
5.1.1 Early Hardware Activities
5.1.2 Specification
5.1.2.1 Internal Specification finalised (S&
5.1.2.2 Completion of HW specification
5.1.3 Hardware development phase
5.1.3.1 Development of all HW related Ite
5.1.3.2 Finalize BOM by HW developmen
5.1.3.3 Finalize BOM by Administration
5.1.3.4 Handover BOM to production
5.1.4 Prototype phase
5.1.4.1 Corrections to Bill of Materials and
5.1.5 Completion of hardware development ph
5.2 Software
5.2.1 Early Software Activities
5.2.2 Specification
5.2.2.1 Internal Specification finalised (S&
5.2.2.2 Completion of SW specification
5.2.3 Software development phase
5.2.3.1 SW development for all Items rela
5.2.3.2 SW-Package Initial Release
5.2.3.3 Creation of release ("EINGELAGE
5.2.3.4 Completion of software developm
5.3 Completion of development (HW and SW)
6 Software QA test (inclusive preparation)
6.1 Test procedures
6.1.1 Generation of test procedures
Datum: Wed 2/27/13
5d
0d
0d
55 d
10 d
5d
5d
10 d
10 d
20 d
20 d
121 d?
99 d?
1 d?
5d
5d
0d
25 d
20 d
3d
2d
0d
5d
5d
0d
121 d?
1 d?
5d
5d
0d
47 d
45 d
0d
2d
0d
0d
66 d
1d
1d
Start
1, 2013
F M A
Thu 6/13/13
Wed 6/19/13
Wed 6/19/13
Thu 5/16/13
Thu 5/16/13
Thu 5/16/13
Thu 5/23/13
Thu 6/20/13
Thu 6/20/13
Thu 7/4/13
Thu 7/4/13
Fri 3/15/13
Fri 3/15/13
Fri 3/15/13
Thu 5/16/13
Thu 5/16/13
Wed 5/22/13
Thu 5/23/13
Thu 5/23/13
Thu 6/20/13
Tue 6/25/13
Wed 6/26/13
Thu 7/25/13
Thu 7/25/13
Wed 7/31/13
Fri 3/15/13
Fri 3/15/13
Thu 6/20/13
Thu 6/20/13
Wed 6/26/13
Thu 6/27/13
Thu 6/27/13
Wed 8/28/13
Thu 8/29/13
Fri 8/30/13
Fri 8/30/13
Thu 6/20/13
Thu 6/20/13
Thu 6/20/13
M
J
Half 2, 2013
J A S O
N
D
Half 1, 2014
J F M A
6/19
6/19
5/22
6/26
7/31
6/26
8/28
8/30
8/30
Vorgang
Meilenstein
Externe Vorgänge
Unterbrechung
Sammelvorgang
In Arbeit
Stichtag
Seite 2
M
J
Half 2, 2014
J A S O
N
D
Hal
J
ID
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
Task Name
Duration
6.2 Test setup
6.2.1 Set up test environment
6.3 SW QA Test phase
6.3.1 SW QA testing according to test specific
6.4 Reporting
6.4.1 Test Reports available
6.5 SW Correction Loop based on QA test resul
6.5.1 Run SW Correction Loop and SW QA re
6.5.2 Final QA Test Report
6.6 Update of release and release documentatio
6.6.1 Update of release and release documen
7 Factory acceptance test (FAT)
7.1 Hardware acceptance testing
7.1.1 Testing on Prototype
7.1.2 Customer sign off on Hardware, Product
7.2 FAT testing procedures
7.2.1 Generation of FAT Test Procedures
7.2.2 FAT Test Procedures Approval by custo
7.3 FAT test setup
7.3.1 FAT test set up completed
7.4 FAT testing
7.4.1 FAT testing inclusive SW correction loop
7.4.2 FAT Test Approval
8 Production and delivery
8.1 Procurement
8.1.1 Back end System, and other third party d
8.2 Prototype production (QMV 0077)
8.2.1 Production / receipt of required Prototyp
8.2.2 Testing and Quality Check on Prototype
8.2.3 Completion of prototype production (QM
8.3 Serial production
8.3.1 Production of Subassemblies and delive
8.3.2 Device Production
8.3.3 Delivery and shipment
8.4 Back End System
8.4.1 Receipt of Back End System
8.4.2 Delivery and shipment
8.5 Completion of production and delivery
9 Installation and commissioning
Datum: Wed 2/27/13
2d
2d
2d
2d
1d
1d
7d
5d
2d
2d
2d
71 d
3d
2d
1d
2d
1d
1d
5d
5d
5d
5d
0d
83 d?
5d
5d
25 d
20 d
5d
0d
50 d?
30 d?
15 d
5d
75 d
60 d
3d
0d
106 d
Start
1, 2013
F M A
M
Mon 9/2/13
Mon 9/2/13
Wed 9/4/13
Wed 9/4/13
Fri 9/6/13
Fri 9/6/13
Mon 9/9/13
Mon 9/9/13
Mon 9/16/13
Wed 9/18/13
Wed 9/18/13
Fri 6/21/13
Thu 8/1/13
Thu 8/1/13
Mon 8/5/13
Fri 6/21/13
Fri 6/21/13
Mon 6/24/13
Mon 9/16/13
Mon 9/16/13
Mon 9/23/13
Mon 9/23/13
Fri 9/27/13
Thu 6/20/13
Thu 6/20/13
Thu 6/20/13
Thu 6/27/13
Thu 6/27/13
Thu 7/25/13
Wed 7/31/13
Tue 8/6/13
Tue 8/6/13
Tue 9/17/13
Tue 10/8/13
Thu 6/20/13
Thu 6/20/13
Mon 9/30/13
Mon 10/14/13
Wed 6/19/13
J
Half 2, 2013
J A S O
N
D
Half 1, 2014
J F M A
9/27
7/31
10/14
Vorgang
Meilenstein
Externe Vorgänge
Unterbrechung
Sammelvorgang
In Arbeit
Stichtag
Seite 3
M
J
Half 2, 2014
J A S O
N
D
Hal
J
ID
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
Task Name
Duration
9.1 Preparation
9.1.1 Installation Test Procedures Completed
9.1.2 Site survey
9.2 Installation phase
9.2.1 Configuration
9.2.2 Installation
9.2.3 Installation acceptance
10 System Acceptance
10.1 Reliability, Maintainability and Accuracy Test (
10.2 System Acceptance
11 Documentation and Training
11.1 Manuals
11.1.1 Generation of Manuals
11.1.2 Approval of manuals by customer
11.1.3 Completion of Manuals
11.1.4 As-built System Design Document Com
11.1.5 Final Documentation (if updated) Comp
11.2 Training schedules
11.2.1 Training Material Provided
11.2.2 Training Courses
11.2.3 Completion of Training
12 Warranty
13 Close out phase
13.1 Negotiation of Close out
13.1.1 Final signing off
13.1.2 Confirmation of close out
13.2 Completion of close Out
14 Handover to Service PM - SRV
14.1 Handover document
14.1.1 Creation of handover document and ac
14.2 Completion of Handover to Service
15 End of project
Datum: Wed 2/27/13
Start
1, 2013
F M A
50 d Wed 6/19/13
0d
Wed 6/19/13
10 d
Thu 8/15/13
31 d
Thu 10/3/13
5d
Thu 10/3/13
21 d Tue 10/15/13
2 d Wed 11/13/13
0 d Thu 11/14/13
0 d Thu 11/14/13
0 d Thu 11/14/13
157 d
Fri 4/5/13
127 d
Fri 4/5/13
1d
Mon 9/2/13
20 d
Tue 9/3/13
0d
Mon 9/30/13
0d
Fri 4/5/13
0d
Mon 6/17/13
51 d
Mon 9/2/13
0d
Mon 9/2/13
30 d
Tue 10/1/13
0 d Mon 11/11/13
263 d Wed 11/13/13
15 d
Fri 11/15/13
15 d
Fri 11/15/13
10 d
Fri 11/15/13
5d
Fri 11/29/13
0d
Thu 12/5/13
5d
Fri 12/6/13
5d
Fri 12/6/13
5d
Fri 12/6/13
0 d Thu 12/12/13
0d
Fri 11/14/14
M
J
Half 2, 2013
J A S O
N
Half 1, 2014
J F M A
D
M
J
Half 2, 2014
J A S O
N
D
Hal
J
6/19
11/14
11/14
11/14
9/30
4/5
6/17
9/2
11/11
12/5
12/12
11/14
Vorgang
Meilenstein
Externe Vorgänge
Unterbrechung
Sammelvorgang
In Arbeit
Stichtag
Seite 4
Fare collection
systems
2
2.1
Deliverables
FareGo
Sales
ST|70
Vending Machine
2.1.1
Ticket
General Function TVM
The overall design approach of Scheidt &
Bachmann emphasises the use of low-risk,
proven equipment and components that can be
used to create an open-system solution. The
hardware components, operating system,
database,
communication
protocol
and
hardware interfaces are all based on current
industry standards.
This design methodology has allowed Scheidt
& Bachmann to design an innovative fare
collection system.
Scheidt & Bachmann has many years of
experience in the vending and cashier
equipment industry. Scheidt & Bachmann
FareGo Sales ST|70 Ticket Vending Machines
(TVM) have been upgraded over the years to incorporate both technological changes
and customer trends. These changes have addressed user friendliness and greater
ticket vending efficiencies without sacrificing security aspects.
The design of the proposed TVM takes into account that the TVM – according to
specific requirements of a given location – can be installed stand alone or in lines.
The housing is based on a design which integrates desk like elements in the TVM
facade. The TVM will be equipped with a user friendly integration of high visibility TFT
screen, touch screen operation, coin- and bank note slots in the front of the TVM. The
design takes into consideration the overall ergonomics associated with the components
of the user interface. The overall goal of component location is to minimise the amount
of movement a customer will need to make during a ticket transaction.
When installed, the TVM complies with Americans with Disabilities Act Accessibility
Guidelines (ADAAG) adopted by DOT regulation (49 CFR Part 37 as amended Oct 30,
2006). Additional related features of our TVM include:
•
•
•
•
•
Voice prompts with both audio speaker and headphone jack
Braille/raised letter signage
Single handed operation with operating forces less than 5 lbs
Reach ranges for wheel chair access
Accessible coin entry slots; the highest unit slot is 48 in
Page 8
Fare collection
systems
•
•
Accessible coin return tray; lowest unit height is 22 in
Customer display tilted to 30° for enhanced viewing
Scheidt & Bachmann TVMs are designed:
•
•
•
•
•
to be suitable for operation in an outdoor environment
to be vandal resistant and secure
ergonomically and suitable for use by disabled people
to operate as standalone machines
to be integrated in an online driven management system
The Scheidt & Bachmann design methodology incorporates the use of standard
components in a modular fashion. This methodology allows Scheidt & Bachmann to
easily incorporate changes in technology as they occur.
The use of standards, both internal Scheidt & Bachmann standards and international
standards, coupled with the modular design methodology is an important aspect relating
to the long-term support of the system Scheidt & Bachmann is proposing to its
customers.
All programming is done in standard languages, and data communications use standard
interfaces and protocols. In the future, such system aspects as central computers can
be upgraded with a minimum of difficulty due to the use of standard operating systems
and interfaces.
The TVM includes the following:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
TVM Housing with Lighting Top
TVM Base
15" Color TFT Touch Screen User Interface (Landscape Mode)
TVM Coin System
TVM Banknote System
Credit / Debit Card Reader
Ticket System for Credit Card Size Paper tickets with Magnetic (4 rolls)
Smart Card Dispenser with 2 stackers with 380 cards each (Optional)
Smart Card Reader Hardware (Optional)
TVM Computer System
Power Supply, Battery Backup
Heating and cooling system
System Software
Customer Application Software
All components are field proven as they are in service in many Scheidt & Bachmann
ticket vending machines in large international projects. The computer system is based
on an industry standard PC running Windows XP Standard.
Page 9
Fare collection
systems
Basic features of the system are:
•
•
•
•
•
•
Standard interfaces, such as RS485, RS232 and TCP/IP.
Modular software design – the same software ‘kernel’ used in all equipment. Only
different device drivers are used for different peripheral modules.
Nearly all software can be loaded and updated without hardware changes
(EPROM, etc.) via a network or using offline data transfer with PCMCIA memory
cards or USB sticks.
Design of data structure used by Scheidt & Bachmann includes tracking of
complete transaction records. That enables the most flexible use of data for all
types of reporting and data processing by the Scheidt & Bachmann Central
Support System.
Full data backup is maintained off-line in dual memory locations in fare collection
equipment. The permanent back-up media is the PCMCIA card. Data storage is
independent of fare collection equipment computer or CSS computer and
contains all transaction records even if the computer fails. The PCMCIA card can
be easily removed and the complete data records transferred to a central location
for backup data recovery.
A backup battery provides for the completion of a transaction that is in process in
case of main power loss.
The TVM will provide the following customer service capabilities
•
•
•
•
•
•
•
•
•
•
Accept cash and credit /debit cards
Read and add trips, passes and stored values
Respond to customer choice of action
Issue Smart Card (Optional)
Register the number of media of each type and price range issued and total
value of fare media sold
ADA compliance
Provide audio output of messages and instructions
Include a security and alarm system
Indicate malfunctions of the unit
Include complete on-line TVM network capability with remote TVM status
monitoring, automatic polling for sales information, a complete audit and
accounting system, ability to remotely command TVMs to reset and selfdiagnose, ability to remotely modify operating parameters, and process all credit /
Page 10
Fare collection
systems
debit card authorization
Upper Front Panel
Speaker
Credit/Debit Card Slot
Coin Slot
Pin/Pad
LC Display
Smart Card target
Headphone Jack
ADA Panel
(Customer Interface Area)
Bank note System Slots
ADA Panel
(Fare Media and Payments)
Front Panel Right Hand
Side
Front Door Lock
Graphic Panel Holder
Lower Front Panel
Change and Ticket Tray
Pedestal Locks
Access Flap
Pedestal
2.1.2
Design Requirements TVM
2.1.2.1 Circuit Breaker
The TVM has a single power switch. Any change in its position sends a message event
to the FareGo Data system and initiates an orderly shutdown when switched to ‘OFF’.
2.1.2.2 Light Fixture
The lighting top contains a bulb to illuminate the front door and a service indicator. The
service indicator will flash to inform service personnel that the TVM requires
maintenance.
The lighting top will be made of 2 mm stainless steel and is equipped with a removable,
lockable cover for service purposes.
The lighting top will also contain the air conditioning unit to ensure the TVM remains
operational in high temperature environments.
2.1.2.3 Display Screen
Though the use of LCD screens in self-service machines is an accepted industry
practice, limitations of readability under direct sunlight are given for all screens on the
market. The special design of the TVM front minimises these restrictions, as it is very
easy for the patron to provide shadow for the screen with his body.
Page 11
Fare collection
systems
Technical Details of the Touch Screen
The sensor is integrated within two laminated layers of lim-natron-glass. This glass is 7
mm thick (3 mm front and 4 mm back) making the sensor very robust and safe.
The advantages of this touch technology are:
•
•
•
•
This technology is not affected by moisture, rain, dirt, grease, harsh cleaning
fluids, solvents, snow and rain, thereby eliminating the need for additional
sealing.
This touch system is very easy to use, even with gloves. It is not necessary to put
any pressure on the touch panel. It is sufficient to place the finger on the surface
to activate the functionality. Depending on the size of the touch buttons – which
is an adjustable parameter completely under software control – it is also possible
to activate the touch screen with the heel of the palm or any other part of the
hand.
The costs for maintenance are very low because there is no drift and so there is
no recalibration required.
With a light transmission of up to 88% the resolution is < 1 mm and the position
accuracy is less than 1% from the reported position.
Further technical details of the touch screen:
•
•
•
•
•
•
•
•
Speed of response: 13msec through 4mm thick glass
Immunity to damage: glass protection provides unsurpassed impact-, vandaland scratch-resistance
Operating temperature: -31° F to +149° F
Detection method: Dynamic capacitance using horizontal and vertical 10 micron
diameter wires
Power requirements: Typically 5mA at 6 to 12 volts which is provided by RS232
port, USB or external source
Humidity: 0 to 90% RH @ 104°F , unaffected by condensation
MTBF (Sensor): Excellent, no
known wear-out mechanism
MTBF (Controller): In excess of 1
million hours – Bellcore TR332
2.1.2.4 Security
All money containers and ticket stock are
locked into the TVM. Matching security
keys are needed to release money
containers and the slide for the ticket
issuing unit. To open the money container
Page 12
Fare collection
systems
itself, keys are needed, which are different from the ones needed to release these
containers. Please find below a table describing which key has to be used and the
recommended users for the different key types.
The keys and locks are manufactured by DOM, and have the key-code YXKE –“X “,
were “X” is the place holder for the various key types (sub-keying), please see table
below:
Location
Key Type
Function
User
1
A
Lock / Release:
Ticket issuing unit slide
Supervisor, Maintainer,
Station Agent
2
B
Lock / Release:
Coin Hopper units
Supervisor, Revenue Service,
Maintainer
3
C
Open / Close:
Coin Hopper units
Supervisor, Revenue
Accounting
4
B
Lock / Release:
Banknote System / Vault
Maintainer
5
C
Open / Close:
Banknote Vault
Supervisor, Revenue
Accounting
6
B
Lock / Release:
Coin Vault
Maintainer
7
C
Open / Close:
Coin Vault
Supervisor, Revenue
Accounting
8
B
Lock / Release:
Coin Escrow units drawer
Maintainer
9
KEY cylinder
lock
Open / Close:
TVM front door
Maintainer, Station Agent
The money containers (coin vault, banknote vault, coin hoppers, and coin escrow units)
have to be opened and emptied by the revenue accounting department prior to
providing the units to the maintainer for corrective or preventive maintenance.
2.1.2.5 Cabinet
The construction material for TVM housing is shown in the following table:
Housing /
Front Door
Housing
2 mm stainless steel (1.4301 N)
Door
Encapsulating Box
Lighting Top
2 mm stainless steel
TVM Base
2 mm stainless steel
Page 13
Fare collection
systems
The listed construction material allows the TVM housing to be installed (with a 15 year
life) in a coastal atmosphere (not directly exposed to sea or sea spray), when all exterior
surfaces are primed and painted properly.
The TVM housing provides easy access to all of the operational components of the
Ticket Vending Machine such as:
•
•
•
•
•
•
•
•
•
•
TVM PC
Coin System
Banknote System
Ticket processing Unit
Smart Card Dispenser
Smart Card Antenna
Alarm Unit
Power converter and distribution (including a 230 VAC Maintenance Power
Socket)
Heater/Blower Unit
TFT Touch Screen
The TVM is constructed of stainless steel sheet metal. The overall construction is done
in a way to minimise any visible seams to prevent the insertion of pry bars.
Access to the TVMs will be by high security keys. PIN-entry after door opening is
required for identification of the authorized person.
Provisions are made to avoid unauthorized access to the TVM. The TVM’s door is a
one-piece construction that is mounted on the front of the machine to permit revenue
and maintenance servicing. All hinges are secure and isolated from view.
2.1.2.6 Lock and Key
First of all the TVM is in general secured against unauthorized access from outside by a
front door lock (security lock with secured keying).
The lock on the front door is covered with a metal flap (stainless steel) that has to be
released by a special tool to get access to the lock.
2.1.2.7 Local Alarm
Alarm Unit
The alarm system of the Scheidt & Bachmann TVM performs two functions in case of
unauthorized access (intrusion or wrong/missing pin entry) or tilting the TVM:
•
•
It sounds a siren
It sends an alarm message to the FareGo Data system (when TVM is powered
and online)
•
Page 14
Fare collection
systems
Intrusion Alarm
An intrusion is activated in the event that the TVM door is opened without being
unlocked. The TVM detects such an occurrence via the door contact, the bolt bar
control contact and the locking contacts. Upon opening, the door lock contact and the
bolt bar control contact have to be activated prior to the activation of the two closed
contacts situated on the upper and lower part of the door. Otherwise, if the closed
contacts (or only one of them) are triggered without activation of the door lock and the
bolt bar control contact, e.g. in case of an opening attempt using a pry bar, an intrusion
alarm will be set off.
The following actions will be triggered in case of an intrusion alarm:
•
•
Siren 110 dB (A), local alarm for a configurable time (adjustable at the TVM and
normally set to 60 seconds)
Alarm message sent to CSS (when TVM is powered and online)
In case of a failure of the main power supply (230 V) the TVM alarm system including
siren will remain battery-buffered for at least 24 hours, if the battery buffer was fully
charged prior to the power failure (48 hours charging without buffering activities). Since
the TVM-computer (SBC-1) is shut down in case of power failure, no online message
will be sent to the FareGo Data system.
Once the alarm condition is triggered, it is only reset when a valid PIN is entered, or the
alarm unit loses power.
2.1.2.8 Ventilation
The TVM is ventilated to provide a constant temperature distribution within the TVM
during normal operation. This ventilation is controlled through a tri-point temperature
control unit.
The TVM will be equipped with an air condition system in order to operate within the
specified operating conditions.
2.1.3
Control System TVM
The TVM microprocessor assembly is based on an IBM PC compatible architecture.
The assembly controls all TVM functionality including the collection, storage and
transmission of data. A PCMCIA interface is used for the removable media support.
There are two PCMCIA data slots available and they are configured as follows:
•
•
“Permanent” PCMCIA data module that mirrors the transactions recorded to the
local TVM hard-drive.
“Non-Permanent” PCMCIA data module that is used for offline data transfer.
The TVM uses the “permanent” data module for backup storage of transactions that can
then later be used for offline data transfer. The term “permanent” refers to the fact that
this module is always mounted in the TVM and is not normally removed for transfers. An
Page 15
Fare collection
systems
offline transfer would use the “non-permanent” slot to transfer the data transactions to
the other PCMCIA module.
The “non-permanent” slot is used for the following:
•
•
•
Initializing a new hard-drive with the fare tables and associated operational files
Offline fare table or other software updates
Offline data transaction transfers
The term “non-permanent” refers to the fact that this module is not always mounted in
the TVM but is normally used for actual data transfers.
2.1.3.1 Cancel Functionality
TVMs permit cancellation of an ongoing transaction (initiated manually by the customer
or automatically by the device) under the following conditions:
•
•
Cash payment is not completed
Cashless payment medium is not inserted or tagged (credit or debit card –
magnetic stripe or contactless -- stored value card, partner-issued card)
To manually cancel a transaction, the customer presses the clearly marked “cancel”
button on the front panel of the TVM.
Upon manual cancellation, the TVM reacts as follows:
•
•
•
•
A “Transaction Cancelled” message is displayed on the display screen
Coins and bills in escrow return to the customer.
TVMs provide for true escrow functionality and return the very same coins and
bills as inserted with this transaction
The TVM is ready for processing the next transactions within 5 seconds of the
cancellation (under normal operating conditions, when no more than 10 coins
and 5 bills have been inserted, and including the inter-transaction time-out)
2.1.3.2 Time Out Functionality
A time out function will be provided to limit the time between successive steps after
initiating a selection.
2.1.3.3 Audit Functionality
To provide performance statistics for maintenance and revenue staff, the TVM will
maintain internal counts of essential TVM data to allow for full recovery from loss of
transactional and fault data. The status of the following conditions will be possible to
determine at all times:
•
•
Amount of money, by denominations, in each of the currency units including
vaults, hoppers and recirculation
Number of transactions since last data download, by ticket/fare type and total
Page 16
Fare collection
systems
•
•
•
•
Number of TVM failures since last data downloads
TVM events since last data download
Total money received, change issued, and overpayment accepted since last data
download
Amount of money inserted through coin slot to fill recirculation units
2.1.3.4 Data Storage and Transfer
The TVM will collect and store data in the TVM’s hard drive. The TVM will transmit the
data to the FareGo Data system. All event and transaction data will be transferred to the
FareGo Data system via network connection
2.1.3.5 Alarm and Event Transmission
Scheidt & Bachmann devices provide for a wide range of events that can be classified
as alarms at the discretion of the system operator. This is fully configurable through the
workstations for authorized users. Alarms are further divided into different alarm groups
to allow for quick allocation of the type of alarm and filtering. The following table
provides an excerpt of events that are most commonly classified as alarms and their
associated alarm group.
Device
Description
Alarm group
General
Power fail
Maintenance
General
Manipulation alarm
Security
General
Login associated alarms, such as wrong PIN,
unknown user ID, timeout, locked user ID, etc.
Security
General
Machine boot / shut down, along with reason for Maintenance
boot / shutdown and initiating entity
Ticket Issuing Unit
Problems with the ticket issuing system, such
as movement errors, sensor problems, read /
write errors during encoding, etc. along with
information on nature and location of problem
Maintenance
Ticket Issuing Unit
Information on ticket stock status such as stock
low, stock end along with stock number
Revenue
Ticket Issuing Unit
Ticket bin full along with bin issuing system
number
Revenue
Application
Application status changes such as out of
service, in service, boot, etc.
Computer Support
Credit / Debit System Problems with credit / debit card reader such as Maintenance
no response from reader or PIN pad or sensor
problems.
Credit / Debit System Credit and / or debit work not possible
Computer Support
Page 17
Fare collection
systems
Device
Description
Alarm group
Credit / Debit System Authorisation interrupted by user/time
Security
Main Computer
Problems with data carrier module such as
module not available, cannot be read, etc.
Status changes, e.g. boot, door open, etc.
Maintenance
Main Computer
Timeouts during login
Security
Version Control
Bad status of version loads
Computer Support
Data Recording
Module
Problems with data recording such as file not
found, drive not ready, read/write errors, drive
full, etc.
Computer Support
2.1.4
Auxiliary Power TVM
TVMs have a battery buffer power system that provides power to the TVM in the event
of an interruption of the main power source. The battery buffer has the capacity to:
•
•
•
•
Complete a smart media purchase transaction (only if payment for the smart
media has been completed)
Permit an orderly shutdown of TVM systems to occur
Provide power to the internal TVM alarm unit for at least a one hour period while
the main power source is not available
Permit transmission of all associated event data to the DMRS prior to the orderly
shutdown of the TVM systems
2.1.5
Bill Handling TVM
2.1.5.1 General Requirements
The TVM will be capable of accepting and
validating and counting US paper currency
bills in the following denominations:
•
•
•
•
•
•
One dollar
Five Dollar
Ten Dollar
Twenty Dollar
Fifty Dollar
One hundred Dollar
The bank note system is a Mars (company)
bank note verifier, models BNA 571-5, with a
removable security bank note vault, model
542-1. The verifier accepts multiple bank
Main Computer
V.11
Board
Bank Note
Validator
Bill Vault Lock,
Key C
SEPTA 142
Page 18
Fare collection
systems
note types (or variants of bank notes) depending on the selected model. Bank notes
inserted store in escrow until the transaction is either finished or canceled. Upon
cancellation, the customer’s actual bank notes are returned from the escrow. If a
transaction is finished satisfactorily, the bank notes move into the bank note vault
The major components of the bank note system are the validator (made-up of the
acceptor/verifier, escrow unit, and stacker) and bank note vault, as shown in the figure
below. Its unique serial number identifies each bank note vault. Encoded serial numbers
will identify the money container as a bank note vault. The device automatically reads
and identifies the bank note vault serial number. In addition, each bank note vault is
marked with a unique serial number, in a manually readable form, on the outside of the
container. The numbers will be of a sufficient size, of adequate contrast, and in the
correct orientation to be readable when the bank note vault is in place for operation
within the FVM.
The bank note handling system includes a bank note acceptor/verifier, bank note
escrow, bank note stacker, and bank note vault. The system accept s$1, $5, $10, $20,
$50 and $100 bank notes including any old and new versions in circulation at the time of
the TVM installation.
2.1.5.2 Bill Validator
The bank note acceptor/verifier, bank note escrow unit and stacker together are called
the bank note validator. The bank note vault slides into place on the bottom of the bank
note validator.
The major function of the Bank Note Validator is to accept and verify the authenticity of
all bank notes that are inserted into the TVM, recognize their value, forward the
appropriate credit signal to the main computer, and store the bank notes. The Bank
Note Validator is capable of accepting a variety of U.S. dollar denominations ($1, $5,
$10 $20, $50 and $100), and uses two bank note slots, the Insertion Slot and the Bank
note Rejection Slot. It can also provide 4-way bank note acceptance, which is client
programmable. A bank note can be inserted either end first, face up or face down.
The Bank note Insertion Slot is equipped with a light-emitting diode (LED). When the
Acceptor is ready to accept a bank note, the LED is green. While the Verifier is
processing a bank note, the LED is red and indicates it is not available to process a
bank note until current processing is completed. When the Bank Note Validator is not
operational, the LED is not illuminated, which means that no bank notes can be
processed. Once a bank note has been verified, the bank note is moved to the Bank
note Escrow Unit, and any invalid bank notes are returned via the Bank note Rejection
Slot on the bottom-front of the unit.
2.1.5.3 Bill Escrow
The bank note escrow unit is located inside at the rear of the bank note validator. The
function of the escrow unit is to store accepted and verified bank notes until the
transaction is completed, and the ticket has been issued to the customer.
Page 19
Fare collection
systems
While a transaction is being processed, the escrow unit drum stores each valid bank
note on top of the previously inserted bank note. The escrow unit can hold up to 15
bank notes, which is the maximum number of bank notes accepted per transaction.
When the transaction is completed, the bank notes are moved from the escrow unit to
the bank note vault by the transport belts and the stacker (a stacking piston).
If a transaction is cancelled or an error occurs prior to the transaction being completed,
the bank notes that were inserted for the transaction are moved from the escrow unit
drum and output through the bank note rejection slot where the customer may retrieve
them.
2.1.5.4 Bill Vault
The bank note vault is located under the bank note validator. The function of the bank
note vault is to collect and store accepted and verified bank notes once a transaction is
successfully completed. Bank note vault design permits only a single placement of the
bank note vault into the TVM after emptying. A shutter locks in a position to close off the
opening when the bank note vault is removed. Bank notes vault capacity is 2,000 bank
notes nominally.
The bank note vault is typically removed by field revenue personnel then opened,
counted and reconciled by accounting revenue personnel. It is secured in place with a
retaining lock. The red/green flag on the bank note vault is red whenever the vault is in
the TVM and when it is initially removed from the TVM. The flag turns green when the
vault is opened using Key C and remains green until the vault is closed, installed, and
then locked in the TVM.
The vaults are equipped with two different locks: one to remove the vault from the TVM,
the other to open the vault. Therefore, the bank note vaults in the field are fully locked
and not accessible to the revenue personnel.
Each bank note vault is identified with a unique serial number. This ID is coded in an
EEPROM and is transferred to the TVM by a contact on the vault. Each bank note unit
in the TVM has a contact at the appropriate position to read the serial numbers of the
inserted bank note vault. On removal of the bank note vault, the TVM recognizes which
vault has been removed. Similarly, it recognizes the insertion. The insertion of the very
same vault (same serial number) is not allowed. The TVM will go into out-of-service
mode if the same vault is re-inserted.
The FareGo Data system is able to monitor in which TVM an individual vault is located.
A removal/insertion of the vault will create a message to the FareGo Data system,
indicating which vault was taken out/inserted by which revenue or service person. Shift
data (e.g., sales data) is recorded together with the serial number of the related bank
note vault. This allows clear reconciliation of counted and recorded revenues according
to the vault serial numbers.
Page 20
Fare collection
systems
2.1.6
Coin Handling TVM
2.1.6.1 General Requirements
The purpose of the coin system is to accept, verify, store, and provide change for all
coin and bank note transactions. The TVM coin system accepts the following US
currency:
•
One Dollar Susan B, Anthony and Golden Dollar
•
Half Dollar (50 cent)
•
Quarters (25 cents)
•
Dimes (10 cents)
•
Nickels (5 cents)
•
Token
The basic functions of the TVM coin system are as follows:
•
After selecting a ticket the coin slot opens and coins can be inserted.
•
Coins inserted are validated by the electronic coin validator. Foreign coins and
detected fake coins are rejected and given back to the patron.
•
Coins accepted are fed
into the corresponding
recirculating
coin
cassettes by means of
an
electronic
coin
diverter. In standard
operation mode there is
an
individual
recirculating
coin
cassette for each coin
type accepted by the
coin system.
•
•
The
recirculating
cassettes are used as
an escrow as well as
for change giving.
Up to 3 Auxiliary
Coin Cassettes
Coin Slot
Coin Acceptor
Up to 6 Recirculating
Coin Cassettes
When
a
payment
transaction is cancelled
by the patron the coins
inserted are given back
out of the recirculating
cassettes.
Coin Vault
Page 21
Fare collection
systems
•
If a recirculating cassette is filled completely, the coins accepted during 'old
transactions' are distributed to the coin vault via an overflow exit.
•
Change is given out of the recirculating cassettes and – if there is not enough
money in the recirculating cassettes – out of the auxiliary coin cassettes (non recirculating coin hoppers).
•
If there is not enough change available, the TVM will switch to 'Exact Fare‘ mode.
•
If the coin vault is full the TVM does not accept payment by coins and displays
this status by an associated appropriate indication to the patron. The TVM also
notifies this status to the CSS by an event.
•
All change from the TVM is dispensed by the coin system.
2.1.6.2 Coin Slot
The coin system has a mechanical shutter that seals the coin slot between transactions.
This coin slot will automatically open for cash based transactions but not for electronic
payment transactions.
The coin slot is manufactured to match precisely the coin acceptor, but is still made as a
separate unit. This foregoes unnecessary coin diversions and jams.
2.1.6.3 Coin Validator
Inserted coins pass through the coin slot by gravity to
the coin acceptor. The coin acceptor NRI-model G13.MFT09V30/5 is used.
The coin verification is based on diameter, thickness
and metallic content. The settings from which
comparisons are made are established by the NRI
programming station and are based on US coins in
general circulation. This information is stored internally.
The coin acceptor provides 2 blocks of 12 validation channels each. At any time, only
one of the blocks can be active. Switching from one block to the other one is done by
means of the TVM software. In Scheidt & Bachmann TVMs, as standard, one block is
programmed for validating national coins, the second is programmed for validating
€URO-coins.
The 12 validating channels of a block are assigned to the 6 recirculating coin cassettes
of the Scheidt & Bachmann coin system.
The individual channels may be activated / deactivated by means of dip switches.
The ‘national’ block of the coin acceptor is programmed to accept $0.05, $0.10, $0.25,
$0.50, $1.00 coins
Page 22
Fare collection
systems
Under normal operating conditions in the normal validating channel 100% of the valid
coins in public use are accepted after the 1st insertion. In the narrow validating channel
99% of the coins are accepted after the 1st insertion.
The coin diverter MV20 is located just below the coin verifier. The transport and the
direction of the coins are controlled by a microprocessor. The microprocessor analyses
directly the signal from the coin verifier and guides the coin to the appropriate coin
magazine. When the coin has reached the correct position the coin diverter processor
sends a signal to the coin controller board. Then the coin controller board sends a
signal to the solenoid and opens the coin flap, so that the coin is dropped into the coin
cassette.
2.1.6.4 Coin Recirculation
The recirculating coin cassette is electronically encoded and has a serial number that is
visible from the outside. A cassette for each type of coin accepted will be provided.
The recirculating coin cassettes support the following:
Removal of a coin cassette will create an
event and an event message can be sent
to the CSS. This event message will
include the contents of the cassette and
the unit number.
The capacities are as follows:
Coin Type
Capacity
$1
106
50cent
106
25cent
106
10cent
148
5cent
124
Each cassette and corresponding slot is
clearly labelled as to which coin type is accepted. This also facilitates quick and easy
exchanges.
Cassettes can only be installed in one direction.
Page 23
Fare collection
systems
The cassettes are constructed to withstand being dropped when either fully loaded or
empty without sustaining distortion, operational impediments or security breaches.
Coin Entry
Overflow into
Coin Vault
Coin Exit to Coin/Ticket Tray
( Cancellation and Change Giving )
2.1.6.5 Coin Vault
The coin vault for accepting coin cassette overflow is electronically encoded and has a
serial number that is clearly visible from the outside. The coin vault is located near the
front of the TVM to facilitate easy exchange by revenue service personnel. The coin
vault has no openings when removed from the TVM and conforms to the following
specifications:
•
The volume is approx. 7 dm³.
•
Removal and reinsertion of the same vault is not possible
•
The vault can only be installed in one direction.
•
The vault is constructed to withstand being dropped when either fully loaded or
empty without sustaining distortion, operational impediments or security
breaches.
2.1.6.6 Auxiliary Change Storage Units
The auxiliary coin magazine is electronically encoded and has a serial number that is
visible from the outside. The auxiliary coin magazines support the following:
•
The coin magazine can be loaded manually.
•
Removal of a coin magazine will create an event and an event message can be
sent to the CSS. This event message will include the contents of the cassette
and the unit number.
The capacities are as follows:
Coin Type
Capacity
$1
1,150
25c
1,400
10c
1,600
Page 24
Fare collection
systems
•
Each magazine and corresponding slot is clearly labeled as to which coin type is
supported. This also facilitates quick and easy exchanges. The slots can be
configured by the customer as to which type of magazine will be placed in the
slot.
•
Magazines can only be installed in one direction.
•
The magazine is constructed to withstand being dropped when either fully loaded
or empty without sustaining distortion, operational impediments or security
breaches.
Please note that there is room for up to three (3) coin magazines. In this proposal three
(3) coin magazines per TVM are included. The type of magazine can be selected
according to the above table.
2.1.7
Credit / Debit (TVM)
2.1.7.1 Card Reader
The TVM accepts and processes credit / debit cards issued by financial institutions such
as American Express, Discover, MasterCard and Visa. The cashless method of paying
for tickets is with credit and/or debit cards, inserted into the magnetic stripe Card
Reader or tagged contactlessly to the smart media processor (optional) at the TVM.
The magnetic stripe credit / debit card reader is installed in the TVM door to the right of
the touch screen, directly above the PIN pad. The card reader’s function is to scan
magnetic information from the card when it is inserted and removed, and transmit the
information to the ECU where it is processed and forwarded to the centralized DMRS.
The TVM is equipped with a magnetic stripe card reader and PIN-pad as described in
this section.
Customer Key Pin Pad
The keypad performs two functions:
 Entering of Debit Card PINs including cancellation via the “Cancel” button for debit
card payments
 Application Control for visually impaired patrons; buttons to be pressed for certain
selections/commands are announced by the FVM’s audio system
Key features of the keypad are:
 10 numeric keys in ATM-style configuration
 ENTER and CLEAR key
 Choice of two cryptographic key management schemes: Master/Session
 DUKPT (Derived Unique Key Per Transaction)
 ASCII character command protocol
 RS 232 Communication
For operation by visually impaired patrons, the center key (“5”) of the numeric pad is
equipped with a raised dot
SEPTA 151
The keypad on the TVM allows entry of a personal identification number (PIN) code
when a debit card is used for payment. Hardware encryption is provided for debit card
transactions.
Page 25
Fare collection
systems
Software
The credit / debit handling at the TVM is controlled by Scheidt & Bachmann-developed
software modules that communicate on-line with the FareGo Data system in order to
perform the cashless transaction.
Upon use of a credit / debit card (magnetic stripe via the reader described here, or
contactless via the SMP), the TVM will check locally if the card data read actually can
be read as a payment medium. If this check cannot be verified, an appropriate message
will be displayed, typically “insert/tag card once more.” Successfully read as payment
card information, the card data is processed by the FareGo Data system, where a
central check against a negative list and a velocity check are performed. With these
tests passed, the FareGo Data system requests an online authorization to the
clearinghouse for which the system is configured. The FareGo Data system will receive
an “OK” not “Not-OK” from the Clearing House, which is provided back to the TVM
which originated the transaction.
With this information received back, the TVM will finalize its transaction. Denied
authorization requests are recorded in the TVM’s transaction records including a denial
reason according to the details provided with the “Not OK” message.
This cashless payment processing principle is implemented in each Scheidt &
Bachmann USA fare collection project which includes cashless payment.
Magnetic Bank Card Reader
The credit / debit card reader will be the model MagTek IntelliStripe 65, manually
operated (dip-insertion) hybrid card reader, designed for unattended terminal
applications. The following features are found in the MagTek IntelliStripe 65:
•
Vandal resistant chassis incorporating coin and “half card” drop out while
preventing bent cards falling into the terminal
•
Secure gate to prevent coin insertion
•
8 smart card contacts (for optional e-purse payment)
•
Up to 3 tracks of magnetic reading with bi-directional read capability
•
Multiple mounting options including front mount brackets or side mount pins
•
Card latch/lock
•
Power failure automatic latch/lock release system
•
Fraud wire detection system
•
Low power operation
•
12 volt electronics
•
On board Security Access Module (SAM) with support for up to 7 SAMs located
on an additional PCB
Page 26
Fare collection
systems
•
Drivers for Windows 2000, Windows NT, Windows 98, Windows 95, Windows XP
•
RS 232 communication interface
The Card Reader reads cards that meet standards defined by ISO 7810, 7811-1, 78112, 7811-3, 7811-4, 7811-5, and 7811-6.
Contactless Bank Card Reader (Optional)
The smart card reader interface is Scheidt & Bachmann's own design, manufactured
and developed fully in-house.
The reader is specifically developed for the use in public transport environments. The
compact, robust and light-weight execution withstands harsh environments, especially
with respect to shock, vibration and temperature. It supports high-level commands for
short transaction communication cycles.
The reader supports the handling of all layers of ISO14443 Type A or B contactless
smart cards as well as the following industrial standard cards:
•
•
•
•
•
•
•
•
MIFARE® Classic 1 & 4 kByte memory cards, according to ISO 14443, parts 1 –
3
MIFARE® Ultralight processor cards
MIFARE® DESfire processor cards, according to ISO 14443, parts 1 – 4
MIFARE® Plus processor cards
Calypso CD 21 cards
NFC communication technology will be supported
The reader has full ITSO 2.1.4 certification
EMVCo authorization level 1 and 2 as well as KA certification are in progress
The reader provides four slots for ISO 7816 compatible Secure Access Modules (SAM).
SAMs will be provided by the Central Server operator. SAMs are not included in the
field devices.
2.1.7.2 Receipt Printing
The TVM incorporates a thermal receipt printer which is used for the production of
receipts and local service reports. This third party component uses standard thermal
Page 27
Fare collection
systems
receipt stock (80mm) which is easily loadable. Receipts will be issued to the
ticket/change tray.
Printed characters are produced with a minimum height of 0.12 inches. The
approximate height to width ratio of the characters will be 5:3.
2.1.8
Fare Media Issuance TVM
The issuing system for credit card sized tickets and/or contactless ISO smart cards
comprises modules entirely developed by Scheidt & Bachmann for various vending
applications. The modules are used in Scheidt & Bachmann ticket vending machines,
fare gates, ticket office machines as well as in all types of equipment for parking
systems.
Configuration
The TVM housing incorporates two complete issuing systems. Each of the systems is
mounted separately on a mounting frame, slide track mounted to the TVM cabinet.
Slide 1 will be configured as follows:
•
2 magnetic encoder
•
2 thermal direct printer
•
1 feed cut unit
•
1 controller and DC power transformer
•
TVM ticket stock: 4 ticket rolls
Slide 2 will not be used, but can be equipped with additional rolls of ticket stock, card
dispenser, or a combination of both.
Ticket Issuing Modules
The ticket system offered here is configured for processing commercially available ISO
credit card size tickets with full printing on the front face. It includes the following
components:
•
Magnetic Ticket Encoder/Decoder MTD/E-12. The magnetic ticket en-coder /
decoder is able to read, write and verify magnetic tickets.
•
Ticket Printer MTP-12. The printing technology used is thermal direct printing. It
can provide full graphics printing features and an extremely short print time.
•
Ticket Feeder MTF-12. The ticket feeder provides a cutter mechanism and is
designed to handle up to 2 different stocks with a unique transport mechanism.
All modules and parts of the ticket handling system are easily accessible and ticket jams
can be cleared without the use of tools with fingertip maintenance. With this
configuration the TVM can dispense 4 different rolls of media, whether it be paper
tickets, poly, or triplex.
Magnetic Ticket Encoder / Decoder
Page 28
Fare collection
systems
The encoder / decoder unit provides
•
Feeding mechanism for ejection of tickets.
•
Adjustable magnetic head for encoding the tickets.
•
Read after write verification
•
Processor controlled stepper motors, which allow for variable transport speed of
the ticket.
•
Scheidt & Bachmann will configure our TVMs to encode magnetic media utilizing
the GFI format provided by the City of Fort Collins.
Ticket Printer
The proposed ticket printer MTP-12 for credit card size tickets uses thermal direct
printing technology. Thermal direct printing offers the following advantages over other
technical solutions such as dot matrix, thermal direct transfer or inkjet printers:
•
Lowest maintenance costs in labor and material because not having to change
any cartridges or ribbons on the printer outweighs the slightly increased costs of
ticket material.
•
Constant print quality over the lifetime of the print head.
•
High lifetime.
•
Printing can be done with a speed of 80 mm/sec and ensures shortest possible
transaction time.
The area that can be printed on is from 1 mm from the left-hand side of the ticket to 1
mm from the right-hand side over the full length, thus covering the full surface of the
ticket (“length” is defined as: parallel to transport direction = parallel to magnetic stripe).
Ticket Feeder
The ticket feeder MTF-12 for credit card size tickets can handle up to 2 different ticket
stocks. For each stock a separate drive with its own stepper motor is provided. The
tickets can be held on rolls or as fan fold stock. Included in this proposal is the use of
rolls. The maximum outer diameter for the rolls is 260 mm.
A cutter device is integrated in the feeder unit.
The tickets are fed into the magnetic ticket system from below. After being cut from the
stock, the tickets reach the ticket path where they are printed and encoded.
Page 29
Fare collection
systems
Smart Card Issuing Modules (Optional)
Introduction to the Hardware Module
The major function of the dispenser unit is to
hold the ticket stock, and to issue Smart
Cards on demand. The dispensers are
located at the top end of the printer unit on
the printer mounting frame. The Smart Card
Dispenser Upgrade Kit comprises of the
following main components:
•
Two cascaded dispensers
•
Card chute to distribute the card to the
ticket issue tray
•
Smart Card antenna in front of the
dispenser unit connected the external
Smart Card reader
Decollator
The decollator contains a feed drive, a
decollator drive, a pair of decollator rollers, a
pass-through path with card transport and a
fork light barrier as a transport sensor.
Card Lift
The major function of the card lift is to
transport the cards to the top of the
magazine. The card lift is located in the bottom of the card magazine.
Card Magazine
The card magazine stores pre-initialized Smart Card stock. It consists of the card lift
platform and two covers. The card magazine can be easily removed and replaced and
is able to hold approx. 380 cards according to ISO 7816 standard. Filling of card
magazines is done in the back office.
Installation of the Smart Card Dispenser
The Smart Card dispenser will be mounted to the second issuing system mounting
frame. The following picture shows the dispenser positioning after installation. To feed
the issued Smart Cards to the issue tray a mechanical shaft is mounted in front of the
dispenser units.
2.1.8.1 Fare Media Inventory
The TVM will have software for counting and monitoring of the card levels. A warning
signal will be sent to the FareGo Data system when the minimum level is detected for
stock replenishment.
Page 30
Fare collection
systems
2.1.8.2 Fare Media Jams
If a smart card jam is detected the TVM will not allow a customer to select the smart
card purchase option in the TVM menu. The TVM will provide the option for the
customer to select other fare media options.
If media types are inoperable the TVM will switch to the "Out‐of‐Service “condition.
2.1.9
Report Journals (TVM)
TVM Report Printing
Each TVM provides preprogrammed report templates upon request for the City of Fort
Collins Revenue Service staff using the TVM receipt stock.
The following reports may be configured:
Cash Container Contents
Reports for the Cash Container may be drawn in the previously configured formats or
customized. Samples of Cash Container Contents Reports for cash statistics are:
•
Cash accumulated by sales/cash issued
•
Cash removed/inserted by revenue
•
Total cash on hand
The Exchange Card reports that may be requested regarding cash flows and handling:
•
Cash on hand
•
Cash in the magazine
•
Cash in the vault
•
Bills in the vault
Stock Report
Our Stock Report indicates the status of the ticket stack and the serial numbers of all of
the statistical events.
Media Failure
Multiple types of reports may be generated by the Reports and Statistics reporting suite
in our FVMs, including custom and configurable reports.
2.1.10
•
•
Customer User Interface TVM
2.1.10.1 Display Screen Interface
The display screen will display instructions, information, and user interface and
be capable of displaying both text and graphics.
The display screen will be the primary means of interface between the TVM and
customer.
Page 31
Fare collection
systems
•
•
•
•
•
The TVM display screen will be user friendly. Braille will be used to comply with
ADA guidelines.
The display will indicate amount due upon selection of fare product type and the
remaining amount due, continuously updated by the amount accepted.
All text messages and information displayed will be capable of being easily
modified.
All TVM messages will be configured in the FareGo Data system and will be
downloaded to the TVMs via both the network and a removable storage media.
All messages will be in English and Spanish with English being the default
language.
2.1.10.1.1
Customer Instructions and Response
The display screen message will respond to the use of the touch screen buttons and will
provide feedback (visual and audio) throughout the fare media purchasing process,
including step by step instructions for purchasing a fare media and error messages
responding to improper customer selections. In addition to the display screen, the TVM
also will provide audio beeps and tones to provide feedback to the customer.
2.1.10.1.2
Display of Operational Conditions
The following indications will be displayed on the screen during applicable special
operating conditions.
•
•
•
•
•
•
•
•
•
Exact fare only
No bills accepted
No coins accepted
Type of fare media not available
No Credit or Debit Cards Accepted
Credit/ Debit Card only
Receipt not available
Time-out transaction cancellation warning
Out of service
2.1.11
Servicing and Maintenance TVM
2.1.11.1 Revenue Servicing
All money containers and ticket stock are locked into the TVM. Matching security keys
are needed to release money containers and the slide for the ticket issuing unit. To
open the money container itself, keys are needed, which are different from the ones
needed to release these containers. The below table describing which key has to be
used and the recommended users for the different key types.
Page 32
Fare collection
systems
The money containers (coin vault, banknote vault, coin hoppers, and coin escrow units)
have to be opened and emptied by the revenue accounting department prior to
providing the units to the maintainer for corrective or preventive maintenance.
2.1.12
Environmental Conditions TVM
The Ticket Vending machine will be able to operate under the following environmental
conditions:
Environmental Interference
Storage Temperature
-5°F to +122°F
Storage Humidity
30% to 90%, non-condensing
Operating Temperature
-14°F to +149°F
Thermal Shock
Up to ±30°F in 2 hours
Relative Humidity Range
30% to 90%, non-condensing
Intermittent Shock
Up to 1 m/s², 20 ms duration, half sine wave,
repeated at intervals of 1 second
Electromagnetic Interference
EN 55022: 1998 +A1: 2000
Radio disturbance characteristics
EN 61000-3-2: 2000
Limits for harmonic current emissions
EN 61000-3-3: 1995
Limitation of voltage fluctuations and flicker in
low-voltage supply systems
EN 50121-4
Electromagnetic Immunity Appliance – railway
applications
EN 61000-4-2: 1995
+A1: 1998
Electrostatic discharge immunity tests
EN 61000-4-3: 1996
+A1: 1998
Radiated, radio frequency, electromagnetic
field immunity test
EN 61000-4-4: 1995
+A1: 2001
+A2: 2001
EN 61000-4-5:1995
+A1: 2001
EN 61000-4-6: 1996
+A1: 2001
Electrical fast transient / burst immunity test
EN 61000-4-11: 1994
Voltage dips, short interruptions and voltage
variations immunity tests
Surge immunity test
Immunity to conducted disturbances, induced
by radio frequency fields
Page 33
Fare collection
systems
2.1.13
Installation Requirements TVM
Scheidt & Bachmann will install and setup all elements of the TVMs at the City of Fort
Collins’ designated locations. To the extent practical the TVM and the associated
equipment will be secured to prevent theft or damage. Scheidt & Bachmann will connect
the TVMs to the existing network communication and power cables. Scheidt &
Bachmann will provide a detailed operating manual for the ticket vending machine on
delivery
2.2
Management Control System
2.2.1
Introduction
To fulfil the need for a Management Control System, Scheidt & Bachmann will be
providing its FareGo Data system. The FareGo Data back office offered by Scheidt &
Bachmann is the central entity for recording data and administering the fare collection
system. The Java-based application software sets new standards in terms of user
ergonomics and intuitive operation. When developing the back office, great emphasis
was placed on the flexible extendibility of the software, so that future developments in
ticket sales and cashless payment applications can easily be integrated into the system.
The back office consists of different software modules. These can be combined with
each other and cover the following areas of the system:
•
Configuration of field devices
Page 34
Fare collection
systems
•
Creation and administration of tariff data
•
Recording operating and settlement data
•
Real-time monitoring of field devices
•
Securing access to devices and data
•
e-Ticketing management
•
Cashless payment methods
FareGo Data supports an integrated, holistic system and provides the interfaces
required between third party systems and the Scheidt & Bachmann system
components. The device management module supports the wide range of field devices
offered by Scheidt &Bachmann, these including:
•
Stationary ticket vending machines
•
Mobile ticket vending machines
•
Validators
•
Fare gates
•
Point of Sale devices
•
Hand-held ticket inspection units
2.2.2
System architecture
The architecture of the fare collection system offered by Scheidt & Bachmann is
composed of four logical levels:
•
Field level
•
Station level
•
Central level
•
Administrative level
A standard LAN / WAN network infrastructure enables communication between the
system levels and the devices installed at the different levels.
Field devices are installed at field level. These devices include gates, ticket vending
machines, validators, point of sale devices and the corresponding local communication
equipment, such as routers and switches.
Data concentrator units and local PC workstations are deployed at station level to
control the communication processes between the field devices and the central level.
These workstations likewise enable staff at station level to access the administrative
functions implemented at the central level.
Page 35
Fare collection
systems
FareGo Data as the central level Software ensures secure and proper function of the
field devices. Wide-ranging system monitoring and control programs are available to
operators for field device administration. In addition, there are generally also local
communication structures, such as network components and routers, and network
management systems, such as Domain Controller.
The administrative level is defined as the totality of all systems and services required to
support the operation of the fare collection system. Examples of such are links to
external tariff databases and credit card authorization for cashless payments.
2.2.3
System overview
The figure below provides a global system overview including FareGo Data.
Page 36
Fare collection
systems
2.2.4
Software architecture
The system architecture was designed to the so-called 3-tier model with thin-client
workstations. This architecture enables reliable data access to the system files, this
forming the basis for the high integrity and availability of the system. The following 3
tiers are differentiated in this architecture:
• Presentation tier, graphic user interface (GUI) between the user and the system
• Execution tier, interface for visual preparation of the data.
• Data retention tier, interface between the application logic and access to the
databases.
All server-side software modules of the execution tier run independently of each other in
the background as Windows services and can be administered separately. The Scheidt
& Bachmann Process System Interface (PSI) encapsulates the modules from each
other and ensures trouble-free communication between the servers and to the field
devices.
The GUIs at workplaces are based on Java and Web standards and have been
developed with special attention to ergonomic design. The software is supplied with
electronic documentation in PDF format.
FareGo Data supports remote maintenance concepts via the commonly used Microsoft
Remote Desktop Protocol (RDP) or other remote servicing software. Secure access can
be provided via VPN connections.
2.2.4.1 Supported system environments
The FareGo Data back office system is based on standard software components, such
as Microsoft's Windows operating systems, Oracle databases and Java-based
application software. It can therefore be easily integrated into an existing IT architecture.
The following system environments are supported:
Component
Software
Application Server
Operating System
Windows Server 2008 R2 x64 (recommended)
Windows Server 2003
Database Server
Operating System
Windows Server 2008 R2 x64 (recommended)
Oracle Linux 5
Windows Server 2003
Database
Oracle Database 11g (recommended)
Oracle Database 10g
Workstation
Page 37
Fare collection
systems
Component
Software
Operating System
Microsoft Windows 7 64 bit (recommended)
Microsoft Windows XP
Java
Oracle Java 7 (recommended)
Oracle Java 6
2.2.5
Hardware architecture and server models
The Scheidt & Bachmann FareGo Data back office system is generally composed of an
application server with an integrated file server and a database server. All servers are
based on standard server architectures.
Depending on the requirements, the system can be extended to take in further
hardware, such as a web server, a reporting server or other servers. In this context, one
physical server can easily take on several logical functions. The actual design of the
computing platforms depends not least on the size of the network, the operator's
requirements vis-à-vis performance and the strategies selected for backing-up and
archiving data. It is defined jointly with the customer during the detailed specification
process. The figure below demonstrates the scalability of the system in dependence on
the size of the network.
The offer contains the software for the Scheidt & Bachmann back office system. We
assume that the network infrastructure and the central hardware required, such as
servers, back-up system, workstations, routers, switches etc., will be provided by the
client. This likewise applies to the operating system software.
Page 38
Fare collection
systems
In terms of the database, an embedded Oracle license is included for the servers
offered.
2.2.5.1 Application server
The application server in the Scheidt & Bachmann back office system is the actual
'active' communication partner. Data is polled from the subordinate system levels (field
level) and controlled by the application server via the programs running there. The sales
devices are not granted direct access to the database. Data from end devices are solely
processed upon request of the application server via upload processes running there
and are subsequently entered in the database. This 'only top down' access represents a
mechanism which ensures that only data from known end devices able to be verified by
the system are entered into the database. Manageable access rights to the back office
represent further protective measures. Data are supplied to the end devices by
analogue download mechanisms; these are likewise controlled centrally by the
application server.
2.2.5.2 File server
The file server serves to store the current application server software modules, the
transaction data from field devices and all files for processing imports and exports of
data.
2.2.5.3 Database server
The database server is designed as a transparent, consistent data depository. All data
relevant for the Scheidt & Bachmann back office are stored in the Oracle database on
this server.
Although the data from the field devices are first deposited on the file server, they are
generally imported into the database directly afterwards, i.e. immediately after they have
been uploaded. In case of data loss, the files are then still held on the field devices and
on the file server as back-ups.
As part of this proposal we have included the embedded license for Oracle. In order to
extract information from the database Scheidt & Bachmann will provide an export ability
that will provide the data in a flat file. The flat file will be provided in a manner that will
be easily imported into other databases. There are alternatives that we would be willing
to discuss which may also suit the needs of the City of Fort Collins.
2.2.5.4 Backup server
FareGo Data can be integrated seamlessly into an existing data back-up concept. Backups of all data (e.g. operating systems, software, databases and transaction files) are
configured on request.
In the standard solution, regular data back-ups of file and database servers are stored
temporarily on a back-up server and later transmitted to a tape drive. Scheidt &
Page 39
Fare collection
systems
Bachmann uses BackupExec from Symantec as the back-up software, although other
software packages or back-up models can be used after agreement.
2.2.5.5 Archive and purge server
In order to keep the database server lean and quick, historical data can optionally be
transmitted to a separate archive server on a regular basis. Such an archive server is a
dedicated Oracle database entity and the data are therefore permanently available for
evaluations.
2.2.5.6 Storage area networks
Storage Area Networks (SAN) are always deployed if several servers are to perform the
same functions, for example in server farms, in case of server virtualisation or for the
provision of substitute servers.
2.2.6
Database licensing
A central element of FareGo Data is the Oracle database server. Scheidt & Bachmann
offers the system with various options for database licensing, these differing from each
other in alignment and use. In this case, a FareGo Data Integration License is deployed.
2.2.6.1 FareGo Data Integration license
Functions, options and the number of licenses depend on the hardware architecture
required by the customer, the number of databases and the processors deployed, in
which virtual environments must be regarded separately.
An Oracle Full-Use license can be offered together with FareGo Data from Scheidt &
Bachmann. This, however, is not part of the FareGo Data license, but should rather be
viewed separately. If appropriate, the Oracle Full-Use license can also be provided by
the customer.
2.2.6.2 Database administration
The Oracle database integrated in FareGo Data needs to be maintained or
administered at regular intervals. The work involved in this context and its frequency
depend upon the size of the system and the customer's IT processes and includes
applications such as changing passwords, adapting the scale of the database, checking
database availability or analysing levels of performance.
Depending on the customer's business requirements, both Oracle tools and programs
from third party suppliers can be deployed for this work. Scheidt & Bachmann can
likewise administer the database as an optional service.
2.2.6.3 Database maintenance
Just as the FareGo Data license and the Oracle license are separate, the maintenance
contracts are likewise separate. Software maintenance for FareGo Data covers the
Page 40
Fare collection
systems
program code of the Scheidt & Bachmann applications and enables patches to be
supplied or the software to be updated.
Database maintenance includes the installation of patches, updates and service packs
for the database. Unless agreed otherwise with Scheidt & Bachmann, these fall under
the customer's remit and they require a software maintenance contract with Oracle. If
the database license is supplied by Scheidt & Bachmann, the first year of such a
software maintenance contract can be supplied together with the database license. The
customer must order this work directly from Oracle for subsequent years.
2.2.7
Network components and band width
FareGo Data consistently uses TCP/IP-based protocols to transmit data throughout all
communication routes.
Servers and workplace computers are typically connected through an Ethernet LAN. In
order to ensure optimal performance, the bandwidth of the network should provide at
least 100 Mbit/s.
All transaction data generated in the field devices or the tariff and operating data
required by the devices can be transmitted between the control computer and the end
devices using online or offline processes.
2.2.7.1 Communication with external services
There are a number of interfaces to external services to import and export the following
data.
•
Tariff and settlement data for import into SAP
•
Import of tariff data etc. from central transport offices
•
Forwarding alarms
Standard protocols (such as ftp, smb or http) are commonly used, with a detailed
specification to be agreed during the system design phase.
2.2.8
FareGo Data CS
2.2.8.1 Introduction
The Scheidt & Bachmann FareGo Data back office system corresponds to current
standards with regard to technology, user ergonomics and simple extendibility.
The GUI at the back office features modern user screens which enable intuitive system
operation. The system applications have been optimised to the extent that most of them
can be executed from just one screen. The system allows several applications to be run
in different windows at the same time.
A wide range of statistical evaluations is provided to support users in their work.
Individual statistics can be compiled quickly and effectively with the software. Database
Page 41
Fare collection
systems
entries are rapidly and reliably determined and sorted by means of configurable filters.
The filters used are displayed by the system and can be edited by the user at any time.
Building on the base version, additional modules can be added to FareGo Data. Thanks
to the open program architecture, new technical software developments made by the
Fare Collection Systems division can be retrofitted at any time.
The FareGo Data base version contains all the modules needed to operate and
administer a modern fare collection system:
Module
Function groups
Administration
•
•
•
Program manager
Master data administration
Data archiving
Configuration
•
•
•
•
•
•
Device administration
Operating data management
Version administration
Release management
Basic tariff data management
Barcode tracking
Device monitoring
•
•
•
•
Communication with the field devices
Job Scheduler
Direct commands
Alarm management
Statistical evaluations
•
Standard reports
2.2.8.2 Operating concept of FareGo Data
All GUIs in FareGo Data follow the same principles with regard to design and operation:
•
The navigation bar at the top provides access to global functions at any time. It
can be individually configured by each user.
•
The information field on the left-hand side contains the sub-functions for the
respective module summarised into function groups.
•
The respective sub-function selected by the user is displayed in the main
window, this could concern tables or detailed data.
The figure below shows the main window of the GUI with the navigation bar at the top,
the information field at the side and the table shown in the main window.
Page 42
Fare collection
systems
Example of the FareGo Data GUI
FareGo Data is characterised by outstanding ergonomics, something recognisable from
the many detail solutions:
Parallel processing of different modules
FareGo Data allows different modules to be run in parallel. As many modules as
needed can be kept open, facilitating even major changes to be made quickly and
efficiently.
Support for multiple monitors
Windows can be undocked from the main window and positioned on other screens. All
screen settings are saved specific to the user.
Sensible arrangement of data
The main window with its arrangement of tables and detail data provides a rapid
overview of the input data.
Filter functions
Effective filter functions enable data to be processed quickly, even where large
inventories of data are concerned. All filters used are always displayed during searches.
Filtering by multiple criteria
Filters on different fields can arbitrarily be combined, selected, or deselected.
Simple search by references
Page 43
Fare collection
systems
References to other objects can be entered in almost all editing screens, e.g. a sales
device refers to a location, a device class or an operating data version. References can
be entered comfortably thanks to sophisticated filter mechanisms.
Direct reference entry (Quick Pick)
If reference numbers are known, entries can be made directly in text fields, FareGo
Data then automatically determines the matching entry.
Generating an ID proposal
During free input of ID numbers, the system immediately suggests the next free number
able to be used.
Cloning inputs
New inputs can be generated at many points from existing data records. Consistency
checks are made in this context, the result is marked in colour.
Grouping details in tabs
Detailed information is summarised into sensible groups and displayed as tabs.
Processing multiple data records
In case of multiple selection, the individual elements are offered one after the other for
processing.
Processing dates
Dates can be entered and changed with a configurable data format and corresponding
selection windows, a quick entry of the current time is possible in many places.
2.2.9
Administration
2.2.9.1 Program manager
All software functions are bundled and managed in the Scheidt & Bachmann program
manager and, depending on the access rights, can be executed from a workstation.
Apart from access via the start menu, individual functions can be added to the quickstart bar or modules opened when FareGo Data is started.
Page 44
Fare collection
systems
FareGo Data program manager
Active (logged in) users and the most important activities, such as the start of modules,
are logged in the database.
Page 45
Fare collection
systems
2.2.9.2 Master data administration
2.2.9.2.1
Management of user groups
FareGo Data assigns users to groups, to which execution rights are assigned. The
access rights of each group are configured by the system administrator and can be
extended or adapted at any time. Members of a user group therefore only ever see the
part of the system they require for their work. Deactivated functions are suppressed by
the system. The system does not permit unauthorised access to an area not defined for
the user group.
All users in the administrator group have all rights to the background system. The
"Workshop" user group is given access rights for field devices (e.g. to execute service
commands and PIN code) and has restricted rights for the background system, to
assess and rectify disturbances.
FareGo Data management of user groups
Page 46
Fare collection
systems
2.2.9.2.2
User management
A dedicated user account is set up in FareGo Data for each user of the system. The
personal data of the user can be stored, changed or blocked here. Each account
contains the user's name and password, plus the allocation to a user group. Not only
those working at the FareGo Data back office are regarded as users, but also service
technicians with access to the field devices.
FareGo Data user management
Page 47
Fare collection
systems
2.2.9.3 Audit Trail
FareGo Data records all user activity. Any change of data in the database,
configurations or alike can be found in the system’s audit trail. The following data
elements will be recorded:
•
Point in time, workstation and IP address
•
User
•
FareGo Data Module and performed activity
•
Success or failure of the activity
•
The executed SQL command
With these elements, FareGo Data implements requirements of modern IT standards
such as ISO 27001 or PCI DSS.
The Administrator may configure what is recorded and which users have access to the
recorded data. A comfortable GUI offers a 2-level-filter for many types of activities, e.g.
analysis of single events or search for critical activities.
The audit trail can be exported for the usage in other tools such as a central log server.
FareGo Data Audit Trail
2.2.9.4 Archiving data
In order to retain levels of performance for the database with regard to statistical
evaluations and reports, data inventories should be archived at regular intervals. The
Page 48
Fare collection
systems
process can be initiated automatically by the system or manually by the administrator.
The archiving parameters (archiving intervals and the periods to be archived) are freely
definable.
FareGo Data archiving manager
2.2.10
Configuration
2.2.10.1 Device administration
The device administration module in FareGo Data serves to set up and maintain the
device-specific master data. Software modules are available for organising and
maintaining the following functions:
•
Management of the network configuration
Management of the back office system includes assigning a network address and
other network parameters to each end device and server.
•
Management of the workplace computers
Management of a workstation includes assigning a network address and a name
and the link up to the Scheidt & Bachmann back office system.
Page 49
Fare collection
systems
•
Management of the classes and groups of devices
Device classes can be deployed in a versatile manner to enable differently
working devices to be grouped together. For example, a certain article could be
sold solely by devices belonging to one class, or a certain software version could
be allocated to a specific class. Reports can naturally also be filtered by device
classes.
Device groups fulfil a similar purpose, thus devices can be simply classified by
different criteria.
•
Management of devices (e.g. TCP/ IP address, PSI entity)
The management of devices includes assigning a device number, a network
address and allocation to a device class. If required, the assignment here can be
made to a line created beforehand or bank details can be declared for settlement
of the devices. The individual devices furthermore get linked to the applicable
tariff data.
•
Management of locations
The management of locations includes the definition of a location name, a
location number and assignment of sales devices to the locations.
Page 50
Fare collection
systems
FareGo Data maintenance of devices
2.2.10.2 Operating data management
Operating data are the parameters specific to sub-assemblies which are required for the
correct operation of field devices, for example settings for printers or card terminals.
FareGo Data includes management of the operating data required for each assembly
group, which are activated in dependence on the configuration of the field devices.
2.2.10.3 Version administration
Maintenance of versions on the sales device software is provided by the FareGo Data
"Configuration" module. This administers, composes and provides the software versions
to be transmitted to the sales devices. The software versions always belong to one of
the categories listed below:
Version category
Description
Operational data
Technical parameters of sales devices.
Page 51
Fare collection
systems
Version category
Description
Application software
Software generating the screens to operate the
machines and sell tickets.
Tariff data
Data to depict the tariff structures of tickets,
location tables, group tables, relational tables
and multimedia elements, such as printed texts,
display texts and speech outputs.
System software
Scheidt & Bachmann operating system
software, software to operate the device subassemblies, and driver software.
Print layout software
Layouts for tickets and receipts
Each category of versions can be specifically created and assigned to each device
class.
FareGo Data version administration
Page 52
Fare collection
systems
After a new version has been composed, this is summarised into a new release and
transmitted to the device class of the field devices controlled by time.
During the download, the end device declares which software versions it has currently
loaded. Subsequently, only those versions that are not already present on the devices
will be transmitted. The current versions of the sales devices are stored in a constantly
updated list and these can be polled in the form of a report.
2.2.10.4 Release Management
Release Management is performed independently by FareGo Data and serves to
monitor the versions transmitted to the end devices. A release describes a consistent
data record of versions of a device class containing all the main parameters for
operating the devices. The device class releases are summarised into an overall
release, a so-called initialization release. This release has its own identification number
and describes the state of the entire system over all device classes.
Master Release
Release Device Class I
Version Operating Data Software
Version Application Software
Version Tariff Software
Version System Software
Version Printlayout Software
Release Device Class II
Release Device Class III
Version Operating Data Software
Version Application Software
Version Tariff Software
Version System Software
Version Printlayout Software
FareGo Data release administration
The overall release for the system and the device class releases are automatically
generated by the compilation of version information. This process is also referred to as
"initialisation data generation".
A release status contains all the valid versions of the device classes. FareGo Data
automatically compares the release status in the devices with the desired release status
through a target-actual comparison. Missing versions are downloaded automatically by
the devices. The loaded release status has a unique number which can be polled from
the sales device by means of a service command.
Page 53
Fare collection
systems
2.2.10.5 Basic tariff data management
The basic tariff data management module depicts the sellable products with prices,
location tables and relations. Product prices can be changed here, new locations can be
entered and relations can be changed and added. Texts can also be stored in different
languages right through to speech outputs.
A period of validity can be declared for each product. This can be printed out upon issue
so that it can be recognised by the passenger. A product can be managed in such a
way that it can only be sold at a precisely defined time, e.g. only in the morning, only at
weekends, only during school holidays etc. It is also possible to restrict an article to
certain devices.
The tariff data are subject to version administration and have a period of validity.
Version administration allows several tariff versions to be bundled and distributed to the
end devices. New fare tariffs can be brought into the field in advance in this way and
subsequently activated in a coordinated manner.
Example of FareGo Data article maintenance
Page 54
Fare collection
systems
2.2.10.6 Barcode tracking
With barcode monitoring activated in the end devices, the paper deployed can be
managed by the Scheidt & Bachmann back office system. The following functions have
been implemented and are available to users:
•
Monitoring the barcode serial number on the back of the ticket. A "paper jump"
event is generated if a gap is recognised in the barcode serial numbers. This
could be caused by changing a roll of paper, by an error (such as a paper jam in
the printer) or by service personnel tearing off single tickets.
•
Recording the respective barcode number per stack at the start and end of the
shift.
•
Generating an event when a new roll of paper is loaded.
•
A lack of paper is reported by the end device to the background system. The
report is generated from the quantity of barcode numbers remaining, which can
be set in the system.
•
Evaluations in the background system. This report can be used to verify, for
example, whether all tickets on a roll of paper have been processed, or whether
half a paper roll was removed from a device and loaded into another device.
The barcode information from the end device is stored in the sales data as an additional
data element. Recording barcodes enables comprehensive, additional security and
monitoring action to be taken to prevent tickets being manipulated.
2.2.11
Device monitoring
2.2.11.1 Communication with the field devices
All transaction data generated by the field devices or the tariff and operating data
required by the field devices can be transmitted between the back office and the field
devices in an online or offline process.
Data transmissions between the back office and the field devices can be encrypted, if
required.
2.2.11.1.1
Online connection
Devices can be connected online through a LAN or via a GPRS/UMTS interface.
TCP/IP is used over all communication routes to address the communication partners.
Data exchange can be initiated by using the Scheduler, i.e. controlled by time. The
bandwidth required for communications between the field devices and FareGo Data
depends to a great extent on the functions implemented, e.g. non-cash payments or eTicketing. The capacity is calculated during the detailed design of the system, typical
values lie between a few 100 kbit/s and 10 Mbit/s per station.
Field devices derive the time from the background system in a uniform manner, a
synchronisation is made when data is uploaded.
Page 55
Fare collection
systems
2.2.11.1.2
Offline linkage
USB sticks are deployed as offline data carriers. This enables data to be exchanged
between devices and the Scheidt & Bachmann background system.
The data carriers can be used as a central, unique data module for all functions, such
as version update, disposing of transaction data and administering hot lists.
2.2.11.2 Job Scheduler
The exchange of data between the field devices and the back office is coordinated and
controlled using the job Scheduler function. The system automatically executes
scheduled data transmissions for the online devices at pre-set times. Unplanned data
transmissions can also be initiated by the administrator at any time.
The following tasks are performed by the schedule planner on a regular basis.
•
Collect data from the devices at set times
•
Transmit data to the devices at set times
•
Collect data from external applications / systems
•
Transmit data to external applications / systems
•
Execute commands to control devices
All upload and download functions in the system are controlled and administered by Job
Scheduler based on time. It can be configured whether a transaction is a one-off or a
repeating process (by time interval, e.g. always on Sunday at 23:30 hrs or every day).
FareGo Data Job Scheduler
Page 56
Fare collection
systems
Job Scheduler enables new jobs to be defined and transmitted to the system.
Furthermore, a control mechanism is implemented which enables the course and the
correct end of the job, or any errors which occurred during execution, to be monitored
and recorded.
An upload or a download can be ordered for single devices, device classes or groups of
device classes - separate from each other - through Job Scheduler.
Parameters which the system collects whilst executing a job can be viewed using the
history function in job administration. These parameters are execution status, start of
execution, last attempt at execution and the time that execution succeeded.
2.2.11.2.1
Download function
All software versions ready for transmission to end devices are downloaded in a
separate process. The timing of the start of the download process is controlled by Job
Scheduler. Devices declare which versions they have during the communication
between the central download process and the version review function in each device.
The only versions subsequently transmitted to the devices are those which they do not
already have. This procedure ensures that all devices have the same software and
operating data stati after a download cycle, and that transmissions are made efficiently
in the shortest time possible.
After each download, a list (kept by the system) of the software versions currently
downloaded to the sales devices is updated. The contents of the table are displayed in
the form of a report in the FareGo Data status monitor, or are printed out for further use,
and enable the status of the versions downloaded to the sales devices to be reviewed at
a glance.
2.2.11.2.2
Upload function
The same mechanisms used for the download function are also deployed for uploading
sales data and technical information.
All incoming data are entered into the central database run by the back office system,
from where they are available for further processing.
Data is checked for consistency during transmission. When the transmission fails, the
data record is deleted and the device requests that the data be transmitted again.
Page 57
Fare collection
systems
FareGo Data job history
2.2.11.3 Direct commands
Providing that the sales devices have an online connection (LAN or wireless) to FareGo
Data, various remote control commands can be sent to the devices from a screen
selection form. Depending on the type of device, a number of remote control commands
can be issued, such as:
•
Set end device to "ready for sales" / "out of service
•
Soft start an end device (reboot)
•
Activate / deactivate coin acceptance
•
Activate / deactivate individual coin values in coin acceptance
•
Activate / deactivate all banknote processing
•
Activate / deactivate individual note values in banknote acceptance (single bank
note denominations)
•
Activate / deactivate all credit / debit payments
•
Activate / deactivate individual payment methods in credit / debit payments
•
Manual status query to single field devices
•
Manually set the date and time at end devices
•
Status query
Page 58
Fare collection
systems
FareGo Data direct commands
All direct commands can be sent to individual end devices or as a collective job to
device groups, device classes, devices of a line or to all end devices.
2.2.11.4 Alarm management
Alarm management for field devices is configured in the master data management
module of the devices and can be controlled from there right down to single alarms. All
error messages from field devices connected online are recorded centrally by FareGo
Data.
Alarm management provides two modules for assessing faults and forwarding notice of
these.
2.2.11.4.1
Action in case of an alarm
Online alarms are sequentially recorded and displayed by the alarm management
module. The alarm messages received from field devices are categorised based on
configuration data for further processing and are then forwarded to staff on-call. The
figure below shows a listing of the alarm messages received.
Page 59
Fare collection
systems
FareGo Data alarm manager
2.2.11.4.2
Forwarding alarms
In general, FareGo Data offers the option of notifying certain events to the external
offices concerned (e.g. service technicians, police, etc.) via SMS or e-Mail. Therefore,
device groups and users can managed in FareGo Data’s "Alarm Processor Groups"
module. A prerequisite for this is that the client has an appropriately configured SMS or
e-Mail server.
In the course of user management, an allocation of time profiles and availability profiles
is administered, so that preset events can also be forwarded to those people on duty.
Time / date rules can be compiled for this purpose and allocated to profile groups. Work
rotas, shift work amongst service technicians or even those staff on-call can thus be
depicted.
Page 60
Fare collection
systems
FareGo Data screen form for editing alarm forwarding
2.2.12
Reporting
Sales devices from Scheidt & Bachmann document all sales transactions, technical
events and access data without exception in log files. This is referred to as transaction
recording. The elements of transaction recording form the data basis for all the
evaluations and reports available from the sales device and in the background.
FareGo Data provides wide-ranging statistics functions for authorised users to evaluate
transaction data. Statistics can be compiled automatically by the system as a routine at
scheduled times, or they can be generated individually by the user.
The figure below shows the screen form for statistical evaluations with the window for
selecting preconfigured filters.
Page 61
Fare collection
systems
FareGo Data statistical evaluation screen form
The following filters and sorting routines have been preinstalled to allow users to
generate individual statistics.
•
Filter by prescribed periods, such as day, month, quarter, year or shift, or by a
freely definable period by declaring the day and hour of the start and end date.
•
Filter by device classes, devices or shifts
•
Filter by predefined events (event codes)
The evaluations generated are depicted in tabular form and can be saved in a number
of different formats (doc, pdf, csv, xls…).
Page 62
Fare collection
systems
Example table for statistical evaluations
FareGo Data is supplied with a set of predefined, standard evaluations which cover the
majority of assessments required. Additional evaluations can be installed subsequently
at any time and adapted to the needs of the customer.
2.2.12.1 Standard evaluations
The following standard evaluations are contained in the FareGo Data basis package:
Sales statistics
Turnover global
Statistics on the total turnover of the system,
referred to the selected sales period.
Turnover by station
Statistics on the turnover of selected stations,
Turnover by device
Statistics on the turnover of selected devices,
Page 63
Fare collection
systems
Turnover by article
Statistics on the turnover of selected articles
including sales figures, referred to the selected
sales period.
Shift turnover by person
Statistics on the turnover of selected sellers.
Turnover by payment method
Turnover by cash / non-cash sales
Single sales
Detailed list of all sales
Event statistics
Event statistics
Statistics on all events referred to a device
class and the selected period.
Exchange vaults
Record of all changes of money boxes.
Operating log by person
Statistics on all events referred to a person.
Online status
Statistics on the online availability of field
devices.
Device components status
Statistics on the online availability of individual
components in the field devices with display of
the restrictions on the sales capability of the
device components.
Device version status
Statistics on the current software version of the
devices.
Upload statistics
Statistics on the proper transmission of shift
data to all field devices.
(missing main shifts)
2.2.13
FareGo Data add-ons
FareGo Data offers a series of add-on modules 1. These can be added-on individually to
extend the functions of the FareGo Data basis version:
1
•
FareGo Data Monitor+
Extended device monitoring
•
FareGo Data Tariff+
Extended fare tariff management
•
FareGo Data Archive+
Retention of archive data in a database
•
FareGo Data Paper+
Tracking rolls of paper
Further modules under development
Page 64
Fare collection
systems
•
FareGo Data Transfer+
2.2.14
Data export/import
FareGo Data Monitor+
FareGo Data Monitor+ provides the operator with a comprehensive overview of the
current operating state of the field devices and their sub-assemblies in real-time. Faults
can be analysed down to the device sub-assembly level, the linkage with other FareGo
Data modules enables any disturbances to be quickly rectified.
FareGo Data status monitor
The network segment under review can be selected from the information field at the
side of the main screen. Filtering by devices, device classes, device groups, lines and
stations is possible at any time. The field already contains a classification of the state of
the devices.
The main window shows detailed information on selected groups of devices, optionally
either in a graphic view with explanatory icons or in a diagrammatic sub-assembly view.
Coloured symbols in the views allow the user to "jump" down to the subordinate level,
e.g. from the line plan down to stations. Any disturbances can be quickly recognised
and diagnosed in this way.
Page 65
Fare collection
systems
FareGo Data status monitor – sub-assembly view.
The status monitor furthermore integrates online alarm messages, version status and
counter readings, so that a complete picture of the state of the system can be
generated. Direct commands and device management are called up directly without
complications. The status monitor is thus a central tool in the day-to-day running of the
system.
Page 66
Fare collection
systems
2.2.15
FareGo Data Tariff+
Whilst the FareGo Data Basis tariff data management module allows simple tasks to be
performed, such as amending prices or correcting relations, the FareGo Data Tariff+
add-on contains all the tools required to independently enter and manage new fare
tariffs, right through to changing a device's user interface and print layouts.
2.2.15.1 Editing print layouts
As a rule, articles are assigned to predefined print layouts. These determine the size
and other characteristics of the paper, as well as the graphics and texts to be printed
out plus their format. However, a dedicated layout can be assigned to each article, if
necessary.
Layouts are administered and edited via a GUI. Editing the print layout enables different
elements to be freely positioned and formatted within the extent allowed by the printer’s
capabilities. For example:
•
Fixed texts
•
Variable texts from the tariff data (e.g. date, price, zone, etc.)
•
Variable texts from the device configuration (e.g. device number)
•
Variable texts from the IBIS (e.g. line or route)
•
Graphics (e.g. constant bitmaps, variable bitmaps or lines)
•
Space reserved for barcodes
The aforesaid elements allow an individual presentation of various ticket layouts.
Layouts are specific to each device group, they are bundled per device group and
administered by version.
2.2.15.2 Screen layout editor
A screen editor has been integrated into the overall system in order to offer users the
greatest possible degree of freedom and convenience. This feature allows users to load
the sales screen forms of the sales devices into the editor and adapt them there.
Page 67
Fare collection
systems
FareGo Data screen editor – start screen
Changes – e.g. if a special ticket is launched – can be created with the screen editor
and stored with the appropriate attributes. So-called quick buttons, which draw on the
Windows functions, are integrated in the program to simplify the individual work steps
with the editor. In this way, an element can be quickly and simply copied and inserted.
The following changes to the application can be made simply with the help of the editor:
•
Change to the formatting/appearance of a message
•
Change to the formatting/appearance of a screen button
•
Change of background images
•
Render existing screen elements invisible
•
Make predefined screen elements visible that had previously been hidden
•
Add new tickets based on the the same business logic as existing tickets
•
Change the application parameters (limits, timeouts)
•
New assignment of existing print layouts to elements
Page 68
Fare collection
systems
FareGo Data screen editor – editing elements (1)
FareGo Data screen editor – editing elements (2)
Once the editing work has been completed, the screen editor offers the option of
inspecting the change to the application in a preview window.
Page 69
Fare collection
systems
FareGo Data screen editor – application preview
Applications are versioned and are downloaded to the sales devices together with
operating data and system software.
2.2.16
FareGo Data Archive+
An "Archiving and Disposal" tool is provided for backing-up and archiving data. This
tool, which is contained even in FareGo Data Basic, is tailored to the requirements and
offers the necessary flexibility for configuring specific periods of time. The system
exports the data in simple files to the place where they are to be archived or from where
they can be re-imported.
The FareGo Data Archive+ add-on transmits data to be archived to a separate database
server. The data remain available for evaluations there. This produces the following
benefits:
•
The FareGo Data database stays lean and healthy
•
FareGo Data. as a real-time system, is not loaded down by resource-gobbling
inquiries concerning historical data
With regard to archiving, a differentiation is made between dynamic and static data.
Static data are understood to be (sales device) configuration data, for example, whilst
dynamic data could be, say, sales transactions.
Page 70
Fare collection
systems
How archiving functions
Dynamic data are always context sensitive, they must therefore be assigned to static
data so that they can be interpreted. Only those field devices which are managed by the
system can generate transaction data (sales data). When the archiving and disposal
function is executed, the data to be archived (e.g. transaction data, event and alarm
data) are moved to a separate archive database. Moreover, the archived data can be
written as Oracle export files for the purpose of data back-ups. The Oracle export files
contain both the static and the dynamic data. Once the archiving and disposal function
has been launched, the application checks whether the static data are still up-to-date
since the last time the function was executed. If this is not the case, all static data are
copied to the archive database. Once the static data have been archived, the dynamic
data are then archived.
In other words, the archive database is a place off the beaten track to store transaction
data, whilst these can still be drawn on for evaluations in the same way as those in the
current database.
FareGo Data Archive+ requires a separate database server including the necessary
operating system and database licenses.
Page 71
Fare collection
systems
2.2.17
FareGo Data Paper+
The FareGo Data Paper+ option adds a comprehensive paper roll management tool to
the functionality of the FareGo Data system. It is not included in this proposal but is an
available option.
The tool depicts the complete life cycle of the paper used for ticketing, from delivery to
issue through to the destruction of residual rolls.
The paper sort, the first roll number and the number of rolls are recorded when paper is
delivered to the stores. The system allocates a unique delivery number to the delivery.
The background system independently breaks down deliveries of paper into rolls. Each
roll is subsequently described and identified in the system by its first barcode number
and barcode quantity.
Preparing an issue delivery note
In principle, rolls are identified and allocated to a delivery/person using their first
barcode number in order to generate a paper delivery note upon hand-out. A planned
recipient and a target destination can be entered when the delivery note is being
prepared. The delivery notes are printed out and are countersigned by the recipient
upon handover. A return delivery note is generated in the background system for
returns, which credits the rolls allocated to the person. Other changes of status, such as
the insertion and removal of rolls in end devices or the destruction of rolls or roll
residues, are likewise supported by the tool. Only certain changes of state are allowed
here, e.g. a roll that has not been issued cannot be loaded into a device.
Page 72
Fare collection
systems
2.2.18
FareGo Data Transfer+
As a rule, FareGo Data installations are tied into an existing IT infrastructure. This
requires an exchange of data with other software packages in both directions, i.e. data
need to be imported as well as exported.
FareGo Data contains a framework for administering import/export processes, on which
any adapter can be hooked in. In principle, many exports and all imports can be
adapted on request to take local circumstances into account , even if integration can be
simplified in many places by standard modules.
The license of FareGo Data Transfer+ includes the import/export framework plus one of
the agvailable adapters. Necessary efforts to adapt an import or export module depend
on the magnitude of changes and will be separately specified and offered.
2.2.18.1 Export interfaces
Time controlled functions predominate for exports. As a rule, data are exported on a
daily or weekly basis. Sales data or events are likely candidates for export.
A cyclic job is set up in FareGo Data to generate an export. Exports generated in this
way are then available, depending on the settings, e.g. as files. All exports executed
can be inspected in the revision history.
The following are available as standard modules, although customer-specific
adaptations can be made on request:
Export
Data types
Adaptable?
Generic XML export
Sales data
No
Generic ASCII export
Sales data
No
Other
Sales data or events
Mandatory
2.2.18.2 Import interfaces
Importing data / information on fare tariffs is common practice in numerous projects in
order to use existing information and structures. For this purpose, the Scheidt &
Bachmann back office provides a framework under Transfer+ to import external data.
This usually concerns release lists, blockage lists or fare tariff data.
Imported data on fare tariffs (articles, relations, tariff zones etc.) are versioned and can
be subsequently edited. After import and subsequent editing in the Scheidt & Bachmann
back office system, they are available for download to the field devices.
As imports are customer-specific to a great degree, they are specified and ordered
separately.
Page 73
Fare collection
systems
Import
Data types
Adaptable?
Any
Varies, mostly tariff data
Mandatory
Import structures need to be agreed in the form of a detailed specification so that any
adaptations to existing import structures that are required can be made.
Example of a FareGo Data import form
2.3
Quality & Testing
At Scheidt & Bachmann we believe that quality is an essential part of providing excellent
products to meet and exceed our customers’ requirements, and to support that
necessity we have dedicated ourselves to develop and refine our Quality Assurance
Processes.
Quality assurance process
The Scheidt & Bachmann Quality Management System established the processes used
to deliver products and servers per the customers’ requirements. It is applicable to
design, manufacture, sales and servicing activities. Scheidt & Bachmann is certified
according to ISO 9001:2000 by Lloyd’s Register Quality Assurance. Our first
certification was achieved in February 1993.
At Scheidt & Bachmann, we emphasize that quality is a joint task for the entire company
and all concerned parties, requiring the continuous commitment and cooperation of
Page 74
Fare collection
systems
every employee, beyond the limits of divisions and functions. We achieve total quality
by consistently eliminating sources of faults, in all functional areas during the processing
of an order, from the point of marketing, to the installation, and use of our systems.
We entrust all managers with the execution of Quality Tasks. They have total
responsibility for establishing, maintaining, and monitoring the Quality Assurance
System as applied to their area of responsibility and meeting ISO 9001:2000 Standards.
Our efforts are to exceed, at all levels, the standards set to ISO 9001:2000 and offer our
customers the best product and services in the industry. It is our continuous
commitment to safe-guard and strengthen the reputation and success of our company.
The Quality Assurance Department of Scheidt & Bachmann represents a central
function within the organization of the Scheidt & Bachmann Group. The head of Quality
Assurance is responsible for all quality issues within the company with principal duties
as follows:
•
•
•
•
•
•
Support of the organization of QM systems
Central coordination of the documentation
Recording and assessment of all evaluations of the quality management systems
of subsidiaries that are affiliated with the QM system
Supervision of internal audits in the subsidiaries
Execution of audits
Forcing of the development of the QM system
The Quality Assurance Department is a separate organization from the departments
responsible for the design and delivery of products and services. However, Quality
Assurance personnel are critical members of the project team as they collaborate with
the Project Manager in developing and executing the test program to verify that the
products and services meet the design specifications agreed to with the customer.
Design and Development Planning
Any design and development activity is documented by describing the activities and
associated responsibilities. These are updated as the design progress progresses.
Included in these plans are the steps to check the development phases (evaluation,
verification, validation).
Individual product-related requirements are established and documented as design
specifications. The completed design is results in manufacturing instruction and
drawings, a functional specification, a performance specification, or similar and
distributed to appropriate departments and groups for information and action.
Design and Development Verification
The finished product is verified according to the requirements of the development plan.
Qualified personnel appointed by the design department or other departments as
needed do the validation testing. Under certain circumstances, design verification may
also include a comparison with approved similar design. Prior to the delivery of the
product, its development is subject to validation. As a rule, design validation is
Page 75
Fare collection
systems
accomplished by field testing. Field tests are performed in agreement between the
design department and sales divisions. Depending on the type of project, there will be
"Factory Acceptance Tests" with or without contribution of the customer.
Hardware Quality Assurance
Hardware Design is first evaluated by the development department against the contract
requirements. The Quality Assurance Department performs this verification:
The quality laboratory, a part of the Scheidt & Bachmann Quality Assurance
Department, is also responsible for the planning and the execution of First Article
Testing (FAT). The procedure for FAT consists of the following steps:
•
•
•
•
•
Formulating test objectives and requirements
Test planning for device prototypes and or design proof of concept prototypes by
the quality laboratory
Preparation for testing by the quality laboratory
Execution of testing by the quality laboratory
Test Evaluation and documentation by the quality laboratory
Test Planning for Manufacturing
The test plan for manufacturing fulfills the job of "converting" established quality test
data into a comprehensive and universal, practical and binding test procedure for all
employees involved in the operation of quality testing.
The department of Quality and Test Planning, a part of the Scheidt &Bachmann Quality
Assurance Department, takes responsibility for the introduction and maintenance of the
test plans for manufacturing. The test plans are documented in the S&B MRP System.
Each test plan describes:
•
•
•
•
•
Necessity of testing
Testing procedure
Frequency of testing
Test characteristics, Method of testing
Testing equipment
Only plans which are released by the Quality Assurance test planners are available to
production. In the case of technical changes, the release code is automatically changed
by the MRP System and the plans are locked for manufacturing, which effectively
places a hold on manufacturing until the item is released.
Configuration Management & Change Control
The platform for configuration management and change control of hardware elements
during design and manufacturing is the Scheidt &Bachmann MRP System. The Scheidt
&Bachmann part number identifies all hardware items from the very highest product
level, e.g. Ticket Vending Machine, down to the lowest level piece part, e.g. screws, and
Page 76
Fare collection
systems
includes a technical index for change control. Any technical modification of a part will
result in a change to the technical index. All drawings are named by part numbers in the
same manner.
The bill of material lists the hierarchical structure each for each product. In the case of a
technical change to any component, the manufacturing plan and all existing
manufacturing orders are automatically locked. Authorized persons of the productionplanning department establish the actions required based on the MRP-documentation
before operations can resume.
The configuration of a manufactured product is documented by association of serial
numbers. The serial number is the important reference between part number and its
technical index.
Software Quality Assurance Program
Scheidt & Bachmann’s Software Quality Assurance activities follow the guidance outlined by IEEE Standard 730-1998 illustrated in Error! Reference source not found..
Most of the Scheidt & Bachmann software processes are ‘standard’ applications that
are developed as part of the ‘CORE’ software modules. Based on system design, it is
not required to change any of these ‘CORE’ processes in order to comply and add
functionalities to the system (customization). These processes are documented as
described within this section. The documentation of All ‘outer’-layer processes and all
‘NEW’ processes, which are modified/added to comply with the customer specific
requirements, are updated accordingly.
Page 77
Fare collection
systems
Overview Software Quality Assurance Plan
Page 78
Fare collection
systems
2.3.1
Test Methodology
Scheidt & Bachmann will provide a high level test program plan which names all tests,
the test sequence, and the dependencies of the tests and the relevant parameters of
each test.
We incorporated dedicated steps for the City of Fort Collins to verify the Final Design of
the system at various milestones of the project:
•
DR – Design Review
•
FAT – Factory Acceptance Test
•
IAT – Installation Acceptance Test
•
RMAT – Reliability, Maintainability and Accuracy Test
S&B will perform internal inspections and testing. This approach represents our
standard methodology which incorporates the use of exiting test plans and procedures.
The installation of any equipment is based on a release for delivery resulting from the
successful completion of the Production Acceptance Test (to be carried out by Scheidt
& Bachmann QA department). The Production Acceptance Test and the Installation
Acceptance Tests are performed per a group of devices.
The RMAT will be performed after an accepted installation. System Acceptance will
occur when all requirements of the RMAT are fulfilled, 30 days after start of Revenue
Service or 120 days after the installation of field devices, whichever comes first.
Design Reviews (DRs)
Test Title
Design Reviews
Equipment under Test
All
Documents needed
Design and conformance requirements
Time of Test
After NTP
Test Purpose
Evaluate the adequacy and specification compliance of
FCS design.
Pass / Fail Criteria
Compliance with specifications in the contract.
Remarks
none
First Article Test (FAT)
Test Title
Factory Acceptance Test (FAT)
FareGo Data System (downsized test hardware)
Ticket Vending Machine
Documents needed
High Level Test Plan
Detailed, comprehensive Test Procedures for all devices
Test Report
Time of Test
After Final Design Review
Page 79
Fare collection
systems
Test Purpose
Demonstrate system and equipment functionality.
Open issues will be prioritized and classified according to
an error level scheme. Relevant issues to be corrected
prior to approval.
Remarks
Due the high level of similarity to existing equipment
deployed in equivalent or harsher environments and prior
environmental testing, FAT will not include environmental
tests.
The FAT will be carried out at Scheidt & Bachmann’s Burlington facility which has a fully
equipped First Article Test area where the City of Fort Collins system will be set up,
configured and tested prior to delivery.
Production Acceptance Test (PAT)
Test Title
Production Acceptance Test (PAT)
Farebox
Validator
Ticket Vending Machine
Page 80
Fare collection
systems
Documents needed
Test procedure / test protocols for all devices
Test Location
S&B Inc. Burlington
Time of Test
after FAT approval
Test Purpose
Verify that each subsequent production unit meets
requirements according to production test procedures.
Test according to test procedures
Remarks
The continuous production acceptance tests are performed
by S&B.
Installation Acceptance Test (IAT)
Test Title
Installation Acceptance Test (IAT)
Each installed unit
Documents needed
Installation Test Procedures for each device
Test Location
On-site at City of Fort Collins location
Time of Test
After installation, prior to public operation.
Test Purpose
Mutual test that unit is properly installed and works correctly
including communication interface.
Installation, Function and Communication as requested in
the test procedures.
Remarks
Tests are performed unit by unit.
Reliability, Maintainability and Accuracy Test (RMAT)
Test Title
Reliability, Maintainability and Accuracy Test (RMAT)
All equipment
Documents needed
High Level Test Plan including FRB procedures
RMAT test procedure
Shared Error Database
Incident Tracking Database
Reliability Tracking Documentation
Cooperation of Authority Perform test together with S&B
Join weekly RMAT meeting
Perform Service Event Audits
Provide final acceptance when RMAT is completed
Test Location
On-site at City of Fort Collins location
Time of Test
After installation and start of revenue service
Page 81
Fare collection
systems
Test Purpose
Final System Acceptance.
For the Final System Acceptance, the RMAT will verify that
the equipment meets the reliability, system accuracy and
maintainability requirements when in operational use.
Reliability, System Accuracy and Maintainability
Requirements
Remarks
The RMAT is a 30 day test following a 14 day settling
period.
2.3.2
Test Plan and Procedure
Scheidt & Bachmann will create test plans and provide them to the City of Fort Collins
for approval at the Initial Design Review. The test plans will include all applicable
procedures that govern the conduct of activity, surveillance, direction and methods of
observing and recording the pertinent data. Each plan will include:
•
•
•
•
•
•
•
•
•
•
•
•
Objective and schedule of test
Test environment conditions
Description of documents & technical publications
Detailed procedure of test
Test equipment to be used
Level and schedule of preventive maintenance required during test
Spares and consumables required
Pass / Fail criteria
Retest procedure
Test data sheet format
Test notification to applicable City of Fort Collins and S&B representatives
Test Reports
Test results for all tests conducted will be submitted to VIA for approval within (10)
ten days of test completion. S&B will keep the City of Fort Collins updated on test
schedule and allow for observation.
2.4
Installation
Scheidt & Bachmann has years of experience installing our devices for agencies both
large and small. Scheidt & Bachmann will provide a forecasted Installation Plan to the
City of Fort Collins at design review. A detailed installation plan will be made available
as the installation date draws near and timing of activities is mutually agreed to between
S&B and the City of Fort Collins.
During installation, S&B will provide storage and work facilities except those specifically
provided by the City of Fort Collins for the purpose. The City of Fort Collins will provide
space for S&B trailers or storage containers if needed to meet S&B’s installation efforts.
Page 82
Fare collection
systems
2.4.1
City of Fort Collins Requirements
The City of Fort Collins will facilitate the installation process by supplying Scheidt &
Bachmann identified support as follows:
•
•
•
•
Sufficient space to support the installation
Sufficient access to vehicles and facilities to support the agreed upon installation
schedule
Test and inspection personnel
Traffic control during the installation process
2.4.2
Installation Rate
The installation of the TVMs will take place over the course of 4 weeks. To achieve that
timeline, multiple teams of technicians will be used. S&B will work with the City of Fort
Collins to ensure that regular revenue service is not disrupted during the installation.
2.5
Training
Scheidt & Bachmann will provide a training program to educate and teach personnel in
all details of the TVMs and FareGo Data system to enable them to operate, service and
maintain the equipment. Classroom sizes will be organized so each trainee will have
one-on-one training with the hardware and software.
The training program will include training for administration, operations, maintenance
and IT functions. Both formal and informal instruction, models, manuals, diagrams and
component catalogs will be utilized.
Scheidt & Bachmann will perform the training at the City of Fort Collins’ facilities. When
possible, actual equipment provided to the City of Fort Collins shall be utilized in training
to offer trainees real world, hands-on experience. Any devices used in training will be
fully tested at the completion of training to ensure they are in proper working order.
The trainer from Scheidt & Bachmann will explain step-by-step the different procedures
for operating and maintaining the system. Comprehensive overview drawings and
operational manuals will be used during training sessions. Each student will be required
to perform actual "hands-on" procedures. Scheidt & Bachmann will utilize the technical
information directly from the manuals.
Successful completion of a written quiz and a hands-on demonstration of all elements of
the lesson will be required from each student. Each student will receive a training
certification for the attended training session.
In general, all Scheidt & Bachmann Instructors will have the following skills:
•
•
•
•
•
Good English language communications skills
Well versed in object oriented instruction
Good electrical/electronic and mechanical background.
Solid software skills and familiarity with Fare Collection Systems software
Extensive field experience with Fare Collection Systems
Page 83
Fare collection
systems
2.6
Warranty
Subject to final negotiation, Scheidt & Bachmann is proposing the following standard
warranty. The warranty will begin on the installation of the first device, and end 12
months following System Acceptance.
Scheidt & Bachmann warrants as follows:
(a)
under normal use and service, the fare collection hardware equipment to be
provided by Scheidt & Bachmann under the Contract (collectively the “Equipment”), will
be free from physical defects in material and workmanship at the time delivered and
subject to normal wear and tear and replacement cycles thereafter.
(b)
Under normal use and service, software developed by Scheidt & Bachmann and
to be provided by Scheidt & Bachmann under the Contract (collectively the “Software”)
will perform substantially in compliance with the agreed written specifications (excluding
"bugs" or minor discrepancies, inconsistencies, brief interruptions, and other flaws that
do not materially impact performance of the intended functions).
Scheidt & Bachmann will remedy Defects in Equipment and Software in accordance
with the warranty procedures set out herein. A ‘Defect’ will be defined as a material
deviation of the Equipment or Software from the warranties defined above, provided that
the relevant Defect is reproducible on Scheidt & Bachmann’s test system.
Exclusions
Scheidt & Bachmann’s obligation to remedy Defects will be excluded if:
(a)
A Defect is the result of normal wear and tear, vandalism, misuse, operator error,
unauthorized modifications, improper use, improper maintenance, negligent acts or
omissions of the Customer or Force Majeure Events;
(b)
A Defect caused by design, material, software or interfaces provided by
Employer.
Consumables and wear parts that have reached their normal lifetime are not covered by
the warranties. Further, Defects caused by consumables and wear parts will not be
considered for the calculation of agreed reliability measures.
The Customer is obliged to protect data in compliance with manuals provided by
Scheidt & Bachmann and to take appropriate data security measures and protective
measures against viruses and other external influences. Scheidt & Bachmann will not
be responsible for the reproduction of lost data.
Warranty Period
The warranty period for all Equipment and Software will end 12 months from System
Acceptance.
At the end of the warranty period as defined herein, the warranty expires for all
Equipment, Software and exchange / spare parts.
Page 84
Fare collection
systems
Warranty Procedures
The Customer’s warranty rights require that it inspects the delivered goods upon receipt
and notifies Scheidt & Bachmann promptly in writing, but not later than one week after
receipt, of any obvious Defect. Further, Scheidt & Bachmann must be notified of any
hidden/latent Defects immediately, but latest within five (5) days upon discovery. It is a
condition that the Defect, or the cause of the Defect, must be demonstrated to have
existed at the date of transfer of risk.
The Customer may submit a warranty claim to Scheidt & Bachmann for any
Equipment/Software that suffers a Defect. A warranty claim must include a description
of the Defect and the problem experienced and must be made within five (5) business
days from the detection of such Defect. If, based on Scheidt & Bachmann’s workbench
analysis, Scheidt & Bachmann determines the Customer’s warranty claim is not covered
under this warranty, Scheidt & Bachmann will notify the Customer in writing. Scheidt &
Bachmann’s notification will list each item in the Customer’s warranty claim that it
believes is not covered by this warranty and will include a written analysis of its reason
for denying the Customer’s warranty claim.
Defective Equipment returned to the designated Scheidt & Bachmann’s repair center
will be repaired or replaced, at Scheidt & Bachmann’s sole discretion, in less than 30
days from receipt of the defective material. Where the repair or replacement will take
more than 30 days, Scheidt & Bachmann is allowed to provide a provisional solution
until repair/replacement of the defective Equipment is finalized. Scheidt & Bachmann
may use spare parts that are purchased by the Customer to replace a failed or defective
part. The Customer will maintain an adequate inventory of operational spares (based
on Scheidt & Bachmann’s recommendation) which are necessary to maintain the
Equipment during the warranty period. The responsibility of Scheidt & Bachmann is
limited to the cost of the defective part.
Unless otherwise agreed in writing, Scheidt & Bachmann’s warranty obligations do not
include preventive maintenance or on-site services and Scheidt & Bachmann will not be
responsible for any on-site costs associated with the repair or replacement of any
defective components.
In the event of a Defect in Software or design, Scheidt & Bachmann will present to the
Customer a plan to resolve the Defect within a timely manner, including reasonable
timelines for correction.
Any shipping charges accruing in connection with defective/repaired parts will be borne
by the Customer for shipping to Scheidt & Bachmann’s repair facility and by Scheidt &
Bachmann for shipping to the Customer's premises. Repaired parts will be delivered to
a location designated by the Customer.
Third Party Components / Third Party Software
The warranties for third party components / third party software (e.g. Microsoft, Oracle)
embedded in Scheidt & Bachmann’s fare collection products are subject to the warranty
and license conditions of the respective third party.
Page 85
Fare collection
systems
With respect to commercially available standard software, the Customer acknowledges
and agrees that due to third party license conditions, Scheidt & Bachmann cannot
remedy defects in such third party software in any event.
Warranty Period Maintenance:
Warranty Period, Maintenance and Service will be structured as follows:
•
•
•
Preventative Maintenance (cleaning, field adjustments)
Level I: Trouble shooting, field repair, remove and replace defective parts,
returning the Fare collection System equipment to service
Level II: Shop repair, PCB and component level repair, module adjustments.
The following scope will be included in our proposal:
Warranty:
•
•
•
•
•
•
The Warranty period will be 1 year after acceptance
The City of Fort Collins has to buy spare parts according to recommended spare
part list
Scheidt & Bachmann to perform level I preventive maintenance
The City of Fort Collins to perform remedial maintenance during the Warranty
period with support of Scheidt & Bachmann’s on site or remote personnel
according to S&B maintenance instructions
Software maintenance will start with the start of the warranty.
Scheidt & Bachmann to perform level II maintenance workshop repair
Service:
•
•
•
•
•
•
•
Up to Year 5 proposed. Continued service past that time may be negotiated.
The City of Fort Collins buying spare parts and repair according to spare part list
and will perform level I maintenance
Scheidt & Bachmann to perform preventive maintenance
The City of Fort Collins to perform remedial maintenance, according to S&B
maintenance instructions
Scheidt & Bachmann will supply software maintenance for critical errors of the
Scheidt & Bachmann software to maintain the operation, capability and
performance level of the fare collection system in place at the time of Fare
Collection System acceptance. Discretionary software upgrades improving the
operation, capability and performance of the Fare Collection System beyond the
levels in place at that time of system acceptance are not included.
Scheidt & Bachmann will supply one software release every 2 years.
Upgrades and 3rd party software verification according to change order
procedures. The status of customized tables and fields, upgrade release (remote
Page 86
Fare collection
systems
•
or on-site) will be defined in the Change Order. Technical and end-user training
will depend on complexity of upgrade.
Help desk support for the system will be available in the Burlington service centre
Other services are available on subject to negotiations.
2.7
Electronic Deliverables Spreadsheet Appendix A
Page 87
Appendix A Cost Summary Sheet
Table 1 – TVM Software, Project Management, Maintenance and Support Costs
MCS Software
Product:
Site License (Unlimited
Number of Users
Users, Employees)
Assume these values
License Costs:
-----------------------20
$
68,950.00
MCS Software and Support
Project Management Costs
Support Costs
$
$
89,730.00
53,440.00
$
55,340.00
$
$
$
$
$
41,880.00
59,830.00
59,830.00
59,830.00
59,830.00
Year 2
Year 3
Year 4
Year 5
Warranty
Project Management Costs
Support Costs
Year 2
Year 3
Year 4
Year 5
Number of TVMs
Optional TVMs
21
15
Table 2 – TVM Equipment, Warranty and Maintenance
TVM
Quantity
(21 each)
Cost/unit
Manufacturer
Installation
21
$
39,890.00 $
Preventive Maintenance
21
21
5,200.00 $
1,060.00
$
$
$
$
1,060.00
1,060.00
1,060.00
1,060.00
Grand Total
Optional units:
Quantity 15
each
$ 837,690.00 $ 109,200.00 $
111,300.00
Cost/unit
$
Extended
Support Costs
Year 2
Year 3
Year 4
Year 5
Extended
Escalator Index
(per year)
15
39,890.00 $
PPI
15
15
5,200.00 $
PPI
1,060.00
PPI
On-Site Maintenance (Two Business Days)
Table 3 – Training and Implementation
TVM
Quantity
Costs
Manufacturer
1
$ 14,500.00
Support Costs
$ 43,940.00
Year 2
Year 3
Year 4
Year 5
Grand Total
$ 58,440.00
Installation Preventive Maintenance
On-Site Maintenance (Two Business Days)
Table 4 – Spare Parts
The Contractor will provide a list of recommended spare parts and pricing for purchase to remain on site for critical repairs.
Part Description
Bill Note Acceptor
Card Magazine w/ Lock
Aux. Coin Magazine $0.05
Coin Magazine $0.05
Coin Magazine $0.10
Coin Magazine $0.25
Coin Magazine $1.00
Coin Acceptor
Coin Divertor
Coin Verifier
SBC-1
Credit / Debit Card Reader
PIN Pad
Power Connection Box
Power Pack
MKV Ticket Printer
LCD 15" Touchscreen
Coin Vault
Bill Vault
Associated System
TVM - Bill System
TVM - Card Dispenser
TVM - Coin System
TVM - Coin System
TVM - Coin System
TVM - Coin System
TVM - Coin System
TVM - Coin System
TVM - Coin System
TVM - Coin System
TVM - Coin System
TVM - Coin System
TVM - Computer
TVM - Credit / Debit System
TVM - Credit / Debit System
TVM - Power
TVM - Power
TVM - Ticketing System
TVM - Touchscreen
TVM - Vault
TVM - Vault
Price (ea)
7,840.00
1,696.80
1,439.60
1,439.60
1,439.60
985.60
985.60
985.60
985.60
2,054.40
2,582.60
370.20
6,335.80
1,890.30
737.90
2,209.30
2,203.00
7,908.50
1,660.30
1,498.40
1,734.60
Recommended Qty
2
10
5
5
5
5
5
5
5
2
2
2
2
2
2
1
2
2
2
5
5
Fare collection
systems
2.8
Electronic Deliverables Spreadsheet Appendix B
Page 88
APPENDIX B – Proposed System Summary
Table 5 Submittal Checklist – Please provide responses in all “Unshaded” spaces
provided. Only provide responses for exceptions if proposal does not comply.
Section
Number
2.6
2.6.1
2.6.2
2.6.3
3
Section Header
TVM Project
Scope
Delivery
Schedule
Installation
Standards
TVM Functional
requirements
CDRL
Provided
(Y/N)
Information
Provided
(Y/N)
Complies (Y/N)
Y
Y
Y
Y
Y
Y
Y
Y
3.0.1
Implementation
Y
Y
3.0.2
3.0.3
3.0.4
TVM Description
Media
Media Design
Y
Y
Y
Y
Y
Y
3.0.5
Ticket
Stock/Magnetic
Fare Card Option
N
N
3.0.6
Electronic Fare
Media Option
N
N
3.0.7
Electronic Smart
Cards Option
Y
Y
Y
Y
Y
Y
Y
Y
3.0.8
3.0.9
3.0.10
Fare Set
Configuration
Fare Set
Download and
Deployment
Data Access to
TVMs
3.0.11
Cash Acceptance
Y
Y
3.0.12
Cash Dispensing
Y
Y
3.0.13
Cash Return
Y
Y
With Exceptions (Describe if
applicable)
Fully compliant with the
exception of part of 3.6.12.
At the time of power loss,
the UPS will provide power
but only to complete
transactions and perform a
safe shut down.
3.0.14
3.0.15
3.0.16
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
Ticket Issuance
Data Storage and
Retrieval
Alarms
TVM Credit Card
Transactions
Credit Cards
Accepted
PCI DSS
Compliance
Real Time
Processing
Cancellation Prior
to Sale
Customer
Interface
Requirements
Design
Back-lighting
Glare
User Interface
Interface
Selection
Information
Display
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
3.2.7
User Instructions
Y
Y
3.2.8
Selection Buttons
Y
Y
3.2.9
User Interface
ADA Compliance
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
N
Y
Y
Y
Y
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.4
3.4.1
3.4.2
3.4.3
TVM Security
Access Control
Design Security
Interior Access
Cash Vaults
Intrusion Alarms
Mounting
Installation
TVM Installation
Design Space
Ethernet
Connection and
Electrical Power
3.4.4
3.5
3.5.1
3.5.2
3.5.3
3.5.4
Installation
Responsibilities
Training and
Documentation
City Furnished
Training Related
Items
Use of Actual
Equipment as
Training Aids
Training Program
Plan
Description
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
3.5.5
Training Delivery
Schedule
Y
Y
3.5.6
Contractor's
Training
Experience
Y
Y
3.5.7
Training Courses
Y
Y
3.5.8
Training Materials
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
3.5.9
3.5.10
3.5.11
3.5.13
3.5.14
3.5.15
3.5.16
3.5.17
3.5.18
System
Administrator
Manuals
Operating
Instruction
Manual
Maintenance
Manual
Revenue
Servicing
Field
Maintenance and
Servicing
Revenue and
Maintenance
Workstation
Operations
Shop Repair
Administrative
Workstation
Operations
TVM Accounting
and Registration
Information
Compliant with all points
except for traffic control.
3.6
3.6.1
3.6.2
3.6.3
3.6.4
3.6.5
3.6.6
3.6.7
3.6.8
3.6.9
3.6.10
3.6.11
3.6.12
3.6.13
3.6.14
Technical
Requirements
Technical
Overview
Technical
Information
Data Information
and Ownership
Y
Database
Information
Operating
Conditions
Outdoor
Exposure
Design
Compliance
Design Life
Power Supply
Source Power
UL Standards
and Code
Compliance
UPS and Back
Up
Main Power
Switch
MCS Software
3.6.15
Software
Requirements
3.6.16
3.6.17
3.6.18
3.6.19
Licensing Model
Anti-Virus
Security
Upgrade Tools
N
Y
Y
Y
Y
Y
Y
Y
Y
Fully complient with the
exception of ODBC access.
Y
Y
exception that max temp
for TVM while operating is
149 F and max humidity at
90% RH @ 104 F.
Y
Y
Y
Y
N
N
N
Y
Y
Y
N
Y
Y
Y
N
Y
Y
Y
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
exception of part of 3.6.12.
At the time of power loss,
the UPS will provide power
but only to complete
transactions and perform a
safe shut down.
Per RFP, CDRLs to be
provided during Design
Review phase.
3.6.20
3.7
3.7.1
Maintenance and
Support
Project
Management
Contract
Management
Y
Y
Y
Y
3.7.2
Project
Management
Plan
N
N
Y
3.7.3
Progress
Reviews,
Schedules and
Project Control
Y
Y
Y
3.7.4
Weekly
Conference Calls
Y
Y
3.7.5
Monthly Progress
Status Updates
Y
Y
Y
Y
Y
Y
3.7.6
3.7.7
3.7.7.1
3.7.7.2
3.7.7.3
Y
Initial Activities
Meeting
Design and
Configuration
Control
Design Principles
and Reviews
Preliminary
Design Review
Final Design
Review
N
N
N
N
Per RFP, Project
Management Plan to be
submitted within 30 days
after NTP.
Y
Per RFP, CDRL to be
provided prior to Primary
Design Review. CDRL can
not be completed until final
scope is defined.
Y
Per RFP, CDRL to be
provided prior to Primary
Design Review. CDRL can
not be completed until final
scope is defined.
Fare collection
systems
2.9
Buy America Certificate
Page 89
Fare collection
systems
2.10
Lobbying Certificate
Page 90
Fare collection
systems
3
3.1
Qualifications and Experience
MBTA (Boston)
Scheidt & Bachmann USA’s MBTA Boston project provided a system wide Automated
Fare Collection System to serve the greater Boston metropolitan area. The project
scope included the following main areas: Fare Vending Machines, Fare Boxes, Fare
Media Validating Equipment, Gates, Station Information Centers, Outlet Sales,
Handheld Card Reader, High Speed Encoding Machines (magnetic), Smart Card
Initialization Machines, Photo ID Equipment and a Central Support System. This recent
Boston project complemented by our project for the City of Phoenix contained all the
fare collection elements currently requested by TARC.
Project Information - MBTA Boston
Customer Contact:
Massachusetts Bay Transportation Authority
Ten Park Plaza
Boston, MA 02116-3974
Project Manager:
Mr. Robert Creedon
Telephone:
+1 (617) 222-3254
Equipment
Administrative Level
Redundant Central-Database Server
High Speed Ticket Production Units
High Speed Smart Card Production Units
Retail Sales Terminals for global ticket selling
Bus-System
1600 Fareboxes - including all money handling equipment
Subway / Rail-System
600 Fare Vending Machines (Full Service, Cashless, Validators)
50 Ticket Office Machines
650 Fare Gates
Project Volume
Currently $85,000,000.
Contractual Status of Scheidt & Bachmann USA, Inc
Page 91
Fare collection
systems
Prime Contractor
Project Description
The MBTA Boston Project represents a complete integrated Automated Fare collection
System for the Boston area. This includes the Bus-System and the Subway-System.
Based on the same fare media (Ticket, card) & tariff system it is now possible to
provide, to the customers of MBTA, convenient transfers between the two systems.
Frequent riders are able to use cards (magnetic- or Smart Cards) for convenient
multiple uses throughout the system (including autoload and ’manual’ re-load at FVMs
and TOMs). Project wide Smart Card media integration is one of the key elements of
this project. The contactless smart card media will be used as Payment type (Money
Value, Multiple Ride Pass), VIP Discount Pass with Picture ID (Senior, Student, VIP
Pass), Prepaid Time Duration Pass (Weekend, week, month, …) or as an Account
Based Monthly Card. Easy, convenient, and quick to use and fast processing are some
of the main objectives realized in this project through the use of the smart card product.
Revenue reporting, online Card tracking and system wide blocking, Account
Management, and global system control are only some of the highlights of the
operational side of the Authority; all implemented using the same modular structure and
design of the system components all over the entire system network.
Credit / Debit Card - Clearing House Provider
Fifth Third Bank
Payment Methods
Fare Media
• Cash (coins and bills)
• Magnetic stripe tickets from rolled
stock
• Cashless (credit / debit)
• Stored Value (smart-card based • Smart Card (Mifare Classic) for
passes and stored value.
and magnetic stripe card)
Key Features
•
Maintenance of System Data
•
Software Version Management
•
Archive & Purge
•
Download of System Data and
Software
•
Upload of Sales Data and
additional technical data for job
scheduling
•
Alarm Management
•
Account
Management
(magnetic stripe and Smart
Cards)
•
System wide Card Tracking
and blocking (Fraudulent Use
check)
•
Maintenance Scheduling
•
Revenue Service Scheduling
•
Reconciliation of credit card
transaction
Central User Management
•
Revenue auditing & reporting
•
Page 92
Fare collection
systems
Project History
Project award in February 2003
Installation Silver-line (farebox-pilot) January 2005
Installation Blue-line (subway) April 2005
Roll-out: spring 2006
MBTA Implementation after 1 Year:
• 1,800,000 CharlieCards in active use
• 64%, or 2 out of 3 fares paid with
CharlieCards
• 12.7 million subway CharlieCard
boardings each month
• 8.4 million bus CharlieCard
boardings each month
• $5.7M USD average monthly
CharlieCard transactions processed
by Fare Vending Machines
"When we introduced smart card technology, we looked around at peer agencies.
We set out projections at what they did. We've exceeded expectations, we have far
exceeded anything that any other agency in the United States has done.”
Joe Pesaturo, MBTA Spokesman
3.2
UTA (Salt Lake City, UT)
Customer Contact
Utah Transit Authority
3600 South 700 West
Salt Lake City, UT 84119
Proj Manager: Mr. Travis Baxter
Telephone: +1 (801) 237-1950
TBaxter@rideuta.com
Page 93
Fare collection
systems
Equipment
Project Volume
Contractual Status of Scheidt &
Bachmann USA, Inc
Complete Central Server System
Paper Fare Media
Prime Contractor
Rail System
Supply and installation of 72 Ticket
Vending Machines
3.3
Regional Transportation District (Denver, CO)
Customer Contact
Regional Transportation District
1600 Blake Street
Denver, CO 80202
Proj Manager: Frank Buczkowski
Telephone: +1 (303) 299-2464
Frank.Buczkowski@rtd-fastracks.com
Equipment
Project Volume
Contractual Status of Scheidt &
Bachmann USA, Inc
Magnetic Fare Media
Prime Contractor
Rail-System
Supply and installation of 40 Ticket
Vending Machines
Supply and installation of 90 Standalone Validators
Supply and installation of 3 Faregate
aisles
Page 94
Fare collection
systems
3.4
PAAC (Pittsburgh, PA)
Customer Contact
Port Authority of Allegheny County
345 Sixth Avenue
Pittsburgh, PA 15222
Proj Manager: Mr. Tom Noll
Telephone: +1 (412) 566-5273
tnoll@portauthority.org
Equipment
Project Volume
Contractual Status of Scheidt
& Bachmann USA, Inc
Contactless Fare Media
Prime Contractor
Bus-System
Supply and installation of 900 Fareboxes
Supply and installation of Garage Systems with
18 vaulting systems
Supply and installation of 40 Ticket Vending
Machines
Supply of 100 Agency and 3rd Party Sales
Terminals
Page 95
Fare collection
systems
4
List of Project Personnel
Project Manager
The proposed project manager is Mr. Bernd Hoene. It is anticipated that he will spend
about 75 % to 100% of his time on this project, depending on the stage the project is at.
Bernd has broad experience with technology implementation, both at Scheidt &
Bachmann, and at other organizations he has worked for. He also has extensive applied
expertise in Scheidt & Bachmann’s project management processes, which will enable
him to effectively assign work and monitor work by the rest of his team and the
participating departments, ensuring the project delivers the system specified on time.
Name
Bernd Hoene
Years
Experience
With Scheidt & Bachmann since 1991
Company
Scheidt & Bachmann USA, Inc.
Title
Senior Project Manager, Fare Collection Projects
Education
Diploma Engineer, Automation Engineering and Computer Science
Related AFC
Project
Experience /
Major Projects
2010 - current: Port Authority of Allegheny County Pittsburgh, PA
(Project Manager)
2009 – 2011: TRI-MET – Portland, OR (Technical Manager at S&BUSA INC.)
2002 – 2010: MBTA Boston, MA (Project Manager)
2000 – 2002: Metro North/Long Island Railroad (Technical Project
Manager)
1994 – 2002: BART San Francisco (Project Manager)
1993 – 1994: Metro Baltimore, MD (Project Manager)
1991 – 1993: Software Engineer for misc. AFC projects
Page 96
Fare collection
systems
Technical Project Manager
Name
Georg Pomp
Years Experience
Title
Technical Project Manager
Education
Diploma degree in Electrical Engineering/Computer Sciences
Related Project
Experience
Software Developer for POS stations
Director of Technical Services for Scheidt & Bachmann
(Parking Division) Boston, Massachusetts USA
Project Team Member for the Metro North / Long Island
Railroad Project New York, New York USA
Project Team Member for MBTA Project Boston,
Massachusetts USA
Project Team Member for the Metro Rail Project Houston,
Texas USA
Hardware Development Lead
Name
Andreas Bongartz, Dipl.-Ing.
Years Experience
Title
Group Manager Hardware Development
Education
Degree in Mechanical Engineering
Related Project
Experience
Overall responsibility for Technical and Hardware
Development for all Fare collection systems division
• Overall concept / Design
• Planning / Controlling
• Mechatronic Devices
• Customer Approvals
Page 97
Fare collection
systems
Software Development Lead
Name
Marina Schiffer,
Years Experience:
Title
Head of Customer Specific Software Development
Education
Dipl.-Ing.(CS) Technical University of Transportation and Telecommunication Science in Zilina , Slovakia
Related Project
Experience
Frontend application development and technical team
management for following projects:
• GER SSB Stuttgart, VAG Nürnberg, Kurbad Norderney,
MoBiel Bielefeld, VGF Frankfurt, Rheinbahn Düsseldorf
• SPT Glasgow
• SWISS Neuchatel
• UK ATOC, GMPTE
• IRE LUAS, Irish Rail
• USA Massachusetts RTA’s, St. Louis, Sound Transit
• Italy NTV
Poland Regional Rail, ZTM Gdansk
Maintenance Service Manager
Name
Michael Senger
Years Experience
Title
Service Manager
Education
Diploma in Engineering
Related Project
Experience
MBTA, Boston
Massachusetts RTAs
Sound Transit - Seattle, WA
PAAC –Pittsburgh, PA
Pittsburgh area RTAs
St. Louis
Milwaukee, WI
Page 98
Fare collection
systems
Documentation Manager
Name
Dale Hedrick
Years Experience
With Scheidt & Bachmann since 2000; 18 years prior
experience in other Firms/Industries
Title
Manager, Technical Documentation & Training
Education
B.A. Business Commerce
Related Project
Experience
Boston MBTA (Documentation & Training Manager)
Phoenix (Documentation & Training Manager)
Las Vegas Monorail, Las Vegas, NV (Documentation
Manager)
Houston Metro (Documentation Manager)
Sound Transit - Seattle, WA (Documentation Manager)
Regional Transit District - Sacramento, CA (Documentation
Manager)
Others
Manufacturing Manager
Name
Gustav Held
Years Experience
Title
Director of Manufacturing, S&B USA
Education
1994: Diploma Engineer, Electronic Engineering
Related Project
Experience
Head of the S&B Production Department
Involved in all production for US projects
Contracts Manager
Name
Joseph McGrath
Years Experience
With Scheidt & Bachmann since 03/2003, other firms since
1979
Title
Contracts Manager
Education
Incorporated Law School of Ireland, Solicitor
University College of Dublin, Bachelor of Civil Law
Related Project
Experience
Oversees all company contract activities
Page 99
Fare collection
systems
Quality Assurance
Name
Udo Paffrath, Dr. rer. nat.
Years Experience
Title
Director of Quality Management
Education
Degree in Physics, University of Cologne 1986
Related Project
Experience
Oversees all company quality activities
Page 100
Fare collection
systems
5
Organization Chart / Proposed Project Team
LTC Project Manager
Scheidt & Bachmann USA
Board of Directors
Quality Assurance
Head
Dr. Udo Paffrath
Key Account
Manager
Richard Simpson
Responsible Executive
David Macaulay
S&B Project Manager
Bernd Hoene
Contract
Management
Joseph McGrath
Manufacturing &
Test
Gustav Held
Documentation &
Training
Dale Hedrick
Technical Project
Manager
Georg Pomp
Software Release
Testing
Veenaye Purgus
Hardware
Engineering
Andreas Bongartz
Systems
Engineering
Alfred Höhn
Installation
Subcontractor
Support Services
Michael Senger
Software Support
Daniel Terryn
Software
Engineering
Marina Schiffer
Page 101
Fare collection
systems
6
Availability
Availability of Scheidt & Bachmann personnel will vary greatly based on the stage of the
project and the person’s role. Throughout the project however, there will always be a
key member of the Scheidt & Bachmann team available. At almost all times, your
project manager will be available to support you.
Project Personnel
Availability
Project Manager
The Project Manager will be the primary point of contact
through the project. From the beginning to the end the Project
Manager will remain an active member of the team.
Technical Project
Manager
The Technical Project Manager will be involved largely in the
beginning of the project during the design phase. They will
also be involved during installation phase to a lesser degree,
and any other time where they may be needed.
Hardware
Development Lead
The Hardware Development Lead and their team focuses a
significant amount of their time at the very beginning during the
design phase and development phases. Once the final design
is accepted and production has started, the Hardware Design
Lead is only involved in the project on an as needed basis.
Software
Development Lead
The Software Development Lead and their team focuses a
significant amount of their time at the very beginning during the
design and development phase. Once the final design is
accepted, and software has been developed and tested, the
Software Design Lead is only involved in the project on an as
needed basis.
Maintenance Service
Manager
After the Project Manager, the Service Manager will be the
person whom Fort Collins has the most interaction with. From
the beginning the Service Manager is involved training his
team on the new equipment. After production is completed,
the Maintenance Service Manager and his team perform the
actual installs of equipment. After the newly installed system
goes live, the primary point of contact changes from the Project
Manager to the Service Manager as responsibilities are
transitioned.
Documentation
Manager
The Documentation Manager is available during the project
after the final design review is completed up until the end.
Page 102
Fare collection
systems
After design review is accepted the documentation starts
development up until production of the manuals.
The
Documentation Manager is also responsible for the training so
they and their team will have a high availability scheduled near
the time of installation to provide training.
Manufacturing
Manager
The Manufacturing Manager is available and dedicated to the
project when the production stage begins. They remain so
until all devices are properly installed and all spares are
provided.
Contracts Manager
The Contracts Manager’s availability is primarily at the very
beginning of the project as the contract is developed and
signed. After signing the Contract Manager is available for any
questions in regards to the contract, or future Change Orders.
Quality Assurance
Manager
The Quality Assurance Manager plays a critical role during the
production and development phases of the project. They are
available afterwards if there is a need to discuss quality
matters regarding the project.
Page 103
Fare collection
systems
7
Estimated Hours by Task
Please refer to Section 1.3 - Draft Project Schedule for a list of tasks and estimated
times. As the schedule is a draft both the tasks involved in the project and the times for
each task may change.
Page 104
Fare collection
systems
8
Schedule of Rates and Cost by Task
The following hourly rates apply for out of scope contract labor.
include travel costs and expenses.
Pricing does not
Resource
Daily Rate
Project Manager
$ 1,440.00
Hardware Developer
$ 1,640.00
Junior Software Developer (Applications / Administration)
$ 1,360.00
Senior Software Developer (Architect / Analyst)
$ 1,640.00
Documentation / Technical Writer
$ 1,240.00
Training Engineer
$ 1,240.00
Quality Assurance
$ 960.00
Software Maintenance / Support / Helpdesk
$ 1,520.00
Field Service
$ 1,600.00
Page 105
Fare collection
systems
9
Addendum
Scheidt & Bachmann acknowledges receiving Addendum #1.
Page 106
Fare collection
systems
10
10.1
Attachments
Sample Service Agreements
Page 107
Fare collection
systems
Scheidt & Bachmann
Service Level Agreement
Appendix General SLA Regulations
This document remains the property of Scheidt & Bachmann. It is provided solely for the purpose of supplier qualification. The content is confidential and may not be disclosed to any third party or used for any other purposes.
This document is based on template version 1.1.
Fare collection
systems
Table of Contents
1
INTRODUCTION ................................................................................................................... 3
2
THE CUSTOMER’S RESPONSIBILITIES ............................................................................... 4
2.1
GENERAL RESPONSIBILITIES .................................................................................................... 4
2.2
MACHINES (TVM) ..................................................................................................................... 4
2.3
BACKOFFICE AND SOFTWARE................................................................................................... 5
2.3.1
Backoffice hardware ............................................................................................... 5
2.3.2
Back Office and Software (Self-Managed) .............................................................. 6
2.3.3
Credit Card authorization ........................................................................................ 7
3
OUT OF SCOPE WORK ........................................................................................................ 8
4
ASSUMPTIONS AND EXCLUSIONS ..................................................................................... 10
4.1
5
ASSUMPTIONS AND EXCLUSIONS RELATED TO VIRUS PROTECTION .................................... 11
DEFINITIONS ..................................................................................................................... 12
File: Fort Collins_ SLA Appendix General SLA Reg. - Draft - V1.1
© Scheidt & Bachmann GmbH – Fare collection systems – Feb-13
Fare collection
systems
1
Introduction
This appendix defines further general regulations for this Service Level Agreement.
.
Fare collection
systems
2
The Customer’s Responsibilities
2.1
General responsibilities
The general responsibilities of the Customer are as follows:

The Customer shall ensure that its staff at the Locations is appropriately
trained and aware of their responsibilities in respect of the operation of the
Supplied Equipment

Provision and administration of the Customer’s data network

costs for attendance for “no fault found” situations

costs for exchange of consumables in the field
Any costs arising as a result of vandalism of the Supplied Equipment remain the Customer’s Responsibility.
At all reasonable times the Customer shall allow access to all the Supplied Equipment and to the FareGo Data system at the Locations to allow Supplier to perform its
Services
In the event that the Customer does not meet its responsibilities defined in this chapter 2, the Supplier may charge its reasonable additional costs incurred as a result of
such failure
2.2
Machines (TVM)
The Customer’s staff shall perform daily management tasks, specifically:

End-of-shift cash handling. Re-stocking coin and bank-note storage
mechanisms and emptying of coin and bank note vaults

Replenishment of ticket stock.

Routine cleaning of the Machine exterior.

Removal of coin, bank-note and credit card jams (where practical).

Basic maintenance activities (‘Fingertip Maintenance’) as defined below.

Provision and administration of the Customer’s Data Network.

The provision of merchant agreement for credit card payment authorisation.
The Supplier shall provide technical documentation to specify how the Customer
shall carry out Fingertip Maintenance. The exhaustive list of Fingertip Maintenance
tasks is listed in the table below:
Fingertip Maintenance - Corrective
Fingertip Maintenance - Cleaning
Insertion, removal and emptying of all re- Cleaning of Machine exterior
movable components of the coin and banknote handling system, e.g. ACM, coin vaults.
Fare collection
systems
Fingertip Maintenance - Corrective
Fingertip Maintenance - Cleaning
Clearing of coin jams with regard to the fol- Cleaning of touch screen
lowing components:
 Coin Acceptor (coin path)
 Coin Verifier (coin path)
 Coin Drawer (coin magazine top slot)
 Exchange of Coin Cassettes (recycling cassettes as well as auxiliary
cassettes)
Clearing of banknote jams with regards to Cleaning of coin verifier
the following components:
 Insert/ Exit Slot
 Banknote Acceptor
Clearing of ticket jams with regard to the fol- Cleaning of banknote system with special
lowing components:
cleaning pad
 Ticket Feed/Cut Unit
 Ticket Printer (ticket path)
 Magstripe Read/Write Unit(ticket path)
 Ticket Stock Holders
Service Commands :
 Restarting Machine <093>
 Reset Coin Problems <090>
Cleaning of credit card reader device with
special cleaning pad
Switching Machine Off/On
Cleaning of ticket issuing device with regard to feed/cut unit and read/write unit
Technical Printouts
2.3
2.3.1
Backoffice and Software
Backoffice hardware
FareGo Data Hardware Maintenance and workstation hardware maintenance are/is
not covered under this Agreement. All hardware related administrative tasks (including analysis of hardware failures, such as checks of disk space and database table
space) will be the responsibility of the Customer.
FareGo Data and workstations may be bought by the Customer from
a) the Supplier or
b) a third party supplier
If FareGo Data or workstations are bought by the Customer from the Supplier, a
dedicated document on Hardware Service Levels will be issued with this equipment
Fare collection
systems
which is a back to back hardware agreement with a third party supplier of these systems.
The Hardware Service Level documents will include all necessary information with
regard to reaction times, response times and resolution of errors. Furthermore, the
Hardware Service Level document will have its own clauses with regard to duration
and termination which is not necessarily bound to this SLA.
If FareGo Data or workstations are bought by the Customer from a third party supplier (and therefore not from the Supplier) then the Customer is fully responsible for
the Hardware maintenance.
2.3.2
Back Office and Software (Self-Managed)
The general responsibilities of the Customer are as follows:
o FareGo Data Operating System Administration for all Back Office servers like Authorisation Server, Application Server or Database Server
o FareGo Data Database System Administration
o Installation of Operating System Patches
o Installation of FareGo Data Database patches
o Maintenance of Supplier approved up-to-date anti-Virus software on the
devices and data protection in compliance with manuals provided by
the Supplier.

Provisioning and Maintenance of the LAN/WAN to connect Field Devices,
Back Office and Workstations.

Provision of a permanent site-to-site VPN connection so that the Supplier will
have full access to the Customer’s FareGo Data and to the connected devices
in the network. The use of a broadband connection is mandatory. The software to be used for remote connections is Microsoft RDP or PC Anywhere.
Supplier will remotely connect to the FareGo Data system and use FareGo
Data functions for the maintenance of Supplied Equipment. To avoid misunderstandings no PC Anywhere connection will be used to connect to the Supplied Equipment. The Customer will provide the Supplier with required LOGfiles and system information if the VPN connection should fail.

Maintenance of the data communications circuits that operate between the
Authorisation server and the credit card acquirer’s systems.

Unless Third Party Software is explicitly provided with appropriate maintenance by Supplier, Customer shall ensure that Third Party Software is properly maintained. In particular Oracle software maintenance is provided by
Supplier for maximum one year if requested; Customer shall contact Oracle
for a maintenance extension from year 2 onwards.

Unless explicitly provided by Supplier, provisioning of a Oracle database license that supports partitioning for database and archive servers.
Fare collection
systems
The Customer shall provide IT support for the daily operational activities required to
maintain the operation of the FareGo Data system, the workstations and the Local
Device Controller (if applicable), e.g. back-up procedures of servers, handling of
back-up tapes, user account maintenance, rebooting servers or monitoring of the
hardware.
2.3.3
Credit Card authorization
The responsibilities of the Customer are as follows:

The provision of merchant agreement for credit card payment authorisation

Merchant costs (e.g. Acquirer costs per transaction)

PCI DSS certification costs unless explicitly covered by this SLA

Any transaction based costs or additional annual maintenance fee for the
payment solution

Transmission costs (secure X.25 or TNS line to Acquirer)
Fare collection
systems
3
Out of Scope Work
For the purpose of this Agreement, ‘Out of Scope Work’ is defined as any Services or
Works not covered under this Service Level Agreement and includes occurrence of
any of the situations described below. ‘Out of Scope Work’ is subject to the Change
Control Procedure:
a) Relocation of devices, including removal, transportation and reinstallation of the devices at the new location.
b) Obsolescence of components supplied by the Supplier’s SubContractors: In the event that any component that is purchased by the
Supplier from its Sub-Contractors (e.g. hard disk, LCD, Screen, support of Third Party Software) becomes obsolete during the term of the
Contract, the Supplier shall identify a compatible replacement solution.
The replacement solution shall represent the most cost effective approach that retains the overall functionality of the affected item. Therefore, the replacement solution may not be an exact one-to-one replacement of the original component. If these non-availability circumstances occur, the Supplier shall submit to the Customer via the
Change Control procedure the rationale and details of the replacement
solution complete with any changes to the Charges, either positive or
negative, relative to the original component.
c) Extraordinary price changes to components supplied to the Supplier by
their Sub-Contractors: In the event that purchasing prices for any SubContracted components (e.g. hard disk, LCD, Screen, support of Third
Party Software) change significantly (in excess of 15% either up or
down), during the term of the Contract then the Supplier shall evaluate
whether the price change or a replacement solution will be the most
cost effective approach. In the event that a replacement is required the
solution shall retain the overall functionality of the affected item and
may or may not be an exact one-to-one replacement of the originally
delivered component. If these significant price change circumstances
occur, the Supplier shall submit to the Customer via the Change Control Procedure, the rationale and details of the change to the Charges,
either positive or negative. The Supplier shall provide sufficient information regarding its changes in cost (not just price) to demonstrate to
the Customer that any price increase is justified.
d) Changes required due to statutory requirements/ regulations: In the
event that a change is required due to statutory requirements or regulations from banks or other authorities, and such change requires the
Supplier to incur additional expenditure in the performance of the Services under this Service Level Agreement, a change under the Change
Control Procedure shall be implemented.
e) Changes required due to vandalism: In the event that extra work is required due to vandalism that requires the Supplier to incur additional
expenditure in the performance of the Services (including parts that
Fare collection
systems
need repair or exchange) under this Service Level Agreement, the
Supplier shall have the right to charge this extra work to the Customer.
f) Software Updates requested by the Customer in excess of the Software Updates limit in this SLA.
g) Work required as a result of the Customer’s failure to perform its obligations under this Agreement.
h) Upgrades and 3rd Party Upgrades are not part of the managed services
and will be handled through a change control procedure. For the
avoidance of doubt changes of the database system (e.g. from Oracle
9i to Oracle 10g) are not part of the managed service as they are Upgrades.
For the avoidance of doubt, none of the provisions of this paragraph describing ‘Out
of Scope Work’ release the Supplier from its obligation to maintain the Standard of
Performance required by the Service Level Agreement. This paragraph simply sets
out those changes for which the Change Control procedure must be applied in order
to effect changes necessary to maintain the Standard of Performance.
Fare collection
systems
4
Assumptions and Exclusions1
For the avoidance of doubt, Upgrades and functional enhancements (whether for
Supplier Software or Third Party Software) are not part of the Maintenance Service
and will be handled through the Change Control Procedure if required by the Customer or deemed necessary by the Supplier.
For the avoidance of doubt, the Supplier’s Help Desk may be called only by Customer’s staff. The Supplier will under no circumstances provide support directly to
End Users.
The Supplier shall have no obligation to provide Services in the event of any Defect
or damage which arises or develops as a result of any:

Normal wear and tear, maintenance or modifications to the Supplied
Equipment or Software performed by the Customer or its contractors
(other than the Supplier or its employees, agents or sub-contractors)
other than in accordance with the Operating Manuals; or failure of any
of these parties to protect data in accordance with the Operating
Manuals;

alteration to the works, Supplied Equipment or Software made by the
Customer or any negligent act or omission of the Customer or any of
their employees, agents or sub-contractors (other than the Supplier or
a Sub-Contractor);

Design, material, software or interface furnished by the Customer or a
3rd party;

Viruses brought into the Customer’s system by interfaces or data carriers that are not under the Supplier’s control;

Force Majeure Events, misuse of the Supplied Equipment or Software,
vandalism or damages caused by any party other than the Supplier.

defect or damage beyond the Suppliers sole and exclusive control or
solely and exclusively caused by the Supplier

Combination of Software or Machines with hardware or software not
provided by or approved by the Supplier;
1
This Service Level Agreement is provided under the general assumption that it will be appended to a
contract with mutually agreed terms and conditions, including limitation of Supplier’s liability (with exclusions of liability for consequential or indirect damage, and loss of revenue and profit and reasonable limitation of liability for direct damage), payment and invoicing procedures, price adjustment and
taxes, term and termination of contract, change control and dispute resolution procedure and a force
majeure clause
Fare collection
systems
4.1
Assumptions and Exclusions related to virus protection
The Supplier shall perform all tasks as agreed in this SLA related to virus protection
in order to protect all Supplied Equipment of the AFC from Software viruses as far as
possible. However, The warranty for third party software or hardware delivered or
used in connection with the Supplied Equipment is limited to that provided by such
third parties. That implies:

For the avoidance of doubt, the Supplier will under no circumstances
whatsoever be responsible for the capability of third party software to
detect, delete, destroy or otherwise eliminate viruses.

For the avoidance of doubt, the Supplier will under no circumstances
whatsoever be responsible for the capability of the third party software
to resolve defects in the patches or the capability of the Customer
network to transport the respective patches.

Failures or malfunctions of third party software cannot always be remedied. In this context the Customer acknowledges that Supplier or its
affiliates will under no circumstances whatsoever be liable for any
damages (indirect, consequential or direct) caused by the third party
software, for the avoidance of doubt, including but not limited to
-
failures or malfunctions in deleting, destroying or otherwise
eliminating viruses,
-
any other failures, defects or malfunctions of one single machine or the whole system.
Any work needed to delete, destroy or eliminate a virus, which has not been deleted,
destroyed or eliminated automatically by the third party software will be charged separately.
Fare collection
systems
5
Definitions
The definitions below replace those of the main contract clauses.
3rd Party Update – means a change to software supplied by a third party supplier
where it is technically possible to install the change with the mechanisms set out in
the Scope of Work and without further configuration or design changes to the Supplier’s software.
3rd Party Upgrade – means a change to software supplied by a third party supplier
which will be installed as a result of the Change Control Procedure. A 3rd Party Upgrade is any change to third party software that incorporates major changes, such as
but not limited to:

A major release of a 3rd Party software

Significant new features in the 3rd Party software

A new or changed license model of the 3rd Party software
AFC (Automated fare collection) System – The sum of all Supplied Equipment and
software components that are installed to enable automated fare collection. These
are for example Machines, Gates, back office servers and workstations.
Agreement - means the agreement to which this Schedule is attached.
Aisle - is the portion of a gate that consists of one walkway.
Annual Charge - has the meaning ascribed to it in the Agreement.
Back Office System – the sum of all servers and software that are centrally installed
to configure, maintain or support the Field Devices. The main components of a Back
Office System are the FareGo Data system and the credit card authorisation.
Business Day - has the meaning ascribed to it in the Agreement.
Change Control Procedure - has the meaning ascribed to it in the Agreement.
Charge - is the amount of money paid per annum for all installed Supplied Equipment (to avoid misunderstanding the Charge applies to each equipment type : for
example a TVM, a Gate, a Validator or a Back Office System) and fees for Services
defined in this Service Level Agreement.
Charge per Period - is the amount of money paid per Period for all installed Supplied Equipment (to avoid misunderstanding the Charge per Period applies to each
equipment type : for example a TVM, a Gate, a Validator or a Back Office System)
and fees for Services defined in this Service Level Agreement)
Fare collection
systems
Consumables - shall have the meaning given to it in Appendix PMRM
FareGo Data – is software provided by the Supplier to the Back Office that provides
features to configure and monitor Field Devices and support accounting and reporting. The scope for the support is the functionality ordered and agreed at the time
when the Agreement is signed.
FareGo Data application – FareGo Data is a combination of several FareGo Data
applications which each provide features related to a specific topic or workflow. The
following FareGo Data applications are defined:
 Status Monitoring
Device Alarm handling and status visualisation
 Device Management
Device inventory and configuration incl. SW provisioning
 Transaction processing
Sales data upload, processing and revenue settlement
 Reporting
Generation of reports within the
 ITSO handling / CMS
Communication with HOPS, management of hot- or blacklists, Clearing of sales in Field Devices, Customer Management System
 External Interfaces
Upload of transaction data to 3rd Party systems like a data warehouse,
Customer – has the meaning ascribed to it in the Agreement
Defect - means a material deviation of the Supplied Equipment or the Software from
its written specification. A Defect must be reproducible on the Supplier’s test system
or the Customer’s system.
Designated Representative – has the meaning ascribed to it in the Agreement.
Documentation - has the meaning ascribed to it in the Agreement.
Down – A Field Device or Server of the Back Office System is Down when it is not
Operational.
Down Time - is the time span for which a device of the Supplied Equipment is not
Operational. In relation to each device, Down Time starts with the Report Time and
ends after the Resolution Time span.
End User – Person that uses the AFC to purchase tickets.
End User Facing Applications – Those applications of the Back Office System that
are directly required to operate the ticket sales processes, such as, but not limited to:
Credit/Debit authorisation, Internet retailing.
Equipment - means Supplied Equipment.
Fare collection
systems
Fares Data – is the information provided by RSP that defines the full set of UK rail
ticket fares that may be vended by a Machine.
Field Devices – means all TVMs, Gates, Farebox and/or Validators covered by this
agreement.
Fingertip Maintenance - is defined as corrective preventive action that requires the
use of hands and keys only without using any tools, e.g. the clearance of ticket,
banknote and coin jams, as further explained in paragraph 2.
Fleet Defect - is a failure or malfunction that occurs on several Field Devices (minimum of five (5)) that is repetitive in nature (minimum of three (3) occurrences in a
Period) and which is due to an identical root cause. Fleet Defects are those failures
or malfunctions that emerge after installation of the device or after installation of a
New Version. Fleet Defects exclude those failures or malfunctions which have been
documented during the Supplier’s factory test.
Force Majeure Event - has the meaning ascribed to it in the Agreement.
Functional Specification - means the Supplier’s technical specification for the devices of the Supplied Equipment.
Hardware Upgrade – means any change to the existing hardware of any Machine
that is not the result of the resolution of a Defect by the Supplier under its maintenance obligation.
Improper Use - means use of the Supplied Equipment or Software by the Customer
or an End User that is not in accordance with operating instructions reasonably
specified by the Supplier or any supplier of 3rd party components.
Hot List - is the set of the commonly used rail tickets vended by a specific Machine
defined by virtue of its location.
Incident - means a problem arising with one or more devices of the Supplied Equipment and reported as a Defect or Software Issue Report.
Incident Number - means a unique reference number allocated by the Supplier’s
Help Desk for each Incident reported by the Customer.
Internal Operations Applications - those applications of the Back Office System
that are required to configure and maintain the AFC but are not directly required to
operate the ticket sales processes, such as, but not limited to: The FareGo Data system or a Reporting Application.
Level of Availability - has the meaning ascribed to it in chapter Error! Reference
source not found..
Fare collection
systems
Local Control Unit - means a PC that is typically located at a station to monitor and
maintain basic functionalities of Gates installed at this station and has been supplied
under the Supply Agreement.
Locations - means the Customer’s locations where the devices of the Supplied
Equipment are installed.
Machine - means the Supplier’s Self Service Ticket Issuing Terminals being subject
to the Services to be provided.
Maintenance Engineer - is an employee or representative of the Supplier who is
technically qualified and knowledgeable about the Supplied Equipment and Software
being subject to this SLA and who will provide on-site or remote Services to the Customer.
Managed Service – has the meaning ascribed to in Appendix MS.
Minor Applications – those applications within the Back Office System that are not
relevant for daily operations of the AFC, such as (but not limited to) test facilities or
Archive & Purge Servers.
New Version - means an Upgrade or an Update.
Operating Manuals - means the operating manuals supplied to the Customer relating to the use of the Supplied Equipment.
Operational - means that
 A Machine is capable of functioning in Revenue Earning Mode in accordance
with the Functional Specification.
 A Gate is capable of functioning in Single Direction Mode in accordance with
the Functional Specification
 Other Supplied Equipment is either in Revenue Earning Mode in accordance
with the Functional Specification or may be used
Period - defines a period of 28 days which starts on a Monday and ends on a Sunday.
Progress Update Time - is the date and time at which the Customer requests any
progress report for an Incident from the Supplier’s Help Desk.
Report Time - is the date and time when the Supplier’s Help Desk first receives an
Incident reported by the Customer. For the purpose of this SLA, ‘receiving’ shall
mean the earlier of
 the time when a call is actually received during Operating Service Times of
the Supplier’s Help Desk or a call related to a high priority incident is received by the On-call Service
Fare collection
systems

the next time that the Supplier’s Help Desk opens according to Service
Times. (when the Customer leaves a message with the Supplier’s Help
Desk outside Operating Service Times on the mailbox or by email),
Resolution Time - has the meaning ascribed to it in this SLA.
Reaction Time - has the meaning ascribed to it in this SLA.
Response Time - has the meaning ascribed to it in this SLA.
Revenue Earning Mode - means a condition under which a Machine, Farebox, or
other Supplied Equipment is capable of collecting fares from passengers and issuing
tickets to them.
RSP – means the Rail Settlement Plan
Server Farm – the sum of all servers that together form the Customer’s Back Office
System.
Service Manager - is a representative of the Supplier appointed as the primary interface between the Supplier and the Customer for all matters in relation to this SLA as
further explained in chapter 2.3 in the main SLA document.
Service Module –The definition of part of Managed Services which provides support
for a specific process or feature. Service Modules cannot be further split or broken
down.
Service Project Initialisation – is the first phase of the Service delivery project
where necessary agreements are made between Supplier and Customer before the
Service can be implemented.
Service Reports - means the electronic and/or paper management reports provided
by the Supplier to enable the Customer to monitor this SLA as further explained in
chapter 2.3 in the main SLA document.
Service Review Meetings - means meetings of representatives of both Parties at
which the performance of the Services is reviewed and any required remedial actions
identified as further explained in chapter 2.3 in the main SLA document..
Services - means the software and hardware services to be provided by the Supplier
to the Customer under this SLA,.
Single Direction Mode - is a mode where one Aisle can only be used in one direction.
SLA - means this schedule.
Fare collection
systems
Software - has the meaning ascribed to it in the Agreement.
Software Configuration Change - means a change (excluding new or extended
functionality) to operating parameters used by the Software that the Supplier is able
to implement without requiring a change to the executable code that comprises the
Software.
Software Enhancement - means an improvement to the Software that may be proposed by the Customer or Supplier in accordance with the Change Control Procedure. Software Enhancements include all changes to Supplier Software that are not
required to correct Defects, i.e. changes required to enhance the functionality or performance of the Supplied Equipment as defined in the Functional Specification.
Software Issue Report - means a Software Defect, Software Configuration Change
or Software Enhancement.
Standard of Performance - has the meaning given to it in paragraph Error! Reference source not found..
Start Date - means the date of the Agreement.
Supplied Equipment - means all equipment supplied under the Supply Agreement
which are Field Devices and Back Office Servers, unless specifically excluded under
this Agreement.
Supplier – has the meaning ascribed to it in the Agreement
Supplier’s Help Desk - means the facility described in chapter 2.1 in the main SLA
document, that is provided by the Supplier for managing the interface between the
Customer and the Supplier for resolution of Incidents.
Term - has the meaning ascribed to it in the Agreement.
Third Party Software - is software that forms part of the Supplied Equipment but not
originally produced by the Supplier. This particularly refers to Microsoft Windows,
Oracle, virus protection software and the like.
Tier 5 – Transaction Integrity – A level of disaster recovery used in business continuity planning. Tier 5 is defined as “consistency of data between production and recovery data centres. There is little to no data loss in such solutions, however, the
presence of this functionality is entirely dependent on the application in use.”
TOM - means the Supplier’s Ticket Office Machines being subject to the Services to
be provided hereunder
TVM (Ticket Vending Machine) – means Machine.
Fare collection
systems
Update - is a New Version of Software required to correct Defects. Updates may include generic enhancements free of charge as determined by the Supplier.
Upgrade - is a New Version of Software incorporating Software Enhancements that
have been agreed as a result of the Change Control Procedure. An Upgrade may
incorporate an Update.
Weekday - means Monday to Friday inclusive but excluding Bank Holidays.
Working Day - means Weekday.
Workstation – means a PC connected to the central server system (FareGo Data)
and configured to run software from the application server of the FareGo Data.
Fare collection
systems
Scheidt & Bachmann
Appendix SWM
Software Maintenance
This Appendix describes Service Modules within the Scheidt & Bachmann service offering. This document is only
valid and shall be construed in conjunction with the Service Level Agreement main document to which it is attached.
It remains the property of Scheidt & Bachmann. It is provided solely for the purpose of supplier qualification. The
content is confidential and may not be disclosed to any third party or used for any other purposes.
Fare collection
systems
Table of Contents
1
SOFTWARE MAINTENANCE ................................................................................................ 3
1.1
WHY SOFTWARE MAINTENANCE? ........................................................................................... 3
1.2
SCOPE OF SOFTWARE MAINTENANCE...................................................................................... 3
1.2.1
Introduction ............................................................................................................. 3
1.2.2
Software Updates and Patches............................................................................... 4
1.2.2.1
1.2.2.2
Updates ............................................................................................................................... 4
Patches ............................................................................................................................... 4
1.2.3
1.2.4
1.2.5
1.2.6
Software Configuration Changes ............................................................................ 4
Data Maintenance ................................................................................................... 5
Changes to the Software scope .............................................................................. 5
Upgrades ................................................................................................................ 6
1.2.7
1.2.8
Testing .................................................................................................................... 6
Procedure to install changes to the live system....................................................... 6
1.2.6.1
General ............................................................................................................................... 6
File: Fort Collins_ SLA Appendix SWM - Draft - V1.9
Page 2 / 7
Fare collection
systems
1
1.1
Why Software Maintenance?
The stability of the software in fare collection systems is extremely important for the
availability of the complete system and the acceptance of your customers. Further on
you as an operator need a stable tool with high availability for your daily processes
such as transfer of sales data, reporting or tariff maintenance. In this context it needs
also to be considered that the software for a fare collection system consists of different software components from different suppliers (Scheidt & Bachmann, Microsoft,
Oracle, etc.). The software maintenance from S&B considers all this and with this
service S&B can offer you:
1.2
1.2.1

A stable system with high availability of the devices and the back office
system.

Simple cost planning

Up-to-date status of the software version which means smoother offering and implementing of upgrades of the software
Scope of Software Maintenance
Introduction
The Supplier shall provide Software Maintenance Services as described in this Appendix (“Software Maintenance”). Software Maintenance ensures that the Software
of the AFC is always up-to-date and Software Defects are corrected properly. Software Maintenance is applicable to Field Devices as well as to the Back Office System.
Via the Supplier’s Help Desk as further detailed in chapter 2 in the main SLA document the Customer may notify the Supplier of any issues concerning the Software.
The Supplier will log such issues as Software Issue Reports and the issues will be
classified and solved as follows:
Software Issue
Solution
Chapter
Software Defect
Update or Patch
1.2.2
Need for a Configuration Configuration Change
Change
1.2.3
Software
Enhancement Upgrade (Change Control 1.2.6
requirement
Procedure)
Page 3 / 7
Fare collection
systems
1.2.2
Software Updates and Patches
Software Defects are solved with Updates or Patches. The general procedure is to
solve the Defects with planned Updates but Patches will be delivered between the
planned Updates, if necessary, for Critical Failures as mutually agreed.
1.2.2.1
Updates
Software Issue Reports that are classified as Software Defects shall be recorded,
investigated and corrected by the Supplier in batches. Software corrections arising
from each batch shall (as far as reasonably possible) be issued by the Supplier in the
form of a single software Update to be applied to all of the Customer’s devices.
The Update is based on the latest applicable release from the Supplier and may also
include enhancements as determined by the Supplier.
The Supplier shall deliver an Update every other per year.
The Supplier will test the Update before providing it to the Customer (please refer
also to chapter 1.2.7), these tests and necessary test equipment, as seen needed by
the Supplier, is included in the offered price.
The planning of the Updates shall be mutually agreed. The Supplier will implement
the Update on the CSS. For the Field Devices the Supplier will make the Update
available for the Customer and the Customer will follow the procedures as defined in
1.2.8 for the rollout.
Apart from the applicable software the Supplier will provide the following with the Update:

Release Documentation describing the content of the Update

Installation Procedure

Test Results.
The Supplier recognises that at any one time the version of Software installed may
be different across the whole fleet of devices. In this context the Supplier accepts its
obligation to maintain and support the Supplied Equipment pursuant to this SLA.
1.2.2.2
Patches
If necessary to resolve Critical Failures in the Supplier’s Software the Supplier shall
deliver Software patches between the scheduled Updates. The scheduling for these
patches will be mutually agreed.
1.2.3
Software Configuration Changes
Software Issue Reports that are classified as Software Configuration Changes shall
be implemented on dates and times that are mutually agreed. The Supplier will provide Software Configuration Changes in less than 29 days measured from Report
Time.
Page 4 / 7
Fare collection
systems
The Customer shall be entitled to request up to two (2) Software Configuration
Changes per year at no additional charge.
1.2.4
Data Maintenance
Both Parties recognise that the correct operation of the Supplied Equipment depends
upon the accuracy of data processed by the Software, including but not limited to the
tariffs maintained in the system.
The Supplier’s Back Office System allows a wide range of tariff changes guided by
the graphical user interface, including for example

Changes of prices of existing articles

Introduction of a new article that has the same structure as an existing
article
More details can be found in the Back Office documentation. These changes may be
done by the Customer or by the Supplier.
In other cases, a tariff change might impact not only the configuration of the AFC but
also the program code, depending on the nature of the change. Examples are:

Introduction of a totally new type of article

Change to the tariff database of the CSS or the Supplied Equipment

Changes and/or enhancement of functionalities with regard to tariff or
tariff maintenance (which are upgrades)

Changes to screens or screen flows
These changes must be done by the Supplier.
The nature of a change may depend on the type of change as well as on the existing
tariff and application structure and must be analysed case by case. The effort for
such changes may vary widely. Therefore, tariff and data maintenance is separated
from this SLA. Any changes to the tariffs or tariff system that the Supplier is requested to provide will be processed via the Change Control Procedure. One solution
is to define a budget for Data Maintenance that can be ordered via the Change Control Procedure.
The Customer is responsible for installing tariff changes that it has made to test
equipment. The distribution of such changes to the Field Devices is the Supplier’s
responsibility as part of the Scheidt & Bachmann Software Rollout Service.
1.2.5
Changes to the Software scope
If additional software modules are integrated into the Back Office System, the
maintenance obligation for such additional modules shall be added to this SLA
through the Change Control Procedure.
Page 5 / 7
Fare collection
systems
1.2.6
Upgrades
1.2.6.1
General
Software Issue Reports that are classified as Software Enhancements (Supplier
Software or 3rd Party) will be delivered as Upgrades and progressed under the
Change Control Procedures and are not covered by this SLA..
1.2.7
Testing
Supplier and Customer will agree to a set of test cases that will be used to verify the
Updates. These test cases will be defined in writing and will be approved by Customer and Supplier as the test cases to be used where test will only and exclusively incorporate the given set of test cases.
The set of test cases will be updated before a new test begins and shall be mutually
agreed between Supplier and Customer.
Supplier and Customer will always use the exact same test cases.
Supplier and Customer will make sure that the software on their respective test systems equals the live system as far as possible. No test shall be allowed that is applied to a test system that is already under another test.
Due to the nature of a Patch the test cases used to test the Patch will be agreed on a
case by case basis. Typically they are a subset of the set of test cases already defined with one or more additional test cases needed to verify the Patch.
Due to the nature of an Upgrade the test cases used to test the Upgrade are created
with the specification of the Upgrade.
1.2.8
Procedure to install changes to the live system
Changes to the live system can be incurred by installing Patches, Updates and/or
Upgrades.
The initial step will be performed by the Supplier: Updating/Upgrading the CSS with
the software release for the Field Devices. The Update/Upgrade of the software is
performed by Supplier’s staff via remote access. In this step the software for the Field
Devices is installed on the servers as a preparation for download.
The installation of software on the field devices is the responsibility of the Customer.
The following procedure is agreed unless an exception is mutually agreed upon in
writing:

Scheduling of software rollout and submittal of rollout plan to Supplier
prior to installation for information

The Update/Upgrade of the Field Devices is performed by Customer’s
staff using functionality of the CSS (Download). A similar procedure applies to the distribution of tariffs to the field devices. In order to minimize
the risk for the operation the updates/upgrades/tariffs are installed step
by step and in the order listed below:
-
Test device
Page 6 / 7
Fare collection
systems
-
One Field Device
-
Next 5 Field Devices
-
Next 30 Field Devices
-
Rest of the Field Devices (in further steps for more than 100 devices)
Each step requires an evaluation phase in order to proceed with the next step. A recommendation for this evaluation phase is one week.
The Customer checks the download
date/upgrade/tariff to the Field Devices.
and
successful
installation
of
up-
In case that the procedures to change the live system are not followed and support
from the Supplier is required Supplier may charge its cost to the Customer.
Page 7 / 7
Fare collection
systems
Scheidt & Bachmann
This document remains the property of Scheidt & Bachmann. It is provided solely for the purpose of supplier qualification. The content is confidential and may not be disclosed to any third party or used for any other purposes.
Fare collection
systems
Table of Contents
1
OVERVIEW .......................................................................................................................... 3
1.1
DEFINITIONS .............................................................................................................................. 3
1.2
INTRODUCTION .......................................................................................................................... 3
1.3
SCOPE OF SERVICES .................................................................................................................. 3
1.3.1
Help Desk and Service Management ...................................................................... 3
1.3.2
Preventive Maintenance ......................................................................................... 3
1.3.3
Software Maintenance ............................................................................................ 3
1.3.4
General SLA Regulations ....................................................................................... 4
1.4
COMMENCEMENT OF SERVICES ............................................................................................... 4
1.5
SERVICE PROVIDER ................................................................................................................... 4
2
CORE SERVICES ................................................................................................................. 5
2.1
SUPPLIER’S HELP DESK ............................................................................................................ 5
2.1.1
General ................................................................................................................... 5
2.1.2
Incident priorities..................................................................................................... 5
2.1.3
Service Times ......................................................................................................... 7
2.1.4
Service Times definition .......................................................................................... 7
2.1.4.1
2.1.4.2
2.1.5
2.1.6
2.2
Equipment Operating Time ................................................................................................. 7
Operated Service Time ....................................................................................................... 7
Reaction time .......................................................................................................... 8
Response Time....................................................................................................... 8
ADVICE AND GUIDANCE ............................................................................................................ 8
2.3
SERVICE MANAGEMENT ........................................................................................................... 9
2.3.1
Service Manager..................................................................................................... 9
2.3.2
Service planning and transition ............................................................................... 9
2.3.3
Service Review Meetings ........................................................................................ 9
2.3.4
Escalation path ......................................................................................................10
2.3.5
Reporting ...............................................................................................................10
3
COVERED COMPONENTS .................................................................................................. 11
File: Fort Collins_SLA 1_Main document - Draft - V1.2
Fare collection
systems
1
Overview
1.1
Definitions
The Definitions that are used in this document and the related appendices can be
found in Appendix General SLA Regulations.
1.2
Introduction
This SLA describes:

The Services that the Supplier shall provide to the Customer during
the Term;

The Customer responsibilities under this Service Level Agreement;

The specific remedies that would apply in the event that the Services
provided by the Supplier fall short of the Level of Availability;

Out of Scope Work and specific exclusions to the Services
This SLA refers to the Supplied Equipment delivered under contract no. XYZ (the
“Supply Contract”).
1.3
1.3.1
Scope of Services
Help Desk and Service Management
Our Help Desk is available to answer any questions, give advice and solve any problems regarding your system. For more extensive problems the Help Desk will coordinate the solution work and keep you as a customer informed about the status. If requested, our experts are able to, vie remote login, support in the analsysis of the
problems in order to minimize the problem solving time.
This service is further detailed in chapter 2. Core services.
1.3.2
Preventive Maintenance
With a schedule based on our thorough product knowledge our personnel will perform preventive maintenance (test, adjustment and cleaning etc) activities required to
pre-empt the developing of defects of the products and consequently minimize the
down time.
This service is further detailed in Appendix LCM.
1.3.3
With the objective to achieve a stable system and the requested performance we offer you a comprehensive Software Maintenance Service. This includes regular Updates for your system to correct any faults. The Updates are always tested exten-
Fare collection
systems
sively to keep a stable system. The Software Maintenance includes also regular 3rd
party verification.
This service is further detailed in Appendix SWM.
1.3.4
General SLA Regulations
The Appendix General SLA Regulations is describing the following:

Customer’s Responsibilities

Out of Scope Work, Assumptions and Exclusions

Definitions
which are valid for this SLA.
1.4
Commencement of Services
The Services shall commence, in relation to any Service Module or element of the
Supplied Equipment provided under the Agreement as soon as that element has
achieved device acceptance or upon the Start Date of the Agreement where no device acceptance is envisaged. The Supplier shall be entitled to charge Annual
Charges in accordance with the Agreement on the commencement of Services,
Any services provided prior to final acceptance under the Supply Contract are not
subject to remedies outlined in paragraph Error! Reference source not found..
1.5
Service Provider
The Supplier is the prime contractor for this SLA and as such shall be responsible for
the overall equipment maintenance and technical support.
All individuals participating in any element of this SLA will receive additional and specific training on the equipment and processes involved in the implementation of the
actual work tasks they are to perform.
In order to provide the Services, the Supplier shall be entitled to subcontract the performance of Services to the following companies, or such other companies as may
be approved by the Customer from time to time, such approval not to be unreasonably withheld:
 Scheidt & Bachmann USA Inc, Fare Collection Service Division.
Scheidt & Bachmann USA Inc, Fare Collection Service Division. shall have the leading role in provision of the Services. In addition, the Supplier shall use the employees
of its subsidiary Scheidt & Bachmann Service GmbH to support the Services. Its employees have been trained by the Supplier.
Fare collection
systems
2
Core Services
2.1
Supplier’s Help Desk
2.1.1
General
The Supplier shall provide a Supplier’s Help Desk to which the Customer shall report
all Incidents concerning the Supplied Equipment for which it requires the Supplier’s
help (“Supplier’s Help Desk”).
Communication between the Customer’s staff and the Supplier’s Help Desk shall be
by telephone and/or by electronic interface (e-mail or online form).
Every Incident notified by the Customer to the Help Desk shall be given a unique Incident Number and the Help Desk shall provide this Incident Number to the Customer
at the time of its first response to the Customer.
The Customer shall be entitled to contact the Supplier’s Help Desk at any time during
Operated Service Times for information on the progress of all Incidents. The Customer shall specify the Incident Number when requesting a progress update from the
Supplier’s Help Desk.
The Supplier’s Help Desk shall be responsible for monitoring the progress of resolution by the Supplier of all Incidents. It is supported by an appropriate fault tracking
software such that all Incidents can be accurately recorded and monitored.
2.1.2
Incident priorities
All Incidents will be assigned to one of the following five groups:
Priority
Incidents
1 – Critical

Majority (> 50%) of the field devices not in revenue
earning mode

Complete failure of CSS functionality

CSS Status Monitoring not running

Credit/Debit Authorization down

Virus detected

Significant amount (> 20%) of the field devices not in
revenue earning mode

Unable to update virus signatures on Supplied Equipment

Credit/Debit system congestion: More than 10% of authorization timeouts within one hour, where there are
more than 100 transactions per hour.
2 – High
Fare collection
systems
3 – Moderate
4 – Low
5 – Information request

One or more field devices Down

CSS Device Management Down

CSS Transaction Processing Down

CSS Reporting Down

CSS External Interfaces Down

Unable to perform software updates on field devices

Loss of credit card Services to a single field device

Other problems in the reporting

Tariff maintenance not working

Partial failure of a field device

Archive & Purge Server not working

User requests advice for software handling

Questions about capabilities of software
The default priority for any other Incident not listed here is 3 – Moderate.
An Incident may be reprioritised according to the above classifications in the event of
misinterpretation, arrival of new information or a partial solution being implemented.
Fare collection
systems
2.1.3
Service Times
At different times of day, different types of Help Desk support are applicable. These
different time slots are called Service Times. The definitions of the Service Times can
be found in the following sections. The table below specifies the Service Time
schedule.
Service Time (US)
Supplied Services
Timezone:
local time EST
(H) US Bank Holidays
Equipment Operating
time
Operated Service Time
Any Incident priority
PM / SM
24/7
Workdays
6am to 9pm
Sat/Sun/(H)
n/a
On-call Service Time
Only critical Incidents
2.1.4
Not applicable
Service Times definition
2.1.4.1
Equipment Operating Time
Equipment Operating Time is the time when the Supplied Equipment is expected to
be Operational.
2.1.4.2
Operated Service Time is the time when the Supplier’s Help Desk (1st-level support)
is operating. Incidents related to all Supplied Equipment are registered and dispatched, e.g. 2nd-level support is involved or field service is activated. Accompanying
Help Desk contacts will be provided under the contract.
During this time all questions from the Customer and Incidents will be worked on by a
technician who may (if technically possible) access the Supplied Equipment installed
in the Customer’s premises via remote connections through the Supplier’s Help
Desk.
During Operated Service Time the Help Desk can be contacted by

Phone

Email

Web portal
Fare collection
systems
For all other defect priorities, the Customer will be able to leave messages with an
automated messaging service. Answers to Incidents placed with the automated messaging system will be given during Operated Service Time.
2.1.5
Reaction time
The Reaction Time is the Time between

The Customer starting a call (getting the call connected signal)
and

speaking to a live operator at the Supplier’s Help Desk, either by being connected within the same call or by being called back by a live operator.
Or between

A Customer’s eMail arriving on the Supplier’s eMail Server
and

the sending of a receipt from the Supplier’s eMail Server.
The Supplier shall provide sufficient resources at the Supplier’s Help Desk to ensure
the following average reaction times:
Average reaction time for …
On-Call Service Time
Phone calls
5 minutes
15 minutes
eMail/Web contact
1 hour
1 hour(*)
(*)
Electronic submissions by the Customer are registered within one (1) hour of receipt at the Supplier’s Help Desk. The Help Desk staff will deal with those submissions during the next Operated Service Time.
2.1.6
Response Time
Response Time is measured as the time between the arrival of eMail or Web contacts and a first feedback to the issuer of the Incident. This includes assignment to a
service technician, and initial analysis. The first feedback will be sent on average
within 5 hours during Operated Service Time.
2.2
Advice and Guidance
At the Customer’s request, the Supplier shall provide the Customer with advice and
guidance to enable the Customer to correctly operate the Supplied Equipment and
Software (“Advice and Guidance”).
In the first instance the Customer should direct such requests to the Supplier’s Help
Desk. The Supplier may elect to refer the Customer’s requests to appropriate members of the Supplier’s staff to provide the required response.
Fare collection
systems
In the event that the Customer requests more than five (5) such requests for advice
and guidance in any one Period and that those requests could reasonably have been
resolved by the Customer using the Operating Manuals and training already provided
by the Supplier, then the Supplier shall be entitled to charge the Customer any additional costs it reasonably incurs in providing such advice and guidance.
2.3
Service Management
Service Management is the organisational foundation of Service delivery. It defines
necessary processes and practices to implement, deliver and improve the agreed
Services.
2.3.1
Service Manager
The Supplier shall appoint a Service Manager who will be responsible for the following activities:
2.3.2

Plan the Service implementation and supervise the set up;

Ensure that Incidents and other requests by the Customer are managed and owned by the appropriate Supplier’s staff in accordance with
this SLA;

Act as an escalation point in relation to any service Incidents which require management intervention;

Monitor the Standard of Performance achieved in respect of this SLA;

Represent the Supplier at Service Review Meetings.
Service planning and transition
The first step in Service Management is to plan the Service delivery together with the
Customer and to ensure the Service is set up as agreed.
The Service Manager is responsible for agreeing that plan with the Customer. The
Service Plan will contain all necessary steps to set-up the Service and to move it to
“live” operation, including milestones and acceptance tests. After the transition phase
is completed, the Services are fully available for the Customer at the agreed performance level.
2.3.3
Service Review Meetings
Unless waived by mutual agreement, regular face to face Service Review Meetings
will be held. The purpose of these meetings is to review the performance of the Supplier in respect of the Service Level Agreement. The meetings will be attended by
appropriate members of staff of both the Supplier and the Customer and will include
as a minimum the Service Manager (or his/her representative) and the Customer’s
Designated Representative (or his/her representative). The frequency of Service Review Meetings as well as the mode (face to face, phone conference) shall be agreed
between the Parties but for guidance one should be held every third (3rd) Period.
Fare collection
systems
2.3.4
Escalation path
In the event that Incidents are not resolved within the time period defined or if any
other aspect of the Standard of Performance in respect of this Service Level Agreement is not met then resolution of the problem may be escalated by the Customer or
the Supplier as follows:
Level Supplier Manager
Customer Manager
1
Service Manager (or Project Manager)
The Supervising Officer
2
National Service Director
Head of Retail Services
3
Vice President S&B, USA
Customer Service Director, and
simultaneously the Head of IT
4
Managing Director Fares Collection Division
Managing Director
2.3.5
Reporting
Service Reports shall be provided once per Period by the Supplier to enable all the
parameters documented in this SLA to be measured and monitored.
The Customer accepts that not all information may be provided for the first six (6)
calendar months following the Start Date. The Supplier shall make reasonable endeavours to make the reports fully available at the earliest opportunity.
Service Reports shall be made available to the Customer in electronic form in a
printable format (e.g. PDF format).
Fare collection
systems
3
Covered Components
The following table summarizes the Supplied equipment covered by this SLA:
Device
Quantity
TVM
21
CSS
1
Content / Comments
Fare collection
systems
Scheidt & Bachmann
Appendix PMRM
Preventive and Remedial Maintenance
This Appendix describes Service Modules within the Scheidt & Bachmann service offering. This document is only
valid and shall be construed in conjunction with the Service Level Agreement main document to which it is attached and further applicable appendices.
It remains the property of Scheidt & Bachmann. It is provided solely for the purpose of supplier qualification. The
content is confidential and may not be disclosed to any third party or used for any other purposes.
Fare collection
systems
Table of Contents
1
PREVENTATIVE MAINTENANCE ......................................................................................... 3
2
SPARE PARTS AND CONSUMABLES .................................................................................... 6
3
APPENDIX 1, PREVENTATIVE MAINTENANCE CHECKLIST FOR TVM ............................. 7
File: SLA Appendix PMRM - Draft - V1.8
Page 2 / 7
Fare collection
systems
1
Preventative Maintenance
Preventative Maintenance shall mean regular scheduled maintenance activities required to pre-empt the development of Defects in the Supplied Equipment, so as to
minimise unscheduled Down Time (“Preventative Maintenance”).
Preventative Maintenance shall be implemented through a program of site visits by
Maintenance Engineers to each device of the Supplied Equipment at a frequency to
be proposed by the Supplier and approved by the Customer. The Customer shall not
unreasonably withhold approval of this program. In the first instance the frequency of
Preventative Maintenance shall be no less than shown in the table below. In no event
shall the frequency of Preventative Maintenance site visits to any one Field Device,
as listed below, be less than once every six calendar months.
Preventative Maintenance Machine (TVM)
Component
Cash & Credit
Card Only
Month
Month
4
8
12
4
8
Interior cleaning Machine
Heater / Blower
X
X
Fan Units
X
X
General Cleaning
X
X
X
X
Check of Machine Components
Ticket / Money Tray
Issuing Tray Light (bulb testing)
Power pack
Power Pack
X
X
Power Connection Box
X
X
Backup Battery
Backup Battery (checking best be- X
fore date)
Alarm System
Alarm System (testing)
X
X
X
X
X
X
X
Pedestal
Machine Pedestal
Check PM due dates
PM Label check
Page 3 / 7
12
Fare collection
systems
Preventative Maintenance Machine (TVM)
Component
Cash & Credit
Card Only
Month
Month
4
8
12
4
8
Check LCM due dates
LCM Label check
X
X
X
X
X
X
Display
Touchscreen Display
Credit Card Terminal
Credit Card Reader
Computer System (i.e. SBC-1)
X
X
Ticket Magnetic Encoder and Printer
(MKV)
Thermal Direct Printer
X
X
Feed/Cut Unit
X
X
Magnetic Encoder
X
X
Coin System
Coin Acceptor
X
Coin Verifier
X
Coin Diverter
X
ACM Return Channel
X
Coin Controller Board
X
Coin Magazine Drawer
X
Coin Chutes
X
Coin Vault
X
Banknote System
BNS maint. level 1
BNS maint. level 2
X
X
Table 1: Preventative Maintenance frequency for Machines (TVM)
Page 4 / 7
12
Fare collection
systems
The Supplier shall provide monthly updates to the schedule of planned Preventative
Maintenance activities for a forward period of three months. The schedule will include
all devices of the Supplied Equipment to be serviced with each month. The Supplier
will reschedule all Preventative Maintenance work once a month and include delayed
Preventative Maintenances in the next month’s schedule.
Preventative Maintenance visits shall be carried out between 09:00 and 17:00 Monday to Friday. The Supplier shall conduct the Preventive Maintenance activities in a
manner designed to minimise disruption to the Customer’s business.
Preventative Maintenance shall be carried out in accordance with a Checklist to be
developed and maintained by the Supplier. The Checklist will be submitted by the
Supplier to the Customer for approval (such approval not to be unreasonably withheld). At the time of the Start Date, the agreed Checklist for the Machines is defined
in Appendix 1. The Checklist will specify all checks and Preventative Maintenance
activities to be carried out by the Maintenance Engineer at the devices during each
visit. The Maintenance Engineer will record the results of all checks and activities on
the Checklist.
Defects discovered with the device whilst carrying out the checks shall be rectified by
the Maintenance Engineer at that visit wherever practical. In the event that Defects
cannot be rectified at the scheduled visit then they shall be recorded for handling under Remedial Maintenance.
The Supplier shall retain Checklist records (as part of the Audit records) for every
maintenance visit and shall make these available upon request to the Customer.
shall be made available to the Customer upon request.
Page 5 / 7
Fare collection
systems
2
Spare Parts and Consumables
Where the Customer chooses to purchase additional spare parts, such spare parts
will be provided by the Supplier and paid for by the Customer in accordance with the
Supplier’s spare parts price list in force from time to time.
Consumables shall be charged to the Customer in accordance with Supplier’s standard scale of Consumables in force from time to time. The following parts are
defined as Consumables:
1. Backlight components of LCD screen
2. Print head
3. Blade of Cutter device of ticket system
4. Belts, ribbons, cables, connectors, and rubber traction rollers in general
5. Hard Drives
6. Magnetic Encoding/Decoding Head
7. Fuses
8. Bulbs in lighting top, coin drop, etc.
9. Blowers (CPU, screen, computer units)
10. Batteries (i.e., CMOS, ZCGVA, UPS)
11. Tickets
12. Any consumable for third party components as described within the
third party documentation/manual.
The offered price does not include any Spare parts or Repair. The Supplier’s Spare
parts and Repair list in force, which may be updated from time to time by the Supplier, will be valid for any Spare parts and/or Repair services required by the Customer.
If requested by the Customer the Supplier will provide an estimate, for budgetary
purposes only, for spare parts likely to be needed and repair costs. The actual cost,
according to the Supplier’s Spare parts and Repair list, may be lower or higher.
Based on the actual yearly cost such estimate may be mutually reviewed on a yearly
basis.
Page 6 / 7
Fare collection
systems
3
Appendix 1, Preventative Maintenance Checklist
for TVM
Page 7 / 7
Fare collection
systems
10.2
Software Licenses
Page 108
Appendix 2
Microsoft Software License Terms for Windows® XP Embedded Runtime
These license terms are an agreement between you and Scheidt & Bachmann. Please read them. They
apply to the software included on the devices to be delivered under the Agreement between you and
Scheidt & Bachmann. The software also includes any separate media on which you received the software.
The software on the devices to be delivered under the Agreement includes software licensed from
Microsoft Corporation or its affiliate.
The terms also apply to any Microsoft
•
Updates,
•
Supplements,
•
Internet-based services, and
•
Support services
for this software, unless other terms accompany those items. If so, those terms apply. If you obtain
updates or supplements directly from Microsoft, then Microsoft, and not Scheidt & Bachmann, licenses
those to you.
As described below, using some features also operates as your consent to the transmission of certain
standard computer information for Internet-based services.
By using the software, you accept these terms. If you do not accept them, do not use or copy the
software. Instead, contact Scheidt & Bachmann to determine its return policy for a refund or credit.
If you comply with these license terms, you have the rights below.
1. Use Rights.
You may use the software on the device with which you acquired the software.
2. Additional Licensing Requirements and/or Use Rights.
a. Specific Use. Scheidt & Bachmann designed the devices to be delivered under the Agreement for a
specific use. You may only use the software for that use.
b. Other Software. You may use other programs with the software as long as the other programs
•
Directly support the manufacturer’s specific use for the device, or
•
Provide system utilities, resource management, or anti-virus or similar protection.
Software that provides consumer or business tasks or processes may not be run on the device. This
includes email, word processing, spreadsheet, database, scheduling and personal finance software.
The device may use terminal services protocols to access such software running on a server.
c.
Device Connections.
•
You may use terminal services protocols to connect the device to another device running
business task or processes software such as email, word processing, scheduling or
spreadsheets.
•
You may allow up to ten other devices to access the software to use
•
File Services,
•
Print Services,
•
Internet Information Services, and
•
Internet Connection Sharing and Telephony Services.
Updated 5/2011
The ten connection limit applies to devices that access the software indirectly through
“multiplexing” or other software or hardware that pools connections. You may use unlimited
inbound connections at any time via TCP/IP.
3. Scope of License. The software is licensed, not sold. This agreement only gives you some rights to
use the software. Scheidt & Bachmann and Microsoft reserve all other rights. Unless applicable
law gives you more rights despite this limitation, you may use the software only as expressly
permitted in this Agreement. In doing so, you must comply with any technical limitations in the
software that allow you to use it only in certain ways. For more information, see the software
documentation or contact Scheidt & Bachmann. Except and only to the extent permitted by
applicable law despite these limitations, you may not:
•
Work around any technical limitations in the software;
•
Reverse engineer, decompile or disassemble the software;
•
Make more copies of the software than specified in this agreement;
•
Publish the software for others to copy;
•
Rent, lease or lend the software; or
•
Use the software for commercial software hosting services.
Except as expressly provided in this Agreement, rights to access the software on the devices to be
delivered under the Agreement do not give you any right to implement Microsoft patents or other
Microsoft intellectual property in software or devices that access the devices to be delivered under the
Agreement.
You may use remote access technologies in the software such as Remote Desktop to access the
software remotely from another device. You are responsible for obtaining any licenses required for use
of these protocols to access other software.
•
Remote Boot Feature. If the Scheidt & Bachmann enabled the device Remote Boot feature of the
software, you may
(i) use the Remote Boot Installation Service (RBIS) tool only to install one copy of the software
on your server and to deploy the software on licensed devices as part of the Remote Boot
process; and
(ii) use the Remote Boot Installation Service only for deployment of the software to devices as
part of the Remote Boot process; and
(iii) download the software to licensed devices and use it on them.
For more information, please refer to the device documentation or contact Scheidt & Bachmann.
•
Internet-Based Services. Microsoft provides Internet-based services with the software. Microsoft
may change or cancel them at any time.
a. Consent for Internet-Based Services. The software features described below connect to
Microsoft or service provider computer systems over the Internet. In some cases, you will not
receive a separate notice when they connect. You may switch off these features or not use them.
For more information about these features, visit
http://www.microsoft.com/windowsxp/downloads/updates/sp2/docs/privacy.mspx.
By using these features, you consent to the transmission of this information. Microsoft does
not use the information to identify or contact you.
b. Computer Information. The following features use Internet protocols, which send to the
appropriate systems computer information, such as your Internet protocol address, the type of
operating system, browser and name and version of the software you are using, and the language
code of the device where you installed the software. Microsoft uses this information to make the
Internet-based services available to you.
•
Web Content Features. Features in the software can retrieve related content from
Microsoft and provide it to you. To provide the content, these features send to Microsoft
the type of operating system, name and version of the software you are using, type of
Updated 5/2011
browser and language code of the device where the software was installed. Examples of
these features are clip art, templates, online training, online assistance and Appshelp.
These features only operate when you activate them. You may choose to switch them off
or not use them.
•
Digital Certificates. The software uses digital certificates. These digital certificates
confirm the identity of Internet users sending X.509 standard encrypted information. The
software retrieves certificates and updates certificate revocation lists. These security
features operate only when you use the Internet.
•
Auto Root Update. The Auto Root Update feature updates the list of trusted certificate
authorities. You can switch off the Auto Root Update feature.
•
Windows Media Player. When you use Windows Media Player, it checks with Microsoft
for
•
•
Compatible online music services in your region;
•
New versions of the player; and
•
Codecs if your device does not have the correct ones for playing content. You can
switch off this feature. For more information, go to:
http://microsoft.com/windows/windowsmedia/mp10/privacy.aspx.
Windows Media Digital Rights Management. Content owners use Windows Media
digital rights management technology (WMDRM) to protect their intellectual property,
including copyrights. This software and third party software use WMDRM to play and
copy WMDRM-protected content. If the software fails to protect the content, content
owners may ask Microsoft to revoke the software’s ability to use WMDRM to play or
copy protected content. Revocation does not affect other content. When you download
licenses for protected content, you agree that Microsoft may include a revocation list with
the licenses. Content owners may require you to upgrade WMDRM to access their
content. Microsoft software that includes WMDRM will ask for your consent prior to the
upgrade. If you decline an upgrade, you will not be able to access content that requires
the upgrade. You may switch off WMDRM features that access the Internet. When these
features are off, you can still play content for which you have a valid license.
c. Misuse of Internet-based Services. You may not use these services in any way that could
harm them or impair anyone else’s use of them. You may not use the services to try to gain
unauthorized access to any service, data, account or network by any means.
4. Windows Update Agent (also known as Software Update Services). The software on the device
includes Windows Update Agent (“WUA”) functionality that may enable your device to connect to and
access updates (“Windows Updates”) from a server installed with the required server component.
Without limiting any other disclaimer in this Microsoft Software License Terms or any EULA
accompanying a Windows Update, you acknowledge and agree that no warranty is provided by MS,
Microsoft Corporation or their affiliates with respect to any Windows Update that you install or
attempt to install on your device.
5. Product Support. Contact Scheidt & Bachmann for support options. Refer to the support number
provided with the device.
6. Backup Copy. You may make one backup copy of the software. You may use it only to reinstall the
software on the device.
7. Proof Of License. If you acquired the software on the device, or on a disc or other media, a genuine
Certificate of Authenticity label with a genuine copy of the software identifies licensed software. To
be valid, this label must be affixed to the device, or included on or in Scheidt & Bachmann’s software
packaging. If you receive the label separately, it is not valid. You should keep the label on the device
or packaging to prove that you are licensed to use the software. To identify genuine Microsoft
software, see http://www.howtotell.com.
8. Transfer to a Third Party. You may transfer the software only with the device, the Certificate of
Authenticity label, and these license terms directly to a third party. Before the transfer, that party must
Updated 5/2011
agree that these license terms apply to the transfer and use of the software. You may not retain any
copies of the software including the backup copy.
9. Not Fault Tolerant. The software is not fault tolerant. Scheidt & Bachmann installed the
software on the device and is responsible for how it operates on the device.
10. Restricted Use. The Microsoft software was designed for systems that do not require fail-safe
performance. You may not use the Microsoft software in any device or system in which a malfunction
of the software would result in foreseeable risk of injury or death to any person. This includes
operation of nuclear facilities, aircraft navigation or communication systems and air traffic control.
11. No Warranties for the Software. The software is provided “as is”. You bear all risks of using it.
Microsoft gives no express warranties, guarantees or conditions. Any warranties you receive
regarding the device or the software do not originate from, and are not binding on, Microsoft or
its affiliates. When allowed by your local laws, Scheidt & Bachmann and Microsoft exclude
implied warranties of merchantability, fitness for a particular purpose and non-infringement.
12. Liability Limitations. You can recover from Microsoft and its affiliates only direct damages up
to two hundred fifty U.S. Dollars (U.S. $250.00). You cannot recover any other damages,
including consequential, lost profits, special, indirect or incidental damages.
This limitation applies to:
•
Anything related to the software, services, content (including code) on third party internet
sites, or third party programs; and
•
Claims for breach of contract, breach of warranty, guarantee or condition, strict liability,
negligence, or other tort to the extent permitted by applicable law.
It also applies even if Microsoft should have been aware of the possibility of the damages. The
above limitation may not apply to you because your country may not allow the exclusion or
limitation of incidental, consequential or other damages.
13. Export Restrictions. The software is subject to United States export laws and regulations. You must
comply with all domestic and international export laws and regulations that apply to the software.
These laws include restrictions on destinations, end users and end use. For additional information, see
www.microsoft.com/exporting.
Updated 5/2011
®
ORACLE End User License Agreement
®
With respect to embedded ORACLE programs and/or services which are distributed to __________ (the “End
User”) hereunder, the End User, by operation of the Scheidt & Bachmann system, agrees to the following
®
specific ORACLE End User License Requirements:
(1)
Use of the programs that are subject to this End User License Agreement is limited to ______________
®
as an executor of the End User License Agreement; if End User rejects this ORACLE End User License
®
®
Agreement, ORACLE does not grant End User license to use the ORACLE Embedded Software
included in the Scheidt & Bachmann system. In that case End User shall not be entitled to use
®
ORACLE Embedded Software together with the delivered system.
(2)
Use of the programs is restricted to the scope of the application package licensed hereunder and to the
internal business operations of the End User; the scope of the expressly permitted business operations
referred to herein is the management of fare collection equipment in the scope of S&B ‘Fare Collection
Systems’ delivered by Scheidt & Bachmann to the End User;
(3)
ORACLE , Scheidt & Bachmann or its licensor’s retain all ownership and intellectual property rights to
the programs;
(4)
Under this End User License Agreement, certain prohibitions and limitations apply to the End User,
which include, but are not limited to those expressly set out herein. In the event of any doubts regarding
the End Users’ rights under this End User License Agreement, the End User shall only contact Scheidt &
Bachmann clarification.
(5)
the following is specifically prohibited:
®
(a) transfer of the programs except for temporary transfer in the event of computer malfunction if the
application package embeds the programs in a physical device;
(b) assigning, giving, or transferring the programs and/or any services ordered or an interest in them to
another individual or entity (and if End User grants a security interest in the programs and/or any
services, the secured party has no right to use or transfer the programs and/or any services);
(c) installation or configuration of the programs separately and independently from the application
package;
(d) access to the programs (by means of embedded tools or any other means) other than through the
application program of Scheidt & Bachmann;
(e) database maintenance other than through a shell application provided by Scheidt & Bachmann;
®
(f) direct access of the database or use of ORACLE supplied API’s for any purposes (including, but not
limited to, the purpose of establishing the transfer of data);
(g) use of the programs for rental, timesharing, subscription service, hosting, or outsourcing;
(h) the removal or modification of any program markings or any notice of Oracle’s or its licensors’
proprietary rights;
(i) making the programs available in any manner to a third party for its use in the third party’s business
operations (unless such access is expressly permitted for the specific program license); and
(j) title to the programs passing to the End User or any other party;
(6)
The End User shall not review any data or run any ad-hoc query report through a script not
preconfigured by Scheidt & Bachmann and as part of the application package. For greater certainty, all
information from the programs shall only be accessed by the End User either through pre-packaged
reports, or ad-hoc reports that are developed by Scheidt & Bachmann and which are included in the
application package, and which do not require or permit the End User to navigate the underlying data
scheme.
(7)
In the event that the End User has been provided with a web-interface, the End User shall not be
allowed to change the web pages if this would be in violation of the End User’s general obligation not to
navigate the underlying data scheme.
(8)
The End User shall not be allowed to request to add an interface to Scheidt & Bachmann’s application
package unless the End User specifically declares that such interface is non-proprietary to the End User
and Scheidt & Bachmann determines in its sole discretion that the interface can be added to its standard
software.
(9)
Reverse engineering (unless required by law for interoperability), disassembly or decompilation of the
programs as well as the duplication of the programs except for a sufficient number of copies of each
program for the End User’s licensed use and one copy of each program media are prohibited (the
foregoing prohibitions include but are not limited to review of data structures or similar materials
produced by programs);
(10)
The End User is further not allowed to:
®
(a) update the embedded ORACLE Software (e.g. by raising the revision level or by downloading
patches) without the involvement of, and written approval by, Scheidt & Bachmann;
®
(b) upgrade to any other ORACLE license without the express written permission of Scheidt &
Bachmann;
®
®
maintenance support directly from ORACLE ; Maintenance Support
for
(c) receive ORACLE
®
embedded ORACLE software shall be received from Scheidt & Bachmann.
(11)
To the extent permitted by applicable law, ORACLE disclaims its liability for any damages, whether
direct, indirect, incidental, special, punitive or consequential, arising from the use of the programs, and
(b) any loss of profits, revenue, data or data use, arising from the use of the programs;
(12)
Upon termination of this ORACLE End User License Agreement, End User is required to discontinue
use and destroy or return to Scheidt & Bachmann all copies of the programs and documentation;
(13)
Publication of any results of benchmark tests run on the programs are prohibited;
(14)
End User is required to comply fully with all relevant export laws and regulations of the United States
and other applicable export and import laws to assure that neither the programs, nor any direct product
thereof, are exported, directly or indirectly, in violation of applicable laws;
(15)
End User is notified that the programs are subject to a restricted license and can only be used in
conjunction with the application package. End User is not permitted to modify the programs;
(16)
End User shall not require ORACLE to perform any obligations or incur any liability not previously
®
agreed to between Scheidt & Bachmann and ORACLE ;
(17)
Scheidt & Bachmann shall be permitted to audit End User’s use of the program, and the End User shall
provide reasonable assistance or access to information in the course of such audit and permit Scheidt &
®
Bachmann to report the audit results to ORACLE . Alternatively, Scheidt & Bachmann may choose to
®
®
assign its right to audit the End User’s use of the programs to ORACLE . Neither ORACLE nor Scheidt
& Bachmann shall be responsible for any of End User`s costs incurred in cooperating with the audit;
(18)
ORACLE is designated as a third party beneficiary of the end user license agreement;
(19)
The Uniform Computer Information Transactions act is not applicable;
(20)
Some programs may include source code that ORACLE may provide as part of its standard shipment of
such programs, which source code shall be governed by the terms of the End User License Agreement.
(21)
Third party technology that may be appropriate or necessary for use with some ORACLE programs is
specified in the application package documentation or as otherwise notified by Scheidt & Bachmann.
Such third party technology is licensed to end user only for use with the application package under the
terms of the third party license agreement specified in the application package documentation or as
otherwise notified by Scheidt & Bachmann and not under the terms of the end user license agreement.
®
®
®
®
®
®
Status 10/2012
SCHEIDT & BACHMANN USA, INC.
31 NORTH AVENUE, BURLINGTON, MA
SOFTWARE LICENSE AGREEMENT
Licensee Name:
Licensee State of Incorporation:
Licensee Address:
Effective Date:
[Insert Date Agreement is executed]
Licensed Software (name, version,
and release - list or reference
separate schedule, if necessary):
Third Party Software (list or
reference separate schedule, if
necessary):
This Software License Agreement (“Agreement”) sets forth the terms and conditions on which Scheidt &
Bachmann USA, Inc. (“Licensor”), a Delaware corporation with offices at 31 North Avenue, Burlington,
Massachusetts, grants and [Licensee Name] (“Licensee”), a [Licensee state] corporation, accepts, a
license as set forth herein to use the Licensed Technology. In consideration of the mutual covenants and
agreements set forth herein, Licensor and Licensee agree to all of the provisions of this Agreement,
including the provisions of this Cover Page, the Software License Terms and Conditions attached hereto,
and any schedules and exhibits attached hereto, or documents expressly referenced above or described
herein, all of which are incorporated by reference herein, and all of which together constitute the
Agreement.
Accordingly, intending to be legally bound, Licensor and Licensee have executed this Agreement as of
the Effective Date set forth above.
[Licensee Name]
Scheidt & Bachmann USA, Inc.
By:____________________________
Name:
Title:
By:____________________________
Name:
Title:
LIBC/4295358.5
SOFTWARE LICENSE TERMS AND CONDITIONS
protection law, trade secret law, trademark
law, and any and all similar proprietary
rights, including without limitation, all
applications and registrations relating to
the foregoing. The term “Intellectual
Property Rights” includes such rights as
they exist as of the execution of this
Agreement, and all such rights as
subsequently acquired by a party to this
Agreement during the Term. Reference in
this Agreement to Licensor owned
Intellectual Property Rights, shall also
include Intellectual Property Rights owned
by Licensor’s parent company.
1. Definitions.
For all purposes of this
Agreement, the terms defined below, when used
with initial capital letters, shall have the
following meanings:
(a)
“Bit Pattern” means a specific defined bit
organization with bit value definitions,
containing information regarding the
position, organization, grouping, and
meaning of different fields in the memory
of a fare medium now in existence or
developed in the future, including, but not
limited to, a smart card or magnetic ticket.
(b)
“Change of Control” with respect to a
person means a sale of all or substantially
all the assets of such person or a merger,
sale of stock, or other transaction in which
one person or a group of persons acting in
concert acquire at least a majority of the
equity interests and voting power in such
person.
(c)
“Contract
Documents”
[__________].
(d)
“Cover Page” means the first page of this
Agreement, containing information with
respect to Licensee and the License, and
bearing the signatures of the parties.
(e)
“Documentation” means the standard user
manuals and standard operator instructions
issued by Licensor in conjunction with the
Licensed Software, and shall specifically
exclude any source code, source code
printouts, flow charts, software listings,
systems documentation, and programming
documentation.
(f)
“Effective Date” means the Effective Date
set forth on the Cover Page.
(g)
“Escrow Agreement” means the Iron
Mountain Three-Party Master Escrow
Service Agreement (Deposit Account No.
[__]).
(h)
“Intellectual Property Rights” means any
rights which exist now or shall exist in the
future under copyright law, patent law,
industrial design rights law, semiconductor
production law, data and database
LIBC/4295358.5
(i)
“License” means the license granted by
Licensor to Licensee as provided in
Section 2.
(j)
“Licensee” means the entity identified on
the Cover Page as the Licensee.
(k)
“Licensed
Software”
means
the
proprietary computer software program(s)
identified as “Licensed Software” on the
Cover Page, including any maintenance
releases, bug fixes, or other changes made
to the Licensed Software that are delivered
to Licensee by Licensor under this
Agreement and/or the System Contract.
[Licensed Software shall not include any
Third Party Software delivered by
Licensor to Licensee for which Licensee
must procure a license to use such
software from the licensor thereof prior
to any use of such software with the
Licensed Software.]
(l)
“Licensed Technology” means the
Licensed Software and the Documentation.
means
(m) “Licensee’s Public Transit System” shall
mean the regional public transit system
operated by Licensee in [location], for
which Licensor supplies and installs the
Licensor System in accordance with the
System Contract.
(n)
“Licensor Proprietary Information” has the
meaning set forth in Section 12(b)(i).
(o)
(p)
“Fare Medium Encoding Format End
Product” means the encoding Bit Pattern
representing the corresponding unique
definition of how to apply the Bit Pattern
to Licensee’s tariff system.
(q)
“System Contract” means the contract
entered into between Scheidt & Bachmann
USA, Inc. and the Licensee, for the supply
and installation of the Licensor System as
means of fare collection in the Licensee’s
Public Transit System.
(r)
“Term” means the period commencing on
the Effective Date and continuing until
termination of this Agreement.
(s)
“Territory” means the territory of [_____].
(t)
“Third Party Software” means the
software referenced on the Cover Page as
Third Party Software and other software
developed by third parties, including
standard commercially available software,
required to be provided under the System
Contract and/or this Agreement, and all
documentation concerning such software.
2.
(a)
(ii)
“Licensor System” means the [Scheidt &
Bachmann Automated Fare Collection
System] substantially specified in the
System Contract and that is to be used as a
means of fare collection in the Licensee’s
Public Transit System.
(iii) To use the Documentation as
reasonably necessary for its internal
use related to the License granted
under subsection 2(a)(i) above, except
that prior to the disclosure of any
Documentation to its employees, the
Licensee requires that each such
employee be instructed with regard to
this Agreement, read this Agreement,
and comply with the terms of this
Agreement.
License.
License Grant. Subject to the terms and
conditions of this Agreement, and as of the
Effective Date, Licensor grants to Licensee
solely within the Territory a non-exclusive,
non-transferable, perpetual, limited right
and license during the Term hereof as
follows:
(i)
To install and use the Licensed
Software in object code form only as
delivered pursuant to this Agreement
and/or the System Contract and
consistent with the use limitations of
Section 2(c) for the purposes of the
operation and use of the Licensor
System
in
conjunction
with
Licensee’s Public Transit System;
2
LIBC/4295358.5
To make one (1) additional copy of
the
Licensed
Software
and
Documentation for back-up or
archival purposes; and
(b)
Reserved Rights. Any rights not expressly
granted in Section 2(a) are reserved by
Licensor.
Without limitation of the
foregoing, Licensor reserves the right to
license the Licensed Technology to others
on such terms as Licensor may establish in
its sole discretion. Licensee acknowledges
that no exclusive right of any kind is
granted to Licensee by the terms of this
Agreement.
Licensee shall promptly
notify Licensor of any infringement or
violation of Licensor’s Intellectual
Property Rights that come to the attention
of Licensee.
(c)
Limitations and Restrictions.
It is
expressly understood and agreed that the
License is subject to the following
limitations and restrictions:
(i)
Licensee may not use the Licensed
Software except as specified in the
System Contract, and solely for the
purposes of the operation and use of
the Licensor System in conjunction
with the Licensee’s Public Transit
System.
(ii)
Licensee may not distribute the
Licensed Technology, or any copy
thereof, by transfer, lease, loan or any
other means, or make it available for
use by others in any manner,
including without limitation by any
time-sharing, service bureau or
similar arrangement.
Technology shall be deemed accepted by
Licensee in accordance with the acceptance and
testing procedures adopted in the Contract
Documents, as may be modified in writing from
time to time.
(iii) Licensee shall not remove, obliterate,
obscure, or conceal the proprietary
notices or legends which appear on
the Licensed Technology, and shall
reproduce such notices or legends on
all
copies
of
the
Licensed
Technology, or of any part of the
Licensed Technology, made under
Section 2(a)(ii).
4.
(a)
(iv) Licensee has no right to obtain or
have access to the source code or
systems
and
programming
documentation of the Licensed
Software or any part thereof. The
Licensed
Technology
and
all
information related thereto shall be
subject to Licensee’s obligations of
confidentiality under Section 12(b).
(v)
5.
Licensee may not alter, modify, adapt
or create derivative works from the
Licensed Technology, and shall
further use all due diligence to protect
the Licensed Technology from such
alterations,
modifications,
or
adaption. Licensee may not, and may
not permit any third party to,
decompile, disassemble, translate, or
otherwise reverse engineer the
Licensed Software or any part
thereof.
(vi) Licensee is required to purchase a
separate license for each copy of the
Licensed Software it installs in
accordance with the System Contract.
For avoidance of doubt, Licensee is
required to purchase a separate
license to install the Licensed
Software in connection with testing or
training facilities.
(vii) Except as otherwise expressly set
forth in this Agreement, no other
rights in the Licensed Technology are
granted.
3. Delivery and Acceptance. Licensor shall
deliver to Licensee the Licensed Technology in
accordance with the project schedule adopted in
the Contract Documents, as may be modified in
writing from time to time, and the Licensed
3
LIBC/4295358.5
Consideration.
Consideration. In consideration of the
License granted under Section 2(a),
Licensee agrees to pay any fees mutually
agreed upon in the Contract Documents in
accordance with the terms set forth therein.
Other Obligations of Licensee.
(a)
Installation, Maintenance and Other
Services. Except as otherwise provided in
a separate service or maintenance
agreement between the parties, or in the
System Contract, Licensee shall be solely
responsible for its installation and use of
the Licensed Software, and Licensor shall
have no obligation or responsibility with
respect thereto.
(b)
Consulting Services.
This license
agreement does not provide for any
consulting services.
Any consulting
services provided by Licensor are
governed by a separate written services
agreement, or by the System Contract.
(c)
Recordkeeping and Access.
Licensee
agrees to maintain reasonable records with
respect to its installation and use of the
Licensed Software, including without
limitation records identifying the computer
on which the Licensed Software is
installed from time to time and identifying
all individuals having access to the
Licensed Software, and to retain all such
records for a period of at least six (6) years
from the date of their creation. Licensee
shall make such records and the computer
on which the Licensed Software is
installed available for inspection by
Licensor or its representatives at any time
during normal business hours upon
request. Licensee shall promptly pay
Licensor any applicable fees identified in
the Contract Documents at Licensor’s then
current rates, and related finance charges
as provided in the Contract Documents for
Format End Product to a third party(s) under a
license agreement in which Licensee retains its
ownership rights in the Fare Medium Encoding
Format End Product.
Any such license
agreement shall be on terms not less restrictive
than the terms in this Agreement, and shall
obligate the third party to acknowledge that it
does not obtain any ownership rights in
Licensor’s
Intellectual
Property
Rights.
Licensor retains ownership rights to the
magnetic ticket encoding, smart card encoding
or other encoding Bit Pattern development
process, to the process for implementing the
Standardized Encoding Format into a fare
collection system, to any derivation of this Bit
Pattern and to the definition of how to apply any
derived Bit Pattern to any tariff system other
than Licensee’s tariff system.
Upon final
acceptance and receipt of all payments due
under the System Contract, Licensor shall
transfer to Licensee ownership of and complete
responsibility for the unique security
mechanisms, including security encryption keys,
if applicable, and unique identifiers in the Fare
Medium Encoding Format End Product.
any reproduction, installation, use or
distribution of the Licensed Technology in
excess of the rights conferred under the
License. Licensee shall also pay Licensor
its expenses for any such inspection which
discloses underpayment of amounts due to
Licensor greater than ten percent (10%) of
the fees identified in the Contract
Documents.
(d)
Export Control Compliance. Licensee
understands that the Licensed Technology
and the information contained therein are
subject to restrictions on export under the
Export Administration Regulations of the
U.S. Bureau of Export Administration and
other applicable laws, in addition to
restrictions imposed by this Agreement.
Licensee agrees to comply with all such
restrictions at all times.
(e)
Notice of Certain Events. Licensee agrees
to give prompt written notice to Licensor if
at any time Licensee becomes aware that
any person has received, used, or had
access to any Licensor Proprietary
Information in violation of Licensor’s
rights therein.
8.
(a)
6. Source Code. For avoidance of doubt, the
licenses granted hereunder to the Licensed
Software are limited to the object code of the
software, and no source code whatsoever will be
provided to the Licensee under this Agreement.
Escrow of source code material will be
established in accordance with the terms of the
Escrow Agreement. Licensor shall not be
responsible
for
updating,
maintaining,
escrowing, troubleshooting, or documenting
software that has been altered by Licensee or by
any third party.
7. Standardized Encoding Format. If the
System Contract requires Licensor to supply
Standardized Encoding Formats for the installed
Licensor System, then upon final acceptance and
receipt of all payments due under the System
Contract, Licensor shall transfer to Licensee
ownership of the Fare Medium Encoding Format
End Product. For the avoidance of doubt, the
System Contract shall not require the Licensor
provide Standard Encoding Formats. Licensee
shall only deliver the Fare Medium Encoding
4
LIBC/4295358.5
Third Party Software.
Third Party Licenses.
Licensor shall
obtain all requisite licenses to Third Party
Software (“Third Party Licenses”) as
required under the System Contract, and
Licensee shall make reasonable efforts to
procure Third Party Licenses that permit
the Third Party Software to be installed
and used as part of the Licensor System.
Use of any Third Party Software shall be
subject to the license conditions of the
respective third party that owns the Third
Party Software. Licensor shall not be liable
for damages arising from use of Third
Party Software or by Licensee’s failure to
use Third Party Software in accordance
with the relevant Third Party License.
Upon request, Licensor shall provide
Licensee with evidence of such Third
Party Licenses and requisite rights. The
number of licenses for Third Party
Software is specifically limited to the
number required in the System Contract.
Licensee acknowledges that no Intellectual
Property Rights will be transferred to the
Licensee in relation to the Third Party
Software.
To the extent that Licensor
requires access to additional Third Party
Software in order to comply with the terms
of the Contract Documents or any
warranty obligations with respect to the
Licensor System, components or related
equipment, Licensee shall procure the
license to such Third Party Software.
(b)
(c)
Oracle License.
With respect to
embedded ORACLE® software, the
license agreement between ORACLE®
and Licensor provides for requirements
that must be transferred to and binds
Licensee as the end user of such embedded
ORACLE®
software
under
this
Agreement. The current ORACLE® end
user license requirements are set forth
separately in [Appendix 1] hereto, and
incorporated by reference into this
Agreement. Licensee acknowledges and
agrees to the ORACLE® end user license
requirements set forth in [Appendix 1].
Licensee further agrees that these
requirements are subject to change by
ORACLE® from time to time and that the
most current version shall apply. Upon
request, Licensor shall provide the most
current version to Licensee.
Compliance With All Third Party End
User License Conditions. Licensee hereby
acknowledges and hereby agrees to
comply fully with any and all end user
license conditions of Third Party Licenses,
including without limitation the Oracle and
Microsoft end user license conditions, and
agrees to indemnify and hold harmless the
Licensor from any claims, losses, or
damages, whatsoever, resulting from or
caused by Licensee’s and/or Licensee’s
sub-licensees’ failure to comply with any
applicable end user license conditions for
Third Party Software or with any third
Party Licenses.
(e)
If Licensee wishes to modify its use any
Third Party Software, differing from that
originally required under the System
Contract, it is the responsibility of
Licensee to obtain any corresponding
licenses from the provider of the Third
Party Software.
9. No Warranties. Licensor does not make
any express or implied warranties, conditions, or
representations to Licensee, any of its affiliates
or any other party with respect to the Licensed
Technology or any services provided hereunder
or otherwise regarding this Agreement, whether
oral or written, express, implied, or statutory.
Without limiting the foregoing, any implied
warranty or condition of merchantability,
noninfringement, or fitness for a particular
purpose are expressly excluded and disclaimed
to the fullest extent allowed by law. Licensor
does not warrant that the Licensed Technology
will meet the Licensee’s requirements or
expectations, or that the Licensed Technology
will operate uninterrupted or error-free, or that
all Licensed Technology errors will be
corrected.
Microsoft License.
With respect to
embedded Microsoft software, the license
agreement between Microsoft Corporation
and Licensor provides for requirements
which must be transferred to and also
binds Licensee as the end user of such
embedded Microsoft software under this
Agreement.
The current Microsoft
requirements are set forth separately in
[Appendix 2] hereto, and incorporated by
reference into this Agreement. Licensee
acknowledges and agrees to these specific
Microsoft end user license requirements
set forth in [Appendix 2]. Licensee
further agrees that these requirements are
subject to change by Microsoft from time
to time and that the most current version
shall apply. Upon request, Licensor shall
provide the most current version to
Licensee.
10. Related Services. This Agreement does
not provide for the performance of any
installation, training, customization, support,
maintenance or other services with respect to the
Licensed Technology. Licensor shall have no
obligation to provide, and Licensee shall have
no right to receive, any such services except as
may be provided in a separate written agreement
5
LIBC/4295358.5
(d)
signed by a duly authorized officer of Licensor.
Except as set forth in a written agreement signed
by Licensor, any services performed by Licensor
for Licensee or at Licensee’s request shall be
subject to charge on a time-and-materials basis
at Licensor’s standard rates.
modify or
replace the Licensor
Technology or otherwise secure for
Licensee the right to continue using the
Licensor Technology, Licensor may
terminate this Agreement and, upon
termination, return to it of all copies of the
Licensed Technology licensed hereunder
and all remedies and recourse shall be
subject to the terms set forth in the
Contract Documents. Notwithstanding the
foregoing, the foregoing defense and
indemnity obligations shall not apply to
any Claim based upon or arising from
(a) use of the Licensed Software in a
manner for which it was not designed or
not in accordance with applicable
Documentation, (b) any modification of
the Licensed Software by any party other
than Licensor, (c) any use of the Licensed
Software in combination with hardware or
software not provided or authorized by
Licensor, or (d) use of the Licensed
Software, when use of a subsequent
software release which Licensor has made
commercially available would have
avoided such infringement.
11. Indemnification.
(a)
By Licensor. Subject to the terms set forth
in the Contract Documents, Licensor shall
defend or settle any third party suit or
proceeding brought against Licensee based
upon a claim that the Licensed Software
constitutes an infringement of any existing
and valid U.S. copyright, patent, trademark
or trade secret in the United States (any
such suit or proceeding, a “Claim”),
provided that Licensee: (i) promptly
notifies Licensor in writing of such Claim
(ii) promptly gives Licensor the right to
control and direct the investigation,
preparation, defense and settlement of such
Claim with counsel of Licensor’s own
choosing (provided that Licensee shall
have the right to reasonably participate, at
its own expense, in the defense or
settlement of any such Claim); and
(iii) gives assistance and full cooperation
for the defense of same. Subject to
Licensee’s compliance with the foregoing
requirements and further subject to Section
11(c) below, Licensor shall pay all
damages and costs awarded by a court of
competent jurisdiction against Licensee in
such Claim or amounts payable pursuant to
a settlement agreed to by Licensor, but
shall not be responsible for any cost,
expense or compromise incurred or made
by Licensee without Licensor’s prior
written consent or for any lost profits or
other damage or loss suffered by Licensee.
If any Licensor Technology is in the
opinion of Licensor likely to or does
become the subject of a claim of
infringement, Licensor may, at its sole
option, procure for Licensee the right to
continue using the Licensor Technology,
modify the affected materials to become
non-infringing, or replace it with noninfringing Licensor Technology.
If
Licensor is not reasonably able to so
6
LIBC/4295358.5
(b)
By Licensee. Licensee hereby agrees to
indemnify Licensor, and hold it harmless,
against any loss or damage that may be
suffered by Licensor, and any claims that
may be made against Licensor by a third
party, as a direct or indirect result of the
use by Licensee of the Licensed
Technology, or of any breach of
Licensee’s covenants herein.
(c)
Limitation of Liability. Licensor and its
third-party vendors shall have no liability
for any monetary damages or other relief
arising out of or related to this Agreement,
regardless of the form of action, in
contract, tort or otherwise. In any event, if
the limitation imposed by the preceding
sentence is determined to be inapplicable
or unenforceable in any particular case,
Licensor’s and its third-party vendors’
maximum total liability for all matters
arising under or related to this Agreement,
regardless of the form of action, in
contract, tort or otherwise, shall be limited
to the amount of the applicable fees paid
by Licensee in accordance with the
Contract Documents. IN ANY EVENT,
NEITHER LICENSOR NOR ANY OF
ITS THIRD-PARTY VENDORS SHALL
UNDER ANY CIRCUMSTANCES BE
LIABLE FOR ANY LOSS OF
REVENUE, LOSS OF PROFIT, LOSS OF
DATA,
SPECIAL,
INCIDENTAL,
CONSEQUENTIAL, PUNITIVE OR
OTHER INDIRECT DAMAGES IN
CONNECTION WITH ANY MATTER
ARISING UNDER OR RELATED TO
THIS
AGREEMENT,
EVEN
IF
LICENSOR WAS AWARE OF THE
POSSIBILITY OF SUCH DAMAGES.
(b)
Confidentiality.
(i)
For purposes hereof, “Licensor
Proprietary Information” shall mean
(A) the Licensed Technology and any
and all information with respect
thereto, and any and all derivative
works of the Licensed Technology,
and (B) any other information that is
disclosed by Licensor to Licensee
under or in connection with this
Agreement, in oral, written, visual,
electronic or other form, provided that
“Licensor Proprietary Information”
shall not include any such information
that (1) is generally known to the
public or in the trade, or becomes so
generally known without breach of
this Agreement by Licensee; (2) is
shown by written record to have been
known to Licensee without restriction
of confidentiality prior to its
disclosure by Licensor hereunder; or
(C) is disclosed to Licensee without
restriction of confidentiality by a third
party who is not in breach of an
obligation of confidentiality to
Licensor in making such disclosure.
(ii)
Licensee acknowledges that the
Licensor Proprietary Information
constitutes
trade
secrets
and
proprietary information of great value
to Licensor. Licensee shall keep
confidential the Licensor Proprietary
Information and all copies or physical
embodiments
thereof
in
its
possession, and shall limit access to
the Licensor Proprietary Information
to those of its personnel who (A) have
a demonstrable need for such access
in connection with Licensee’s use of
the Licensed Technology as permitted
by this Agreement and (B) have
executed
written
confidentiality
agreements establishing protection for
the Licensor Proprietary Information
reasonably
equivalent
to
the
provisions of this Section 12(b).
12. Proprietary Rights and Confidentiality.
(a)
Proprietary Rights.
The Licensed
Technology and all proprietary rights
therein, including without limitation any
and all copyrights, patents, trademarks,
and trade secret rights with respect to any
of the Licensed Technology, shall be and
remain at all times the property of
Licensor, and Licensee shall have no right,
title or interest therein except as expressly
provided herein. The foregoing shall also
apply to any derivative works of or
improvements to any of the Licensed
Technology that are made either by
Licensor or by Licensee, or by any person
under contract to either of them. Licensee
agrees to assign, and does hereby assign,
to Licensor any right, title or interest
which it may have or obtain in any
derivative works of the Licensed
Technology which it has developed or may
in the future develop, and will upon
Licensor’s request execute and deliver
such instruments of transfer and other
documents to effect, complete and confirm
such assignment. Licensee agrees that it
will not take any action to jeopardize,
limit, or interference with Licensor’s
proprietary rights. Licensee agrees not to
remove, deface, diminish, or obscure in
any way, any proprietary notices of
ownership, copyright notices, logos, and
trademarks that are contained on or in any
of the Licensed Technology.
(iii) Licensee shall not seek to reverse
engineer, reverse assemble or
7
LIBC/4295358.5
general assignment for the benefit of
creditors, or files a voluntary petition in
bankruptcy or for reorganization or
arrangement under the bankruptcy laws, or
if a petition in bankruptcy is filed against
Licensee and is not dismissed within 30
days after the filing, or if a receiver or
trustee is appointed for all or any part of
the property or assets of Licensee; (v) if
both parties sign a mutual agreement to
terminate this Agreement; or (vi) the
Licensor System supplied by Licensor to
Licensee is discontinued from service.
decompile any part of the Licensor
Proprietary Information in an attempt
to discover any of the proprietary
algorithms or techniques or other
trade secrets of Licensor embodied
therein or used in the development
thereof, and Licensee shall not allow
any of its personnel or Licensees or
any other person to do so.
(iv) Licensee shall not use any part of the
Licensor Proprietary Information in
any manner other than as expressly
authorized under this Agreement or
otherwise in writing by Licensor.
(v)
(c)
Rights and Obligations on Termination.
Upon any termination of this Agreement
the License granted under this Agreement
shall terminate, and Licensee shall
immediately cease all use of the Licensed
Technology and return to Licensor all
copies, notes, memoranda, and other
tangible embodiments of Licensor
Proprietary Information in its possession
or under its control, or destroy all such
tangible embodiments and certify such
destruction in writing to Licensor. Upon
such termination, all rights and obligations
of the parties under this Agreement shall
cease except that (i) Licensee shall remain
obligated to make any payment due or to
become due under this Agreement;
(ii) Licensee’ obligations under Section
12(b) shall continue and survive such
termination; and (iii) the provisions of
Sections 1, 5, 6, 8, 9 and 10, Section 11(b),
Section 11(c), Section 12, and this Section
13(c) shall remain in effect.
(d)
The termination of this Agreement or any
license shall not limit either party from
pursuing any other remedies available to it,
including injunctive relief.
Licensee shall secure and protect the
Licensor Proprietary Information and
any and all copies thereof in its
possession through security measures
at least as protective as those used by
Licensee to maintain the security of
its own proprietary source code and
information of a similar nature and
value, and in any event no less than a
reasonable degree of security.
13. Term and Termination.
(a)
Term. The term of the License and of this
Agreement shall commence upon the
Effective Date and shall continue until
termination of this Agreement.
(b)
Termination. Licensee shall be deemed to
be in default under this Agreement, and
Licensor may terminate this Agreement in
whole or in part by written notice to
Licensee, in the event of the occurrence of
any of the following: (i) if Licensee
violates the confidentiality provisions of
Section 12(b) of this Agreement, or uses,
reproduces, distributes or sublicenses any
of the Licensed Technology in any manner
not authorized by the License granted
herein; (ii) if Licensee assigns, attempts to
assign or is deemed to have assigned this
Agreement contrary to the provisions of
Section 14(e); (iii) if Licensee fails to
observe or perform any term or condition
of this Agreement and does not cure such
failure within 30 days after written demand
by Licensor; (iv) if Licensee makes a
14. General.
(a)
8
LIBC/4295358.5
Entire Agreement.
This Agreement
contains the entire understanding of the
parties about the license terms of the
Licensed Technology. It supersedes and
replaces all prior or contemporaneous
understandings or agreements, written or
oral, regarding such subject matter, and
prevails over any conflicting terms or
this Agreement without Licensor’s consent
shall be null and void.
conditions contained on printed forms
submitted with purchase orders, sales
acknowledgments or quotations.
(b)
Amendment. This Agreement may not be
amended or modified, in whole or part,
except by a writing signed by duly
authorized representative of both parties.
(c)
Waivers. No provision or part of this
Agreement or remedy hereunder may be
waived except by a writing signed by a
duly authorized representative of the party
making the waiver. Any such waiver shall
be narrowly construed to apply only to the
specific provision and under the specific
circumstances for which it was given, and
shall not apply with respect to any
repeated or continued violation of the same
provision or any other provision. Failure
or delay by either party to enforce any
provision of this Agreement will not be
deemed a waiver of future enforcement of
that or any other provision.
(d)
Relationship of Parties. Nothing in this
Agreement shall be construed to place
Licensor and Licensee in an agency,
employment, franchise, joint venture, or
partnership relationship. Neither party will
have the authority to obligate or bind the
other in any manner, and nothing herein
contained shall give rise or is intended to
give rise to any rights of any kind to any
third parties. Neither party will represent
to the contrary, either expressly, implicitly
or otherwise.
(e)
Assignment; Change of Control. Licensee
may not assign this Agreement, or
sublicense, transfer, sell, assign, or
distribute any of the rights granted herein,
in whole or in part, without the prior
written consent of Licensor, which consent
may be withheld at the sole discretion of
Licensor. For purposes of the foregoing, a
Change of Control with respect to
Licensee shall be deemed to be an
assignment, and shall give rise to
Licensor’s right to terminate this
Agreement under Section 13(b).
Any
attempt by Licensee to assign or transfer
any of the rights, duties or obligations of
9
LIBC/4295358.5
(f)
Severability.
In the event that any
provision of this Agreement is found to be
unenforceable, such provision will be
reformed only to the extent necessary to
make it enforceable, and such provision as
so reformed will continue in effect, to the
extent consistent with the intent of the
parties as of the Effective Date. If any
provision or part of this Agreement will, to
any extent, be or become invalid, illegal or
unenforceable, the remainder of this
Agreement will continue in effect, and
every other provision of this Agreement
will remain valid and enforceable to the
full extent permitted by applicable law. In
such event, the invalid or unenforceable
provision shall be reformed only to the
extent necessary to make it enforceable,
and such provision as so reformed will
continue in effect, to the extent consistent
with the intent of the parties as of the
Effective Date.
(g)
Remedies. The remedies provided herein
are cumulative, and may be exercised
either successively or concurrently. The
parties acknowledge that any breach of the
conditions and restrictions contained in
this Agreement may cause irreparable
harm to a party, and/or third parties, and
that monetary damages would not be
adequate protection in certain cases. It is
therefore agreed that any party affected by
any such breach may seek injunctive or
other equitable relief, as appropriate, from
a court in the event of such breach.
(h)
Force Majeure. Neither party shall be
liable to the other party for failure or delay
in performance of any obligation under
this Agreement, directly or indirectly,
owing to war, acts of terrorism, natural
disasters, embargoes, riots, strikes, and
other events beyond its control. In the
event that such failure or delay occurs, the
affected party shall notify as soon as
possible the other party of the occurrence
thereof, and the parties shall negotiate in
good faith a fair resolution to the failure or
delay in performance.
(i)
Notices. All notices under or related to
this Agreement will be in writing and will
reference this Agreement. Notices will be
deemed
given
when:
(i) delivered
personally; (ii) sent by confirmed telecopy
or other electronic means; (iii) three (3)
days after having been sent by registered
or certified mail, return receipt requested,
postage prepaid; or (iv) one (1) day after
deposit with a commercial overnight
carrier, with written verification of receipt.
All communications will be sent to the
addresses set forth on the Cover Page or
such other addresses designated pursuant
to this Section 14(i).
(j)
Governing Law. This Agreement is made
under and will be governed by and
construed in accordance with the laws of
the Commonwealth of Massachusetts,
without regard to its conflict of laws
principles, and specifically excluding from
application to this Agreement the United
Nations Convention on the International
Sale of Goods.
(k)
Jurisdiction. Any legal proceedings under
or related to this Agreement shall be
subject to the exclusive jurisdiction of the
state and federal courts located in the
Commonwealth of Massachusetts. Each
party submits to the personal jurisdiction
of, and waives any objection against
jurisdiction by, such courts.
(l)
Counterparts. This Agreement may be
executed in two or more counterparts, each
of which will be deemed an original, but
all of which will constitute but one and the
same instrument.
10
LIBC/4295358.5
Fare collection
systems
10.3
Escrow Agreement
Page 109
Fare collection
systems
10.4
CDRLS
10.4.1
CDRL 704 – Monthly Report (Draft)
Page 110
PROJECT NAME
MONTHLY STATUS REPORT FOR: MONTH YEAR
Project Details
Project Number:
x 47 yy yyy
Overall Project Status
11
Total Percentage of all Levels (refers to Prince2 Performance Measurement System)
Project Description:
Description
Report Date:
Date
Report Distribution:
Names
Last Updated By:
Project Manager
..%
Project Status:
Indicator
Status
Milestones
Comment
Status of Milestones
*****
Customer satisfaction
Short description of customer situation
***
Management Summary
Brief description
Project Milestones
Description
Baseline
End date
Forecast
End date
Complete
End date
Comment
Final Design Approval
Factory Acceptance Testing
Start Delivery
Final Acceptance
Project time extension per Change Order
Date of latest released Project Schedule
Planned next two Board Meetings (Date)
DRAFT CDRL 703 - Monthly Report
FCS PM Template Vs. 2.0
created: YYYY-MM-DD
page: 1/3
Existing Problems and issues
Numbering
Description
Corrective Actions
Description……….
Owner
Date of occurrence
Prime Risks
No. of risks with
tolerance > 125
Risk-ID
SB-RISK-0001
0
Number of mitigation plans
in place
Description
Mitigation
0
Owner
Proximity
SB-RISK-0002
Main Tasks for Next four weeks
Task
Dated
Assigned
Task 1
Wk 46/47
Customer
Wk 47
S&B
Task 2
---- END OF Report ----
created: YYYY-MM-DD
page: 2/3
Colour Scheme definition:
For Milestones:
delay (month) to
baseline not
covered by CO*
<=0
<1
<2
<3
>=3
For Project Budget:
Covered by Co?
n
n
n
n
n
Status
Budget of your project
Status
Below budget
in tolerance
<5% out of budget
<10% out of budget
>10% out of budget
*****
****
***
**
*
*****
****
***
**
*
*A new baseline can be established by change order or by written approval of customer.
For Risks:
For Customer satisfaction:
For risks we will provide two figures only from
now on:
Number of Risks beyond risk tolerance
Number of mitigation plans in place
No further status for risks will be required.
Customer satisfaction**
Very high (++)
High (+)
Average (0)
Low (-)
Dissatisfied (--)
Status
*****
****
***
**
*
**The customer satisfaction will be set by the PM. If you are not sure, ask. Upon request, the
customer satisfaction can be asked for by the PM or Senior User of your project.
Overall:
The overall project status figure is the sum of the number of stars of the individual stati (Milestones,
Project Budget, and Customer satisfaction. Every project with an Overall project status figure below 7 is
deemed to be critical.
3-6 = red
7-10 =yellow
11-15 = green
Critical Status Activity:
In case one of the sub items (Milestones, Project Budget, or Customer satisfaction) represents a Red
status as per definition above or the overall status is below 7, the PM has to escalate the situation
proactively. Therefore a meeting request to the project assurance or, if not established, to the head of PM
/head of technical PM or Operations manager has to be issued. In preparation for the meeting, the
following information has to be provided in writing by the PM upfront:
- Reason for RED Status (brief write up)
- Impact to Milestone
- Impact to Financials
- Impact to customer relation
- Impact to other major contractual regulations (e.g. LD’S, Warranty, Acceptance)
- Proposed recovery plan / action
Filename definition:
HL-Report-Projectname-MMM-YY.doc
MMM-YY: for reported month e.g.: Oct-2011
created: YYYY-MM-DD
page: 3/3
Fare collection
systems
10.4.2
CDRL 601 – Technical Overview
Page 111
CDRL 601 – Technical Overview
System Overview:
Optimum and minimum requirements to be defined upon completion of scope.
Fare collection
systems
10.5
Vendor Statement
Page 112
9HQGRU6WDWHPHQW
,KDYHUHDGDQGXQGHUVWDQGWKHVSHFLILFDWLRQVDQGUHTXLUHPHQWVIRUWKLV5)3DQG,DJUHHWR
FRPSO\ZLWKVXFKVSHFLILFDWLRQVDQG HTXLUHPHQWV,IXUWKHUDJUHHWKDWWKHPHWKRGRIDZDUGLV
DFFHSWDEOHWRP\FRPSDQ\,DOVRDJUHHWRFRPSOHWH6(59,&(6$*5((0(17ZLWKWKH&LW\RI
)RUW&ROOLQVZLWKLQGD\VRIQRWLFHRIDZDUG,IFRQWUDFWLVQRWFRPSOHWHGDQGVLJQHGZLWKLQ
GD\V&LW\UHVHUYHVWKHULJKWWRFDQFHODQGDZDUGWRWKHQH[WKLJKHVWUDWHGILUP
127( 9(1'2567$7(0(17,672%(6,*1('5(7851(':,7+<285352326$/
9(1'25,672$/62,1&/8'(7+(5(48,5(',1685$1&(&(57,),&$7(
1$0,1*7+(&,7<2))257&2//,16$6$1$'',7,21$/,1685('%8<
$0(5,&$$1'/2%%<,1*&(57,),&$7,210867%(5(7851(':,7+<285
352326$/68%0,77$/
),501$0( Scheidt
& Bachmann
USA, Inc.
$''5(66 31 North
Ave, Burlington, MA 01803
Macaulay.David@S-B-USA.com
(0$,/$''5(66 3+21( 781-272-1664
Macaulay
%,''(5¶61$0( David
6,˘ $7ˆ 5(
35,0$5<6(59,&(6,668(6&217$&7 Thomas
Arabudzki
7(/(3+21( 781-262-6660
)$; 781-272-1654
(0$,˜ Arabudzki.Thomas@Scheidt-Bachmann-USA.com
! (˜ ˜ 781-353-1904
(0(5˘ ( ! ˛ n/a %$! &ˆ ° 781-272-1664
Compensation and Contract Process
1.
After contract award, progress invoices shall be billed in quarterly installments, subject to review and approval by the
City’s Project Manager. City payment terms will be Net 30 Days from receipt of invoice.
2.
The City reserves the right to award directly as a result of the written proposals. The City may or may not opt to
conduct oral interviews.
3.
The selected Contractor shall be expected to sign the City’s standard Services Agreement prior to commencing
Services (see sample attached to this Proposal).
PLEASE GO TO www.fcgov.com/purchasing TO REGISTER IN OUR E-PROCUREMENT SYSTEM FOR FUTURE BID
OPPORTUNITIES! BE SURE TO SELECT ALL APPROPRIATE COMMODITY CODES.
COMMODITY CODES USED FOR THIS RFP:
550-90 Transportation Systems, Intelligent (An automated information system which provides traffic management,
communications, and analysis of data as a minimum
920-32 Intelligent Transportation System Software (To Include Design, Development, and Maintenance Services)
5)30$;%577LFNHW9HQGLQJ0DFKLQHV
3DJHRI
Fare collection
systems
10.6
Insurance Certificate
Page 113

view - City of Fort Collins Public Records

Transcription

Similar documents

Flämingstrasse

218.347.1075 218.346.7325 Rural Home with 5

Pre – Booking

Airport Parking Management With Software As A

Business Flowing in with Water System

[1.8 MB/]

e-Fare™web based fare system

UK offer - Your Model Railway Village

the implementation of successful social programmes in the provision

Transitions - Orientation and Transition Programs