Specification of Requirements

CAR PARK MANAGEMENT SYSTEM

AT

ELMSLEIGH SURFACE CAR PARK AND ELMSLEIGH MULTI STOREY CAR PARK

Contents

1. About Spelthorne & About This Requirement. 2

2. Scopeof the Contract. 4

3. Background. 4

4. Detailed Requirements. 0

5. Support Requirements. 2

6. Project Requirements. 3

7. CONTRACT MANAGEMENT. 4

8. Service Levels and Key Performance Indicators (KPIs). 4

9. EXIT ARRANGEMENTS. 4

10. GENERAL DATA PROTECTION REGULATION (GDPR), AND PRIVACY IMPACT ASSESSMENTS (PIA). 5

1. About Spelthorne & About This Requirement

1.1 About Spelthorne

The Borough of Spelthorne has a population of approximately 103,000 residents and covers some 20 square miles.

Situated on the River Thames between Windsor and Hampton Court, Spelthorne is fortunate to have a long river frontage and the river forms much of the Borough’s boundary. Spelthorne’s riverside areas are some of the most attractive spots in Surrey and attract visitors from a wide area.

The main areas of the Borough are Ashford, Shepperton, Staines-upon-Thames, Stanwell and Sunbury-on-Thames. 65% of the Borough is designated as Green Belt and a further 30% is covered by floodplains or reservoirs.

Prior to the pandemic and hostile events in Europe, Spelthorne has enjoyed a buoyant economy, with a wide range of businesses attracted by the Borough’s close proximity to London and Heathrow Airport and the excellent transport links to the M25, M3 and M4 motorways.

BP, Wood Group, Netflix (Shepperton Studios) and dnata are just a few of the global businesses which can be found here.

Figure 1: Borough Overview

Spelthorne Borough Council (the “Authority”) is the administrative body for the area; the Authority’s main administrative office is at Knowle Green in Staines-upon-Thames. The Authority provides a wide and varied range of local services to residents and businesses as shown below:

The Authority’s Corporate Plan sets out five Corporate Priorities and seven Corporate Values as shown below:

1.2 About this Requirement

The Authority is inviting Bidders to submit proposals which fully meet the requirements of this Specification, and which demonstrate value for money.

2. Scope of the Contract

The Authority is looking to purchase a combined car park management system for its Elmsleigh Surface car park (SCP) and Elmsleigh multi story car park (MSCP). The requirement includes all elements of the equipment, materials, delivery and installation of the new system, as well as ongoing repairs and maintenance.

The contract will include all elements of the delivery, installation, testing and signing off of the new system, as well as including a Service Level Agreement for specialist repair and maintenance outside of scope of warranty.

All mandatory elements of the Specification will be included in the contract, and the Authority reserves the right to include or exclude optional elements of the Specification.

All existing equipment is to be removed from site and disposed of appropriately. During site visits, all equipment to be removed will be indicated, but the new system must be a full replacement of the existing equipment and meet the same functionality

The Authority reserves the right to include or exclude any optional elements of the Specification.

1.

2.

3. Background

2.

3.

3.1 Location

The Authority has a number of off street car parks regulated under The Spelthorne Borough Council Off-Street Parking Places Order 2020.

The Order is published on our website at https://www.spelthorne.gov.uk/parkingorder

Within the Order we have two Pay on Foot car parks, Elmsleigh SCP and Elmsleigh MSCP that share the same entry and exit points and are operationally managed as a single car park.

The site map provided shows the boundaries of the parking areas and important location details

Site map key:

Red box - details the limits of the Elmsleigh MSCP parking area (including the access ramp.

Blue box - details the limits of the Elmsleigh SCP area.

Orange box - details the limits of the shared Entry/Exit and pedestrian access.

“P” -  location of current pay points

“O”  - operations office.

“1” - Entry barrier.

“2” - -Entry barrier.

“X1” Exit barrier.

“X2” Exit barrier.

3.2 Entry and Exit Barriers

Currently the Entry barriers have ANPR cameras facing South, and the Exit barriers have ANPR cameras facing Southwest. These surface cameras currently have regular issues with lighting adjustment and capturing registrations correctly. This is particularly noticeable at times of the day where the sun is in lower positions (early mornings and late afternoons).

The car park is currently operated using a ticket-based system. End users obtain a barcoded ticket at the entry points and then present their ticket at the end of their stay at one of the pay points for the charge to be calculated. If the registration is collected successfully at entry and exit, the exit barrier opens automatically if there is a paid session and the exit terminal prevents the insertion of the ticket associated, which leads to people littering the exit lanes with discarded tickets.

There is no segregation of traffic, so there is currently no way to identify if a customer uses the SCP or the MSCP. At the moment, segregation is presumed based on the entry point used, however people are able to cross into either car park regardless of the entry point used and can then park in either the SCP or MSCP.

Magnetic loops are installed on entry lanes to each car park area and connected to a central mast, but they are not connected to any component of the current system.

The following are more detailed pictures of the Entry and Exit barriers as they are currently:

3.3 Cabling

The current terminals are connected using ethernet cabling to the server that is located in the operations office. This is achieved using basic ducting, with manhole covers at specific points where there is a junction of cabling routes. The ducting is very basic and small, and the junction boxes are often filled with water. Below are pictures to illustrate those junction boxes as they appear once the manhole covers are removed:

Once the ducting reaches the operations office, the cables are exposed through the ground and enter the operations office through a hole on the floor. The ethernet cabling is managed using multiple chained switches at the terminals.

3.4 Car park management system

The current car park management system was purchased and installed in 2016. The system is centrally managed by a server with its own dedicated broadband line, with no data redundancy, and a basic server running Windows Server 2012. There is also a POS in the operations office that consists of an LCD monitor with a thin client PC attached to it, which has a proprietary ticket printer and validator, as well as an RFID reader and barcode reader.

Access to the system is performed using the proprietary software of the original provider, however the database is not optimally structured. The ANPR cameras are self-contained ParkIT cameras. They have inbuilt ANPR functionality and are only programmed to return video stills to the server at specific activations (one at activation of the presence loop, one at opening of the barrier, and one at activation of the safety loop after the barrier). The system is designed to only obtain the vehicle registration detected at the presence loop activation, which can lead to a nil result if the vehicle approached the barrier at speed or without keeping a safe distance to the car in front. The most common nil result is a result of the barrier obscuring the registration due to the angle of the camera.

3.5 Pay Points

Card payment terminals use a standalone connection to the server that is done through proprietary software and certification. The connections are of low bandwidth and are very slow. They are provided by NMI to the car park management system installer

The card payment setup has the Authority as a merchant, as well as attributing the PCI-DSS compliance mechanism to the Authority for the whole system.

Below are pictures to illustrate the current payment terminals and their relative positions:

4. Detailed Requirements

The following are the mandatory requirements, itemised for reference on the technical and price evaluation part of this tender.

4.

4.1 The system must be ticketless, and there must be appropriate measures to ensure its uptime is 100% (excluding external factors outside the control of the car park management system, normally referred to contractually as force majeure).

4.2 Appropriate tools and processes must be available in the system to enable and ensure the data it manages is stored and processed in full compliance with the appropriate national and international legislation (including GDPR), as well as ensuring that the border arrangements during the entire lifetime of the contract and agreements between the UK and other countries do not prevent at any point the continued access to that information.

4.3 End users must be able to make payment using coins (all forms of legal tender valid in England, except the lowest value coins - £0.05 or less), notes (all forms of legal tender valid in England, except the highest value note - £50) or any form of bank card or equivalent contactless payment method (e.g. Google Pay) on at least two separate central and accessible pay points (including for end users with disabilities). Additional pay points should have solely bank card/contactless payment methods accepted. Where coins/notes are to be accepted, exact change must be dispensed to the customer with the machine being able to store a proportionate amount of inserted currency to dispense as change on a daily basis. The car park management system must be able to interface with an App that enables end users to remotely manage parking sessions and payments, and the car park management system provider must commit to join the NPP (National Parking Platform).

4.4 Being ticketless, the system needs to have sufficient tools and processes to deal in a self-sufficient manner with incorrect vehicle registration captures at Entry/Exit, in a way that does not require manual intervention by the operator, and the customer is able to ensure the details are correct and verified at both the pay point and the exit terminal. Where printing facilities are to be available, the Authority must be able to source and obtain consumables independently from the system supplier, as well as having assurance that the printing elements have a defined End of Life program and an objective solution to the Authority to prolong the full operation of the system once any End of Life is achieved for any component of the system. For any component of the system (including the system as a whole), if there is a defined End of Life it must be stated, otherwise the system supplier will be considered able to ensure the continued full operation of the system whilst the Authority operates it.

4.5 The system must have a comprehensive Level 1 maintenance manual or set of instructions that can be easily distributed and accessible by the Authority, aimed at any and all maintenance actions that are basic in nature and can be carried out by operatives without professional qualifications related to electrical or mechanical activity.

4.6 There must be a service level agreement for repairs and maintenance outside of scope of warranty, including a full list of prices of replacement components and any costs to visit, install and test replacement equipment. The service level agreement must have a fixed cost for the expected maintenance cycle within Level 2 actions and above (requiring professional qualification and/or proprietary knowledge of the system software and hardware architecture and functionality) for the first 5 years after installation.

4.7 The system must have a remote management capability, using secure connectivity and credential verification (this means the ability for any computer with internet connectivity, regardless of their location). This remote management capability should include intercom functionality between a given asset and the operator. If such facilities have a yearly cost, please quote the cost for the first 5 years after installation in the Pricing Schedule, otherwise they are presumed to be at no cost.

4.8 From a system frontend query perspective, the Authority must be able to access and model the following datasets remotely:

4.8.1 Total bay occupancy;

4.8.2 Occupancy by car park zone/area;

4.8.3 Asset status, including presence and condition of asset (e.g. vehicle is present, barrier is present, asset is functional and online, etc);

4.8.4 Parking Session payment statistics, including total payment received across a custom date range (split by payment type, payment terminal and car park area);

4.8.5 Parking Session length statistics (including length of stay per car park area, per end user, averages and totals, across any custom date range);

4.8.6 Season ticket statistics (including length of stay per car park area, per group/business, per end user, averages and totals, across any custom date range);

4.8.7 Downtime live information and reports, in a way that enables the Authority to clearly see any asset or component that is not accessible by the system or functional to end users;

4.8.8 Individual parking session information, including narrative history and any stills taken by the ANPR cameras;

4.8.9 Itemised history of all system records and events, for any custom date range;

4.8.10 Any reports produced must have the functionality to be exported into a file format that can be opened and edited using a standard Office 365 suite program.

4.9 From a system frontend data entry perspective, the Authority must be able to enter and customise the following aspects of the system:

4.9.1 Car park user groups (basic groups would be post pay users, pre-pay users, but the system must enable the creation of customisable groups with different characteristics or a combination of existing or preset characteristics)

4.9.2 Tariff structure and values, without restrictions on tariff point segment duration (i.e. no set length times for tariff points such as 1 hour intervals)

4.9.3 Set-up, application and/or validation of a discount system, under set parameters

4.9.4 Differential charging days, where a custom tariff or nil tariff can be set for a specific calendar day in advance (e.g. special tariff or free parking for Christmas day).

4.10 The entry asset setup must ensure that every parking session has appropriate evidence and data associated, as well as appropriately segregating and managing a queue of vehicles. The setup must also work with the main system to prevent entry to vehicles deemed not to be welcomed into the car park, either through manual intervention of the operator for a previous offence, or for the existence of unpaid parking sessions associated with the vehicle. Entry must also not be enabled if there isn’t an available space in the car park with customisable ranges when the car park has a temporary change in spaces available to end users (i.e. bays suspended from use).

4.11 The exit asset setup must be able to prevent non-payment exits (e.g. tailgating), but if forceful exit is attempted, the assets must have a functionality and structure that enables a quick and straightforward return to full function by any operator. The setup must make it clear to end users if an exit is not fully operational, particularly if there are payment terminals inbuilt (e.g. it must be clear to end users if one or all payment options at exit are available, before the vehicle attempts to approach an exit without payment completed).

4.12 The car park management system must be able to integrate or manage inbound/outbound data relating to bay occupancy with our existing VMS system (Zephyr – Swarco, currently done using Simple Object Access Protocol), as well as being able to report internally on a per-bay basis.

4.13 If you a product is proposed that is already capable of managing bay occupancy on a per-bay basis this must be quoted separately in the Pricing schedule.

 The current total of bays is as follows:

Elmsleigh Surface car park – 365 spaces

Elmsleigh MSCP – 512 spaces

4.14 There should be no re-use of existing equipment and assets, except for ducting that the supplier deems as functionally and structurally sound. The transition between the current system and the new system must have a structured and appropriate project timeline aimed at reducing any period where the car park cannot be operated as a Pay on Foot car park. The maximum permitted period of non-operation by Pay on Foot of the car park is 1 week, with a deductible applicable on the overall tender price if that period is exceeded (equal to the calculated income loss associated with the additional downtime).

5. Support Requirements

1.

2.

3.

4.

5.

The following support is required:

5.1 Remote Support during working hours – 09:00 – 17:00 hours Monday to Friday for software issues as a minimum.

5.2 Remote Support during working hours – 09:00 – 17:00 hours Monday to Friday for hardware issues as a minimum.

5.3 Onsite support for software or hardware issues if required during working hours – 09:00 – 17:00 hours Monday to Friday as a minimum.

5.4 Acknowledgement of the reported problem within 24 hours of the issue being raised;

5.5 Resolution of the Issue within 48 hours of the issue being raised (for issues affecting system uptime)

5.6 If cloud based all upgrades and fixes are included for the lifetime of the contract

5.7 If on premise upgrades and fixes can be done by the Authority, without consultancy requirements (unless these are covered by the support contact), details of the solution must be provided within 48 hours of being available to the Authority

5.8 Commitment that the software that operates the systems will be supported for the entire duration of the contract, including extensions

5.9 If software version is changed within this time, all migrations and upgrade costs are included within the contract

6. Project Requirements

6.

6.1 The selected Provider must nominate a project manager to support all stages of the project.

6.2 Once the Provider has been selected, the nominated project manager will need to arrange weekly project update meetings with the Authorities authorised representative.

6.3 The Provider must provide details, including CV and any relevant experience, of the specialist installers who will attend site to carry out the installation.

6.4 The Provider will provide all hand over documents, operations manuals etc. to the Authority on completion of the works onsite.

6.5 Work will only be deemed as complete by the Authority once they have been formally signed off in writing by the Authorities authorised representative.

6.6 Invoicing for the completed works will only be accepted when the written sign off has been provided

6.7 Training for administrators will be required virtually, for a minimum of 4 people. This training will need to be delivered before the go live date.

6.8 There needs to be a clear escalation process for reporting on project issues regarding work being completed on time and to a satisfactory standard.

7. CONTRACT MANAGEMENT

7.

7.1 The main term of this contract shall be for 3 years, with the option to extend for two 12 month periods.

7.2 Key Contract Elements

The Contract will be managed XX. The Supplier (successful bidder) will be required to provide XX reports providing details of the performance against the Key Performance Indicators.

Where contract performance falls short of the required KPI (Key Performance Indicators) standards, the supplier will be expected to attend (in person or virtually) a Contract Review meeting to discuss the measures to be implemented to address the issues.

8. Service Levels and Key Performance Indicators (KPIs)

The Authority requires the system to be available as detailed in the ‘Key Performance Indicators’ table below.

Key Performance Indicators (KPIs)

No	Service Area	Service Level Measure	Service Level Requirement
1	System uptime	All functionality available	99%
2	Remote Support for software issues and hardware issues	Support service available	Within 24 hours of the issue being reported
3	Onsite Support for software issues and hardware issues	Support service available	Within 48 hours of the issue being reported (for issues affecting system uptime)

9. EXIT ARRANGEMENTS

8.

9.

9.1 The main term of this contract shall be for 3 years. No later than 12 months prior to the end of the contract main term, SBC shall review the performance of the contract to consider options for new contract provisions.

9.2 The Provider shall give every assistance in this regard, including providing detailed performance, statistical and any other information held pertaining to SBC. Information shall be provided in a timely manner, and no later than 10 Working Days after request.

9.3 Where applicable, the Provider shall support any new tendering exercise undertaken by SBC, including providing timely responses to any points of clarification raised during the tendering process.

9.4 At the end of the contract, should the contract transfer to another third party, [the Provider] shall support transfer of any and all information needed to support the new provider mobilisation.

9.5 Any data held by the Provider shall be handed back to SBC at the end of the contract, or, where this is not possible, shall destroy such information.

10. GENERAL DATA PROTECTION REGULATION (GDPR), AND PRIVACY IMPACT ASSESSMENTS (PIA)

Data processing

This Schedule shall be completed by the Controller, who may take account of the view of the Processor, however the final decision as to the content of this Schedule shall be with the Controller at its absolute discretion.

1. The contact details of the Controller’s Data Protection Officer are: Email – data.protection@spelthorne.gov.uk

2. The contact details of the Processor’s Data Protection Officer are: Email –

3. The Processor shall comply with any further written instructions with respect to

processing by the Controller.

4. Any such further instructions shall be incorporated into this Schedule.

Description	Details
Identity of the Controller and Processor	The Parties acknowledge that for the purposes of Data Protection Legislation, the Authority is the Controller and the Service Provider is the Processor.
Subject matter of the processing	Personal Data will be processed during the provision of cleaning services in connection with the performance of the Services under this agreement.
Duration of the processing	The duration of this Agreement
Nature and purposes of the processing	The nature of the processing means any operation such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment, or combination, restriction, erasure of destruction of data (whether or not by automated means). The Service Provider will process Personal Data provided from the Authority.
Type of Personal Data being Processed	The Personal Data processed shall be that which is necessary for the performance of the Service Provider’s obligations under this agreement. Personal data may include name, email, telephone number, photographs and images, vehicle registration numbers, signature and any other information provided by the Service Provider or the Service Provider’s Personnel.
Categories of Data Subject	The Data Subjects shall be those individuals whose data is processed in the performance of the Service Provider’s obligations under this agreement, including the employees, staff other workers, agents, consultants and contractors of both the Authority and the Service Provider.
International transfers and legal gateway	None
Plan for return and destruction of the data once the processing is complete	The Authority has defined the retention period as a maximum of 6 years from the data that the Personal Data was provided. However, Personal Data shall be retained no longer than it is necessary to retain it. If it is still in the possession of the Service Provider on termination or expiry of this agreement it shall be returned or deleted as agreed between the parties.