Ashghal ITS Deployment Manual v1.0
Ashghal ITS Deployment Manual v1.0
Version 1.0
January 2013
Contract #5 – ITS Consultancy Services – Task 1.9 ITS Standards,
Specifications and Deployment Manual
Version: 1.0
Revision Number: 5
Table of Contents
1 Introduction ........................................................................................................... 1
2 Systems Engineering Process ............................................................................. 3
3 Traffic Detection and Monitoring Systems ....................................................... 29
4 Closed Circuit Television Cameras ................................................................... 46
5 Roadway Weather Information Systems (RWIS) and Air Quality Monitoring
Sites ..................................................................................................................... 55
6 Over-Height and Over-Weight Detection Systems ........................................... 64
7 Dynamic Message Signs .................................................................................... 70
8 Lane Control Signs ............................................................................................. 84
9 Ramp Metering Systems..................................................................................... 91
10 Ducts and Chambers ........................................................................................ 116
11 Power ................................................................................................................. 117
12 Communication ................................................................................................. 123
Appendix A – Design Checklists.............................................................................. 132
List of Tables
List of Figures
1 Introduction
The purpose of this publication is to ensure the proper and consistent deployment of
ITS to support the Client’s transportation operations.
The above identified references are not the end-all for supporting documentation. In
addition to these references, additional resources and references may be identified
during the project development process. Also, all local requirements and
specifications shall be taken into consideration.
To help guide the reader through this document, the following icons are used to draw
attention to various parts:
The purpose of this section is to introduce the Systems Engineering (SE) process
and provide a basic understanding of how it will be applied to planning, designing,
and implementing ITS projects on the Client’s roadway network in Qatar. This
section leads the reader step by step through the project life cycle and describes the
SE approach at each step. It describes how to use the SE approach on ITS projects
to:
Increase the likelihood that an ITS project will meet the user’s needs.
Reduce the risk of schedule and cost overruns.
Develop more flexible, resilient systems and reduce the risk of obsolescence.
Verify functionality and reduce defects.
Improve documentation.
Why consider SE? Because applying the SE approach can improve the quality of
the system that is developed and reduce the risk of schedule and cost overruns.
The quality of the system can be improved because the SE process, through the
steps of requirements development and verification, can result in fewer defects in the
developed system. In addition, the process helps developers find the defects earlier
in the development process, reducing the cost of correcting the defects and reducing
the risk of schedule overruns. SE will not guarantee success, but it will help to
identify issues earlier in the project schedule and will improve the chances for a
successful project in the end. SE does this by focusing on the following key
principles2:
Stakeholder Involvement
Successful projects involve the customer, users, operators, and other
stakeholders in the project development. The SE process includes reviews
and decision points intended to provide visibility into the process and
encourage stakeholder involvement. The SE process involves stakeholders
through all stages of the project, from initial needs definition through system
verification and acceptance. The stakeholders who are involved in any
1
International Council on Systems Engineering (INCOSE), What is Systems Engineering?,
http://www.incose.org/practice/whatissystemseng.aspx, 14 June 2004.
2
Principles are taken from USDOT, Systems Engineering for ITS, An Introduction for Transportation
Professionals, January, 2007.
What exactly is the SE process? There have been many representations of it over
the years, but one that is commonly used in transportation is called the Vee model,
which is shown in Figure 2-1. This model defines a set of steps that any project
using SE can follow and covers the entire life cycle of the system being developed,
from the planning that occurs prior to the start of the project development all the way
through to the decisions that are taken to retire or replace a system once it is at the
end of the system life cycle.
ITS Project
Planning
An ITS Architecture defines the technical and institutional integration planned for ITS
deployments in a region. It is a tool to support ITS planning in the region, serving as
a guide for how different ITS-related projects fit together into an overall plan for the
deployment of ITS. For Qatar, this would be the State of Qatar ITS Architecture,
which is available through the Public Works Authority (Ashghal).
Each project that moves forward into development must be planned. The first step in
the application of the SE process is to create a Project Management Plan (PMP) and
Systems Engineering Management Plan (SEMP) for the development. The PMP
identifies the detailed work plans for both the administrative and technical tasks. The
plan estimates the resources (people, equipment, and facilities) needed for each
task along with an estimated budget for each task. Also, it identifies key events and
the technical and program milestones, and establishes a schedule for the project.
The PMP is the primary document for tracking the schedule and budget of the
project.
The SEMP is the top-level plan for organizing and managing all engineering activities
for the project. The SEMP defines how the SE portion of the work item will be
organized, structured, and conducted, and how the total engineering process will be
controlled to provide a product that fulfills customer requirements. The SEMP will be
used in technical management of this project, describing the process and steps to be
performed in the conduct of the project, and the roles and responsibilities of the
participants in the project. The SEMP describes how each SE subtask of the PMP
will be performed and completed, and defines the controls to ensure that each
subtask is completed correctly and on-schedule. The PMP focuses on the
management processes whereas the SEMP concentrates on applying the SE
structure. Templates for the PMP and SEMP are shown in Table 2-1 and Table 2-2,
respectively.
1.0 Purpose of The purpose of this document is the plan for execution of the project including
Document defining all necessary tasks and their products.
2.0 Scope of This section provides a brief description of the planned project and the purpose
Project of the system to be built. Special emphasis is placed on the project’s
complexities and challenges to be addressed by the project’s managers.
This section defines the project’s relationship to the State of Qatar ITS
Architecture. It also defines the relationship of the project’s system to other
systems with which it interfaces, either physically [with a data interface] or
operationally.
3.0 Project This section is the heart of the PMP. It defines each task of the project in terms
Tasks of the task inputs, approach, and outputs.
Outputs: A description of the products of the task. As with inputs, the outputs
may take many forms, including, but not limited to:
4.0 Work This section provides a hierarchical structure of all tasks and sub-tasks of the
Breakdown project, identifying the name of the task or sub-task, the allocated budget, and
Structure and the team or organization with the authorization and responsibility to perform the
Task Budgets task. The budget may not be allocated to each sub-task but may be allocated
to a higher level group of sub-tasks, tasks, or group of tasks, as necessary to
manage the project.
5.0 Schedule Development of a schedule for each task, for each sub-task, and for each
output of a task. This schedule is under complete control of the project’s
management by a variety of means, including the assignment of more or fewer
resources. This schedule takes into account the necessary precursors [inputs]
to each task or sub-task.
6.0 Deliverable This section is, as much as possible, a complete and precise list of the tangible
Requirements deliverables of each and every task. In general, a tangible deliverable may
List include, from the list of outputs of a task:
7.0 Referenced This section lists the applicable documents that are inputs to the project [that is,
Documents are needed by but not produced by the project].
1.0 Purpose This section is a brief statement of the purpose of this document and the plan for
of Document the SE activities with special emphasis on the engineering challenges of the
system to be built.
2.0 Scope of This section gives a brief description of the planned project and the purpose of
Project the system to be built. Special emphasis is placed on the project’s complexities
and challenges that must be managed by the SE efforts.
This section defines the general process for developing the SEMP, including the
draft framework version prepared by the Client or their Systems Engineer and the
complete version prepared in conjunction with the Systems Engineer and
development teams.
3.0 Technical This section lays out the plan for the SE activities. It should be written in close
Planning and synchronization with the project’s Project Plan. Unnecessary duplication
Control between the Project Plan and the SEMP should be avoided.
The purpose of the section is to describe the activities and plans that will act as
controls on the project’s SE activities. For instance, this section identifies the
products of each SE activity, such as documentation, meetings, and reviews.
This list of required products will control the activities of the team performing the
activity and will control the satisfactory completion of the activity. Some of these
plans may be completely defined in the SEMP. For other plans, the SEMP may
only define the requirements for a particular plan. The plan itself is to be
prepared as one of the subsequent SE activities, such as may be the case with a
Verification Plan or a Deployment Plan. Almost any of the plans described below
may fall into either category.
These plans should be prepared when they are clearly needed. In general, the
need for these plans become more important as the number of stakeholders
SECTION CONTENTS
involved in the project increases.
4.0 Systems This section describes the intended execution of the SE processes used to
Engineering develop the system. These processes are generically described in the different
Process steps of the VEE diagram. The SEMP describes the processes specifically
needed for a project in sufficient detail to guide the work of the SE and
development teams.
This section will contain a description of the SE steps (from the VEE diagram)
tailored to the specific project.
A Concept of Operations (ConOps) is a document, written from the user and the
Client’s point of view, that clearly defines the situation or problem scope, identifies
user needs, and the operational context for the project. The ConOps, therefore,
should be developed with participation from all users that benefit from or are
impacted by the system.
The purpose of the ConOps is to clearly convey a high-level view of the system to be
developed that each stakeholder can understand. This step of the process identifies
the user needs that must be addressed by the project – that is, what transportation
problem or operational need is the project or system to address. It documents a
clear definition of the stakeholders’ needs and constraints that will support system
requirements development in the next step.
This is a foundation step that frames the overall system and sets the technical
course for the project. A good ConOps answers who, what, where, when, why, and
how questions about the project from the viewpoint of each stakeholder, as shown in
Figure 2-2.
How – What resources are needed to develop, operate, and maintain the
system?
The ConOps is a powerful tool for defining needs since it forces the stakeholders to
think about the way the system will behave and how it will interact with users and
other systems. Interviews, workshops, and surveys are some of the techniques that
are used to develop a ConOps.
The following criteria should be used as the basis for documenting well-written
needs:
The list of user needs that is generated also should be prioritized by the
stakeholders. Once stakeholders start to compare and rank the user needs, they will
discover that some of their “needs” are really “wants” or “nice-to-haves”. A template
for the development of a ConOps is shown in Table 2-3.
1.0 Purpose This section is a brief statement of the purpose of this document. It is a
of Document description and rationale of the expected operations of the system under
development. It is a vehicle for stakeholder discussion and consensus to ensure
that the system that is built is operationally feasible. This will briefly describe
contents, intention, and audience. One or two paragraphs will suffice.
2.0 Scope of This short section gives a brief overview of the system to be built. It includes the
Project purpose and a high-level description. It describes what area will be covered and
which agencies will be involved, either directly or through interfaces. One or two
paragraphs will suffice.
3.0 The Here is a brief description of the current system or situation, how it is used
Current currently, and the drawbacks and limitations of the current system. This leads
System into the reasons for the proposed development and the general approach to
improving the system. This is followed by a discussion of the nature of the
planned changes and a justification for them.
4.0 This section contains a discussion of why the changes are needed and describes
Justification the user needs that the proposed system should meet. The user needs are one
for and of the key outputs of the SE process. User Needs are summarized in the C5 -
Nature of Concept of Operations document, and one or more of the needs found in the
Changes comprehensive list of user needs for Qatar in that document can be used as a
starting point for this section. Needs selected from this document for a specific
project may need to be edited to correspond with the intended scope of the
project.
5.0 Concept This section is an overview of the system to be developed. The section describes
for the the project scope, the users of the system, what it interfaces with, the states and
Proposed modes of the system, the planned capabilities, the goals and objectives, and the
System system architecture. Note that the system architecture is not a design [that will
be done later]. It provides a structure for describing the operations, in terms of
where the operations will be carried out, and what the lines of communication will
be. This section can be developed by starting with a selection of one or more
customized service packages from the Qatar ITS Architecture. Start by reviewing
each of the customized service packages in the Qatar ITS Architecture (found at
http://consystec.com/qatar/web/services.htm), and select those that are relevant
to the project. These selected customized service package diagrams can then be
combined and edited to create a project architecture identifying stakeholder ITS
elements and architecture flows of information between the selected ITS
elements.
6.0 Each scenario describes a sequence of events, activities carried out by the user,
Operational the system, and the environment. It specifies what triggers the sequence, who or
Scenarios what performs each step, when communications occur and to whom or what
[e.g., a log file], and what information is being communicated. The scenarios will
need to cover all normal conditions, stress conditions, failure events,
maintenance, and anomalies and exceptions. There are many ways for
presenting scenarios, but the important thing is that each stakeholder can clearly
see what his expected role is to be. Examples of project operational scenarios
are shown in the C5 - Concept of Operations document.
SECTION CONTENTS
7.0 Analysis This section describes the concept exploration, if one occurred, but will be
of Proposed removed if no set of alternatives was evaluated. It starts with a list and
System description of the alternative concepts examined. The evaluation and
assessment of each alternative follows. This leads into the justification for the
selected approach. This is not a design, but a high-level, conceptual, operational
description. It uses only as much detail as needed to be able to develop
meaningful scenarios. In particular, if alternative approaches differ in terms of
which agency does what, that will need to be resolved and described. An
example would be the question of whether or not a regional signal system will
have centralized control.
8.0 Applicable This section is a place to list any supporting documentation used and other
Documents resources that are useful in understanding the operations of the system. This
could include any documentation of current operations and any strategic plans
that drive the goals of the system under development.
9.0 This is a place to put a glossary, notes, and backup or background material for
Appendices any of the sections.
This purpose of this step of the SE process is to identify the system requirements
that will completely fulfill the user needs to be addressed by the project. One of the
most important attributes of a successful project is a clear statement of requirements
that meet the stakeholders’ needs. When considering the implementation of a
project, it is a good practice to understand the requirements of the devices and/or
systems being implemented. Knowing these requirements early in the project life-
cycle can alleviate potential problems during subsequent phases. Successful
projects rely on the understanding of functional, design, and testing requirements
before any procurement, development, or implementation.
Every project should have a documented set of requirements that are approved and
baselined. Each requirement should be derived based on the user needs identified
in the ConOps; some requirements may satisfy more than one user need, but the full
set of requirements that will be created will fully satisfy all the user needs identified in
Each requirement should use “shall” in the sentence, and above all, the requirement
should be measurable and testable. Functions should be defined in a manner
reflective of the nature of the operation, such as being manual, automated, or semi-
automated. The following criteria should be used when documenting and writing
requirements:
2.0 Reference Identifies all needed standards, policies, laws, concepts of operations, concept
exploration documents and other reference material that support the
requirements.
3.0 Functional requirements [What the system should do]. The Qatar ITS
Requirements Architecture Turbo Architecture database has functional requirements for
each stakeholder ITS element. These requirements can be used as a
resource for initially developing the project functional requirements.
Performance requirements [How well the requirements should perform].
An example of this type of requirement might be a requirement defining
how quickly (in seconds) traffic sensor information is displayed at the
center.
Interface requirements [Definition of the interfaces]. The Qatar ITS
Architecture Turbo Architecture database also includes recommended
open standards, where they exist, for each of the architecture flows.
Data requirements [Data elements and definitions of the system].
Non-Functional requirements, such as reliability, safety, and
environmental requirements [e.g., temperature range over which the
equipment must operate].
Enabling requirements [e.g. Production, development, testing, training,
support, deployment, and disposal requirements]. This can be developed
through references to other documents or embedded in these
requirements.
Constraints – [e.g., technology, design, tools, and/or standards]. For
example, the continuation where appropriate of legacy technology
investments in Qatar.
4.0 Verification For each requirement, identify one of the following methods of verification:
Methods Demonstration is a requirement that the system can demonstrate without
external test equipment.
Test is a requirement that requires some external piece of test equipment,
e.g., logic analyzer and/or volt meter.
Analyze is a requirement that is met indirectly through a logical
conclusion or mathematical analysis of a result, e.g., algorithms for
congestion. The designer may need to show that the requirement is met
through the analysis of count and occupancy calculations in software or
firmware.
Inspection is verification through a visual comparison. For example,
quality of welding may be done through a visual comparison against an in-
house standard.
5.0 Supporting Catch-all for anything that may add to the understanding of the Requirements
Documentation without going elsewhere [Reference section]
6.0 Traceability This is a table that traces the requirements in this document to the user needs
Matrix contained in the ConOps.
2.2.5 Design
The design step in the SE process can be broken into two distinct parts which will be
described below:
In high-level design, subsystems are identified and decomposed further into smaller,
more manageable pieces of functionality, called components. Interfaces are
specified in detail, requirements are analyzed and derived, and all requirements are
allocated to the system components. The definition of interfaces in high-level design
permits identification of the standards that will be used. The definition of subsystems
and interfaces defines a project architecture, which can be developed as a subset of
the regional ITS architecture. If the project architecture, as envisioned, differs from
the representation in the regional ITS architecture, a revised project architecture
should be created that accurately reflects the project. If there are alternative
approaches to implementing the project, alternative architectures should be
developed and evaluated in order to select a desired approach.
One of the key activities of high-level design is to develop and evaluate alternative
high-level designs. To do this, the system is partitioned into subsystems and the
subsystems are partitioned into smaller assemblies in turn. The partitioning process
continues until system components – the elemental hardware and software
configuration items – are identified. The partitioning is driven by many factors
including consideration of existing physical and institutional boundaries, ease of
development, ease of integration, and ease of upgrading. One of the most important
objectives is to keep the interfaces as simple and as standard as possible.
There are times when an informal high-level design is all that is required. If the ITS
project being developed is a stand-alone system or a system that is in a single “box”
that will be developed by a single group, the project doesn’t need a lot of high-level
design because the project will be dealing with few external or internal interface
issues. Take a look at the size and complexity of the project, particularly the number
of components and interfaces, to determine whether a formal high-level design is
warranted.
As shown in Figure 2-1, there are key decision points that occur at the conclusion of
High-Level and Detailed design. These usually take the form of design reviews,
where the customer and the project team review the design and approve moving to
the next step in the development process. In addition, in parallel with the
development process the project team must obtain any approvals required to deploy
the project (such as environmental approvals).
A template for the development of design documentation is shown in Table 2-5 and
Table 2-6.
1.0 Purpose of This section is a brief statement of the purpose of this document. It is a high-
Document level description of the architecture [hardware and software] of the system. It
summarizes the contents of the document.
2.0 Scope of This section gives a brief description of the planned project and the purpose of
Project the system to be built. This section can be copied from a previous document,
and is included for completeness. This may be the only document which some
project participants and stakeholders may see.
3.0 Sub- This section describes the architecture of the system and how it is divided into
systems sub-systems, when that is found to be necessary. Simpler systems may not
need to be subdivided, and if so, this section is void.
4.0 Hardware This section identifies the hardware components of each sub-system. It
Components identifies them by name, function, capabilities, source [manufacturer], and
quantity. It shows the interconnections between the components [e.g., point-to-
point or local area network]. If a hardware component needs optional
SECTION CONTENTS
components or features, they are listed and defined at this time.
This section also includes a trace of requirements, where applicable, into the
hardware components.
5.0 Software This section describes the preliminary design of the software application. It
Components shows the allocation of the software to sub-systems and to hardware elements.
It shows and identifies the COTS software packages to be used, and their
allocation to sub-systems and to hardware components. It also
shows/identifies all custom-designed software packages and their allocation to
sub-systems and hardware components. It shows the architectural relationship
between the various software packages, both custom and COTS.
6.0 Sub-system This document may be used to describe additional requirements that were not
Requirements covered in the requirements specifications. These may include, but are not
limited to:
These types of requirements [with the exception of the last type] also may be
included in the Requirements Document or documented in separate
documents, as deemed appropriate.
1.0 Purpose of This section is a brief statement of the purpose of this document. The purpose is
Document to expand and complete the preliminary design descriptions included in the High-
Level Design Document.
2.0 Scope of This section describes the project and may be copied from the High-Level Design
Project Document.
SECTION CONTENTS
3.0 Sub- This section completes the description of the system architecture and the sub-
systems systems, as necessary.
4.0 Hardware This section completes the description of the hardware components. It contains
Components a detailed list of the exact hardware items to be procured by name, part number,
manufacturer, and quantity. If necessary, it lists any hardware component
specifications or drawings which have been prepared by the design team.
5.0 Software This section completes the description of the software components. It contains a
Components detailed list of the COTS software products to be procured, by vendor, name, part
number, and options.
If the project involves custom software applications, this section becomes the
dominant and largest part of the Detailed Design Document. The section
purpose is to provide enough information so the code can be developed, and so
the code can be understood for maintenance and system upgrades. As a result,
the overriding requirement is that the descriptions of the software components
are complete and the link between these descriptions and the actual source code
is clear and explicit.
The next step of the SE process is the procurement, development, and installation of
the various hardware and software components of the project, based on the project
specifications. This step may involve the selection of a contractor to provide the
desired components of the system to be procured, based on the requirements and
design from the previous steps. Once a development team is on board, the SE team
primarily provides technical oversight as an implementation team of hardware and
software specialists create the detailed component-level design, fabricate the
hardware, and write the software programs. Some of the key activities of this step
are:
control tools, third party application libraries, test simulators, etc. Every tool
that is used should be documented specifically enough so that the
development environment can be replicated if necessary.
Develop software and hardware – The software is written and the hardware is
built based on the detailed design. On most projects, there is an easy
transition from detailed design to software/hardware construction because the
same person that does the detailed design for a specific part of the project
also writes the software for that part. The current state of the practice is to
develop the software incrementally and release the software in stages. The
initial releases implement a few core features and subsequent releases add
more features until all requirements are satisfied. This incremental approach
enables early and on-going feedback between the customer and the
implementation team. If this approach is used, a staged delivery plan should
define the order in which the software will be developed and the staged
release process.
2.2.7 Testing
After the development and installation of the system, the next step of the SE process
involves testing. From the Client’s perspective, the primary purpose of testing is to
verify that the requirements stated in the Client’s specification are delivered by the
contractor. Technically, testing is performed for verification and validation:
Testing also validates that the system satisfies the user needs; that is, the
right system was built.
The right side of the Vee model in Figure 2-1 is all about verification and validation.
A complete ITS device testing program consists of many phases of testing, taking
place in a methodical approach. Overall, the testing program should cover all
requirements leading to a complete system including electrical requirements,
For ITS projects in Qatar, the following specific testing requirements apply:
Refer to the General Provisions for ITS specification within Ashghal ITS
Specifications for specific requirements for each of the above phases of testing.
Test Design. References the test cases applicable to a particular test plan
associated with the test design. The test design also references the features
(requirements) to be tested.
Test Cases and Procedures. Describe the inputs, outputs, expected results,
and procedures used to verify one or more requirements. A Verification
Procedure Template is provided in Table 2-11.
2.0 Scope of This section gives a brief description of the planned project and the purpose of the
Project system to be built. Special emphasis is placed on the project’s deployment
complexities and challenges.
This section may be copied from earlier documents. It is important only to people
[stakeholders] who will be introduced to the project for the first time by this
document.
3.0 This section informs the reader what the high-level plan is for integration and,
Integration most importantly, why the integration plan is structured the way it is. As
Strategy mentioned before, the Integration Plan is subject to several constraints,
sometimes conflicting constraints. Also, it is one part of the larger process of
build, integrate, verify, and deploy, all of which must be synchronized to support
the same project strategy. For even a moderately complex project, the integration
strategy, based on a clear and concise statement of the project’s goals and
objectives, is described here at a high, but all-inclusive, level. It may also be
necessary to describe the analysis of alternative strategies to make it clear why
this particular strategy was selected.
This section covers and describes each step in the integration process. It
describes what components are integrated at each step and gives a general idea
of what threads of the operational capabilities [requirements] are covered. It ties
the plan to the previously identified goals and objectives so the stakeholders can
understand the rationale for each integration step. This summary level description
also defines the schedule for all the integration efforts.
4.0 Phase 1 This, and the following sections, define and explain each step in the integration
Integration process. The intent here is to identify all the needed participants and to describe
to them what they have to do.
SECTION CONTENTS
5.0 Multiple This, and any needed additional sections, follows the format for section 3. Each
Phase covers each step in a multiple step integration effort.
Integration
Steps [1 or N
steps]
3
Table 2-8: Verification Plan Template
SECTION CONTENTS
1.0 Purpose of This section identifies the type of verification activity to be performed within this
Document Verification Plan. For instance, this activity may verify the entire system, a sub-
system, the deployment at a site, a burn-in test, or any other verification activity.
2.0 Scope of This section gives a brief description of the planned project and the purpose of
Project the system to be built. Special emphasis is placed on the project’s complexities
and challenges that must be addressed and verified by the SE efforts.
3.0 Referenced This is a list of all documents used in the preparation of this Verification Plan.
Documents This almost always includes the Project Plan, the SEMP [if one was written],
and the applicable Requirements Documents. However, reference of other
documents, such as descriptions of external systems, standards, a ConOps,
and manuals may need to be included.
4.0 Test This section provides details on how the testing is accomplished. It defines who
Conduct does the testing, when and where it is to be done, the responsibilities of each
participant before, during, and after each test; the hardware and software to be
used [and other systems as well], and the documents to be prepared as a
record of the testing activity. Another very important part of this section defines
how testing anomalies are to be handled [that is, what to do when a test fails].
3
IEEE 1012-1998 Independent Verification and Validation
SECTION CONTENTS
5.0 Test This section is the heart, and largest, section of the Verification Plan. It
Identification identifies the specific test cases to be performed. A test case is a logical
grouping of functions and performance criteria [all from the Requirements
Documents] that is to be tested together. For instance, a specific test case may
cover all the control capabilities to be provided for control of a changeable
message sign. There may be several individual requirements that define this
capability, and they all are verified in one test case. The actual grouping of
requirements into a test case is arbitrary. They should be related and easily
combined into a reasonable set of test procedure actions.
Each test case should contain at least the following information:
A description name and a reference number.
A complete list of the requirements to be verified. For ease of tracing of
requirements into the Verification Plan and other documents, the
requirements are given numbers. They can be accurately and
conveniently referenced without repeating all the words of the
requirement.
A description of the objective of the test case, usually taken from the
wording of the requirements, to aid the reader understanding the scope
of the test case.
Any data to be recorded or noted during the test, such as expected
results of a test step. Other data, such as a recording of a digital
message sent to an external system, may be required to verify the
performance of the system.
A statement of the pass/fail criteria. Often, this is just a statement that
the system operates per the requirements.
A description of the test configuration. That is a list of the hardware and
software items needed for the test and how they should be connected.
Often, the same configuration is used for several tests.
A list of any other important assumptions and constraints necessary for
conduct of the test case.
2.0 This section gives a brief description of the planned project and the purpose of
Scope of the system to be built. Special emphasis is placed on the project’s deployment
Project
complexities and challenges. This section may be copied from earlier
documents. It is important only to people [stakeholders] who will be introduced to
the project for the first time by this document.
The significant goals and objectives guiding the deployment strategy should be
relatively few [no more than a dozen] and need to be clearly stated in this section.
SECTION CONTENTS
Some typical examples of goals and objectives include:
The funding profile for a multi-year project which limits the scope of
deployment in a single year.
Development and installation prerequisites. An analysis of the system
may show that feature A must be deployed first before features B, C, or
D, all of which need A to function.
Construction activities that must precede deployment.
Deployment of interfacing systems [especially by other agencies] that
must precede deployment of a system feature.
The need to create a viable operational capability at each stage of the
deployment. This influences how much of the system must be deployed
at each step.
4.0 This, and the following sections, define and explain each phase of the
Phase 1 deployment. The intent here is to identify all the needed participants and to
Deployment
describe to them what they have to do. In general, each phase description
should identify:
5.0 This, and any needed additional sections, follows the format for Section 4. Each
Multiple covers each step in a multiple step deployment effort.
Phase
Deployment
Steps [1 or N
steps]
2.0 This section gives a brief description of the planned project and the purpose of
Scope of the system to be built. Special emphasis is placed on the project’s complexities
Project
SECTION CONTENTS
and challenges that must be addressed by the SE efforts.
This section also describes the environment in which the project operates. It
identifies the organization structures that encompass all stakeholders. It also
gives a brief description of the role to be played by each stakeholder. This
includes ad hoc and existing management work groups and multi-disciplinary
technical teams that should be formed for supporting the project.
3.0 Referenced This is a list of all documents used in the preparation of this Validation Plan.
Documents This almost always includes the PMP, the SEMP [if one was written], and the
ConOps. However, reference of other documents, such as descriptions of
external systems, standards, and manuals may need to be included.
4.0 Validation This section provides details on how the validation is accomplished. It defines:
Conduct who does it; when and where it is to be done; the responsibilities of each
participant before, during, and after each event/activity; the hardware and
software to be used [and other systems as well]; and the documents to be
prepared as a record of the activity.
In general, the following information should be included in this section:
5.0 Validation This section identifies the specific scenarios and other events to be performed.
Event For Validation, scenarios can be clustered around a typical operator’s use of the
Identification system. It may also be structured around the operational needs defined in the
baseline ConOps.
Each event should contain at least the following information:
A description name and a reference number.
A complete list of the needs to be validated. For ease of tracing into the
Validation Plan and other documents, the Needs are given numbers.
They can be accurately and conveniently referenced without repeating
all the words from the ConOps.
A description of the objective of the event, usually taken from the
wording of the Needs.
Any data to be recorded or noted during the event.
SECTION CONTENTS
A statement of the pass/fail criteria. Often, this is just a statement that
the system satisfies the needs.
A description of the system configuration. This is a list of the hardware
and software items needed and how they should be connected. Often,
the same configuration is used for several events/scenarios.
A list of any other important assumptions and constraints necessary for
conduct of the event.
2.0 Verification This section identifies the equipment and software to be verified. It also
Configuration identifies all equipment and software necessary for this verification activity that
and Software is external to the system / sub-system configuration under test. This may
Under Test
include special test equipment and any external systems with an interface to the
configuration under test. For the hardware / software configuration under test,
this section identifies:
3.0 Verification This section describes the steps to be taken to set up each verification
Setup configuration, including, but not limited to, tuning of the hardware, configuring
and starting the software, starting the special test software, and set-up steps at
each external system to be used.
4.0 Verification This section describes the step-by-step actions to be taken by the verification
Procedures operator for each verification case. Each step includes:
Operator action to be taken. This operator action may be, for example,
an entry at a workstation, initiation of a routine in the special test
software, or an action at an external system.
Expected result to be observed. This too may take several forms, for
example, display of certain information at a workstation, a response at
an external system, recording of data for subsequent analysis, or an
action by a field device.
Pass / fail entry space. Here the verification conductor records whether
or not the expected result occurred. If the expected results are not
observed, the procedures for dealing with failures contained in the
Verification Plan are invoked.
SECTION CONTENTS
A trace of each verification step from a verification case in the
applicable Verification Plan and a trace from a requirement in the
applicable Requirements Document.
2.0 This section identifies the equipment and software verified. It also identifies all
Identification of equipment and software necessary for this verification activity that is external to
the the system / sub-system configuration under test. This may include special test
Configuration
equipment and any external systems with an interface to the configuration
Under Test
under test. This section can be taken from the applicable Verification
Procedure.
3.0 Individual This section summarizes the purpose and results of each test case performed
Test Case in the applicable Verification Procedure. Special attention is paid to any test
Report case where a failure occurred and how the failure was resolved. This section
covers:
2.0 This section identifies the equipment and software validated. It also identifies all
Identification of equipment and software necessary for this validation activity that is external to the
the system / sub-system configuration. This may include special test equipment and
Configuration
any external systems with an interface to the system. This section can be taken
Under Test
from the applicable Validation Plan and updated to reflect the actual system as
delivered.
SECTION CONTENTS
3.0 Individual This section summarizes the purpose and results of each event performed in the
Validation applicable Validation Plan. Special attention is paid to any situation where a failure
Reports (or deviation from the expected System performance) occurred and how the failure
was resolved. This section covers:
Traffic Detection and Monitoring Systems (TDMS) are stand-alone detectors that
detect the presence of vehicles and their characteristics. They can detect and
provide valuable real-time and historical data, including speed, volumes, vehicle
presence, occupancy, gaps, and incident occurrence. This data can then be utilized
to complete a variety of functions, including:
Detector
Purpose and
Operational System
Needs Requirement
s
Figure 3-1: Detector Design Operational Needs
specific regulations or guidance related to the design process for a TDMS are
contained in those referenced sections.
The criteria contained in this publication should be followed when designing new
TDMS. It is important to note/clarify, however, that there will be instances where all
of the criteria in these guidelines cannot be met. Justification for deciding to go
through with an installation, despite not being able to meet all criteria, should be
detailed by the designer. The goal of this process is to provide practitioners with
guidance as well as to provide consistency with respect to TDMS installations.
Upload event logs. This feature allows an operator to upload any event
logs that are maintained by the field devices.
Collect data from the field devices. This feature allows an operator to
retrieve the data from the in-progress sample period (started but not yet
completed), the current sample period, and historical sample periods.
The communications protocol should support all the features desired for these
devices.
3.2.1.2 NTCIP for Traffic Detection and Monitoring
The following NTCIP Information Level standards are applicable.
NTCIP 1206, Object Definitions for Data Collection, is a data dictionary
standard used to support the functions related to data collection and
monitoring devices within a transportation environment. This standard
defines data elements specific to transportation data collection sensors – it
supports the collection of information about each vehicle, such as number
of axles, vehicle dimensions (such as length, width and height), vehicle
weight, and axle weight. Other information that may be collected includes
vehicle headways, vehicle speeds, and vehicle acceleration.
Detection systems will be used on all minor and major arterials as well as all
expressways throughout the State of Qatar. These systems will include point vehicle
detectors that collect presence, speed, and occupancy data at each detection
location for each lane of travel. In addition, floating vehicle (probe vehicle) data will
also be collected for a representative sample of vehicles on all corridors to provide
for link travel time and origin-destination data. Together, the information from the
point vehicle detectors and the probe vehicle detectors will be utilized to provide a
comprehensive set of data for all corridors, including real-time and historical data,
such as speed, volumes, vehicle presence, occupancy, gaps, and incident
occurrence. This data can then be utilized to complete a variety of functions,
including:
1. Spacing and Lane Coverage (Point Detectors) – Point vehicle detectors will
be spaced every 0.5km on all minor and major arterials and expressways.
The quantity and frequency of detectors correlate with the effectiveness of the
overall system. Detector spacing is paramount. All lanes of travel should be
covered by the detector(s) at each detection point.
2. Spacing and Lane Coverage (Probe Vehicle Detectors) – Probe vehicle
detectors will be spaced every 0.5km on all minor and major arterials and
expressways in urban areas (e.g., Doha). Outside of urban areas and on
interurban expressways, probe vehicle detectors will be spaced at major
intersections and interchanges, with a maximum spacing of 2.0km.
3. Cost – Because multiple detectors should cover all lanes of travel at a
detection location, the cost of the system can quickly escalate. Choose
detector types, locations, and communication methods that minimize the
overall cost of the system. Co-locate detectors on existing structures (e.g.,
CCTV poles) where possible to minimize the need for new structures,
provided the integrity of 0.5km detector spacing remains intact.
4. Accessibility – Accessibility of the device for maintenance and repair purposes
is of high importance, especially when many devices are necessary for a
system. Inaccessible devices lead to higher costs and the potential need to
close lanes to perform maintenance, which increases the potential for
disruption of traffic.
5. Comprehensive Data Capabilities – For incident detection, speed, volume,
and occupancy are typically required.
6. Accuracy – Speed data must be accurate within a range of approximately 5
km/h. Accuracy levels should be as a minimum 95% for volume, 90% for
occupancy, and 90% for speed for all lanes.
7. Location Precision – Precision is secondary to detector spacing. The exact
location of the detector is not of high importance, provided the integrity of the
detector spacing remains intact.
Point detection systems may be utilized for specific locations such as detection at
traffic signals as part of the traffic signal system and urban traffic control (UTC)
system, at entrance or exit ramps along the expressway network, etc. Point
detection technologies (inductive loop, radar, video, and magnetometer) can be used
for point detection systems.
Vehicle detection systems used in tunnels shall ensure compliance with all
requirements of National Fire Protection Association (NFPA) 502 - Standard for
Road Tunnels, Bridges, and Other Limited Access Highways. Refer to the NFPA
502 standard for design requirements.
The detector technologies currently approved for use in Qatar for point vehicle
detection are inductive loops, microwave radar, video image, and magnetometer.
For probe vehicle detection, Bluetooth® detection systems will be utilized. Table 3-3
should be used as a starting point for selecting the appropriate detector technology.
Table 3-4 displays how each of the technologies fulfills the Detection System
Requirements. Table 3-4 also displays additional design considerations and
advantages vs. disadvantages for each system.
The designer should use the Detection System Requirements, Table 3-3, and Table
3-4 to determine the appropriate detection technology for the proposed system. The
remainder of this chapter identifies design considerations and guidelines for each
detection system.
-Speed
-Volume
In- Moderate- Easy/
Magnetometer -Occupancy Low-Moderate
Pavement High Intrusive
-Classification
(Length-based)
-Speed
Pole or
® -Travel Time Moderate-
Bluetooth Existing Easy Low-Moderate
-Origin- High
Structure
Destination
This section identifies deployment guidelines and criteria for each detector
technology. The designer should use this section as a guide for deployment of the
detector or system of detectors.
For specifics and additional guidance concerning the size and placement
of the loop within the travel lane, the Designer should refer to the Ashghal
ITS Specification – Traffic Detection and Monitoring and the Ashghal Civil
and Structural Standards for ITS.
When designing a microwave/radar detector location, the designer should follow the
steps below.
2. Detector Quantity
Radar detectors have a range of approximately 75m from the detector structure
to the farthest detection point. At locations where the detection zone exceeds
75m, multiple detectors must be used. This typically occurs at locations where
two directions of travel must be captured. When the zone exceeds the detection
capabilities of a detector, one detector on either side of the roadway is necessary
to capture all travel lanes.
Setback – Detector setback is the distance from the edge of the nearest travel
lane in the detection area to the detector itself. This setback is required so that
the detector’s radar beam can expand to cover the detection area. Newer radar
detectors do not require a setback. A minimum of 3.0m setback from the edge of
the closest detection lane is recommended.
4. Structure Type
Microwave detectors can be either free-standing on a steel or concrete pole (as
seen in Figure 3-3 and Figure 3-4), or collocated with an existing structure such
as:
Sign structure
Overhead Truss structure
Bridge structure
CCTV pole
DMS structure
The designer should locate radar sensors on any of the above structures where the
structures coincide with required detector spacing, where the structure satisfies the
mounting height and setback guidelines, and where the structure meets the wind
speed and vibration/deflection requirements identified by the manufacturer.
5. Obstructions
Microwave sensors can experience interference and disruption when obstructions
such as barriers or high retaining walls are within the detection area. To
minimize this interference, locations should be selected to reduce the impact of
these obstructions. If obstructions are unavoidable, the designer should consider
using multiple detectors to avoid the conflict. For example, if a roadway is
separated by a jersey barrier median, one detector on either side of the roadway
may be needed to capture all travel lanes.
0.60m
5.0 m 5.0 m
To To
8.0 m 8.0 m
6.0 m 6.0 m
When designing a VIVDS system, the designer should follow the steps described
below.
1. Detector Location
Detector location areas are determined by system use – either data collection or
incident detection.
If the detector is used for point data collection, the system needs may
require a very specific detection area (e.g., a specific lane or entrance
ramp, or a point on the main line, or a traffic signal structure). The
designer should not place the detector outside of this detection area.
If the detectors are part of a corridor data collection system, they must be
spaced approximately 0.5km apart.
Full coverage of all tunnels should be provided for incident detection, as
per the requirements of NFPA 502.
2. Detector Structure
Because VIVDS detectors are above-roadway systems, it is highly recommended
that they are located on existing structures such as:
Bridges
Trusses
Mast arms
Poles
Tunnel ceilings/walls
Each detection zone must be defined such that only vehicles within the detected
lane cross the zone. This will make certain that each detection zone gathers
lane-specific data, and that vehicles are not counted more than once. See Figure
3-5 for an example of defined detection zones.
There are also VIVDS that utilize existing CCTV cameras, adding analytics to the
“back-end” of the CCTV image. These systems require additional hardware (video
servers) in which the analytics are added prior to being used by a TMC Operator.
These systems have no adverse effect on the actual video, but can provide input into
an existing Advanced Transportation Management System (ATMS) in which, once
an incident has been detected, it would generate an alarm through the ATMS or
simply route the image to the video wall, thus notifying the Operator of the incident.
These systems are very comprehensive, where the analytics “re-learn” the image
every time the CCTV camera is adjusted. A significant drawback to these types of
systems is that it requires a substantial amount of additional hardware for
processing, typically adding an additional video server for every eight CCTV
cameras.
them into electronic signals. A portion of the vehicle must pass over the sensor for it
to be detected. A magnetometer can detect two vehicles that are separated by a
distance of 30cm. The sensor is placed in the middle of the traffic lane in a core
drilled in the roadway surface. The detection data is transmitted in real-time via low-
power radio technology to an Access Point (AP) or Repeater Unit (RU), it is
processed, stored, forwarded to an ITS enclosure, and then sent to the TMC.
When designing a magnetometer detector location, the designer must follow the
steps below.
1. Detector Location
The location of the detectors will vary based on their use – either data collection
or incident detection. All highways and major arterials throughout Qatar will be
designed to provide incident detection.
If the detector is used for point data collection, the system needs may
require a very specific detection area (e.g., a specific lane or entrance
ramp, or a point on the main line). The designer should not place the
detector outside of this detection area.
If the detectors are part of a corridor data collection system, they must be
spaced approximately 0.5 to 2.0km apart or according to the
manufacturer’s recommendation.
If detectors are part of an incident detection system, they must be spaced
at a maximum 0.5km apart.
2. Detector Quantity
One or more magnetometers must be used in each lane of each approach. In
typical arterial and highway management applications, a sensor is placed in the
middle of a traffic lane to detect the passage of vehicles and provide counts.
Vehicle speeds are measured by installing at least two sensors in the same lane.
The recommended distance between sensors depends on the range of expected
speeds to be measured. For typical highway applications, a separation of
approximately 6 to 7 meters is recommended. For typical arterial applications, a
separation of 3 to 4 meters is preferred.
5 30
6 45
9 50
4. Structure Type
Access Points and Repeater Units can be either free-standing on a pole, or
collocated with an existing structure such as:
Sign structure
APs/RUs are amenable to mounting configurations that vary from those listed above.
The designer should co-locate an AP/RU on any of the above structures where the
structures coincide with required detector spacing, and where the structure satisfies
the mounting height guidelines.
Bluetooth® devices have a unique electronic identifier called a Media Access Control
(MAC) which is transmitted short distances. The system works by having an initial
reader pick up the MAC address and then a second reader along the corridor
identifying the same MAC address. A vehicle containing a detectable Bluetooth ®
device is observed at the two stations. The MAC address and time of detection is
logged, and the information used to obtain a sample travel time for the segment.
Observations of multiple vehicles containing Bluetooth ® devices provide an accurate
estimate of traffic conditions. This information is then processed to calculate the
travel time and average speeds. Similarly, the origin-destination is obtained.
®
Figure 3-9: Bluetooth Traffic Monitoring Operation Concept
Photo Credit: University of Maryland Center for Advanced Transportation Technology
When designing a Bluetooth® detector location, the designer must follow the steps
below.
1. Detector Location
Bluetooth® detectors are primarily used to provide link travel times and origin-
destination data. The device needs to be positioned along the side of the
roadway at a height of approximately 3 to 5 m. Bluetooth® detectors should be
designed on all highways and major arterials throughout Qatar.
On highways, detectors should be located with a maximum of 2km
spacing. Additionally, there should be at least one detector located
between each interchange.
On major arterials, detectors should be located with a maximum of 1km
spacing. Additionally, there should be at least one detector located
between each signalized intersection or major roundabout.
Also, when locating a Bluetooth® site the access for power and
communication needs to be taken into consideration. Solar power, Power
over Ethernet (PoE), and cellular modem could be utilized.
2. Detector Quantity
Bluetooth® detectors can typically cover approximately a 45m radius, which is
equivalent to up to six lanes of traffic. At locations where the roadway exceeds
45m, multiple detectors must be used. When the zone exceeds the detection
capabilities of a detector, one detector on either side of the roadway is necessary
to capture all travel lanes.
3. Structure Type
The device can be pole-mounted and does not require an overhead structure.
Bluetooth® detectors can be either free-standing on a pole, or collocated on an
existing structure such as:
Sign structure
Overhead truss structure
CCTV pole
DMS structure
Light pole
Bluetooth® detectors are amenable to mounting configurations that vary from those
listed above. The designer should co-locate Bluetooth® detectors on any of the
above structures where the structures coincide with required detector spacing, and
where the structure satisfies the mounting height guidelines.
When the TDMS system includes devices that will be designed, constructed, and
maintained as Client-owned assets, the enclosure and its associated components
must be included in the design process.
The enclosure for the TDMS controller should be pole-mounted on the TDMS
pole or existing structures wherever possible in order to minimize cost.
When it comes to designing the enclosure, there is no standard size. There are a
wide variety of component manufacturers to choose from and this will usually impact
the enclosure interior space requirements. In some cases, collocated ITS devices
may also share the same enclosure. This will further influence the design of the
enclosure size.
Standard Specifications for an ITS enclosure can be found in the Ashghal ITS
Specifications:
The criteria contained in this publication must be followed when designing new
CCTV cameras. It is important to note/clarify that there will be instances where all of
the criteria in these guidelines cannot be met. Justification for deciding to go through
with an installation, despite not being able to meet all criteria, should be detailed by
the designer. The goal of this process is to provide practitioners with guidance, as
well as to provide consistency with respect to camera installations.
Control the CCTV Camera System. This feature allows an operator to control
the pan/tilt unit, lens, and camera. It allows an operator to control the zoom,
command the camera to preset positions, activate camera features (e.g.,
wipers, washers, blower, auto iris, auto focus), set and clear alarms and alarm
thresholds, and set camera zones and labels.
Monitor the CCTV Camera System Status. This feature allows an operator to
monitor the overall status of the field device, the status of each sensor, the
output status, and the status of each zone. This feature also allows an
operator to determine presets, the position of pan/tilt unit, the status of
features supported by the camera (wipers, washers, blower, auto iris, auto
focus), and monitor alarms.
The communications protocol should support all the features that are required
for this device.
NTCIP 1205, Object Definitions for Closed Circuit Television (CCTV) Camera
Control, is a data dictionary standard used to support the functions related to
controlling and monitoring the status of cameras, lenses, and pan/tilt units
within a transportation environment. This standard defines data elements
specific to a CCTV camera control subsystem, which consists of an assembly
of a camera, lens, and pan/tilt functions.
Camera locations should provide a clear line of site with minimal obstructions. The
considerations outlined in Table 4-3 should be taken into account when selecting the
site and placement of the camera.
Full CCTV camera coverage should be provided for all minor and major arterials and
all expressways throughout the State of Qatar. Full camera coverage of a roadway
results in CCTV camera placement such that an operator can view and monitor the
entire corridor, with no breaks in coverage. In order to provide full and continuous
coverage of a roadway, cameras should be placed no more than 2.5km apart
depending on the curvature of the roadway. In addition, CCTV cameras should be
considered at signalized intersections where warranted.
Full CCTV camera coverage within tunnels is also required, in accordance with the
requirements of NFPA 502.
Most of the desired CCTV camera features are standard with commonly available
commercial products. Depending on use, a camera may be chosen that meets the
Ashghal ITS Specifications for:
CCTV Camera
Video Encoder/Decoder
The following features related to camera type must be considered as part of the
design process:
Note that barrel mount cameras should be used on a case-by-case basis, and for
very specific applications (such as within tunnels).
Using a Pan-Tilt-Zoom (PTZ) platform, CCTV system operators can change camera
position about the 360-degree ‘azimuth’ axis and adjust camera elevation up or down
(within a 90-degree range). Together with a zoom lens, the PTZ camera allows
operators to view a scene within any direction about the camera, and within the lens
field-of-view and distance ranges. The speed of the pan/tilt mechanism determines
the rate of camera coverage, while the horizontal and vertical camera movements
determine the coverage area.
Dome-enclosed systems provide much higher PTZ speeds. Dome systems also
have much more range than external units, having the ability to look straight down. It
should be noted that dome cameras are “horizon limited” and cannot look up at the
sky or up a nearby steep hill very well. However, unless the camera is to be placed
in very hilly terrain, this is not a major drawback for roadway traffic monitoring.
Fixed cameras should only be considered for installations that focus on only one
view, and in locations such as tunnels and long underpasses where the camera will
not have to fight strong wind loads. PTZ cameras are the preferred camera type.
The Ashghal ITS Specifications contain two camera types; one which transmits video
in IP format only and one which is a dual IP/Analog camera.
The need to deploy analog cameras is typically due to the Client still maintaining
legacy infrastructure that contains some analog devices or cannot accommodate IP
signals.
The overriding factor in determining a CCTV camera location is the site’s fitness for
performing the operational role that it is designed for (see Section 4.3). If all other
factors are equal, the ITS practitioner may possibly have more than one option on
the type of camera mount to design. The three possible choices are:
Pole-mounted
On an existing sign or structure, like a bridge
Inside a tunnel, on a wall, or an underpass wall
The most prevalent structure for CCTV cameras is a stand-alone pole. The
minimum pole height to be used in Qatar is 15m, and pole heights of 20 to 25m may
be warranted at some locations depending on topography, obstructions, bridges,
interchange geometry, etc. Design standards for a CCTV pole can be found in the
following Client documents:
For a pole-mounted enclosure, do not place the enclosure on the same side as the
hand hole for a camera lowering winch or under the camera to be lowered.
CCTV camera systems for use in tunnels shall ensure compliance with all
requirements of NFPA 502 - Standard for Road Tunnels, Bridges, and Other Limited
Access Highways. Refer to the NFPA 502 standard for requirements. One hundred
percent (100%) CCTV coverage should be provided on the approaches to and inside
a tunnel.
An ITS enclosure and its associated components must be included in the design
process.
Design criteria for a suitable ITS enclosure location includes the following:
In locations where the site has limited space, the enclosure may be pole-
mounted.
The enclosure should be at a level where the maintainer doesn’t need a step
ladder to perform maintenance at the enclosure location.
A leveled maintainer’s pad should be provided at the front of the enclosure for
the maintenance worker to stand on while accessing the enclosure.
When it comes to designing the enclosure, there are a wide variety of component
manufacturers to choose from and this will usually impact the enclosure interior
space requirements. In some case, collocated ITS devices may also share the same
enclosure. This will further influence the design of the enclosure size.
The primary function of the Road Weather Information System (RWIS) is to measure
and monitor road weather conditions with the use of different sensors. RWIS assists
the Client and other agencies in determining road conditions. This information can
be shared with drivers or used internally to assist in scheduling maintenance.
RWISs collect atmospheric, pavement surface, and sub-surface information to
provide the most accurate weather information available.
The system component that collects weather data is the Environmental Sensing
Station (ESS). An ESS consists of a combination of sensors that gather and
transmit pavement, temperature, wind speed, visibility, and humidity data. These
sensors are controlled by a field controller, called a Remote Processing Unit (RPU),
which sends the sensor data to the TMC.
There are several Client and industry standards/requirements related to RWIS and
AQM Sites. The table below highlights some of the more important ones:
Table 5-1: RWIS and AQM Site Standards
Criteria Relevant Standard
Ashghal ITS Specifications - Road Weather Information
Sensor and Pole Type
Systems
Communication and Software NTCIP
QCS 2010
Structure
Per Manufacturer’s Requirements
Enclosure Ashghal ITS Specifications – General Provisions for ITS
All sensors require power to operate. Power is also required for the collection of the
data at the RPU and for transmission of the road weather data to its intended users.
Table 5-2: RWIS and AQM Site Design Considerations and Section Outline
Pre-Design Planning Chapter 2
Is this deployment consistent with “needs” outlined in a Concept of
Operations?
Is this deployment consistent with the ITS architecture?
Location/Placement Guidelines Section 5.5
Has the RWIS and/or AQM Site location been chosen/designed with
consideration to atmospheric conditions?
Has a site for the RWIS been chosen that considers the available utilities
and the cost/constraints associated with connection to those utilities?
Has the site been chosen with consideration to protecting the RWIS and/or
AQM Site structure and ensuring that it will last without undue maintenance
necessary to the structure and the surrounding site?
Has a site been chosen that makes the best use of the operational needs of
a RWIS and/or AQM Site (e.g., low visibility sites)?
Has a site been chosen that satisfies safety requirements for personnel
performing maintenance on the system?
Has the site been chosen so that it will minimize maintenance costs and in
accordance with QCS 2010, Section 11, Part 1.1.8 (e.g., there is sufficient
shoulder to park a bucket truck without the need for a full lane closure and
significant maintenance and protection of traffic)?
Sensor Type Section 5.3.1
Are the sensor types appropriate for the desired location?
Sensor Mount Section 5.3.2
Have the Client’s standards been followed in the design of the
mount/structure?
Is the mounting height appropriate?
Enclosure Section 5.6
Is an enclosure required at this location?
Can personnel safely access the enclosure?
Is the enclosure mounted on the RWIS pole or on an existing structure
(where possible)?
Does the location and orientation provide adequate protection for the
enclosure?
Has a concrete maintainer’s pad been provided at the enclosure’s main
door?
Power Requirements Section 11.1.1
Have the power requirements for the RWIS and/or AQM Site components
been determined?
Power Availability Section 11.1.2
Has an appropriate power source been located and confirmed with the utility
company within a reasonable distance from the site?
Have Step-Up/Step-Down transformer requirement calculations been
performed?
Have the metering options been determined?
Power Conditioning Section 11.2
Have the UPS and power back-up options been determined and accounted
for?
Communication Section 12
Have the communication requirements for the RWIS and/or the AQM been
determined?
Has an appropriate communication infrastructure been located and
confirmed within a reasonable proximity to the site?
If there are multiple communication options, have the pros/cons been
studied?
If using public communications infrastructure, has service been coordinated
with the Client?
Environmental
Have all the necessary environmental, community, and cultural impact
studies, processes and concerns been addressed?
Monitor Water Level. This feature allows an operator to monitor the depth of
water at one or more locations, such as over a roadway or in a stream.
Monitor Air Quality. This feature allows an operator to monitor the current air
quality in the vicinity of the RWIS and/or AQM Site, and determine whether
there are airborne biohazards in the vicinity.
Upload Event Logs. This feature allows an operator to upload any event logs
that are maintained by the RWIS and/or AQM Site.
The communications protocol should support all the features that are desired for
RWIS and/or AQM equipment.
The typical RWIS site consists of a pole, enclosure, a RPU, and several
environmental sensors. Figure 5-2 shows the typical location and mounting heights
of sensors on a pole-based RWIS. The RWIS outstations are likely to include some
or all of the following:
Road sensors in travel lanes are used to measure surface temperature, sub-
surface temperature, and surface condition.
A RPU connected to all the sensors translates and records the signals
received from the sensors. The RPU transmits data to the server.
Most of the sensors on an outstation are installed above the road, affixed to a pole.
The sensors that are typically included in a RWIS are the ultrasonic wind speed and
direction sensor, precipitation and visibility sensor, air temperature/relative humidity
sensor, and passive pavement sensor (PPS). These sensors are typically part of an
outstation. However, some sensors are installed either at the road surface or sub-
surface.
detecting fog, mist, smoke, and sand. These sensors typically use infra-red forward
scatter technology, with a limitation being that anything in the optical path that
attenuates or scatters the infra-red beam, such as dirt, or even spider webs, may
cause erroneous readings. To avoid this problem multiple sensors can be used to
check and adjust for any contamination errors. These sensors should be installed at
a height of approximately 2.0 to 3.0m above the ground.
The pole height should be sufficient to accommodate the sensors. If installing wind
sensors, poles should be at least 10m in height. Poles are most frequently installed
within a range of 10 to 15m from the edge of the paved surface and if possible at the
same elevation as the surface of the road as shown in Figure 5-3.
10 to 15m
The AQM Site is an air quality device that is used to measure common air pollutants
including Sulphur Dioxide (SO2), Nitrogen Oxides (NO), Ground Ozone (O3),
Carbon Monoxide (CO), Hydrocarbon-Methane and Non-Methane THC, and
Particulate Matter (PM10, PM2.5) among others. Air samples are generally collected
to observe pollution trends and sources, and activate control procedures. The AQM
Site should have a particle monitor module and a gas module to detect the pollutants
mentioned above. The mounting assembly and the RPU should follow
manufacturer’s specifications and Ashghal’s ITS Specifications. Figure 5-4 shows a
typical AQM Site.
A poorly chosen site can result in incorrect readings, service difficulties, or even
damage from passing traffic. The site should not be sheltered in such a way that
sensor readings give a false impression of the situation closer to the road. At the
same time, sensors and the outstation should not be located too close to the road
that wind from passing traffic will give inaccurate readings. The height of sensors
above the ground, as well as their orientation, can also affect sensor readings and
needs to be taken into account when selecting locations and installing equipment.
The number and spacing of sites in the network is dependent upon a variety of
factors including; topography, soil type, land use, microclimate zones, proximity to
utilities, and road classification. Generally, the greater the variability in these factors,
the more sites will be required in the network. RWIS deployments should focus on
roadways where sandstorms and/or fog are prevalent. The observation points and
pavement sensors should be installed at critical points along the roads. Variations in
sensor or structure siting may be unavoidable due to many circumstances, such as
limited road right-of way, access for maintenance, geography, and security concerns.
The contractor shall install the weather sensors at various pole heights using
mounting brackets in accordance with the RWIS Specifications.
When the RWIS system includes devices that will be designed, constructed, and
maintained as Client-owned assets, the enclosure and its associated components
must be included in the design process. See manufacturer’s specifications to
determine the maximum distance between the enclosure and the field device it
services.
The criteria contained in this publication must be followed when designing new Over-
height and Over-weight Detection Systems. It is important to note/clarify however,
that there will be instances where all of the criteria in these guidelines cannot be met.
Justification for deciding to go through with an installation, despite not being able to
meet all criteria, should be detailed by the designer. The goal of this process is to
provide practitioners with guidance, as well as to provide consistency with respect to
Over-height and Over-weight Detection System installations.
Environmental
Have all the necessary environmental, community, and cultural impact
studies, processes and concerns been addressed?
The WIM shall automatically indicate when vehicles are over the permitted weight as
they drive over a sensor. Unlike static weigh stations, WIM systems do not require
the vehicles to stop; therefore, making them more efficient.
Over-height vehicle detections systems are deployed to warn drivers and the TMC
when a vehicle exceeds the maximum height for an upcoming infrastructure or
obstacle.
Over-height detectors are used to identify over-height vehicles and warn drivers of
an upcoming obstacle. They can be used in different applications such as bridges,
over-road walkways, tunnels, overpasses, and parking structures among others.
Over-height detectors should be installed prior to a bridge that is lower than the
standard height of 5.7m over a roadway. The system should activate a visual and/or
audible alarm, warning signs, flashing lights, or traffic signals to prevent accidents.
The system should also send an alarm to the TMC when activated. See Figure 6-1
for an illustration of an Over-height Detection System.
6.3.2 Weigh-in-Motion
WIM devices are designed to capture and record vehicle weights as they drive over
a sensor installed under the road pavement. The sensors estimate the load of a
moving vehicle without disrupting the traffic flow. WIM systems are used for
collection of statistical traffic data, support of commercial vehicle enforcement, and
traffic management.
The most common WIM sensors are the quartz piezoelectric sensors. The piezo-
quartz sensor is a widely used type of piezoelectric sensor that has a stable
response over a large temperature range. The quartz sensors are used for
measuring wheel and axle loads of moving vehicles. These sensors consist of a
light metal material fitted with quartz discs. When an external force is applied to the
surface of the sensor, the load causes the quartz discs to yield an electrical charge
proportional to the applied force through the piezoelectric effect. A charge amplifier
converts the electric charge into a proportional voltage that can be measured and
correlated with the applied force.
This sensor offers great accuracy as well as low maintenance. The sensor is
embedded in the pavement and produces a charge that is equivalent to the
deformation induced by the tire loads on the pavement’s surface. The sensor’s
performance is affected by pavement flatness. See Figure 6-2 and Figure 6-3 for
details of a WIM layout.
A standard WIM system should cover all lanes of the expressway where oversized
are permitted. The travel lanes are instrumented with induction loops and quartz
sensors. All vehicles driving through the WIM site are measured. The legal weight
and height limits should be determined by the Client.
This section identifies deployment guidelines and criteria for each detector
technology. The designer should use this section as a guide for deployment of the
detector or system of detectors.
WIM should be installed on all key Qatar roadway network routes and access routes
to/from major generators of truck traffic. The installation of WIM includes making the
pavement cuts and rehabilitation for the inductive loops and quartz sensors. Loop
vehicle detectors and quartz sensors are buried several centimeters beneath the
pavement surface of the roadway. For specifics concerning the size and placement
of the loop and quartz sensor within the travel lane, the Designer should adhere to
the guidelines provided in the Ashghal’s ITS Specification - Over-height and Over-
Weight Detection Systems.
Over-height detectors consist of a sensor mounted on each side of the road. Over-
height vehicle detection systems are deployed to warn drivers if their vehicle
exceeds the maximum height for the upcoming infrastructure, whether that be a
tunnel entrance, low bridge/overpass, or sign gantry. The location of the over-height
detector should provide drivers sufficient warning time to stop prior to the structure or
re-route without causing traffic congestion. Typically the Over-height Detector
System consists of transmitters and receivers, an electronic warning sign,
uninterruptable power supplies, and inductive traffic loops. When designing an
Over-height detector or system location, the designer must determine detector
location, quantity, height and setback. In some cases, over-height detectors can
also be used to support WIM systems. Also, the structure type must be approved by
the Client.
The primary function of a DMS is to provide traveler information. The nature of this
information is varied, but the goal is to disseminate roadway condition information to
travelers so that they can make informed decisions regarding their intended trip
and/or route.
The criteria contained in this publication should be followed when designing a new
DMS. It is important to note/clarify that there will be instances where all of the
criteria in these guidelines cannot be met. Justification for deciding to go through
with an installation, despite not being able to meet all criteria, should be detailed by
the designer. The goal of this process is to provide practitioners with guidance as
well as providing the Client consistency with respect to DMS installations.
Configure the DMS. This feature allows an operator to determine the identity
of the DMS, determine its capability, manage fonts, manage graphics, and
manage the brightness.
Control the DMS. This feature allows an operator to control the message on
the sign face of the DMS, control the brightness output, control external
devices connected to the DMS, reset the DMS, and perform preventative
maintenance. This feature also allows a DMS to be controlled from more than
one location.
Monitor the Status of the DMS. This feature allows an operator to monitor the
current message on the DMS, and perform diagnostics.
Upload Event Logs. This feature allows an operator to upload any event logs
that are maintained by the DMS.
The communications protocol should support all the features that are desired for the
DMS system.
NTCIP 1203, Object Definitions for DMS, is a data dictionary standard used to
support the functions of DMS system within a transportation environment.
This standard defines data elements that allow for the display of messages
and the configuration of DMS. The standard also defines data elements to
support fonts, graphics, and message text so that the DMS may accurately
render messages on the sign face based on these data elements.
DMS should be considered at all key strategic decision making points, variable
speed limit gantries, and entries to Expressways. The site characteristics in the
vicinity of the planned DMS must be investigated. These characteristics dictate the
amount of information that can be displayed. Relevant characteristics include:
Detection Zone
Reading and Decision Zone
Out-of-Vision Zone
Detection Zone: At expressway speeds (between 80 and 120 km/h), the DMS
should be visible to the approaching driver from approximately 300 to 600m away.
The visibility distance should also be increased if the DMS is placed at an offset from
the traveling lane, per Figure 7-3 and Figure 7-4.
Drivers need approximately one second per word to read and comprehend a
message. Travelling at approximately 100 km/h, this translates into roughly time
enough to read and comprehend a 10-word message. The character height, cone of
vision, and lateral placement must all be considered when determining the
placement of the sign to meet the sight distance requirements.
Out-of-Vision Zone: Once the driver gets close to the sign, they will not be able to
read the message. The distance is determined by the viewing angle (Section 7.4.2)
of the sign, the structure that the sign is placed on (Section 7.5) and the lateral
placement of the sign (Section 7.3.2).
Table 7-4: DMS Sight Distance vs. Speed Limit vs. Roadway Type
Legibility Distance
Expressway Limited Access Arterial Major Arterial
Requirements
Less than 80 km/h N/A 200m 200m
80 km/h to 100 km/h 250m 250m 250m
Greater than 100 km/h 300m or more 300m or more N/A
QTM
QCS 2010, Section 6, Part 7 – Vehicle Crash Barriers
The DMS structure must be placed far enough behind a crash barrier or outside the
clear zone to comply with the minimum clearances values. Refer to the safety
specifications, in QCS 2010, of the particular barrier present at the site or the barrier
planned to be installed.
The offset of the DMS (horizontal distance from the sign as a function of travel lane)
will require additional sight distance to clearly view and react to the sign. Figure 7-5
provides a rough guide of the additional distance that must be factored into the
longitudinal (Section 7.3.1) sign placement.
A roadway’s vertical alignment impacts the visibility of the DMS. If there are a limited
number of potential locations available, a slight upward grade is desirable.
The selection of the sign type, the configuration of the display, and the technology
employed all have direct or indirect impacts on the visibility of the message that will
be displayed on the DMS.
DMS display characters and symbols in a matrix format, which are generally
designed in one of the following three patterns:
Character Matrix
Line Matrix
Full Matrix
All permanent DMS used in Qatar shall be full color, full matrix. Portable DMS shall
be amber color, full matrix. Full matrix DMS displays are important as the use of
graphics and symbols become more accepted and used. In this format, the entire
display consists of continuous matrix of pixels, as shown in the layout below.
The technology required for all DMS deployed in Qatar is Light-Emitting Diode
(LED). LEDs are semiconductors that emit light when current is applied. Typically,
several individual LEDs are "clustered" together in order to create each pixel. LEDs
have the added benefit of being able to display signs in full color with the appropriate
LED type. The reliability of LED lamps is very high.
Viewing angle is an important aspect and depends upon the mounting location of the
DMS and the curvature of the roadway. There are three standard angles available
from DMS manufacturers: 15 degrees, 30 degrees, and 70 degrees. The 30-degree
viewing angle is typical and required for use on all DMS in Qatar.
The Client requires the use of either walk-in or front-access signs. Rear-access
signs are extremely difficult to access given the existing standard drawings for DMS
structures. What follows is a brief examination of the pros/cons of the walk-in or
front-access signs.
The three types of permanent structures that the Client allows for mounting DMS are
overhead or span, cantilever, and center-mount, as shown in Figure 7-7. All large
and medium-size DMS shall be mounted on either overhead or cantilever structures.
Center-mount structures will be considered as an exception in urban areas for
medium-size signs only; however, they will require specific approval from the Client.
The lateral placement guidelines in section 7.3.2 and the nature of the roadway are
the two main factors in determining the type of structure that the DMS should be
mounted on. Portable DMS should not be considered as an acceptable long-term
The width of the roadway (including all lanes and hard shoulders), the
speed characteristics, and the available ROW determine the placement
and structure type of the DMS.
The following outline contains the information which must be submitted for each
DMS sign structure. The outline contains aspects of the DMS design required by the
Client.
The Client’s sign structure guidelines will be used for all structure types. All design
calculations, plans, and details will be in accordance with the Civil and Structural
Standards for ITS. Each DMS structure will be assigned its own structure number.
The Client’s order of preference for DMS support structure types is:
1. Overhead truss
2. Cantilever
3. Center-mount
Foundation Design
o One test boring will be completed at each DMS foundation location.
Where exceptions are granted and no borings are completed, use
worst-case soil conditions found in the standard drawings. The Client’s
Geotechnical Unit must approve the procedure and assumptions for
designing the foundations.
o Analysis in accordance with QCS 2010 will be used for drilled shafts
(caissons).
Note: The standard drawings establish minimum plate, bolt, weld sizes, etc.
Additional calculations may be required for using larger plate, bolt, weld sizes, etc.
DMS shall be utilized in advance of all tunnels in accordance with all requirements of
NFPA 502 - Standard for Road Tunnels, Bridges, and Other Limited Access
Highways. These DMS shall be primarily focused on alerting drivers of tunnel
closures due to accidents, fires, or other unplanned events and emergencies within a
tunnel. Refer to the NFPA 502 standard for design requirements.
When the DMS system includes devices that will be designed, constructed, and
maintained as Client-owned assets, the enclosure and its associated components
must be included in the design process.
Design criteria for a suitable ITS enclosure location include the following:
A concrete pad should be provided at the front of the enclosure for the
maintenance worker to stand on while accessing the enclosure.
Standard Specifications for the ITS enclosure can be found in Ashghal ITS
specifications:
The primary function of the Lane Control Signs (LCS) is to maximize roadway
capacity and safety. The information is transmitted though specific dynamic road
traffic signs with a relatively small dimension. Applications for LCS include lane
open/close/change, variable traffic restrictions, variable speed limits, travel times,
congestion warning, temporary shoulder use, and hazard lane signalization. In the
future, the VSL should be linked to micro-simulation models running in real time
using dynamic traffic data that can set pre-emptive speed limits to avoid the on-set of
congestion before it actually occurs. Signals with a green downward arrow are used
to indicate a lane which is open to traffic facing the signal. A red cross indicates that
a lane is closed to traffic. A flashing amber circle, arrow or cross, indicates to traffic
facing the signal to immediately clear the lane. Other LCS can show full color
graphics or text depending on the intended use.
Configure the LCS. This feature allows an operator to determine the identity
of the lane control sign, determine its capability, and set its default values.
Control the LCS. This feature allows an operator to control the sign face of
the lane control sign, control external devices connected to the lane control
sign system, reset the lane control sign system, and perform preventative
maintenance.
Monitor the Status of the LCS. This feature allows an operator to monitor the
current status of the lane control signs and perform diagnostics.
Upload Event Logs. This feature allows an operator to upload any event logs
that are maintained by the lane control sign system.
The communications protocol should support all the features that are desired
for the lane control sign system.
NTCIP 1203, Object Definitions for DMS, is a data dictionary standard used to
support the functions of a DMS system within a transportation environment.
This standard defines data elements that allow for the display of messages
and the configuration of DMS. The standard allows addressing LCS by
defining each LCS basically as a DMS. Each possible indication (e.g., green
downward arrow, a red cross, etc.) would be defined as a message.
The dimensions and weight of most LCS allow easy installation and configuration for
different road infrastructures, including tunnels, bridges, expressways, and road
interchanges. All messages shall be clearly legible under any lighting conditions as
shown in Figure 8-2 and Figure 8-3. In the case of lane closures, the signs must
clearly indicate which lanes are open or closed to avoid driver confusion.
All LCS shall be coordinated so that all the indications along the controlled section of
roadway are operated uniformly and consistently. For reversible-lane control signs,
the indications must not be simultaneously displayed over the same lane to both
directions of travel. All lane-use control signal faces will be located in a straight line
across the roadway approximately at right angles to the roadway alignment.
The placement should allow drivers to decide in which lane they need to drive, and
should provide maximum visibility of the message. At expressway speeds, the LCS
should be visible to the approaching driver from 300 to 600m away. The color of
LCS indications must be clearly visible for 600m at all times under normal
atmospheric conditions, unless otherwise physically obstructed. LCS will be placed
at a maximum spacing of 500m apart on all major arterials and expressways.
The sign placement should not be lower than the required vertical clearance of the
structure where it is attached. QTM and QCS 2010 provide information on the
vertical clearances.
LCS are special overhead signs on a street or expressway that indicate whether
travel in a lane is prohibited or allowed. Each LCS is independently controlled to
indicate the status of each travel lane. LCS signs can also be collocated with a DMS
to provide additional information as shown in Figure 8-4.
Graphic displays placed over individual travel lanes displaying bright color
pictograms (red cross, green arrow, yellow arrow to the left or right) indicate lane
usage as follows:
Green indication: drivers may travel in the lane under a green signal as
shown in Figure 8-5.
Steady or Flashing yellow indication: drivers are warned that a lane
control change is being made.
Steady red indication: drivers shall not enter or travel in any lane where a
red signal is shown.
Full matrix, full-color, high-resolution pixels will be used to allow for crisp graphics
and easy to read text. Graphics and pictograms should replace text whenever
possible to minimize confusion. All lane-use control signal indications will be in units
with rectangular signal faces and will have opaque backgrounds. Nominal minimum
height and width of each downward green arrow, yellow arrow, and red X sign face
will be at least 60cm for typical applications. See Figure 8-6 and Figure 8-7 for
examples.
LCS shall be placed directly above the lanes they control. They can be attached to a
new or existing sign structure. The Client’s structural engineer must approve the
design and the load calculations.
LCS can be attached to another type of structure for different road infrastructures like
tunnels, bridges, expressways, and static signs. LCS can also be mounted on a new
structure depending on the size and the location. The design must be approved by
the Client prior to installation.
When the LCS system includes devices that will be designed, constructed, and
maintained as Client-owned assets, the enclosure and its associated components
must be included in the design process.
Ramp meters are traffic signals that control traffic at entrances to expressways, and
are installed to address three primary operational objectives:
Control the number of vehicles that are allowed to enter the expressway.
Reduce expressway demand.
Disperse platoons of vehicles released from an upstream traffic signal.
The purpose of the first and second objectives is to ensure that the total traffic
entering an expressway section remains below the operational or bottleneck capacity
of that section. A secondary objective of ramp metering is to introduce controlled
delay to vehicles wishing to enter the expressway, and as a result, reduce the
incentive to use the expressway for short trips during rush hour. Easily accessible
alternate routes must exist to achieve the desired result. Also, measures should be
implemented to prevent any traffic diversion to neighborhood or local streets. The
purpose of the third objective is to provide safe and efficient merge operation at the
expressway entrance. Ramp metering has been shown to prevent disruptions in
expressway operations, which can cause unsafe queuing conditions by significantly
decreasing expressway capacity. Prevention of expressway flow disruptions also
minimizes chances of rear-end crashes.
Most urban expressways are multi-lane facilities that carry heavy traffic during peak
periods. Traffic demand at a single on-ramp, however, is usually a small component
of the total expressway demand. Therefore, metering a single ramp and even a few
ramps may not be sufficient to achieve the first objective. In addition, drivers
affected by a small ramp metering system perceive such a system to be unduly
taxing them, favoring those who have entered the expressway at uncontrolled ramps
at upstream expressway sections. Thus, ramp metering with the objective of
mitigating downstream congestion should be installed on a sufficiently long section of
an expressway if it is to achieve all of these benefits and keep the motorists happy.
When properly installed, ramp metering has the potential to achieve the following
benefits:
Analyze Ramp
Geometry to
Determine Feasibility
and Extent of Ramp
Metering
The criteria contained in this publication should be followed when designing a new
RMS. It is important to clarify that there will be instances where all of the criteria in
these guidelines cannot be met. Justification for deciding to go through with an
installation, despite not being able to meet all criteria, should be detailed by the
designer. The goal of this process is to provide practitioners with guidance as well
as providing the Client consistency with respect to RMS installations.
Configure the Ramp Meters. This feature allows an operator to determine the
identity of the ramp meter controller, configure the thresholds, configure the
scheduler, and define the lane and sensor configurations for the mainline and
ramp.
Control the Ramp Meters. This feature allows an operator to control the
operational mode of the ramp meter and control the ramp metering plans.
Monitor the Status of the Ramp Meters. This feature allows an operator to
monitor the current status of the ramp meters, monitor the current status of
the sensors, determine what operational mode or ramp metering plan is
currently being implemented, and perform diagnostics.
Upload Event Logs. This feature allows an operator to upload any event logs
that are maintained by the ramp metering system.
The communications protocol should support all the features that are desired
for the ramp metering system.
Ramp metering can improve the safety and efficiency of traffic flow at or around
expressway bottlenecks under certain conditions. A thorough engineering study
should be conducted to determine the applicability of this traffic management
strategy.
Detailed data should be collected for the entire expressway section of interest, which
may include one or more bottlenecks and adjacent roadway facilities. Preliminary
site visits should be performed to assess where and how the data will be collected.
Then, plans should be developed and executed to collect the following types of data:
When available, crash records for the section of concern for at least the past
one year, and preferably for three years.
Traffic data:
o 15-minute traffic volumes in individual expressway lanes at key
locations within the section of interest. For analysis purposes, these
volumes should be converted to hourly flow rates.
o 15-minute volumes of traffic entering and leaving the expressway
section at exit and entrance ramps, and converted to hourly flow rates.
o 15-minute volumes of traffic at surrounding adjacent roadway facilities.
o Expressway speeds at key locations and speeds of traffic approaching
and traveling on the ramp.
o Observations about formation, dissipation, and impacts of queues on
expressway lanes, entrance ramps, and exit ramps.
Roadway geometry:
o Number and width of expressway lanes, segment lengths (i.e., distance
of on-ramp entrance from upstream intersection, ramp length, length of
auxiliary acceleration lane, lengths of tapers, etc.), widths of ramps,
locations of physical bottlenecks (i.e., a lane-drop), and other relevant
The first step is to analyze any available crash data to identify the locations,
numbers, and severity of crashes in the section, and compare them to other sections
of the same expressway or similar roadways. If the number of crashes is higher than
the average for other similar locations or the crashes are more severe than similar
locations, some countermeasure is needed to minimize the number and severity of
crashes. Additional analysis should be conducted to determine the appropriate
countermeasures. These countermeasures may include ramp metering at
immediately upstream or downstream ramp, active traffic management (advance
warning of downstream queues or slow traffic, speed harmonization, etc.), or both.
Another countermeasure might be to adjust signal timings to provide more capacity
to exiting ramp traffic in cases where queues at the downstream intersection begin to
interfere with exiting traffic or spillback into main lanes.
1. If the total expressway plus ramp volume is more than the capacity of a
downstream bottleneck (a downstream expressway section or the ramp merge
area) for a significant part of a peak period, one or more upstream ramps should
be considered for metering depending on the amount of excess demand. The
reader should note that service volume (count of vehicles) at a location
represents traffic demand only when no queuing occurs immediately upstream of
that location.
At entrance ramps, merging of entering traffic into the main stream creates
bottlenecks under certain conditions. The level of impact depends primarily on the
ramp volume, and the volumes in the expressway merge lane and adjacent
expressway lane. The graphs in Figure 9-2 and Figure 9-3 can be used to determine
if ramp metering can be justified based on two criteria based on these volumes. It
should be noted that these two graphs assume typical entrance ramps, which are
located on the right side of the expressway. If there is a need, the user can use
these plots for on-ramps located on the left-side by using data from the appropriate
expressway lanes.
Use the following steps to test the criteria given in these figures:
2. For each 15-minute flow rate (15-minute volume multiplied by 4), calculate the
average expressway volume in the two right-most lanes. Using Figure 9-2, locate
the point corresponding to acceleration distance from Step 1 and this value. If
the point lies above the solid line, metering is recommended at this ramp during
the assessed period. Repeat for other time times.
3. For each 15-minute, add flow rates for the on-ramp and the right-most lane and
plot against acceleration distance in Figure 9-2. If the point is located above the
solid line, ramp metering would be recommended.
Even if these criteria are not met for a ramp, a meter may be justified based on
safety or system-based analysis. For instance, if a ramp meets criteria for metering,
but it is not possible to reduce expressway demand by the desired amount by only
metering traffic at this ramp, one or more upstream ramps could be metered to
achieve the desired results. Also, consideration of the adjacent roadway system
should be taken into account to ensure it is not affected by queued traffic from the
ramp meter.
Expressway
Expressway
If the analysis shows that safety and/or operational benefits can be achieved by
installing a ramp meter, additional analysis should be conducted to ensure that ramp
geometry is adequate to support a good ramp metering operation. In some cases,
the Client may have to make decisions that may compromise some objectives.
Using methods (equations and graphs) described earlier, the following tasks are
recommended:
Determine the desired metering rate and select a metering strategy. Note that
a dual-lane meter is recommended for metering more than 900 vph. Bulk
metering can be used for slightly higher demands, but it compromises a key
ramp metering objective.
Determine how many additional ramps, if any, will need to be metered, based
on a system-based analysis.
Figure 9-4 and Figure 9-5 illustrate the various typical components of a ramp meter
system. These components include detectors and traffic control devices.
Mainline
Primary Queue Detectors
Detector Merge Detector
Mainline
Primary Queue Detectors
Detector Merge Detector
Loop
"Ramp Metered "Form 2 Lanes Intermediate Queue Demand Ramp Meter Signals
When Flashing" When Metered" Detector Detectors "Stop Here On Red"
Several loop detectors can be installed to provide a wide range of operations. Table
9-3 provides a description of these detectors.
A series of warning and regulatory signs could be used to convey the intent of the
expressway management system. Various ramp meter signs used under single-lane
and dual-lane configurations are described in Section 9.5.7.7.
The final element of the single-lane or multiple-lane traffic control devices is the
traffic signal display. As the motorist nears the ramp meter stop-bar, one of two
standard signing and traffic signal display conventions is used to inform the driver of
the regulatory requirements of the ramp meter and to indicate when the motorist is
allowed to enter the expressway. Figure 9-6 and Figure 9-7 illustrate the typical post
mounted signal used for single- and dual-lane metering. It should be noted that
three-section (three-aspect) signal heads are installed on both sides of the entrance
ramp on breakaway posts because they are located within the clear zone. If
breakaway poles are not supported by the existing policy, other measures should be
used to prevent crashes involving vehicles and signal poles. These measures
include curbs and barriers.
As illustrated in Figure 9-6, single-lane meters use one signal-head on each side of
the ramp. One of these signals is installed at an angle where vehicles stopped at the
meter can clearly see the lights. The other is installed at an angle that allows lights
to be seen from the ramp entrance. Additionally, a “Stop Here On Red” sign is
posted below each signal-head.
For dual-lane meters, as shown in Figure 9-7, two three-section heads are installed
on each pole. The top signal head points to vehicles entering the ramp, while the
bottom signal head points to vehicles stopped at the meter. Signals on the left side
pole are for the left lane and signals on the right side pole are for the right-lane. A
“Stop Here On Red” sign is mounted on each pole between the two signal heads.
Additionally, a “Left Lane Left Signal” sign is placed below the bottom signal head on
the left pole, and a “Right Lane Right Signal” is similarly placed on the right pole.
In addition to the standard marking on the ramp to separate travel lanes from the
shoulders, dual-lane meters require an additional line to identify the two metered
lanes. Typically a solid line is used to convey the message that shifting lanes is
prohibited once a vehicle has entered this space. An HOV by-pass lane also
requires marking (a diamond) to identify lane restrictions.
To be suitable for ramp metering applications, the traffic controller should provide the
following functionality:
For each metered lane, allow programming of green, yellow, and red
indications in the 1 to 99 second range with 0.1 seconds intervals.
Support configuration of at least one detector trap per expressway lane for
up to a maximum of six lanes. Furthermore, the controller should provide for
collection of average speed, volume (separate for passenger cars and
trucks), and average occupancy data from these detectors in separate bins.
The data should be collected every 0.1 second and aggregated over a user-
specified time (e.g., 20 second, 30 second, etc.).
Collect volume and occupancy data from other detectors on the ramp.
Support queue override functionality using occupancy data from primary and
intermediate queue detectors.
A startup cycle should provide for activating the advance flashing beacon for
a programmable duration before normal metering cycle begins.
Provide for advance flashing beacon to be active during the normal metering
cycles.
Similar to a regular traffic signal, the controller should be installed on a concrete pad
meeting the QCS 2010 - Traffic Signal requirements.
Loop detectors should be installed and wired using the QCS 2010 requirements and
hardware as for traffic signals.
Ramp metering can be operated in a number of ways depending on the type and
level of operation.
When the merge area of the expressway is not a bottleneck, an uncontrolled single-
lane expressway entrance ramp may have a throughput capacity of 1800 to 2200
vph. The same ramp will have lower capacity when metered. The maximum
theoretical metering capacity depends on the type of strategy used. There are three
ramp-metering strategies. These strategies are described below.
Installation of a ramp meter to achieve the desired objectives requires sufficient room
at the entrance ramp. The determination of minimum ramp length to provide safe,
efficient, and desirable operation requires careful consideration of the elements
described below:
Figure 9-8 illustrates the distance requirements at the ramp meter location. In this
figure, the dotted line shows the ramp length. Under strict metering, the primary
queue detector controls the maximum queue length in real-time. Thus, the distance
between the meter and the queue detector defines the storage space. For dual-lane
ramps, the ramp storage area as shown in Figure 9-8 should also consider the
transition from one lane to two lanes and dual-lane storage space. The transition
zone should be at least 23m long, and the length of dual-lane storage should be
sufficient to store a minimum of four cars per lane (approximately 31m). In addition,
the signal poles should be placed where they cannot be reached by vehicle
occupants.
Single-Lane Meter
Dual-Lane
Meter
2-Lane Storage
Transition
The placement of signal poles controls the distribution of available ramp length to
storage and acceleration distances. If needed, additional acceleration distance may
be provided by constructing an auxiliary lane parallel to expressway lanes. Similarly,
additional storage may be provided on the frontage road upstream of ramp entrance.
Outer Separation
2.2m 2.2m
1.1m 1.1m
Ramp Details
0.6m 4.3m 1.8m
Single-Lane Uncurbed m6´ Desired
0.6m 3.6m 3.6m 18 m
Dual-Lane Uncurbed Desired
v2
X 0.278vT
a
254 G
9.81
where:
X = Stopping sight distance, meters;
v = Speed of traffic approaching the on-ramp, km/h;
T = Perception-reaction time (2.5 sec), seconds;
a = Deceleration rate, m/s2; and
G = Percent grade divided by 100.
Assuming a deceleration rate of 3.5 m/s2, 60 km/h approach speed, and zero grade,
the value of stopping sight distance will be 81.5m. This would be the minimum value
for the assumed conditions. If the decision point is an upstream intersection, this
calculation should also consider cross-street turning traffic that, even though making
the turn maneuver at a slower speed, may need travel distance to allow one or more
lane changes.
In this equation, L (in meters) is the required single-lane storage distance on the
ramp when the expected peak-hour ramp demand volume is V vehicles per hour
(vph). Dividing calculated value of L by the length of a design vehicle (7.7m) will
convert the value to storage requirement in terms of number of vehicles. For a dual-
lane ramp meter, storage distance can be calculated by considering the length of
dual-lane storage.
Figure 9-11: Safe Merge Speeds Corresponding to Expressway Free Flow Speeds
Table 9-4 indicates when it is appropriate to permit one or two vehicles per green:
The FHWA Ramp Management and Control Handbook recommends that ramp lanes
have a width of at least 3.6m, an inside shoulder width of approximately 2.0m and an
outside shoulder width of 2.0m.
These guidelines should be used when determining the appropriate number of ramp
metered lanes. Other considerations such as environmental disturbance, existing
structures, and other factors may influence the final design.
The ramp meter and stop bar must be placed at a location on the entrance ramp that
balances the need for an upstream queuing/stacking area and a downstream
acceleration and merge area. The meter must be placed such that enough stacking
space is available on the ramp to accommodate the queues it will generate.
The designer should utilize the methods of calculating queue storage requirements.
As a rough estimation, queue lengths can be calculated by subtracting the metering
rate from ramp volume over a specific period of time.
The exact location of the ramp meter on the entrance ramp will come
from the ramp meter study. The rules of thumb included here are to
be used to determine general placement areas, but will not address
the needs of each unique situation.
Single lane ramps should utilize a signal pole (vertical pole) with two
mounted signal heads placed on the left side of the stop line. The
signals should be vertically spaced such that the driver can see the
signal heads while parked at or just in front of the stop bar. A Figure 9-12:
Ramp Meter
duplicate pole on the right side of the ramp can supplement the left Signals
side signal if deemed necessary. For ramp meter applications, signal
heads should have red, amber, and green lamps.
Two lane ramps should utilize two signal poles, one on either side of the ramp. For
multi-lane ramps using staggered or multi-vehicle green periods, it is recommended
that two signal heads be used per lane.
The QTM and QCS 2010 provide standards for traffic signal applications. Ramp
meter designers must follow the standards in the Ashghal ITS Specifications.
Signal supports should be placed as far as practical from the edge of the
traveled way without adversely affecting the visibility of the signal indications.
Where supports cannot be located based on the recommended AASHTO (or
equivalent BSEN) clearances, consideration should be given to the use of
appropriate safety devices.
used in the ramp metering system. See Chapter 3 for more information regarding
vehicle detection options and installation guidelines.
Located just across the stop-line. Detects when vehicles pass the
Passage Detector
ramp meter. Also referred to as a check-out detector.
The detection area for the demand detector should be approximately 14m, or the
length of approximately 2 vehicles. The demand detection area must cover all
metered lanes. Figure 9-13 displays a typical inductive loop passage
detector/demand detector configuration.
1.8m
3.6m
3.0m 3.0m
2.1m 1.8m
1.8m
23 m min.
to edge
of gore
Queue detection is a crucial input for a traffic-responsive system algorithm, and must
be included in the ramp meter system.
Figure 9-14 displays typical inductive loop mainline detector configuration. If using
loops, multiple loops must be installed in sequence in order to accurately detect
speeds and vehicle queues.
3.6m
1.8m
Abundant, well placed, clear signage and pavement markings are critical to effective
and safe ramp meter installations. The need for signage increases with the
complexity of the system. For example, ramp meters at high-volume or expressway-
to-expressway interchanges require a network of signage that includes overhead
signs equipped with flashing beacons.
Table 9-6: Typical Types and Locations of Signs Used for RMS
Sign Location Application
Placed on the left side of the This warning sign is accompanied by a
frontage road approximately 60 yellow flashing beacon that is activated
RAMP meters upstream of the slip-ramp during metered periods to alert motorists of
METERED entrance point and downstream of the upcoming controlled ramp.
WHEN any signalized intersections or off-
FLASHING ramps.
Positioned near the beginning of the This regulatory sign is used to convert the
FORM dual-lane queue storage reservoir on single-lane on-ramp into a dual-lane queue
2 LINES the right side of the on-ramp. storage reservoir during flow signal
operations.
WHEN
METERED
Placed on both sides of the on-ramp This regulatory sign identifies the stop-bar
STOP at the stop-bar. This sign is placed location and is used to align drivers over the
HERE ON on the signal pole under the post- demand detectors placed upstream of the
mounted configuration. stop-bar.
RED
Pavement Markings
Ramp metering systems should utilize pavement markings consistent with standard
signalized intersections and expressway ramp operations, including: stop lines,
merge lines, and dashed lane separator lines. Lines may be paint, plastic, or raised
pavement markers. All pavement markers should conform to the guidelines set in
QCS 2010.
The ramp controller system consists of an enclosure, controller, load switches, input
files, loop amplifiers, and other miscellaneous devices, very similar to traffic signal
systems. The controller must be capable of meeting the needs and functions
outlined in the ramp metering study. Many standard controllers are available that
meet the general needs of a ramp metering system. The most common controllers
are “Type 170s” or “Type 2070s.” The Model 170 controllers are becoming obsolete,
so new installations should use the Advanced Transportation Controller (ATC) 2070,
except in cases where it will conflict with existing systems and/or system software.
The requirements for ducting along the Client’s roadways and expressways shall be
6 x 100mm unplasticated polyvinylchloride (UPVC) ducts running parallel to the
expressway in the reserved location within the utilities corridor on both sides of the
expressway. In a circumstance whereby ducts cannot be provided on both sides of
the expressway due to space restraints or other conflicts, use an 8 x 100mm
configuration along one side of the roadway. In both configurations, the top four
ducts shall be designated for ITS power and communications cables, and the bottom
two or four ducts shall be designated for drainage SCADA cabling. Ducts on both
sides of the expressway in the 6 x 100mm configuration is the standard requirement
and shall be followed on all schemes unless an exception is provided in writing by
the Client.
Chambers shall be located adjacent to the ITS equipment, and at both sides for all
expressway crossing locations. Where significant changes of direction of ducting are
required, this will be through a chamber and at a maximum spacing of 150m.
Sufficient drainage shall be allowed for in the area surrounding each chamber, and
each chamber shall have a sump to prevent flooding of the ITS network through the
conduit system.
For details regarding duct and chamber construction, alignment, location, installation,
marker tape, concrete encasement of ducts, duct assignment, and chamber cover
labeling, refer to Ashghal’s Civil and Structural Standards for ITS.
All duct and chamber materials and works shall be in accordance with Ashghal’s
Civil and Structural Standards for ITS and QCS 2010.
11 Power
The key design steps for an ITS device deployment (electric) power system are:
The total power requirement for any deployed device and/or deployment site is the
sum of the power requirements of the following:
The device(s) (e.g., detectors, CCTV camera, RWIS, LCS, DMS, etc.)
The enclosure components (refer to ITS Enclosure specification in Ashghal
ITS Specifications - General Provisions for ITS, QGEWC(E) Regulations for
electrical installation, and QGEWC(E) regulations for protective multiple
earthing).
Convenience outlet per BS1363, 10Amperes, inside the device enclosure.
Select conductor and breaker sizes based on the worst-case scenario, in which all
connected electric components are operating at full-capacity. Do not factor-in both
devices for ancillary services which perform opposing services and are not expected
to operate simultaneously (e.g., heater and air-conditioner). For this preliminary
sizing calculation, assume the expected load drawn from the convenience outlet to
be 8 Amperes at 240V.
A larger conductor size may be necessary to keep the voltage drop over long lengths
to 6.9V or less (refer to section 11.1.3).
See Table 11-1 for typical power requirements for commonly used ITS devices.
Listed power loads are for estimation purposes only; actual power loads should be
obtained from the related manufacturer(s) of the equipment being specified or
provided on each scheme.
Once a power supply is made available in the ITS device enclosure, the electric
power must be converted to the voltage and format (AC or DC) as appropriate for the
used electronic devices.
Part of the voltage made available at the point of service is dissipated by the power
cable that brings the electrical power to the intended ITS device. This loss of voltage
over the supply power cable (voltage drop) is proportional to the distance involved:
The standard electrical supply in Qatar is 240V, 50Hz. In some areas, however, the
supply voltage is 220V. For the purpose of voltage-drop consideration, the nominal
voltage is chosen at 230V.
Most electrical and electronic devices are designed to operate at the nominal
voltage, with varying tolerances above and below the nominal voltage. It is a
common practice in the ITS industry to limit the voltage drop to 2.5% or less. The
voltage drop requirements per the electrical code for 240V, 230V, and 220V are
7.2V, 6.9V and 6.6V, respectively.
At ITS deployment sites that may be located a large distance from the intended
power source, a significant voltage drop becomes an important consideration.
Given a fixed distance between an ITS deployment site and related power source, in
order to keep the related voltage drop within the design limit, a designer has to
decide how to keep the related voltage drop within the design limits. The two most
common methods are the use of larger power conductors or transmitting the electric
power over power cable at a higher voltage. The higher voltage method commonly
involves using a step-up transformer near the power source and a step-down
transformer at the related ITS deployment site. This choice is often dominated by
cost consideration.
1. Determine the total power requirement (Watt or VA) for the whole enclosure,
including devices which are powered from the enclosure. This should include
the added load of 240 V at 8A that the convenience outlet may draw.
2. Determine the required current (Amperes) that will flow through the power
conductors when all devices are operating at full capacity. In the case of
240V single-phase electric system, the current (I) is calculated as Total Power
requirement (in VA) divided by the product of applicable power voltage and
the power factor. Generally, a power factor of 0.8 is assumed, so the
resulting equation is: Power (VA) = Voltage (V) * Current (A) * Power Factor
(0.8).
3. Determine the wire size from the applicable table in the applicable electric
code that has a higher ampacity rating than the current calculated above. If
no electric code is available, use NEC requirements.
4. Calculate the applicable voltage drop using the formula shown above
(VD=2*I*D* Rs) Aim for a voltage drop of 6.9V or less.
5. Calculate the appropriate size of ground wire through the system using the
system load and the applicable electric code.
6. Choose an appropriate duct size for the power cable and ground wire. Make
sure that the duct is large enough for the power conductors. Power
conductors are not permitted to be placed in the same duct as communication
cables. In order to facilitate ease of cable pulling, and to provide an
acceptable rate of heat dispersion (through duct walls) when conducting lower
current than the rated limit, with three or more conductors the total of cross
section of all enclosed wires must be less than 40% of the actual cross
section area of the duct.
11.1.4 Metering
When necessary, provide metering for power draw to each ITS deployment site from
a power-supply point. In locations that do not use Automatic Meter Reader (AMR)
systems, safe and convenient meter reader access for utility personnel is an
important consideration in selecting the deployment location. Roadways with small
or no shoulders should not be considered for meter location. One way to circumvent
Coordinate with the power utility agency early in the design process to
determine metering options. Consider the following power metering
options:
Install power cable(s) in ducts and duct chambers separate from those used for the
installation of communications cables. The duct size is 100mm and the maximum
duct fill ratio should be 40 percent.
To facilitate cable pulling, chambers should be installed in a manner that the duct
center line is aligned with the center line of the chamber. Electrical chambers are
typically installed at a maximum separation of 150m to avoid impacting the power
cable because of the pulling tension. The chambers should not be installed in
carriageways, driveways providing access to properties, drainage ponds, or bottoms
of drainage ditches. The cover of the chambers should be labeled in accordance
with the Civil and Structural Standards for ITS. In addition, all chambers must be
earthed according to the electrical code.
The chambers should match the existing sidewalks elevations or surface level to
avoid the potential for pedestrians tripping. Concrete aprons should be provided for
all chambers that are not installed in a sidewalk. The concrete apron should be
sized according to the size of the chamber. In addition, the concrete apron should
be sloped away from the chamber to reduce the intrusion of water into the chamber.
Lightning spikes, transients, and line noise will degrade electronic devices over time.
Power conditioning provides protection from these issues as well as regulating
against sags (brownouts) and surges, thus reducing premature failure, improving
equipment performance, and maintaining the uninterrupted operation of key
equipment.
Lightning strikes are the most common cause of power surges to the ITS field
devices. The resulting voltage surges can propagate long distances along the cable
to the connected devices. In order to protect the related ITS deployment,
appropriate surge protection measures must be provided for the ITS devices. These
measures can be broken down into four components:
The provision of lightning rods is preferred for deployments involving great heights,
such as CCTV cameras and radio antenna at the top of tall poles, or DMS on
structures that stand out among the surrounding landscape and vegetation. The use
of a lightning rod is usually omitted for deployments involving relatively low heights
and where taller structures are present nearby.
The provision of one or more lightning rods over the ITS device, in conjunction with
an earthing conductor(s), can often help to divert the lightning discharges away from
the field device assembly. Lightning abatement measures such as this are only
effective if the lightning rod, related terminations, and the earthing conductors are
sufficiently robust to conduct and to survive lightning discharges.
Telecommunications cables and sensor cables from nearby locations, just like the
utility power cable, are subject to the same possibility of lightning strikes. The
requirement for appropriate surge protection measures must therefore be extended
to all cables brought into the enclosure of all ITS deployments.
A proper earthing arrangement must be provided at the support structure, and at the
enclosure for the system. Where the enclosure is installed at or close to the base of
the support structure, both the support structure and the enclosure may be bonded
to the same earthing system.
It is important that the related earthing system is able to disperse the electric charge
from the lightning strike to the surrounding earth mass quickly. This requirement is
translated in the performance requirement on the earthing system to have earthing
resistance of 25 Ohms or less.
The standard is to use a 16mm diameter steel core copper jacketed type earth
electrode, not less than 3.6m long, in 1.2m sections coupled by strong bronze
couplers for earthing. When multiple rods are needed to achieve the required
maximum ground resistance (25 Ohms), space the ground rods at least as far apart
from each other as the length of the rods.
Earth rod electrodes, systems, and testing procedures are specified in QCS 2010,
Section 21, Part 21 (Lightning Protection). The designer should assess the site
environmental conditions to determine if the earthing system identified in QCS 2010
is sufficient for the device location. Some devices require more robust earthing
requirements, such as CCTV cameras located at the tops of hills and mounted to
high structures.
Frequent shutdowns and restarts of the electronic devices generally cause the
electronic device to fail prematurely. Intermittent device shutdowns are generally
triggered by low power-supply voltage, which are often the result of brief drops in
supply voltage (brownouts) lasting seconds, and to lesser degrees complete power
outages (blackouts) lasting more than a few minutes.
A UPS providing four hours of power shall be provided for all ITS field devices and
field communications hubs. Alternatively or in addition, a dual power supply may be
designed for each site.
12 Communication
The communication protocol for Qatar’s roadway ITS devices should be based
around those used for wide area network (WAN) via Internet Protocol (IP). The
WAN is to be a fiber Ethernet network (possibly multi-Gigabit (where required))
which runs the length of the roadway connecting the ITS devices and subsystems. It
should be constructed as a redundant ring. The data will be carried between nodes
on fiber-optic cables and will be converted to a local telecommunications method
(e.g., fixed via copper circuits, or wireless Wifi, WIMAX, DSRC etc.) in the roadside
enclosures.
The Ethernet WAN ring will be used to carry all control, monitoring, and video
information. The ring topology will provide redundancy (i.e., closed loop) such that
all nodes can be communicated with, even if the ring is cut in a single place.
Remote ITS field devices may use wireless connection to the nearest location
containing a fiber drop point. The capacity and security of the wireless connection
shall not be inferior to the similar wired connection.
Generally, the key design considerations for the F2C communications system for an
ITS deployment are:
Each ITS system brings with it particular communication needs. The communication
pattern and bandwidth requirement are the two key factors in evaluating what the
system device needs to operate effectively.
Table 12-1 contains the typical bandwidth requirements for various ITS devices.
These requirements must be accommodated by the selected communications
medium.
CCTV cameras, unless being used to transmit strictly still images, will require an
always-open, continuous communication session and the means to support the
relatively large communications bandwidth is required for the transmission of the
video image. A full T-1 (1.544 Mbps) or E-1 (2.048Mbps) service is typically used for
video transmission to the TMC, though lower bandwidths (such as fractional T1 or E-
1) could be used for video streams with low frame rate (frames-per-second).
12.3 Availability
Potential F2C communication arrangements that are appropriate for ITS systems
are:
Unless otherwise specifically stated, use single-mode fiber-optic cable for all
communications backbone infrastructure. Use cellular data services for portable ITS
deployments and for some stationary DMS installations.
Design Considerations:
Verify that the cable installation through the intended route is feasible.
Advantages:
Virtually unlimited bandwidth.
No danger of voltage surges.
Disadvantages:
Potential difficulties in achieving clear right-of-way for installation.
High installation cost of infrastructure for the cable.
Design Considerations:
Supports bandwidths limited to T-1 (E-1) over less than 2 km without the use
of repeaters.
Abatement measures against voltage surges are necessary.
Advantages:
Lower initial investment.
Disadvantages:
Recurring usage fees.
Reliance on service provider for repair services.
Propagation of voltage surges from third-party system are possible.
Design Considerations:
Except for short-range paths that can be visually evaluated, a path study,
performed by a communications consultant or a system integrator, is
recommended for new installations. A path study predicts the signal strength,
reliability, and fade margin of a proposed radio link. While terrain, elevation,
and distance are the major factors in this process, a path study must also
consider antenna gain, feed line loss, transmitter power, and receiver
sensitivity to arrive at a final prediction.
Abatement measures against lightning strikes are necessary for outdoor
installations.
Maximum data bandwidth and maximum transmission distance as claimed by
manufacturer are singularly achievable, but not both attainable
simultaneously.
Advantages:
High bandwidth (up to 300 Mbps, up to 50 km depending on technology used)
Point-to-point, multi-point, repeater configurations possible, depending on
technology used.
Low infrastructure costs
Disadvantages:
A clear transmission path is not always possible.
Requires a RF license application/acquisition, unless license-exempt RF
bands are used.
Periodic tree-trimming may be required to maintain clear line-of-sight.
Design Considerations:
Cellular system coverage outside of population centers typically is focused
along major arterial roads, which coincides roughly with areas where the need
for ITS deployments may be the greatest.
Verify that there is adequate cellular signal strength available at the planned
deployment site. This may simply involve using a portable computer
equipped with a compatible wireless adaptor module and antenna to measure
signal strength and confirm upload bandwidth.
Verify that Machine-to-Machine (M2M) service, with guaranteed bandwidth, is
available in the related deployment area.
Advantages:
Allows much flexibility in the planning of device deployment sites.
Available in majority of the regional expressways.
Antenna height does not have to be very tall.
Low set-up and infrastructure costs.
Where available, M2M service provides guaranteed (high) bandwidth.
Disadvantages:
Availability of data channels is low in/near densely populated areas.
Where data transmission is routed through public domain, significant security
measures are required.
Recurring costs incurred.
Design Considerations:
Verify that there is adequate satellite data signal strength available at the
planned deployment site. This may involve using a portable computer
equipped with compatible wireless adaptor module and antenna to measure
signal strength and confirm upload bandwidth.
Advantages:
Available practically everywhere.
Installation costs are negligible.
Disadvantages:
Availability affected by usage surges.
Signal quality affected by weather events.
Significant security measures necessary.
Line of sight with satellites required – tree trimming may be necessary.
This section discusses the logical communications interface between a TMC and the
roadside devices that the center controls or monitors.
In the future, the Client may want to communicate with field devices procured
from different vendors. If a closed proprietary communications interface is
used, the Client will either have to use the same vendor again, or update the
TMC software to support a different vendor’s communications interface, both
of which may be costly. However, with open standards, there are
opportunities that new devices can be added onto an existing communications
channel and mixed with different types of devices on the same line.
12.4.1.1 NTCIP
NTCIP is an example of a family of open standards that will be used in Qatar for
remote control and monitoring of roadside equipment from a TMC. NTCIP defines
open, consensus-based communications protocols and data definitions for the traffic
management industry.
The NTCIP Framework, shown in Figure 12-1, uses a layered or modular approach
to communications standards, similar to the layering approach adopted by the
Internet and International Organization for Standardization (ISO). The NTCIP family
identifies five layers, or levels, for defining the communications interface between the
TMC and the field device. The five levels are: information level, application level,
transport level, subnetwork level, and plant level.
Application C2C XML (2306) DATEX (2304) FTP (2303) TFTP (2302) SNMP (2301) STMP (2301)
Level
Plant
Level Dial-Up Telco Fiber Coax Wireless Twisted Pair Leased Line
For more information about using NTCIP and the NTCIP Framework, the
Designer should read The NTCIP Guide, which can be downloaded at
www.ntcip.org.
When using NTCIP to define the communications interface for the ramp metering
system, the designer should specify which NTCIP standard(s) to use for each level.
Multiple profiles may be selected for an implementation. For example, at the
subnetwork level, the communications is initially point-to multi point protocol (PMPP),
but Ethernet is expected to be used in the future. Therefore, standards NTCIP 2101
for PMPP and NTCIP 2104 for Ethernet should be specified.
Information Level – The NTCIP information level defines the data to be used
for exchanging information between the TMC and the field devices. It also
defines the functions the system is to support.
Application Level – The application level standards define the rules and
procedures for exchanging information data. The NTCIP 2300 series defines
the application profiles that can be used. The applicable profiles for managing
ramp metering systems are contained in NTCIP 2301, Simple Transportation
Management Framework (STMF) Application Profile. NTCIP 2302, Trivial File
Transfer Protocol – Application Profile and NTCIP 2303, File Transfer
Protocol – Application Profile, which are primarily used to transfer files, may
also be applicable.
Transport Level – The transport level standards define the rules and
procedures for exchanging the application data between two points on a
network, including any necessary routing and network management functions.
The NTCIP 2200 series defines the protocol stacks that can be used in
managing the communications network. At least one of the following
transport profiles should be included in the specifications if deploying NTCIP:
Subnetwork Level – The subnetwork level standards define the rules and
procedures for sharing the same communications line with other devices
using the same subnetwork profile. At least one subnetwork profile should be
included in the specifications if deploying NTCIP. The current applicable
NTCIP subnetwork profiles are:
Plant Level – The plant level is shown in the NTCIP Framework only as a
means of providing a point of reference to visualize the standards profile when
learning about NTCIP.
The vendor will provide the Client with all documentation, including the source
and object codes, for the communications interface. The documentation will
consist of the source code for the communications interface, and any and all
operator's and user's manuals, training materials, guides, listings, design
documents, specifications, flow charts, data flow diagrams, commentary, and
other materials and documents that explain the performance, function, or
operation of the communications interface. The documentation will include a
description of the data elements/objects required to perform each function
required in the specification, including the conditions and the sequence of
events that the data elements/objects are exchanged between the TMC and
the device. The software documentation defining the data elements/objects
will be in the form of a management information base (MIB), using Abstract
Syntax Notation One (ASN.1).