mch 2475 version 05 maintenance handover · pdf filecontrol centres (rccs) also fall within to...

© Crown Copyright 2008

First published 2008

Printed and published by the Highways Agency

MCH 2475 Ramp Metering Maintenance Handover

Procedures

MCH 2475 Issue B March 2008

Ramp Metering

Maintenance Handover Procedures

MCH 2475

B MCH 2475 with amendments Pete Kirby

Dave Hunter

Babar Malik

Julian Steed 17/03/08

A Reissued as MCH 2475 Pete Kirby

Rob Porter

Babar Malik


03 Initial Issue Pete Kirby

Rob Porter

Babar Malik


02 Draft for Client Approval Peter Kirby

Rob Porter

Babar Malik


01b Minor changes to Appendix E, Draft for Client Comment

Peter Kirby

Mike McMahon

Babar Malik

Rob Porter 16/08/07

01 Draft for Client Comment Peter Kirby

Mike McMahon

Babar Malik

Rob Porter

16/07/07

Originated Checked Reviewed Authorised Date

Revision Purpose Description

RAMP METERING Maintenance Handover Procedures

March 2008 i MCH 2475

Contents Section Page

Executive Summary iii

1. Introductions 1-1 1.1 Document Overview 1-1 1.2 RM Deployment 1-1 1.3 Fault Management and Maintenance Handover Procedures 1-1 1.4 System Stakeholders 1-3 1.5 Document Distribution 1-4 1.6 The ‘Primary Maintainer’ 1-4 1.7 Document Validity 1-4

2. Interim Maintenance Protocols 2-5 2.1 Overview 2-5 2.2 Peek Contract 2-5 2.3 System Functionality 2-6 2.4 Informal Fault Identification Mechanisms 2-6 2.5 Traffic Management Considerations 2-6

3. Full Maintenance Protocols 3-8 3.1 Overview 3-8 3.2 Fault Identification 3-8 3.3 Fault Management 3-8 3.4 System Components to Maintain 3-8 3.5 Stakeholder Maintenance Responsibilities 3-9 3.6 Response Times 3-10 3.7 Spares Equipment 3-12

Appendix A – Maintenance Sections of the Systems Specification (Contract) A-13

Appendix B – Note for Switching a RM System Off B-16

Appendix C – Detailed Fault Diagnosis and Rectification Protocols C-22

Appendix D – Maintenance Matrix of Responsibility D-33

Appendix E – Traffic Management Considerations E-35


March 2008 ii MCH 2475

List of Tables Table D.1 - Maintenance Matrix of Responsibility D-34

List of Figures Figure 1.1 - Ramp Metering Scheme Life Cycle 1-2 Figure B.1 - Area 9 & 11 RM Sites IP Address Shortcuts B-16 Figure B.2 - Switch Off Process – Steps 1 to 6 B-18 Figure B.3 - Switch Off Process - Steps 7 to 8 B-19 Figure B.4 - Switch Off Process - Steps 9 to 14 B-20 Figure B.5 - Switch Off Process - Steps 15 to 18 B-21 Figure C.1 - Site Monitor Page C-25 Figure C.2 - Fault Log C-26 Figure C.3 - Fault Tree - Key C-27 Figure C.4 - Fault Tree - System Faults C-28 Figure C.5 - Fault Tree - Comms Check C-29 Figure C.6 - Fault Tree - Slip Road Faults C-30 Figure C.7- Fault Tree - RMO Faults C-31 Figure C.8 - Fault Tree - MIDAS Faults C-32 Figure E.1 - The RM Vicinity E-35 Figure E.2 - Dealing with TM in the RM Vicinity E-36


March 2008 iii MCH 2475

Executive Summary The Highways Agency undertook a project to deliver 30 ramp metering (RM) systems by the end of March 2007. These systems are intended to increase the traffic flow capacity of existing motorway junctions by regulating the slip road traffic flows.

This document provides the necessary procedures to identify and manage faults which occur on the RM systems. The maintenance regime begins with immediate affect and shall continue until June 2008. This document does not cover any periodic inspections or planned maintenance activities which are the subject of a separate document within the full handover pack.

The various system stakeholders (multiple divisions of the Highways Agency, the RM system suppliers, network operators and the Highways Agency’s transmission service providers) and the boundaries and overlaps between the stakeholder’s interests and involvements within the RM project are defined.

The system supplier, IPL/ Peek, currently operate a maintenance contract to support the first 30 installations. The contract began following the first installation and will continue until June 2008. The key deliverables and contractual arrangements are detailed for additional information to support the handover into maintenance procedures.

The RM system is broken into its component parts and the stakeholders responsible for each component are defined. The mechanisms and processes to deal with the various types of faults are discussed. The stakeholder responsible for particular aspects of a fault is identified along with the corresponding response times. Further information to support these procedures is detailed within the appendices.

The document highlights the importance of understanding how RM relies on the existing infrastructure and how changes to any traffic behaviour may have a detrimental affect on the RM operation. For traffic management and road space booking tasks, procedures for consulting the RM operation are advised and defined.


March 2008 1-1 MCH 2475

1. Introductions

1.1 Document Overview

This document has been prepared to inform the appropriate stakeholders of their roles and responsibilities in maintaining the RM throughout the maintenance period, with immediate affect until the end of June 2008.

It forms part of a suite of documents describing the site selection, design, installation, calibration and maintenance of ramp metering sites on the HA’s road network as illustrated in Figure 1.1.

1.2 RM Deployment

The Highways Agency undertook a project to deliver 30 RM systems by the end of March 2007. The RM systems are located in the West Midlands and the North of England. The 30 sites have been installed in the following Highways Agency Areas.

♦ Area 9 (West Midlands) ♦ Area 10 (NW England) ♦ Area 11 (West Midlands) ♦ Area 12 (Yorkshire)

1.3 Fault Management and Maintenance Handover Procedures

In order to ensure that the RM systems continue to offer the optimal benefit to the network, appropriate fault management and maintenance handover procedures need to be defined.

The RM system blends elements of both technology and civil infrastructure. The technology and civils maintenance aspects require differing maintenance processes which are performed by various organisations. Further details about which organisation is responsible for which system component is provided in the following sections of these procedures.

The RM system is a fully automatic system which utilises data from the existing technology infrastructure. An unusual RM system maintenance requirement is the need to understand which components of the existing infrastructure the RM system utilises. If traffic management is deployed or an incident occurs which may affect the everyday traffic patterns, the operation of the RM may suffer and unnecessary delays may result. These maintenance procedures detail the processes to be taken to ensure that the RM system does not operate inefficiently.


March 2008 1-2 MCH 2475

Site SelectionIAN 103/08

Advice Regarding the Assessment of Sites for Ramp Metering

DesignMCH 2470

‘Ramp Metering Technical Design Guidelines’

Infrastructure Installation and Test

MCH 2471 ‘Ramp Metering Installation Guidelines’

System Installation and Commissioning

Evaluation5053147_04_02_027

‘Ramp Metering Operational Assessment Report’

Configuration Management

MCH 2472 ‘Ramp Metering Configuration Setup

and Management Guidelines’

CalibrationMCH 2473

‘Ramp Metering Calibration Guidelines’

Configuration SetupMCH 2472

‘Ramp Metering Configuration Setup and Management Guidelines’

System Procurement and Supply

MCH 1965

Operational StrategyMCH 2470

‘Ramp Metering Technical Design Guidelines’

Operation and Maintenance

MCH 2475‘Ramp Metering Maintenance

Handover Procedures’MCH 2474

‘Ramp Metering Operational Procedures’

Figure 1.1 - Ramp Metering Scheme Life Cycle


March 2008 1-3 MCH 2475

1.4 System Stakeholders

There are several stakeholders involved with the RM systems. The level of involvement of each party varies and covers a range of aspects such as site selection, design, construction, calibration etc. Whilst all these aspects are not core to a maintenance regime, it is important to ensure that all stakeholders are aware of the roles and responsibilities of the various parties. The following sections outline each of the stakeholders’ overall roles and responsibilities.

Highways Agency

The Highways Agency’s national Traffic Operations (TO) and Standards and Safety Research (SSR) directorates both have key interests in the system. SSR were responsible for designing, procuring and evaluating the initial 30 systems. Through the local contract with the TechMAC & MAC / SuperMAC, the TO Areas were responsible for the construction of the initial 30 sites and ensuring that the RM systems operate as needed and provide benefits to the Area network. The Regional Control Centres (RCCs) also fall within TO and they will play a role in ensuring network performance, of which RM involvement is a small aspect.

TechMAC & MAC / SuperMAC (the ‘Primary Maintainer’ see Section 1.6)

The local MAC and TechMAC were contracted to install the infrastructure and technology aspects of the sites. This includes, but is not limited to, the slip road loops, cabinets, ducts, chambers, safety barrier, anti-skid and the associated warning signs. The role of the SuperMAC is a single contract which encompasses both the TechMAC and MAC activities. In the context of this document, where Areas utilise an MA and a TMC contract, this should be considered the equivalent of a SuperMAC.

IPL/Peek (System Suppliers)

The contract to provide and install the RM system was let to IPL, with Peek acting as their subcontractor. IPL/Peek built the hardware and software, installed the equipment on site and was responsible for factory and site acceptance testing. IPL/Peek currently operate a maintenance contract with the Highways Agency to cover the aspects the RM system which they have supplied and installed. This includes the hardware and software for traffic signal controller and the RM controller, and the signal heads and all cabling to them. This contract began once the first RM site was installed and is scheduled to run until the end of June 2008. An extract from the contract is reproduced in Appendix A.

National Roads Telecommunications Service (NRTS)

At a national level, NRTS took responsibility for the Highways Agency’s communications network during early 2007 (actual dates were Area-dependant). For this reason, NRTS had limited involvement in the initial 30 sites. As the NRTS contract start date had been known for some time, it was always considered that NRTS would eventually take on the responsibility for maintaining the RM communications aspects.


March 2008 1-4 MCH 2475

There are several communications setups across the 30 sites as follows:

♦ Single BT line with broadband link to an individual RM system (no NRTS involvement).

♦ Single satellite with broadband link to an individual RM system (no NRTS involvement).

♦ Single BT line with broadband link serially, ‘daisy-chained’ to connect to multiple sites.

NRTS influenced the type of equipment procured and the techniques that were used to ‘daisy-chain’ the communications at adjacent sites.

1.5 Document Distribution

In order to ensure that the custodial maintenance period operates successfully with a minimum level of system downtime, the document will be distributed and agreed by all the system stakeholders who are as follows:

♦ Highways Agency SSR ♦ Highways Agency TO (on a national level) ♦ TechMAC (or SuperMAC) ♦ MAC (or SuperMAC) ♦ IPL/Peek ♦ NRTS

1.6 The ‘Primary Maintainer’

The first line maintenance will be the responsibility of the ‘Primary Maintainer’. The Primary Maintainer will be responsible for resolving faults or passing faults to the appropriate third party for resolution. Section 3 and Appendix C details the Primary Maintainer’s responsibilities and the processes for dealing with fault occurrences.

1.7 Document Validity

The document covers the fault management procedures to be followed with immediate effect until the end of June 2008. This period is concurrent with the scheduled end date of the existing Peek maintenance contract. Beyond this time period, it is expected that a similar maintenance protocol will be utilised, however as this has not been confirmed, this document is valid only until 30 June 2008 when it will need to be reviewed and revised as necessary .

This document does not cover any periodic inspections or planned maintenance activities which are the subject of a separate document.


March 2008 2-5 MCH 2475

2. Interim Maintenance Protocols

2.1 Overview

This section of the document outlines the interim maintenance procedures in place prior to handover.

2.2 Peek Contract

The installation of the first RM system was completed in June 2006. From the point of installation until June 2008, Peek operates a maintenance contract with the Highways Agency which covers the system aspects which they were contracted to supply and install. The Peek contract does not cover the wider infrastructure elements which are in place to provide the safe environment in which the systems reside (such as anti-skid, safety barrier, cabinet sites), nor does it cover the slip road loops, Motorway Incident Detection and Automatic Signalling (MIDAS) outstations or remote communications. Further details of Peek’s contractual requirements are located in Appendix A.

Peek’s contractual arrangement ties them into a system operational performance target. At the times when traffic conditions exist to switch on the RM (mainline occupancy is sufficiently high and mainline lane 1 speed is sufficiently low), Peek need to ensure that their equipment functions 99.5% of this time.

To ensure that Peek can deliver this level of service, they dial over the internet into each site daily to interrogate the system fault logs and perform a general check of the site to confirm that each site is free from errors and able to meter traffic when conditions prevail.

If faults are determined, Peek will log the fault and complete one of the following options:

♦ Fix the fault remotely. An example of this may involve issuing traffic signal controller commands or resetting the RM system software.

♦ Instruct one of their engineers to visit the site. This may include replacing lamps or traffic signal controller hardware.

Although not Peek’s contractual responsibility, Peek have been supportive by alerting Atkins or the local TechMAC / SuperMAC if the fault falls outside of Peek’s responsibility. This may happen if MIDAS outstations were not communicating with the RM software.


March 2008 2-6 MCH 2475

2.3 System Functionality

The RM Controller (RMC) is equipped with an automatic emailing system which alerts a nominated recipient of the faults of pre-determined categories. The system can deliver the fault notification to three separate email accounts in the form of the following three reports:

♦ Report 1 – Fault log contains ALL faults. ♦ Report 2 – Fault log contains CRITICAL faults. ♦ Report 3 – Fault log contains CRITICAL faults.

The emails can be sent on any specified day at a specified time to a single email recipient. Standard email client packages used by the email recipient (e.g. MS Outlook) can be used to filter and manage fault notifications once they have been transmitted by the RMC.

As the sites have not yet been handed over into maintenance, the email alerts have not been fully configured as an agreement with the individual Area’s Primary Maintainer is required.

It is suggested that the most suitable configuration for the emailed alerts is a daily email as follows:

♦ Report 1 – to the Primary Maintainer. ♦ Report 2 – to IPL/ Peek. ♦ Report 3 – unused.

All faults have a user-configurable severity. The Primary Maintainer may chose to reallocate these email addresses or manage them via an email client as appropriate.

The processes for managing faults are detailed in Appendix C.

2.4 Informal Fault Identification Mechanisms

Historically, faults on the RM systems have also been reported to Atkins or the Primary Maintainers by the Highways Agency Traffic Officers as well as members of the public and members of the particular local authorities.

2.5 Traffic Management Considerations

Early experience from one of the 30 sites highlighted a threat to the network’s operation if the appropriate procedures are not undertaken when deploying traffic management in the vicinity of a RM system. In this particular example, the road space booking process did not consider the RM system operation. The resultant lane 2 closure of the slip road caused the RM system to release only half the vehicles from the stopline that the algorithm had calculated were required. This low flow from the stopline created considerable congestion on the local authority roads. The congestion problem was compounded by the system algorithms calculating that the occupancy of the slip road, and therefore the length of queue, was only half the true value.


March 2008 2-7 MCH 2475

If traffic management is deployed on the mainline that results in vehicles running in the hard shoulder, the measured occupancy at the downstream site will not reflect the true conditions. This will lead to the RM signals delivering an inappropriate amount of traffic for that particular condition.

Appendix E provides an overview of how the RM system relies on and interacts with the local environment. Following this overview, advice is given for traffic management and road space booking procedures to avoid similar operational problems in the future.

Appendix B details the steps required to switch the RM systems on and off and should be read in conjunction with Appendix E.


March 2008 3-8 MCH 2475

3. Full Maintenance Protocols

3.1 Overview

This section of the document outlines the stakeholders’ responsibilities throughout the maintenance period. The information contained in this section merely indicates the general concept of responsibilities of system stakeholders. Details of the step-by-step protocols for fault resolution can be found at Appendix C.

3.2 Fault Identification

There are a number of ways in which faults within the system can be identified. These are all used to maintain the system during the Interim Maintenance Period as described in Section 2. These are summarised as follows:

♦ Peek analysts checking health of the system. ♦ Automated email fault notification. ♦ Scheme engineers, maintenance engineers, HA staff and members of the public

identifying faults / incorrect signal sequencing.

3.3 Fault Management

As the RM systems have been operating for some time now, an analysis of the faults received enables the type of faults and the frequency of them to be determined. The flow charts contained in Appendix C draw on this experience and is the suggested process by which the system stakeholders should address their responsibilities.

The flow charts detail the lifecycle of a fault from determination to rectification and are simplified in the steps below. Consideration has been given to the:

♦ Paths by which fault recognition is achieved. ♦ Fault logging process. ♦ How that fault is distributed (organisational) for resolution. ♦ Technical steps required to be undertaken to rectify that fault. ♦ Feedback loop which ensures that no secondary faults have occurred. ♦ Reporting procedures to accommodate the successful clearance of faults.

3.4 System Components to Maintain

A ‘RM system’ consists of several aspects as follows:

♦ The hardware and software technology components required to operate this kind of traffic control technique.

♦ The wider infrastructure elements which are in place to provide the safe environment in which the systems operate.


March 2008 3-9 MCH 2475

♦ The existing infrastructure which the system makes use of for operational purposes.

The maintenance arrangements for these three aspects are all approached by considerably different mechanisms. The technology components will be looked after by a combination of the TechMAC / SuperMAC, NRTS and IPL/Peek. The wider infrastructure elements are the responsibility of the MAC / SuperMAC, whilst the existing infrastructure which the RM system makes use of is covered by the TechMAC / SuperMAC.

To offer a more detailed level of RM system components, the following categories have been defined. A further breakdown of these aspects, and the ownership of them, is provided in Appendix D.

♦ Infrastructure ♦ Cabinets ♦ Cabling ♦ Loops and MIDAS ♦ Remote communications ♦ Ramp metering controller

3.5 Stakeholder Maintenance Responsibilities

Highways Agency - SSR

SSR are not tied to any maintenance responsibilities for the RM systems. SSR has been responsible for determining maintenance procedures and as such should remain involved to offer advice on any arising issues.

Until the RM systems are in full maintenance, SSR are providing handover into maintenance documents to the various local TO Area.

Highways Agency - TO

The Local TO Area is responsible for ensuring that the RM systems offer benefits to the motorists and the local area. This is top-level responsibility is merely an extension to the Area’s current regime of ensuring best-network performance.

Until the RM systems are in full maintenance, the local TO Area are also responsible for funding all maintenance costs.

TechMAC (or SuperMAC / MA & TMC)

The TechMAC will be the Primary Maintainer for the RM systems. The TechMAC will identify faults via the mechanisms outlined in Section 3.3 and provided in further detail in Appendix C. Both the automated email fault notification and the Peek routine health checks are reliant on the availability of remote Internet Protocol Communication with the RMC. Should the communications system fail, neither of these fault identification mechanisms will be effective. It is therefore essential that the TechMAC monitor the heath of the communications links on a daily basis. This may


March 2008 3-10 MCH 2475

be achieved by using the modem supplier’s health check software, or by manually logging onto each RMC.

Once a fault has been identified, the TechMAC will be responsible for rectifying that fault, or passing that fault onto the appropriate party for them to resolve. The TechMAC will be responsible for verifying that the fault has been rectified once they have been appropriately notified by any third party. The TechMAC will maintain a log of all faults and will take responsibility for tracking fault progress and ensuring a timely fault resolution. The log of maintenance activities will be sufficiently maintained to assist with trend analysis and future maintenance regimes.

Once the TechMAC have determined and investigated a fault, they will either rectify the fault themselves or pass the fault to the appropriate third party as detailed below. If that third party is IPL/Peek, then the TechMAC will also provide any traffic management required for the task.

The TechMAC will also be responsible for ensuring that any works on the network are considerate of the vicinity of that work in relation to the RM system, and the network assets on which the RM system relies. Further information and guidance on these issues can be found in Section 2.5 and Appendix E.

MAC (or SuperMAC / MA & TMC)

(As advised by the TechMAC) the MAC will be responsible for the wider infrastructure elements which are in place to provide a safe operating environment for the RM system.

The MAC will also be responsible for ensuring that any works on the network consider any RM system in the vicinity of the work, and the network assets on which the RM system relies. Further information and guidance on these issues can be found in Section 2.5 and Appendix E.

IPL/Peek

(As advised by the TechMAC) IPL/ Peek will be responsible for the system aspects as supplied and installed by them. This requirement falls under IPL/ Peek’s existing contract with the Highways Agency. IPL/ Peek do not provide their own traffic management for any works they undertake which requires it. This traffic management will be provided by the TechMAC.

NRTS

(As advised by the TechMAC) NRTS will be responsible for all communication aspects of the RM systems.

3.6 Response Times

There are several maintenance scenarios as follows:

♦ System shutdown. ♦ Fault rectification (restricting RM operation).


March 2008 3-11 MCH 2475

♦ Fault rectification (RM still operates). ♦ Knockdowns. All stakeholders will need to comply with the response times below for any equipment which falls under their responsibility. Appendix D details the stakeholders matrix of responsibilities.

3.6.1 System Shutdown

A system shutdown would be required when an incident occurs on the network which affects how the RM system reacts to traffic conditions. If a vehicle was broken down in or around the merge area, there is a high chance that the normal operation of the RM system will be unsuitable until the incident has cleared. The RM system should be switched off in these circumstances. In the event of such an incident, it will be clear on-street if the system needs to be switched off.

3.6.2 Fault Rectification (restricting RM operation)

There are several faults which, if they occur, will restrict the RM system from switching on. This may happen if the MIDAS outstations are not communicating with the RM controller, of if two red lamp failures have occurred. These faults require immediate attention to minimise any system downtime.

3.6.3 Fault Rectification (RM still operates)

There are a number of faults which will still allow the RM system to operate if they occur, but the performance may not be optimal. Lamp dimming faults and single aspect failures fall within this category.

3.6.4 Knockdowns

In the event of a knockdown, the site will need to be made safe. It is unlikely that a collision with the RM controllers will occur as the cabinets are all located behind safety barriers. The most likely knockdown would be to one of the passive poles which are not always located behind safety barriers. Once a pole has been struck, the site must be made completely safe, in terms of the ‘dotplug’ electrical connections and the removal of any debris from within the carriageway.

3.6.5 Response Time Periods

The fault scenarios detailed above require the following response times:

♦ System shutdown – 1 hour. ♦ Fault rectification (restricting RM operation) – 24 hours*. ♦ Fault rectification (RM still operates) – 48 hours. ♦ Knockdowns – 24 hours. *If the Main Carriageway Upstream Loop 1 was to fail, the TechMAC would have 28 days to resolve this particular fault.


March 2008 3-12 MCH 2475

3.7 Spares Equipment

♦ The existing contract with IPL/ Peek requires them to hold sufficient spares in order to meet their maintenance obligations. It is recommended that each stakeholder holds a level of spares appropriate to their system maintenance responsibilities.


March 2008 A-13 MCH 2475

Appendix A – Maintenance Sections of the Systems Specification (Contract) 4 SCOPE OF SUPPLY

The contractor shall provide, in accordance with the bill of quantities:

♦ Development, design, integration and project management (of the items described in this specification to produce a ramp metering system).

♦ Ramp metering controllers including application software and Human Machine Interface (Supervisory interface).

♦ Loop interface units (if required). ♦ LED signal heads. ♦ All interconnecting cabling with the exception of power, loop tails and existing

longitudinal. ♦ Installation and commissioning services on-site. ♦ Maintenance services. ♦ Design, operational and maintenance documentation. ♦ Operational and maintenance training.

The infrastructure, designed and implemented by others will provide:

♦ Inductive loops for vehicle detection. ♦ Roadside enclosure for the ramp metering controller. ♦ Roadside enclosure for the loop interface unit (if required). ♦ Buried ducts to carry cables. ♦ Mounting poles for signal heads. ♦ Fixed warning signs in advance of the stop line. ♦ Power supply to the ramp metering controller in the form of single phase mains

supply. ♦ Communications to/from the ramp metering controller through a remote

connection. ♦ MIDAS outstations where additional needed.

14 MAINTENANCE

The contractor shall provide maintenance support of a form described below to maintain the specified availability for a period that starts upon commissioning the first system and continues for all systems until June 2008 after successful on-site commissioning of the final system. It can be assumed that systems will be deployed on any part of the English motorway network.


March 2008 A-14 MCH 2475

Monthly performance payments are paid subject to meeting the service levels described below. The contractor can put forward a method for measuring service levels.

The contractor shall hold a number and selection of spares to enable the specified availability to be achieved.

A primary requirement of the system is the need to be easily enhanced and modified through evolution. Some of this evolution may take place during the maintenance period. In this case the contractor will only be responsible for the maintenance and performance of software, hardware and designs supplied by the contractor.

As part of this, the contractor will be required to work on live carriageways and must therefore provide, in advance, a method statement showing how the safety of the contractor’s workforce, road users and any others will be safeguarded.

In order to maintain a safe working environment on site, the contractor must adhere to any relevant procedures put in place by the Highways Agency’s Area Agent.

14.1 HARDWARE MAINTENANCE

The contractor shall provide on-site service to rectify any fault and restore the system to its state upon completion of successful commissioning within 24 hours of receiving notification of the fault.

The contractor may receive notification of faults by automated alert, e-mail sent by an individual, by telephone or written means.

The contractor shall put in place a means of regularly and remotely monitoring the health of each installed system and shall investigate and resolve any indication that there is a problem. Each installed system shall be checked at least daily.

14.2 SOFTWARE MAINTENANCE

The contractor will provide three types of software support:

♦ Issue resolution (non-critical). ♦ Issue resolution (critical). ♦ Software enhancement.

A non-critical software issue is one where the software is preventing the system meeting the performance required in this specification, however it is still possible to operate ramp metering at that site for the benefit of road users.

A critical software issue is one where the software is preventing the system meeting the performance required in this specification in such a way that it is not possible to perform ramp metering at that site.

A software enhancement is a feature or function that is requested or required and that is not currently defined in this specification.


March 2008 A-15 MCH 2475

The contractor shall resolve non-critical software issues within one month of notification.

The contractor shall resolve critical software issues within five working days of notification.

Resolution of software issues will be defined as tested and working software installed in all the relevant systems.

The contractor shall provide the Highways Agency with an escalation process if there is insufficient progress in the resolution of issues within 75% of the stated response time.

In response to a request for a specified software enhancement, the contractor shall respond within 10 working days with an estimate for the elapsed time and costed time to implement the requirement.


March 2008 B-16 MCH 2475

Appendix B – Note for Switching a RM System Off In certain circumstances it is necessary to switch off a ramp metering (RM) system at a particular junction. This is achieved by accessing the Supervisory Interface for that junction by using a login with the correct access level privileges. Once access to the site has been gained, the site activationMode within the SwitchOnOff algorithm is changed to ManualOff. This process is fully described in the following steps and shown diagrammatically in Figure B.22 to Figure B.5 5.

Each RM junction has a unique ‘external’ Internet Protocol (IP) address that is entered into the Internet Explorer1 (IE) address bar to access the site – these addresses may be stored as Favourites within Internet Explorer. Once all RM sites have a defined IP address then Atkins will provide a html file with all the IP addresses for the RM junctions in a HA Area (see Figure B.1).

To switch off a RM system a ‘User name’, ‘Password’ and ‘Write Password’ is required and these will be notified to each organisation by Atkins. Each junction will have unique passwords.

Figure B.1 - Area 9 & 11 RM Sites IP Address Shortcuts

1 The RM system only supports the Microsoft Internet Explorer browser. Other browsers may work but results cannot be guaranteed.


March 2008 B-17 MCH 2475

Ramp Metering Switch Off Process

(1) Enter the IP address of the site to be accessed in the IE address bar.

(2) Press Enter or Select ‘Go’.

(3) When the Security Alert dialog appears select ‘Yes’ to continue to the Login page.

(4) The Supervisory Interface login page for the RM site will be displayed. The name of the site appears in the top left had side. Check that the correct site has been accessed.

(5) Complete the login information:

(a) Enter a ‘User name’ that has write access permissions.

(b) Complete both the ‘Password’ and the ‘Write Password’.

(c) Press ‘Enter’ or click ‘Login’.

(6) Only one user can be logged in with write-access permissions. If someone is already logged in with write access permissions, repeat step (5) but tick the box to ‘force’ the other user out. (Note, this will inhibit the other user making any further changes.)

(7) When the Security Alert dialog appears select ‘Yes’ to continue to the Supervisory Interface ‘Home’ page.

(8) In the ‘Algorithms’ section click on the ‘Configuration’ link to expand the options.

(9) From the expanded ‘Algorithms Configuration’ section click the ‘SwitchOnOff’ link.

(10) Wait for the SwitchOnOff Parameters page to be displayed.

(11) Click the drop down box for the ‘activationMode’ parameter.

(12) Select ‘ManualOff’.

(13) Scroll to the bottom of the page.

(14) Click on the Submit button.

(16) The screen will refresh and advise whether or not the update was successful.

(17) The new activationMode is shown within the drop down menu.

(18) Having completed the change of activationMode for the RM site, log out of the Supervisory Interface using the link at the top right hand side of the page.

Ramp Metering Switch On Process

Repeat steps (1) to (18) above but at step (12) Select ‘timedOccupancy’.


March 2008 B-18 MCH 2475

Figure B.2 - Switch Off Process – Steps 1 to 6


March 2008 B-19 MCH 2475

Figure B.3 - Switch Off Process - Steps 7 to 8


March 2008 B-20 MCH 2475



March 2008 B-21 MCH 2475



March 2008 C-22 MCH 2475

Appendix C – Detailed Fault Diagnosis and Rectification Protocols

The Fault Tree shown in Figure C.3 to Figure C.8 is provided as a basis by which system faults can be investigated and assigned to the appropriate party to resolve. It is not intended to prescribe a particular method of fault monitoring or diagnosis, but follow a logical sequence of steps that could be used to isolate the cause of a specific fault.

The Fault Tree is based on the role of a ‘Primary Maintainer’ who has first line responsibility for:

♦ Receiving any fault notifications. ♦ Logging the faults and updates to the fault progress. ♦ Carrying out sufficient investigations to determine the cause(s) of the fault(s). ♦ Assigning the fault to the relevant organisation to resolve. ♦ Receiving notification of clearance of faults. ♦ Confirming the system is operational after the fault has been cleared. ♦ Logging the clearance of the fault.

The Fault Tree defines the Primary Maintainer as the TechMAC or SuperMAC (dependant on Area conventions).

‘System Faults’ Page

The Primary Maintainer would receive notification of a fault with the RM system by various means:

♦ Notification by third party (System Supplier, Regional Control Centre, colleagues on the network).

♦ Email alert when fault first raised; and ♦ Scheduled fault log (sent daily, weekly or monthly as required).

The notification of faults to the Primary Maintainer is dependant on the communications link to the site being operational and the equipment at the site being in a state whereby it can generate emails. If the communications link fails there would be no automatic notification of faults and thus the communications link needs to be checked regularly (for example, once a day).

Once notified of a fault, the Primary Maintainer would investigate and assign the fault to a party based by following the Fault Tree, starting with Figure C.4. They would log in to the system in order to check the Site Monitor (Figure C.1) and Fault Log (Figure C.2) for information about current faults.

Should they be unable to access the site, they would check the communications link following the steps in Figure C.5.


March 2008 C-23 MCH 2475

If the site is accessible remotely then a review of the Site Monitor and Fault Log will give a good indication as to the cause of the fault and to whom it should be assigned, based on three main categories:

♦ Slip Road Loop Faults – generally for the TechMAC to resolve but could be a System Supplier issue (see Figure C.6 - Fault Tree - Slip Road Faults)

♦ Ramp Metering Outstation Faults – generally for the System Supplier to resolve but there could be power issues for the TechMAC to resolve (see Figure C.7- Fault Tree - RMO Faults)

♦ MIDAS/OAL Faults – generally for the TechMAC to resolve but there could be issues for NRTS or the System Supplier to resolve (see Figure C.8 - Fault Tree - MIDAS Faults)

The TechMAC/SuperMAC may have to do some further investigation, as shown in the Fault Tree, before finally assigning a fault to a third party (e.g. confirming power to the site).

When the TechMAC/SuperMAC attends to a device/site to investigate a fault, they should record (and subsequently pass on) the status of any indicators (e.g. LEDs) that might aid a third party when the faults are transferred to them.

On rectification of a fault, the TechMAC/SuperMAC should be notified. They would then check that the fault has been cleared, confirm that no secondary faults have arisen, check that the system is operational again and log the clearance of the fault.

‘Comms Check’ Page

As the method by which communications to a RM site is provided varies from Area to Area the steps in Figure C.5 are intended to cover all current permutations. It is acceptable for each Area maintainer to amend the processes to suit their specific arrangements based on subsequent experience of fault finding communications problems.

If a site is inaccessible remotely, there could be a number of reasons for this:

♦ Fault with the physical BT line or satellite link to that site (pass to NRTS). ♦ Problems with the Internet account (pass to NRTS). ♦ Problems with power to the hardware that provides the end to end

communications link to a site (TechMAC/SuperMAC). ♦ Problems with the hardware that provides the end to end communications link to

a site (pass to NRTS). ♦ Problems with the cabling that provides the end to end communications link to a

site (pass to NRTS). ♦ Problems with the ramp metering outstation (pass to the system supplier).

If a site cannot be accessed the first step would be to try to connect to the ADSL modem/ firewall at the start of the communications link. If its configuration page can be accessed, this confirms that the BT or satellite link and associated Internet connection are operational.


March 2008 C-24 MCH 2475

When there are a number of devices/sites that form part of the link to a particular site, a logical step would be to check which of those devices/sites are accessible and which are not. This would narrow down the point at which the link fails. However, as the main purpose of the Fault Tree is to assign fault types to the appropriate party, the approach shown in Figure C.5 is to confirm the external communications to the first device (as described above) and check the status from the last point in the link (i.e. the RM controller).

If the first device in the link (ADSL modem/ firewall) cannot be contacted from the last point in the link then the fault is with the intermediate communications devices and/or cabling and thus would be transferred to NRTS (once TechMAC/SuperMAC have confirmed that power to these devices, for which TechMAC/SuperMAC are responsible, exists).

If the first device in the link (ADSL modem/ firewall) can be contacted from the last point in the link then the problem is likely to be with the ramp metering controller which can be confirmed by trying to access it locally – this fault would be transferred to the system Supplier.

‘Slip Road Faults’ Page

If one or more faulty loops are reported, the TechMAC/SuperMAC would attend site to isolate the loop and loop feeder from the ramp metering controller in order to determine whether these items were operating to specification. If the loop and/or loop feeder are faulty then the TechMAC/SuperMAC would arrange for their repair including any traffic management and possibly temporary Traffic Regulation Orders required.

NOTE: Certain slip road loop faults could cause the RM system to switch off until the fault has been cleared.

If the loop and loop feeder are operating within specification then the fault could lie with system supplier cabling, detection cards or related hardware. The fault would be transferred to the system supplier.

‘RMO Faults’ Page

Most faults reported in the fault log, with the exception of loop faults and MIDAS / Outstation Auxiliary Link (OAL) faults, would be transferred to the system supplier for resolution. However, if the problem was due to lack of power to the site then this would be for the TechMAC/SuperMAC to investigate, though it may get passed to the system supplier if their equipment is found to be tripping the incoming supply.

‘MIDAS Faults’ Page

As the MIDAS outstations used by RM are part of COBS (Control Office Based System) and report faults to Highways Agency LOGging ENvironment (HALOGEN) then any ‘MIDAS Faults’ reported by the RM systems should be checked on COBS/HALOGEN to help verify the cause of the fault. However, as COBS/HALOGEN does not cover OAL faults then further investigation will generally be required.


March 2008 C-25 MCH 2475

If one or more mainline loops are faulty then this would be for the TechMAC/SuperMAC to resolve.

NOTE: Certain mainline loop faults could cause the RM system to switch off till the fault is cleared.

If there are problems with one or more MIDAS Outstations (e.g. no link to a specific Outstation or no data from it) then further investigation is required to determine who to assign the fault to.

The fault would only be assigned to the System Supplier if all configured MIDAS Outstations were reported faulty by the RM Controller. If the RM Controller can communicate with one device on that OAL circuit then this indicates that the RMC is operational. The RMC can be checked by isolating it from the OAL circuit and monitoring its output with a MIDAS Outstation Testing Equipment (MOTE) or equivalent device.

NOTE: The RMC has two OAL ports but the Fault Tree assumes that only one OAL port is used as that is generally the case (valid for the first 30 installed sites).

If the RM controller is not at fault then the TechMAC/SuperMAC has to determine whether the fault is with the MIDAS Outstation(s) (hardware, software or configuration) for which they are responsible for maintaining or whether the issue lies with the cabling (quads, longitudinal or End Of Line resistors) which NRTS maintain.

Figure C.1 - Site Monitor Page


March 2008 C-26 MCH 2475

Figure C.2 - Fault Log


March 2008 C-27 MCH 2475

Figure C.3 - Fault Tree - Key


March 2008 C-28 MCH 2475

Figure C.4 - Fault Tree - System Faults


March 2008 C-29 MCH 2475

Figure C.5 - Fault Tree - Comms Check


March 2008 C-30 MCH 2475

Figure C.6 - Fault Tree - Slip Road Faults


March 2008 C-31 MCH 2475

Figure C.7- Fault Tree - RMO Faults


March 2008 C-32 MCH 2475

Figure C.8 - Fault Tree - MIDAS Faults


March 2008 D-33 MCH 2475

Appendix D – Maintenance Matrix of Responsibility

SuperMAC

(Area Team)

IPL/Peek

(System Supplier)

TechMAC

(Area Team)

MAC

(Area Team) NRTS

Routine Duties

Daily logging into site (normal working days) √ (contractual) √ (advisable)

Fault logging and management including allocation of Faults to other parties

√

Emergency shut down (24hr response) √

Standard Routine Maintenance as per existing contract

√ √ √ √

Cabinet Site and Access (including steps, handrail, paving) Note, this responsibility may be Area

dependant

√ √

Infrastructure

Barrier √

Road Surfacing and White Lining √

Fixed Plate Signs and associated poles (lit and unlit)

√

Active Queue Warning Message Sign √

Local Ducts and Chambers √ √

(if duct includes NRTS cabling to

a local SDP)

Longitudinal Ducts and Chambers √

Signal Heads √ 1. Make safe in event of

knockdown.

2. Provide TM for Peek if required.

Pre-wired Signal Poles √

Pre-wired Pole Signal Foundations √

Solar Cells √

Breakaway Plugs √

Cabinets

Power Cabinet (including fireman’s switch where fitted)

√

RMC Cabinet (including modem shelf and mains distribution)

√

Satellite Poles √

Cabling

Traffic Signal Cables √


March 2008 D-34 MCH 2475

SuperMAC

(Area Team)

IPL/Peek

(System Supplier)

TechMAC

(Area Team)

MAC

(Area Team) NRTS

Quad: MIDAS – C2 (OAL) √

Quad: RMC – C2 (remote communications) √

Quads: RMC – Interface Cabinet (BT/ITM/Fire station)

√

Power: EI to P √

Power: P to RMC √

Power: Street Lighting and Lit Signs √

Loop Feeders: Slip detection loops √

Quad: RMC to Active Queue Warning Message Sign √

Power: P to Active Queue Warning Messages Sign √

Loops and MIDAS

Slip Road Loops √

Mainline MIDAS Loops √

(Under current TechMAC

maintenance)

MIDAS Outstations on mainline √

(Under current TechMAC

maintenance)

Remote communications

Satellites plus associated Firewalls and cabling √

SHDSL network equipment √

BT lines plus associated Modems, Firewalls and Cabling

√

(within RCC)

√

(Direct to roadside or into Transmission

Station)

Ramp Metering Controller

TSC √ 1. Make safe in event of

knockdown.


Peek Chameleon √ 1. Make safe in event of

knockdown.


RMC Site Data √

Table D.1 - Maintenance Matrix of Responsibility


March 2008 E-35 MCH 2475

Appendix E – Traffic Management Considerations A ‘typical’ RM system comprises of four traffic signal heads, ten pairs of slip road loops and five main carriageway MIDAS outstations. The RM controller is located either on the nearside of the slip road or the nearside of the mainline within a standard communications cabinet.

The slip road loops and outstations continually read traffic data from the slip road and the mainline. The RM system operation relies on this continuous stream of traffic data and varies the vehicle release flow over the stopline (via the RM signal sequences) according to the data values obtained from the road side.

If traffic management is deployed within the vicinity of the RM system, the traffic behaviour will become altered in the area. As the RM system is finely calibrated at each site to reflect the individual characteristics of that site, significant changes to the traffic behaviour will affect the RM system operation in a negative way.

The Figure F.1 below highlights the parts of the network (‘the Vicinity’) which feed data to the RM system. If any traffic management is required to be deployed in the vicinity, the TechMAC should be advised so that the appropriate action may be taken.

Figure E.1 - The RM Vicinity

Office protocols to support Works within the vicinity of a RM system

It is advised that the local Area Road Space Booking applications are modified to include a section relating to the potential impacts on RM.

Figure F.2 below illustrates the information that needs to be obtained and how various TM interactions with a RM system are to be handled.

MIDAS Outstations

Traffic Signals

500m

~ 500m No TM ¼ mile

No TM ½ mile

Pairs of slip road loops

This is the area in which TM can affect RM operation. In the Flow Chart below, this area is termed the ‘vicinity of RM’

Diagram not to scale

Ramp Metering Enclosure


March 2008 E-36 MCH 2475

Figure E.2 - Dealing with TM in the RM Vicinity

mch 2475 version 05 maintenance handover · pdf filecontrol centres (rccs) also fall within to...

Documents