Stage 2: Innovation and Assessment Requirements

Strategic Actions associated with this stage. This stream will collate the overall and detailed user needs for the innovation. These will be used to develop the pilot’s functional requirements or viewpoint, its physical context and the associated communication requirements. This step will utilise the user needs, collated within Stage 1 – aims and objectives, to develop a series of statements defining the requirements for the innovation. This step defines the functionality needed by the innovation to fulfil the requirements This step defines how the functionalities can be grouped into physical locations to form implementable innovation to fulfil the requirements This step, developed from the physical viewpoint, describes the communications links needed to provide implementable innovation and fulfil the requirements. This step, developed from the functional, physical and communications viewpoint, estimates the likely cost of implementing the innovation within the trial. Consideration may also be given to the potential total costs of implementing the innovation across the wider HA network following a successful assessment. The purpose of this stream is to determine key performance indicators (KPIs) for the pilot and develop the overall test methodology to assess these indicators. This stream will also consider the various impacts of the innovation and the likely cost of the overall assessment process. The extent and the practicality of the range of data collection issues would also be addressed. This step considers and determines the key performance indicators (KPIs) to be monitored by the pilot against which the impact of the innovation will be assessed. This step defines the methodology that will be used to measure and quantify the performance indicators defined in step 2.2.1. This step considers and estimates the impact that is anticipated through the implementation of the innovation in the pilot. This step estimates the likely cost of the assessment of the innovation within the pilot. The third stream in this stage is site selection. This includes developing the criteria for the consideration of the pilot site, traffic data analysis, health and safety assessment, environmental impact analysis and site identification. This step develops the criteria required to be fulfilled by the pilot site This step applies the criteria defined in step 2.3.1 to locations on the HA network or off road sites to identify the location of the pilot. After the completion of all three streams within Stage 2, consideration must be given to the overall viability and programming of the pilot. This will balance the estimated costs and impacts of the innovation itself, the assessment framework and the pilot location, identifying alternative procurement routes to ensure these provide flexibility for potential enhancements typically needed in pilots. This will be summarised within the full business case validating the assumptions made to support the continued investment within the pilot. Typical outputs that might be expected from this stage. Stage 1 Stage 3 Stage 3 Stage 4 Stage 5 No Yes

Step 2.1.1 - Determine Requirements

In 2000 the European Commission published the European ITS Framework Architecture. It describes the general ITS architecture development process. It has been updated and become a base document for European ITS Framework Architecture Deliverable Documents [EC 2004] FHWA produced a document on developing functional requirements for ITS projects [FHWA 2002A]. These are useful references for innovation requirement analysis in HA pilot projects, particularly for ITS projects.

An example of how this progression from functional requirements, through the physical to the communications requirements can be found in the Highways Agency Ramp Metering System Requirements Specification [HA 2006F] .

Within the overall boundaries and scope of the pilot as defined in Stage 1 there are likely to be three prime aspects to the description of the innovation requirements, namely:

  1. the functional requirements or viewpoint – this defines and describes what functionality is needed to be included within the pilot in order to fulfil the requirements of the user needs
  2. the physical viewpoint – this defines and describes how the functional architecture will be brought together into groups to form physical entities 
  3. the communication considerations – this defines and describes how the information is exchanged between different parts of the system.

These three aspects are applicable to all types of pilots, whether considering a complex technological innovation or the simple implementation of alternative practices. For all pilots it is essential to define what function or functions that are expected to be achieved by the innovation under consideration. This could range from simple statements such as: ‘This road cone shall be visible to drivers, with minimum legal eyesight, in good weather conditions from a distance of 100m’ to ‘This system shall correctly read and identify number plates from vehicles travelling up to 200kph’. These will all define what the innovation is expected to do.

For simple innovations there may be only limited physical requirements. A simple road cone must be able to withstand inclement weather conditions and statements as to the minimum expected environmental standards would be stated as part of the requirements. For a number plate recognition system the physical requirement would be more complex physical requirements perhaps specifying what would be required to be achieved on the roadside and within a control room.

With regard to the communication requirements this area would not be a consideration for a road cone pilot. However, for the number plate recognition system definitions of what data would be expected to be transferred between, for example the roadside and the control room, would be required.

For technology based pilots and trials, the Traffic Technology Division (TTD) Code of Connection should be applied where necessary. This is to assure that all connections to TTD devices, systems or services are not exposed to high levels of security risk. Applicants who wish to connect to TTD systems and services are required to follow the Code of Connection as defined within MCH1415.

Early involvement of the HA teams responsible for the future maintenance of the pilot will help to reduce ambiguities in the requirement, minimise the change of the requirement specification and provide a more resilient understanding of the time and cost for the design and implementation.