TFL 2228 INTELLIGENT SPEED APPLICATION DESIGN AND ...mpainesyd.com/filechute/TFL ISA Proposal - Technical Response (fin… · Transport for London Intelligent Speed Application Design

Transport for London Intelligent Speed Application Design and Development

TfL 2228, Confidential April 2008 p 1

TFL 2228

INTELLIGENT SPEED APPLICATION DESIGN AND

DEVELOPMENT

TECHNICAL PROPOSAL



CONTENTS

0. Executive Summary ......................................................................................................................... 4

1. Introduction ..................................................................................................................................... 8

1.1 This Proposal ............................................................................................................................ 8

1.2 Requested Information ............................................................................................................ 8

1.3 Contact Details ......................................................................................................................... 9

2. Intelligent speed Adaptation ......................................................................................................... 10

2.1 What is ISA? ............................................................................................................................ 10

2.2 Why is ISA Necessary? ............................................................................................................ 10

2.3 TFL and ISA ............................................................................................................................. 12

3. Our Capability ................................................................................................................................ 13

3.1 Our Credentials ....................................................................................................................... 13

3.2 Reference Sites and Experience ............................................................................................. 14

3.2.1 Western Australia – ISA Trial ........................................................................................... 14

3.2.2 Transport For London - ISA Advisory Application ........................................................... 15

3.2.3 Transport For London - Congestion Charging Technology Trials .................................... 15

4. Meeting TfL’s Requirements .......................................................................................................... 17

4.1 Our Understanding of Your Requirements ............................................................................. 17

4.2 Our Proposed Approach ......................................................................................................... 17

4.3 Our proposed Solution ........................................................................................................... 19

4.3.1 Overall Solution Architecture .......................................................................................... 19

4.3.2 In vehicle equipment: Speedshield ................................................................................. 20

4.3.3 Back Office and GIS support systems .............................................................................. 28

4.3.4 Communications systems................................................................................................ 29

4.4 Statement of compliance ....................................................................................................... 30

4.4.1 Priorities Identified by TfL ............................................................................................... 30

4.4.2 Compliance Checklist ...................................................................................................... 34



5.0 Implementation Plan and Approach .......................................................................................... 42

5.1 Overview of our Proposed Approach ..................................................................................... 42

5.2 Detailed Project Plan .............................................................................................................. 44

5.2.1 Phase 0 – Project Mobilisation ........................................................................................ 44

5.2.2 Phase 1 – Product Certification/Testing .......................................................................... 48

5.2.3 Phase 2 – Fit for purpose demonstration ....................................................................... 50

5.3 Project Organisation ............................................................................................................... 51

5.3.1 Project Manager .............................................................................................................. 51

5.3.2 Project Organisation and Project Team .......................................................................... 52

5.4 Project Timeline and Resource Schedule ............................................................................... 52

5.5 Project Management .............................................................................................................. 55

5.5.1 Project Governance ......................................................................................................... 55

5.5.2 Proposed Project Methodology ...................................................................................... 56

5.5.4 Risk Management ............................................................................................................ 56

6.0 ‘Post-Programme’ Strategy to Promote Wider System Adoption ............................................. 61



0. EXECUTIVE SUMMARY

Inappropriate speed is a major cause of fatal incidents and accidents on the roads of London.

Research has demonstrated that by reducing the collision speed of a vehicle from 50 to 30 km/hr, a

child’s probability of survival increases from less than 50% to 90%.

Intelligent Speed Adaptation (ISA) technology links the speed of the vehicle to the legal speed limit

for the road on which the vehicle is travelling. The technology uses a positional reference device

(usually a GPS receiver) to locate the vehicle, a means of measuring the speed of the vehicle (using

GPS velocity estimates, a wheel counter or a link to the vehicle’s speedometer) and a speed limit

map.

TfL is a leader in the field of ISA. The London Road Safety Unit (LRSU) has already made a significant

investment in ISA, creating a comprehensive speed sign database for 33 boroughs across London

(2007) and piloting an advisory ISA system that uses a commercial-off-the-shelf (COTS) satellite

navigation product as its base (2008).

This proposal addresses the next phase in the development of TfL’s ISA strategy, the piloting and

demonstration of a voluntary ISA solution within more than 30 vehicles throughout the London area.

The rationale for embarking on this next phase is clear. Research undertaken by Leeds University has

shown that if an advisory ISA application was adopted in London, the expected reduction in fatal

incidents would be approximately 19% (voluntary system) and as high as 37% (mandatory system).

With an annual cost of road accidents in London of £1.2bn (2006), any strategy which can positively

impact on London accident rates is likely to be compelling from both safety and cost perspectives.

Our understanding of TfL’s strategy is that they wish to continue to take a leadership role by actively

promoting that ISA can save lives and reduce collisions. Running a successful ISA trial within the

London environment is an essential part of this goal. The subsequent promotion of the benefits of

ISA systems within and outside TfL, based on meaningful trial results, is also important.

We believe this document sets out a response which meets the many detailed requirements set out

by TfL as part of the tender process. More importantly though, while taking care to meet the

detailed requirements described in the statement of work, much of the focus of this proposal is on

ensuring that TfL delivers on its strategic goal of successfully introducing ISA systems to a wide

audience of potential adopters.

Our proposal is based on deploying an existing COTS ISA product which can be utilised in Advisory,

Voluntary or Mandatory modes. The product is the most advanced of its kind in the world and has

already been tested extensively in the field, via a number of trials, similar to those contemplated by

TfL. References for these trials are available.

By promoting a COTS base product, Speedshield, we are proposing an approach which we believe

will be attractive to TfL; providing immediate access to a demonstration vehicle set up in voluntary

ISA mode; minimising the time to the first vehicle certification (less than 4 months from project

commencement), maximising TfL’s exposure to the 35 vehicle on-road trials (full trial to start within

5 months of project commencement); ensuring the project will directly benefit from the learnings of

other comparative trials which are running in parallel to this initiative; leveraging the many man-



years of technology investment which have already been made in the Speedshield product; and re-

using the existing Congestion Charging trials technology infrastructure.

Of course, the base product is only one aspect of a project programme. Equally important will be

the team tasked with working to implement the product within TfL’s specified trials infrastructure.

We are therefore proposing a team with the appropriate capability, technology, delivery and TfL-

specific experience to ensure a successful next phase of the ISA programme. Our team includes:

Mapflow

- Experts in GIS and GNSS technologies;

- Deep understanding of GPS performance within the London area;

- Directly relevant project experience with the LRSU team having developed the ISA

Advisory application;

ACS (Automotive Control Systems)

- World leader in the development of Intelligent Speed Adaptation systems;

- Provider of the Speedshield OBU product which is at the core of this proposal;

Consulting Stream

- Extensive experience in project and trials management;

- Programme manager for TfL’s congestion charging technology trials including a 500

vehicle distance based charging pilot;

TÜV

- Leading global company in the area of vehicle systems certification.

At an individual level our team includes:

Nick Williams (project and trials manager/architect); Nick has over thirty years experience in

the Telecommunications, Hi-Tech and Consulting industry sectors, the last thirteen at

Partner and Director Level. He has deep technical knowledge in fixed, mobile and satellite

telecommunications matters ranging from handset, network and server hardware

technologies through to software solutions for applications on mobile devices or on back

office systems. Nick was the project and trials manager for the technology trials undertaken

by TfL over a four year period and is recognised as a leading expert in the area of GPS based

system performance within harsh urban environments such as London.

Richard Bryce (project QA); Richard’s primary experience during the last sixteen years in the

Information Communications and Technology (ICT) sector has been the successful delivery

of a number of large, complex systems and technology programmes including programmes

for Transport for London (Congestion Charging Technology Trials), AA Ireland (Rescue centre

and dispatch system), the European Space Agency (ARMAS program), the Revenue

Commissioners (integrated taxation system), Tesco (retail administration, trading and

control system) and Hibernian Insurance (Geo-underwriting system). During his nine years in

Mapflow, Richard has helped grow the organisation into an internationally recognised



product and services company winning numerous technology and growth awards along the

way.

James Shields (technical lead); James is a senior systems analyst with over 10 years of

experience in designing systems for large multi-national clients including major

transportation organisations such as TfL. James was responsible for the technology delivery

and systems analysis activities as part of the recent Congestion Charging and ISA projects.

Our proposal describes a phased project structure, split into a series of self-contained work-streams,

with appropriate sign-off and acceptance ‘gates’ between phases. This approach ensures a

disciplined and rigorous project structure while also providing the flexibility to change course should

requirements and priorities change. As much of this project will be trials based, we believe that this

‘controlled flexibility’ will be a critical part of a successful project engagement.

The proposed approach involves three initial phases each with associated milestones as follows:

Phase 0 Mobilisation (2 months)

Phase 1 Certification (2 months)

Phase 2 Fit for purpose demonstration (8 months).

We have also set these initial phases in the context of a later wider scale deployment of ISA systems

(phases 4 and 5) although have assumed that these are out of scope of this proposal. We have

though, as requested in the tender document, described how we would help TfL promote the use of

ISA throughout a much wider user base, driving ISA adoption into tens of thousands of London

vehicles.

Our project pricing demonstrates our willingness to engage under a fixed price model while also

providing a level of flexibility to increase or decrease the levels of work that will be required, as

would be expected in a trials project.



Finally, this proposal provides a blend of experience and capability which positions us uniquely to

partner with TfL on this opportunity by:

Introducing a world class ISA product to TfL, the most advanced of its kind. The product

includes a GPS chipset from uBlox, which has been rigorously tested in the London

environment (we would be happy to provide results of this test if appropriate);

Demonstrating unparalleled experience of running GPS trials in the London environment,

capturing vehicles journeys for up to 500 vehicles concurrently;

Proposing an approach which recommends that a vehicle is fitted with a voluntary ISA

system (and certified) within 4 months of project commencement, enabling a full 35 vehicle

trial by month 5. This will maximise TFL’s exposure to the ISA system, providing valuable

learnings in advance of any wider scale roll-out, without in any way compromising on future

design or product sourcing strategies;

Implementing a back office solution (data collection, data repository, data analysis and

reporting) which maximises the re-use of technology already built and deployed by TfL as

part of the Congestion Charging trials. The re-use of TfL’s “HUB” infrastructure reduces cost,

reduces risk and reaps the benefit of four years (and many thousands of miles) of GPS data

collection, map matching and journey analysis on behalf of TfL.

We are eager to win this project opportunity. As part of demonstrating our commitment to this bid,

we would be willing to set up a demonstration of the Speedshield product during a short list process.

To that end we would like to invite TfL to a demonstration in London of the Speedshield solution as

part of our submission.



1. INTRODUCTION

1.1 THIS PROPOSAL

This proposal is in response to the ITT (TFL 2228) released by the London Road Safety Unit (LRSU) on

the 14th of March, for the design and development of a voluntary Intelligent Speed Adaptation

application for use in TfL-owned vehicles to prove the concept of ISA in London.

1.2 REQUESTED INFORMATION

TfL requested a number of items of information to be incorporated into tenderers’ responses. The

following table provides an overview of our response and a cross-reference to where in this

document further details are provided.

ITEM

DESCRIBE HOW THE VENDOR INTENDS TO:

COMMENT

SECTION

1 Interact with the vehicle to limit acceleration beyond the speed limit

A detailed description of the Speedshield product functions has been included.

4.3.2

2 Provide updates of the map to the vehicle

Maps can be updated using a range of techniques.

4.4.1.4

3 Ensure GPS accuracy through either hardware or software

High precision GPS is provided through a combination of the ANTARIS GPS positioning engine and the Enhanced Kalman Filter EKF™ algorithm. Mapflow also brings significant map matching expertise to the project.

4.3.2.2

4 Conduct the on-road testing Up to 10 months of on road trials have been proposed.

5.2.2- 5.2.3

5 Access the retail market and bring the developed device to market

Our recommendations in respect of wider user adoption and access to markets have been included.

6.0

6 Any relevant subcontractor information

Sub-contractors are as follows; Consulting Stream, Automotion Control Systems (ACS) and TÜV. Detailed corporate information in relation to ACS has been provided (as this wasn’t included at the qualification stage).

Appendices

7 A high level project plan & project structure

A detailed project plan and project structure have been provided

5.1-5.5

8 To design a voluntary ISA application that includes automated vehicle speed control

A detailed description of the Speedshield product functions has been included.

4.3



1.3 CONTACT DETAILS

The following are the details for the primary contact person at Mapflow in relation to this bid.

Name: Jonathan Guard

Company: Mapflow Limited

UK Address: 68 Lombard Street

London

EC3V 9LJ

Phone: +44 (0) 20 786 81705

Headquarters Address: 4 Merrion Square

Dublin 2

Ireland

Phone: +353-1-63 41430

Fax: +353-1-676 0504

Mobile: +353-86-8035861

Email: [email protected]

mailto:[email protected]



2. INTELLIGENT SPEED ADAPTATION

2.1 WHAT IS ISA?

Intelligent Speed Adaptation (ISA) is a system that monitors the local speed limit of the road that the

vehicle is travelling on and either informs the driver if the vehicle is travelling faster than the speed

limit (Advisory) or takes control of the acceleration of the vehicle. Where ISA is used to take control

of the vehicle it can either have an override facility (Voluntary) or no override facility (Mandatory).

The core components of an ISA system are:

- Road identification, knowing what road the vehicle is travelling on, most often through a

GPS receiver;

- Local speed limit identification, identifying the speed limit for the road the vehicle is

travelling on and identifying the points at which the speed limit changes. This information is

sourced from a speed limit map which is held in the device, and;

- An ISA application that either provides an audible or visual warning through an in-car unit,

or in the case of voluntary or mandatory systems, takes control of the vehicle’s acceleration.

In addition, other systems are required for updating the mapping remotely on the device,

management of the speed limit map, fitting diagnostics and unit maintenance and for administration

purposes.

Our understanding of the requirement as outlined by TfL is for a voluntary system whereby the

driver can over-ride the ISA system.

2.2 WHY IS ISA NECESSARY?

Inappropriate speed kills. In 2001 the European Commission set-out to reduce fatal accidents on our

roads by 50% by 20101. By 2006 fatalities had dropped by 18% from the 2001 levels. Governments

are working hard to improve safety, including slowing drivers down through a range of educational,

enforcement and infrastructure improvement initiatives.

ISA is not a new technology, although step developments in GPS, communications and computing

capability are making the potential widespread adoption of ISA a reality. Much research has been

undertaken in the ISA field, including projects in Scandinavia, the Netherlands, the UK and Australia.

The table below highlights some of these initiatives.

1 EC White paper: European transport policy for 2010 : time to decide



Country Region Year Number of participants (Drivers/Vehicles)

HVI (Type of ISA)

Duration

Sweden Ezlov 1996 92 Passive 2 months

Sweden Umea 1999 4000 Passive 8 months

Sweden Lund 1996 290 Active 12 months

Netherlands Tilburg 1999 20 Active 2-4 months

UK Leeds 2003 80D 20V Active 6 months

Denmark Aalborg 2000 24 Passive 6 weeks)

Finland 2001 24 Passive Participants drove a fixed 18km test route 4 times each (once each for no ISA, advisory ISA, Voluntary ISA, Mandatory ISA)

France Various 2001 100 Active + Passive 8 weeks ( 2 weeks each of Pre ISA recording, advisory, voluntary and mandatory ISA)

UK Leeds 2007 20 Active + Passive 6 months repeated 4 times, 20 vehicles, 80 drivers.

Australia Sydney 2006/7 20+ Active Up to 12 months

Australia Melbourne 2007/8 3 + 50 in 2007/8 Active/Passive 6 weeks

Australia Perth 2007/8 3 + 50 in 2008 Active/Passive Up to 6 months

In a study completed by Leeds University for TfL, the following benefits from deploying ISA systems

were identified:

System Type Speed Limit Type Best estimate of injury incident

reduction

Best estimate of fatal and serious

incident reduction

Best estimate of

fatal incident reduction

Advisory Fixed 10% 14% 18%

Variable 10% 14% 19%

Dynamic 13% 18% 24%

Driver Select Fixed 10% 15% 19%


Dynamic 19% 26% 32%

Mandatory Fixed 20% 29% 37%


Dynamic 36% 48% 59%

Leeds University has also recently completed a trial of 20 vehicles and 80 drivers over a 24 month

period, the results of which are expected to be published shortly. A HGV which was fitted with a

Voluntary application was included in the trial.



2.3 TFL AND ISA

One of the goals of the London Road Safety Unit (LRSU) is to reduce the number of personal injury

collisions and overall casualty numbers occurring on London’s street network. Over the past decade,

London has seen a significant reduction in casualties due to a combination of effective education

and the implementation of road safety schemes. However, absolute incident numbers remain high:

in 2006 there were approximately 30,000 incidents in the London area.

The LRSU is seeking solutions which will help maintain a downward trend in casualty numbers. ISA is

a candidate technology in which the LRSU has taken a leadership role by evaluating its application to

reducing road incidents:

It commissioned Leeds University to undertake a study on the benefits of ISA for London

(2006).

It commissioned the creation of a speed limit map for 33 boroughs across London (2007).

It piloted an advisory ISA application built on top of an industry standard satellite navigation

product, and has plans to release the Advisory application in June 2008 to public users

(2007-08).

The current tender, which represents the next phase of ISA sophistication, demonstrates the LRSU’s

ongoing commitment to the successful development and future widespread adoption of ISA

systems.



3. OUR CAPABILITY

3.1 OUR CREDENTIALS

Our proposal is built around bringing a proven commercial product to this project. ACS ‘Speedshield’ is

an industry-proven Intelligent Speed Adaptation (ISA) system and is installed in vehicles around the

world. Available commercially for over a decade, Speedshield is supplied to blue chip companies such as:

DANA

Amcor

Alcan

Chep

Coca-Cola Amatil

Visy

Nestle

Fosters

BlueScope Steel.

A proven COTS product is at the core of this proposal. In addition we have put forward a project

team with the requisite technology, delivery and TfL-specific experience and skills to help deliver the

LRSU’s ISA programme successfully, with the minimum of risk.

Team Member Overview and relevant experience

Mapflow Mapflow works with agencies with responsibility for managing the efficiency and safety of road networks. Their specific expertise is in the area of using advanced technologies for road management, road pricing and road safety. During 2007 Mapflow was engaged by TfL to develop an ISA advisory application on behalf of the LRSU. Mapflow has also been working with Transport for London in the area of next generation road congestion management technologies, supporting TfL in strategy policy, field trials and investigation of specific issues. Other relevant clients include the European Space Agency, the Ministry of Transport in the Netherlands and the Department for Transport.

ACS Automotion Control Systems, based in Melbourne, Australia, are the developers of the Speedshield ISA system, the most advanced active ISA system in the world. The company is a recipient of an Australian Design Award and the WorkSafe Award. Originally developed for industrial vehicles the Speedshield system has been adapted for use in on road vehicles and is now installed in over 100 vehicles across Australia. ACS has considerable experience in working with Australian Roads authorities to provide comprehensive on-road trials and demonstrations of ISA systems. ACS is currently under contract to supply Speedshield ISA systems to the Victorian Traffic Accident Commission and Main Roads West Australia. ACS also has technology relationships and is a preferred supplier of:

General Motors

Kenworth/PACCAR

DAF Trucks

Consulting Stream

Consulting Stream are experts in designing, testing and project managing major technology programmes, with a particular specialism in transportation and mass transit



applications. Consulting Stream have been supporting TfL on similar programmes for the last seven years, and have worked closely with DTO, RNP, RNM, CC, TPED, TDM, LUL, and IM. Over the last five years Consulting Stream has been managing and designing TfL’s largest set of technology trials involving over 500 volunteer vehicles. This programme tested solutions for vehicle detection and tracking in London using GPS, GSM, DSRC tag and beacon as well as other congestion management solutions.

TÜV TÜV Rheinland InterTraffic GmbH is a subsidiary of TÜV Rheinland Kraftfahrt GmbH, which belongs to TÜV Rheinland Group. TÜV Rheinland Group comprises over 100 companies at 300 locations in more than 50 countries worldwide providing independent testing laboratories and inspection and certification bodies as well as consultancies engaged in many fields of technology. TÜV Rheinland InterTraffic provides consultancy services to leading European car manufacturers in the context of chassis management systems, shift by wire applications and electrical-assisted steering systems. Furthermore, in its role as accredited technical service TÜV has done several approvals of safety-relevant electronic components for vehicles like steer by wire and hybrid system controls. TÜV is member of the German national standardisation committee for European Vehicle homologation regulations and present in several international committees. With TÜV Rheinland InterTraffic’s (TRIT) significant experience in the design of certification and safety processes for systems across Europe TÜV will provide advice and practical experience in the development of safety tests and certification procedures for the proposed ISA application.

3.2 REFERENCE SITES AND EXPERIENCE

We have included reference details for 3 projects below. We would be happy to provide additional

references on request.

3.2.1 WESTERN AUSTRALIA – ISA TRIAL

A paper on the Western Australia (WA) ISA trial is provided in Appendix C. The following is a short

overview of the trial.

ACS is currently under contract to supply Main Roads Western Australia with an ISA solution as part

of a trial being conducted this year. Fitting of vehicles has already commenced with approximately

one quarter of the West Australian ISA fleet completed. In total, 50 vehicles will be fitted with an

advisory ISA application with participant involvement of between three and six months. Although

the system being fitted is primarily an advisory ISA system, the contract also includes provision of a

voluntary system to a number of demonstration vehicles. The contract also requires that all systems

provided as part of this project must be re-configurable as voluntary systems.

The WA trial involves demonstrating a low cost ISA system that can be retrofitted to most modern

vehicles and will focus on a qualitative assessment of the entire ISA architecture, from the in-car



experiences of drivers to road agency experience with speed limit data creation, maintenance and

updates.

3.2.2 TRANSPORT FOR LONDON - ISA ADVISORY APPLICATION

During 2007 TfL awarded a contract to Mapflow (supported by TomTom) to develop an Advisory ISA

application. The contract was completed successfully in April 2008.

The application is simple to use and can be downloaded onto specific models of the TomTom. The

core function of the application uses the TfL Speed Map for London and warns the driver with a loud

audible beep when the vehicle is travelling greater than the speed limit for the road the vehicle is

travelling on. Alert levels can be set so that the driver receives either a beep or a voice warning

depending on the extent by which they are breaking the speed limit. In addition to the audible

warnings, a warning sign also flashes on the TomTom screen if the driver is breaking the speed limit.

The application also has the ability to collect statistics on the journey, providing a report to the user

on the amount of times and duration the vehicle went above the speed limit during the journey.

The next phase of the project is to gather feedback from up to 200 users who register to download

the application. This phase will commence in June 2008. Based on that feedback, a further phase of

development may be initiated, for example embedding the application into the core TomTom

software.

3.2.3 TRANSPORT FOR LONDON - CONGESTION CHARGING TECHNOLOGY TRIALS

Transport for London (TfL) wished to advise the Mayor of London on the feasible technology options

for future road charging and traffic management schemes, which would intercept with potential

national and European schemes.

These trials were to evaluate new camera and automatic number plate reading systems, tag and

beacon systems, positioning technologies, including GPS/GNSS and GSM, for the purposes of area

charging or distance-based charging. In addition, the trial would evaluate the related customer

communication and traffic management facilities which may be required to enable customer

payment accounts.

In the GNSS area, repeated trials were carried out across London using robust statistical methods to

overcome the stochastic nature of results. The need for an accurate and trusted ‘truth’ (e.g. GIS data

for roads, road segments and associated attributes) was clear and multiple runs for data gathering

were achieved to ensure statistically sound results. The outcomes of each stage were reviewed and

endorsed by an independent Peer Review Board to ensure their technical and academic credibility.

Within the TfL Technology Trials, other technical systems were reviewed using the same analytical

rigour. These included the analysis of the successful identification of in-car mobile phones by small

(pico) cell GSM base stations, the successful delivery of Value Added Services to drivers triggered by

Tag and Beacon DSRC and the use of GSM/GPS positioning to alert drivers to entry into the

Congestion Charging Zone. Results were presented in a number of innovative and informative

graphical/tabular formats that were appropriate for a range of stakeholders.



These trials were designed and managed by Consulting Stream, while the technology delivery and

the data analysis were undertaken by Mapflow.



4. MEETING TFL’S REQUIREMENTS

4.1 OUR UNDERSTANDING OF YOUR REQUIREMENTS

We have reviewed in detail the requirements set out in the TfL tender documentation.

The following sections describe our response to the complete set of requirements as set out by TfL.

We have also highlighted below those areas which we understand are of particular importance to

TfL, and the corresponding section in our response.

REQ DESCRIPTION STATUS DESCRIBED FURTHER IN SECTION

1 The ISA application should control the vehicle speed when the vehicle is travelling faster than the legal speed limit for that motorway, road or street

Compliant 4.3.1, 4.3.2

2 The speed limit mapping needs to be updated remotely Compliant 4.4.1.4

3 The HMI interface needs to be non-distracting and meets various UK and European legislation requirements in relation to car equipment

Compliant 4.4.1.2

4 The unit needs to be reliable Compliant 4.4.1.1

5 The unit needs to be designed to ensure that it is protected from fraud Compliant 4.4.1.5

6 The unit needs to be implemented in different types of vehicles (4 vehicle types have been identified in the specification document) and the unit needs to be capable of operating in different modes for each of the identified vehicle types

Compliant 4.4.1.3

7 The vendor needs to manage a pilot trial, supply up to 5 vehicles and provide secure parking. Drivers will be provided by TfL

Compliant 5.0

8 The vendor may need to sell/commercialise the product and provide to a greater market

Compliant 6.0

9 The unit needs to be capable of collecting road usage speed information from the unit and reporting this to the users

Compliant 4.3.1, 4.4.1.6

10 The units need to have a supporting system that is capable of dealing with general GIS data, TfL speed map data and any data collected from the units such that road usage speed information can be aggregated and measured effectively

Compliant 4.3.1, 4.3.3

4.2 OUR PROPOSED APPROACH

Our understanding is that TfL wishes to support and promote the widespread adoption of ISA within

and beyond TfL. We have structured our proposed approach with this goal in mind.

A bespoke design and build approach is one way to meet this goal. However, where a proven

product already exists in the market, we believe it is preferable to re-use this existing product

capability: the project will be delivered in a shorter timeframe, with greatly reduced ‘pre-trial’ (e.g.

design and build) activities, energy will be focused on the actual vehicle trials, TfL will directly benefit

from the learnings of other comparative trials which are running in parallel; and total project cost

(and risk) will be reduced because TfL will be able to leverage the many man-years of technology

investment which has already been made in the product.



Our recommended approach is therefore to deploy existing Speedshield product within TfL’s trials

environment London environment. We believe that this can be achieved within a 4 month

timeframe from project commencement, with minimal configuration and/or software changes,

including a thorough certification and acceptance phase. We are confident that there are many

benefits to this product-led approach when compared to an alternative bespoke approach:

Benefit Description Cost We estimate a direct saving of >£0.5M by utilising an existing product. Time We estimate a time saving of 12-24 months by utilising an existing product, eliminating

long bespoke product design and build cycles which would otherwise be required. Risk Re-using a proven product greatly mitigates the technology risk in the project. While some

risk still exists (proving that the product is fit for purpose in a London environment), this risk will be addressed and eliminated within the 1

st 4 months.

The above are some of the key benefits associated with our proposed approach; there are also many

others:

Mapflow has already deployed a trials management infrastructure (congestion charging) on

behalf of TfL. This infrastructure can be re-used with minor changes as part of the ISA

project to collect and analyse vehicle data.

The ACS Speedshield product within this proposal provides a wide range of deployment

options to TfL, including multiple modes (Advisory, Voluntary or Mandatory), and multiple

HMIs (PDA and custom hardware).

The TÜV group brings world class is testing and certification expertise to the project,

mitigating any perceived health and safety risks which may be associated with active ISA

products.

Consulting Stream brings practical experience of managing complex and demanding trials on

behalf of TfL, most recently the 500 vehicle distance-based charging trials undertaken by

Congestion Charging.

Our approach provides a means for TfL, if desired, to build on the ISA Advisory application

investment which has already been made. While we understand this to be out of scope for

the time being, there are many possibilities here.



4.3 OUR PROPOSED SOLUTION

4.3.1 OVERALL SOLUTION ARCHITECTURE

Our proposed solution comprises 3 major system components:

- In-vehicle equipment: Speedshield HMI, OBU and EMS (engine management system)

components

- Back office system:; GIS system for speed map publishing to both the reference data for the

OBU and also for the route definition application, data collection system and data analysis

and reporting system;

- Communication systems: vehicle to data collection system and the GIS speed map

publishing system to the vehicle

In addition there are a number of other external components such as Carrier phase GPS for the truth

source and mapping for converting the vehicle position data into routes.

The solution architecture above is a subset of a full (post pilot) system. Additional components

which would be expected to be included in a live environment would include administration systems

and diagnostics and maintenance systems.

Each of the above three core system components are described in more detail later in Sections 4.4.1

– 4.4.3 below.



4.3.2 IN VEHICLE EQUIPMENT: SPEEDSHIELD

4.3.2.1 Introduction to the Speedshield system

The Speedshield system, is the only commercially available voluntary ISA solution available on the

market and is developed by Automotion Control Systems (ACS). Speedshield has the following core

functions:

Display current speed limit to the driver via a dash mounted HMI display;

Warn the driver when speeding by causing a dash-mounted HMI to display warnings to the

driver;

The acceleration is managed when the driver goes above the speed limit for a given road;

There is a System Override Function via a configurable kick down override or via HMI

interface;

Remote updating of the Road Speed Limit database on the device;

Critical data recording with acceleration/crash data.

The core components of the Speedshield in vehicle system are:

Speedshield OBU to calculate the position of the vehicle, the speed of the vehicle and to

relate the speed to a speed map, to provide both control of the acceleration and provide a

warning to the driver via the Speedshield HMI

Speedshield HMI of which there are two options; a specific display unit (known as TAC) and

a PDA application

The schematic below shows the various functions of the on-board system which include:

Determine the speed limit for the road the vehicle is on using GPS and a built in Speed Limit

map;

Calculate the vehicle speed using a wheel counter and comparing to speed limit;

Control the Electronic Throttle Control (ETC) signal to the engine, managing the acceleration

and sending a signal to the HMI to warn the driver they are breaking the speed limit.





4.3.2.2 Speedshield OBU

The Speedshield OBU is a device that can be fitted under the dashboard, in the boot, engine bay or

under the seat of a car.

For a light vehicle, the OBU is made up of 3 separate modules, each being 14 cm by 3cm by 12 cm.

Modules can be installed stacked, or located separately. Ideally there is a minimum clearance of 8

cm between the top of the uppermost module and vehicle chassis is required to enable easy

installation.

With regard to positioning, the Speedshield OBU uses the uBlox TIM-LR GPS chipset. The TIM-LR is

an ultra-low power, sensor-based dead reckoning GPS module suitable for passive and active

antennas. The combination of the ANTARIS GPS positioning engine and the Enhanced Kalman Filter

EKF™ algorithm provide precise navigation in locations with no or impaired GPS reception, for

example tunnels, indoor car parks and deep urban canyons. The TIM-LR is the ideal solution for high-

volume applications requiring a cost-effective and tightly integrated product that fulfils 100% road

coverage requirement. (The uBlox chipset has been tested extensively in the London area –

performance reports are available in relation to these tests).

The OBU uses the location to determine the road on which the vehicle is travelling and hence the

speed limit. It does this using a position-based search algorithm to match the input GPS data to road

vector data and speed data. The speed data is sourced from a speed map which is stored on the

OBU device. Speed map data updates can be managed manually using an SD card or remotely over

GSM.

The speed of the vehicle is calculated based on wheel pulses. The calculated speed can be calibrated

with the vehicle’s speedometer to ensure that the driver is not reported two different speeds.

The OBU has over 1 Gbyte of data storage for logging usage data (location, speed, bearing, journey

distance, stop time, road id). This data can be stored and then sent to a central server for further

analysis over the GSM network. The frequency with which this data is returned to the server is

configurable.



The Speedshield OBU is powered from the vehicle’s own 12V power supply and is linked to the

ignition system to ensure that Speedshield is only powered when the engine is running. Acceleration

is controlled through digital regulation of the vehicle’s throttle interface. Installed between the

accelerator and the throttle interface, Speedshield prevents additional throttle signal from the

accelerator to the throttle if the vehicle is above the speed limit.

ACS supply as standard a ‘shark fin‘ style combined GPS/GSM antenna. This antenna measures

60mm in height with base dimension 45mm by 80mm and has a magnetised base allowing for a

range of mounting positions. For additional cost ACS can supply an internal GPS antenna that can be

located discretely within the vehicle. For further cost ACS can develop a GSM antenna that is

integrated inside the Speedshield OBU.

4.3.2.3 Speedshield HMI

There are two HMI type options available with the Speedshield system:

The TAC Speedshield display unit has a dashboard-mounted speed display;

A PDA application which is linked to the Speedshield OBU via Bluetooth.

Speedshield TAC Display

The TAC display is an automotive ISA HMI designed specifically for the Victorian Traffic Accident

Commission. The TAC display is a compact display unit that communicates with the Speedshield OBU

via Bluetooth. The TAC display is generally mounted to the dash (to the right of the driver’s position)

or to the driver’s side A pillar (provided the vehicle is not fitted with curtain airbags). Alternative



mounting positions are also possible. The display simply requires an ignition-connected power

source and will automatically connect to the Speedshield OBU on start up.

Functionality includes:

Displays current speed limit

Flashes when exceeding speed limit

Plays audible alarm when exceeding speed limit

Turn voluntary speed limiting on/off

Turn entire system on/off

Turn speed display (passive ISA) on/off

2 minute system override

Automatic photometric LED brightness control

The display shows:

System fault

Voluntary Speed limiting on

System overridden

Current speed limit

Speed limit exceeded (flashing)

Speedshield PDA ISA Application

The PDA ISA application is a customisable PDA-based ISA application that communicates via

Bluetooth with the Speedshield OBU. Designed to work on a variety of PDA’s and smart phones, the

application displays advisory overspeed warnings and includes the ability to engage/disengage

various system functions. The PDA is generally mounted using a windscreen cradle that supplies

power to the PDA but a variety of alternative mounting options are also available.

The display shows:

The text within the red circle shows the

current zone speed limit

The black text to the right of the circle

shows the current vehicle speed. These

values are received via Bluetooth from the

Speedshield OBU and updated

automatically by the system in real-time.

System messages appear above the red circle.

The application controls:

Log Position – (upper left) Press to log the current time and position of the vehicle

System Override – (upper right) Press this button to override the ISA system for 2 minutes.

Enable Speed Control – (lower left) By pressing this button, the application will

activate/deactivate speed control.



Mute Audio – (lower right) When a user is travelling over the legal speed limit, the

application will provide warnings by blinking the speed limit sign visually and playing a sound

every 2 second. A user can choose to mute/unmute the audio alerts by pressing this button.

Functionality

Displays current speed limit

Flashes when exceeding speed limit

Plays audible alarm when exceeding speed limit

Turn voluntary speed limiting on/off

Turn entire system on/off

Turn speed display (passive ISA) on/off

2 minute system override

Data that can be showed:

Connection loss

System faults

Voluntary Speed limiting activates/deactivated

System overridden

Current speed limit

Speed limit exceeded (flashing)

Current Vehicle speed

Audio muted/unmated

Position logged

4.3.2.4 Speedshield OBU Installation

Installation will be conducted by the UK-registered ‘Speedshield’ agent IMPCO. Technicians certified

to install Speedshield will be used.

Installation requires inspection of vehicle (determine that it is the correct model), removal of vehicle

fascia to gain access to mounting positions and vehicle wiring, making wiring connections, mounting

OBU bracket, final connections, start up test, replace vehicle fascia, finished by an on-road test.

Installations take 4 – 6 hours depending on the vehicle.

Speedshield has been tested to work in the following vehicle types (list is not exhaustive):



VOLUNTARY ISA DEPLOYMENTS

YEAR MAKE MODEL VARIANT/S

2003 Ford Falcon BA/BF

2006 Ford Territory

2007 Holden Commodore VE Berlina

2005 Holden Commodore VE Omega

2007 Holden Commodore VZ-V8 Gen 3

2008 Subaru Impreza

2005 Mercedes Benz Vito

2007 Toyota Prius

2007 Toyota Corolla

2007 Toyota Aurion

TRUCK ISA DEPLOYMENTS


2005 Mack Quantam

2006 Kenworth T604

2001 Kenworth T605

2008 Kenworth T608

ADVISORY ISA DEPLOYMENTS


2007 Holden Astra (Petrol)

2007 Holden Commodore VE Statesman

1996 Volvo 850

2008 Toyota Land Cruiser

2005 Toyota Camry

2007 Subaru Liberty

2007 Subaru Forester

2000 Saab 95

2006 Mitsubishi 380

2003 Mitsubishi Pajero

2007 Mercedes Benz E350

2000 Mazda 323

2007 Honda Accord (Euro)

2003 Honda CRV

2007 Honda Jazz

2005 Holden Rodeo (Diesel)

2007 Ford Mondeo

2007 Ford Falcon SV6

2001 BMW M3

Note that all details related to Australian models. If an active solution is developed a passive

solutions is automatically developed. Holden is the Australian badge for Vauxhall.

For the certification phase (see Section 5.2.2), two vehicle types will be installed with Speedshield - a

Toyota Prius and a Vauxhall Astra.



In terms of other vehicles the requirement to fit each vehicle model includes:

Taking sensor readings (throttle and speed signal) for each model

Adapting hardware settings according to these readings

Developing an installation solution (including mounting positions, loom length and

preferable wiring points)

Development of installation manual.

The minimum (ideal) requirements for any vehicle to be compatible with the Speedshield ISA system are:

Easily locatable vehicle speed signal

Electronic throttle control

Easily accessible mounting position, with sufficient clearance for easy installation

Mounting position does not present servicing issues.

Older vehicles models (generally pre 1999) that do not have electronic throttle control will require

an electronic throttle interface to be fitted.

4.3.2.5 Trial Vehicles

Our understanding is that TfL wishes to trial a minimum of 35 vehicles of which 15 are Toyota Prius

and 13 are Vauxhall Astra. Our understanding is that TfL requires the vendors to also provide up to

an additional 5 vehicles.

For the purposes of the certification trial (see section 5.2.2) we plan to provide (or TfL to provide) A

Toyota Prius.

ACS have successfully interfaced with the equivalent vehicle in Australia although we expect a small

amount of configuration work for the UK model.

4.3.2.6 Training in use of Speedshield

Trial participants will be supplied with a user manual for the ISA system and associated HMI,

including a quick reference guide. It is recommended that each participant undertake a supervised

test drive to first review the possible interactions between the driver and the ISA system (e.g. how to

use the HMI, identification of different feedback, how to use the kick down override) and then to

test drive the ISA system, engaging various modes of the HMI and using the kick down override. This

will ensure that when participants come to use various features of the ISA system they understand

how to operate the system correctly and how the system will respond.



4.3.3 BACK OFFICE AND GIS SUPPORT SYSTEMS

As part of the TfL Congestion Charging technology trials, TfL invested in the development of a trials

management platform known as HUB. This platform provides the means to collect data from

multiple devices (and device types) in a structured manner and to present the data in formats

suitable for analysis.

We are proposing that TfL re-utilise this investment and use the platform for managing the ISA trials

data collection process.

The core components within HUB are as follows:

Data collection, an interface to the data from the vehicles is set-up allowing the data to be

automatically collected and stored in a consistent manner within HUB. This ensures data

does not get lost and is safely retrievable.

Journey definition, for the certification phase, we are planning to use fixed routes which the

driver will repeatedly drive and data collected for. The journeys are defined using a map

interface or an external GIS system.

Truth data, in order to be able to measure the accuracy of the Speedshield or other devices,

a truth source is required. We propose using a carrier phase GPS receiver which will provide

sub 0.5m accuracy and will ensure that the metrics generated are reliable. This is the same

as the approach which was taken by TfL for measuring the performance of GNSS vendors in

the congestion charging trials.

Data analysis, HUB contains statistical analysis routines that can be customised to generate

various reports on the performance of the Speedshield device, accessing the data by device,

by route or by time. The metrics can include;

- Required Navigation Performance: accuracy, availability, continuity and time to first

fix of the positioning system. This is a standard way to describe the performance of a

GPS-based device;

- Per Route statistics detailing the number and type of speed transitions;

- Per Journey statistics showing the number of correctly, missed and incorrectly

identified speed transitions;

- Aggregated journey statistics (e.g. per hour of day, per day, per month) showing the

performance of the device as per the journey statistics above.

In addition to HUB, a GIS process for converting the ITN-based TfL Speed Limit map into a format

that the Speedshield OBU can utilise will be provided.



4.3.4 COMMUNICATIONS SYSTEMS

Communications between the vehicle and HUB for data collection can either be via a download

through a serial port onto a laptop or via a remote GSM link. The serial port download approach was

used throughout the TfL congestion charging trials and is a safe and proven way of getting access to

the data for the certification trials. For the demonstration phase, where the vehicles and the drivers

are not part of a fixed route program, i.e. they are free to go about their normal business, a wireless

download via GSM to a hosted web portal is proposed. It is expected that fortnightly or monthly

downloads would be sufficient.

Uploading the speed map to the Speedshield OBU is a more complex process as it is dependent on

data formats of the speed limit map and ensuring that the device can safely update the mapping

without user intervention. Previous trials experience suggests that updates can be efficiently

managed via the SD card in the OBU.

A wireless update method can also be provided as a bespoke enhancement.

This optional wireless update method (if included) will be based on the FM Databank system

developed by ACS that is currently in use at the Port Kembla steelworks south of Sydney. This system

allows map updates made through the ACS Road Mapping Application to be compiled and sent to on

site vehicles. While the current system is designed to manage a constrained amount of transfer data,

it can be enhanced to meet the deployment requirements for an on road ISA system. Such

enhancements would include the development of a multi level spatial data compiler to allow

polygon, vector and point data and expansion of data transfer capability.



4.4 STATEMENT OF COMPLIANCE

4.4.1 PRIORITIES IDENTIFIED BY TFL

TfL set out a number of priorities in the tender document, our responses to which are provided

below.

4.4.1.1 OBU PERFORMANCE AND RELIABILITY

During the mobilisation phase of the project a set of acceptance test criteria will be agreed based on

the project requirements. In Phase I a number of fixed route trials will be performed in London. The

output of these trials will be a measure of the performance of the system within the challenging

London GNSS environment. Such output would include (but is not restricted to) statistics showing

the following performance attributes of the system;

Performance

Standard RNP metrics (accuracy, availability, continuity, time to first fix) for the GPS

component of the system.

Calculated speed vs. speedometer speed

No. of speed transitions per route

% Speed Transitions correctly detected

% Speed Transitions incorrectly detected

% Speed Transitions not detected

% Journey time for which the vehicle was above the speed limit

Time delay between crossing a speed transition point and the system recognising this fact.

% time for which the system is turned off.

Reliability

GPS reliability can be measured using the standard RNP metrics as described above

Failure mode analysis can also be undertaken:

No GPS - Mean time between failures (where a failure is regarded as a period of

greater than x seconds without GPS) will be calculated.

Incorrect Speed Limit Detection (MTBF)

Further to the above testing, reliability and performance of the OBU can be demonstrated through

previous extensive use of the Speedshield system for industrial and on road applications. The

Speedshield OBU has shown that it is capable of providing robust performance over a number of



years with little or no maintenance required. We would be happy to set up reference calls with

existing Speedshield customers to confirm this robustness.

4.4.1.2 HMI USABILITY AND DESIGN

ACS has developed two variants of its ISA HMI. Key considerations in the development of ACS HMI

are:

Ergonomics

Reducing driver distraction

Ease of use

Compatibility with vehicle safety systems, particularly airbag deployment

In addition, the IVIS assessment checklist from TRL LTD Project Report PA3535/99 ‘ A safety checklist

for the assessment of In Vehicle Information Systems: A User Manual’ has been completed for

relevant sections (B-F).

ACS HMI design is compliant with the assessment checklist above with the following exceptions:

Exception Comment

Item B2: The IVIS does not obstruct the view out of the window.

Permanent mounting positions are selected that do not obscure the drivers vision out of any window. If, however, the user does not wish for a permanent mounting (e.g. for a leased vehicle) a dash mounted cradle is available that, in some mounting positions, can obscure driver visibility slightly.

Item B6: When an audio message is being presented other auditory outputs (e.g. the radio) will mute.

Due to the differences between vehicle radio systems in different vehicle models and in the interests of minimising development costs this has not been achieved. ACS are capable of developing this functionality as part of the project as an option if necessary.

Item C3: Controls do not perform more than one function.

As per the specification for development of the TAC display some controls have dual functions in order to reduce the overall size of the display.



4.4.1.3 VEHICLE TYPE APPROVAL

Development of technical solutions to new vehicle models is a continuous process at ACS. ACS’s goal

is to have developed approved solutions for as many vehicle types as possible, with a focus on

providing solutions for popular makes and models initially.

ACS has reviewed legislation relevant to the use of in vehicle speed limitation devices and concludes

there are no concerns with fitting or operating the Speedshield OBU with all vehicle types and

vehicle type approval is also not affected.

The Speedshield system is compliant with the following legislation:

UK Road Traffic Act 1988 - as amended the Road Traffic Act 1991

2002/85/EC Road Speed Limiter

Australian Design Rule 18/03 Instrumentation

Australian Design Rule 65/00 Maximum Road Speed Limiting for Heavy Goods Vehicles

BS au 217 Maximum road speed limiters for motor vehicles

EN 12895 Electromagnetic Compatibility.

An additional (optional) work package has been included with this proposal whereby TÜV would

complete a study on certification and vehicle type approval requirements for an ISA system in the UK

market (see Appendix C).

4.4.1.4 SPEED LIMIT MAPPING

ACS will develop a vectorised database from the data set provided by TfL. In this process, a reference

map is used, along with the speed sign point dataset to generate a network of road vectors. Each

vector represents a section of road and is attributed fields such as road name, speed (both

directions) special conditions (e.g. time based variable speeds) and road classification. This process

has the added benefit of revalidating the dataset as inconsistencies in the data set (missing signs or

incompatible speed zones) can be detected. The process of vectorisation of the data set utilises the

ACS propriety Road Mapping Application (RMA) specific to this purpose. This software has been

previously used to generate trial vector databases for the cities of Melbourne, Sydney, Canberra,

Adelaide and Perth as well as numerous towns, cities and linking highways. The ACS RMA allows

vector addition, deletion or modification and allows users to edit individual vector attributes

through a user-friendly graphical interface. As the RMA uses a reference map interface it is easy to

view the data set against a reference road map. The RMA is also used for database management and

allows search functions based on road vector attributes.

Once the data set it developed it is compiled into a proprietary format for use in the OBU. This

proprietary format not only minimises file size it also offers considerable protection against

unauthorised use or copying of the dataset. Use of this format also protects the system against

fraudulent information being stored on the system as the OBU only recognises the ACS propriety

format.

Updating of the OBU dataset is done manually; however it is proposed that in future this is done

through a remote GSM base station, connected to a roads database server. New updates would be



transferred into the database by a member of the ACS Geomatics team who would then compile the

dataset into the ACS onboard file format. The onboard file would then be uploaded from the server

to the base station where it can be distributed to all vehicles within the fleet. The ACS proprietary

format has been developed so that only the part of the dataset that has been updated is transferred,

reducing base station workload and increasing transfer speed. This system is currently in the

prototype phase and can be developed to a fully deployable solution as per TfL’s specifications.

4.4.1.5 FRAUD PROTECTION

The OBU only accepts an ACS proprietary format file. This file is generated using an ACS compiler

that is linked directly to the dataset (within the ACS server). This prevents users from generating

their own data set or manipulating the on board data set. In the event that the dataset is deleted or

modified the Speedshield OBU could be developed to send a message to a central server to alert ACS

staff that the dataset may have been compromised. Details such as the unit ID, driver/client details

and vehicle location could be included in the message.

ACS has extensive experience with anti-tampering solutions due to the development of industrial ISA

solutions. The Speedshield PCU board is housed within a water repellent, shock resistant, fire

resistant polymer casing. The system can be configured such that any tampering with the

Speedshield OBU that leads to the system becoming inoperable and will prevent the vehicle from

being started. Furthermore, with Speedshield’s real-time vehicle monitoring system it is possible to

determine the status of each Speedshield unit at any time.

The OBU is generally mounted out of sight often behind the interior fascia. Only a determined search

(including removal of the interior fascia) will locate the OBU in these circumstances.

4.4.1.6 MONITORING INFORMATION

As part of the TfL Congestion Charging technology trials, TfL invested in the development of a trials

management platform. The platform has already been licensed by TfL Congestion Charging and this

project represents an opportunity for TfL to leverage the investment already made.

The trials management platform is known in TfL as ‘HUB’ and it collects data from GNSS-based

devices, stores the data in a common format and provides a range of customisable reports that can

be accessed by TfL at any stage during the trial through an internet based application.

The platform has been used by TfL in a recent trial of over 500 vehicles collecting and analysing

several thousand miles of road usage data.

It is proposed to re-utilise HUB for the trials stage of this project.



4.4.2 COMPLIANCE CHECKLIST

The requirements below represent those outlined in TfL the statement of work.

TFL REFERENCE REQUIREMENT COMPLIANCE COMMENT

2.1 The aim of the project is to develop and prototype a voluntary ISA system for use in TfL vehicles to prove the concept of ISA in London

Compliant The consortium is utilising an existing commercial product – Speedshield rather than a design/build effort. The principle reason for this is to reduce time, cost and project risk.

2.1 In the case that TfL do not own the IPR it will still need to be made available to TfL on the understanding that TfL will not exploit the knowledge for its own commercial gain

Commercial/contract discussion

IPR in project deliverables such as project reports will vest in TfL.

Pre-existing background product IPR will remain vested in Mapflow and/or its third party licensors.

Any additional discussion in relation to IPR will be considered as a contract issue.

2.2.2 The design, programming and physical manufacture of the devices to be developed for the individual vehicle types.

Compliant

2.2.2 Vehicle types to be used are likely to include: - General use vehicles (Vauxhall Astra

/ Toyota Prius or similar) - London Bus (Volvo B7TL) - London Taxi (TX4) - A diesel vehicle (Ford Transit)

Compliant The baseline costs provided in this proposal assume initial deployment in a Toyota Prius. We have also provided outline costs for configuration/ certification with the additional vehicle types specified. We do not anticipate any issues at this point with the additional vehicle types proposed.

2.2.2 The HMI will provide both audio signals on the speed limit and display the current speed limit to the driver

Compliant We have proposed two methods of HMI: 1. A dash mounted display constantly displaying the posted speed

limit on an LED display. It is not recommended that this display also includes current speed

2. PDA based display, which provides current vehicle speed and posted speed limit, and a customisable UI.

2.2.3 Fitting and testing of the OBU’s to pilot vehicles – this will include fitting the ISA

Compliant




devices to vehicles on a ‘per vehicle’ cost basis

2.3 Prospective tenders should ensure that they have access to appropriate premises to carry out all engineering work and that this is included in the estimated price.

Compliant

2.4 All work to be carried out in full compliance with the 1974 Health and Safety at Work Act

Compliant

3.1 The appointed company should be prepared to either lease or procure vehicles, or make provisions for the lease or procurement of vehicles on behalf of TfL.

Compliant We have included cost estimates for the leasing of up to 5 family car vehicles.

3.1 It is expected that maintenance and servicing of the vehicle will be carried out within this contract

Compliant Noted.

3.2 Provide secure parking close to 197 Blackfriars Road, Southwark, London

Compliant An option has been provided for parking close to TfL’s address

4.2 The system will be a voluntary (ISA) system where the decision as to whether the system is engaged will be left to the driver. Enabling/disabling the system will be done via a dashboard control or, ideally, a steering wheel control.

Compliant The Speedshield system is controllable from dash (on/off/disable active ISA/mute alarms) - the number of options available to the driver is minimised to avoid driver distraction and to ensure that the system operates in the most effective manner possible. While there is also an option to include a steering wheel mounted control, this feature is not currently incorporated as it is felt there is too much risk that a driver could activate controls inadvertently.

4.2 There will be three levels of engagement:- - On, the unit is engaged and

acceleration will be limited to the speed limit, with an allowance for a TfL set tolerance.

- Off, the unit will not be active and

Compliant, subject to confirmation of bespoke requirements

“On” and “Off” functions both fully supported.

System reengaging after a period of temporary inactivity (as selected by the driver) is currently time based, or based on the cessation of acceleration (when the unit is deactivated temporarily for a deliberate overspeed manoeuvre).

Additional functionality, whereby if the system has been temporarily deactivated it automatically turns on once a lower




acceleration will not be limited. - Temporarily inactive, the unit has

been disabled, but will automatically engage once the vehicle enters a new speed limit or returns below the current speed limit

speed zone is encountered. This function can be deployed (although is not included in the baseline solution provided here). However, we believe that the decision to as well any decision to re-engage the voluntary system should require deriver intervention (much like intervention is required to disable the system). This is to meet safety requirements.

4.3 It is expected that the equipment developed will be compatible with as many vehicle types as possible, with a bias towards those vehicles commonly found on London’s road network.

Compliant We do not envisage any local London compatibility issues. ACS has developed solutions for a number of vehicle makes and models

(see sections 4.3.2.4, 4.4.1.4).

In terms of other vehicles, the requirement to fit each vehicle model includes:

Taking sensor readings (throttle and speed signal) for each model

Adapting hardware settings according to these readings

Developing an installation solution (including mounting positions, loom length and preferable wiring points)

Development of installation manual.

For older models (generally pre 1999) that do not have electronic throttle control an electronic throttle interface would need to be fitted.

Minimum (ideal) requirements for any vehicle to be compatible with the Speedshield ISA system are:

Easily locatable vehicle speed signal

Electronic throttle control

Easily accessible mounting position, with sufficient clearance for easy installation

Mounting position does not present servicing issues.

4.7 Absent signs have been included in the speed limit map to maintain the integrity of the map. Proposals of how this data will be worked with are expected in the tender responses,

Compliant The inclusion of Absent signs will make no difference to the way the Speedshield system operates. Mapflow will convert the ITN data format into a format suitable for Speedshield.




including any requirements for TfL (e.g. the purchase of mapping licences)

4.8 It is essential that the OBU allows a mechanism for the map held in the unit to be updated. It is expected that this will be done in a way which requires no input from the driver.

Compliant Our baseline method for the initial trial is to support map updates via an SD card. We believe this is adequate for the initial mobilisation and certification phases.

A system has also been developed to support wireless updates over 900mH RF and GSM spectrums. This is an option (costed separately) for TfL for the demonstration (30 vehicle) phase if required.

Bluetooth and Wifi update methods can also be supported.

4.9 TfL will supply SIM cards to be placed in the units. Updates would be sent to the vehicle via this SIM card, and the OBU would process the updates integrating the changes into the map.

Compliant, bespoke capability

Bespoke development costs to be priced separately.

4.10 It would be unacceptable if a user had to open the OBU and insert a memory card.



4.11 In the design phase, options for updating the map in times of exceptions (power failure) will be investigated. Currently TfL believe an internet based update system is ideal.



4.12 Ideally the update system would be able to generate a response from the OBU that the map has been successfully updated. In the case of a SIM card this may be in the format of a txt message response



4.13 It is essential that the ISA system work under normal circumstances without maintenance, for at least the period which vehicles are covered by factory warranty (3-5 years)

Compliant The Speedshield devices are designed to exceed an operational lifespan of 12 years; standard factory warranty for equipment supplied as part of this contract is 3 years.

4.14 There is a requirement for the unit to Compliant However, we would suggest an alternative location. We would suggest




withstand the ambient environment of an engine bay. Tolerance to factors such as exposure to moisture, temperature and vibration, are all key factors in ensuring that the unit does not fail under normal use

mounting the unit elsewhere in the vehicle (e.g. in boot, under seat, behind fascia) as space in engine bay is often at a premium and mounting in engine bay could cause issues if the vehicle requires other servicing/maintenance.

4.15 Please provide estimates for the likely size of the units

Compliant For a light vehicle, the on board unit is made up of 3 separate modules, each is 14cm by 3 cm by 12cm (to be mounted such that the largest face is horizontal). Modules can be installed stacked, or located separately. Ideally minimum clearance of 8cm between top of uppermost module (when on mounting bracket) and vehicle chassis or component to require easy installation. Wire loom is approximately 2 meters long with a general diameter of 1.5cm. Other wiring is considered insignificant.

4.16 The OBU must display some robustness to other attacks, such as those which may be as a result of fraud. Largely linked to the updating of the map the unit will need to only accept genuine updates and resist those attacks which are considered more likely. The unit must also resist physical attack and tampering once in place.

Compliant The OBU uses a proprietary data format which creates a security layer. No other steps to ensure data security have been required at this point, as to date, it has not been an issue. However, if it were required to increase security, options exist to not only providing firmware and software-based measures, but also a data validation system whereby the system notifies a server if data is uploaded without following the correct procedures. In this event the system would automatically send the file (with vehicle and locations details) to the server for inspection for signs of tampering.

4.17 The antennae should be as discrete as possible. TfL welcome suggestions on how to improve the accuracy of the OBU, given restrictions on antennae size. In particular, TfL is interested in using map matching / geofencing to add accuracy.

Compliant ACS supply as standard a ‘shark fin ‘ style combined GPS/GSM antenna. This antenna measures 60mm in height with base dimension 45mm by 80mm and has a magnetised base allowing for a range of mounting positions. For additional cost ACS can supply an internal GPS antenna that can be located discretely within the vehicle. For further cost ACS can develop a GSM antenna that is integrated inside the Speedshield OBU. ACS have experience with geofencing systems, generally for industrial ISA solutions. It is recommended that a vectorised dataset representative of individual road segments is more appropriate for speed mapping a road network.




The combination of the ANTARIS GPS positioning engine and the Enhanced Kalman Filter EKF™ algorithm provides precise navigation in locations with no or impaired GPS reception. Certification trials have been included in the proposed programme of work to measure the performance of the Speedshield device against a carrier phase GPS receiver which will provide an accurate truth source. Mapflow also has developed extensive map-matching expertise in a London environment, including as part of the TfL technology trials. If required this experience can also be applied to the proposed solution.

4.18 It is expected that there will be a simple HMI interface displaying the system status, the current speed limit and feedback on the vehicles speed against the posted limit.

Compliant Details on the HMI options available are provided in section 4.5.1.2 System status is provided with both the TAC display and PDA based applications. PDA applications have more capacity for detailed messages. System status feedback includes: system on/off, system malfunction, HMI disconnection, ‘off road’, ‘on road’, outside mapped area.

4.18 The OBU should also beep to notify drivers of a change in speed limit or in system status.

Compliant The Speedshield HMI flashes when the vehicle goes above the speed limit and also there is a notification beep

4.19 Care should be put into the design of the HMI, as TfL want to avoid any issues with driver distraction.

Compliant Detailed information on the HMI interface can be found in section 4.5.1.2

4.20 Tenderers should provide unit costs for production runs of 1000, 5000 and 10,000 units

Compliant Unit costs have been provided in the Commercial document.

4.21 The system developed should not compromise the approval of that vehicle to use the UK highway. In practice this means that the vehicles once fitted with the ISA solution, must comply with the Road Traffic Act 1988 – as amended the Road Traffic Act 1991 and any other relevant legislation

Compliant Compliance expected based on experience of the Australian legislation in this area. An optional study to be completed by TÜV has been included. This study will ensure that all aspects of legislation and health and safety are met and certified.

4.22/4.23/4.24 The system should be designed so that other companies can access the system

Commercial/contract discussion,

The back office (data capture and analysis) system can be licensed to TfL. Likewise, as outlined above, IPR in project deliverables such as




and load their own functions. Documentation should be provided that will enable this.

project reports will vest in TfL.

However, pre-existing background product IPR will remain vested in Mapflow and/or its third party licensors; and it is not anticipated that hardware components (such as Speedshield) will be ‘opened’ to third parties.

Any additional discussion in relation to IPR and/or the openness of the system will be considered as a contract issue.

5.1 Possible vehicle types which the unit may be fitted to are: - TfL pool vehicles (15 Toyota Prius

hybrid vehicles and 13 Vauxhall Astras)

- A London taxi (TX4) - A London bus (Volvo B7TL) - A diesel vehicle (Ford Transit

medium sized van)

Compliant, bespoke interface capability

For the demonstration it is proposed to only provide interfaces to the TfL pool vehicles (i.e. Toyota Prius and Vauxhall Astra).

Costs have also been provided for the development of interfaces to the TX4, Volvo B7TL and the Ford Transit.

5.2 As part of any final project other models may also be implemented

Compliant A standard fee for implementing Speedshield can be agreed with TfL. The only constraint is that for older (pre 1999) models there may be additional difficulties and associated costs to implement.

5.3 TfL will not provide resources to carry out the provision of engineering, and prospective suppliers must demonstrate that they have access to the necessary engineering resources to complete the work

Compliant Access will be provided to engineering resources for all stages of the project and also post implementation.

5.4/5.5 The fitting of the unit to the vehicles must be well documented so that it can be repeated if necessary by a fully qualified mechanic. The documentation should include a ‘trouble shooting’ section. This documentation must be released without restriction to TfL.

Partial Compliance The units will be fitted for the demonstration by a trained engineer (UK agent of Speedshield – IMPCO).

We would expect that a number of companies who could fit the devices would need to be trained and certified by ACS or by TÜV for installing the units, if there are large volumes of ISA units to be installed. In such cases documentation will be made available to TfL and other stakeholders under appropriate confidentiality agreements.




5.6 On road testing will need to be conducted to ensure the accuracy and performance of the unit. TfL provide a list of information that they are interested in knowing in the statement of work. The chosen contractor is expected to carry out this testing

Compliant In section 5.2.3.1 detail on the testing approach is provided. We have significant and relevant experience in running trials of ISA and road pricing technology.

6.1 Pricing will be based on a fixed price per element of work, as described in section 2.2.3

Compliant Rate card based and fixed price options have been included in the commercial proposal.

6.2/6.3 The times included in Table 1-3 in the statement of work are estimates, primarily for tender comparison. Tender’s are requested to also offer alternative timescales and rates if they feel that these are not realistic, along with a brief explanation of where the additional effort is required

Compliant See 6.1.

6.4 Tenderers should also identify any areas where they consider there to be a significant risk of cost fluctuations due to additional effort required and describe what may be involved/ give reasons for these fluctuations

Compliant We have taken care to create a project approach which minimises project risk (such as utilising existing product, reuse of TfL owned trials platform, phased approach with gate criteria).

We have provided outline costs for some additional tasks which TfL may wish to include but which we do not believe are necessary to achieve the goals of the project.

6.5 The contract is expected to run to April 2010 for the ongoing supply of ISA equipment to TfL. All tenderers are to provide a project plan for the development and deployment of ISA with an emphasis on the timing around the first test vehicles. It is also expected that the monitoring information will be collected for a period of 6 months.

Compliant A detailed project plan is provided in section 5.4.



5.0 IMPLEMENTATION PLAN AND APPROACH

5.1 OVERVIEW OF OUR PROPOSED APPROACH

The approach consists of a number of distinct phases with clear project gates at key points in the

programme of work. In the overall project, including the out of scope implementation phases, it is

proposed there are 4 gates at which point, there will be agreement with TfL that the next phase can

be embarked upon.

The above figure illustrates the project phases:

- Phase 0: Mobilisation;

- Phase 1: Certification;

- Phase 2: Fit for Purpose Demonstration;

- Phase 3: Implementation Preparation (outside of immediate project scope - see Appendix 2)

- Phase 4: Implementation/Roll-out (outside of immediate project scope - see Appendix 2).

Each of the in-scope phases is introduced below and described in more detail in the next section.

- The objective of the mobilisation phase (phase 0) is to ensure that project stakeholders are

aligned, project governance is established, and that and design gaps are identified and closed.



The Speedshield product will also be installed in a single TfL vehicle providing access to some

‘on-road’ testing within the first 2 months of the project;

- The objective of the certification phase (phase 1) is to ensure that the unit performs adequately

in the London environment. For example that the positional accuracy is sufficient;

- The demonstration phase (phase 2) is designed to ensure that there is a sufficient level of road

testing in a trials environment. Three sets of activities are envisaged within this phase:

o A 2 month control trial of all 35 vehicles. Each vehicle will be fitted with the unit but

with the voluntary accelerator control disengaged and the HMI disengaged. The purpose

of this phase is to collate a control dataset;

o A 4 month trial of all 35 vehicles, with 30 vehicles with the ISA unit fully engaged and 5

vehicles continuing as control vehicles;

o An optional trial to monitor driver behaviour with the ISA unit disengaged, to establish

whether drivers return to previous behaviour;

- On completion of the demonstration, the feedback both from the drivers and from the analysis

will be collated into a report and presentation that TfL can use to promote the benefits of ISA; it

is expected that TfL will have significant input to this report.



5.2 DETAILED PROJECT PLAN

5.2.1 PHASE 0 – PROJECT MOBILISATION

5.2.1.1 APPROACH

The primary objective of the project mobilisation phase is to ensure clarity for the project team and

key stakeholders as to the objectives, roles, approach and timescales for the project.

At the start of the project, a kick-off meeting will be held where the project team will agree and

confirm their understanding of the project’s objectives, the roles of the project team, the project

approach, key milestones, deliverables and issues and risks.

We will work within TfL’s Spearmint framework for the project management methodology for the

project, and during the project mobilisation phase we will develop a Project Initiation Document

(PID) for approval by appropriate senior management within TfL. This PID will include:

Background to and objectives for the project

An expression of project governance and resourcing

The overall approach to the project

Detailed project plans

An assessment of the project’s stakeholders and an engagement plan for these

A statement of the controls over the project, including how quality will be maintained.

Much of the more detailed content for the PID will be developed during the mobilisation phase, in

particular:

The detailed project plan

The detailed assessment of stakeholders and the engagement plan

The detailed project issues and risks.

During the mobilisation phase, two other key documents will be produced for agreement by TfL,

these being:

The design and requirements verification document – this document will provide:



o a clear functional definition for the system against which test plans can be

developed

o a function design formalising the functional processes to be delivered by the system

o a technical design and architecture to assess design and operational issues

The trials plan and acceptance tests definition – this document will detail the criteria against

which the solution will be tested, the nature of the tests that will be performed on the

solution and how the outcomes of these tests will be rated against the criteria. The plan will

be developed building upon our experience of specifying and managing technology trials for

TfL in a wide area. The document will provide:

o a test plan identifying resources; test procedures and base lining (“the truth”)

o a robust plan for repeatable data collection, storage and analysis

o an expression of how the results will be delivered in a clear and impactful way to

ensure the stakeholders get clarity of the outcomes.

We are proposing two options with regards to the leasing of up to 5 vehicles as requested in the

statement of work.

During the phase, a single pilot vehicle will be installed with the ISA solution. This will enable the

consortium to demonstrate to TfL during the project certification and testing phase the effectiveness

of the on-road performance and how the trials process will work.

Option 1 is to lease via TfL in a similar arrangement as to the Congestion Charging

Technology Trials. For this option we would:

Lease through TubeLines at Acton but they would bill TfL directly including for CC

charges;

Potentially park the vehicles at Windsor House

Insurance would be via TfL’s cover

Drivers would be sourced by TfL or possibly via Faber Maunsell

Option 2 is for the private leasing of the required vehicles;

The vehicles would be leased through a local dealer

Drivers would be provided by TfL or via Faber Maunsell



TfL has indicated that the cars provided by TfL in the demonstrations will be Toyota Prius or Vauxhall Astra. We propose that one of each vehicle would be sourced either via TfL or via private leasing for the certification and demonstration phases.

During this phase, the design for the data collection infrastructure and interfaces will also be

developed.

5.2.1.2 MILESTONES (GATE CRITERIA)

The table below is an indication of the of gate criteria that need to be passed before commencing

the next phase of the project.

Criteria Description Criteria Passed

Project Initiation Document agreed

Project Initiation Document agreed by TfL

Yes/no

Phase 1 costs agreed Costs for the product certification and testing phase agreed by TfL

Yes/No

Design & requirements agreed

The design and requirements verification document agreed by TfL

Yes/No

Trials and acceptance tests agreed

Acceptance test definition document approved by TfL

Yes/No

Pilot vehicle installed & configured

ISA solution installed into the pilot vehicle

Yes/No

Data collection interface and infrastructure specification developed

Interface and infrastructure design for the data to be collected

Yes/No



5.2.1.3 KEY DELIVERABLES

The key deliverables from this phase include:

Deliverable Description

Project plan Detailed project plan covering activities to the conclusion of the trials phase

Project Initiation Document Document that defines the nature of the project and fundamentally describes the objectives, how and when the objectives will be achieved and who is responsible

Design and requirements document

Document that captures TfL’s requirements of the ISA solution and the trial. The document will also detail the design of the consortium’s solution and will articulate how the solution meets TfL’s requirements.

Trials and acceptance definition document

Document that details the trials and acceptance process. This will include the criteria against which the solution will be tested, the nature of the tests that will be performed on the solution and how the outcomes of these tests will be rated against the criteria.

Pilot vehicle installation and configuration

Speedshield installed and operational in a single pilot vehicle

Data collection interface and infrastructure specification

Design for the data collection interface and infrastructure



5.2.2 PHASE 1 – PRODUCT CERTIFICATION/TESTING

5.2.2.1 APPROACH

The objective of this phase is to certify that the Speedshield product and its installation does not

negate the type approval of the test vehicle and that the ISA solution will meet the performance

criteria as defined in the mobilisation phase.

During the project mobilisation phase, a single pilot vehicle will have been fitted with the

Speedshield product. During the product certification and testing phase, the consortium will

demonstrate to TfL the effectiveness of the on-road performance and how the trials process will

work. This exercise will also provide an opportunity to demonstrate and agree the exact nature of

the trial outputs and subsequent analysis and reports. This exercise will ensure that the best value is

made of the time available during the demonstration phase.

As an option, for the pilot vehicle, TÜV will conduct a detailed review of the Speedshield product and

the nature of its installation. This assessment will be compared with the relevant legislation,

directives and standards to identify any areas on non-compliance. It is expected that TÜV will be

able to confirm that the Speedshield installation and application does not affect the type approval of

the vehicle nor invalidate the manufacturer’s warranty.







Pilot vehicle installation Speedshield installed and operational in a single pilot vehicle

Yes/no

Phase 2 costs agreed Costs for the demonstration phase agreed by TfL

Yes/No

Trials approach and outcomes confirmation

Confirmation of the trial approach and the nature of the data capture, analysis and reporting agreed by TfL

Yes/No

TÜV report completed TÜV report completed (OPTIONAL) Report complete

5.2.2.3 KEY DELIVERABLES



Interim report Interim report outlining the conclusion of the pilot performance trial, lessons learnt and early findings

Updated trials and acceptance plan

Trials and acceptance plan updated as appropriate to reflect the lessons learnt from the pilot and agreed by TfL

Data collection infrastructure in place

The interfaces and infrastructure necessary to collect the data for the trial is in place, tested and operational

Optional - TÜV report A report articulating the extent to which the installation does not negate the vehicle’s type approval and warranty.



5.2.3 PHASE 2 – FIT FOR PURPOSE DEMONSTRATION

5.2.3.1 APPROACH

The fit-for-purpose demonstration trial will be conducted in accordance with the plan agreed in the

mobilisation phase with any updates agreed from the product certification and testing phase.

Our experience underlines the need for clear trial procedures and administration to ensure data

collection is managed accurately with vehicles, routes, and trial runs. This experience stresses the

need for detailed administration and recoding of events by test mode, device, time, location and

vehicle. This allows test data to be analysed correctly against the appropriate events to discover

cause and effects.

It is proposed to operate the main trial in two stages:

Phase 1 - a two month phase where the 35 vehicles will be fitted with the ISA unit but is not

activated in terms of ISA control. This will allow baseline data on recognition of speed

restriction zone and driver behaviour to be amassed.

Phase 2 – a four month phase where 30 vehicles will have their ISA activated and five

vehicles where the ISA control remains deactivated to act as a baseline and to provide

control data.

Data will be collected throughout the trial and transferred to the back office systems for analysis.

The back office system to be used, called HUB, is a platform already owned and developed by TfL

and so will be a re-use of this investment.

Driver feedback surveys will be completed before and after the trials.

Following analysis, the data and conclusions from the trials will be presented to TfL in a format

agreed in the product certification and testing phase, including presentations and press releases as

appropriate to promote the benefits of ISA.







Data collected and analysed in accordance with plan

The trials have been conducted in accordance with the approach agreed with TfL and that the required data has been collected and analysed.

Yes/no

5.2.2.3 DELIVERABLES



Installation and configuration of solution in test vehicles

The solution is installed and configured in the test fleet

Drivers trained Drivers who will drive the trial vehicles are trained in the solution

Data collection, analysis and final report

A document that reports on the outcomes and conclusions of the ISA trial and presents recommendations for next steps

5.3 PROJECT ORGANISATION

5.3.1 PROJECT MANAGER

Nick Williams was the project and trials manager for the technology trials undertaken by TfL over a

four year period.

Nick has over thirty years experience in the Telecommunications, Hi-Tech and Consulting industry

sectors, the last thirteen at Partner and Director Level. He has strong commercial and

communication skills and is able to influence and work at Board Level. He has advised governments,

corporations and regulators around the world on a range of commercial and technical issues

associated with telecommunications. He has deep technical knowledge in fixed, mobile and satellite

telecommunications matters ranging from handset, network and server hardware technologies

through to software solutions for applications on mobile devices or on back office systems.

A full set of CVs is provided in Appendix A



5.3.2 PROJECT ORGANISATION AND PROJECT TEAM

The table below shows the depth and breadth of the required skills for the project available from

within the consortium member firms.

The proposed project organisation is as follows:

5.4 PROJECT TIMELINE AND RESOURCE SCHEDULE

A project plan for the first three phases of the project (0,1, and 2) is shown overleaf.

Project/Trials Manager

Nick Williams

Project delivery team

Product installation & configuration

team

Trials, data analysis and

reporting team

Data interfaces and infrastructure

team

Design and requirements

team

Mapflow

Consulting Stream

ACS

Quality AssuranceRichard Bryce



ID Task Name Duration Start1 Intelligent Speed Adaptation Study 261 days Mon 02/06/08

2 Phase 0 - project mobilisation 44 days Mon 02/06/08

3 Plan and hold project kick-of f meeting 10 day s Mon 02/06/08

4 Establish project gov ernance 10 day s Mon 02/06/08

5 Dev elop Project Initiation Document 20 day s Mon 16/06/08

6 Conduct requirements v erif ication exercise 20 day s Mon 16/06/08

7 Conf irm solution design 15 day s Mon 30/06/08

8 Dev elop interf ace specif ication 15 day s Mon 30/06/08

9 Dev elop trials plan 20 day s Mon 16/06/08

10 Dev elop acceptance test document 10 day s Mon 14/07/08

11 Install solution in pilot v ehicle f or Phase 1 29 day s Mon 16/06/08

12 Finalise Phase 1 costings 5 day s Fri 25/07/08

13 Prepare f or Phase 0 milestone sign of f 5 day s Fri 25/07/08

14 Conf irm Phase 0 completion 0 day s Thu 31/07/08

15 Phase 1 - Product certification and testing 45 days Fri 01/08/08

16 Conduct pilot demonstration trial 20 day s Fri 01/08/08

17 Conduct pilot data collection, analy sis and report 25 day s Fri 01/08/08

18 Ref ine and conf irm trials approach 5 day s Fri 05/09/08

19 Ref ine and conf irm reporting f ormat 5 day s Fri 05/09/08

20 Dev elop data collection sy stem 30 day s Fri 01/08/08

21 Finalise Phase 2 costing 5 day s Fri 12/09/08

22 Optional study - conduct TUV rev iew of solution 40 day s Fri 01/08/08

23 Prepare f or Phase 1 milestone sign of f 5 day s Fri 26/09/08

24 Conf irm Phase 1 completion 0 day s Thu 02/10/08

25 Phase 2 - fit for purpose demonstration 172 days Fri 03/10/08

26 Complete trial v ehicle installations 18 day s Fri 03/10/08

27 Manage trials logistics 150 day s Fri 03/10/08

28 Conduct driv er training 7 day s Fri 10/10/08

29 Phase 1 tests (35 v ehicles, ISA deactiv ated) 45 day s Tue 21/10/08

30 Collect phase 1 data 45 day s Tue 21/10/08

31 Phase 2 tests 85 day s Tue 23/12/08

32 Collect phase 2 data (30 activ ated, 5 deactiv ated) 85 day s Tue 23/12/08

33 Analy se data 20 day s Tue 21/04/09

34 Dev elop conclusions and draf t report 30 day s Tue 21/04/09

35 Dev elop supporting publicity material 10 day s Tue 19/05/09

36 Prepare f or Phase 2 milestone sign of f 5 day s Tue 26/05/09

37 Conf irm Phase 2 completion 0 day s Mon 01/06/09

31/07

02/10

01/06

May July September Nov ember January March May July September



The following table shows the schedule of resources against each key deliverable for each phase of

the project.

Deliverable Key contributing role Estimated mandays

Phase 0 – project mobilisation

Project Initiation Document Project/Trials Manager 17

Programme Manager/QA 3

ACS Product Manager 1

Phase 1 costs Project/Trials Manager 4



Design & requirements document

Project/Trials Manager 8

Mapflow Technical Lead 5


ACS Project Support 5


Trials and acceptance test document



ACS Project Support 5


Pilot vehicle installation & configuration

Installer specialist 28



Data collection interface and infrastructure specification


Phase 1 – product certification and testing

Interim report Project/Trials Manager 20


Data Analysts 26

Updated trials and acceptance plan



Data collection infrastructure in place


Mapflow Software Engineer 30

Phase 2 costs agreed Project/Trials Manager 10


Phase 2 – fit for purpose demonstration

Installation and configuration of solution in test vehicles

ACS Technical Team 63

Drivers trained Project/Trials Manager 2

Data collection, analysis and final report


Data analysts 40




5.5 PROJECT MANAGEMENT

5.5.1 PROJECT GOVERNANCE

The diagram below reflects the proposed outline governance structure for the Voluntary Intelligent

Speed Adaptation project. The actual constituency of the governance bodies will be agreed during

the early stages of the project mobilisation phase.

A Senior Responsible Owner (SRO) for the project will be identified from within TfL.

The ISA Project Board will be jointly staffed by senior stakeholders within TfL and senior

management of the consortium including the project manager and the SRO. This body will be

responsible for:

Demonstrating and communicating commitment for the project

Approving project plans

Make timely decisions when required

Monitoring project progress and remove barriers to progress

Ensuring project risks and issues are managed

Approve key messages and appropriate audiences for project communications

Project quality will be ensured by a representative from both TfL and the consortium. These

representatives will be independent from the project and will work jointly to ensure the projects

approach and deliverables achieve the required standard.

The ISA Project Manager is accountable for the overall completion and success of the project. He will

be responsible for managing all components of the project through the project delivery resources in

accordance with the project plan. He will be supported in this task by a consortium management

team who will ensure consistency and alignment across the consortium member companies.

Consortium management

team

ISA Project Board

Senior Responsible Owner

ISA Project Manager

Quality AssuranceTfL representative

Consortium representative

Project delivery resources

Requirements and solution design

Trials and acceptanceElectrical and

mechanical engineering



5.5.2 PROPOSED PROJECT METHODOLOGY

The project management methodology that will be used on the project is Spearmint, TfL’s project

management methodology in which key members of the proposed project team have prior

experience.

In conjunction with the project manager, the Project Board will agree the specific deliverables from

the Spearmint methodology that will be of value to the project in achieving its objectives.

5.5.4 RISK MANAGEMENT

The combined experience of Mapflow, Consulting Stream, ACS and IMPCO results in significant

reduction in risks for this contract. Because we propose using the proven Speedshield ISA system as

the vehicle OBU, risks associated with technology development, on time delivery of units and

specification non-compliance are also significantly reduced.

Our risk management approach is rooted in strong project management and project delivery

disciplines, ensuring that programme progress is tracked against consistent objectives and timelines,

and that potential risks are identified (and mitigated against) early in the project/programme life

cycle. Structures and processes used to effectively manage project risk include formal project scope

sign-off; regular, frequent progress status meetings, project steering meetings and peer group

reviews; as well as formal user acceptance processes.

Risk management is managed according to the following process:

Identification and analysis of risk – involves identification, agreeing, prioritising and assigning

responsibility for the management of specific key business and project risks.

Identification and analysis of controls – having identified the key risks the next step is aimed

at identifying and critically evaluating the controls currently in place to manage these risks.

Choice of risk management strategy; Mitigation - reduction of the risk through the

introduction of improved controls, Avoidance - rejection of some risks as unacceptably high

and discontinuation of the underlying activities, Retention - acceptance of the risk when this

is the most cost effective option.

Documentation of the process – effective documentation of risk management information is

critical to the success of the project. It is important that each risk be graded as to the

probability of the event occurring and the impact on the project should the event occur.

The sections below highlight some of the key risks for the project. The most important project risks,

as requested by TfL are identified first.



5.5.4.1 KEY RISK - MAP QUALITY

The most cited project risk relates to the quality of the underlying map database. If the database is

not current and accurate, user trust will be eroded and the success of the trials will be jeopardised.

As a result of the critical nature of this risk, the topic is described in some detail below.

There are four main ways in which speed data issues can present themselves: errors as a percentage

of speed transition or driving time, regular errors, omissions and poorly located speed transition

points.

Occasional errors

Occasional errors affect the entire driving population and are caused by drivers encountering errors

occasionally (in effect randomly). Drivers will accept a certain number of errors (estimated at no

more than 5% of all speed changes and no more than 2% of total driving time). More than this will

undermine the system (the higher the number of errors the greater the dissatisfaction). If the

number of errors reaches a critical level (different for each driver) they may discontinue use of the

system due to annoyance and/or a belief that using the system puts them at greater risk.

Regular errors

Drivers encounter regular errors because the dataset is not being updated thoroughly enough or in a

timely fashion. Even if the error is minor (e.g. inaccuracy in sign location causes a longer than normal

delay in speed transition), the significance of the error will compound as will driver dissatisfaction.

To deal with errors in the dataset, a streamlined error reporting system (generally web based) and a

streamlined update and validation system is necessary. It is probably beyond the scope of this

project to manage these systems fully - however they should be considered prior to full

implementation of an ISA product. With the experience of ACS and Mapflow in handling updates and

validation to road speed limit data, it will be possible to manage issues related to update of the data

set (due to errors, omissions or real world changes). Furthermore, as the dataset is geographically

limited and has been carefully collected and validated by a focused, highly trained team, the risk of

significant numbers of errors in the data set is low. From experience, errors in the data set tend to

increase as the geographical size of the data set increases, the training of collection/validation staff

decreases or the responsibility for the data accuracy decreases. Draft standards (GDF) to specify

road data quality standards are available and should be considered when specifying data

requirements for ISA applications.

Omissions

Omissions may not actually be errors. They may occur deliberately when a type of speed zone is not

included in the data set, for example variable speed zones (common around schools) or special

speed limits for certain vehicles (commonly trucks and buses). Non-inclusion of these data sets will

lead to driver frustration as they have to invest more workload in keeping note of speed zones and

may come not to trust the ISA system. Similar problems occur when large numbers of speed zones

are omitted.



Omissions should be dealt with by considering whether special zones should be included within the

data set prior to collection/compilation and by treating non deliberate omissions as errors.

Poorly located speed transition points

Driver frustration will occur if speed transition points, as determined by the system, do not allow

drivers to accelerate at an acceptable point when entering a higher speed zone, or that slow drivers

at a point that is considered too early when entering a lower speed zone. This may be due to a lag

within the system but may also be due to the location of speed transition points. Current ISA

systems step from one speed to another instantaneously, where as drivers (and vehicles) take a

discrete amount of time to speed up/slow down when entering new speed zones.

To deal with poorly located speed transition points, careful consideration of driver behaviour and

the definition of a speed zone is required. It must be accepted that drivers will exceed the posted

speed limit prior to encountering an increase in speed for situations such as merging onto highways

where they must achieve a much higher speed to safely join the flow of traffic. Similarly,

consideration of when a driver should have reached a lower speed limit must also be considered.

Note that different drivers will have different preferences and the use of different types of vehicles

will also affect preference. With ISA however, it is possible to incorporate some provision for

different driver or vehicles types and the data set (or the way the system handles the data set) could

be customised to suit. For example, the legal situation in Australia is that there is an approximate

250 meter zone either side of a sign where drivers may make a speed transition. This is not a

specification of any road authority and is not present in any road rule – it is a matter of policy for law

enforcement only. A system whereby drivers are able to have a transition zone (rather than a

defined point of speed change) is worth considering for ISA systems; however the data set must then

reflect this. It is beyond the scope of this project to consider transitional zones in the data set and a

decision should be reached by the relevant road authority in each region (TfL in this case) as to the

legal definition of a ‘speed zone’ and how speed transitions should occur (in accordance with driver

behaviour) prior to implementation of transitional zones within the dataset.



5.5.4.2 OTHER KEY RISKS

We have highlighted two other key risks in line with TfL’s request. These are described briefly

below.

Risk Category Description Impact Mitigation Strategy

SAFETY The nature of the solution (such as the HMI design or vehicle speed limitation) causes driver distraction or reduced control over the vehicle

The solution compromises the safety of the vehicle whilst in motion, leading to unnatural driver behaviour and even, potentially, accidents

The ACS HMI has been designed to be simple and clear and has been thoroughly tested across a large user base.

There also will be an opportunity in Phase 1 of the project (certification) to confirm formally that the HMI is of minimal distraction.

The solution also has a ‘kick-down’ speed override for those occasions where it is necessary to exceed the speed limit to avoid an incident. Again this has been thoroughly tested over a period of years across a diverse set of trials.

RELIABILITY The ISA solution does not work as required or as designed

The test duration is extended or the data collected is corrupted or unrepresentative

The consortium has selected a product with a proven track record in speed adaptation.

In addition, Phase 1 – Product Certification (months 3-4) is intended to demonstrate the effectiveness of the solution in a formal, measurable way before installation in the entire test vehicle fleet.

As a result, any reliability issues (though none are anticipated) will be identified and resolved early in the project.



5.5.4.2 OTHER RISKS

Finally, we have included some additional risks to be managed throughout the project. These are

based on our experience from other similar projects and should be included in the project risk

register as part the mobilisation phase. These – and other newly identified risks - will be managed

on an ongoing basis throughout the project.

Risk Category Description Impact Mitigation Strategy

ACCEPTANCE There is resistance to the technology by drivers selected for the trial

Unrepresentative test results are achieved as data from a cross-section of drivers is not able to be collected

A communication strategy to be developed to ensure drivers have a full understanding of the project approach and objectives.

REQUIREMENTS It is difficult to finalise TfL’s solution requirements and the overall scope of the trial

There is a potential increase to the project’s costs and/or duration

The requirements will be baselined in Phase 0 – project mobilisation. A change control process will be established and operated through the project governance structure. The cost and time implications will be articulated for each change request and these will be considered by the Project Board before approval.

RESOURCES The extended nature of the project and the part-time nature of certain project roles makes it difficult to co-ordinate the input from the project team members

There is a potential increase to the project’s duration

The detailed project plan to be developed in Phase 0 – project mobilisation will define the activities to be performed by each individual and when their input is required. This plan will be maintained by the Project Manager with adequate communication to the consortium member firms to ensure the resources are freed as required.



6.0 ‘POST-PROGRAMME’ STRATEGY TO PROMOTE WIDER SYSTEM ADOPTION

The tender documentation describes a requirement for the selected partner to demonstrate its

credentials in providing access to end user markets and the its capability to support high volume

production runs of units.

We have addressed each of these questions below.

Our market strategy to help support TfL migrate from a trials environment to a commercial and

consumer ‘end user environment’ is based on some or all of the following approach:

Create demand for technology by promoting benefits of ISA safety (reduced accidents),

financial (fuel savings, insurance savings, lower costs to society associated with road

crashes), societal (improved road user behaviour) crashes, and environmental (emissions

reductions) benefits of ISA through related forums, conferences, presentations, media

articles and through networking.

Establish community acceptance though on road trials with credible partners (such as local

authorities and motoring groups) to demonstrate technology reliability.

Release ISA sub-system components (vehicle monitoring, top speed and acceleration

limiting, driver verification) into the market to further community acceptance (target

government fleet, heavy vehicle operators and existing industrial ISA customers first) on the

basis of health and safety obligations, risk mitigation environmental obligations and fuel

savings.

Dissemination through the market place by encouraging ISA uptake by private users.

Supplement this with media promotion and public demonstration events.

Once speed-sign data sets become available, release advisory, voluntary and mandatory

systems to market (target government fleet, heavy vehicle operators and existing industrial

ISA customers first) on basis of health and safety obligations, risk mitigation environmental

obligations and fuels savings. For those already using component subsystems, market on the

basis of lower costs to achieve full voluntary ISA solution. Supplement this with media

promotion and public demonstration events.

Create relationships with manufacturers for system to be an optional inclusion on new

vehicles.

Use consumer safety rating authorities to introduce ISA systems into scoring protocols for

new vehicles. This will drive demand for manufacturers to fit system as standard.

Use demonstrated benefits to direct future legislation – supporting the inclusion of ISA

systems on all new vehicles sold after a certain date (as has been done for seatbelts, airbags

and electronic stability control).



The above strategy also includes the following ongoing marketing related tasks/exercises:

Regular market evaluation;

Customer needs identification;

Technology improvement and development;

Integration of related technology;

Ongoing production/manufacturing planning to allow for increased demand (leveraging

production/manufacturing capabilities for industrial ISA).

Each of the project partners brings skills and capability to support a strategy based on the above

principles:

ACS’s future business success is dependent on the transition of ISA systems from ‘niche R&D’

to ‘widespread adoption’. While price reduction (ISA units) and continued technology

development will assist this transition, changes in market awareness, driver attitudes, and

initiatives rooted in legislative and/or policy change will be as important, if not more

important. ACS is therefore acutely aware of the market development strategies which will

be required and is actively engaged in similar strategies elsewhere in the world.

Consulting Stream worked closely with TfL to generate significant outbound communications

and media coverage associated with the Congestion Charging technology trials. As a result,

the technology trials have achieved global recognition and TfL is consistently regarded as the

leading example of successful GPS based road pricing pilots.

Mapflow has already engaged with the LRSU to help co-promote the current Advisory ISA

system. This is being undertaken with TomTom, who have more than 10 years experience of

promoting, distributing and selling consumer products on a mass scale. TomTom remains an

advisor and participant in the proposed project. Mapflow also has customer and partner

relationships with motoring organisations (such as the AA) and insurance companies (such as

Norwich Union and AXA). Building stakeholder support for initiatives such as ISA would be

possible through these relationships.

TfL has separately indicated the potential requirement for up to 40,000 ISA units as part of a wider

roll-out. We do not anticipate any issues with the proposed production volumes. ACS, through its

more than 10 years of developing industrial and vehicle based ISA systems (including appropriate

outsourced manufacturing capability) has the requisite experience in this regard. We would be

happy to supply additional details of this manufacturing capability if requested.

Documents

TFL 2228 INTELLIGENT SPEED APPLICATION DESIGN AND ...mpainesyd.com/filechute/TFL ISA Proposal - Technical Response (fin… · Transport for London Intelligent Speed Application Design