sr-11/ome port of entry...sr-11/ome port of entry syrs: rbms –version 3.0 version description #...

SR-11/OME Port of Entry SyRS: RBMS –Version 3.0

SR-11/OME Port of Entry

System Requirements Specification (SyRS)

Regional Border Management System

Final Version 3.0

Released on: 2017-03-17


Version Description

# Date Author Notes

0.1.3 2016-01-29 PC (IBI) ▪ Initial version released for internal review ▪ Partial coverage, 9 out of 11 functional sections only

0.2 2016-03-31 PC (IBI) ▪ Updates based on 0.1.3 comments ▪ Restructured organization of sections 2-5 ▪ Significant rewrite of sections 2-5 ▪ Production of sections 9 (Training), 11 (System Config.

Management) ▪ Production of Non-Functional Requirements (Section 12) ▪ Absorbed Incident Management section, previously stand-alone,

into Traffic Management for better readability and consistency with logical architecture

0.3 2016-04-22 EK (IBI) ▪ Integration of requirements management tool output to deliverable with context narrative.

1.0 2016-04-29 EK (IBI) ▪ Integration of Field Device and Communications with central system requirements for Master SyRS document

▪ Diagrams and context added throughout

1.1 2016-05-24 EK (IBI) ▪ Restructured central systems section to follow Mission and Enabling functions format

▪ Scrubbed requirements language for consistent use of defined terms (both glossary and data dictionary) and verbs

▪ Updated diagrams

1.2 2016-05-30 EK (IBI) ▪ Finalized glossary ▪ Harmonized defined terms in body of document ▪ Updated tool-tips and links for defined terms ▪ Finalized needs tracing

1.3 2016-06-13 EK (IBI) ▪ Corrected CBP acronym definition ▪ Corrected headers to reflect correct document version

1.4 2016-10-05 EK (IBI) ▪ Consolidated comment response version with changes tracked for internal review

2.0 2016-10-07 EK(IBI) ▪ Consolidated comment response version with changes tracked for client review of Final Draft

2.1-2.6 2017-03-15 IK, MC, DL (IBI)

▪ Addressed all comments from stakeholders, including from the System Requirements workshop #2

3.0 2017-03-17 IK, MC, DL (IBI)

▪ Addressed final draft comments from stakeholders.


i

Table of Contents 1 Central System Functional Requirements .......................................................................................... 1

1.1 High-Level Project Background .............................................................................. 1

1.2 Requirements Section Overview ........................................................................... 5

1.3 Functional Overview .............................................................................................. 5

1.4 Enabling Functionality through Exchanges of System Data .................................... 7

1.5 Data Types Overview ............................................................................................. 8

1.6 Reviewing the Requirements ................................................................................. 9

1.6.1 Reviewing Document Sections ............................................................................ 10

1.6.2 Reviewing the Requirement Statements ............................................................. 10

1.7 Mission Functions ............................................................................................... 12

1.7.1 Border Traffic Monitoring .................................................................................... 12

1.7.2 Traffic Video Surveillance .................................................................................... 30

1.7.3 Border Traffic Management ................................................................................ 39

1.7.4 Border Traffic Analysis ......................................................................................... 60

1.7.5 Alert Management .............................................................................................. 72

1.7.6 System Reporting ................................................................................................ 84

1.8 Enabling Functions .............................................................................................. 96

1.8.1 Data Management .............................................................................................. 96

1.8.2 User Interface Management ............................................................................. 110

1.8.3 System Administration ...................................................................................... 145

1.8.4 System Interface Management ......................................................................... 164

1.8.5 User Training ..................................................................................................... 184

2 RBMS Field Devices ....................................................................................................................... 189

2.1 General Requirements ...................................................................................... 189

2.1.1 Environmental Requirements ............................................................................ 189

2.1.2 Electrical Power Requirements .......................................................................... 190

2.1.3 Communications Integration Requirements ...................................................... 191

2.2 RBMS Closed Circuit Television System ............................................................. 191

2.2.1 Functional Requirements .................................................................................. 193

2.2.2 Implementation Requirements ......................................................................... 197

2.3 Approach Lane Variable Message Signs ............................................................. 200




ii

2.4 POE Gate/Lane Status System ........................................................................... 207



2.5 Point Vehicle Time Detection ............................................................................ 212



2.6 Vehicle Detection Station .................................................................................. 218



2.7 Variable Toll Message Signs ............................................................................... 225



3 RBMS Communications System ..................................................................................................... 234

3.1 Real-Time Data Acquisition (US) ...................................................................... 235

3.1.1 US Side Port-of-Entry Area Wireline Access Network ........................................ 236

3.2 Real-Time Data Acquisition (Estados Unidos Mexicanos) ................................... 239

3.2.1 Mexican Side Port-of-Entry Area Wireless Mesh Access Network...................... 239

3.2.2 Mexican Side Port-of-Entry Area Wireline Access Network ............................... 241

3.2.3 Mexican Side Port-of-Entry Pre-Approach Communications .............................. 244

3.3 Network Management ...................................................................................... 248

3.3.1 General ............................................................................................................. 248

3.3.2 NMS Server ....................................................................................................... 252

3.4 Data Backhaul to RBMS Control Center ............................................................. 253

3.4.1 Backhaul of US Side Access Level Network ........................................................ 254

3.4.2 Interborder Communications Link ..................................................................... 255

3.5 Data Dissemination to Partners ......................................................................... 258

4 System Quality (Non-Functional) Requirements ............................................................................ 260

4.1 External Quality Attributes ................................................................................ 260

4.1.1 External Quality Requirements .......................................................................... 260

4.2 Internal Quality Attributes ................................................................................. 268

4.2.1 Internal Quality Requirements .......................................................................... 268

Referenced Terms ...................................................................................................................................... 271


iii

Table of Figures

Figure 1: USA/Mexico Border Crossings in the Region .................................................... 2 Figure 2: New Border Crossing and Vicinity .................................................................... 3 Figure 3: RBMS Elements - The Big Picture ..................................................................... 4 Figure 4. The 11 Major Sections of System Functionality/Behavior/Capability ............... 5 Figure 5. Relationships of RBMS System Capabilities, Data Stores, and External

Interfacing Systems .................................................................................... 8 Figure 6. RBMS Border Traffic Management Zones Where RBMS Is Required ............. 12 Figure 7: Border Traffic Monitoring with RBMS Overview ............................................ 13 Figure 8: Border traffic monitoring architecture ........................................................... 14 Figure 9. The Data Stores Directly Relevant to Traffic Monitoring ................................ 15 Figure 10. Example Data Items Relevant to Border Traffic Monitoring Classified under

the Human Factors Terms ........................................................................ 16 Figure 11. Functional architecture within the Border Traffic Monitoring function

specifying sources of the data to be provided. ......................................... 19 Figure 12: Traffic & Incident Management Regional Border Traffic Management Zones

.................................................................................................................. 39 Figure 13: Traffic & Incident Management in RBMS ..................................................... 40 Figure 14: Traffic & Incident Management Architecture .............................................. 41 Figure 15: RBMS Border Performance Monitoring Architecture ................................... 60 Figure 16: Alerts as they relate to Users and Interfacing Systems in RBMS .................. 72 Figure 17: Alerts Origin Sources .................................................................................... 73 Figure 18: Alert Types ................................................................................................... 74 Figure 19: Alert Taxonomy ............................................................................................ 75 Figure 20: Alert Management Functionality .................................................................. 76 Figure 21: Definitions of Alerts ...................................................................................... 77 Figure 22. Overview of Data Reporting Functionality .................................................... 85 Figure 23: RBMS Reporting Architecture ...................................................................... 86 Figure 24. Summary view of elements of the Data Management capability ................. 97 Figure 25: RBMS Data Management Architecture ........................................................ 98 Figure 26. User Interfaces High-level Architecture. .................................................... 110 Figure 27. User Interface Requirements Relationship to Other Requirements Sections.

................................................................................................................ 111 Figure 28: RBMS User Interface Management Architecture. ...................................... 112 Figure 29. Conceptual Convention Adopted in This Specification for User Interface. . 113 Figure 30. Notional Representation of a Traffic Management User Interface. ........... 114 Figure 31. Representative Illustration of the Status of Crossing Lanes (a Static Data

Item) at the Border Crossing. .................................................................. 115 Figure 32. Example of a Performance Dashboard. ...................................................... 116 Figure 33. Specific UIs and UI elements described in the requirements of the RBMS. 121 Figure 34: RBMS System Configuration Management Architecture ........................... 148 Figure 35. Sections of this specification addressing RBMS' behavior and relationship

with External Interfacing Systems ........................................................... 165 Figure 36. Context Diagram for the RBMS Central System illustrating all the known

Interfacing Systems and classifying them (i.e.:inter/external). Also illustrated is the side of the border a system resides, US-only or US-


iv

Mexico co-located/duplicated. The interface identifiers (i.e.:IF-XY) referencing the appropriate IRS are also provided. ................................ 166

Figure 37: RBMS System Interface Management Architecture ................................... 168 Figure 38: IF04 Data Flows between OME Toll System and RBMS Central System ..... 180 Figure 39: IF06 Data Flows between the Data Hub and RBMS Central System ........... 181 Figure 40a: IF07a Data Flows between CHP and RBMS Central System ...................... 182 Figure 41b: IF07b Data Flows between the CBP Watch Commander and RBMS Central

System .................................................................................................... 182 Figure 42c: IF07c Data Flows between Aduanas Management and RBMS Central

System .................................................................................................... 183 Figure 43: RBMS Field Device - Closed Circuit Television (CCTV) System Architecture 192 Figure 44: RBMS Field Devices - Approach Lane Variable Message Sign (VMS) System

Architecture ............................................................................................ 201 Figure 45: RBMS Field Device POE Gate Status Detection Architecture...................... 209 Figure 46: RBMS Field Device Point Vehicle Time Detection (PVTD) Architecture ...... 213 Figure 47: RBMS Field Device - Vehicle Detection Station Architecture ..................... 219 Figure 48: RBMS Field Devices - Variable Toll Message Signs Architecture................. 226 Figure 49: RBMS Communications Network Architecture........................................... 234 Figure 50: RBMS Communications Network Technology ............................................ 235 Figure 51: Border Region Fiber Optic Network ........................................................... 253

SR-11/OME Port of Entry SyRS: RBMS – Version 3.0

1

1 Central System Functional Requirements

1.1 High-Level Project Background

The SR-11/Otay Mesa East (OME) border crossing is a unique and complex environment involving a multitude of federal, state, and local agencies from both the USA and Mexico. In addition, the border area presents unique political, institutional, safety, and security considerations that impact operations and systems deployments for the purposes of this project. This section provides a brief overview of the overall border crossing project; however, this document does assume a basic understanding of the border environment, the SR-11/OME ITS project, and the work that has proceeded the development of these System Requirements. For additional background on the border crossing process, objectives of the project and systems, User roles and responsibilities, current border crossing layouts, and basic system needs, reference should be made to the SR-11/OME Binational Concept of Operations v4.1.

Project Mission Statement & Role of the Regional Border Management System

The SR-11/OME border crossing project is a unique undertaking with ambitious objectives and goals. The overall purpose of the border crossing is to provide enhanced regional binational connectivity and prosperity. The new crossing is unique in that it will be at least partially funded through tolling of passenger and truck traffic choosing to use the new crossing to save time and experience a more consistent crossing experience. The system requirements for the Regional Border Management System (RBMS) defined in this document are focused on a System that supports:

• Orchestration of regional and border traffic and border crossing operations from both the USA and Mexico through the binational sharing of operational information and functionality.

• Enhanced binational interagency cooperation and improved accuracy and timeliness of information to border region travelers.

• Enhanced traffic management functions specific to the unique and innovative features that enhance User perception and attractiveness of the new border crossing, including enhanced reliability, improved information, and improved management of access facilities.

• Management of approach lane elements to the Port-of-Entry (POE) to more effectively deliver traffic for border crossing processes, as well as balance the flow and supply of available processing lanes with the changing demands of traffic by type and crossing classification throughout the day (e.g. cars versus trucks, SENTRI versus READY traffic, etc.).

• Supporting requirements for toll operations consistent with tolling industry best practices.

• Collection of the data and on-going storage and calculation of performance metrics essential to monitor border traffic/wait time trends and adjust pricing of the new border crossing to balance crossing demand and supply.

• Leveraging and integrating existing and planned traffic management centers and information resources on both sides of the border.

Overall Project Mission Statement Provide a new, safe, secure, green,

flexible, and efficient border crossing and associated

access roads.


2

System Deployment Location

Figure 1 displays the overall border region along San Diego County, as well as the relative location of the proposed new crossing for OME.

Legend Existing border crossings: San Ysidro/Puerta Mexico/El Chaparral Otay Mesa (West)/Mesa de Otay Tecate/Tecate Private crossing (in development): Cross border Airport Terminal Planned crossing: Otay Mesa East

Figure 1: USA/Mexico Border Crossings in the Region

While the new planned crossing at OME is the focus of many of these requirements, RBMS can be viewed as an orchestrating system over the broader San Diego/Tijuana region. The OME crossing will be located a little more than two miles east of the existing Otay Mesa (west) crossing and will allow passenger vehicle, commercial vehicle, and pedestrian traffic in both directions. Figure 2 provides a high-level overview of the proximity of the new border crossing. Each side of the crossing will provide the following direct access to major highway and freeway networks:

• SR-11 will be constructed as a new facility and provide direct and exclusive access to SR-905, SR-125, and major roadways in the Otay Mesa area. The project has been divided into three basic segments for design and implementation purposes. Segment 1 was recently completed and is open to traffic.

• A new access facility for passenger and commercial vehicle traffic will be constructed in Mexico to connect the border crossing with Highway 2-D that connects Tijuana to Tecate and Mexicali.


3

Figure 2: New Border Crossing and Vicinity

Figure 3 displays a high-level data flow diagram including RBMS and associated systems interfaces and external systems. The functionality of the RBMS central system, user capabilities and access, field device types, and system interfaces to the data hub are described in this System Requirements document. Flows shown are consistent with the National ITS Architecture and fit within the regional system architecture in place and under development. Specific data flows and requirements are discussed in the appropriate sections of this document, but, at a high level, system elements include:

• RBMS Central Systems and Users – The core focus of these system requirements focused on supporting the overall border crossing project objectives.

• Data Hub – The central point of binational data sharing between systems and management centers on both sides of the border that will be expanded upon current data integration and fusion systems in the region. RBMS interfaces to the data hub are defined in this System Requirements document.

• SCT/Tijuana Traffic Management Center (TMC) – The management center and applications being planned and implemented in Mexico to support border and traffic management needs in Tijuana.

• Tolling/Congestion Pricing System (SBX) – The tolling back office and roadside tolling systems supporting collection of tolls for the new border crossing in both directions. Interfaces with RBMS and the tolling systems are defined in this document.

• Caltrans D11 – Transportation Management Center – The regional traffic management center for San Diego supporting US freeway/highway access in the border region and beyond.

• Roadway Systems and Devices (Mexico) – Field devices and sensors providing situational awareness and management functionality that will be managed through the SCT/Tijuana TMC with some elements having redundant communications from RBMS.

• Roadway Systems and Devices (US) – Field devices and sensors providing situational awareness and management functionality that will be managed through the Caltrans TMC or RBMS.


4

Figure 3: RBMS Elements - The Big Picture


5

1.2 Requirements Section Overview

This section of the specification contains the system behavioral requirements (functional, informational, performance) for the Regional Border Management System’s (RBMS’) central software component. The section has been developed utilizing a function-based approach (see INCOSE Handbook v4 2015) and is supported by a bespoke information architecture guided by the principles of the US Department of Transportation (DOT) National Intelligent Transportation Systems (ITS) Architecture, where Data Items referenced in the requirements are defined, attributed, and maintained in the RBMS Data Dictionary (See Referenced Terms: Business Data Dictionary).

The section is one in a number describing the totality of RBMS as it will be initially deployed into the operational environment. Further lifecycle considerations (e.g.: installation, maintenance, change control, retirement processes) are described elsewhere. There are two sections in addition to this describing the deployed system; when taken together they describe the whole physically represented RBMS and its requisite capabilities, behaviors, functions, and performance. They are:

1. RBMS Field Devices (Section 2): those system elements (e.g.: Closed Circuit Television [CCTV], Variable Message Signs [VMS], Point Vehicle Time Detection [PVTD]) that reside in the field and serve as sensor or effectors for the central system (Section 1 of the specification). For the purpose of this central system specification these are treated as External Interfacing Systems (internally interfacing); Data Items residing in those system elements are paired with those in the RBMS central system

2. RBMS Communications System (Section 3): the communications system and infrastructure enabling the exchange of RBMS Data Item information between RBMS and External Interfacing Systems, as well as within RBMS

1.3 Functional Overview

The functional and non-function requirements defined in this section have been organized into eleven (11) major sections (Figure 4). Each section is further sub-divided into sub-sections where the relevant requirements are contained. The requirements describe the behavior the System needs to exhibit in order to meet the needs of its Users. System requirements are statements of necessity for the System, rather than statements of necessity Users have of the System (also known as User Requirements).

To clarify the requirement intent for the reader, text describing the purpose of the function has been included as an introduction to each section and sub-section. This text explains, in uncomplicated terms, what value-add to Users is being asked for, what needs the requirements address, and how the System should generally behave to meet those needs.

Figure 4. The 11 Major Sections of System Functionality/Behavior/Capability

Traffic

Monitoring

Traffic

Management

Incident

Management

Status AlertingPerformance

Analysis

System

Reporting

Data

Management

User Interface

Management

System Interface

ManagementSystem Training

Configuration

Management


6

The capabilities illustrated in Figure 4 can be better understood and classified under two broad headings:

1. Mission Functions, which are those functions the operational Users have and need and which serve the primary purpose for why the System is being acquired; and

2. Enabling Functions, which are those functions the System has that are used to service the needs of Users and the System itself but do not directly contribute to the operational mission of the System.

The functions within these two broad headings are summarized as follows:

1. Mission Functions

o Border Traffic Monitoring: functionality that provides a User the capacity to construct and maintain situation awareness in the traffic zones of the border region by presenting the necessary information and information-seeking abilities to them

o Traffic & Incident Management: functionality that provides a User the capacity to influence and control the movement of vehicles and traffic flows in the border region in a variety of ways by means of planning tools and effector controls, along with functionality that provides a User the capacity to manage unanticipated, exception traffic management scenarios that occur in the field by means of prioritized planning tools and effector controls. Incident Management can be considered an extension of border traffic management functionality.

o Border Traffic Analysis: functionality that provides a User the capacity to understand the operational performance of the Border Crossing and region against standard benchmarks and methods by means of calculated values, either discrete or ongoing. Border Crossing performance analysis can be considered an extension of Border Traffic Monitoring.

o Status Alerting: functionality that provides a User the capacity to understand, in a timely fashion and when required, the type and degree of a special condition detected. Status Alerting can be considered an extension of Border Traffic Monitoring.

o System Reporting: functionality that provides a User the capacity to document and configure the documentation of Historic Data in the System.

2. Enabling Functions

o Data Management: functionality that supports the intended state of proper operation of the System, as well as the User’s confidence in information validation presented to them. Data warehousing and storage are also considered.

o User Interface Management: functionality to manage, modify, prepare the relation, co-location, representation, and presentation of Data Items to Users on Graphical User Interfaces (ostensibly using personal computers and devices) and Mechanical User Interfaces (ostensibly using physical, mechanical elements)

o Configuration Management: functionality that supports the management, monitoring, and modification of System configuration items, from internal rule-based processes to adding/modifying interfacing hardware in the field


7

o System Interface Management: functionality for the management of interfacing relationships between the central system, RBMS Field Devices, and External Interfacing Systems

o System Training: functionality for the training of Users including training tools, scenarios, and task evaluation by trainers

1.4 Enabling Functionality through Exchanges of System Data

The benefits of these capabilities are realized through the proper provisioning of the System, as well as availability and free exchange of the data necessary for to execute the features and functions described in the requirements. It is this availability and exchange of information that serves the appreciation of the System and is therefore crucial to understand and define during the design phase so that sufficient information can be made available to achieve the desired benefit.

Data Items in the central system may originate through generation from within (e.g.: through a calculation), or captured from the external world (e.g.: via an External Interfacing System). Once within, they will be exchanged, processed, evaluated, and calculated upon, generating new Data Items in the process. Certain Data Items will then be either represented to human Users via a User Interface, shared via a Connection Session to an External Interfacing System, or stored locally or remotely.

Figure 5 illustrates the relationship between system capabilities, information sources (i.e.: Data Stores) information flows (arrows), and information boundaries (borders) that work together to realize the benefits of the System. This specification section (System Capabilities) utilizes this representation as the basis of requirement definition, hierarchy, and partitioning for the purpose of the RBMS acquisition.


8

Figure 5. Relationships of RBMS System Capabilities, Data Stores, and External Interfacing Systems

1.5 Data Types Overview

To achieve a both a complete and minimal set of System requirements, the System’s information content (sum of all Data Items) and the relationships between Data Items must be formally defined and controlled. A Data Item called out as a product of one requirement may, for example, become a triggering condition for another; without an organizing framework it would not be possible to account for similar relationships fully or assure a reliable description of the information necessary to fulfill system functionality and behavior.

RBMS Field System

POE Gate

RBMS

Central System Data Store

Traffic Monitoring Traffic ManagementIncident

ManagementStatus Alerting

Performance

AnalysisSystem Reporting

Data ManagementUser Interface

Management

System Interface

ManagementSystem Training

Configuration

Management

System Config. Store

Business Rules Store

System Alerts StoreStatic Border Store

Live Traffic Store Live System Store Historic Data Store

Data Items

Data Items Data Items Data Items Data Items

Data Items

Data Items Data Items Data Items Data Items Data Items

Data Items - IF01

Data Items - IF05

Data Items - IF02

Data Items - IF03

Data Items - IF08

Data Items - IF12

Data Items - IF13

Data Items - IF04

External System

OME II Crossing

Tolling System

Data Items - IF0X

External System

Data Hub

RBMS Field System

Approach Lane VMS

RBMS Field System

RBMS CCTV

RBMS Field System

Point Vehicle

Detection

RBMS Field System

VTMS

RBMS Field System

Traffic Flow

Sensors

External System

Lane Assignment

VMS

External System

CBP Border Wait-

Time Website

Data Items - IF06

RBMS Central System Boundary

RBMS Whole System Boundary

Externally Interfacing Systems


9

To address this issue, seven Data Stores have been identified as conceptual repositories of information managed within System. These Data Stores are referenced throughout the System requirements in this section and include the following:

1. Live Traffic Store: A dynamic conceptual information store that contains the most current account of the observed status of traffic in the border region; this information is sourced from External Interfacing Systems directly, internally calculated or evaluated, or User entered

2. Static Border Store: A static, or very slowly changing conceptual information store that contains the Border Infrastructure configuration including roadways, roadway gantries, location of field ITS equipment, locations and layout of border region facilities such as Customs and Border Protection (CBP), Aduanas, tolling facilities, ground topology, intersecting transportation routes (bus, rail), among others

3. Live System Store: A dynamic conceptual information store that contains the most current account of the observed RBMS System status; this information is sourced from RBMS central system components, RBMS Field Devices, and External Interfacing Systems

4. System Configuration Store: A static, or very slowly changing conceptual information store that contains the RBMS central system’s configuration, including hardware versions, software configurations, configuration item settings, and the System User Model

5. Business Rules Store: A static, or very slowly changing conceptual information store that contains the logical rules for calculating Performance Measures and Traffic Management Strategies

6. System Alerts Store: A static, or very slowly changing conceptual information store that contains the logical rules for detecting, classifying, and distributing Alerts to Users and retaining in System logs

7. Historic Data Store: An historic conceptual information store that contains an historic account of the observed status of traffic in the border region; this information is sourced from External Interfacing Systems directly, internally calculated or evaluated, or User entered

1.6 Reviewing the Requirements

This document contains the functional and non-functional requirements and description of the RBMS. It is organized into the following five major sections:

1. Central System Functional Requirements describing the capabilities of the central information system that exchanges and processes information with Field Devices and Users via User Interfaces. This section is sub-divided in two: mission functions (those functions the System provides Users to fulfill their traffic management duties), and enabling functions (those functions the System must have internally to support and realize the mission).

2. RBMS Field Devices providing requirements defining the behavior and implementation of RBMS Field Devices that communicate with the RBMS Central System and, in certain


10

cases, the traveling public (e.g.: variable message signs). This section is sub-divided by each Field Device type.

3. RBMS Communications System, that describe the behavior of communications infrastructure to be implemented in the USA and MEX enabling the elements of RBMS to operate together. This section is sub-divided by USA and MEX requirements for the communications system, as well as networking management across both territories and backhaul to the RBMS Control Center.

4. System Quality (Non-Functional) Requirements describing the performance of the RBMS. This section is sub-divided by external quality (what is observable to Users of the System), and internal quality (attributes within System crucial to enabling external quality and performance).

5. Referenced Terms providing the definition and, in certain cases, explaining the relationship between defined terms utilized in the requirements.

1.6.1 Reviewing Document Sections

Each section begins with a narrative overview that serves as an introduction to the requirement statements provided at the end of the section. The overview is intended to explain who the stakeholders of interest are for the section, their concerns with the specific needs addressed in the section, and how the System will generally behave to address those needs.

1.6.2 Reviewing the Requirement Statements

The requirements are presented in a tabular format and contain several components that are necessary for the reader to consider in their review as follows:

• Unique ID – a unique identifier for each requirement. In addition to distinguishing each requirement, the ID also conveys parent-child ownership between requirements of the section via a dot (“.”) notation. The composition of the Unique ID is described in further detail below.

• Requirement Text – the requirement statement. Requirement statements typically include defined terms (see the Referenced Terms section) that are italicized to differentiate their presence to the reader. The first time a defined term appears in this document, the term is shown in blue, e.g., System. When reviewing on screen, the reader may also move their cursor to the term, and a window will pop up with a definition as shown below.


11

• Requirement Type – that describes either the (functional) requirement’s purpose in the System’s logical architecture (i.e.: an input, process, or output of information flow) or if it is a security or performance requirement.

• Verification Type – that describes the method that should be used to verify the requirement, i.e.: analysis, demonstration, test, inspection

• Needs Trace – that relates the requirement back to the RBMS TMS needs

1.6.2.1 Composition of Requirement Unique IDs

Because RBMS is a complex information system that involves a central system component, interfaces to many field devices and external systems, as well as having a purpose-built communications network, the requirement Unique IDs have been encoded with additional information to aid the reader who will have to cross-reference requirements in the future.

A requirements Unique ID (e.g.: CS-TMO-01.1) encodes three pieces of information. They are:

1. XX prefix – the major system area that the requirements relates to, as follows: a. CS – the RBMS Central System b. FD – the RBMS Field Devices c. IS – the RBMS enabling infrastructure components d. SQ – System Quality

2. YYY prefix – designating the sub-function (in the case of CS) or system (in the case of FD, IS). Designation key is as follows:

a. RBMS Central System (CS-YYY) i. TMO – Traffic Monitoring ii. TVS – Traffic Video Surveillance iii. TMG – Traffic Management iv. ANL – Traffic Analysis v. ALT – Alert Management vi. REP – System Reporting vii. DMG – Data Management viii. UIF – User Interface Management

ix. ADM – System Administration x. IFS – System Interface Management xi. TRA – System Training

b. RBMS Field Devices (FD-YYY) i. GEN – General Field Device requirements ii. CTV – Close Circuit Television System iii. VMS – Approach Lane Management Variable Message Sign (VMS) System iv. POG – Port of Entry Gate/Lane Status System (POE GLS System) v. PVT – Point Vehicle Time Detection System vi. VDS – Vehicle Detection Station System vii. VTM - Variable Toll Message Sign System

c. Infrastructure (IS-YYY) i. COM – Communications System

d. System Quality (SQ-YYY) i. EXT – External ii. INT – Internal


12

3. Unique List Number, which encodes the parent-child relationship between a requirement and its neighbors (e.g., “01” parent requirement with “01.1”, “01.2”, and etc. child requirements).

Note that for configuration management purposes each requirement has a unique alias identifier (not shown) that is invariant with the location of the requirement in the requirement list schema.

1.7 Mission Functions

1.7.1 Border Traffic Monitoring

1.7.1.1 Overview

Traffic management personnel need the RBMS to provide a timely and faithful presentation of road and traffic status in the Otay Mesa East (OME) Port-of-Entry (POE) region in order to meet their Traffic Management and Incident Management responsibilities. Monitoring and awareness enables better context-driven decision making, facilitating the selection of appropriate strategies to manage traffic flow and respond to incidents.

Figure 6 illustrates the zones in which traffic is monitored and managed by the RBMS User. Other than certain nationally secured inspection areas (California Border Patrol and Aduanas), traffic monitoring capability is required in all zones by Users.

Figure 6. RBMS Border Traffic Management Zones Where RBMS Is Required

Traffic monitoring is operationally required; thus a requisite of RBMS to provide in traffic monitoring capabilities in all zones other than secure areas (those shaded gray). In-the-round traffic movement and

Regional Border Traffic Management Zones (Passenger Vehicle)

Monitored by RBMS-CS

Neither monitored nor managed by RBMS-CS

Southbound

Northbound

CBP Primary & Secondary

Inspection Zones


Pre

To

ll

Zo

ne

Departure

ZonePre-Approach Zone Approach Zone

Lane

Allocations

Zone

USA

POE

Lanes

Toll

Zone

Departure ZoneMexico

POE

Lanes

Toll

Zone

Lane

Allocations

Zone

Pre-Approach

Zone

Ap

pro

ach

Zo

neAduanas

Inspection ZoneOptional SB Inspection Zone


13

status comprehension in these zones is formed through a User’s cognition processes, where they fuse aural (e.g., verbal) and visual information in the operating environment. This will be achieved through a combination of RBMS-related functions and coordination with other agents/agencies via supplementary systems (e.g.: co-located coordination in the management center, telephone communication). Accurate fusion relies on a User’s own ability to comprehend as well as a well formed RBMS User Interface (UI) design.

Figure 7: Border Traffic Monitoring with RBMS Overview

Traffic Management Status

Incident & Emergency Status

Traffic Status

Systems Status

Road Works Status

Services & Facilities Status

Presented Information

Operations PersonnelOther Stakeholders

conducts

Status Within RBMS

triggers

Border Traffic Monitoring with RBMS

Users may receive information about the status of roadway traffic via two channels: the RBMS Central System’s UIs, and person-to-person communication outside RBMS.

For the case within RBMS, the System captures traffic data via Interfacing Systems and User Interfaces. That information is then calculated on to provide performance metrics (e.g.: Border Wait Times), and evaluated for conditions where an Alert may be provided.

The System (utilizing a variety of UIs and information channels) provide the User with the information they need per business rules tailored to the role and responsibility of the User. Users may also query and retrieve information that is not immediately presented to them (if permissions allow), and also add or edit that information if necessary (if say they received it via person-to-person communication) to maintain the quality of the record of field conditions in the System.

Manage Information

Query & Retrieve Information

Capture, Modify Information

of type

Calculated by RBMS External SystemEvaluated by RBMS RBMS Field Device

User

Sources of Operational Data

Operational status data generally resides in the Live Traffic Store until it is archived in the Historic Data Store.

System status related data generally resides in the Live System Store until it is archived in the Historic Data Store.

Topology of roadways, infrastructure, etc., generally resides in the Static Border Store.

Static configuration of interfaces to other systems, and RBMS’ own systems and components resides in the Static System Store.

Field Configuration

Update User Interfaces & Interfacing Systems

triggers

Bo

rder

Tra

ffic

Mo

nit

ori

ng

Man

ag

em

en

t,P

erf

orm

an

ce,

Ev

alu

ati

on

Field Imagery

Create/Remove Alerts

Recalculate Performance Values

Update Reports


14

Figure 8: Border traffic monitoring architecture

Live Operation Store

Static Operation Store


Static System Store

Live System Store

Historic Data Store

Capture Verify

Validated Border Operations DataRequest Responses

System StatusControl Requests - Approval/Denials

Create

MOP Business RulesAlert Business Rules

Border Operations Data (Live)Enhanced CCTV Imagery (Live)

Provide

Data Publication Rules

Border Operations Data (Historic)CCTV Imagery Requests (Historic)

Border Operations DataBorder Operations Data Requests (Live, Static & Historic, Suspend)CCTV Imagery Requests (Live & Historic)CCTV Controls Requests

Border Operations Data• Requested Border Operations Data (Live & Historic)• Required Border Operations Data• Suspended Border Operations Data• Border Operations Data Input Denials• Border Operations Data Request DenialsCCTV Imagery• Requested CCTV Imagery (Live & Historic)• Required CCTV Imagery• Suspended CCTV Imagery• CCTV Imagery DenialsCCTV Controls• CCTV Controls Available• CCTV Controls Approval Feedback• CCTV Control Denials

Border Operations DataCCTV ImageryCCTV Control Feedback

RBMS Field Devices

ExternalInterfacing Systems

Border Operations Data Requests (Live, Static & Historic)Border Operations Data InputCCTV Imagery Requests (Live & Historic)

RBMS User

RBMS Field Devices


RBMS User

CCTV Imagery (Historic)Border Operations Data (Historic)

Border Operations Data Requests (Static)

CCTV Imagery (Live)Border Operations Data

Border Operations Data• Requested Border Operations Data (Live)• Required Border Operations Data• Suspended Border Operations Data• Border Operations Data Input Denials• Border Operations Data Request DenialsCCTV Imagery• Requested CCTV Imagery (Live)• CCTV Imagery Requests• Suspended CCTV Imagery• Required CCTV Imagery• CCTV Imagery Denials

Border Operations DataBorder Operations Data Requests (Live, Suspend)CCTV ImageryCCTV Imagery Requests (Live)

CCTV Control Instructions

See section 1.8.2 User Interface Management for User Interface

description and requirements.

See section 1.8.3 System Interface Management for requirements for

system interface descriptions and requirements.

CCTV Control RequestsCCTV Control Feedback

Validated Border Operations DataBorder Operations Data Input DenialsCCTV Imagery

Border Operations DataBorder Operations Data Requests

Border Operations Data (Static)

Border Operations Data Requests (Historic)CCTV Imagery Requests (Historic)

ArchiveArchival Business Rules

Border Operations DataBorder Operations Data RequestsBorder Operations Data DenialsCCTV ImageryCCTV Imagery RequestsCCTV Imagery Denials

Archive Data

Data Access RulesCCTV Control Rules

CCTV Control RequestsCCTV Control Feedback

Border Operations Data (Historic)Enhanced CCTV Imagery (Historic)


15

1.7.1.2 Information Necessary for Traffic Monitoring

The RBMS will notionally manage its data in Data Stores and provide the necessary Data Items to Users via User Interfaces. Figure 9 illustrates those Data Stores considered most-relevant in the provisioning of operational data that would support the Traffic Management and Incident Management operations.

Figure 9. The Data Stores Directly Relevant to Traffic Monitoring

This border traffic monitoring section provides the User and stakeholders’ current understanding of their information requirements to achieve those missions of traffic and incident management. However, all Data Items can only be known based on current experience, until final design, implementation, and prototyping are completed, when Users and stakeholders’ will have direct experience with the new System. This specification provides the independently-verifiable Data Items currently understood necessary based on analysis of intended operational concept for RBMS, other border crossing operations, and experience with other advanced traffic management system (ATMS) deployments. As part of the System design process, it is crucial to identify (via Human Factors [HF] Task Analysis) which Data Items form a complete and necessary set to accomplish those mission goals of border traffic monitoring (illustrated in Figure 9). This analysis will inform the design of User Interfaces (UI) with capability tailored to meet the Users operational need.

Data items for monitoring may be classified in any number of HF schema. Figure 10 provides a representative example of one (non-binding) schema including several Data Items considered essential to the fulfillment of situation awareness (i.e.: border traffic monitoring). The following four groupings have been provided in this example with the view to illustrate how the criticality and application of Data Items can serve a UI design:

1. Situational – Data Items crucial to situation identification and assessment processes; may be necessary on a continuous basis

2. Instructional – Data Items that communicate what actions are being taken and are needed to be taken by others to manage strategy

3. Conformational – Data Items that are crucial to the User’s situation validation (feedback) processes

System Config. Store


System Alerts StoreStatic Border Store

Live Traffic Store Live System Store Historic Data Store

Data Items

Border Traffic Monitoring- providing operational data to Users


16

4. Contextual – Data Items that provide the contextual information Users need to make in-the-round assessment and decisions making

Figure 10. Example Data Items Relevant to Border Traffic Monitoring Classified under the Human Factors Terms

These Data Items are directly relevant to border traffic monitoring and would be contained in one of the Data Stores illustrated in Figure 10 as classified under the HF terms explained above.

The “situational” Data Items identified in Figure 10 above can be described as follows:

• Traffic Movement data includes status information such as lane congestion, directionality, and designation. Safe and reliable management and incident resolution relies on decision making based on data provided by the System across a number of types including directionality, speed, vehicle type designation, wait-times, traffic volume flow, lane designation (i.e.: dynamic, static).

In addition, certain traffic status (i.e.: the traffic condition) and lane status (i.e.: the lane condition) information may be processed by the System internally. Information quality and any Alert-able conditions must be processed internally. Requirements governing the terms for evaluation and calculation of those values are provided in subsequent sections (i.e.: Section 1.7.5 Alert Management and Section 1.7.4 Border Traffic Analysis).

• Performance Values data includes key indicators, such as crossing time, necessary in operational decision making. To assist in proper resource allocations and adjustments, Users need operational key performance indicators that provide information on such quantities as:

o Crossing volumes by vehicle type

o Crossing demands by vehicle type

o Border Crossing Wait Times, including real time comparisons of wait times at San Ysidro, Otay Mesa West (OMW), and Otay Mesa East (OME)

o Areas of Delay

Instructional Confirmational ContextualSituational

Traffic Movement Roadway ImageryTraffic Management

Details

Incident Management

DetailsPerformance Values

Alerts

System Status

Infrastructure Status

Facility Status

Road Maintenance

Details

Personnel Status

RBMS - Central System Data Store

Public Facing

Historical Data


17

• System Status data includes the status of Field Devices and interfacing source systems, assuring Users’ their data is accurate and timely.

• Alerts data includes operational and systemic Alerts so that Users may prioritize their management of traffic operations when necessary. Alerts and Alert details are a crucial component of the decision-making processes for traffic management personnel. The RBMS User needs to be provided with operational Alerts and operational Alert details, in order to focus their attention on specific operational issues and decision areas. Similarly, those operational personnel need certain System Alerts and System Alert details that advise them on the integrity of data in the System.

The “instructional” Data Items identified in Figure 10 above can be described as follows:

• Traffic Management Details data includes the RBMS’s and interfacing authorities’ strategies in place for managing roadway traffic. Authorities other than those RBMS-centric in operation at the border (i.e.: California Highway Patrol, CBP, Aduanas, Tolling Authority, Caltrans) have control over certain portions of traffic flow within the border region. RBMS will monitor and control the approach/departure territories adjacent to these portions (e.g.: CBP/Aduanas inspection zone, toll lanes). To successfully manage vehicle traffic up to those operational interfaces requires RBMS Users be properly appraised of the strategy those authorities have put in place and are following.

• Incident Management Details data includes the RBMS’ and interfacing authorities’ strategies in place for managing roadway incidents. Effective strategic and tactical incident resolution relies on Users having and sharing visibility on the field conditions and associated details of an incident, such as what is involved, where the incident is, what type of incident it is, and the strategy being employed to resolve the issue, if applicable (e.g.: “vehicle tow called-to-scene”). Information that is of sufficient criticality, such as a life-critical collision, may be communicated through several channels simultaneously, and format of dissemination requirements are addressed in Section 1.8.2: User Interface Management. This section provides requirements of System functionality specifically for the provision of Incident information to Users.

The “confirmational” Data Items identified in Figure 10 above can be described as follows:

• Roadway Imagery data includes static and moving imagery captured via RBMS and networked regional CCTV sources. Video imagery provides eyes for the User on the roadway status, establishing situation awareness among multiple lines simultaneously and in real-time. Users need to be able to interrogate historic roadway imagery as well as select and control camera systems in real-time to enable them to identify, assess, and resolve a situation as it evolves.

• Public-Facing data includes information provided to Users as assurance that their operational world-views are consistent. RBMS Users need to confirm as feedback the travel information the traveling public is seeing in their territory. For example, the User viewing roadside VMS messages is critical because implementing management strategies in conflict with these messages puts the effectiveness and safety of the managed territory in question. Current toll rates are also relevant to Users as they may need to adjust their management strategies based on variable toll pricing.

• Historic Data includes historic operational and System data provided to the User.


18

The “contextual” Data Items identified in Figure 10 above can be described as follows:

• Road Maintenance Information data including active Work Zones as well as details of future planned roadwork. Scheduled and unplanned roadwork will be a recurring activity in the region managed by border traffic operations personnel. Users and their supervisors need to understand and anticipate the impact that roadwork is having, and will have, on Traffic and Incident Management so that they may revise their traffic management strategies accordingly. Information about the roadwork associated with the current traffic status is also crucial for a safely integrated regional system.

• Border Infrastructure Status data so that Users understand the status of the Border Infrastructure. In order to understand the context of the managed border region, Users need to know the status of Border Infrastructure and any constituent system devices (e.g.: CCTV camera locations), as well as service schedules (e.g.: tolling service, CBP services hours of operation, early closing, etc.). The RBMS User needs to understand the status of these components in order to properly manage traffic and incidents as they occur in the management zone.

• Facility Status data so that Users understand the status of facilities and their services (e.g.: toll plaza open/closed lanes)

• Vehicle Information includes individual vehicle data such as type, speed, and uniquely identifiable information (e.g.: tag number, license plate). In order to carry out routine and Incident Management tasks, Users may need to access or update details about specific vehicles, or groups of vehicles, such as the type (e.g.: passenger, work, cargo), or its status (e.g.: disabled). The location of specific vehicles may also be queried and provided to RBMS Users, if for certain reasons, such as security, it is required to identify the current, or last-known position of a specific vehicle.

1.7.1.3 Border Traffic Monitoring Functionality

To support the information architecture necessary for effective Border Crossing monitoring by Users and External Interfacing Systems, several System functions and elements must be provided, combining in some circumstances capability from across the System together, most crucially in the User Interface design (see Section 1.8.2: User Interface Management).

Three major functional headings are adopted in the requirements to innumerate the situation awareness relevant Data Items and composite functionality. Certain other functions within RBMS contribute to Border Crossing monitoring (and reference to those sections is made where appropriate):

1. Present, Represent, and Configure Data Items include requirements that innumerate the situation awareness-relevant Data Items (e.g.: Figure 9) that need to be both published (i.e.: disseminated) to Users and External Interfacing Systems and represented (i.e.: format, style, medium). Because the information needs of Users will adapt over time, this presentation also needs to be configurable; therefore, the System must provide presentation functionality.

2. Access Roadway Imagery addresses the Users’ need for the ability to access to certain information channels, including Dashboards, CCTV Controls, etc., to enhance their Border Monitoring capability; therefore, the System must provide access functionality.


19

3. Update Situation Awareness addresses the Users’ need to modify or add certain data as necessary to document, and thereby enhance situation awareness; therefore, the System must provide data capture functionality.

Figure 11. Functional architecture within the Border Traffic Monitoring function specifying sources of the data to be provided.

Access Roadway

Imagery

Update Situation

Awareness

via User Interface

via Interfacing System

via System Calculation

Border Traffic Monitoring

via System Evaluation

Present Data Items Represent Data ItemsConfigure Presentation

and Representation

Present Imagery

Represent Imagery

Control Imagery

Record Imagery


20

1.7.1.4 Border Traffic Monitoring Requirements

UNIQUE ID REQUIREMENT TEXT REQUIREMENT TYPE

VERIFICATION

NEED TRACE

CS-TMO-01 The System shall accept Border Operations Data for currently occurring activity from a User. Input

Demonstration

N01

CS-TMO-01.1 The System shall accept Incident Details for the OME Crossing from a User. Input

Demonstration

N02

CS-TMO-01.1.1 The System shall enable a User to complete an Incident Report, Output

Demonstration

N02

CS-TMO-01.1.2 The System shall provide a User the option to preconfigure Incident Details, selectable by the User.

Output

Demonstration

N02

CS-TMO-01.2 The System shall accept Road Work Details for the OME Crossing from a User. Input

Demonstration

N03

CS-TMO-01.2.1 The System shall provide a User with a Road Work Report template with pre-configured Road Work Details selectable by the User.

Output

Demonstration

N03

CS-TMO-01.3 The System shall manage failures of automatic Border Operations Data receipt (via RBMS Field Devices or External Interfacing Systems) by providing a User with manual data entry capabilities, including the following:

a. Traffic Movement data

i. Border Wait Time at OME Crossing

ii. Vehicle occupancy at OME Crossing

b. Border Service Status

i. Border Crossing status (open or closed; by vehicle type)

Output

Demonstration

N05


21


VERIFICATION

NEED TRACE

ii. Tolling Details, including:

1. Toll rate by vehicle type

2. Toll lane closures (open/closed)

3. Toll lane vehicle type

c. Field Device details

i. RBMS Field Device status (online/off-line)

CS-TMO-01.3.1 The System shall verify enactment of internal System computations by providing a User with manual data entry capabilities, including the following:

a. Traffic Movement data

i. Border Wait Time at OME Crossing

ii. Vehicle occupancy at OME Crossing

b. Border Service Status

i. Border Crossing status (open or closed; by vehicle type)

ii. Tolling details, including:

1. Toll rate by vehicle type

2. Toll lane closures (open/closed)

3. Toll lane vehicle type

c. Field Device details

i. RBMS Field Device status (online/off-line)

Output

Demonstration

N05

CS-TMO-01.4 The System shall accept Border Environment details for the OME Crossing from a User. Input

Demonstration

N04

CS-TMO-01.4.1 The System shall provide a User with a Border Environment report Dialogue with pre-configured Border Environment details selectable by the User, including the following:

a. Weather conditions, e.g.: rain, high-wind, heavy fog;

Output

Demonstration

N04


22


VERIFICATION

NEED TRACE

b. Localized Environmental condition, e.g.: roadway flooding, grease spill on roadway;

c. Start time of condition;

d. End time of condition;

e. Responders;

f. Reporting source; and

g. Free-text notes for comments about the condition.

CS-TMO-02 The System shall validate the data it receives from a User. Process

Demonstration

N01

CS-TMO-02.1 The System shall verify the data meets the System’s internal data quality standards (configured in the design phase) via configurable input masks and verifications of field character length and character type.

Process

Demonstration

N01

CS-TMO-02.2 The System shall verify the data does not conflict with other data within the System. Process

Demonstration

N01

CS-TMO-02.3 If the data entered by a User cannot be validated, then the System shall provide a User with an Alert requesting the User re-enter a valid data input within System Parameters.

Output

Demonstration

N01

CS-TMO-02.4 If the data entered by a User is incomplete, then the System shall provide a User with a preventative Alert requesting the User complete entry of the data.

Output

Demonstration

N01

CS-TMO-03 The System shall determine any values contingent on the User-entered values. Process

Demonstration

N01

CS-TMO-04 When a User provides the System with Border Operations Data, the System shall update Border Operations Data in the Live Traffic Store.

Process

Demonstration

N01

CS-TMO-05 The System shall provide Border Operations Data on User Interfaces within five seconds.

Constraint

Demonstration

N01


23


VERIFICATION

NEED TRACE

CS-TMO-05.1 The System shall provide current (i.e.: live, real-time) Border Operations Data on User Interfaces for traffic regions including the following:

a. OME Crossing;

b. OMW Crossing;

c. San Ysidro Crossing;

d. Greater San Diego Traffic Zone; and

e. Greater Tijuana Traffic Zone.

Output

Demonstration

N01

CS-TMO-05.2 The System shall provide historic (i.e.: for the past week, day, hour, minute) Border Operations Data on User Interfaces for traffic regions including the following:

a. OME Crossing;

b. OMW Crossing;

c. San Ysidro Crossing;

d. Greater San Diego Traffic Zone; and

e. Greater Tijuana Traffic Zone.

Output

Demonstration

N01

CS-TMO-05.2.1 The System shall provide Historic Trend Data with Current Data so that a User may understand the evolution of a condition up to the current time.

Output

Demonstration

N01

CS-TMO-05.2.2 The System shall enable a User, on a User Interface, to retrieve historic Border Operations Data of a certain type for a range of time in the past, including the following:

a. The past month;

b. The past week;

c. The past day;

d. The past hour; and

e. The past minute.

Output

Demonstration

N01


24


VERIFICATION

NEED TRACE

CS-TMO-05.2.3 When the System is providing Border Operations Data on User Interfaces, the System shall display a schematic representation of the roadway and traffic management infrastructure from the Static Border Store with the Current Data, Historic Data, and Projected Data.

Output

Demonstration

N01

CS-TMO-05.3 The System shall provide projected Border Operations Data on User Interfaces for the OME Crossing.

Output

Demonstration

N05

CS-TMO-05.3.1 The System shall provide projected trend data within two minutes to compare with key performance indicators (KPI’s) so that a User may understand the evolution of a condition beyond the current time.

Constraint

Demonstration

N05

CS-TMO-05.3.2 The System shall provide projected Border Operations Data of certain types (e.g.: Border Wait Time) on time-scales of the following:

a. The next quarter-hour;

b. The next half-hour; and

c. The next hour.

Output

Demonstration

N05

CS-TMO-05.4 The System shall provide Traffic Movement details on User Interfaces, including the following:

a. Border Wait Times (bi-directionally) across the region;

b. Vehicle Speeds across the region;

c. Traffic Volumes across the region; and

d. Vehicle Occupancy across the region.

Output

Demonstration

N05

CS-TMO-05.4.1 The System shall alert Users when Border Wait Time exceeds threshold value at OME Crossing. Output

Demonstration

N05

CS-TMO-05.4.2 The System shall alert Users when Traffic Volume exceed threshold value for a roadway segment at OME Crossing.

Output

Demonstration

N05

CS-TMO-05.4.3 The System shall alert Users when vehicle occupancy exceed threshold time at a location at Border Crossing.

Output

Demonstration

N05


25


VERIFICATION

NEED TRACE

CS-TMO-05.5 The System shall provide Traffic Management Status details on User Interfaces, including the following:

a. Primary Inspection Lane Types displayed on Approach Lane Management VMS;

b. Lane Closures across the region;

c. Lane Vehicle Type configuration displayed on Approach Lane Management VMS;

d. Lane Direction configuration displayed on Approach Lane Management VMS; and

e. Lane Speed Advisories across the region (static and dynamic).

Output

Demonstration

N01

CS-TMO-05.5.1 The System shall alert Users when an incorrect vehicle type is detected in a lane at the OME Crossing within five seconds.

Note: Some vehicle types are allowed in multiple Traffic Lanes.

Constraint

Demonstration

N01

CS-TMO-05.5.2 The System shall alert Users when a vehicle is detected traveling in the wrong direction at the Border Crossing.

Output

Demonstration

N01

CS-TMO-05.5.3 The System shall alert Users when a vehicle is detected traveling in excess of speed advisory at the Border Crossing

Output

Demonstration

N01

CS-TMO-05.6 The System shall provide operational management details on User Interfaces, including the following:

a. Operational Mode of System in effect (i.e.: automated, manual, partial auto);

b. Traffic Management Plan in effect (e.g.: Sunday plan, morning rush-hour); and

c. Staff Details.

Output

Demonstration

N01

CS-TMO-05.6.1 Staff Details provided on User Interfaces shall include the following:

a. Who is logged into the System;

b. The session start time;

c. The session duration; and

d. Their physical location.

Output

Demonstration

N01


26


VERIFICATION

NEED TRACE

CS-TMO-05.7 The System shall provide Road Work Details on User Interfaces.

Output

Demonstration

N03

CS-TMO-05.7.1 The System shall alert Users when a vehicle is detected traveling within an OME Crossing Road Work Zone.

Output

Demonstration

N03

CS-TMO-05.7.2 The System shall alert Users when a vehicle is detected traveling in excess of advisory speed at an OME Crossing Road Work Zone.

Output

Demonstration

N03

CS-TMO-05.8 The System shall display Incident Details from an OME Crossing Incident Zone on User Interfaces.

Output

Demonstration

N02

CS-TMO-05.9 The System shall provide Border Service Status details on User Interfaces, including the following:

a. Open/closed status of San Ysidro, OMW Passenger and Cargo Lanes, and OME Passenger and Cargo Crossings; and

b. Tolling Details, including:

i. Toll rate by vehicle type;

ii. Toll lane status (open/closed); and

iii. Toll Lane Vehicle Type.

Output

Demonstration

N04

CS-TMO-05.10 The System shall provide Border Environment details on User Interfaces, including the following:

a. Weather conditions, e.g.: rain, high-wind;

b. Localized environmental condition, e.g.: roadway flooding, grease spill on roadway;

c. Start time of condition;

d. End time of condition;

e. Responders;

Output

Demonstration

N04


27


VERIFICATION

NEED TRACE

f. Reporting source; and

g. Free-text notes for comments about the condition.

CS-TMO-05.11 The System shall provide RBMS Field Device details on User Interfaces, including the following:

a. RBMS Field Device status (online/off-line);

b. Caltrans TMC Vehicle Detection Station (VDS) CMS status (online/off-line, data CMS messages, VDS rates, etc.);

c. SCT TMC VDS CMS status (online/off-line);

d. Start time of condition;

e. End time of condition; and

f. Free-text notes for comments about the condition.

Output

Demonstration

N04

CS-TMO-05.12 The System shall provide Public Advisory details that have been displayed on OME Crossing VMS to User Interfaces, including the following:

a. AMBER Alert;

b. Silver Alert;

c. Special Event Details; and

d. Weather Advisory.

Output

Demonstration

N04

CS-TMO-05.13 The System shall alert Users when a vehicle is detected traveling in a closed lane at the Border Crossing.

Output

Demonstration

N01

CS-TMO-05.14 The System shall Alert Users when a vehicle is detected travelling within an OME Crossing Incident Zone.

Output

Demonstration

N02

CS-TMO-06 The System shall accept Border Operations Data for currently occurring activity from an External Interfacing System.

Input

Demonstration

N01

CS-TMO-06.1 The System shall accept Incident Details for the OME Crossing from External Interfacing Systems.

Input N01


28


VERIFICATION

NEED TRACE

Demonstration

CS-TMO-06.1.1 The System shall enable an External Interfacing System to complete an Incident Report. Output

Demonstration

N02

CS-TMO-06.2 The System shall accept Road Work Details for the OME Crossing from an External Interfacing System.

Input

Demonstration

N03

CS-TMO-06.3 The System shall accept Border Environment details for the OME Crossing from an External Interfacing System.

Input

Demonstration

N04

CS-TMO-07 The System shall validate the data it receives from an External Interfacing System. Process

Demonstration

N01

CS-TMO-07.1 The System shall verify the data meets the System’s internal data quality standards (configured in the design phase) via configurable input masks and verifications of field character length and character type.

Process

Demonstration

N01

CS-TMO-07.2 The System shall verify the data does not conflict with other data within the System. Process

Demonstration

N01

CS-TMO-07.3 If the data entered by an External Interfacing System cannot be validated, then the System shall provide the User with an Alert requesting the User attempt to amend the data input to conform to System parameters.

Output

Demonstration

N01

CS-TMO-07.4 If the data entered by an External Interfacing System is incomplete, then the System shall provide a User with a preventative Alert requesting the User complete entry of the data.

Output

Demonstration

N01

CS-TMO-08 The System shall determine any values contingent on the External Interfacing System-entered values.

Process

Demonstration

N01

CS-TMO-09 When an External Interfacing System provides the System with Border Operations Data, the System shall update Border Operations Data in the Live Traffic Store.

Process

Demonstration

N01


29


30

1.7.2 Traffic Video Surveillance

The requirements in this section describe the following:

1. Receipt of traffic images (video and static images from camera devices) for the OME Crossing and for other crossings and the region;

2. Presentation of live, as well as historic, images to Users;

3. Storing/retention of only certain live video on User demand for the purpose of historical investigation (i.e.: imagery is generally not retained);

4. Provisioning of certain live images to the Data Hub;

5. Control of CCTV cameras at the OME Crossing that are configured to be controlled by RBMS;

6. Processing of static and video images to improve their quality;

7. Automated detection of and RBMS actions in response to Incidents;

8. Appending certain static and video images to reports or sharing internally with RBMS Users.


31

1.7.2.1 Traffic Video Surveillance Requirements


VERIFICATION

NEED TRACE

CS-TVS-01 The System shall receive Traffic Images from External Interfacing Systems. Input

Demonstration

N06

CS-TVS-01.1 The System shall receive Traffic Images from the RBMS CCTV System [IF05]. Input

Demonstration

N06

CS-TVS-01.1.1 The System shall receive Traffic Images from the RBMS CCTV System of type and location, including the following:

a. Video images from:

i. Pre-Approach Zone (northbound and southbound);

ii. Approach Zone (northbound and southbound);

iii. Lane Allocations Zone (northbound and southbound);

iv. Pre-Toll Zone (northbound only); and

v. Departure Zone (northbound and southbound).

Input

Demonstration

N06

CS-TVS-01.1.1.1 The System shall receive video images at sub-second rates at a rate of display so that the image transition is smooth and imperceptible to a User.

Performance

Demonstration

N06

CS-TVS-01.1.2 The System shall receive Incident Alerts and Incident details from the RBMS CCTV System that are correlated to imagery being provide to the System.

Input

Demonstration

N08

CS-TVS-01.2 The System shall receive Traffic Images from External Interfacing Systems through the Data Hub System [IF06] within 30 seconds.

Constraint

Demonstration

N07

CS-TVS-01.2.1 The System shall receive Traffic Images from the Data Hub System of type and location including the following:

a. Streaming video images from:

Input

Demonstration

N06


32


VERIFICATION

NEED TRACE

i. San Ysidro Crossing;

ii. OMW Crossing;

iii. Greater San Diego Traffic Zone; and

iv. Greater Tijuana Traffic Zone.

b. Static images from:

i. San Ysidro Crossing;

ii. OMW Crossing;

iii. Greater San Diego Traffic Zone; and

iv. Greater Tijuana Traffic Zone.

CS-TVS-01.2.1.1 The System shall receive video images at sub-second rates at a display rate so that the image transition is smooth and imperceptible to a User

Performance

Demonstration

N06

CS-TVS-01.3 The System shall receive Traffic Images from External Interfacing Systems in real-time, with a degree of latency at the sub-second time scale since the image was recorded by the camera sensor.

Constraint

Demonstration

N06

CS-TVS-02 The System shall provide live Traffic Images to a User Interface. Output

Demonstration

N06

CS-TVS-02.1 The System shall provide live Traffic Images to a desktop computer User Interface. Physical

Demonstration

N06

CS-TVS-02.2 The System shall provide live Traffic Images to a video wall User Interface. Physical

Demonstration

N06

CS-TVS-02.3 The System shall provide RBMS CCTV Camera System Traffic Images to User Interfaces with a degree of latency at the sub-second time scale since the image was recorded by the camera sensor.

Constraint

Demonstration

N06


33


VERIFICATION

NEED TRACE

CS-TVS-03 The System shall provide Traffic Images of the OME Crossing native to the RBMS to the Data Hub System [IF-06], including the following:

a. Pre-Approach Zone (northbound and southbound);

b. Approach Zone (northbound and southbound);

c. Lane Allocations Zone (northbound and southbound);

d. Pre-Toll Zone (northbound only); and

e. Departure Zone (northbound and southbound).

Output

Demonstration

N07

CS-TVS-03.1 The System shall provide Traffic Images of the OME Crossing to the Data Hub System within 5 seconds.

Constraint

Demonstration

N07

CS-TVS-04 The System shall record Traffic Images in the Historic Traffic Store for near-term and long-term retrieval for a period not less than 7 days.

Process

Demonstration

N06

CS-TVS-04.1 The System shall enable a User to start/stop recording of specific Traffic Images (static and video) into the Historic Traffic Store.

Process

Demonstration

N06

CS-TVS-04.1.1 The System shall enable a User to archive the Traffic Images so that they can be queried for retrieval later.

Process

Demonstration

N06

CS-TVS-05 The System shall enable a User to retrieve live and historic Traffic Images on their User Interface. Input

Demonstration

N06

CS-TVS-05.1 The System shall display on the User Interface which cameras are available to be viewed. Output

Demonstration

N06

CS-TVS-05.2 The System shall enable a User to request Traffic Images from an individual camera. Input

Demonstration

N06

CS-TVS-05.3 The System shall enable a User to request multiple Traffic Images simultaneously from multiple cameras in a Traffic Zone.

Input

Demonstration

N06


34


VERIFICATION

NEED TRACE

CS-TVS-05.4 The System shall enable a User to retrieve historic Traffic Images. Input

Demonstration

N06

CS-TVS-05.5 The System shall provide archival retrieval methods to Users so that they may identify and retrieve Traffic Images, including the following:

a. by time (including calendar day, time of day);

b. by location (Traffic Zone and direction of travel); and

c. by CCTV camera (location and Camera Type).

Process

Demonstration

N06

CS-TVS-05.6 When Traffic Imagery has been selected in the Historic Traffic Store, the System shall display the imagery with playback features including the following:

a. Imagery fast-forward control;

b. Imagery rewind control;

c. Imagery slow-motion control (forward and backward in time);

d. Imagery frame stepping control (forward and backward in time); and

e. Imagery progress bar navigation control.

Output

Demonstration

N06

CS-TVS-05.7 The System shall accept playback control instructions from a User. Input

Demonstration

N07

CS-TVS-06 The System shall enable a User to control RBMS OME Crossing CCTV native cameras on an authorized User Interface.

Process

Demonstration

N07

CS-TVS-06.1 The System shall display on the User Interface which native cameras are available to be controlled. Output

Demonstration

N07

CS-TVS-06.2 The System shall provide options to control native control-enabled RBMS PTZ enabled CCTV Cameras on a User Interface, including:

a. Pan camera (360 degrees);

b. Tilt camera;

Output

Demonstration

N07


35


VERIFICATION

NEED TRACE

c. Zoom camera;

d. Wiper Control;

e. Adjust iris diameter; and

f. Return to default/pre-set position based on configurable or pre-set time frame. Default time frame is 10 minutes (auto-return).

CS-TVS-06.3 The System shall accept CCTV control instructions from a User. Input

Demonstration

N07

CS-TVS-06.4 The System shall provide the RBMS CCTV Camera System with CCTV control instructions. Output

Demonstration

N07

CS-TVS-06.4.1 The System shall provide CCTV control instructions with a degree of latency at the sub-second time scale since the instruction was provided by the User.

Constraint

Demonstration

N07

CS-TVS-06.5 The System shall provide a User with CCTV control feedback indicating the position and location of the camera, and adjustment acceptance/denial messages.

Output

Demonstration

N07

CS-TVS-06.5.1 The System shall receive CCTV control feedback from Users in real-time, with a degree of latency at the sub-second time scale since the CCTV control instruction was provided by the User.

Constraint

Demonstration

N07

CS-TVS-06 The System shall process Traffic Images to improve their presentation quality on a User Interface. Process

Demonstration

N06

CS-TVS-06.1 The System shall provide a User with the capability to adjust properties of how the Traffic Image is represented on their display, including the following:

a. Size of displayed image on User Interface;

b. Orientation;

c. Color attributes, including sepia, grayscale options; and

d. Sharpen/soften quality of image.

Process

Demonstration

N06


36


VERIFICATION

NEED TRACE

CS-TVS-06.2 The System shall determine the properties of a Traffic Image automatically to compensate for criteria including the following:

a. Low levels of background illumination (e.g.: night-time, adverse weather);

b. High levels of background illumination (e.g.: direct sunlight); and

c. Image vibration, including heat shimmer.

Process

Demonstration

N06

CS-TVS-07 The System shall process Traffic Images to detect Traffic Incidents at the OME Crossing. Process

Demonstration

N08

CS-TVS-07.1 Traffic Incidents shall include the following:

a. Traffic congestion indicating unusual conditions, indicating potential challenges reaching Border Wait Time targets;

b. Disabled vehicles; and

c. Other non-vehicle items on the roadway, e.g.: debris, people walking/standing, and animals walking/standing.

Process

Demonstration

N08

CS-TVS-07.2 When the System detects an Incident from a Traffic Image, the System shall provide a User with an Alert.

Output

Demonstration

N08

CS-TVS-07.2.1 When the System detects an Incident from a Traffic Image, the System shall generate an Incident Report for validation of by the User.

Output

Demonstration

N07

CS-TVS-07.3 When an Incident is reported or detected in the Live Traffic Store, if a CCTV Camera is in the vicinity of the Incident, the System shall automatically present the Traffic Images at that location on a User Interface.

Output

Demonstration

N08

CS-TVS-08 The System shall enable a User to export Traffic Images. Process

Demonstration

N07

CS-TVS-08.1 The System shall enable a User to append a Traffic Image to an Incident Report. Process

Demonstration

N07


37


VERIFICATION

NEED TRACE

CS-TVS-08.2 The System shall enable a User to distribute a Traffic Image in a pre-defined distribution list. Process

Demonstration

N07

CS-TVS-09 The System shall provide authorized Users with privileges to manage other Users access to Traffic Images, including:

a. Terminating presentation of Traffic Images on User Interfaces on-demand;

b. Terminating transmission of Traffic Images to External Interfacing Systems on-demand;

c. Turning off/on certain or all;

d. Resetting certain or all controllable RBMS CCTV Cameras to their default locations;

e. Restricting CCTV control privileges of Users; and

f. Restricting CCTV viewing privileges of Users.

Process

Demonstration

N07

CS-TVS-10 The System shall enable an External Interfacing System to retrieve live and historic Traffic Images on their User Interface.

Input

Demonstration

N06

CS-TVS-10.1 The System shall enable an External Interfacing System to request Traffic Images from an individual camera.

Input

Demonstration

N06

CS-TVS-10.2 The System shall enable an External Interfacing System to request multiple Traffic Images simultaneously from multiple cameras in a Traffic Zone.

Input

Demonstration

N06

CS-TVS-10.3 The System shall enable an External Interfacing System to retrieve historic Traffic Images. Input

Demonstration

N06

CS-TVS-10.4 The System shall provide archival retrieval methods to External Interfacing Systems so that they may identify and retrieve Traffic Images, including the following:

a. By Time (including calendar day, time of day);

b. By location (Traffic Zone and direction of travel); and

c. By CCTV camera (location and Camera Type).

Process

Demonstration

N06


38


39

1.7.3 Border Traffic Management

The following figures provide illustrative overviews of the border traffic management zones, processes and interfaces, and overall border traffic management architecture.

Figure 12: Traffic & Incident Management Regional Border Traffic Management Zones

Regional Border Traffic Management Zones

Monitored & managed by RBMS Central System

Monitored but not managed by RBMS-CS


Southbound

Northbound

CBP Primary & Secondary

Inspection Zones


Pre

To

ll

Zo

ne

Departure

ZonePre-Approach Zone Approach Zone

Lane

Allocations

Zone

USA

POE

Lanes

Toll

Zone

Departure ZoneMexico

POE

Lanes

Toll

Zone

Lane

Allocations

Zone

Pre-Approach

Zone

Ap

pro

ach

Zo

neAduanas

Inspection ZoneOptional SB Inspection Zone


40

Figure 13: Traffic & Incident Management in RBMS

Create/Remove Alerts

Modify Lane Status (Open/Close Lane)

Modify Lane Direction

Publish Advisories to Public

Assign Unique Primary Inspection Lane

Modify Traffic Speed Advisory

Communicate Instructions to Field Devices

Manage Primary Inspection Lane Approach

triggers

Manage Roadway Traffic Management Strategy

Set Traffic Management Mode in System

Create, Start/Stop Incident Response Plan

Create, Start/Stop/Schedule Road Work Plan

Create, Start/Stop Day-Of Strategy

Recalculate Performance Values

TMC Operations UserOR RMBS (auto-mode)

conducts

Traffic DemandChange

Primary InspectionDesignation Change

Incident OccurrenceRoad WorkScheduled

TMC-Level Issue (e.g.: staff level change)

has part

Operational Events Impacting RBMS

Within RBMS

triggersvia RBMS sensed data, UI details, Alerts, Performance Indicator value or threshold, CCTV images, or direct communication with another user or official

Ro

ad

wa

y M

an

ag

em

en

t

Update User Interfaces

Mo

nit

ori

ng

,P

erf

orm

an

ce

ev

alu

ati

on

Users may receive information about the status of roadway traffic via two channels: the RBMS Central System’s UIs, and person-to-person communication outside RBMS.

The System captures traffic data via Interfacing Systems and User Interfaces only. That information Is then processed to provide performance metrics (e.g.: Border Wait Times), Alerts, and User Interface representations of the status of traffic in the field.

Users, or the System (utilizing business rules when in automated mode) then implement roadway management plans and strategies to correct conditions and manage traffic via field device control toward safety and performance targets (e.g.: target Wait Times).

Update Reports


41

Figure 14: Traffic & Incident Management Architecture

Traffic Management Inputs• Traffic Operations Plan Input• Traffic Management Mode Input• Traffic Management Strategy Input• Incident Management Plan Input• Road Work Plan Input

Management Instructions

Capture

Verify

Create Strategies

Provide

Archival OutputsManagement InstructionsManagement AdviceManagement AlertsManagement Denials




Static System Store

Live System Store

Historic Data Store

Generate Advice

Traffic Management Advice Requests

Traffc Management AdviceBorder Operations Data

Context Help

Archival Plans

Border Operations Data

Advice Business Rules

Traffic Management Strategy InputTraffic Management Mode Input

Traffic Management Business Rules

Traffic Management Business Rules

Traffic Management InputsTraffic Management Advice Requests

Archival Requests

Traffic Management Strategy InstructionsTraffic Management Mode InstructionsTraffic Management AdviceTraffic Management AlertsTraffic Management Denials

Archive

Archival Data

Data Publication Rules RBMS User

RBMS Field Devices

Archival Business Rules

Archival OutputsManagement InstructionsManagement AdviceManagement AlertsManagement Denials

Traffic Management Advice Requests• Context Help (Knowledge)• Rules-Based Recommendations

Archival Requests• Traffic Operations Plan Search/Store• Incident Management Plan Search/Store• Road Work Plan Search/Store

RBMS User

Traffic Management Strategy InstructionsTraffic Management Mode Instructions

Traffic Management Strategy InstructionsTraffic Management Mode InstructionsTraffic Management AlertsTraffic Management Denials


42

1.7.3.1 Managing and Reporting Incidents

During the course of daily traffic operations, unexpected deviations from the operational plan will occur. Users will need to be made aware of these occurrences and have the capabilities necessary to manage a coordinated response, if necessary, and restore operations to the intended plan. The majority of a User’s interaction during with the system during their shift will involve addressing incidents, so the user experience needs to be highly intuitive and tailored to the border region.

An example of an Operational Incident would be a disabled vehicle, which may have an occupant and traveling public safety risk aspect, a compounding delay in traffic movement, and possible increase in border crossing time. Another example may be a vehicle traveling in the wrong direction, where coordination with other authorities may be needed.

In addition to Operational Incidents, Users will be made aware of, and manage, System Incidents. These are occurrences that ostensibly involve the RBMS “machine”, i.e.: the technology systems, hardware and software both in the central system and field locations, as well as interfaces to outside systems. From an operational perspective, System Incidents may pose an operational hazard, where a fault in the system reduces the operational capability of traffic management on the border region. For example, the failure of a CCTV Camera may impact the ability to observe and better manage volume flow across the border.

1.7.3.2 Incident Management and User Model

Operational Incidents and System Incidents may be managed by personnel performing more than one role. For example, at the TMC a Traffic Operator (job) may perform Operational Incident Responder (role) for an Operational Incident (e.g.: disabled vehicle) as well as First-Line Responder (role) for a Systems Incident (e.g.: CCTV failure). RBMS will need to be able to support this type of User Model flexibly. Similarly, escalation pathways of Incidents by Users (e.g.: First-Line Responder and/then System Administrator are notified of a CCTV failure) will also need to be accommodated in the final implemented solution. Chain-of-custody for Incidents will also need to be preserved; in certain cases it may be necessary to transfer responsibility (and control) of an Incident Management Strategy from one appointed User to another.

1.7.3.3 Relationship between Incident Management and Traffic Management

Incident Management is an extension (i.e.: a supplemented version) of the border traffic management capability (see Section 1.7.3 Border Traffic Management); Incidents are a special class of event but managed by many of the same tools and techniques as a Traffic Management Strategy. In the case of the Incident, the response time-frame is often acute; the duration of the Incident may be short-lived or protracted. However, certain “Incident only” capabilities will be needed above conventional Traffic Management Strategies, and this section indicates what those special capabilities are.

1.7.3.4 Automated Response by RBMS

Incident response will in general require some degree of user participation, from active management of the roadways via on-the-fly Traffic Management Strategies to simple acknowledgement of an unfolding event. Automated Incident responses based on detected values are also needed, particularly in the case of System-related faults impacting operations (e.g.: catastrophic failure of all CCTV feeds). This section of the specification provides specific functionality and performance requirements for the System to automate its response to a condition. However, these must be carefully prototyped and implemented during design;


43

RBMS should not become a “reflex hammer”, susceptible to giving automated responses when a stimulus to the System may have been unintended or unfriendly. The System will also have capabilities to disable automated responses.

1.7.3.5 Response Plans for Operational Users

When an Incident occurs a User will often need to take a corrective or responsive action that is predicated by a decision based on information garnered from the RBMS system and operational theater interactions (e.g.: speaking to colleagues in the operating center, telephone calls from partner organizations). It will be highly commonplace for Users to make those decisions based on their own fusion of information from several sources, referring back to personal knowledge and experience managing traffic behavior, as well as their learned experience of the RBMS system’s behavior.

To assist in the human decision making and action implementation processes, the RBMS will provide Users with pre-defined Operational Response Plans (and System Response Plans) that will provide guidance that is indexed to Incident scenarios, retrievable either manually by the User or provided automatically by the System in response to the recording of the Incident in the system. These will complement the inventory of Traffic Management Strategies (see Section 1.7.3 Border Traffic Management) as well as ad-hoc development capability. For example, if a User reports in RBMS that there is a disabled vehicle in a lane, based on the codified response to that scenario, RBMS may provide suggested Traffic Management Strategies, VMS Message Text, a list of VMS Locations where the message should be posted to, contact information for co-ordination partners (e.g.: EMS, towing services).

1.7.3.6 Incident Ownership and Transference

Certain Incidents will involve road and public safety concerns, potentially the security of the border region, and the integrity of the RBMS-vital systems themselves. It is therefore necessary that a chain of custody in the management of Incidents be preserved. The agency expects to define the specific management protocols during the design and implementation phase of this program. This specification will define the functionality that will be implemented and tailored to create those specific protocols. Escalation paths of Incident Management activity to others, as well as sharing or transference of responsibility (-ies) among peers and managers, also need to be provisioned by RBMS.

1.7.3.7 Incident Data Fusion by RBMS

Details of an Incident can be reported into the RBMS Central System through a number of machine and human channels. Data consistency and duplication are therefore concerns that need to be managed by the RBMS, in concert with operational processes at the TMC. These consistency issues may be managed by several means, including:

• Assigning only certain staff certain reporting and modification authorization; e.g.: only a supervisor can modify apparently conflicting information in an Incident reported by Field Devices;

• Limiting the fusion of Incident Details in the RBMS; e.g.: only certain information items are present in an Incident report; a User must mine data from several locations in the RBMS, other systems, and paper forms at the TMC for the full Incident Details; or

• A combination of both.


44

RBMS will have certain fusion capabilities that will highlight, and in certain cases resolve, detected conflicts or duplications between information from Field Devices or External Interfacing Systems, and User(s)-entered information, and information calculated or interpreted by the RBMS.


45

1.7.3.8 Border Traffic Management Requirements


VERIFICATION

NEED TRACE

CS-TMG-01 The System shall provide Traffic and Incident Management capabilities to Users at the OME Crossing.

Process

Demonstration

N09

CS-TMG-01.1 The Traffic Management capability shall include features and functions that support:

a. Managing traffic;

b. Providing guidance to Users;

c. Managing the overall operation at the traffic management center (TMC) level (e.g.: staff, territories, modes); and

d. Ensuring all actions comply with Traffic Safety Rules for the OME Crossing and its neighboring regions as well as security rules for border and law enforcement at the OME Crossing.

Process

Demonstration

N09

CS-TMG-01.1.1 The Traffic Management capability of managing traffic features and functionality shall include the following:

a. Communicating Traffic Management Strategy options to Users;

b. Receiving Traffic Management Strategy inputs from Users;

c. Computing Traffic Management Strategies automatically;

d. Establishing Traffic Management Strategies in the field;

e. Establishing Traffic Management Plans in the field;

f. Managing Incidents as a part of Broader Traffic Management;

g. Managing Road Work as a part of Broader Traffic Management; and

h. Establishing default management plans in the event of equipment failures.

Process

Demonstration

N09


46


VERIFICATION

NEED TRACE

CS-TMG-01.1.2 The Traffic Management capability of providing Guidance to Users features and functionality shall include the following:

a. Standard Operating Procedures (SOP) based Traffic Management advice when requested;

b. Automated advice based on the current situation; and

c. Projected outcomes from Traffic Management Simulations that Users control.

Process

Demonstration

N09

CS-TMG-01.1.3 The System shall provide Traffic Management capabilities with latencies at the sub-second time scale.

Constraint

Demonstration

N09

CS-TMG-01.2 The System shall transmit and automatically display VMS Messages to Approach Lane VMS in the Regional Zone in order to direct or influence driver behavior (i.e.: to “manage traffic”)

Process

Demonstration

N14

CS-TMG-01.3 The System shall determine the contents of VMS Messages, including use of Permitted Words only, through the processing of Traffic Management Strategies and Traffic Management Plans specified by Users and/or the System.

Process

Demonstration

N14

CS-TMG-01.4 The System shall include Traffic Management Strategies.

Process

Demonstration

CS-TMG-01.4.1 The System shall include Traffic Management Strategies, including the following:

a. Management of Lane Closures (i.e.: open, closed) of a Traffic Lane; and

b. Management of Primary Approach Lanes messaging, e.g.: right lane designated in advance of the POE as SENTRI, READY, FAST, etc.

Process

Demonstration

N10


a. Management of Lane Vehicle Type, i.e.: the type of vehicle (commercial/passenger) permitted in the lane; and

b. Management of Lane Direction, i.e.: normal or reverse direction of the travel lane.

Process

Demonstration

N10


47


VERIFICATION

NEED TRACE


a. Management of Lane Speed Advisories; and

b. Management of Public Advisories to the travelling public, which may or may not directly impact traffic movement, e.g.: weather Alert, AMBER Alert, special event Alert.

Process

Demonstration

N10

CS-TMG-01.5 The System shall establish different Traffic Management Strategy capabilities in specific Traffic Zones, including the following:

a. Pre-Approach Zone (northbound and southbound);

b. Approach Zone (northbound and southbound);

c. Lane Allocations Zone (northbound and southbound);

d. Pre-Toll Zone (northbound only); and

e. Departure Zone (northbound and southbound).

Note: Traffic zones may change in the design phase.

Process

Demonstration

N10

CS-TMG-01.5.1 The Pre-Approach Zone (northbound and southbound) traffic management capabilities shall include the following:

a. Managing Public Advisories

Process

Demonstration

N10

CS-TMG-01.5.2 Approach Zone (northbound and southbound) traffic management capabilities shall include the following:

a. Management of Lane Closures;

b. Management of Lane Vehicle Type;

c. Management of Lane Direction;

d. Management of Primary Approach Lanes messaging;

e. Management of Lane Speed Advisories; and

f. Management of Public Advisories.

Process

Demonstration

N10


48


VERIFICATION

NEED TRACE

CS-TMG-01.5.3 Lane Allocations Zone (northbound and southbound) traffic management capabilities shall include, the following:

a. Management of the Target POE Lane

Process

Demonstration

N10

CS-TMG-01.5.4 Pre-Toll Zone (northbound only) Traffic Management capabilities shall include the following:


b. Management of Lane Vehicle Type (i.e.: Passenger, commercial);

c. Management of Lane Direction; and

d. Management of Lane Speed Advisories.

Process

Demonstration

N10

CS-TMG-01.5.5 Departure Zone (northbound and southbound) Traffic Management capabilities shall include the following:




d. Management of Lane Speed Advisories; and

e. Management of Public Advisories.

Process

Demonstration

N10

CS-TMG-01.6 The System shall include Traffic Management Plans – sets of Traffic Management Strategies which taken together enable the operator to manage traffic based on general demand, including the following:

a. Weekday peak AM;

b. Weekday peak PM;

c. Weekday off-peak;

d. Saturday;

e. Sunday; and

Process

Demonstration

N10


49


VERIFICATION

NEED TRACE

f. Holidays, including:

i. USA Holidays; and

ii. MEX Holidays.

g. Monthly

h. Seasonally

CS-TMG-01.6.1 The System shall enable a User to modify Traffic Management Plans, including User configurable time intervals, for peak travel periods for commercial and passenger vehicles.

Process

Demonstration

N10

CS-TMG-01.7 The System shall support Traffic Management by managing Traffic Management Strategies in Traffic Management Modes of the System, including the following:

a. Fully manually, where Users make modifications to the strategies;

b. Fully automatically, where the System implements the strategies; and

c. Partly automatically, where the User and System both make modifications.

Process

Demonstration

N10

CS-TMG-02 The System shall accept Traffic Management Strategy inputs from Users. Input

Demonstration

N11

CS-TMG-02.1 The System shall provide a User with the capability to manage traffic in the OME Crossing manually, with configurable Traffic Management Strategies, including the following:




d. Management of Primary Approach Lanes messaging;

e. Management of Lane Speed Advisories;

f. Management of Public Advisories.

Process

Demonstration

N11


50


VERIFICATION

NEED TRACE

CS-TMG-02.2 The System shall provide Users with User Interfaces containing pre-populated features (e.g.: checklists, drop-down menus) to enter Traffic Management Strategy parameters.

Note: see Section 1.8.2: User Interface Management for further details and requirements on User Interface look and feel.

Physical

Demonstration

N11

CS-TMG-02.2.1 When manually managing Traffic Management Strategies, the System shall provide Users with capabilities to apply the same strategy at different levels of aggregation, including the following:

a. Multiple roadway segments at the same time;

b. An entire direction of travel; and

c. The entire RBMS.

Input

Demonstration

N11

CS-TMG-02.3 The System shall accept Lane Closure instructions from a User, including the following:

a. Road segment of interest;

b. Road segment that an existing Lane Closure should be removed;

c. Duration of Lane Closure (default value will be indefinite); and

d. Traffic Lane of Interest.

Input

Demonstration

N11

CS-TMG-02.3.1 The System administrator shall determine the list of Permitted Words for Lane Closure instructions.

Input

Demonstration

N11

CS-TMG-02.3.1.1 The Business Rules Store shall maintain the list of Permitted Words for Lane Closure instructions.

Input

Demonstration

N11

CS-TMG-02.4 The System shall accept Lane Vehicle Type instructions from a User, including the following:


b. The Lane Vehicle Type for segment, i.e.: commercial, passenger, or both; and

c. Duration of the assignment (default value will be indefinitely).

Input

Demonstration

N11


51


VERIFICATION

NEED TRACE

d. Traffic Lane of interest.

CS-TMG-02.5 The System shall accept Lane Direction instructions from a User, including the following:


b. Traffic Lane(s) of interest in that road segment;

c. Lane Direction for the Traffic Lane, i.e.: normal, reverse; and

d. Duration of the assignment (default value will be indefinite).

Input

Demonstration

N11

CS-TMG-02.6 The System shall accept Primary Approach Lane instructions from a User, including the following:


b. Traffic Lane of interest in that road segment;

c. Primary Inspection Lane Type that correlates to the Traffic Lane(s); and

d. Duration of the assignment (default value will be indefinite).

Note: this feature will generally be determined automatically by the System based on the values collected from the field but can be manually overridden. Refer to the Section 1.7.4: Border Traffic Analysis for details on how the calculation is performed.

Input

Demonstration

N11

CS-TMG-02.7 The System shall accept Lane Speed Advisory instructions from a User, including the following:


b. Lane Speed Advisory (e.g.: 20 mph/30 kph) that should be displayed on the VMS; and

c. Duration of the assignment.

Input

Demonstration

N11

CS-TMG-02.8 The System shall identify if Free-Text contains words that are not Permitted words; words that are not permitted will not be published in VMS messages.

Output

Demonstration

N11

CS-TMG-03 The System shall determine certain Traffic Management Strategies automatically. Process N12


52


VERIFICATION

NEED TRACE

Note: refer to Section 1.7.4: Border Traffic Analysis for details on how the calculations are performed and safety standards required to be enforced.

Analysis

CS-TMG-03.1 The System shall determine certain Traffic Management Strategies continuously for manual and automated mode of operation.

Process

Analysis

N12

CS-TMG-03.1.1 Certain Traffic Management Strategies shall only be determined when the System is placed in a fully automated mode.

Process

Analysis

N12

CS-TMG-03.2 The System shall continuously determine certain Traffic Management Strategies based on Traffic Management Mode, including the following:

a. Management of Primary Approach Lanes messaging

Process

Analysis

N12

CS-TMG-03.3 When in its fully Automatic Mode of Operation, the System shall determine Traffic Management Strategies based on Traffic Management Mode, including the following:

b. Management of Lane Closures;

c. Management of Lane Vehicle Type;

d. Management of Lane Direction;

e. Management of Primary Approach Lanes messaging, e.g.: right lane designated in advance of the POE as SENTRI, READY, FAST, etc.; and

f. Management of Lane Speed Advisories.

Process

Analysis

N12

CS-TMG-04 The System shall accept Traffic Management Plan selections from Users. Input

Demonstration

N13

CS-TMG-04.1 The System shall provide Users with User Interfaces containing pre-populated features (e.g.: checklists, drop-down menus) to Search, retrieve and select Traffic Management Plans.

Note: see section 1.8.2: User Interface Management for further details and requirements on User Interface look and feel.

Physical

Demonstration

N13


53


VERIFICATION

NEED TRACE

CS-TMG-04.1.1 Pre-configured Traffic Management Plans available to Users shall include the following:

a. Divert all passenger traffic at a specific point to commercial lanes; vice-versa; by direction of travel;

b. Weekday Peak AM Plan;

c. Weekday Peak PM Plan;

d. Weekday off-peak Plan;

e. Saturday Plan;

f. Sunday Plan;

g. Holiday Plan; and

i. USA Holidays

ii. MEX Holidays

h. Default Safety Plan.

Process

Demonstration

N13

CS-TMG-04.2 The System shall enable a User to save their current Traffic Management Strategy configuration as a Traffic Management Plan.

Process

Demonstration

N13

CS-TMG-05 The System shall accept Incident Management inputs from Users. Input

Demonstration

N11

CS-TMG-05.1 The System shall provide Users with User Interfaces containing pre-populated features (e.g.: checklists, drop-down menus of Incident Details) to Search, retrieve and select Incident Management Plans.

Physical

Demonstration

N11

CS-TMG-05.2 Pre-configured Incident Management Plans available to Users shall include the following:

a. Emergency all-stop of traffic movement at the OME Crossing, including:

i. By direction (i.e.: northbound, southbound); and

ii. By vehicle type;

Process

Demonstration

N13


54


VERIFICATION

NEED TRACE

b. Immediate diversion of all approaching traffic away from the OME Crossing to pre-established secondary routes; and

c. Immediate diversion of all traffic within the OME Crossing to the departure zone per pre-established secondary routes.

CS-TMG-06 The System shall accept Road Work Management inputs from Users. Input

Demonstration

N11

CS-TMG-06.1 The System shall accept Road Work Zone instructions from a User using Road Work Details, including the following:

a. The road segment of interest where the Road Work is occurring/will occur;

b. The Road Work Safety Zone for that road segment, wherein if a vehicle is detected moving, an Alert would be triggered; and

c. Duration of the Road Work (default value will be indefinite).

Input

Demonstration

N11

CS-TMG-06.2 The System shall provide Users with User Interfaces containing pre-populated features (e.g.: checklists, drop-down menus of Road Work Details) to retrieve and select Road Work Management Plans configurable by segment.

Physical

Demonstration

N11

CS-TMG-06.2.1 Pre-populated Road Work Management Plans available to Users shall include the following:

a. Categories of Road Work Safety Zones, including:

i. All commercial Traffic Lanes northbound/southbound designated as Road Work Safety Zone; and

ii. All passenger Traffic Lanes northbound/southbound designated as Road Work Safety Zone; and

b. Diversions around Road Work Safety Zones, i.e.: route all commercial traffic to passenger lanes, and vice versa.

c. Ability to show Lane Status (i.e. Open/Closed)

Process

Demonstration

N13


55


VERIFICATION

NEED TRACE

CS-TMG-07 The System shall verify the Traffic Management Strategies, Plans, and Modes are safe to establish in the field.

Process

Analysis

N10

CS-TMG-07.1 The System shall determine if updating to the new Strategy, Plan, or Mode is permitted to establish based on criteria including the following:

a. The current traffic status (i.e.: Border Operations Data in the Live Traffic Store);

b. The current status of RBMS Field Devices, e.g.: out-of-service, non-responsive;

c. Traffic Safety Rules for the OME Crossing and neighboring traffic operations; and

d. Law Enforcement and Security Rules.

Process

Analysis

N10

CS-TMG-07.2 If the System determines that the Traffic Management Strategy, Plan, or Mode does not meet safety and operating rules, an Alert will be sent to the User and the System shall ensure the strategy, plan, or mode is not established.

Process

Demonstration

N10

CS-TMG-07.3 If it is unsafe to establish the Traffic Management Strategy, Plan, or Mode, the System shall provide the User with an Alert.

Output

Demonstration

N10

CS-TMG-08 The System shall determine VMS Messages for Approach Lane VMS in order to implement as part of the Traffic Management Strategies and Plans in the field.

Process

Demonstration

N10

CS-TMG-08.1 When computing VMS Messages, the System shall determine messages to be displayed on both incident (site of the strategy) as well as any impacted (derivative) messages that may be necessary in road segments in advance of the strategy location.

Process

Demonstration

N14

CS-TMG-08.2 The System shall manage failures of implementing Traffic Management Strategies and Plans in the field.

Process

Demonstration

N14

CS-TMG-08.3 The System shall determine default VMS Messages (i.e.: blank) in the event that it determines an intended strategy or plan cannot be fully implemented in the field.

Process

Demonstration

N14

CS-TMG-09 The System shall transmit VMS Messages to RBMS Field Devices including the following: Output N14


56


VERIFICATION

NEED TRACE

a. VMS signs and sign systems directly connected to the RBMS System; Demonstration

CS-TMG-10 The System shall provide Users with decision support capabilities to better manage traffic and resolve incidents.

Process

Analysis

N15

CS-TMG-10.1 The System shall provide a User with navigable help content that contains information including the following:

a. Instructions for using System, e.g.: ‘how-tos’, meanings of symbols, etc.; and

b. Operational SOPs.

Output

Demonstration

N15

CS-TMG-10.2 The System shall determine Traffic Management Strategy Advice. Process

Analysis

N15

CS-TMG-10.2.1 The Traffic Management Strategy Advice shall provide a User with recommended Traffic Management Strategies customized to the current operational condition (i.e.: Border Operations Data in the Live Traffic Model) intended to help the User adjust their management approach to better align with safety and performance targets of the border traffic operation.

Output

Analysis

N15

CS-TMG-10.3 The System shall provide a User with Traffic Management simulation capability. Process

Analysis

N15

CS-TMG-10.3.1 The Traffic Management simulation capability shall provide a User with future (projected) performance values of the traffic operation based on Traffic Management Strategies that they have selected.

Output

Analysis

N15

CS-TMG-10.3.2 The Traffic Management projections shall use time-scales of:

a. Fifteen minutes from the current time; and

b. Thirty minutes from the current time.

Process

Analysis

N15

CS-TMG-11 The System shall support Operations Management at the OME Crossing. Process

Demonstration

N16


57


VERIFICATION

NEED TRACE

CS-TMG-11.1 The System shall enable an authorized User to assign territory responsibilities to individual Users, including:

a. A User managing traffic northbound from MEX Pre-Approach Zone to USA Departure Zone;

b. A User managing traffic southbound from USA Pre-Approach Zone to MEX Departure Zone;

c. A User managing traffic northbound and southbound, i.e.: a single User managing the entire RBMS Traffic Zone; and

d. A USA-only User with a MEX-only User.

Input

Demonstration

N16

CS-TMG-11.2 The System shall enable a User who has sufficient permissions to assign specific management responsibilities to other Users, including:

a. A User managing routine (i.e.: non-Incident) conditions with no permissions to activate an Incident Management Plan;

b. A User responsible only for managing Traffic Management Plans, Incident Management Plans, Road Work Plans;

c. A User managing traffic southbound from USA Pre-Approach Zone to MEX Departure Zone; and

d. A User managing traffic northbound and southbound, i.e.: a single User managing the entire RBMS Traffic Zone.

Input

Demonstration

N16

CS-TMG-11.3 The System shall enable a User who has sufficient permissions to manage access credentials of Users.

Input

Demonstration

N16

CS-TMG-11.3.1 The System shall enable a User to exclude another User from accessing the System. Process

Demonstration

N16

CS-TMG-11.3.2 The System shall enable a User to include another User in the access permissions for the System.

Process

Demonstration

N16


58


VERIFICATION

NEED TRACE

CS-TMG-11.4 The System shall enable a User who has sufficient permissions to update any Traffic Management Strategy or Plan that another User has implemented, including the following:

a. Cancelling the strategy or plan another User has implemented

Process

Demonstration

N16

CS-TMG-11.5 The System shall enable a User to schedule in advance when the fully automated mode of operation of the System can go into effect.

Process

Demonstration

N16

CS-TMG-11.6 The System shall provide a User with an Alert prior to the mode of the System changing. Process

Demonstration

N16

CS-TMG-11.6.1 The System shall enable a User to postpone the change of mode. Process

Demonstration

N16

CS-TMG-11.6.2 The System shall enable a User to change the operating mode of the System to/from:

a. Fully manually, where only Users make modifications to the strategies;

b. Fully automatically, where only the System makes modification to the strategies; and

c. Partly automatically, where the User and System both make modifications.

Process

Demonstration

N16

CS-TMG-12 The System shall transmit VMS Messages to External Interfacing Systems including the following:

a. Approach Lane VMS System; and

b. Data Hub System;

Output

Demonstration

N14

CS-TMG-13 The System shall accept Traffic Management Strategy inputs from the CBP External Interfacing System.

Input

Demonstration

N11

CS-TMG-13.1 The System shall include Traffic Management Strategies from the CBP External Interfacing System including the management of the Target POE Lane; a unique, Visual Instruction from CBP personnel, to an individual vehicle to approach the POE in a specific lane.

Process

Demonstration

N10


59


VERIFICATION

NEED TRACE

CS-TMG-13.2 The System shall accept Public Advisory instructions from the CBP External Interfacing System, including the following:

a. Road Segment of Interest;

b. VMS sign of interest;

c. Public Advisory message of interest (if from pre-picked list); and

d. Free-Text input from authorized CBP personnel.

Input

Demonstration

N11

CS-TMG-13.2.1 Public Advisories shall be provided in either, or both, USA English [ref-1] and Español [ref-2]. Other dialects will not be accepted.

[ref-1] ISO 639.2 Eng

[ref-2] ISO 639.2 Spa

Input

Demonstration

N11

CS-TMG-13.2.2 The System shall identify if Free-Text is deemed misspelled when compared with a System dictionary.

Output

Demonstration

N11

CS-TMG-13.3 The System shall provide the CBP External Interfacing System with the capability to Manage Traffic in the OME Crossing manually, with configurable Traffic Management Strategies, including the management of the Target POE Lane.

Process

Demonstration

N11

CS-TMG-13.3.1 The System shall accept Target POE Lane instructions from the CBP External Interfacing System, including:

a. POE Lane identifier that should be displayed for a specific Traffic Lane indefinitely until next updated by the CBP External Interfacing System.

Input

Demonstration

N11


60

1.7.4 Border Traffic Analysis

Effective Traffic and Incident Management requires informed action by operations staff driven by the best performance and impact assessment data. RBMS will provide Border Crossing traffic performance metrics to Users (including the traveling public) in an easy-to-process way as an aid to informing their view of the current and projected performance of the Border Crossing area so that they can take informed decisions on the road.

SANDAG utilizes common industry key performance indicators (KPIs) to assess traffic flow and volume throughput, but these values are calculated after the operational day is over. RBMS will provide real-time KPIs with associated benchmarks to support running assessments of travel quality at the border cross.

Improvements in the monitoring of traffic performance will support objective assessments of how well the RBMS project meets the needs of the traveling public and system operators identified in the ConOps.

Figure 15: RBMS Border Performance Monitoring Architecture


61

1.7.4.1 Border Traffic Analysis Requirements


VERIFICATION

NEED TRACE

CS-ANL-01 The System shall determine new Border Operations Data values from existing data in the Live Traffic Model.

Process

Analysis

N17

CS-ANL-01.1 The System shall determine current Traffic Movement values based on data in the Live Traffic Model, including the following:

a. Border Wait Times (bi-directionally) at the OME Crossing;

b. Border Crossing Times (bi-directionally) at the OME Crossing;

c. Traffic Volumes at the OME Crossing;

d. Traffic Speed at the OME Crossing; and

e. Vehicle occupancy at the OME Crossing.

Process

Analysis

N17

CS-ANL-01.1.1 The System shall determine Border Wait Times computations based on the time it takes for a vehicle to reach the CBP’s primary inspection booth after it arrives at the end of the queue utilizing Timestamp Tag Indications from the PVTD System [IF13].

Process

Analysis

N17

CS-ANL-01.1.2 The System shall determine Border Crossing Times computations based on the time it takes for a vehicle to exit the border crossing process after it joins the queue before CBP primary inspection booth utilizing Timestamp Tag Indications from the PVTD System [IF13].

Process

Analysis

N17

CS-ANL-01.1.3 The System shall determine Traffic Speed computation based on aggregate speeds from many vehicles in a road segment over a period of time utilizing vehicle speeds from the VDS sensor [IF08].

Process

Analysis

N17

CS-ANL-01.1.4 The System shall determine Vehicle occupancy computation based on the detected occupancy time at a point exceeds a threshold time utilizing VDS Occupancy Time from a VDS sensor [IF08].

Process

Analysis

N17

CS-ANL-01.2 The System shall determine new Incident details based on data in the Live Traffic Model, including:

a. Incident detection at the OME Crossing via the following:

Process

Analysis

N17


62


VERIFICATION

NEED TRACE

i. Sudden change in Traffic Speed utilizing calculation based on decrease by X% over Y minute period;

ii. Sudden change in Border Wait Times and Border Crossing times utilizing a calculation based on increase in wait time by X% over Y minute period;

iii. Vehicle moving in a closed lane based on PVTD [IF13] or VDS [IF08] indication of moving vehicle that maps to the Traffic Lane or Primary Inspection Lane that is closed;

iv. Vehicle detected moving in an Incident Zone based on PVTD [IF13] or VDS [IF08] indication that occurs within an Incident Zone or location;

v. Vehicle detected moving in a Road Work Zone based on PVTD [IF13] or VDS [IF08] indication that occurs within a Road Work Zone or location;

vi. Vehicle is detected traveling opposite to the Direction of Traffic based on PVTD [IF13] or VDS [IF08] indication that movement is occurring opposite to the pre-set Direction of Traffic in the System for the lane segment or point location in question; and

vii. Detection from automated video and CHP.

b. Incident Duration:

i. Based on the difference between the start time of the Incident (first recorded) and the current time, or when reported to be resolved.

CS-ANL-01.3 The System shall determine new Road Work details based on data in the Live Traffic Model, including the following:

a. Road Work duration at the OME Crossing based on User-enter Road Work data to calculate the difference between the start time of Road Works (first recorded) and the current time, or when reported to be concluded

Process

Analysis

N17

CS-ANL-01.4 The System shall determine new Border Service Status values based on data in the Live Traffic Model, including the following:

a. Border Crossing open/closed duration at the OME Crossing calculating the difference between the opening time and the current time, or when reported to be closed based on:

Process

Analysis

N17


63


VERIFICATION

NEED TRACE

i. Border Gate Status data via POE GLS System [IF01]; or

ii. User entered open/closed times;

b. Border Crossing open/closed duration at the San Ysidro and OMW Crossings calculating the difference between the opening time and the current time, or when reported to be closed based on:

i. Open/closed status via Data Hub System [IF-06]; or

ii. User entered open/closed times as a manual override;

c. Toll Lane Closure duration calculating the difference between the opening time and the current time, or when reported to be closed based on:

i. Open/closed status via OME Toll System [IF-04]; or

ii. User entered open/closed times as a manual override.

CS-ANL-01.4.1 The System shall verify that User entered manual overrides do not conflict with Traffic Safety Rules.

Process

Analysis

N17

CS-ANL-01.5 The System shall determine Field Device Status (online/degraded/offline) values based on data in the Live Traffic Model, including the following:

a. RBMS Field Device status online/degraded/offline (i.e.: operating state) at the OME Crossing calculating the time elapsed between the last expected communication and current time exceeds a threshold based on greater than X% of time over Y time period

Process

Analysis

N17

CS-ANL-01.6 The System shall compute new Traffic Management Status values based on data in the Live Traffic Model, including the following:

a. Duration of Primary Inspection Lane Types in effect;

b. Duration of Primary Inspection Lanes open/closed;

c. Duration of Lane Vehicle Type configuration; and

d. Duration of Lane Speed Advisory in effect.

Process

Analysis

N17

CS-ANL-01.7 The System shall determine new operational management values based on data in the Live Traffic Model, including the following:

Process

Analysis

N17


64


VERIFICATION

NEED TRACE

a. Duration of User Session in the system; and

b. Duration of Traffic Management mode in effect

CS-ANL-02 The System shall determine projected Traffic Movement values from existing data in the Live Traffic Model, including the following:

a. Border Wait Times (bi-directionally) at the OME Crossing;

b. Border Crossing Times (bi-directionally) at the OME Crossing;

c. Traffic Volumes at the OME Crossing; and

d. Traffic Speed at the OME Crossing.

Process

Analysis

N17

CS-ANL-02.1 The System shall determine projected Traffic Movement values from existing data in the Live Traffic Model for points of time in the future including the following:

a. Five minutes from the current time, including:

i. Border Wait Times (bi-directionally) at the OME Crossing;

ii. Border Crossing Times (bi-directionally) at the OME Crossing;

iii. Traffic Speed at the OME Crossing; and

iv. Traffic Volumes at the OME Crossing.

b. Fifteen minutes from the current time, including:


ii. Border Crossing Times (bi-directionally) at the OME Crossing;

iii. Traffic Speed at the OME Crossing; and

iv. Traffic Volumes at the OME Crossing.

c. Thirty minutes from the current time, including:


ii. Border Crossing Times (bi-directionally) at the OME Crossing; and

iii. Traffic Volumes at the OME Crossing.

d. One hour from the current time, including

Process

Analysis

N17


65


VERIFICATION

NEED TRACE

i. Traffic Volumes at the OME Crossing.

CS-ANL-03 The System shall determine new Historic Operations Data values based on data in the Historic Traffic Store, including:

a. Cumulative values (e.g.: averages) over time; and

b. Statistical analysis of values over time (e.g.: variability, deviation, percentiles).

Process

Analysis

N17

CS-ANL-03.1 When the System has determined new Historic Operations Data values the System shall record those in the Historic Traffic Store.

Process

Analysis

N17

CS-ANL-03.2 The System shall determine historic values bi-directionally (i.e.: northbound and southbound) based on a physical location criteria, including the following:

a. By roadway segment;

b. At specific roadway points;

c. By Traffic Lane;

d. By Primary Inspection Lane;

e. Cumulative value of all Primary Inspection Lanes at a POE; and

f. By Vehicle Lane Type.

Process

Analysis

N17

CS-ANL-03.3 The System shall determine historic values, in a continuous fashion, on time scales including:

a. Fifteen minutes prior to the current time;

b. Thirty minutes prior to the current time;

c. One hour prior to the current time;

d. Six hours prior to the current time;

e. 24 hours prior to the current time;

f. Since the beginning of today (00:00 hrs);

g. Since the beginning of this week (00:00 hrs Monday);

h. Since the beginning of this month (00:00 hrs, 1st of month);

i. Since the beginning of this year (00:00 hrs, January 1st); and

Process

Analysis

N17


66


VERIFICATION

NEED TRACE

j. Seasonal period.

Note: Older data is available in the Historic Traffic Store.

CS-ANL-03.3.1 The System shall determine historic values bi-directionally (i.e.: northbound and southbound) for commercial and passenger vehicles based on time-of-day and day-of-week criteria, including the following:

a. Weekday Peak AM for passenger and commercial (configurable) ;

b. Weekday Peak PM for passenger and commercial (configurable);

c. Weekday off-peak for passenger and commercial (configurable);

d. Saturday;

e. Sunday;

f. Holidays, including:

i. USA Holidays; and

ii. MEX Holidays;

g. Weekly rolled-up (i.e.: aggregate) values;

h. Monthly rolled-up (i.e.: aggregate) values; and

i. Seasonally rolled-up (i.e. aggregate) values.

Process

Analysis

N17

CS-ANL-03.4 The System shall determine specific historic values for the OME Crossing, including the following:

a. Border Wait Time;

b. Border Crossing Time;

c. Traffic Volumes;

d. Average monthly Wait Time;

e. Day of week average Wait Time;

f. Time of day average Border Wait Time;

g. Average hourly Wait Time distribution;

Process

Analysis

N17


67


VERIFICATION

NEED TRACE

h. Wait Time distribution by day of week;

i. Yearly 95th percentile Border Crossing time and Buffer Index;

j. Quarterly 95th percentile Border Crossing time and Buffer Index;

k. Monthly 95th percentile Border Crossing time and Buffer Index;

l. Weekly 95th percentile Border Crossing time and Buffer Index;

m. Year-by-year comparison of hourly average OME Wait Time;

n. 2-week comparison of hourly average OME Wait Time;

o. Yearly average crossing time comparison by Port-of-Entry (POE);

p. 2-week comparison of Wait Time reliability;

q. Severity of average daily Wait Time by POE;

r. Peak hour average travel speeds by segment or corridor;

s. Peak hour average travel time by segment or corridor;

t. Peak hour travel time variability by segment or corridor (Buffer Index);

u. Operational performance month-over-month;

v. Peak hour average travel speed;

w. Peak hour average travel time;

x. Peak hour travel time variability;

y. Traffic Management values, including:

i. Number of VMS messages by associated event type; and

ii. Percent time of VMS message by associated event type;

z. System values, including:

i. System uptime, including:

1. Uptime percentage; and

2. Total downtime (in days, hours, minutes, and days-hours-minutes per year);

ii. System uptime percentage month-over-month trend; and


68


VERIFICATION

NEED TRACE

iii. Field Device reports, including:

1. Number of device failures by type;

2. Number of devices in System by type; and

3. Percentage availability of devices by type (e.g.: camera-hours of availability vs. total number of cameras and total time);

aa. Incident values, including

i. Frequency of incidents;

ii. Number of incidents managed;

iii. Number of incidents by type;

iv. Number of incidents managed by impact or severity;

v. Number of incidents managed by segment or corridor;

vi. Number of incidents managed by peak versus off-peak;

vii. Number of secondary incidents by segment or corridor;

viii. Number of incidents managed by detection source;

ix. Number of incidents unmanaged (not confirmed) by detection source;

x. Incident detection time by type (histogram), average, median;

xi. Incident verification time (histogram), average, median;

xii. Incident response time (histogram), average, median;

xiii. Incident clearance time (histogram), average, median;

xiv. Total incident Duration (histogram), average, median;

xv. Number of incidents shorter than 30 minutes in duration;

xvi. Number of incidents between 30 to 60 minutes in duration;

xvii. Number of incidents between 60 to 90 minutes in duration;

xviii. Number of incidents longer than 90 minutes in duration;

bb. Information dissemination time (histogram), average, median, including:

i. Number of incident notifications by notified agency.


69


VERIFICATION

NEED TRACE

CS-ANL-04 The System shall determine optimal Traffic Management Strategies in order to manage traffic operations dynamically without User intervention.

Process

Analysis

N17

CS-ANL-04.1 The System shall utilize data in the Live Traffic Store to determine Traffic Management Strategies.

Process

Analysis

N17

CS-ANL-04.2 The System shall utilize Performance Targets in the Static Border Store as a reference baseline with which to determine optimal Traffic Management Strategies.

Process

Analysis

N17

CS-ANL-04.3 The System shall verify the Traffic Management Strategies for traveler and staff safety. Process

Analysis

N17

CS-ANL-04.3.1 When computing Traffic Management Strategies for automated management, the System shall conform to highway safety rules for the OME Crossing and adjoining Traffic Zones including the Greater San Diego Traffic Zone and Greater Tijuana Traffic Zone.

Process

Analysis

N17

CS-ANL-04.3.2 When computing Traffic Management Strategies for automated management, the System shall conform to Traffic Safety Rules for transitioning from a manual/semi-manual operating mode to an automated mode (and vice-versa) in order to ensure a safe transition.

Process

Analysis

N17

CS-ANL-04.3.3 When computing Traffic Management Strategies for automated management, the System shall conform to already-in-effect Traffic Management Strategies so that a strategy can be formulated which is complimentary to the existing operation and its performance.

Process

Analysis

N17

CS-ANL-04.3.4 When computing Traffic Management Strategies for automated management, the System shall conform to already-in-effect Alerts so that a safe strategy can be formulated.

Process

Analysis

N17

CS-ANL-04.3.5 When computing Traffic Management Strategies for automated management, the System shall conform to traffic management SOPs codified in the System for the OME Crossing.

Process

Analysis

N17

CS-ANL-04.4 The System shall determine Traffic Management Strategies for a fully automated mode of operation.

Process

Analysis

N17


70


VERIFICATION

NEED TRACE

CS-ANL-04.4.1 The System shall determine which Lane Closures (and openings) for northbound and southbound directions should be enacted for road segments in order to respond to conditions including the following:

a. Traffic Incident; and

b. Align segment operation with performance targets.

Process

Analysis

N17

CS-ANL-04.4.2 The System shall determine which Lane Vehicle Type should be enacted for road segments (northbound and southbound) in order to respond to conditions including the following:

a. Traffic Incident;


Process

Analysis

N17

CS-ANL-04.4.3 The System shall determine which Lane Direction should be enacted for road segments (northbound and southbound) in order to respond to conditions including the following:



Process

Analysis

N17

CS-ANL-04.4.4 The System shall determine an appropriate Lane Speed Advisory for road segments (northbound and southbound) in order to respond to conditions including the following:



Process

Analysis

N17

CS-ANL-04.4.5 When the System is in automated management mode, the System shall select the appropriate Traffic Management Strategy and the appropriate VMS Messages to be displayed on all impacted Approach Lane VMS [IF03].

Process

Analysis

N17

CS-ANL-04.5 The System shall determine Approach Lane Traffic Management Strategies regardless of whether it is in a fully automated mode or manual mode of operation.

Process

Analysis

N17

CS-ANL-04.5.1 The System shall receive the appropriate Primary Inspection Lane designations. Process

Analysis

N17


71


VERIFICATION

NEED TRACE

CS-ANL-04.5.2 When the System has received the appropriate Primary Inspection Lane designations, the System shall determine the appropriate VMS Messages to be displayed on all impacted Approach Lane VMS [IF03].

Process

Analysis

N17

CS-ANL-04.5.3 The System shall receive the Primary Inspection Lane designations by utilizing several variables, including the following:

a. POE Primary Lane Designation data via the Data Hub [IF-06];

b. Lane occupancy at the POE Lane, via:

i. Occupancy Time from VDS [IF08];

c. Traffic Management Strategies that are in effect, including the following:

i. Lane Closures; and

d. Swing Gate Status at the POE Lane via the POE GLS SystemIF01.

Process

Analysis

N17

CS-ANL-04.6 The System shall determine projected Traffic Management values based on simulated Traffic Management Strategies.

Process

Analysis

N17

CS-ANL-04.6.1 The System shall determine projected Traffic Management values as outcomes to Traffic Management Strategies on time scales of:

a. Fifteen minutes from current time.

Process

Analysis

N17

CS-ANL-04.6.2 The System shall determine the accuracy of the predicted outcome against 95th percentile of what actually happened if the strategy was implemented in order for Users to later evaluate the efficacy of the scenario projection capability of the System.

Process

Analysis

N17


72

1.7.5 Alert Management

1.7.5.1 Overview

Alerting is a high-priority operational capability the RBMS needs to provide Users so that they can recognize and if necessary intervene in operational and system issues as they are occurring and evolving, triggering changes in the System process.

Classically, the engineering approach to alerting for user-intensive systems has relied on UI prototyping toward the end of the implementation phase. Given the security, operational, governance, and commercial components of the OME II program, the approach to Alert implementation in RBMS needs to be considered early, often, and in a highly structured way so that the benefits of dependent capabilities can be realized most effectively, e.g.: situational awareness, lane traffic management, Incident Management, System Administration and maintenance.

Alerts are considered in this specification as a special class of data object typically represented to a User or External Interfacing System as an attribute of, or in reference to another Data Item e.g.: lane speed status is “not moving”, interface connection is “disabled”. The emphasized element may be represented as an Alert, potentially by font changes, shape, color, motion, or sound through a number of UI distribution channels i.e.: desktop screen, large scale display, SMS, email, or to an External Interfacing System.

This section therefore describes the Agency’s understanding of Alerts from the perspective of a class of data object, and their behavior (functionality and performance) necessary to meet the operational and maintenance goals for the system.

1.7.5.2 Alerts versus Alarms

Alerts are not the same as “alarms”, but Alerts do consider what would commonly be thought of as alarms. Alerts encompass the full set of special, differentiating notices that, because of their value to a User, need to be brought to their attention in a distinguishing way, e.g.: a visual prompt to check the status of a Field Device, klaxon indicating border evacuation. “Alarms”, as a pejorative, are a narrowly defined and loaded term, connotative of flashing lights and wailing sirens only in the event of severe emergencies, and are thus avoided as a term of definition in this specification. This does not mean that those implementations are precluded in the deployed solution; Human Factors analysis and prototyping must still be considered in the solution implementation.

uc Alert Management

RBMS Central System

:RBMS Central

System USER

Communicate Alert

Manage Alert

Configure Alert

«System»

Interfacing System

Create Alert in

System

Audible Graphical

Detect Alert

Internal Origin

External

Origin

Log Activ ity

«extend»

«extend»

«extend»

Figure 16: Alerts as they relate to Users and Interfacing Systems in RBMS


73

1.7.5.3 Tackling Alert Fatigue

It is imperative that the Alerts implemented in the system solution:

• operate correctly for the range of scenario conditions where Users need an Alert indication;

• have a life-cycle and behavior tailored to the needs of the RBMS User and context;

• eliminate or minimize the occurrence of false positives; and

• are designed in a way to eliminate or minimize Alert fatigue for Users.

System designs where alerts are over-prescribed need to be avoided as a common outcome is that alerts are “switched off” or their intended alerting behavior is modified to avoid distracting Users. A Human Factors analysis and prototyping effort needs to be conducted to ensure that this situation is not encountered.

1.7.5.4 Alert Configuration

The representation and presentation of Alerts to Users is a critical aspect of system design and prototyping. Flexibility is essential to allow SANDAG to modify who receives which Alerts, both in response to lessons learned through experience and changes in operating policy and staffing.

1.7.5.5 Alert Origination and Classification

There are two major sources of Alerts, as illustrated in the figure below, described in this specification:

1. Within Central System – where the Alert is generated within RBMS.

2. External to Central System – where an Alert is provided to the RBMS System from either a User or an External Interfacing System.

In addition to origin, the Alerts described may also be classified by type:

Alert Origin

Within Central System External to Central System

User Interfacing System

RBMS Field External System

Figure 17: Alerts Origin Sources


74

• Operational Alert – an Alert that denotes a traffic management operations related issue that requires attention of the User.

• System Alert – an Alert that denotes an issue with the RBMS Central System or RBMS Field Devices, or interfaces to other systems; this could for example be an issue that requires intervention by a System Administrator to repair.

1.7.5.6 Prioritization and Taxonomy of Alerts

A taxonomy of Alerts will therefore be developed by the Contractor. Alerts destined for presentation and representation to Users in User Interfaces or other forms will be classified according to this taxonomy, which will establish how different Alerts will be presented, to whom they will be presented, and what action(s) if any are required in response to the Alert. The configuration, classification, presentation and representation will be all modifiable in order to accommodate changes to SANDAG policies and practices over time. Representation may be in either visual, or aural formats, or a combination of both.

An example of categories for the taxonomy of Alerts could include:

• Warning – information that requires immediate attention of an operator with possible loss of life or property as a consequence of lack of attention.

• Caution – information that does not require immediate attention, but may require attention in 'near future' or could elevate to warning.

• Advisory – information that identifies recommended action predicated on metrics of the current 'situation.' An advisory could be anything from simple on-line Help Content, and access to relevant SOP and other documentation, to a proposed complex Traffic Management Strategy.

Figure 18: Alert Types


75

• Notification – information that indicates a significant State or status change. The operational definition of ‘significant’ shall be a configuration item for any random variable that forms the basis for a Notification.

1.7.5.7 High-Level Functional Overview

The figure below illustrates the functionality described in this Alert management section of the specification. Alert management involves two principal functionalities:

1. Alert Processing – the life-cycle handling of Alerts and Alert-able events, including the creation of Alerts, their classification and prioritization, and their eventual termination/conclusion, when they are removed for immediate consideration and stored for later review. The System will utilize the System Alerts store to evaluate and execute business rules involving the processing capability.

2. Alert Configuration – Users need the capability to configure how Alerts function in the system, what features an Alert has, its classification, priority, presentation, duration, who receives it, whether Alerts need to be acknowledges, how they should be classified and stored for later use. The system will utilize the System Alerts store to maintain the configuration of Alerts.

Alert Taxonomy(notional)

WarningCautionAdvisoryNotification

Figure 19: Alert Taxonomy


76

The Alert management function will monitor/receive as inputs Operational Status Data from the Live Traffic Store and System Status Data from the Live System Store. Once it had determined that an Alert-able condition is present in the data, it will output either an Operational Alert or System Alert to the Live Traffic Store or Live System Store respectively.

A

lert

Ma

na

gem

en

t

Processing

Creation

Classification

Prioritization

Configuration

System Alerts Store

triggers

triggers

Live Traffic Store Live System Store

Operational Alerts

System Status InformationOperational Status Information

System Alerts

Conclusion

has part

Figure 20: Alert Management Functionality


77

1.7.5.8 Types of Alert Requirement in this Specification

This specification addresses Alert functionality in three ways:

1. As specific required Alerts required, both operational and systemic, written in-line with functional and performance requirements throughout the specification

2. Alert functionality requirements as described in this specific section, describing the capability of Alerts as a form of Data Item.

3. Alert design and implementation requirements, which describes how the design processes of Human Factors Engineering and Prototyping should address Alert identification, definition and implementation, for both specific Alerts (number 1 above) and Alert functionality (number 2 above).

1.7.5.9 Alerts Requirements

The requirements in this section describe:

1. The capturing of Alerts from External Interfacing Systems;

Alert Definition

In this Specification Other Activities

This SectionBy requirements in

other sections

Human Factors

EngineeringPrototyping

Figure 21: Definitions of Alerts


78

2. The verification, classification and prioritization of those Alerts by the System;

3. The calculation of specific Alerts known to be of importance to this design phase in the program; and

4. The presentation and management of those Alerts by Users.


VERIFICATION

NEED TRACE

CS-ALT-01 The System shall receive Alerts from External Interfacing Systems. Input

Demonstration

N18

CS-ALT-01.1 The System shall receive Alerts from RBMS Field Devices, including the following:

a. POE GLS System [IF01];

b. Approach Lane Variable Message Sign (VMS) System [IF03];

c. RBMS CCTV System [IF05];

d. Vehicle Detection System [IF08];

e. Variable Toll Message Sign (VTMS) System[IF12]; and

f. Point Vehicle Time Detection (PVTD) System [IF13].

Input

Demonstration

N18

CS-ALT-01.2 The System shall receive Alerts from External Interfacing Systems, including the following:

a. Data Hub System [IF06] including:

i. Incident information Alerts;

ii. Border Data for broadcast;

iii. Device Status Alerts;

b. OME Toll System [IF-04].

i. Suspension of tolling by location (e.g. toll rate set to zero);

ii. Device Status Alerts; and

iii. Toll lane/booth closed to Traffic.

Input

Demonstration

N18

CS-ALT-01.3 The System shall receive Alerts from External Interfacing Systems, including the following: N18


79


VERIFICATION

NEED TRACE

a. Connection Session faults;

b. Device fault;

c. Data quality fault; and

d. Data absence.

CS-ALT-01.4 When the System receives Alerts from Interfacing Systems, the System shall classify the Alert Type for future use, including the following:

a. Operational Alert – an Alert related to the status of the border operation; and

b. System Alert – an Alert related to the status of the System, or its components.

Process

Demonstration

N18

CS-ALT-01.5 The System shall verify Alerts that it receives from RBMS Field Devices and External Interfacing Systems to confirm they can be identified in terms of location and time consistent with current System time.

Process

Demonstration

N18

CS-ALT-01.6 The System shall include Operational Alerts in the Live Traffic Store. Process

Demonstration

N19

CS-ALT-01.7 The System shall include System Alerts in the Live System Store. Process

Demonstration

N20

CS-ALT-02 The System shall determine Alerts. Process

Demonstration

N19

CS-ALT-02.1 The System shall determine if there are Alert-able conditions in the System’s Data Stores. Process

Demonstration

N19

CS-ALT-02.2 The System shall identify Alert-able conditions by verifying values in the Data Stores against target values (i.e.: a reference model of business rules codified in the System).

Process

Demonstration

N19

CS-ALT-02.2.1 The System shall support User configurability of the target values for the verification and classification of Alerts.

Process

Demonstration

N19


80


VERIFICATION

NEED TRACE

CS-ALT-02.2.2 The System shall support User configurability of the frequency and duration of occurrence of Alerts for the verification and classification of Alerts

Process Demonstration

N19

CS-ALT-02.2.3 The System shall support User configurability of the location of Alerts for the verification and classification of Alerts

Process Demonstration

N19

CS-ALT-02.3 When the System determines Alerts internally, the System shall classify the Alert type for future use, including the following:

a. Operational Alert; and

b. System Alert.

Process

Demonstration

N19

CS-ALT-02.4 When the System determines Alerts internally, the System shall classify the Alert priority for future use, including the following:

a. Warning, which includes information that requires immediate attention of an operator with possible loss of life or property as consequences of lack of attention;

b. Caution, which includes information that does not require immediate attention, but may require attention in ‘near future’ or could elevate to warning;

c. Advisory, which includes information that identifies recommended action predicated on metrics of the current situation. An advisory could be anything from simple on-line help, and access to relevant SOPs and other documentation, to a proposed Traffic Management recommendation; and

d. Notification, which includes information that indicates a significant status change, but may not warrant action by a User.

Process

Demonstration

N19

CS-ALT-02.5 The System shall determine summary Alerts, representing an aggregate of conditions in the field. Process

Demonstration

N19

CS-ALT-02.5.1 The System shall determine summary Alerts including the following:

a. Northbound POE operational status, e.g.: red-amber-green ‘Level of Service’ of crossing;

b. Southbound POE operational status, e.g.: red-amber-green ‘Level of Service’ of crossing;

Process

Demonstration

N19


81


VERIFICATION

NEED TRACE

c. RBMS Field Device type health status, e.g.: red-amber-green ‘Level of Service’ of all devices; and

d. RBMS Central System type health status, e.g.: red-amber-green ‘quality’ of whole system.

CS-ALT-02.6 The System shall manage cascading Alerts utilizing strategies codified within the Systems Alerts rules.

Process

Demonstration

N19

CS-ALT-02.6.1 The System shall determine specific Alerts, including the following:

a. Operational Alerts; and

b. System Alerts.

Process

Demonstration

N19

CS-ALT-02.6.1.1

The System Operational Alerts shall include the following:

a. Border Wait Time exceeds threshold value at OME Crossing;

b. Border Crossing Time exceeds threshold value at OME Crossing;

c. Traffic Volume exceeds threshold value for a roadway segment at OME Crossing;

d. Vehicle Occupancy exceed threshold time at a location at OME Crossing;

e. Proposed Traffic Management Strategy by User contravenes safety rules codified in the System;

f. Vehicle is detected traveling in closed lane at OME Crossing;

g. Incorrect Vehicle Type is detected in lane at OME Crossing;

h. Vehicle is detected traveling in wrong direction at OME Crossing;

i. Vehicle is detected crossing POE Lane in wrong direction at OME Crossing;

j. Vehicle is detected traveling within OME Crossing Road Work Zone;

k. Vehicle is detected traveling in excess of advisory at OME Crossing Road Work Zone;

l. Vehicle is detected traveling within at OME Crossing Incident Zone; and

m. Severe road weather conditions at the OME Crossing or in the region.

Process

Demonstration

N19


82


VERIFICATION

NEED TRACE

CS-ALT-02.6.1.2

The System Alerts shall include the following:

a. Unauthorized login in System;

b. Connection Session failure;

c. Health Status from External Interfacing System is out-of-tolerance;

d. Quality of data from External Interfacing System does not meet expectations;

e. Quality of data within System does not meet expectations;

f. System function failure;

g. Incorrect User logon; and

h. System infrastructure failure, including the following:

i. Server failure.

Process

Demonstration

N19

CS-ALT-03 The System shall provide a User Interface with an Alert. Output

Demonstration

N19

CS-ALT-03.1 The System shall determine from the properties of the Alert which User Interface and External Interfacing System to present it on, when, and how.

Process

Demonstration

N19

CS-ALT-03.1.1 Properties of the Alert shall include:

a. Alert type; and

b. Alert priority.

Process

Demonstration

N19

CS-ALT-03.2 The System shall enable a User to manage an Alert presented on a User Interface. Process

Demonstration

N19

CS-ALT-03.2.1 The System shall enable a User to acknowledge an Alert presented on a User Interface. Process

Demonstration

N19

CS-ALT-03.2.2 When a User acknowledges an Alert on a User Interface, the System shall update the Alert’s presentation properties.

Output

Demonstration

N19


83


VERIFICATION

NEED TRACE

CS-ALT-03.2.3 The System shall enable a User to cease future presentation of Alerts on a User Interface. Process

Demonstration

N19

CS-ALT-03.2.4 The System shall enable a User to cease presentation of Alerts of certain types, including the following:

a. Alerts from specific field device e.g.: a faulty PVTD sensor;

b. Alerts from specific class of field devices e.g.: all PVTD sensors;

c. Alerts from a specific location; and

d. Alerts from a specific region.

Output

Demonstration

N19

CS-ALT-04 The System shall transmit Alerts to External Interfacing Systems in accordance with their interface design.

Output

Demonstration

N18

CS-ALT-04.1 The System shall transmit Alerts to the interfacing Data Hub system including the following:

a. Incident information Alerts;

b. Border Data for Broadcast; and

c. Device Status Alerts.

Output

Demonstration

N18

CS-ALT-05 The System shall receive Alerts from External Interfacing Systems in accordance with their interface design.

Input

Demonstration

N18


84

1.7.6 System Reporting

Reports documenting historical events, actions taken, and performance of traffic operations and System Performance are of crucial importance to the System Users, administrators, managers, and executives tasked with responsibility and accountability for management of traffic crossing the border region.

The System needs to provide the capability for Users to flexibly customize and produce many different types of reports for different purposes. Those reports may be provided on a physical format (e.g.: screen), or printed as a hardcopy, or both. A sample of the types of reports includes:

• After-action Review Reports – After major Incidents, operations personnel may wish to conduct internal after-action reviews to assess performance in responding to incidents. The System needs to be able to capture the relevant information to support these reviews, including logging all system activity, who performed what functions, and when.

• Performance Measures Reports – There is a need to assess the performance of the System, both for reporting successes to decision makers and for internal assessments. These reports may be programmed for monthly or annual production, or they may be requested as needed. They may provide source data for larger reports such as annual reports to reporting agencies.

Reports may contain a combination of types of information, such as the following:

• Sensed – those Data Items that the System received from External Interfacing Systems.

• Calculated – Data Items that the System calculates, either to support aspects of System behavior or in particular for the purposes of a report, such as a statistical value.

• Evaluated – those Data Items that the System generates itself based on business rules, for example Alerts.

• User Entered – Data Items entered by System Users themselves, such as free-text notes that later become part of an after-action review report.

1.7.6.1 Report Creation, Templates, and Control Concepts

In order for the reporting functionality of the System to be expandable and flexible, it is necessary to allow reports to be customized for each purpose or task. The term "configurable" is used throughout this section to indicate that each parameter of Historic Reports can be adjusted to suit the custom needs of Users as defined elsewhere in this specification. Reports are generated from a design template (report template), and the template can be saved for later reuse.

Figure 22 illustrates the major reporting capabilities for RBMS and the interactions between the information model and the functions of the System.


85

Figure 22. Overview of Data Reporting Functionality

Live Traffic Store

Live System StoreBusiness Rules Store

Static Border Store

Static System Store

Historic Data Store

Access Historic

Reports

Publish Current

Reports

Configure Report

Properties

Manage Template

Library

Manage Historic

Reports

Report Configuration Report Publication

Configure

Publication

Properties

Configure Template

Appearance

Configure Template

Data Item Content

Archive Historic

Reports

Access Template

Archive Template

Schedule

System Triggers

User Triggers

Access Privileges

Access Privileges

Distribute Channels

Template Properties

Publication Properties

Archiving PropertiesTemplate Properties

Publication Properties

Archiving Properties

Data Items

Report RequestHistoric Report

“Push”

“Pull”


86

Figure 23: RBMS Reporting Architecture

Capture

Report RequestsReport Property Configurations• Information Content• Presentation Layout• Distribution Channels• Schedule Properties• Event Properties• Access Privileges• Format Properties

Manage Report Library

RBMS User

Border Operations Report TemplatesRBMS System Report TemplatesBorder Operations ReportsRBMS System ReportsReport Request Denials




Static System Store

Live System Store

Historic Data StoreReport Requests

Report Property Configurations• Information Content• Presentation Layout• Distribution Channels• Format Properties

Report Property Configurations• Information Content• Presentation Layout• Distribution Channels• Format Properties

Report Property Configurations• Schedule Properties• Event Properties• Access Privileges

Report RequestsArchive Data

Report Business Rules

PresentReport Business Rules

Border Operations Report Templates

RBMS System Report Templates Populated Reports

Populated Reports

RBMS User


Border Operations ReportsRBMS System ReportsReport Request Denials

Report RequestsExternal

Interfacing Systems


87

1.7.6.2 Configuring Reports

Users will need to create and modify Historic Reports and Report Templates flexibly from the initial deployment to over time as their business and reporting needs change. Users will also need to be able to manage that inventory of formatter reports, upon which new reports can be generated. When modifying an existing report or creating a new one, three elements need to be configured:

1. Information Content; the Data Items which appear in the report need to be configurable

2. Presentation Format; the presentation of Data Items, such as charts, tables, placements, as well as the physical format (e.g.: digital file, paper copy, both)

3. Access and Distribution Properties; configuring properties of the report such as the events that trigger the publication of a report (e.g.: on-demand by User, timed event, Alert), the distribution channels (e.g.: External Interfacing System, on-screen, to printer at a location), Users permissions for access or modification of the report

Report Templates are the framework structures into which Data Items populate to produce Historic Reports. Templates ensure that reports will be reusable and consistent over time. However, the System will make provision for ad-hoc reporting (see Publication section below). The templates may be basic spreadsheet style sheets, text documents, graph templates, or pre-formatted versions of the same, combining elements of all into a single formatted report

1.7.6.3 System Reporting Requirements

The requirements in this section describes capabilities of the system to:

1. Produce reports of traffic operations, system operations and performance for Users and the organization to use, either on User request, or by the system automatically;

2. Design customized reports as data needs change over time;

3. Archive reports for later use; and

4. Transmit reports securely to trusted parties.


88


VERIFICATION

NEED TRACE

CS-REP-01 The System shall provide reporting capabilities to Users. Process

Demonstration

N21

CS-REP-01.1 The reporting capabilities shall provide a User with features to manage reports. Output

Demonstration

N21

CS-REP-01.1.1 The reporting capabilities shall provide (i.e.: generate) reports on-demand and automatically; both timed and triggered.

Output

Demonstration

N21

CS-REP-01.1.2 The reporting capabilities shall establish custom reports; utilizing existing reports as a basis as well as creating new.

Output

Demonstration

N21

CS-REP-01.1.3 The reporting capabilities shall cache queries within five seconds; either initiated by a User or the System automatically, for later use.

Constraint

Demonstration

N21

CS-REP-01.1.4 The reporting capabilities shall transmit reports to trusted parties as a formatted document or data

Output

Demonstration

N21

CS-REP-01.2 The System shall provide Users with reports of the following:

a. Border operations performance;

b. Incidents on the roadway;

c. System Performance;

d. System Incidents;

e. User Training; and

f. Failure reports of System elements, communication, and interfaces.

Output

Demonstration

N21

CS-REP-01.3 The System shall provide reports with a variety of presentation features including the following:

Output

Demonstration

N21


89


VERIFICATION

NEED TRACE

a. Data trends presented with graphs, e.g.: pie-charts;

b. Data tables;

c. Text, both pre-populated and User-supplied Free-Text.

CS-REP-01.4 The System shall provide reports in a variety of formats including the following:

a. On-screen;

b. Rich Text Format (.rtf);

c. Portable Document Format (.pdf);

d. Comma separated variable (.csv);

e. Microsoft Word Document (.docx); and

f. Microsoft Excel Document (.xlsx).

Output

Demonstration

N21

CS-REP-01.5 The System shall ensure all data within its stores is accessible for report generation. Performance

Demonstration

N23

CS-REP-01.6 The System shall ensure all reports provided are interpretable to a User as-is, without any need for the System to further interpret or decode the data.

Process

Demonstration

N23

CS-REP-02 The System shall provide (i.e.: generate) reports. Process

Demonstration

N21

CS-REP-02.1 If the System fails to provide a report when required, the System shall provide a User and System with an Alert.

Output

Demonstration

N21

CS-REP-02.2 The System shall enable a User to request a report. Process

Demonstration

N21

CS-REP-02.2.1 The System shall provide a User with report request features including the following: Output N21


90


VERIFICATION

NEED TRACE

a. Selecting the Report Type from a pre-configured list of type templates;

b. Specifying a time interval that should be reported on in the report, including the following:

i. Certain hours before current time;

ii. The day before;

iii. The week-to-date;

iv. Any prior week or number of weeks;

v. The month-to-date;

vi. Any prior month or number of months;

vii. The year-to-date;

viii. Any prior year or number of years; and

ix. Between two selected dates.

c. Specifying the publication format of the report, e.g.: .pdf, .csv.

Demonstration

CS-REP-02.2.1.1 The System shall provide a set of initial Report Types. Example types may include the following:

a. Border Wait Time trend report;

b. Border Crossing Time trend report;

c. Traffic Volumes report;

d. Traffic Management report;

e. Incident Summary report;

f. Road Work report;

g. System Performance report;

h. System Failure report;

i. External Interfacing Systems report;

j. Communications System report;

Output

Demonstration

N21


91


VERIFICATION

NEED TRACE

k. Training Session report; and

l. Toll Rate report.

CS-REP-02.2.2 The System shall provide a User with report editing features including the following:

a. Adding their own text into the body of the report; and

b. Attaching User-specified items to the report including Traffic Images.

Output

Demonstration

N21

CS-REP-02.2.3 The System shall display the report on-screen to the User once it has been generated within 30 seconds.

Constraint

Demonstration

N21

CS-REP-02.3 The System shall provide reports automatically. Output

Demonstration

N21

CS-REP-02.3.1 The System shall provide reports automatically with a frequency, including the following:

a. Daily, at a specific time;

b. Weekly at a specific time and day; and

c. Monthly at a specific time and day.

Output

Demonstration

N21

CS-REP-02.3.2 The System shall enable a User to specify the frequency of automatic report provisioning. Output

Demonstration

N21

CS-REP-03 The System shall enable a User to design a new customized Report. Input

Demonstration

N21

CS-REP-03.1 The System shall enable a User to modify an existing or create an entirely new Report. Input

Demonstration

N22

CS-REP-03.2 The System shall enable a User to identify which type of data should be included together in a new Report including the following:

a. Border Operations Data;

Input

Demonstration

N22


92


VERIFICATION

NEED TRACE

b. System Operations Data;

c. External Interfacing Systems Data; and

CS-REP-03.2.1 Border Operations Data Report shall include the following:

a. Traffic Movement data;

b. Traffic Management data, including:

i. Incident Details;

c. Operations Management data, including:

i. When were Users logged on/off to the System;

ii. What actions did the Users perform;

iii. When was the System in an automated operational mode; and

iv. What Traffic Management Strategies were implemented.

d. Border Service data;

e. Border Weather data; and

f. Public Advisory data.

Input

Demonstration

N22

CS-REP-03.2.2 System Operations Report Data shall include the following:

a. Network Management System (NMS) status;

b. System Security status;

c. Database status; and

d. User Interface status.

Input

Demonstration

N22

CS-REP-03.2.3 External Interfacing Systems Report data shall include the following:

a. Connection Session data, e.g.: start/stop of sessions;

b. Connection security status;

Input

Demonstration

N22


93


VERIFICATION

NEED TRACE

c. Data volumes exchanged; and

d. External Interfacing System Health Status.

CS-REP-03.2.4 Training data shall include the following:

a. Trainee progress on courses; and

b. Trainee performance on activities.

Input

Demonstration

N22

CS-REP-03.3 The System shall enable a User to identify determined values that are included in the report, including the following:

a. Averages of data sets;

b. Standard deviations of data sets;

c. User-specified formulae (e.g.: dividing one data set by a scalar or another data set); and

d. User defined ranges of data sets.

Input

Demonstration

N22

CS-REP-03.4 The System shall enable a User to identity the typesetting that should be used in the report.

Input

Demonstration

N22

CS-REP-03.5 The System shall enable a User to identify graphical items that are used to present data in the report, including the following:

a. Graphs, with which axes should contain which data and including:

i. Gridlines;

ii. Trend-lines;

iii. Error-bars on data; and

iv. Logarithmic;

b. Pie-charts, with which slice should contain which data; and

c. Tables, with which cells should contain which data.

Input

Demonstration

N22


94


VERIFICATION

NEED TRACE

CS-REP-03.6 The System shall enable a User to identify the frequency and time for report generation, e.g.: provide report every day at 6:00 am.

Input

Demonstration

N22

CS-REP-03.7 The System shall enable a User to identify elements of the style sheet for the report, including the following:

a. Table of contents layout;

b. Headers and footers (if a published document); and

c. Placement/sequence of information appearing in the report.

Input

Demonstration

N22

CS-REP-03.8 The System shall enable a User to identify where the report is saved to the User’s local drive, i.e.: its default storage location

Input

Demonstration

N22

CS-REP-03.9 The System shall enable a User to store each customized Report Template for later retrieval and use.

Process

Demonstration

N22

CS-REP-03.9.1 The System shall enable a User to share customized Report Templates with other Users. Process

Demonstration

N22

CS-REP-03.10 The System shall provide the features to design customized Report in a manner simple for Users to learn with a short amount of training.

Performance

Test

N22

CS-REP-04 The System shall provide report archival capabilities archived to the Historic Data Store. Process

Demonstration

N24

CS-REP-04.1 The System report archive shall provide Navigation Features accessible to Users including the following:

a. Search, by date, time, location, Report Type;

b. Sort; and

c. Filter.

Process

Demonstration

N24


95


VERIFICATION

NEED TRACE

CS-REP-04.2 The System shall enable a User to establish where reports they have requested be provided are stored.

Input

Demonstration

N24

CS-REP-04.3 The System shall automatically store User-requested or automatically-provided reports in specific storage locations.

Process

Demonstration

N24

CS-REP-04.4 When requested by a User, the System shall display an archived report on their User Interface.

Output

Demonstration

N24

CS-REP-04.5 If the System fails to archive a report when required, the System shall provide a User with an Alert.

Performance

Demonstration

N24

CS-REP-05 The System shall transmit reports. Output

Demonstration

N25

CS-REP-05.1 When requested by a User, the System shall transmit an archived report requested by them to a User-specified printer.

Output

Demonstration

N25

CS-REP-05.2 When requested by a User or groups of Users, the System shall transmit an archived report requested by them to a User-specified recipient.

Output

Demonstration

N25

CS-REP-05.3 If the System fails to transmit a report when required, the System shall provide a User with an Alert within five seconds.

Performance

Demonstration

N25


96

1.8 Enabling Functions

1.8.1 Data Management

This section of the specification describes and defines the Data Management capability of the RBMS. The timeliness and accuracy required of data capture, processing, and dissemination in the System coupled with the quantity of data involved makes data management a significant concern for the Users. Ineffective data management capability will, for them, adversely impact their decision making capability as well as their operational effectiveness. Users require the enabling infrastructure to perform certain actions against certain performance criteria in order to be effective and meaningful.

Capabilities that User need in data management are:

• Data Flow

o Collection (system boundary) – Data must be gathered by the System through its interfaces, either machine-machine (see Section 1.8.4: System Interface Management) or human-machine (see Section 1.8.2: User Interface Management). Requirements for the capture of data are held in alternative sections

o Transmission (system boundary) – Data must be presented by the System through its interfaces, either machine-machine (see Section 1.8.4: System Interface Management) or human-machine (see Section 1.8.2: User Interface Management). Requirements for the presentation of data are held in alternative sections.

o Transfer (within system boundary) – the System will need to exchange information within the System’s Data Stores in order for processing to take place. This involves the extraction and insertion of data from and stores once functionally processed

• Data Computation

o Verification – Users need to be assured that the information they are basing operational decisions on is verified within design tolerances of the System. The System therefore must validate the data that it captures and processes.

o Transformation – Information will arrive into the System in a number of formats, configurations, arrangements, and will generally need to be automatically transformed into forms and structures that are intelligible to the internally processes, arranged for processing, and then transformed/processed; Users will not be responsible for defining or conducting this typically.

o Analysis – The System must calculate and evaluate new values from the data it has. Calculation involves the processing of new values from existing data, whereas evaluation is conditional property of data determined by a set-point or threshold range, for example does a calculated value reach a threshold to determine it is an Alert; thus the User needs the System to monitor data for Alert-able conditions.

• Data Retention

o Storage – providing storage, managing the configuration of storage, the act of storing itself.


97

o Retrieval – Users need the System to find data either automatically, or on their request (e.g.: via a Search feature).

o Logging – data presence, activity, and state transformation/change must be continually recorded within the system so that an accurate historical record of System behavior can be reported.

Figure 24. Summary view of elements of the Data Management capability

Data Flow Data Computation Data Retention

Collection

Transmission Retrieval

Transfer

Verification

Transformation

Analysis

Storage

Logging


98

Figure 25: RBMS Data Management Architecture

RBMS Field Devices


Capture Present

Verify Correlate, Overlay, Transform

StoreLog Events

RBMS User




Static System Store

Live System Store

Historic Data Store

Data Items

Data Items

Data Items

Create

Data Items Data Items

Event Instances Event RecordsData Items

Data Items

Data Items

Data Items

Data Items

RBMS Field Devices


RBMS User

Data Items

Data Items

Data Items

Configure Data Management Rules

Data Management Business Rules Updates

Data Management Business Rules


99

1.8.1.1 Data Management Requirements

Requirements in this section cover the following:

• Data Transfer. Users need the System to automatically route information within the System from one Data Store to another, as needed. This process needs to be invisible to the User, as automated as possible.

• Data Verification. Users need the System to provide an accurate representation of conditions in the field as well as to other External Interfacing Systems. Information flowing across the RBMS boundary as well as within the System needs to be verified to ensure the quality of that information meets the expected targets, as codified in the business rules and configuration rule stores. Users may need to:

o Be notified of a condition where the System detects unexpected Data Items or Data Item Property

o Authorize the System to implement a correction it or they have selected (e.g.: inhibit data processing, suspend Connection Session)

In certain situations established in the business rules and configuration rules stores, the System will take corrective action automatically without User notification or intervention.

• Data Transformation. Information will arrive into the System in a number of formats, configurations, and arrangements, and will generally need to be automatically transformed into forms and structures that are intelligible to internal processes, arranged for processing, and then transformed/processed; Users typically are not responsible for defining or conducting this process.

• Data Retention. Users need data to persevere in the System, to support both the ongoing execution of the System’s capabilities, as well as later retrieval for reporting and analysis. There are three major data retention needs:

o Storing Data. Users need data to be stored so that it may be retrieved for future analysis; storage needs to be accomplished in a structured, organized way so that Users as well as the System can reproducibly and predictably access data at a later time as needed. The nature of data persistence must also be addressed – certain data should be available to Users quickly, but longer-term storage and archiving will be necessary given the anticipated amount of data over the duration of the System’s lifecycle. There are four aspects of data storage:

1. Store Data

2. Data Repositories, Near-Term Storage

3. Data Repositories, Long-Term Storage

4. Expand Storage Capacity

o Retrieval. The User and the System need to reclaim data that has been stored easily. Over time as the data is archived, if the System configuration changes, newer configurations of the System still need to be able to reliably interpret older archived data.


100

o Logging. Users can take advantage of summarized logs describing certain occurrences or changes that happened operationally or in the enabling system, in real-time or post-analysis.

• Data Repositories; Near- and Long-Term Storage of Data Items. Users will need to access Data Items from the Data Repository at different times for different purposes. How that Data Repository capability is realized in the final system (e.g.: deploying data archives) will be informed by the Supplier design and the RBMS design process, subject to approvals by the Engineer.

Accessibility and retention of the data in a Data Repository (-ies) must accommodate both the implemented design of the System (and therefore requirements are drafted independent of a specific data repository solution) and intended use of data by Users. Potential implemented solutions for the use of and retaining of RBMS data can depend on the Data Age parameter, including:

o “Real-Time/Near-Real-Time” Data via Office System Storage. These are Data Items that are historical but part of the “live” operational picture and potentially “stored” within the primary operational system. e.g.: an Operational Incident such as ‘a disabled vehicle was reported 20 minutes previously’ may be retained and provided to Users.

o “Contemporary/Recent” Data via Office System Storage. These are Data Items still retrievable by Users via the primary office system and are retained in the office system.

o “Old” Data via Archives – Non Office System Storage. A period of time (i.e.: Data Age) codified in the Data Repository configuration rules determines when Data Items are to be archived outside the office system. Data Items would still be retrievable by Users via the primary office system. The threshold for Data Age would be governed by a number of parameters as a function of the Data Type, but would include the limit of the office system to store real-time and contemporary data without impacting its performance or threatening the integrity of the data.

• Data Logging. Certain state values (i.e.: the condition or value of a System Element or Data Item) within the System need to be monitored and recorded for occurrence or change over time (i.e.: logged). For the purpose of this specification, an occurrence or change to a state is termed a “state value event.”

Logging of state value event can result in a “log” being created, possibly provided to a User. State value event logs are operationally useful to Users. For example, incident logs that indicate when an Operational Incident occurred or in post-event analysis where forensic review can show what occurred in the System can be helpful. Incident logs may include details such as: whether a CCTV Camera feed was working, the time when the system failed, and duration of an Incident.

State value events fall broadly into two categories:

1. Operational values or changes of certain Data Items related to the management and monitoring of traffic in the border region, e.g.: Incident Alerts, POE/GLS System status, and Travel Time; and


101

2. Systemic values or changes of certain Data Items related to the operation and configuration of RBMS itself, e.g.: Connection Session status with an External Interfacing System, System Failover, System Alert for a failed process, the point in time at which a function executes a transformation, calculation, evaluation, receipt, or transmission of data, the point in time that a User was granted access to the System, duration of their session, failed state of a System function, and failed state of a System Element.

Only certain state value events need to be logged – not all. Over time, those items identified to be logged may change – the System therefore needs to provide Users with the capability to manage the change of what constitutes state event values, which state event values are to be logged/recorded, how (where, when) they should be recorded, and how (where, when) they should be published. Certain historic logs (i.e.: reports containing state event values) will thus be of use to Users directly (either “live” or after the fact) and others may only be necessary or provided upon request.


102


VERIFICATION

NEED TRACE

CS-DMG-01 The System shall manage System Data (i.e.: data within the System) by providing data management capabilities, including the following:

a. Data transfer;

b. Data verification and validation;

c. Data transformation;

d. Data retention;

e. Data Repositories, i.e. near and long-term storage of Data Items;

f. Data logging, i.e.: events; and

g. Configuration of business rules of the System to perform each of these activities.

Process

Analysis

N26

CS-DMG-01.1 Data Transfer capabilities shall include the following:

a. Across the System boundary, i.e.: with External Interfacing Systems and User Interfaces; and

b. Within the System, i.e.: from one System Store to another.

Process

Analysis

N26

CS-DMG-01.2 Data transformation capabilities shall include the following:

a. Calculating new data values utilizing existing; and

b. Evaluating existing data and deriving Alerts.

Process

Analysis

N26

CS-DMG-01.3 Data Retention capabilities shall include the following:

a. In near-term storage for retrieval by Users who need historical data for recent reporting; and

b. In long-term storage (i.e.: ‘archiving’) based on Data Age.

Process

Analysis

N26

CS-DMG-01.4 Data Repositories capabilities shall include the following:

a. “Real-time/near-real-time” data via office System storage;

b. “Contemporary/recent” data via office System storage; and

c. “Old” data via archives (non-office System storage).

Process

Analysis

N26


103


VERIFICATION

NEED TRACE

CS-DMG-02 The System shall transmit and receive data. Process

Analysis

N26

CS-DMG-02.1 The System shall transmit and receive data with System Elements at the System boundary without creating latency in the System, including the following:

a. External Interfacing Systems;

b. RBMS Field Devices;

c. User Interfaces.

Constraint

Analysis

N26

CS-DMG-02.2 The System shall transmit and receive data between System Elements within the System boundary within the performance timeframes indicated below.

Process

Analysis

N26

CS-DMG-02.2.1 The System shall transmit and receive data between Data Stores within 500ms. Process

Analysis

N26

CS-DMG-02.2.2 The System shall transmit and receive data between System software processes within 500ms.

Process

Analysis

N26

CS-DMG-02.2.3 The System shall transmit and receive data between System hardware and firmware within 500ms.

Process

Analysis

N26

CS-DMG-02.2.4 The System shall transmit and receive data between Data Warehouse(s) within 500 ms. Process

Analysis

N26

CS-DMG-03 The System shall verify and validate data in the System. Process

Analysis

N27

CS-DMG-03.1 The System shall verify that a Data Item’s properties conform to the System’s expectations of that Data Item value, as defined in the System’s business rules.

Process

Analysis

N27


104


VERIFICATION

NEED TRACE

CS-DMG-03.1.1 The System shall allow System Administrator configuration of System expectations for each Data Item or provide for review and static configuration at the time of System design, implementation, and testing.

Process Analysis

N27

CS-DMG-03.1.2 Data Item Properties shall include the following:

a. Permitted values – values that are considered normal tolerance for the Data Item;

b. Completeness – that the range of values are present, i.e.: no missing data; and

c. Latency – the Data Item arrives at its next process “on-time”.

Process

Analysis

N27

CS-DMG-03.1.3 If a Data Item’s properties are not within expectations, then the System shall generate a System Error and provide the System or error log with an Alert.

Process

Analysis

N27

CS-DMG-03.2 The System shall verify that a Data Item does not contain malicious software (e.g.: ‘malware’, ‘viruses’).

Process

Analysis

N27

CS-DMG-03.2.1 If the System determines data that could contain software viruses, then the System shall route the data to a System quarantine to be isolated from further processing by the System.

Process

Analysis

N27

CS-DMG-03.3 When data has been verified, the System shall accept it to be further processed by the System.

Process

Analysis

N27

CS-DMG-04 The System shall process data from one form to another (i.e.: transform data). Process

Analysis

N28

CS-DMG-04.1 The System shall process Data Items for export and offsite recovery into archive file formats that can be transferred to external media.

Process

Analysis

N28

CS-DMG-05 The System shall provide data storage capabilities. Process

Analysis

N29


105


VERIFICATION

NEED TRACE

CS-DMG-05.1 The System shall support multiple forms of Data Storage. Performance

Demonstration

N29

CS-DMG-05.1.1 Data Storage capabilities shall include the following:

a. Near-term storage in the Historic Traffic Store and Historic Data Store for use in traffic and System management activities, e.g.: near-term recall, reporting; and

b. Long-term storage in a Data Warehouse for archival purposes, e.g.: investigations, audits.

Process

Demonstration

N29

CS-DMG-05.1.2 Near-term storage shall support access to data within the System for a period of not less than a 36 hour period (e.g. 24 hour operating day plus 8 hour overlap).

Process

Demonstration

N29

CS-DMG-05.1.3 Long-term storage shall support System access to data for a period of not less than two years.

Process Analysis

N29

CS-DMG-05.1.4 Data storage beyond long-term storage may be retained in a separate storage process if it is made available for reporting purposes for a minimum period of 36 months.

Process

Analysis

N29

CS-DMG-05.2 The System shall store data in the Historic Stores in a manner that does not impact the Systems operational responsiveness to Users (defined as not generating any UI or display latency greater than 100 ms).

Constraint

Demonstration

N29

CS-DMG-05.3 The System shall store data in a Data Warehouse in a manner that does not impact the Systems operational responsiveness to Users (defined as not generating any UI or display latency greater than 100 ms).

Constraint

Demonstration

N29

CS-DMG-05.4 The System shall store data, except those which are transitory and used only during processing, in non-volatile memory.

Physical

Test

N29

CS-DMG-05.5 The System shall ensure no alteration of Data Items in:

a. Historic Traffic Store;

Security

Test

N29


106


VERIFICATION

NEED TRACE

b. Historic System Store; and

c. Data Warehouse.

CS-DMG-05.6 If the storage process is interrupted (e.g.: power failure, Connection Session failure), then the System shall resume data storage in response to the type of interruption a manner consistent with business rules, including the following:

a. no Data Item is lost;

b. Data Items can be discarded; and

c. Data Items can be discarded only for a given period.

Performance

Demonstration

N29

CS-DMG-05.7 The System shall securely store Data Items. Security

Analysis

N29

CS-DMG-05.7.1 The System shall encrypt Data Items in storage in a manner subject to approval by the Engineer.

Security

Analysis

N29

CS-DMG-05.7.2 The System shall decrypt Data Items from storage in a manner subject to approval by the Engineer.

Security

Analysis

N29

CS-DMG-05.8 The System shall provide storage capacity sufficient for storage of 10 years of archived data in the Data Warehouse.

Performance

Analysis

N29

CS-DMG-05.9 In the event of a change to the System application software code, the System shall maintain the fidelity of previously stored data.

Process

Analysis

N29

CS-DMG-05.10 In the event of a change to the System configuration, the System shall maintain the fidelity of previously stored data.

Process

Analysis

N29

CS-DMG-05.10.1 The System shall provide access to data in the Data Warehouse. Output

Demonstration

N29


107


VERIFICATION

NEED TRACE

CS-DMG-05.10.2 When requested by a User, the System shall provide a Data Item stored in the Data Repository.

Process

Demonstration

N29

CS-DMG-05.10.2.1

When the Data Item is part of queried near-term data storage, the System shall provide the requested Data Item within 10 seconds.

Performance

Test

N29

CS-DMG-05.10.2.2

When the Data Item is part of queried long-term data storage, the System shall provide the requested Data Item within 120 seconds.

Performance

Analysis

N29

CS-DMG-05.10.3

When requested by an External Interfacing System, the System shall provide a Data Item stored in the Data Repository.

Process

Demonstration

N29

CS-DMG-05.10.3.1

When the Data Item is part of queried of near-term data storage, the System shall provide the requested Data Item within 10 seconds to the External Interfacing System.

Performance Test

N29

CS-DMG-05.10.4 The System shall enable Data Repository data in current status or near-term storage retrieval on a second by second basis.

Performance

Demonstration

N29

CS-DMG-05.10.5 The System shall provide external reporting/analysis tools access to the Data Repository without creating any additional latency in System processes, UIs, or functions.

Constraint

Demonstration

N29

CS-DMG-05.10.6 The System shall provide functionality for Data Repository connectivity based on an open standard (e.g.: XML, ODBC, NTCIP, TMDD, etc.).

Output

Analysis

N29

CS-DMG-05.10.7 When the System application software versions are changed, the System shall maintain Data Item retrieval functionality for all previously stored records from near- and long-term storage.

Process

Analysis

N29

CS-DMG-06 The System shall record certain data events (i.e.: changes) for later retrieval. Process

Demonstration

N29


108


VERIFICATION

NEED TRACE

CS-DMG-06.1 The System shall record for future retrieval the occurrence of operations based events including the following:

a. (Info Logging Level) User logon and logout activity, including the following:

i. Logon time; and

ii. Logout time;

b. (Info Logging Level) User Activity details, including, the following:

i. User Interface views accessed;

ii. Start and end time of view access; and

iii. Activities enacted using the view;

c. (Info Logging Level) Traffic Management Strategies implemented details, including the following:

i. User responsible for implementation; and

ii. Start and end time;

d. (Warn Logging Level) Incident Management Strategies implemented details, including the following:

i. User responsible for implementation;

ii. Start and end time;

iii. Operational Alert details, including the following:

1. Alert type;

2. Alert severity;

3. Start and end time;

4. Alert location; and

5. Time Alert transmitted from System via User Interface or External Interfacing System.

Process

Demonstration

N29

CS-DMG-07 The System shall enable a User to modify business rules of the System that govern the behavior of data management and computation processes.

Process

Demonstration

N30

CS-DMG-07.1 Business rules shall include the following: Process N29


109


VERIFICATION

NEED TRACE

a. Road Safety Rules;

b. Alert parameters;

c. Data storage parameters; and

d. Data logging parameters.

Demonstration

CS-DMG-07.1.1 Road operations safety rules shall include the following:

a. Determined parameters;

b. Algorithms; and

c. Computation triggers.

Process

Demonstration

N29

CS-DMG-07.1.2 Alert parameters shall include the following:

a. Alert algorithms;

b. Alert thresholds; and

c. Alert triggers.

Process

Demonstration

N29

CS-DMG-07.1.3 Data storage parameters shall include the following:

a. Storage triggers

Process

Demonstration

N29

CS-DMG-07.1.4 Data logging parameters shall include the following:

a. Logging triggers

Process

Demonstration

N29


110

1.8.2 User Interface Management

1.8.2.1 Overview of RBMS User Interfaces

RBMS Users require purposeful, powerful, and easy-to-use interfaces that enable them to understand and execute their duties in a timely and effective way. User Interfaces are distinct from External Interfacing Systems (see Section 1.8.4 System Interface Management); they are the tangible machine-human component of RBMS that serves as the information collection and dissemination end-point to the User (Figure 26 below).

Figure 26. User Interfaces High-level Architecture.

As shown in the figure above, User Interfaces will serve a binary role in RBMS data flow; present information contained within the system, and proivide a User with the capability to enter information into the System. For the purpose of this section in the specification, the generalized term User is adopted in the requirements. During the design and implementation phase when the User Model is developed, the design will refine this definition as required.

Users will sense and effect information within the system using the User Interfaces that they are given access to. This section of the specification provides those User Interface system requirements that the RBMS stakeholders have identified will be necessary to realize a UI of high quality and success.

The stakeholders recognize that the final design configuration that fully meets these requirements can only be realized through the design phase of the program. Certain requirements will be implemented in different ways based on Vendor solutions, the User and Operational Model for RBMS, and how different elements of information and User functionality need to relate to each other in an interface to minimize User error. Final design of the UI therefore relies on synthesizing:

• The User Model

• Data Items that Users need to perform their duties

• System Controls that Users need to perform their duties

Live Traffic Store

Live System Store


Static Border Store

Static System StoreUser Interfaces Capture

Distribute

System Alerts Store

Historic Data StoreSystem Operator,

Operations Manager

System Administrator,

System Maintainer

RBMS Users

including(but not limited to)

Effect

Sense


111

• The interfacing environment, legacy and new (e.g.: External Interfacing Systems, locations, physical structures), that the Users and the UI will be placed into

• Customization or bespoke development of a Vendors solution

An output of the design analysis process, the User Model will be a matrix set of tasks, roles and responsibilities against a hierarchy of Users. Through this model levels of access control, security, capability, features and functionality can be codified and controlled in the system.

Figure 27 illustrates how this requirement section, other sections in this specification, and the design process, as described in the OME RBMS Systems Engineering Management Plan (SEMP) connect with the interfacing environment and Vendor solution to produce the necessary set of User Interfaces required for the program.

Figure 27. User Interface Requirements Relationship to Other Requirements Sections.

System

Vendor’s UI Solution

(if applicable)

SE Activity

UI Design and

Development

(c.f. OMEII RBMS SEMP)

UI Solutionrealizes

RBMS UI Requirements

(this section)input

customization

UI SolutionUI SolutionUser Interfaces

(end delivery)

System

Other RBMS Interfaces

(e.g.: legacy systems)

constrains

In/Pr/Out/Perf/Sec

Requirements

(other specification sections)

input


112

Figure 28: RBMS User Interface Management Architecture.

Navigation Business Rules

Capture UI Entered Data

Present UIs

Manage Representations

RBMS User




Static System Store

Live System Store

Historic Data Store

Navigation InputsInteraction InputsModes SelectionsUI Configuration Inputs

Data Items

RBMS User

Navigate UI

Data Items

Populate UIs

Navigation InputsInteraction InputsModes SelectionsUI Configuration Inputs

Navigation Inputs

Navigation Outputs

UI Configurations

Presentation Rules

Presentation Rules

Representation Requests

Populated UIs

Representations

Navigation InputsMode Inputs

Presentation Rules


113

1.8.2.2 Categories of RBMS User Interface

RBMS will have two physical categories of User Interface:

1. Graphical User Interfaces (GUIs) – the principal computer generated interfaces by which Users visually interact and navigate to sense and effect changes in the traffic operations

2. Hardware User Interfaces (HUIs) – the physical devices by which Users interact with the RBMS systems, subdivided into:

a. GUI Application Hardware – hardware utilized by a User to interact with the GUIs, including keyboards, mice, touchscreens, haptic feedback

b. Mechanical Hardware – hardware utilized by a User to interact with the RBMS’ physical elements, including pushbuttons, locks, levers, handles (see the System Administration and Maintenance section for these specific requirements)

Figure 29. Conceptual Convention Adopted in This Specification for User Interface.

Figure 30 illustrates a (low-fidelity) example of a GUI a User could expect to see when managing traffic. This representation is presented as an aid to understand general expectations; how concepts could work together in real presentations to users. The intent is not to guide design, indicate a preferred representation approach, or set expectations of the quality of UI that would be deemed acceptable; SANDAG intends the Supplier to provide a modern and sophisticated UI as part of the RBMS program.

Graphical User

Interface (GUI)

User Interface Element

(1..n)

Data Items

(1..n)

User Interface

Hardware User

Interface (HUI)

is realized by

is composed of

System Controls

(1..n)

containscontains


114

Figure 30. Notional Representation of a Traffic Management User Interface.

Note that the illustrative graphic in the figure above should be considered as representative only, illustrating how the workspace and containing information could be navigated, presented entered. This representation is not intended as requirement, to be a preferred representation approach, or acceptable design quality.

The GUI contains a series of GUI elements; data presentation, and system control features on the display Users observe and interact with in order to perform the tasks necessary as part of their duties. The data and controls can be represented as either formal (i.e.: textual, numeric) or secondary (i.e.: icons, flashing, scrolling) formats. In the example provided, specific GUI elements would include:

• Cartographical map – a geographical representation can be helpful in certain decision-making processes, augmented with secondary information on traffic flow

• Navigation Features – ostensibly standard

• GUI page tabs – shortcuts where a user wants to navigate to multiple pre-defined views, for example a series of focused territories, or on one screen view a map and on another a tabular representation of the same detail, a log, a dashboard

• Contextual help – where a User can access this on the UI as needed to either help with navigating/using the software features themselves, or availing of standard operating procedures to support decision making

Traffic Management Strategy Dialogue

Strategy List

Data Items

Enter text...

Drop Down List

C

Screen 3 Screen 4Screen 1 Screen 2

Notional RBMS UI representation to aid

understanding. NOT to be considered as design

requirements or endorsement of a particular

approach or sufficient to meet Users

expectations and needs

Cameras

Incidents

Flow

Road Work

Layer Menu

Incident Report Dialogue

Incident List

Data Items

Enter text...

Drop Down List

ab c d

e

f

i

g

VMS Dialogue

h

j


115

• Layer Menus – where layers of detail can be toggled off or on, helping a User to filter information of use to them or others

• Traffic Management Strategy Dialogue – where details of a Traffic Management Strategy can be entered, retrieved, accessed, modified, and associated geo-tag on the cartographic map

• Live Video Imagery – overlaid on the cartographic map, this element provides the current feed at the camera icon location selected by the user on the map

• VMS Display – displays the text currently active on the Variable Message Signs (VMS) in the field

• Incident Report Dialogue – displays the details of an Incident to the User, enables them to report and classify details of an Incident, or implement an Incident Response Strategy

• Screen navigation – controls to laterally and vertically move, rotate, and zoom in/out the view

Figure 31. Representative Illustration of the Status of Crossing Lanes (a Static Data Item) at the Border Crossing.

User Interfaces will generally combine multiple types of information into representations with features and capabilities to perform several actions at once. For example, a map of the current status of border traffic may contain the Live Traffic Store information ostensibly overlaying Static Border Store data; the User can zoom to see more granular detail, pan through a geographic map, and annotate certain areas with notes or Incident Reports selected from a drop down menu.

It is imperative the relevant information, features, and capabilities be combined in an easy-to-use format so that Users can make, and implement, the most informed decisions possible to better manage the border region and the System’s health and state-of-good-repair. The design and development phase of the RBMS UI program is imperative to accomplish the best value outcome.

US CBP

1 2 3 4

US CBP US CBP US CBP

X


116

Figure 32. Example of a Performance Dashboard.

1.8.2.3 Specification Overview

The requirements in this section of the RBMS specification cover three areas:

• General Feature Requirements – requirements addressing fundamentals of User Interfaces such as access permissions, read/write-only, information placement on a GUI, information freshness

• General Design Requirements – requirements addressing the characteristic design of the system, it’s goodness in the eyes of the User, supporting the cognitive and decision making processes of Users

• Specific UIs and UI Elements – stakeholder-identified elements of UI considered necessary, including:

o Presentation Formats – forms (i.e.: physical, functional types, arrangements), typically types of User display but also including audible

o Navigation Features – the variety of features that Users will need in order to access and provide information in the System

o Interaction Features – the variety of ways in which Users will act to access or provide information into the System

o Specific UIs and UI Elements – specifically envisioned UIs strongly considered necessarily in the Vendor solution

+18%

Item 1

Item 2

Item 3

Item 4

Item 5

Item 6

High

Med

Med

Low

High

Med

Lorem ipsum dolor sit amet,

consectetur adipiscing elit











+25%

-8% +78%

Incident Log


117

o UI Configuration – capabilities Users will need to have to modify and customize UIs to their needs over time

o UI Access Locations – accessibility of the UIs, either on-site or remote locations

o UI States and Modes – transitions of the UI to/from modes and states in the event of changes

These three primary areas will cover the following:

• Access Permissions. RBMS will be accessed, operated, and modified by its User community in a continuous, ad-hoc/as-needed, and periodic basis as needed. The features and functions each User has in the system needs to conform to, and be managed by a model/representation (i.e.: User Model) that is customized to the operational and maintenance structures and business processes in play in the RBMS community. For example, a traffic operations User should typically not have the ability to modify a configuration file in the system, and vice versa. The User Model will be developed as part of the design process, and will be implemented in terms of access permissions to meet the following requirements.

• Data Population. The information and controls represented in the User Interfaces need to reflect their current status and populated in a timely fashion.

• Static Data Layers and Real-Time Layer Overlays. For the purposes of this specification, collections of Data Items of a particular type (e.g.: Traffic Flow Rate at points across the region, CCTV feeds) in the System are represented as Information Layers, ostensibly data that overlay other Static Data Item representations. One example may be a static cartographic map (Static Data Item) of the border region with dynamic traffic flow-rate data overlaid on top.

• User Interface Layout. As illustrated above, a User Interface will be comprised of User Interface Elements and will include Data Items from the System, either static or dynamic, as well as System Controls of the system. These components of the User Interface may be arranged on a GUI or a HUI in the following ways.

• General Design Principles. Certain User Interface specific requirements are provided in this section.

• User Interfaces and their components including the following:

o Presentation properties

o Presentation formats – Data Items and System Controls will be provided to Users in a variety of presentation formats – those being the ways in which information is arranged and set out on a GUI or HUI. Those form factors may cover physical objects (e.g.: alerts delivered on physical objects such as monitors) or physical services (e.g.: alerts delivered by email or SMS alerts).

o Navigation Features – Users need to be able to navigate (i.e.: access Data Items and System Controls) in the GUI and HUI environments. The System must provide sufficient features for them to access the Data Items and System Controls necessary to fulfill their duties, and provide in a manner that is consistent with the design principles that support a simple and intuitive experience for a User.


118

Navigation of the System is ostensibly a System Control action of the System itself. The features include the following:

o On-demand navigation

o Subscribed navigation

o Interaction features – Users will interact with the System and implement their choices through a variety of context driven features. Principally Users will perform their actions (e.g.: access Data Items, operate System Controls) using their desktop workstation – other physical formats may also be supported.

o User Interface response to System Modes. The System will operate in as-designed configuration profiles (i.e.: operating modes). As a view into that operating configuration, in the User Interface states manifest as different collections of capabilities, features, functions and information items, as well as look-and-feel on the screen based on the profile that is in effect at the time of use. For example, the “Training Mode” UI should be clearly differentiable from the production (normal operation) so that the User and their Supervisor understand the System condition that is in effect. That Training Mode may remove or modify certain capabilities, for example the ability to directly modify VMS in the field. Another example could be a System recovery mode, where only core functionality needed to repair/reboot the System is provided.

For the purpose of this specification, a System Mode is considered a higher order configuration item of the system; a collection of capabilities available potentially to a User, accessible through their User Interface. A System State, either from the perspective of the User (e.g.: operational state such as approach, departure), or from the System, a physical attribute of the System (e.g.: operational, failed, degraded).

The capabilities, features, functions, information items and non-functional aspects of the User Interface representation shall be developed as part of the UI design and development process.

• System Access Locations. Depending on their role and responsibility, Users will need to access the System from a variety of physical locations. The System needs to be able to support their Connection Sessions securely at these locations (see Section 1.8.4: External Interfacing Systems). That access may need to be continuous, or ad-hoc.

• Specific User Interface Designs. As part of the design process, the Supplier will conduct a Human Factors Task Analysis (described in OME RBMS SEMP). As part of that analysis, a User Model will be developed that describes the tasks that need to be fulfilled, and corresponding System capability provided to the particular types of Users of RBMS. For example:

o a System Administrator will need to change configuration settings, inspect and modify a Connection Session with an External Interfacing System

o an Operations Manager will need to monitor the current state of the border’s regional traffic in order to implement any necessary corrections


119

Consequently, User Interfaces must be developed to serve these task activities, and designed in a way that meets the performance expectations those Users have, and which are placed on them.

Elsewhere in this specification, requirements for the traffic monitoring, management, incident management and system lifecycle management (among other capabilities) are provided. These describe those capabilities, function, features, and performance Users need from the System in order to be able to perform their duties. How those are realized in GUI and HUI form are subject to the system design process.

Although the User Interface design is strongly contingent on design activities (e.g.: Human Factors Task Analysis) as well as capabilities and pre-developed products from Suppliers, certain specific User Interfaces (e.g.: Data Items on UIs) and their behaviors are known to be necessary by the Stakeholders and can be defined at this phase in the program. This section describes those specific User Interface that will be required.

• Border Traffic Monitoring and Management. RBMS will provide traffic operations personnel with Data Items and System Controls on a User Interface tailored to activities requiring the monitoring and management of situations in the field. Their primary User Interface will be a GUI that features a static representation of the border region (e.g.: a map, a lane layout) overlaid with Data Items such as Traffic Volumes, ITS field equipment status, and necessary System Controls to navigate the environment and implement actions predicated on their decision processes and response system outside of RBMS (e.g.: communication with peers).

The System shall provide the following Data Items on User Interfaces:

o Traffic Status

o Projected Traffic Status

o Border Crossing Traffic Status (Passenger, Commercial)

o Toll Lane Status

o Road Work Details

o Travel Time

o Toll Data

o KPIs, specifically:

▪ Regional Border Crossing performance

▪ Average speed by road section selected by a User

Users will need to be able to access the traffic management capabilities as described in Section 1.7.3 Border Traffic Management. Traffic Management Strategy (-ies) as described in the section. The details provided in Dialogues should minimize the effort of Users to enter details into the system such that:

o The System shall provide a User with a Traffic Management Strategy Dialogue(s) that enables them to select a Traffic Management Strategy of their choosing from a set of pre-defined Traffic Management Strategies.


120

o The System shall provide a User with a Traffic Management Strategy Dialogue(s) that enables them to customize a Traffic Management Strategy of their choosing from a set of pre-defined Traffic Management Strategies.

o The System shall provide a User with a Traffic Management Strategy Dialogue(s) that enables them to execute the Traffic Management Strategy of their choosing.

o When providing a User with a Traffic Management Strategy Dialogue, the System shall provide dedicated Data Item fields pre-populated with relevant Traffic Management Strategy details

o When providing a User with a Traffic Management Strategy Dialogue, the System shall provide dedicated Data Item fields pre-populated with selectable Traffic Management Strategy details.

• Incident Management. Incident Management is an extension of Traffic Management, RBMS will provide traffic operations personnel with Data Items and System Controls on a User Interface tailored to activities requiring the monitoring and resolution of incidents

The following figure illustrates these elements.


121

Figure 33. Specific UIs and UI elements described in the requirements of the RBMS.

Presentation Formats Navigation Features Interaction FeaturesSpecific UIs and

UI ElementsUI Configuration

UIs and UI Components

Requirements describing

the variety of formats

(types) of UI including:

Physical Form Factors

• Large Scale Display

• Desktop Display

• Tablet

• Cellphone

• Siren/Speaker

• Paper Form

Service Formats

• SMS (Text Message)

• Email

• Instant Message

Composition Forms

• Cartographic (map)

• Schematic

• Tabular

• Graph/Trend-line

• Video Array/Wall

• User Dialogue

• Dashboard

• Document

Notation Forms

• Alphanumeric (A-N)

• A-N Styles

• Iconography

• Graphics/Images

• Shapes

• Video

• Overlays

• Animation

• Overlays

• Pop-up

• Ticker-tape

• Fade In/Out

• Audible Sound

• Lighting Pattern

• Timestamps

Fidelity Formats

• Live

• Historic

• Simulated

• Multi-format


the variety of navigating

features including:

On-Demand Navigation

• Search

• Sort

• Filter

• Open/Close

• Pan

• Rotate

• Zoom

• Minimize/Maximize

• De-clutter

• Hyperlink

• Layer

Subscribed Navigation

• Alert Receipt


the variety of interactive

features including:

Interaction Actions

• Select

• Drag/Drop

• Copy/Paste

• Annotate

• Save

• Undo/Redo

• Print

• Lock/Unlock

• Set Display

Interaction Devices

• Keyboard

• Mouse

• Haptic

• IVR

• Mechanical

• Protection

• Switch

• Button

• Lock

• Key


specific types of User

Interface known to be

necessary at this phase

in the program, including:

Border Traffic

• Traffic Status

• Projected Status

• Crossing Status

• Toll Plaza Operation

• Toll Plaza Traffic

• Road Works Details

• Travel Time

• Tolling Rate

• KPIs

Traffic System Controls

• Traffic Management

Strategy Details

• Balancing Regional

Demand

Incident Management

• Incident Response

Plan Details

• Alerts

• Incident

• Incident History

Instrument Monitoring

and Control

• Video Controls

• VMS Controls

• CCTV Controls

• Specific Overlays

• Field System Logs

• VMS Text Dialogue

• CCTV Controls

• Field System Overlay

• Event Logs/History

Other UIs

• Training UI

• Video Library

• Error Message

• Environmental

• Operations Mgmt

• System Administrator

• Management Reports

• Cable Television

• Date/Time

Refer to section X.Y of

the specification for

requirements describing

the variety of

configuration items and

features including:

• UI Edit

• Access Privileges

• Remote Access

• Edit Privileges

• Display Configuration

• Subscription Config.

• Display Privileges

• Language Select

Access Locations


the accessibility of UIs

including:

Internal Site

• TMC/SBX Facility

• Mexico TMC

• Sandag TMC

• Sandag HQ

• CHP Watch Cmd

• CHP CVEF Primary

External Site

• Vendor Facility

• Public Location

UI States and Modes


the operating modes of

the User Interface and

system response from a

UI perspective to faults

or failures, including:

• Normal Operation

• Tailored Capability

• Failure

• Traffic Operations

• Security Blackout

• Administrator

• Training


122

1.8.2.4 User Interface Management Requirements

Note that requirement CS-UIF-04 in this section references guidelines.usability.gov.


VERIFICATION

NEED TRACE

CS-UIF-01 The System shall support User Account Properties. Security

Demonstration

N31

CS-UIF-01.1 The System shall provide those Data Items to a User via a User Interface permitted in the User’s User Account Properties.

Output

Demonstration

N31

CS-UIF-01.2 The System shall capture Data Items from a User via a User Interface authorized method based on the User’s User Account Properties.

Input

Demonstration

N31

CS-UIF-01.3 The System shall provide User Interface elements in a User Interface authorized method based on the User’s User Account Properties.

Security

Demonstration

N31

CS-UIF-01.3.1 The System shall provide User Interface Controls in a User Interface authorized method based on the User’s User Account Properties.

Output

Demonstration

N31

CS-UIF-01.3.2 The System shall restrict a User’s User Interface interaction by approved physical means including the following:

a. Software protections (e.g.: password, biometrics); and

b. Hardware protections (e.g.: key locks, button screens, touchscreen disabling).

Security

Demonstration

N31

CS-UIF-01.3.3 The System shall populate User Interface views automatically with Data Items relevant to that User Interface view based on User Account Properties.

Constraint

Demonstration

N31

CS-UIF-01.3.4 The System shall populate User Interface Views automatically with User Interface elements relevant to that User Interface view based on User Account Properties.

Constraint

Demonstration

N31

https://guidelines.usability.gov/


123


VERIFICATION

NEED TRACE

CS-UIF-01.3.5 The System shall populate User Interface elements automatically with Data Items relevant to that User Interface element based on User Account Properties.

Constraint

Demonstration

N31

CS-UIF-02 The System shall update Data Items in the User Interface. Output

Demonstration

N32

CS-UIF-02.1 When a Data Item is updated in the System, the System shall update that Data Item representation in the User Interface.

Output

Demonstration

N32

CS-UIF-02.1.1 The System shall update the User Interface for a specific Data Item within one second. Performance

Demonstration

N32

CS-UIF-02.1.2 When a User navigates through a representation of Data Items (e.g.: a geographical map with roads, icons, scrolls through a table etc.), the System shall update the Data Items presented to a User.

Output

Demonstration

N32

CS-UIF-02.1.3 When a User navigates through a representation of Data Items (e.g.: a geographical map with roads, icons, scrolls through a table etc.), the System shall update the representation presented to a User.

Output

Demonstration

N32

CS-UIF-02.2 The System shall provide Static Data Items in User Interfaces. Output

Demonstration

N32

CS-UIF-02.3 The System shall provide Dynamic Data Items in User Interfaces. Output

Demonstration

N32

CS-UIF-02.3.1 The System shall display Dynamic Data Items in conjunction with Static Data Items automatically in pre-configured User Interfaces.

Output

Demonstration

N32


124


VERIFICATION

NEED TRACE

CS-UIF-02.3.2 When requested by a User, the System shall display Dynamic Data Items in conjunction with Static Data Items on User Interfaces.

Output

Demonstration

N32

CS-UIF-03 The System shall provide the capability to present multiple User Interface views. Process

Demonstration

N32

CS-UIF-03.1 The System shall provide the capability to present multiple User Interface elements in one User Interface.

Process

Demonstration

N32

CS-UIF-03.1.1 The System’s User Interfaces shall position User Interface elements on the User Interface in a manner that maximizes the Users perceptual capabilities, subject to analysis as part of the design process as described in the OME RBMS SEMP.

Performance

Analysis

N32

CS-UIF-03.2 The System shall provide the capability to present multiple Data Items in one User Interface.

Output

Demonstration

N32

CS-UIF-03.2.1 The System’s User Interfaces will position Data Items on the User Interface in a manner that maximizes the Users perceptual capabilities.

Security

Analysis

N34

CS-UIF-03.2.1.1

The Data Items User Interface perceptual capabilities shall conform to the guidelines defined in ISO 9241 series 100-300 (software ergonomics, human system interaction processes, displays and display related hardware).

Security

Analysis

N34

CS-UIF-04 The System’s User Interface shall utilize a design aesthetic (including aesthetic realism) consistent with today’s Users’ expectations of a modern competitive IT solution, subject to analysis and approval as part of the design process, following the federal guidelines outlined by the U.S. Department of Health and Human Services.

Performance

Analysis

N34

CS-UIF-04.1 The System shall use User Interfaces designed to minimize the number of actions a User must take in a User Interface to accomplish an operational task error-free.

Process

Demonstration

N34


125


VERIFICATION

NEED TRACE

CS-UIF-04.2 The System shall use GUIs designed to be unambiguously interpretable to people of color-blindness.

Security

Demonstration

N34

CS-UIF-04.3 The System shall use HUIs designed to be operated effectively by persons of either handedness.

Performance

Demonstration

N34

CS-UIF-04.3.1 The RBMS Graphical User Interface shall support the reversal of left/right mouse buttons for left handed individuals.

Performance

Demonstration

N34

CS-UIF-04.3.2 The RBMS Graphical User Interface shall support reasonable horizontal repositioning of menus and forms to accommodate left handed individuals.

Performance

Demonstration

N34

CS-UIF-04.4 The System shall ensure that latency in User Interface response does not exceed 100ms. Constraint

Demonstration

N34

CS-UIF-05 The System User Interfaces shall translate/convert both United States English [ref-1] and Español [ref-2] for communication to Users.

[ref-1] ISO 639.1 Eng

[ref-2] ISO 639.2 Spa

Performance

Demonstration

N33

CS-UIF-05.1 The System User Interfaces shall use United States English as the primary language for communication to Users where entire words are used or displayed. Other dialects (e.g.: U.K. English) will not be accepted.

Performance

Demonstration

N33

CS_UIF-05.1.1 The System User Interfaces may use United States English and/or symbols to provide IDs, abbreviations, and/or labels.

Performance Demonstration

N33


126


VERIFICATION

NEED TRACE

CS-UIF-05.2 The System User Interfaces shall use Spanish as the secondary language for communication to Users where entire words are used or displayed.

Performance

Demonstration

N33

CS-UIF-05.2.1 The System shall translate the secondary language entries into the primary language for data storage.

Input

Demonstration

N33

CS-UIF-05.3 The System shall display only the primary or secondary language at one time on User Interfaces.

Output

Demonstration

N33

CS-UIF-05.4 The System shall accept User entered Data Items (e.g.: free text) in the primary or secondary language.

Output

Demonstration

N33

CS-UIF-05.5 The System shall translate User entered Data Items from the secondary to primary language.

Input

Demonstration

N33

CS-UIF-05.6 The System shall store User entered Data Items in the primary language. Input

Demonstration

N33

CS-UIF-06 The System shall display words that are deemed misspelled when compared with a System Dictionary.

Output

Demonstration

N33

CS-UIF-06.1 The System shall display words that are not Permitted Words. Output

Demonstration

N33

CS-UIF-07 The System shall utilize Graphical User Interfaces (GUIs). Process

Demonstration

N32

CS-UIF-07.1 The System shall provide GUIs with a graphical resolution sufficient for the Users perceptual (i.e.: decision making) capabilities, subject to analysis as part of the design process as defined by standards in ISO 9241 series 100-300.

Output

Analysis

N32


127


VERIFICATION

NEED TRACE

CS-UIF-07.2 The System shall provide GUIs with a graphical color properties sufficient for the Users perceptual (i.e.: decision making) capabilities, subject to analysis as part of the design process as described in the OME RBMS SEMP.

Output

Analysis

N32

CS-UIF-07.3 The System shall provide GUIs with a graphical brightness sufficient for the Users perceptual (i.e.: decision making) capabilities, subject to analysis as part of the design process as described in the OME RBMS SEMP.

Output

Analysis

N32

CS-UIF-08 When providing haptic feedback on User Interfaces, the System shall provide a vibration(s) of type sufficient for the Users perceptual (i.e.: decision making) capabilities, subject to analysis as part of the design process as described in the OME RBMS SEMP.

Output

Analysis

N35

CS-UIF-09 When providing audible feedback on User Interfaces, the System shall provide a sound(s) of type sufficient for the Users perceptual (i.e.: decision making) capabilities, subject to analysis as part of the design process as defined by standards in ISO 9241 series 100-300.

Output

Analysis

N35

CS-UIF-09.1 Those sound(s) type capabilities shall be subject to analysis as part of the design process, as described in the OME RBMS SEMP.

Output

Analysis

N35

CS-UIF-09.2 The System shall provide different sounds for categories of Alerts of type sufficient for the Users perceptual (i.e.: decision making) capabilities, subject to analysis as part of the design process as described in ISO 9241 series 100-300.

Output

Analysis

N35

CS-UIF-010 The System shall provide physical form factors. Process

Demonstration

N35


128


VERIFICATION

NEED TRACE

CS-UIF-010.1 The System shall provide information to a User in a physical form factor of type including the following:

a. Large-scale display, ostensibly deployed in control room(s) displaying information on a large-scale for team review and decision making;

b. Desktop workstation; includes physical devices such as GUI display, keyboard, mouse;

c. Tablet, portable computing device;

d. Cell phone, smartphone devices via a platform agnostic, mobile web interface;

e. Siren/Speaker, audible Alerts, codified by Alert type;

f. Electric light (e.g.: light emitting diode [LED]);

g. Paper document, documents printable from the system; and

h. Clock, a common frame of reference (network time) with resolution at the second level.

Physical

Inspection

N35

CS-UIF-010.2 The System shall format the User Interface so as to be correctly rendered in the physical form factor.

Process

Test

N35

CS-UIF-010.3 When required, the System shall render the User Interface in multiple form factors within 1 second.

Performance

Test

N35

CS-UIF-011 The System shall provide service formats. Process

Demonstration

N35

CS-UIF-011.1 The System shall format the User Interface so as to be correctly rendered in the service form factor.

Output

Test

N35

CS-UIF-011.2 When required, the System shall render the User Interface in Multiple service formats within 1 second.

Performance

Test

N35


129


VERIFICATION

NEED TRACE

CS-UIF-011.3 The System shall provide information to a User in a service format of type including the following:

a. Short Message Service (SMS), text messages, principally employed for Alert notification;

b. Electronic mail (email); and

c. Instant Message (IM), messaging client capability between authorized Users active in the System.

Output

Demonstration

N35

CS-UIF-011.3.1

The System shall provide an SMS-based message service capability. Physical

Test

N35

CS-UIF-011.3.1.1

The System shall provide a User with the capability to compose and send an SMS message to a User.

Input

Demonstration

N35

CS-UIF-011.3.1.2

When a pre-configured Alert takes place, the System shall provide a User with an SMS message.

Output

Demonstration

N35

CS-UIF-011.3.2

The System shall provide an email-based message service capability. Physical

Test

N35

CS-UIF-011.3.2.1

When requested by a User, the System shall provide a User (or group of Users) with an email message.

Output

Demonstration

N35

CS-UIF-011.3.2.2

When a pre-configured Alert takes place, the System shall provide a User with an email message.

Output

Demonstration

N35

CS-UIF-011.3.3

The System shall provide an IM-based message service capability. Physical

Demonstration

N35

CS-UIF-011.3.3.1

The IM capability shall enable a User to send messages to a User defined individual User. Input

Demonstration

N35


130


VERIFICATION

NEED TRACE

CS-UIF-011.3.3.2

The IM capability shall enable a User to send messages to User defined groups of Users. Input

Demonstration

N35

CS-UIF-011.3.3.3

When a pre-configured Alert takes place, the System shall provide a User with an IM message.

Output

Demonstration

N35

CS-UIF-011.4 The System shall display User Interfaces to a User. Output

Test

N35

CS-UIF-011.4.1

The System shall display User Interfaces to a User in a cartographic; physically proportioned map of the border region containing features such as the road topology, locations of notable facilities, and local and regional services (e.g.: customs, police, fire).

Output

Test

N35

CS-UIF-011.4.2

The System shall display User Interfaces to a User using Schematics; diagram, symbolic and simplified of key lane patterns and structures, for example the border cross.

Output

Test

N35

CS-UIF-011.4.3

The System shall display User Interfaces to a User using Tabular; Data Items arranged by category in rows, columns, cells on a grid.

Output

Test

N35

CS-UIF-011.4.4

The System shall display User Interfaces to a User using graph-/trend-lines; Data Items that trend over time or have a useful relative relationship to one another can be usefully arranged in a chart.

Output

Test

N35

CS-UIF-011.4.5

The System shall display User Interfaces to a User using a video array; panels of multiple live video streams, where multiple locations can be monitored by personnel simultaneously.

Output

Test

N35

CS-UIF-011.4.6

The System shall display User Interfaces to a User using a User Controls Dialogue; a portal where a User receives Data Items and can operate System controls.

Output

Test

N35

CS-UIF-011.4.7

The System shall display User Interfaces to a User using a Dashboard; a simplified panel containing Data Items in a variety of style formats (e.g.: graphs, tables, video).

Output

Test

N35


131


VERIFICATION

NEED TRACE

CS-UIF-011.4.8

The System shall display User Interfaces to a User using Documents; Data Items may be assembled into reports for either view on-screen or to print.

Output

Test

N35

CS-UIF-011.4.9

When required, the System shall display a User Interface element using multiple formats simultaneously.

Physical

Demonstration

N35

CS-UIF-011.4.9.1

The Systems shall display User Interface element formats to be correctly rendered in the physical form factor.

Process

Demonstration

N35

CS-UIF-012 The System shall provide composition forms. Process

Demonstration

N35

CS-UIF-012.1 When required, the System shall format System data for presentation in a Notation Format.

Process

Demonstration

N35

CS-UIF-012.1.1

The System shall provide information to a User in a notation format of types including the following:

a. Alphanumeric (formal words and numbers including date/time);

b. Alphanumeric styles (secondary information, e.g.: underlining, bold, italic, font, punctuation);

c. Iconography (icons to represent Data Items and System Controls in the User Interfaces);

d. Graphics/Images (static color and grayscale figures, line color, borders);

e. Shapes; these may often be rectangular, but different shapes could be utilized to denote secondary information for example;

f. Video; imagery from CCTV systems, for example, with frame rates (e.g.: 60Hz) contingent on the capabilities of the device and System settings;

g. Overlays; Data Item and System control layer representations (e.g.: CCTV locations layer);

h. Animation; moving images over time, sub-types could include:

Physical

Analysis

N35


132


VERIFICATION

NEED TRACE

i. Pop-up Elements; User Interface Elements that appear or disappear on a GUI;

ii. Ticker-tape; a linear animation of Data Items, typically in alphanumeric format;

iii. Fade In/Out;

iv. Audible Sound; patterns in frequency, amplitude, and duty-cycle (i.e.: continuous or bleep); and

v. Lighting pattern; patterns in color, arrangement, intensity, and duty-cycle; and

i. Timestamps; the time at which the information being provided was created, last modified.

CS-UIF-012.2 When presenting video format information, the System shall provide the information to a User in a manner faithful of the resolution of the captured and compressed data transmitted to the System.

Output

Test

N35

CS-UIF-013 When required, the System shall provide System data for presentation in a playback mode. Process

Demonstration

N35

CS-UIF-013.1 The System shall provide information to a User in playback mode. Output

Demonstration

N35

CS-UIF-013.1.1

The System shall provide information to a User in the form of a live; real-time picture of the traffic or system status

Output

Demonstration

N35

CS-UIF-013.1.2

The System shall provide information to a User in historic form; through recorded information.

Output

Demonstration

N35

CS-UIF-013.1.3

The System shall provide information to a User in simulated projections of the status of Data Items in the future.

Output

Demonstration

N35


133


VERIFICATION

NEED TRACE

CS-UIF-013.1.4

The System shall provide information to a User in multi-format; through simultaneous co-location of live, historic, and Simulated Data on the same User Interfaces.

Output

Demonstration

N35

CS-UIF-013.2 The System shall distinguish playback modes from each other when presenting to Users. Output

Demonstration

N35

CS-UIF-014 When required, the System shall format System data for presentation in multiple information style formats simultaneously.

Process

Demonstration

N35

CS-UIF-014.1 The System shall provide simultaneous information within 500 ms of each other where separate display screens or dialogues are used.

Constraint Test

N35

CS-UIF-015 The System shall support on-demand navigation. Process

Demonstration

N34


134


VERIFICATION

NEED TRACE

CS-UIF-015.1 The System shall provide a User with the capability to navigate a User Interface as applicable to the form factor in the final design including the following:

a. Search – tool(s) to find specific Data Items or System Controls;

b. Sort – to arrange and organize information in a User Interface;

c. Filter – to remove Data Items or System Controls in order to reveal a target sub-set;

d. Open/Close – to access information files from different parts of the System;

e. Pan – to adjust the presented scene in a horizontal or vertical direction;

f. Rotate – to adjust the presented scene in a circular direction (clockwise or counter-clockwise);

g. Zoom – to smoothly change the degree of detail in a representation (e.g.: geographic zoom in/out);

h. Minimize/Maximize – modifying the proportion a User Interface or User Interface element fills the screen;

i. De-clutter – by re-arranging and/or removing Data Items and System Controls from the User Interface;

j. Hyperlink – a shortcut to navigate, be transported, from one representation to another; and

k. Layer – to add and remove layers of Data Items or System Controls.

Input

Demonstration

N35

CS-UIF-015.2 The System shall permit the User to modify Navigation Features in the representation in ways that are permitted in their User Account Properties.

Constraint

Demonstration

N35

CS-UIF-015.3 When required, the System shall format System data for presentation based on an on-demand navigation action.

Process

Demonstration

N35

CS-UIF-016 The System shall support the ability of Users to subscribe to a System Alert. Process

Demonstration

N35


135


VERIFICATION

NEED TRACE

CS-UIF-016.1 When configured by the User Interface, the System shall provide a User with the capability to receive System Alerts and a System Alert receipt.

Input

Test

N35

CS-UIF-017 The System shall support interaction actions. Process

Test

N35

CS-UIF-017.1 The System shall provide a User with the capability to perform interaction actions in the User Interface, including the following:

a. Select – may be implemented in a variety of ways as needed, such as highlighting text, selecting an object, checking a box or a radio button;

b. Drag/Drop – where a Data Item or System Control can be moved from one User Interface or User Interface element into another;

c. Copy/Paste – transference of Data Items (typically text);

d. Annotate – adding notes or labels to existing Data Items or System Controls;

e. Save – to retain information for later retrieval/navigation;

f. Undo/Redo – backing-out or reapplying modifications to Data Items or System Controls that were applied by the User;

g. Print – sending an item to a printer for physical production;

h. Lock/Unlock – physically securing or un-securing an element of the System; and

i. Set Display – turn on or off lighting that is a component of a User Interface, for example desktop display, large scale display brightness.

Process

Test

N35

CS-UIF-018 The System shall support interaction devices. Input

Demonstration

N35

CS-UIF-018.1 The System shall enable a User to interact with the System using a variety of interaction devices including the following:

a. Keyboard – keyboards will be of QUERTY standard – necessary specialized keyboards will be provided by the Supplier through the design phase, subject to approvals by the Engineer;

Input

Demonstration

N36


136


VERIFICATION

NEED TRACE

b. Mouse – two button with roll-wheel will be standard; necessary specialized mice will be provided by the Supplier through the design phase, subject to approvals by the Engineer;

c. Text-to-speech – the System will translate text-to-speech as necessary;

d. Mechanical components;

e. Mechanical Protection – mechanical or physical protections may be necessary to prevent accidental or unintended activation of a button or switch e.g.: sliding spring panels, lids over buttons;

f. Switch – force necessary to activate, shape, size, color, subject to approval by the Engineer;

g. Button – force necessary to activate, shape, size, color, subject to approval by the Engineer;

h. Lock – lock type (e.g.: mechanical keys, biometrics) subject to approval by the Engineer; and

i. Key – mechanical keys, size and complexity are subject to approval by the Engineer.

CS-UIF-018.2 The System may enable a User to interact with the System using:

a. Haptic touchscreen – responsiveness will be subject to approvals by the Engineer and will be subject to environmental testing (e.g.: effects of moisture on the screen).

Input

Demonstration

N36

CS-UIF-019 The System shall support User Interface access to System and operational modes. Output

Demonstration

N31

CS-UIF-019.1 The System shall distinguish clearly on a User Interface when the System is actively in Normal Operations State; the default configuration of the System within its engineered tolerances.

Output

Demonstration

N31


137


VERIFICATION

NEED TRACE

CS-UIF-019.1.1

The System shall distinguish clearly on a User Interface when the System is actively in Failure State; an exception to the default configuration where the System User Interface is modified to prevent further failures and provide capability to a User to restore service.

Output

Demonstration

N31

CS-UIF-019.2 The System shall distinguish clearly on a User Interface when the system is actively in the following Operational Mode: Traffic Operations Mode; the primary mission operations mode of the System, to enable Users to manage traffic in the border region.

Output

Demonstration

N31

CS-UIF-019.2.1

The System shall distinguish clearly on a User Interface when the system is actively in the following Operational Mode: Security Blackout Mode; a special security-related mode where Data Items and System Controls are removed in order meet privacy or security requirements of regional stakeholders (e.g.: United States Customs and Border Control).

Output

Demonstration

N31

CS-UIF-019.2.2

The System shall distinguish clearly on a User Interface when the system is actively in the following Operational Mode: Administrator Mode; a mode of System operation where System Administrators and Maintainers have access to features that Operational Users do not, e.g.: System configuration files, parameter control

Output

Demonstration

N31

CS-UIF-019.2.3

The System shall distinguish clearly on a User Interface when the system is actively in the following Operational Mode: Training Mode; a mode of operation with a similar look-and-feel to the Traffic Operations Mode but used to train operational Users in an environment that will not result in any modifications or action being committed in the primary operational System.

Output

Demonstration

N31

CS-UIF-019.3 The System shall describe to a User when a transition between modes takes place. Output

Demonstration

N35

CS-UIF-020 The System shall support different User Interfaces based on User location. Physical

Demonstration

N31


138


VERIFICATION

NEED TRACE

CS-UIF-020.1 In addition to access, Users shall establish specific User Interface needs based on their location, including the following:

a. SBX Facility;

b. MEX Traffic Management Center;

c. SANDAG Traffic Management Center;

d. SANDAG Headquarters;

e. California Highway Patrol Watch Command;

f. CHP CVEF Primary;

g. Caltrans/CHP Transportation Management Center;

h. Vendor Facility; and

i. Public Location.

Physical

Demonstration

N31

CS-UIF-020.2 The System shall enable a User to securely access a User Account within the System’s secured network via both internal and external sites.

Process

Demonstration

N31

CS-UIF-020.2.1

The System shall enable a User to securely access a User Account within the System’s secured network at internal sites.

Physical

Demonstration

N31

CS-UIF-020.2.1.1

The System shall enable a User to securely access a User Account within the System’s secured network at the SBX Facility; in the operating center, the redundant backup center, and facility offices.

Physical

Demonstration

N31

CS-UIF-020.2.1.2

The System shall enable a User to securely access a User Account within the System’s secured network at the MEX Traffic Management Center.

Physical

Demonstration

N31

CS-UIF-020.2.1.3

The System shall enable a User to securely access a User Account within the System’s secured network at the SANDAG Traffic Management Center.

Physical

Demonstration

N31

CS-UIF-020.2.1.4

The System shall enable a User to securely access a User Account within the System’s secured network at the SANDAG Headquarters.

Physical

Demonstration

N31


139


VERIFICATION

NEED TRACE

CS-UIF-020.2.1.5

The System shall enable a User to securely access a User Account within the System’s secured network at the California Highway Patrol Watch Command.

Physical

Demonstration

N31

CS-UIF-020.2.1.6

The System shall enable a User to securely access a User Account within the System’s secured network at the CHP CVEF Primary.

Physical

Demonstration

N31

CS-UIF-020.2.1.7

The System shall enable a User to securely access a User Account within the System’s secured network at the Caltrans/CHP Transportation Management Center.

Physical

Demonstration

N31

CS-UIF-020.2.2

The System shall enable a User to securely access a User Account within the System’s secured network at external sites including the following:

a. Vendor Facility; and

b. Public Location.

Performance

Demonstration

N31

CS-UIF-020.2.3

The System shall recognize when a User is accessing the User Account from an internal site or external site.

Physical

Demonstration

N31

CS-UIF-020.2.3.1

When a User accesses a User Account from an external Site, the System shall restrict the access to capabilities, features, and Data Items during that User Session.

Output

Test

N31

CS-UIF-021 The System shall provide Users with Traffic Management System Controls. Performance

Demonstration

N34

CS-UIF-021.1 The System shall provide a User with a Traffic Management Strategy Dialogue(s) that enables them to execute the Traffic Management Strategy of their choosing.

Input

Demonstration

N34

CS-UIF-021.1.1 The System shall provide a User with a Traffic Management Strategy Dialogue(s) that enable(s) them to select a Traffic Management Strategy of their choosing from a set of user configurable, pre-defined Traffic Management Strategies.

Input

Demonstration

N34


140


VERIFICATION

NEED TRACE

CS-UIF-021.1.2 The System shall provide a User with a Traffic Management Strategy Dialogue(s) that enable(s) them to customize a Traffic Management Strategy of their choosing from a set of pre-defined Traffic Management Strategies including all items defined in CS-TMG-01.4.

Input

Demonstration

N34

CS-UIF-021.1.3 When providing a User with a Traffic Management Strategy Dialogue, the System shall provide dedicated Data Item fields pre-populated with relevant Traffic Management Strategy Details, including the following:

a. Detection and confirmation;

b. Incident Management;

c. Travel Advisory; and

d. Congestion management.

Input

Demonstration

N34

CS-UIF-022 The System shall display projecting Border Crossing demand regionally. Process

Demonstration

N34

CS-UIF-022.1 The System shall display balancing Border Crossing demand regionally. Process

Demonstration

N34

CS-UIF-022.2 The System shall provide a User Interface that contains regional information. Output

Demonstration

N32

CS-UIF-022.2.1 The System shall provide a User Interface that contains Regional Border Performance Metrics.

Output

Demonstration

N32

CS-UIF-022.2.1.1

The Regional Border Performance Metrics shall enable Users to monitor the performance of the region against regional performance targets.

Output

Demonstration

N32

CS-UIF-022.2.2 The System shall provide a User Interface that contains Regional Traffic Management Projection.

Output

Demonstration

N32


141


VERIFICATION

NEED TRACE

CS-UIF-022.2.2.3

The Regional Traffic Management Projection shall enable Users to see projections of the regional performance to effect better decision making.

Output

Demonstration

N32

CS-UIF-022.3 The System shall provide the following Data Items on User Interfaces:

a. Traffic Status, including:

i. Border Crossing Traffic Status (Passenger, Commercial);

ii. Toll Plaza Operating Status; and

iii. Toll Plaza Traffic Status (Passenger, Commercial);

b. Road Work Details;

c. Travel Time;

d. Tolling Rate;

e. KPIs, including:

i. Regional Border Crossing performance; and

ii. Average Speed by road section selected by a User.

Output

Demonstration

N32

CS-UIF-022.4 The System shall provide the projected Traffic Status. Output

Demonstration

N32

CS-UIF-023 The System shall provide Users with an interface to manage Incidents. Input

Demonstration

N34

CS-UIF-023.1 The System shall provide the following Data Items on User Interfaces including the following:

a. Incident Details;

b. Incident Management Plan Details;

c. Alerts; and

d. Incident History.

Output

Demonstration

N34

CS-UIF-023.2 The System shall provide a User with an Incident Management Strategy Dialogue(s) that enables them to select an Incident Management Strategy of their choosing.

Output

Demonstration

N34


142


VERIFICATION

NEED TRACE

CS-UIF-023.2.1 The System shall provide a User with an Incident Management Strategy Dialogue(s) that enables them to select an Incident Management Strategy of their choosing from a set of pre-defined Incident Management Strategies.

Input

Analysis

N34

CS-UIF-023.2.2 The System shall provide a User with an Incident Management Strategy Dialogue(s) that enables them to customize an Incident Management Strategy of their choosing from a set of pre-defined Incident Management Strategies including all items defined in CS-TMG-01.4, CS-TMG-05.1 and CS-TMG-05.2.

Input

Demonstration

N34

CS-UIF-023.3 The System shall provide a User with an Incident Management Strategy Dialogue(s) that enables them to execute the Incident Management Strategy of their choosing.

Input

Analysis

N34

CS-UIF-023.3.1 When providing a User with an Incident Management Strategy Dialogue, the System shall provide dedicated Data Item fields pre-populated with relevant Incident Management Details, including the following:

a. Approach Lane Management Sign Response Plan;

b. ATIS Coordination Response Plan;

c. Regional Evacuation Response Plan; and

d. Emergency OME Toll System Coordination Response Plan.

Output

Demonstration

N34


143


VERIFICATION

NEED TRACE

CS-UIF-023.3.2 When providing a User with an Incident Management Strategy Dialogue, the System shall provide dedicated Data Item fields pre-populated with selectable Incident Management Details including the following:

a. Lane closures;

b. Lane vehicle type;

c. Lane direction;

d. Primary approach lane messaging;

e. Lane speeds advisories;

f. Public advisories;

g. VTMS display information;

h. CMS display information; and

i. RBMS User Alerts.

Output

Demonstration

N34

CS-UIF-024 The System shall provide the current date and time at time of presentation on a User Interface.

Output

Demonstration

N34

CS-UIF-024.1 When presenting Historic Data to a User, the System shall provide the date and time the Historic Data refers to.

Output

Demonstration

N34

CS-UIF-024.2 The System shall unambiguously distinguish between current date and time and historic date and time on the representation made to the User.

Output

Demonstration

N34

CS-UIF-025 The System shall provide other User Interfaces and Components, including the following:

a. Training User Interface;

b. Training Scenario Editor;

c. Video Library;

d. Error Message Dialogue;

e. Border Environment;

Physical

Demonstration

N34


144


VERIFICATION

NEED TRACE

f. Operations Management;

g. User Logon/Logoff;

h. Performance Dashboard;

i. Employee Roster;

j. Scheduled;

k. Active;

l. System Administrator;

m. Management Reports;

n. Cable Television; and

o. Date/Time.

CS-UIF-026 The System shall provide other User Interfaces and components for System status, including the following:

a. Device Status;

b. System Status;

c. Health Status; and

d. Connection Session Status.

Process

Demonstration

N34

CS-UIF-027 The System shall provide other User Interfaces and Components for System control, including the following:

a. Training Scenario Controls;

b. Field Lighting Controls; and

c. System Status Control.

Process

Demonstration

N34


145

1.8.3 System Administration

This section covers the following:

• Database Configuration. Users will need to be able to make modifications to the central system "Database Structure" is used in this specification to describe the tables, fields, relationships, views, indexes, packages, procedures, functions, queues, triggers, types, elements, etc., which fully describe the database. The term "Database Schema" was specifically not used due to the number of diffuse meanings propagated by some relational database developers.

• Network Configuration. Configuration of the Network includes the configuration of I/O ports from the perspective of the 7 Layer OSI Model as described by ISO/IEC 7498-1. It is also necessary to configure local internal network ports, VPNs, routers, etc., which are inside the system boundary of the RBMS System.

• Hardware Configuration. Hardware Configuration includes changes/additions to system physical components such as; servers, Displays, Network Interface ports, Processors, Routers, Power Supplies, etc.

• Software Configuration. Software configuration includes changes/additions to system software components within the core platform. An example of this would be the Real Time Operating System for the RBMS Platform.

• Firmware Configuration Management. Firmware configuration includes changes/additions to system firmware components, such as basic input/output system (BIOS) refresh, OEM uploads to components, etc.

• Audit Trail. The ability to modify the system configuration carries with it the burden of tracking each modification and further providing an ability to regress (or “roll back” or "revert") to a previous configuration for diagnostic or forensic investigative needs. It is necessary to know what was changed, where it was changed, when the change occurred, and who authorized or performed the actual change.

• Configuration Management functionality will record a baseline “snapshot” of the installed hardware and software at the completion of each modification (replacement, upgrade or Rollback) along with the What, Where, When and Who information. The collection of these recorded snapshots becomes an “Audit Trail”.

In addition to configuration tracking and regression (Rollback) capabilities, it must be possible to modify or expand the Configuration Management capability itself. This would preferably be accomplished with the application of (or Interface to) external tools, some of which are currently in use at SANDAG.

• Rollback Functionality. Capability to restore the system (or a subsystem of the system) to a previous configuration level (reversion). A complete system backup refers to the capability to restore the system with the assumption that all physical and software items have been replaced. This is known as a "bare metal restoration" and must include all firmware, drivers, OS software, application software and configuration settings to ensure that the system operates as it did at the time of the backup. A partial system restore refers to any subset of the complete system backup, such as a restoration of the application software.


146

• Access Control. In order to be in compliance with SANDAG Security policies, it is necessary that SANDAG has the ability to control access to the System. This includes the ability to define primitive entities such as Roles, Business Rules and Users and then to be able to create Groups of Roles or Users for efficiency of administration. It is further necessary to map each role to system functions (views, reports, User input actions, Editing tools, etc.) to ensure that information and functionality access is compartmentalized and thereby help mitigate (i.e.: isolate) breaches in security. Access Parameters include; User Credentials, Roles, Groups and Territories. An object-oriented approach is typically required to provide maximum flexibility in the final design of the system access schema.

• User Roles and Groups. The Access Schema will define the creation of Roles, groups, zones and territories. It will then be necessary to map (associate) Users to Roles, groups, zones & territories.

• User Credentials. The System User access subsystem must maintain an independent list of Users and credentials for access to the System.

• Diagnostics. Diagnostics is a cornerstone of availability for the system. It is necessary to detect when an anomaly or issue occurs (what happened), understand the expected reason (why or cause) for the issue and then know how to correct the issue. The ability to perform this rapidly will ensure that the system meets its availability targets.

It is further necessary to record events for forensic use in improving the diagnostics functionality. Health monitoring aids in detection of issues and diagnostics messaging allows the system to communicate with users in various roles (i.e.: first response technician or senior administrator) to improve the response time to an issue.

Diagnostic messages also include those notifications suitable for other roles. For example, timely indication of a loss of performance which is “understood and being addressed” is essential in order to minimize the impact to the overall traffic operation. In addition to the listed diagnostics capabilities, it must be possible to modify or expand the diagnostics capability itself. This would preferably be accomplished with the application of (or interface to) external tools, some of which are currently in use at SANDAG. Examples of this would be service proven database management tools or network management tool suites.

Specific capabilities are necessary for analyzing health of Line Replaceable Units (LRUs) such as workstations, switches, displays, etc. It is necessary to quickly diagnose the failed item (triage) to support overall availability goals. It is further necessary to quickly diagnose bench repairable LLRUs in support of overall life cycle maintenance costs. In all cases a root cause must be found for the failure and a corrective action plan documented and executed.

• Performance Monitoring. Performance is intended to refer, in this section, to performance of the System - as opposed to performance of the actual road. Performance Monitoring is closely related to diagnostics in that observed and recorded trends can be used to establish a prediction of a future issue (prognostics), such as a failing network switch or an RTOS “memory leak”. Performance Monitoring is a form of early diagnostics detection.SSRS-OFC-5282


147

• Performance specifications are NOT provided in this section. These measurable numbers will be developed and agreed during the design phase of the program. The requirements in this section provide the functionality to ensure that the agreed performance measurements can be detected by the System.

• In addition to the listed monitoring capabilities, it must be possible to modify or expand the Performance Monitoring capability itself. This would preferably be accomplished with the application of (or interface to) external tools, some of which are currently in use at SANDAG. Diagnostic tools will typically incorporate Performance Monitoring functionality.

o The System shall provide Performance Monitoring.

o The System shall interface with a Performance Monitoring tool suite, subject to approval by the Engineer.

• Simulation and Testing. This section contains the requirements that are applicable to testing functionality. The training and testing system will mimic the functionality, structure and appearance of the production environment without affecting the live system and allow the input interfaces to be controlled manually, automatically (scripted) or connected to a live interface.

The following figure provides an overview of the System Configuration Management architecture.


148

Figure 34: RBMS System Configuration Management Architecture

Capture Publish

Configuration Control

RBMS User




Static System Store

Live System Store

Historic Data Store

Configuration Changes

Data Items

RBMS User

Diagnostics and PerformanceMonitoring

System Status Data

Configuration Status

Configuration Changes

Configuration Control Business Rules

Configuration Business RulesConfiguration Business Rules

Simulation and Testing

Data Items

RBMS Field Devices


Data Items

Data Items

Test Data

Test Results

Test Business Rules

System Performance DataSystem Alerts

RBMS Field Devices


Data Items

Data Items

Configuration ChangesData Items


149

1.8.3.1 System Administration Requirements

The requirements in this section describe capabilities of the system to:

1. Detect and resolve faults, failures, and errors in the System’s operation;

2. Modify its configuration;

3. Test changes in configuration changes; and

4. Maintain audits of the System’s configuration and behavior for future reference.


VERIFICATION

NEED TRACE

CS-ADM-01 The System shall enable Users to administer the System Administration. Process

Analysis

N37

CS-ADM-01.1 System Administration capabilities shall enable Users to maintain the capabilities and characteristics of the System.

Process

Analysis

N37

CS-ADM-01.2 System Administration capabilities shall enable Users to restore the capabilities and characteristics of the System.

Process

Analysis

N37

CS-ADM-01.3 System Administration capabilities shall include the ability to expand the capabilities and characteristics of the System.

Process

Analysis

N37

CS-ADM-02 The System shall provide System Administration capabilities to Users including:

a. Fault Detection & Resolution

b. Configuration Change

c. System Testing

d. System Auditing

Process

Analysis

N37

CS-ADM-02.1 The User fault detection and resolutions capabilities shall include the following:

a. Diagnostic Monitoring – performance, health, and security

Process

Analysis

N37


150


VERIFICATION

NEED TRACE

b. User Reports of System Faults

c. Quarantine, Shutdown, Failover, Reboot and Reversion

d. Troubleshooting Help, e.g.: ‘How-to’ checklists, ‘as-built’ documentation

CS-ADM-02.2 The User configuration change capabilities shall include the following:

a. Hardware Configuration Change

b. Software Configuration Change

c. Firmware Configuration Change

d. Enterprise Application Configuration

i. Business Rules Configuration

e. Configuration Backup

Process

Analysis

N37

CS-ADM-02.3 The System shall provide System Administration capabilities to manage elements of the System’s Architecture.

Process

Test

N38

CS-ADM-02.3.1 The System shall provide System Administration capabilities to manage System instantiations, including:

a. Primary system

b. Secondary system (‘warm’ backup) – identical configuration to primary

c. Test system – identical configuration to primary

Process

Test

N38

CS-ADM-02.3.2 The System shall provide System Administration capabilities to manage software processes, including:

a. Mission system related processes

i. Traffic Monitoring process

ii. Traffic and Incident Management process

iii. System Reporting process

iv. Alerting process

Process

Test

N38


151


VERIFICATION

NEED TRACE

v. Performance Computation process

vi. User Interface process

vii. User Management process

viii. Data Validation processes

ix. Data Storage processes

CS-ADM-02.3.3 The System shall provide System Administration capabilities to manage enabling system related processes, including:

a. Diagnostic Monitoring process

b. Security Monitoring process

c. Configuration Management process

d. Network Management process

e. System Testing process

Process

Test

N38

CS-ADM-02.3.4 The System shall provide System Administration capabilities to manage hardware components, including:

a. Mission system hardware and its firmware

i. User desktop computers and peripherals

ii. Tablet devices

iii. Large scale displays at TMCs

iv. RBMS Field Devices

b. Enabling system hardware and its firmware

i. System servers

ii. Communications hardware

iii. Data warehouse

Process

Test

N38


152


VERIFICATION

NEED TRACE

CS-ADM-03 The System shall provide a diagnostic process to continuously monitor the System, its constituent elements (i.e.: software and hardware), and External Interfacing Systems.

Process

Demonstration

N37

CS-ADM-03.1 The diagnostic process shall continuously monitor the System Performance of the System, its constituent elements (i.e.: software and hardware), and External Interfacing Systems.

Process

Demonstration

N37

CS-ADM-03.2 The System shall provide a User with System Diagnostic Information on User Interfaces. Process

Demonstration

N37

CS-ADM-03.2.1 The System shall provide Diagnostic Information represented in

a. Event log views

b. Dashboard views

Output

Demonstration

N37

CS-ADM-03.2.2 If the System determines that a value in its Diagnostics Information is outside of an expected range defined in the Business Rules, then the System shall provide a User with an Alert.

Output

Demonstration

N37

CS-ADM-03.3 The System shall determine measures of performance of the System’s behavior.

Process

Test

N37

CS-ADM-03.3.1 The System shall determine measures of System usage, including:

a. Processors usage by device, by process, e.g.: percent of the maximum resources available

b. Memory usage by device, by process, e.g.: percent of maximum resources available

Process

Test

N37

CS-ADM-03.3.2 The System shall determine measures of System speed, including:

a. Time to next scheduled maintenance activity (or overdue time if overdue)

b. Trends in processing speed of processes (software) and components (hardware)

Process

Test

N37

CS-ADM-03.3.3 The System shall determine measures of System availability, including:

a. Operational uptime, i.e.: time since last off-line for

Process

Test

N37


153


VERIFICATION

NEED TRACE

b. Trends in process, component availability

CS-ADM-03.3.4 The System shall determine measures of System reliability. Process

Test

N37

CS-ADM-03.3.5 The System shall determine measures of Trends in data output quality from processes, components.

Process

Test

N37

CS-ADM-03.4 The Diagnostic Information provided by the System shall verify the health status of the System by identifying System Events.

Process

Test

N37

CS-ADM-03.4.1 The Diagnostic Information shall verify the health status of the System by identifying System Failures, where a component or process does not behave as expected, i.e.: deviates from its designed behavior

Process

Test

N37

CS-ADM-03.4.2 The Diagnostic Information shall verify the health status of the System by identifying System Faults, where a component, process, or data contains an inherent defect, which may or may not lead to a System Failure if it continues to propagate in the System

Process

Test

N37

CS-ADM-03.4.3 The Diagnostic Information shall verify the health status of the System by identifying System Errors (aka, erroneous states), which are the manifestation of System Faults, where a component, process, or Data Item is in a state that has already or will lead to a System Failure. System Errors are typically coded by type and provide Users and the System with a pre-configured response. They are also typically derived from User interaction with the System, e.g.: password log-on error.

Process

Test

N37

CS-ADM-03.5 The System shall provide a fault report management capability to Users so that they may manage reports of faults, failures, and errors in the System.

Output

Demonstration

N37

CS-ADM-03.5.1 The System shall provide a fault reporting capability to Users so that they may report any issues they have with the System as they occur, with an Alert being immediately registered in the System Alerts Store.

Output

Demonstration

N37

CS-ADM-03.5.2 When a fault report is received by the System, the System shall provide a User with an Alert. Output N37


154


VERIFICATION

NEED TRACE

Demonstration

CS-ADM-03.5.3 The fault management capability shall automatically report faults by

a. fault type

b. fault priority

c. fault status, e.g.: active, intermittent

Process

Test

N37

CS-ADM-03.5.4 The fault management capability shall report faults by User action:

a. fault type

b. fault priority

c. fault status, e.g.: active, intermittent

Process

Test

N37

CS-ADM-03.5.5 The fault management capability shall automatically report the fault’s resolution status, e.g.: ‘pending’, ‘resolved’

Process

Demonstration

N37

CS-ADM-03.5.6 The fault management capability shall report the fault’s resolution status, e.g.: ‘pending’, ‘resolved’, by a User action

Process

Demonstration

N37

CS-ADM-03.6 The diagnostic function shall verify the status of the System’s security at the System’s boundary:

i. By monitoring Connection Session security with System Firewalls

ii. By monitoring the encryption of data traffic with External Interfacing System

iii. By monitoring for intrusion attempts from

1. Masquerader – an actor attempting to impersonate a trusted External Interfacing System

2. Misfeasor – an actor who has gained access through a trusted External Interfacing System

Security

Analysis

N37

CS-ADM-03.6.1 The diagnostic function shall verify the status of the System’s security within the System:

a. By monitoring for software viruses

Security

Analysis

N37


155


VERIFICATION

NEED TRACE

b. By monitoring for Users repeatedly entering erroneous credentials

CS-ADM-03.7 The diagnostic process shall continuously monitor the System, its constituent elements (i.e.: software and hardware), and External Interfacing Systems.

Process

Demonstration

N37

CS-ADM-04 The System shall provide capabilities to manage the effects of unintended system behavior, including:

a. Quarantine data

b. Suspend User account

c. Manage System Operating Status

Process

Test

N37

CS-ADM-04.1 The System shall provide capabilities to Manage System Operating Status to suspend Connection Session with External Interfacing System (see Interface Management section for further details).

Process

Test

N37

CS-ADM-04.2 The System shall provide capabilities to Manage System Operating Status to initiate failover to backup system, hardware element, software process (automatic or on User instruction).

Process

Test

N37

CS-ADM-04.3 The System shall provide capabilities to Manage System Operating Status to restart hardware components, firmware, and software processes.

Process

Test

N37

CS-ADM-04.4 The System shall identify malicious software at various locations within the System, including, the following:

a. Internal to the RBMS applications;

b. Within the Data Stores and any RBMS database;

c. Within the supporting operating systems and applications for RBMS; and

d. Any central system configuration and supporting files.

Process

Analysis

N37

CS-ADM-04.4.1 When identified, the System shall exclude (i.e.: 'quarantine') malicious software from further processing.

Process

Analysis

N37


156


VERIFICATION

NEED TRACE

CS-ADM-04.5 If the System determines that a User has entered incorrect User credentials (i.e.: username, password) incorrectly more than three (3) times, then the System shall suspend the User’s access to their account.

Output

Demonstration

N37

CS-ADM-04.5.1 A User with sufficient privileges shall enable Account access for Users with suspended accounts.

Output

Demonstration

N37

CS-ADM-05 The System shall provide capabilities to manage the System’s operating status automatically

.

Process

Test

N38

CS-ADM-05.1 If the System determines a condition (i.e.: System Fault, Failure, Error) where its ability to process critical mission functions in the primary systems is compromised (e.g.: an abnormal termination of a major process such as Traffic Management), then the System shall automatically transition operations to its secondary instantiation.

Process

Test

N37

CS-ADM-05.2 If the System determines a condition (i.e.: System Fault, Failure, Error) where its ability to process non-critical mission functions in the primary systems is compromised (e.g.: an abnormal termination of a process such as a Connection Session to an RBMS Field Devices), then the System shall restart that specific hardware device or specific software process, in an automated fashion.

Process

Test

N37

CS-ADM-05.3 The System shall provide capabilities to manage the System’s operating status on User command.

Process

Test

N37

CS-ADM-05.4 The System shall enable a User through an RBMS Management Interface to manually:

a. Initiate the transition between alternate instantiations of the System

b. Restart a hardware device or software process

Input

Demonstration

N38

CS-ADM-05.5 The System shall enable a User through an RBMS Management Interface to manually:

a. Suspend or cancel the transition between alternate instantiations of the System

b. Suspend restart a hardware device or software process

Input

Demonstration

N38


157


VERIFICATION

NEED TRACE

CS-ADM-05.6 A User shall determine the System Faults, Failures and Errors that trigger the need for transition between alternate instantiations of the System.

Input

Demonstration

N38

CS-ADM-05.7 A User shall determine the System Faults, Failures and Errors that trigger the need for restarting a hardware device or software process.

Input

Demonstration

N38

CS-ADM-05.8 A redundant backup of the entire central System (i.e.: secondary instantiation) shall manage operation in the event of a primary failure, with no greater than 10 minutes of latency in operational - i.e.: ‘warm standby’.

Constraint

Test

N38

CS-ADM-05.8.1 The System shall ensure data in the primary instantiation of the RBMS Central System is mirrored (i.e.: System data and configuration values replicated) to the secondary on an interval not exceeding 10 minutes, facilitating a ‘warm standby’ configuration.

Process

Test

N38

CS-ADM-05.8.2 The System shall enable a User to initiate the data mirroring process manually. Input

Demonstration

N38

CS-ADM-05.8.3 While the System is transitioning from the primary to secondary System, the System shall transmit instructions Approach Lane VMS and VTMS to maintain their current message configuration.

Output

Demonstration

N38

CS-ADM-05.9 While the System is restarting a process that impacts Approach Lane VMS messaging, the System shall transmit instructions to the Approach Lane VMS and VTMS to maintain their current message configuration.

Output

Demonstration

N38

CS-ADM-06 The System shall provide a User with User information about the System to understand and resolve conditions as they occur.

Output

Demonstration

N38

CS-ADM-06.1 The System shall provide a User with User Information about the System to increase situational awareness

Output

Demonstration

N38

CS-ADM-06.2 The System shall provide a User with User Information about the System to promote issue resolution in real-time.

Output

Demonstration

N38


158


VERIFICATION

NEED TRACE

CS-ADM-06.3 The System shall provide a User with an archive of Standard Operating Procedure (SOP) checklists that explain step-by-step how to resolve faults in the System.

Output

Demonstration

N38

CS-ADM-06.4 The System shall provide a User with an archive of System and System element descriptions so that they may understand the composition of the System in order to address and resolve faults.

a. The system software hardware configuration must be fully documented and available online

b. The system software configuration must be fully documented and available online

c. The system assets deployed to the field must be fully documented and available online

Output

Demonstration

N38

CS-ADM-07 The System shall provide an authorized User with capabilities to change the System’s configuration items over time, including:

a. Upgrading (i.e.: enhancing) existing software and hardware elements

b. Replacing existing software and hardware elements with newer versions

c. Reverting to older versions of software and hardware elements

d. Modifying Business Rules

Process

Test

N38

CS-ADM-07.1 The System shall provide a User with capabilities to modify Business Rules of the mission application, e.g.: updating road-segment configuration

Process

Test

N38

CS-ADM-07.2 The System shall provide a User with capabilities to modify Business Rules of enabling applications, e.g.: creating and updating User accounts.

Process

Test

N38

CS-ADM-07.3 The System shall enable a User to establish configuration changes to System databases. Process

Test

N38

CS-ADM-07.3.1 The System shall accept configuration options that are consistent with Traffic Safety Rules as configured during initial system implementation.

Process

Test

N38


159


VERIFICATION

NEED TRACE

CS-ADM-07.3.2 The System shall accept configuration items in RBMS such as lane availability, directionality, traffic type, barrier devices, allowable speeds, and gates configured by the User in such a way as to ensure safety and consistency.

Process

Test

N38

CS-ADM-07.4 The System shall enable a User to establish configuration changes to the System’s communication network, including:

a. Wide Area Network interfaces

b. Local Area Network interfaces

c. Security and firewall settings

d. Logging level settings

Process

Test

N38

CS-ADM-07.5 The System shall enable a User to establish configuration changes to the System’s display devices (e.g.: desktop computers, video wall, etc.), including:

a. Desktop configuration

b. Video Wall templates

c. Default and startup settings

Process

Test

N38

CS-ADM-07.6 The System shall enable a User to establish configuration changes to the System’s operating system.

Process

Test

N38

CS-ADM-07.6.1 Changes shall include

Software patches, e.g.: security patch

Process

Test

N38

CS-ADM-07.7 The System shall enable a System Administrator to establish configuration changes to the System’s enterprise application.

Process

Test

N38

CS-ADM-07.7.1 The System shall enable a User to establish updates to Traffic Monitoring functionality, including:

a. Adding/removing data sources, e.g.: new PVTD Station installed in the field

Process

Test

N38


160


VERIFICATION

NEED TRACE

CS-ADM-07.7.2 The System shall enable a User to manage updates to Traffic Management functionality, including:

a. Modifying the configuration of lane segments on which automated Traffic Management is determined

b. Adding new types of Traffic Management Strategy (e.g.: Queue Warning)

Process

Test

N38

CS-ADM-07.7.3 The System shall enable a User to manage updates to data analysis functionality, including:

a. Modifying the configuration of lane segments on which traffic performance is determined

b. Adding/removing new measures of performance to be made available in System reports and on User Interfaces

Process

Test

N38

CS-ADM-07.7.4 The System shall enable a User to manage updates to Alerting functionality, including:

a. Modifying the configuration of lane segments on which Alerts are determined

b. Adding/removing new types of Alerts to determine

Process

Test

N38

CS-ADM-07.7.5 The System shall enable a User to manage updates to a User’s credentials, including:

a. Creating a new User account

b. Resetting a User’s password

c. Setting their position in a hierarchy of User permission levels

d. Restricting their capability to access System functions, e.g.: can view CCTV images, but cannot actively manage traffic (e.g.: reverse Lane Direction)

Security

Demonstration

N38

CS-ADM-07.7.5.1

The System shall ensure that a strong password is required from a User to access their User account and will be subject to approval during the System design.

Security

Demonstration

N38

CS-ADM-07.8 The System shall enable a User to manage updates to User Interface functionality, including:

a. Updating existing or adding new icons

b. Modifying the display of Alerts on the UI

Process

Demonstration

N38


161


VERIFICATION

NEED TRACE

CS-ADM-07.9 The System shall provide capabilities to retain records of its configuration for future rollback as necessary.

Process

Analysis

N41

CS-ADM-07.10 When requested by a User, the System shall transition to a prior configuration of a System element.

Process

Test

N41

CS-ADM-07.11 If a change to a configuration item in the System results in contravening the Road Safety Rules at the OME Crossing, then the System shall provide a User with an Alert.

Process

Test

N41

CS-ADM-07.12 The System shall ensure any change in a configuration item would not result in a contravention of Road Safety Rules at the OME Crossing.

Process

Test

N41

CS-ADM-08 The System shall enable a User to test a change to the System’s configuration on a Software Test Facility (STF) prior to putting that change into effect on the Primary System.

Process

Test

N39

CS-ADM-08.1 When performing a test, the System shall use data from the:

a. Live Traffic Store

b. Live System Store

c. Historic Traffic Store

d. Historic System Store

e. Static Border Store

f. Static System Store

Process

Test

N39

CS-ADM-08.2 The STF configuration shall operate independently from the primary and secondary instantiations of the System.

Process

Test

N39

CS-ADM-08.3 The STF configuration shall provide a mirrored view of the primary instantiation of the System.

Process

Test

N39

CS-ADM-08.4 The STF shall provide the capability to mimic the functionality of the production System. Process

Test

N39


162


VERIFICATION

NEED TRACE

CS-ADM-08.5 The STF shall enable a User to select Test Configuration Data to utilize in a System Test. Security Demonstration

N39

CS-ADM-08.6 The STF shall generate reports with information to support verification and validation of software unit under test and verify ready for deployment.

Performance

Demonstration

N39

CS-ADM-08.7 The STF shall enable a User to configure and edit the test system's Test Configuration Data. Process

Test

N39

CS-ADM-08.8 The STF shall store/save/Search/retrieve/reuse Test Configuration Data. Process

Test

N39

CS-ADM-08.9 The STF shall enable a User to edit stored configurations. Process

Test

N39

CS-ADM-08.10 The STF shall enable a User to edit Test Scenarios. Process

Test

N39

CS-ADM-08.11 The STF shall store/save/Search/retrieve/reuse Test Scenarios. Process

Test

N39

CS-ADM-08.12 The System STF shall record test outputs for all test runs. Output

Test

N39

CS-ADM-08.13 The System STF shall record faults/failures/errors/ Alerts discovered during testing. Output

Test

N39

CS-ADM-08.14 The System STF shall generate test reports to include test output for executed tests. Input

Demonstration

N39

CS-ADM-09 The System shall maintain Audit Trails of its operation. Process

Test

N40


163


VERIFICATION

NEED TRACE

CS-ADM-09.1 The System shall maintain an Audit Trail of all adjustments made to the enterprise application.

Process

Test

N40

CS-ADM-09.2 The System shall maintain an Audit Trail of all adjustments made to the System’s hardware configuration.

Process

Test

N40

CS-ADM-09.2.1 The System shall maintain an Audit Trail of all adjustments made to the External Interfacing System hardware configuration.

Process

Test

N40

CS-ADM-09.3 The System shall maintain an Audit Trail of all adjustments made to the operating system configuration.

Process

Test

N40

CS-ADM-09.4 The System shall maintain Event Logs for pre-defined events that occur in the System for later analysis.

Process

Test

N40

CS-ADM-09.5 The System shall enable a User to configure Data Items that are to be recorded in Event Logs and will be defined during the design phase.

Process

Test

N40

CS-ADM-10 The OME System Time shall ensure synchronization with the National Institute of Standards and Technology (NIST) official U.S. time.

Process

Inspection

N38


164

1.8.4 System Interface Management

This section of the specification describes the machine-machine interfacing behaviors of the RBMS. For User-Machine related requirements, please refer to Section 1.8.2 User Interface Management.

The System and its Users rely on Data Items received from interfacing systems to generate a shared view of the traffic and incident management and decision making. RBMS operates in a regional information context where Data Items are exchanged with itself and its External Interfacing Systems. The exchange is bi-directional; RBMS must prepare and transmit data, as well as receive and validate. Interfacing relationships (i.e.: Connection Sessions) between RBMS and those External Interfacing Systems enables a secure and reliable exchange to take place with minimal User intervention on a continuous basis. This section of the specification provides the background descriptions and those necessary requirements of the Central System (i.e.: ostensibly “RBMS”) to perform in the manner Users rely on to receive and provide Data Items predication operational and maintenance actions.

Interface Management has been divided into five requirement sub-sections that address specific aspects of RBMS behavior necessary to fulfill the missions of the RBMS system (Figure 35). The sections address the following RBMS behaviors:

• Configure Interfacing – Users need to be able to set-up and manage the configuration of an interface connection between the Central System and External Interfacing Systems

• Manage Connection Session –Users need the Central System to automatically manage the Connection Session with External Interfacing Systems as well as provide capability to intervene manually to perform connection, re-initiation, and termination actions in the event of a failure or security concern

• Verify and Validate Data Items –when Data Items enter the Central System, Users will need the Central System to verify that the Data Items content and properties arrive within tolerances expected and take appropriate action as necessary.

• Channel Data –Users need the Central System to channel Data Items to and from the correct Data Store as needed

• Tx/Rx Data Items with Specific Systems –requirements governing the relationship to specific External Interfacing Systems and specific system requirements of the Central System to support those specific relationships. This section links the RBMS requirements to Interface Requirement Specification documents – living documents that will define the details of the relationships between RBMS and External Interfacing Systems, including the fully defined set of Data Item as-built, their properties (e.g.: data type – CSV, txt, etc.), exchange methods (e.g.: push/pull), exchange protocols (e.g.: TCP/IP, FTP), failure mode behaviors.


165

Figure 35. Sections of this specification addressing RBMS' behavior and relationship with External Interfacing Systems

Requirements in this section will cover:

Machine-to-Machine Interfaces. RBMS will systemically exchange data with two classes of machine system:

• Inter-RBMS Interfacing Systems –ostensibly RBMS Field Devices; considered part of the RBMS system context, these are sensors and effectors (controlled systems) under the direct supervision and operation of RBMS

• External Interfacing Systems –sources of sensed data (e.g.: regional CCTV imagery) and supplied data (e.g.: border wait times) that exist beyond the RBMS context; these systems are supervised and operated by non-RBMS actors, although may be co-located with RBMS systems

The RBMS shall interface via the Data Hub to share traffic data with the Caltrans District 11 TMC and its existing ATMS software. The C2C Infrastructure will be based on C2C National Transportation Communications for ITS Protocol (NTCIP) and TMDD 3.03c standards and fully supports exchanging status and command between parties. The interface data will be formatted as XML described in Interface Control Documents (ICD) with well-defined XML Schemas

Configure InterfacingManage

Connection Session

Verify and Validate

Data ItemsChannel Data Items

Tx/Rx Data Items with

Specific Systems

Inter-

RBMS

External

Systems

Interface Management(Machine-Machine)

Data Stores

Data Items Data ItemsInterface

Requirement

Specifications (IRS)

(c.f.: Appendix X)

traces to


166

Figure 36. Context Diagram for the RBMS Central System illustrating all the known Interfacing Systems and classifying them (i.e.:inter/external). Also illustrated is the side of the border a system resides, US-only or US-Mexico co-located/duplicated. The interface identifiers (i.e.:IF-XY) referencing the appropriate IRS are also provided.


167

Connection Sessions. Because of the quantity of interfaces and their criticality, Users need RBMS to manage and maintain Connection Sessions between the System and External Interfacing Systems on their behalf. The conditions for establishing, suspending, and re-establishing Connection Sessions are behaviors that Users should have configured within the System (Static System Store) – the operation of the System in line with those parameters is then performed by the System.

On occasion a User may wish to intervene and manage a Connection Session(s) manually, for example if they are troubleshooting a fault or connecting to an External Interfacing System for the first time. RBMS therefore needs to provide an additional manual capability.

Verification and Validation of Data Items. The information received from External Interfacing Systems needs to be evaluated, verified, by the System to ensure its configuration (e.g.: Data Item Properties) meet as-designed criteria defined in the Data Item Configuration Rules. Users need to be notified of the condition where the system detects unexpected Data Items or Data Item Properties, which are therefore suspect for use further in the System. In this condition Users should be provided the capability to INHIBIT the use of such Data within the system.

Channel Data within System. Users need the RBMS to channel Data Items received, or access Data Items to be transmitted to and from the correct repository (i.e.: Store; ostensibly a server/database in the implemented solution) within the System as needed.

User Levels: The following user levels will be defined within the RBMS to manage the privilege and access level of connections. Lower user level numbers correspond to the highest privilege and will encompass RBMS Operators (and potentially the Operators of partner control centers) who have direct access to the RBMS Graphical User Interface. Lower user level numbers correspond to stakeholders of border region partner agencies (e.g.: CHP, CBP and Aduanas) who will generally require read-only access via a thin client interface into RBMS.

1. Level 1 User – Full access & rights to setup new users, control access to all RBMS functions & applications. Note this may be different from the network administrator outside of RBMS.

2. SuperUser – User that has full control of all RBMS functions and devices (including device diagnostics and configuration) outside of setting user permissions.

3. Operations User – Full operational control to RBMS functions and devices – unable to set or change configurations. Ability to take action within the system and log incidents, events, etc. Includes VTMS, CCTV, and notifications control – those elements under RBMS control.

4. View Only User – Ability to view all RBMS data and device feeds and create incident/event notifications – no ability to control notifications or VTMS, CCTV PTZ etc.

5. Fixed View User – Ability to view fixed set of RBMS views and data feeds – without modification or configuration

6. Reports Only User – No operational access to RBMS applications – only to reports or BI Tools – not real time info.


168

Figure 37: RBMS System Interface Management Architecture

RBMS Field Devices


Capture Transmit

Manage Connection SessionVerify Received Data

RBMS User




Static System Store

Live System Store

Historic Data Store

Data Items

Data ItemsHealth Status

Data ItemsHealth Status

Data Items Data Items RBMS Field Devices


RBMS User

Data Items

Data Items

Data Items

Configure Interfacing Rules

Interfacing Business Rules Updates

Interfacing Business Rules

Connection Session Status

Connection Session Instructions


Received Data Items

Data Item Rules

Data Item Approval/Denials

Data Item Approval/Denials


Interfacing Business RulesInterfacing Business Rules


169

1.8.4.1 System Interface Management Requirements

The following table identifies the system Interface management requirements.


VERIFICATION

NEED TRACE

CS-IFS-01 The System shall provide Connection Session configuration capabilities to Level 1 Users. Process

Test

N42

CS-IFS-01.1 The System shall enable a Level 1 User to configure all parameters related to each Connection Session.

Input

Test

N42

CS-IFS-01.2 The System shall enable a Level 1 User to put a Connection Session into a manual or automatic activation mode.

Input

Test

N42

CS-IFS-01.3 The System shall support secure protocols per FIPS 140 for Connection Sessions with External Interfacing Systems and be approved by the Engineer.

Security

Test

N42

CS-IFS-02 The System shall enable Level 1 Users to manage a Connection Session. Process

Analysis

N42

CS-IFS-02.1 The System shall maintain its Connection Session with an External Interfacing System in accordance with rules described in the appropriate Interface Control document.

Performance

Test

N42

CS-IFS-02.2 When the Level 1 User determines that a Connection Session is to be established, the System shall establish the Connection Session automatically.

Output

Demonstration

N42

CS-IFS-02.3 When the System determines that the Connection Session is to be terminated, the System shall terminate the Connection Session automatically.

Output

Demonstration

N42

CS-IFS-02.4 When a Connection Session with an External Interfacing System has been terminated, and the System determines that the Connection Session is to be re-established, the

Output

Demonstration

N42


170


VERIFICATION

NEED TRACE

System shall re-establish the Connection Session automatically unless overridden by a Level 1 User.

CS-IFS-02.5 When requested by a Level 1 User, the System shall establish a Connection Session with an External Interfacing System.

Output

Demonstration

N42

CS-IFS-02.6 When requested by a Level 1 User, the System shall terminate a Connection Session with an External Interfacing System.

Output

Demonstration

N42

CS-IFS-02.7 The System shall exchange Data Items with External Interfacing System in the manner defined in the Interface Control Description Document for each interfacing relationship.

Performance

Demonstration

N42

CS-IFS-02.8 If an established Connection Session experiences a System Fault, System Failure, or System Error, then the System shall provide a Level 1 User with a System Alert.

Process

Demonstration

N42

CS-IFS-03 The System shall exchange Data Items with specific External Interfacing Systems. Process

Demonstration

N42

CS-IFS-03.1 The System shall exchange Data Items with RBMS Field Devices. Process

Demonstration

N42

CS-IFS-03.1.1 The System shall receive Data Items with the POE GLS [IF01]. Process

Demonstration

N42

CS-IFS-03.1.1.1 The System shall receive Data Items from the POE GLS about the POE Gate including:

a. Barrier System Status

b. Health Status

c. System Alerts

d. Operational Alerts

Input

Demonstration

N42

CS-IFS-03.1.1.2 The System shall receive Data Items from the POE GLS about the POE Lane including: Input N42


171


VERIFICATION

NEED TRACE

a. Lane Management Information

b. Health Status

c. System Alerts


Demonstration

CS-IFS-03.1.1.3 The System shall receive Data Items from the POE GLS about the Swing Gate (at POE Lane) including:

a. Barrier System Status

b. Health Status

c. System Alerts


Input

Demonstration

N42

CS-IFS-03.1.2 The System shall exchange Data Items with the Approach Lane VMS System [IF-03]. Process

Demonstration

N42

CS-IFS-03.1.2.1 The System shall provide Data Items to the Approach Lane VMS System including:

a. Roadway Information System Data

b. Lane Management Control

Output

Demonstration

N42

CS-IFS-03.1.2.2 The System shall receive Data Items from the Approach Lane VMS System including:

a. Lane Management Information

b. Roadway Information System Status

Input

Demonstration

N42

CS-IFS-03.1.3 The System shall exchange Data Items with the RBMS Closed Circuit Television (CCTV) System [IF-03].

Process

Demonstration

N42

CS-IFS-03.1.3.1 The System shall provide Data Items to the native RBMS CCTV System including:

a. Video Surveillance Control

Output

Demonstration

N42

CS-IFS-03.1.3.2 The System shall receive Data Items from the native RBMS CCTV System including: Input N42


172


VERIFICATION

NEED TRACE

a. Video Surveillance Feedback

b. Traffic Images

c. Field Device Status

d. System Alerts

e. Operational Alerts

Demonstration

CS-IFS-03.1.4 The System shall exchange Data Items with the Vehicle Detection Station (VDS) System [IF08].

Process

Demonstration

N42

CS-IFS-03.1.4.1 The System shall provide Data Items to the VDS System including:

a. Traffic Sensor Control

Output

Demonstration

N42

CS-IFS-03.1.4.2 The System shall receive Data Items from the VDS System including:

a. Traffic Probe Data

i. Speed

ii. Volume

iii. Direction

iv. Occupancy

b. VDS Station Number/Roadway ID/Ramp ID

Input

Demonstration

N42

CS-IFS-03.1.5 The System shall exchange Data Items with the Point Vehicle Time Detection (PVTD) System [IF08].

Process

Demonstration

N42

CS-IFS-03.1.5.1 The System shall receive Data Items from the PVTD System including:

a. Toll Probe Data

i. Station ID

ii. Obfuscated Vehicle Probe Data

iii. XML feed

b. Road Network Traffic Probe Data

i. Station ID

Input

Demonstration

N42


173


VERIFICATION

NEED TRACE

ii. Obfuscated Vehicle Probe Data

iii. XML feed

CS-IFS-03.1.6 The System shall exchange Data Items with the Variable Toll Message Sign (VTMS) System [IF12].

Process

Demonstration

N42

CS-IFS-03.1.6.1 The System shall provide Data Items to the VTMS System including:

a. Roadway Information System Data

i. VTMS ID

ii. Border Wait Time

iii. OME Variable Toll Rate

iv. Message (e.g.: Closed)

Output

Demonstration

N42

CS-IFS-03.1.6.2

The System shall provide Data Items to the Data Hub System including:

a. Incident information

i. Duration

ii. Location

iii. Severity

iv. Type

v. Associated closures

b. Traffic Images

i. Selected CCTV image sources

c. Device Data

i. External CMS/VMS

ii. VDS

d. Device status

i. Available

ii. Degraded

iii. Unavailable

Output

Demonstration

N43


174


VERIFICATION

NEED TRACE

e. Road network conditions

i. Closures

ii. Restrictions

iii. Current and forecast conditions

iv. Segment travel times

f. Road Work

i. Maintenance and Construction Work Plan

1. Locations

2. Lane Closures

g. Border Wait Time at OME Crossing

i. by Direction of Travel

ii. by Primary Inspection Lane Type

h. Border Crossing Time at OME Crossing


ii. by Primary Inspection Lane Type

i. Toll Rates at OME Crossing

i. by Vehicle Type

ii. by Direction of Travel

iii. by time of day

CS-IFS-03.1.6.3 The System shall receive Data Items from the VTMS System including:

a. Roadway Information System Status

b. Health Status

c. System Alerts


Input

Demonstration

N42

CS-IFS-03.1.6.4 The System shall receive Data Items from the Data Hub System, within five seconds, including:

a. Incident information

Input

Demonstration

N43


175


VERIFICATION

NEED TRACE

i. Duration

ii. Location

iii. Severity

iv. Type

v. Associated closures

b. Traffic Images

i. Selected CCTV image sources

c. Device Data

i. External CMS/VMS

ii. VDS

d. Device Status

i. Available

ii. Degraded

iii. Unavailable

e. Road Network Conditions

i. Closures

ii. Restrictions

iii. Current and forecast conditions

iv. Segment travel times

f. Road Work


1. Locations

2. Lane Closures

g. Border Wait Times for:

i. OMW Crossing

ii. San Ysidro Crossing


176


VERIFICATION

NEED TRACE

CS-IFS-03.2 The System shall exchange Data Items with External Interfacing Systems. Process

Demonstration

N42

CS-IFS-03.2.1 The System shall exchange Data Items with the OME Toll System [IF-04] via the Data Hub.

Process

Demonstration

N42

CS-IFS-03.2.1.1 The System shall provide Data Items to the OME Toll System including:

a. Toll Data Request

b. Health Status

i. VTMS Health Status

ii. RBMS Central System Health Status

c. Border Wait Time

d. Traffic Probe Data (from Pre-Toll Zone and Toll-Zone areas)

e. Lane Type

f. Incident Notification

Output

Demonstration

N42

CS-IFS-03.2.1.2 The System shall receive Data Items from the OME Toll System including items related to Toll Data:

a. Toll Price


ii. by Vehicle Type

iii. by hour and upon change

iv. by Pay Type

b. Toll Lane Status

i. Open Road Terminal

1. Open

2. Closed

ii. Automatic Payment Terminal

1. Open

Input

Demonstration

N42


177


VERIFICATION

NEED TRACE

2. Closed

c. Closed Toll Transaction Summaries

i. Toll Volumes

1. by Vehicle Type

2. by payment type

3. by Direction of Travel

4. by day of week

5. by time of day

CS-IFS-03.2.1.3 The System shall receive Data Items from both the Primary and Secondary implementations of the OME Toll System

Input

Demonstration

N42

CS-IFS-03.2.1.4 The System shall exchange Data Items from both the Primary and Secondary implementations of the OME Toll System

Output

Demonstration

N42

CS-IFS-03.2.1.5 The System interface to the OME Toll System shall use a transport layer protocol (typ. TCP).

Performance

Test

N42

CS-IFS-03.2.2 The System shall provide Data Items from up to three border crossings to the Border Enforcement Border Waits Information System including:

a. Border Wait Times & Crossing Times for

i. OMW Crossing

1. By Direction of Travel

2. By Primary Inspection Lane Type




iii. OME Crossing

Output

Demonstration

N42


178


VERIFICATION

NEED TRACE



b. Traffic Images

c. Incidents

d. Roadway Network Conditions

i. Closures

ii. Restrictions

iii. Current & Forecast Conditions

iv. Segment Travel Time

e. Road Work


f. Toll Rates

i. By Vehicle Type

ii. By Direction of Travel

iii. By Time of Day

CS-IFS-03.2.3 The System shall provide Data Items from up to three border crossings to the Aduanas Border Waits Information System including:

a. Border Wait Times & Crossing Times for

i. OMW Crossing






Output

Demonstration

N42


179


VERIFICATION

NEED TRACE

iii. OME Crossing



b. Traffic Images

c. Incidents

d. Roadway Network Conditions

i. Closures

ii. Restrictions

iii. Current & Forecast Conditions

iv. Segment Travel Time

e. Road Work


f. Toll Rates

i. By Vehicle Type

ii. By Direction of Travel

iii. By Time of Day


180

Figure 38: IF04 Data Flows between OME Toll System and RBMS Central System


181

Figure 39: IF06 Data Flows between the Data Hub and RBMS Central System


182

Figure 40a: IF07a Data Flows between CHP and RBMS Central System

Figure 41b: IF07b Data Flows between the CBP Watch Commander and RBMS Central System


183

Figure 42c: IF07c Data Flows between Aduanas Management and RBMS Central System


184

1.8.5 User Training

The System must include the capability for new and existing operational Users to be trained on system functionality in compliance with the Operational Training requirements defined in Training scope of work (SOW).

The software, hardware and training materials provided by the contractor that together enables this, is referred to in this section as the Training Environment, which will initially match the configuration of the production environment in addition to meeting the functional requirements in this section. The Training Environment will minimally have the performance necessary to train trainees in compliance with the operational training requirements defined in Training SOW.

The scope of the Training Environment is limited to enabling trainees to undertake operational training only. The Training Environment is envisioned as separate from the environments. The Training Environment will allow trainees to take part in individual and group training activity utilizing training workstations located in the training room. The Training Environment must support the various types of training activities supervisors may wish to perform, some of which may be performed with or without an instructor present.

The Training Environment will utilize training scenarios that define and control the training activity. A number of training scenarios will be developed by the contractor and initially provided with the system, and instructors will be able to edit (e.g.: create, replace, update or delete) them. The training scenarios initially developed by the contractor will be in compliance with, and aligned with, the operational training requirements and subject to human factors requirements.

The Training Environment will be capable of utilizing historical data and Simulated Data when conducting a training activity. The Training Environment will enable instructors to view the training record of a trainee, and instructors will be able to print, email and export training records from the Training Environment.

The Training Environment is envisioned as separate from the production environment and test environment, rather than a mode of the production environment. The Training Environment will not affect the performance of the production environment, and it will allow appropriately authorized users to manually synchronize the configuration of the Training Environment with the production environment, as well as reverting to previous configuration should the need arise. The Training Environment will allow appropriately authorized users to view (read-only) live data from the production environment during a training activity.


185

1.8.5.1 User Training Requirements


VERIFICATION

NEED TRACE

CS-TRA-01 The System provide a Training Environment capable of providing System operations training to RBMS Users who manage the traffic operation at the OME Crossing.

Physical

Demonstration

N44

CS-TRA-01.1 The Training Environment shall use the same configuration and functionality as the Validation environment.

Performance

Demonstration

N44

CS-TRA-01.2 The Training Environment shall enable data to be received from the Validation environment’s external interfaces, which may be simulated.

Input

Demonstration

N44

CS-TRA-01.2.1 The fidelity of data input to Training Environment via its external data interfaces shall conform to that of the Validation environment, which may be simulated.

Performance

Demonstration

N44

CS-TRA-01.3 The Training Environment shall include workstations physically installed at the training room

Physical

Demonstration

N44

CS-TRA-01.3.1 The Training Environment shall enable a minimum of two trainees to undertake a training activity at a training workstation

Performance

Demonstration

N44

CS-TRA-01.3.2 The Training Environment shall include instructor workstations physically installed at the training room

Physical

Demonstration

N44

CS-TRA-01.4 The Training Environment shall ensure that the performance of the production environment is not degraded by the operation of the Training Environment.

Performance

Demonstration

N44

CS-TRA-01.4.1 The Training Environment shall enable trainees to concurrently participate in training activity without degrading the performance of the Training Environment.

Process

Demonstration

N44

CS-TRA-01.5 The Training Environment User interface shall include a feature that distinguishes it from the production environment User interface, subject to approval by the engineer

Performance

Demonstration

N44


186


VERIFICATION

NEED TRACE

CS-TRA-01.6 The Training Environment shall enable Users to access its functionality pursuant to User credentials

Output

Demonstration

N44

CS-TRA-02 The Training Environment shall provide Users with training scenarios. Output

Demonstration

N45

CS-TRA-02.1 The Training Environment shall operate training activity based on training scenarios Process

Demonstration

N45

CS-TRA-02.2 The Training Environment shall provide initial training scenarios as part of the Training Environment, subject to approval by the engineer.

Performance

Demonstration

N45

CS-TRA-02.4 The Training Environment shall enable instructors to edit training scenario parameters before a training activity starts

Input

Demonstration

N45

CS-TRA-02.5 The Training Environment shall enable instructors to edit training scenario parameters while a training activity is underway

Input

Demonstration

N45

CS-TRA-03 The Training Environment shall enable training activities to be conducted. Process

Demonstration

N46

CS-TRA-03.1 The Training Environment shall enable the training activity defined in the training plan specified in the operational training requirements to be undertaken by trainees.

Output

Demonstration

N46

CS-TRA-03.2 The training activity shall include:

a. Qualification training

b. Refresher training

c. Critique/tutorial training

d. Training with instructor present

e. Training with instructor not present

Output

Demonstration

N46


187


VERIFICATION

NEED TRACE

CS-TRA-03.3 The Training Environment shall enable instructors to start, stop and pause training activity. Input

Demonstration

N46

CS-TRA-03.4 The Training Environment shall enable a single trainee to take part in training activity Performance

Demonstration

N46

CS-TRA-03.5 The Training Environment shall enable multiple trainees to simultaneously take part in group training activity

Performance

Demonstration

N46

CS-TRA-03.6 When providing training activities, the Training Environment shall support the use of

a. Historic Data

b. Training Data (i.e.: scripted simulation data)

Input

Demonstration

N46

CS-TRA-04 The Training Environment shall provide a User with training activities without the instructor present.

Process

Demonstration

N46

CS-TRA-04.1 The contractor shall enable training activity to be undertaken by trainees with an instructor not present.

Process

Demonstration

N46

CS-TRA-04.2 The Training Environment shall enable trainees to start, stop and pause individual training activity performed with an instructor not present

Input

Demonstration

N46

CS-TRA-05 The Training Environment shall provide a User with results of training activities. Output

Demonstration

N44

CS-TRA-05.1 The Training Environment shall enable instructors to view training records Output

Demonstration

N44

CS-TRA-05.2 The Training Environment shall enable a trainee to view their training record Output

Demonstration

N44


188


VERIFICATION

NEED TRACE

CS-TRA-05.3 The Training Environment shall enable instructors to modify training records Process

Demonstration

N44

CS-TRA-05.4 The Training Environment shall enable instructors to print training records Output

Demonstration

N44

CS-TRA-05.5 The Training Environment shall enable instructors to email training records from the Training Environment to recipients outside of the Training Environment

Output

Demonstration

N44

CS-TRA-05.6 The Training Environment shall enable instructors to export training records from the Training Environment in human-readable and machine-readable formats.

Output

Demonstration

N44

CS-TRA-05.7 The Training Environment shall keep a training record all trainees, and enable Users to view, modify, print, email and export those records.

Process

Demonstration

N44

CS-TRA-06 The Training Environment shall enable a User to manage its configuration. Process

Demonstration

N47

CS-TRA-06.1 The Training Environment shall enable Users to manually synchronize its configuration with that of the production environment

Process

Demonstration

N47

CS-TRA-06.2 The Training Environment shall enable Users to roll-back to previously deployed configuration of the Training Environment

Process

Demonstration

N47


189

2 RBMS Field Devices

2.1 General Requirements

Field equipment shall include devices placed at strategic locations along the roadway that will enable collection of traffic and vehicle data, and ensure transmission of the data to the RBMS Central System. Field equipment shall also enable RBMS to communicate traffic, travel and border information to road users. All field equipment shall meet the following general requirements:

2.1.1 Environmental Requirements

ID REQUIREMENT TEXT REQUIREMENT TYPE

VERIFICATION

NEED TRACE

FD-GEN-01 All field equipment components shall operate in the southern California and Northern Mexico climate within operating temperature range of 10-165 degrees Fahrenheit (ºF) and non-condensing humidity in the range of 0 percent to 100 percent.

Performance

Inspection

N48

FD-GEN-02 All field equipment components shall operate in rain of up to two inches per hour (2in/hr.), wind, dust, fog, changing temperature, and changing lighting conditions.

Performance

Inspection

N48

FD-GEN-03 All field equipment components installed in the United States of America shall not transmit or be susceptible to electromagnetic interference in conformance with FCC Rules and Regulations, Tile 47, Part 15, Class A.

Performance

Analysis

N48

FD-GEN-04 All field equipment components installed in Mexico shall not transmit or be susceptible to electromagnetic interference in conformance with IFT-008-2015.

Performance

Analysis

N48

FD-GEN-05 All equipment components encased in NEMA-rated enclosures shall conform to NEMA Standards for use in the Border Environment or be placed in a separately supplied NEMA rated enclosure.

Physical

Inspection

N48


190

2.1.2 Electrical Power Requirements


VERIFICATION

NEED TRACE

FD-GEN-06 The Contractor shall install field equipment with supplied voltage of 120/240 VAC 60Hz at +/-5 percent.

Physical

Inspection

N48

FD-GEN-06.1 The Contractor shall ensure field equipment power supplies are rated to supply a minimum of 150% of the total steady-state volt-ampere power rating for all equipment held at the site.

Physical

Inspection

N48

FD-GEN-07 If equipment requires other supply voltage, the Contractor shall ensure equipment is supplied with the required power supply equipment or share power supplies at the field cabinet for use by multiple equipment.

Physical

Inspection

N48

FD-GEN-08 The Contractor shall ensure equipment sensitive to voltage fluctuations or sudden outages, including VTMS, is supplied with uninterruptible power supplies (UPS).

Physical

Inspection

N48

FD-GEN-08.1 The Contractor shall ensure that an uninterruptible power supply is usable by multiple pieces of equipment at each field cabinet.

Physical

Inspection

N48

FD-GEN-08.2 Field cabinets shall maintain A/C to maintain an internal temperature at or below 104 F/40 C.

Physical

Inspection

N48

FD-GEN-08.3 The Contractor shall ensure that the Uninterruptible power supply is sized for equipment load and back up duration of 2 hours.

Physical

Inspection

N48

FD-GEN-09 Unless otherwise noted, the Contractor shall ensure that electrical components are designed for permanent power connection with solar power supplies or other type of batteries permitted only where noted.

Physical

Inspection

N48


191

2.1.3 Communications Integration Requirements


VERIFICATION

NEED TRACE

FD-GEN-10 The field equipment shall connect with the real-time data acquisition local area communications system that will provide connectivity to the RBMS Backbone.

Physical

Inspection

N55

FD-GEN-011 Each type of field equipment shall include any required media or protocol converters to complete the interface to the local real-time data acquisition communications system.

Performance

Inspection

N55

FD-GEN-012 Field equipment shall connect with the local area communications system conforming to National Transportation Communications for Intelligent Transportation System, Ethernet Subnetwork Profile, NTCIP 2104 or equivalent wireless 802.11 Ethernet.

Performance

Inspection

N26, N54, N55

FD-GEN-013 Field equipment shall connect with the local area communications system conforming to National Transportation Communications for Intelligent Transportation System Protocol, Internet (Transmission Control Protocol/Internet Protocol and User Datagram Protocol/Internet Protocol) Transport Profile, NTCIP 2202.

Performance

Inspection

N26, N54, N55

2.2 RBMS Closed Circuit Television System

The RBMS Closed Circuit Television (CCTV) System shall be used to provide real-time traffic surveillance system to enable RBMS operators to monitor roadway conditions, monitor ITS field equipment, identify incidents and emergencies, and monitor responses to incidents and the effectiveness of traffic management and tolling strategies.


192

Figure 43: RBMS Field Device - Closed Circuit Television (CCTV) System Architecture


193

2.2.1 Functional Requirements

The following table defines the requirements for the CCTV System Field Devices.


VERIFICATION

NEED TRACE

FD-CTV-01 The RBMS CCTV System shall receive color imagery data from CCTV camera devices deployed in the field.

Input

Demonstration

N6

FD-CTV-02 The RBMS CCTV System shall accept Video Surveillance Control from the RBMS Central System [IF05].

Input

Demonstration

N7

FD-CTV-02.1 The RBMS CCTV System shall include fixed view cameras at select sites in the Lane Allocation Zone on both sides of the border within the OME compound that are located near CBP/Aduanas Customs Inspection facilities.

Physical

Demonstration

N7, N50

FD-CTV-02.2 CCTV Cameras shall support a minimum of two individually configured video streams. Input

Demonstration

N7

FD-CTV-03 The RBMS CCTV System shall process Video Surveillance Control. Process

Test

N7

FD-CTV-03.1 The RBMS CCTV System shall determine the appropriate CCTV Control Feedback message to transmit to the RBMS Central System based on the CCTV Control Instructions it has received and the action carried out.

Process

Test

N7

FD-CTV-03.2 If the RBMS CCTV System determines that the Video Surveillance Control would result in providing imagery from a secure area, then the RBMS CCTV System shall exclude the Video Surveillance Control from further processing

Process

Test

N7, N50

FD-CTV-03.3 When the RBMS CCTV System excludes a Video Surveillance Control the RBMS CCTV System shall establish an Operational Alert.

Process

Test

N7, N50


194


VERIFICATION

NEED TRACE

FD-CTV-03.4 Camera control protocol shall conform to the National Transportation Communications for Intelligent Transportation System Protocol, Object Definitions for Closed Circuit Television Camera Control, NTCIP 1205.

Process

Test

N7, N26

FD-CTV-04 The RBMS CCTV System shall process raw field sensor data into Traffic Images. Process

Test

N6

FD-CTV-04.1 Video encoding shall support multiple including the latest or current protocols, defined at time of design, for video signal transfer from the camera to the RBMS Central System over an IP network.

Process

Test

N6

FD-CTV-04.2 The RBMS CCTV System shall accept RTSP Stream initiation requests from the RBMS Central System and transmit video streams back via RTP.

Performance

Test

N6, N7

FD-CTV-04.3 CCTV system shall provide clear full motion, high-definition TV quality video. Performance

Test

N6

FD-CTV-04.3.1 Cameras shall enable use of resolution lower than the native resolution of the device. Performance

Test

N6

FD-CTV-04.4 The CCTV camera shall support low light level operation and provide a high contrast color picture with a full video output at a minimum illumination of 0.8 lux

Performance

Test

N6

FD-CTV-04.5 The RBMS CCTV System shall enable a User to configure of video encoding for frame rate between 1 and 30 frames per second (fps).

Process

Test

N6

FD-CTV-05 The RBMS CCTV System shall process video imagery continuously, in order to automatically detect incidents based on abnormal conditions

Process

Test

N9

FD-CTV-05.1 While in a standard pre-set view, the RBMS CCTV System shall automatically detect when debris is present in the roadway via analysis of a predefined image zone.

Process

Test

N9


195


VERIFICATION

NEED TRACE

FD-CTV-05.2 While in a standard pre-set view, the RBMS CCTV System shall automatically detect when traffic conditions (e.g.: stalled or slow moving vehicles) differ from expected conditions at the given time of day and current weekday.

Process

Test

N9

FD-CTV-06 The RBMS CCTV System shall determine its own Health Status. Process

Demonstration

N49

FD-CTV-06.1 If the RBMS CCTV System cannot receive imagery data from CCTV devices, then the RBMS CCTV System shall establish a System Alert.

Process

Demonstration

N20

FD-CTV-07 The RBMS CCTV System shall provide Video Surveillance Control to its CCTV camera devices deployed in the field.

Output

Test

N7

FD-CTV-08 The RBMS CCTV System shall transmit updated data via a Connection Session [IF05]. Output

Test

N54

FD-CTV-08.1 The RBMS CCTV System shall transmit updated Traffic Images to the RBMS Central System [IF05].

Output

Test

N54

FD-CTV-08.2 The RBMS CCTV System shall transmit updated Video Surveillance Feedback to the RBMS Central System for PTZ- controllable cameras [IF-05].

Output

Test

N7

FD-CTV-08.3 The RBMS CCTV System shall transmit Automated Incident Video Detection alerts to the RBMS Central System when an incident is confirmed [IF05].

Output

Test

N9

FD-CTV-08.4 The RBMS CCTV System shall transmit updated Health Status to the RBMS Central System [IF05].

Output

Test

N49

FD-CTV-08.5 The RBMS CCTV System shall transmit its updated System Alerts and Operational Alerts to the RBMS Central System [IF05].

Output

Test

N19, N20


196


VERIFICATION

NEED TRACE

FD-CTV-08.6 If the Connection Session [IF05] is interrupted, then the RBMS CCTV System shall establish the Connection Session [IF05].

Output

Test

N54

FD-CTV-08.7 The RBMS CCTV System shall display true HD (1080p) and SD Video streaming. Performance

Test

N6

FD-CTV-08.7.1 The RBMS CCTV System shall enable a User to program a native CCTV camera to present HD or SD Video.

Performance

Test

N6

FD-CTV-08.8 The RBMS CCTV System shall provide Flexible Video Title Management. The video screen will have available scalable fonts for video ID as well as date and time stamps.

Performance

Test

N6

FD- CTV-08.9 The RBMS CCTV System shall provide Flexible Logo Management. The system will have a scalable logo in .jpg and .gif uploaded with X-Y positioning and with at least 100 point granularity.

Performance

Test

N6

FD-CTV-08.10 The RBMS CCTV System shall provide a static Image Snapshot file to be uploaded to a Snapshot Server with periodic updates and the filename that can be uniquely specified.

Output

Test

N6

FD-CTV-08.11 The RBMS CCTV System shall conform to ONVIF standard for IP Cameras. Performance

Inspection

N48

FD-CTV-08.12 The RBMS CCTV System shall use Cameras with Image Stabilization capability. Performance

Test

N48

FD-CTV-08.13 The RBMS CCTV System shall use IP Cameras with wipers for cleaning the camera lens. Performance

Test

N48


197

2.2.2 Implementation Requirements

The following tables define the implementation requirements for the CCTV System Field Devices in three primary sub-sections:

1. General requirements applicable to all implementations.

2. USA-specific requirements, and

3. MEX-specific requirements.

2.2.2.1 General


VERIFICATION

NEED TRACE

FD-CTV-09 The RBMS CCTV System shall provide full video coverage of the Approach Zone and Pre-Approach Zone on both sides of the border.

Physical

Inspection

N6, N50

FD-CTV-09.1 The RBMS CCTV System shall provide full video coverage of Approach Lane Management and Variable Toll Message Signs, such that RBMS Operators are able to visually confirm the displayed variable messages at all times

Physical

Test

N6, N50

FD-CTV-09.2 The RBMS CCTV System shall use fixed cameras when focused on VTMS/VMS. Performance

Test

N6, N50

FD-CTV-09.3 The RBMS CCTV System cameras focused on VTMS/VMS, which are required to have PTZ capabilities, shall use defined presets to allow the view to adjust back to the VTMS/VMS display.

Physical

Inspection

N6, N50

FD-CTV-010 The Lane Allocations Zone shall use fixed view cameras that limit the view of sensitive customs areas.

Physical

Inspection

N6, N50

FD-CTV-011 The RBMS CCTV System shall include camera pole and foundation, mounting hardware, interconnect wiring and connectors, power supply and underground conduit connection between the pole foundation and the field cabinet.

Physical

Inspection

N48


198


VERIFICATION

NEED TRACE

FD-CTV-011.1 The Contractor shall install electrical and communications conduits separately within the same trench.

Physical

Inspection

N48

FD-CTV-012 The camera and the cabinet shall use continuous wiring between them, contained within the pole and underground conduit.

Physical

Inspection

N48

FD-CTV-013 RBMS CCTV System shall conform to Caltrans guidelines or National Electric Code (NEC) regarding grounded wiring, as applicable.

Physical

Inspection

N48

FD-CTV-014 All field components shall support outdoor operation or be enclosed in an environmental enclosure designed for operation in the deployment area climate.

Physical

Inspection

N48

FD-CTV-015 The Contractor shall ensure that the operation of the camera assembly is unaffected by vibration and wind and be equipped with wipers or another self-cleaning system for ease of maintenance and minimal exposure of maintenance personnel.

Performance

Demonstration

N48

FD-CTV-016 The RBMS CCTV System shall provide full video coverage of the Pre-Toll Zone and Toll Zone areas.

Physical

Inspection

N6, N50

2.2.2.2 United States of America


VERIFICATION

NEED TRACE

FD-CTV-017 All field installations shall conform to Caltrans guidelines and practices for installation of CCTV equipment.

Physical

Inspection

N48

FD-CTV-017.1 The CCTV shall use a pole a minimum of 40 feet long and conform to Caltrans standard ES-16D. Longer poles conforming to Caltrans standards may be selected as warranted by the roadway geometry to achieve required video coverage.

Physical

Inspection

N48


199


VERIFICATION

NEED TRACE

FD-CTV-018 Roadside cabinets for CCTV installation shall conform to Caltrans standard 334 (66” high), with 304 Grade A or B stainless steel.

Physical

Inspection

N48

FD-CTV-019 If co-location of the RBMS cameras is required on the same pole with Caltrans cameras, the Contractor shall ensure that Caltrans camera be placed on top of the CCTV pole with the RBMS camera placed three-feet below the top on a dedicated mounting arm.

Physical

Inspection

N48

FD-CTV-020 The RBMS CCTV System shall use Dedicated field cabinets, conforming to Caltrans standards. The RBMS CCTV cabinets may be co-located with other ITS equipment.

Physical

Inspection

N48

FD-CTV-021 CCTV within the RBMS region on the US side shall connect back to the wired RBMS Communications network.

Physical

Demonstration

N56

2.2.2.3 Estados Unidos Mexicanos


VERIFICATION

NEED TRACE

FD-CTV-022 All field installations shall conform to Baja California state and regional guidelines and practices for installation of CCTV equipment.

Physical

Inspection

N48

FD-CTV-023 Video coverage shall include passenger and cargo northbound approaches to the OME Compound along the redesigned De las Torres roadway and Colina del Sol respectively.

Physical

Inspection

N6

FD-CTV-024 The site and field cabinet design shall ensure security and integrity of the equipment. Security

Inspection

N48

FD-CTV-025 CCTV within the RBMS region on the Mexican side shall connect back to the RBMS Communications network via wireless connection (typ. LTE).

Physical

Demonstration

N57


200


VERIFICATION

NEED TRACE

FD-CTV-025.1 Feeds from CCTV sites within the RBMS region on the Mexican side connecting back to the RBMS Communications network via Cellular LTE shall use an appropriate bitrate which can be supported by the communications path and balances the requirement for stream versus cost of transmitted data.

Physical

Demonstration

N57

2.3 Approach Lane Variable Message Signs

The Approach Lane Variable Message Sign (VMS) System shall provide dynamic lane management in the Approach Zone to the border in both directions, following the split of passenger vehicle and truck/commercial traffic. Approach lane functionality shall be provided for each lane, mounted over the lanes on a shared gantry.


201

Figure 44: RBMS Field Devices - Approach Lane Variable Message Sign (VMS) System Architecture


202


The following table defines the functional requirements for Approach Lane Variable Message Sign (VMS) System Field Devices.


VERIFICATION

NEED TRACE

FD-VMS-01 The VMS shall receive Roadway Information System Data via a Connection Session [IF03]. Input

Test

N54

FD-VMS-01.1 The Approach Lane VMS shall receive Roadway Information System Data from the RBMS Central System, including:

a. Lane Status (i.e.: open/closed) by lane of traffic under the VMS

b. Vehicle Type permitted in the lane

c. Primary Inspection Lane Type northbound (e.g.: FAST, SENTRI, READY, general, Laden, Empty, etc.)

d. Primary Inspection Lane Type southbound (e.g.: Laden, Empty, NEEC, PEQUEÑAS, auto-carriers, declare, no-declare, busses)

Input

Test

N14

FD-VMS-02 The VMS shall receive Lane Management Control signals (i.e.: parameters for controlling the operation of the variable message sign and the manner in which messages are displayed) via a Connection Session [IF03].

Input

Test

N14, N54

FD-VMS-02.1 The VMS controller and communications protocol shall conform to the most recent version of the NTCIP standards including all approved or recommended amendments to these standards as of the same date.

a. NTCIP 1201: Global Object Definitions

b. NTCIP 1203: Object Definitions for Dynamic Message Signs (DMS)

c. NTCIP 2104: Ethernet Subnetwork Profile

d. NTCIP 2202: Internet (TCP/IP and UDP/IP) Transport Profile

Performance

Test

N26

FD-VMS-03 The VMS shall process received messages for display within five (5) seconds.

Constraint

Demonstration

N14


203


VERIFICATION

NEED TRACE

FD-VMS-03.1 VMS shall display all English and Spanish characters including diacritics with a height of 18 inches for roadways with a speed limit 45mph or higher and 12 inches for roadways with a speed limit of less than 45mph.

Physical

Demonstration

N33

FD-VMS-03.2 VMS shall automatically adjust levels of luminous intensity according to ambient light conditions.

Performance

Demonstration

N48

FD-VMS-04 The VMS shall determine its own Health Status.

Process

Test

N49

FD-VMS-05 The VMS shall display messages on VMS displays. Output

Demonstration

N14

FD-VMS-05.1 The display placement, visibility, legibility, display configuration and maximum units of information per message for VMS in USA shall conform to the current California edition of Manual on Uniform Traffic Control Devices (MUTCD).

Performance

Demonstration

N14, N48

FD-VMS-05.2 The display placement, visibility, legibility, display configuration and maximum units of information per message for VMS in MEX shall conform to the current Mexico edition of Manual De Dispositivos Para El Control Del Transito En Calles Y Carreteras.

Performance Demonstration

N14, N48

FD-VMS-05.3 VMS shall display lane designation information in a single phase display. Output

Demonstration

N10, N14

FD-VMS-05.3.1 VMS text options that fit on the sign, and up to three per lane simultaneously, shall include:

a. Commercial Traffic southbound: Laden, Empty, NEEC, PEQUEÑAS, AUTO-CARRIERS

b. Commercial Traffic northbound: Fast, Laden, Empty

c. Passenger Traffic Southbound: Declare, No-Declare, Busses

d. Passenger Traffic northbound: SENTRI, Ready, General

e. Lane Status (i.e.: Open, Closed) by lane of traffic under the VMS

Output

Demonstration

N10, N14


204


VERIFICATION

NEED TRACE

FD-VMS-06 The VMS shall transmit lane management status data via a Connection Session [IF03]. Output

Test

N54

FD-VMS-06.1 The VMS shall transmit updated Health Status to the RBMS Central System. Output

Test

N49

FD-VMS-06.2 The VMS shall transmit updated Lane Management Information (i.e.: confirmation of the current lane management information currently presented on the variable signage) to the RBMS Central System within five seconds

Constraint

Test

N14

FD-VMS-06.3 If the Connection Session [IF03] is interrupted, then the VMS shall re-establish the Connection Session [IF03].

Output

Test

N54

FD-VMS-06.4 If the Connection Session [IF03] is interrupted, the VMS shall display an independently programmable default message.

Output

Test

N54


The following tables define the implementation requirements for the Approach Lane VMS System Field Devices in three primary sub-sections:

1. General requirements applicable to all implementations.

2. USA-specific requirements, and

3. MEX-specific requirements.


205

2.3.2.1 General


VERIFICATION

NEED TRACE

FD-VMS-07 VMS shall include sign case, display elements, photocell sensor, controller, sign structure and footings, and other associated mechanisms and equipment required to form an operational display.

Physical

Inspection

N48

FD-VMS-08 All components shall support an outdoor operation or be enclosed in an environmental enclosure designed for operation in the deployment area climate.

Physical

Inspection

N48

FD-VMS-09 VMS enclosure shall conform to NEMA TS 4-2005. Physical

Inspection

N48

FD-VMS-010 The VMS shall connect to the wired or wireless real-time data acquisition RBMS Communications equipment.

Physical

Inspection

N56, N57

FD-VMS-011 The VMS and the field cabinets shall use continuous wiring between them, contained within the support structure or underground conduit.

Physical

Inspection

N48

FD-VMS-012 The cabinet sites may be co-located with other ITS equipment, where feasible. Physical

Inspection

N48

FD-VMS-013 The Contractor shall install VMS so that it is grounded in accordance with locally the enforced Electrical Safety Code.

Physical

Inspection

N48


206



VERIFICATION

NEED TRACE

FD-VMS-014 VMS field cabinets, support structures, footings, conduits and installation methods shall conform to Caltrans standards for Variable Message Signs.

Physical

Inspection

N48

FD-VMS-015 The Contractor shall install VMS in the Approach and Lane Allocations Zone downstream of the separation of passenger and commercial traffic.

Physical

Inspection

N48

FD-VMS-016 VMS within the RBMS region on the US side shall display information primarily in the English language.

Physical

Inspection

N33

FD-VMS-016.1 VMS shall enable equivalent Spanish translations of English messages to be displayed, so long as these messages are sufficiently abridged or condensed to fit the same number of characters as the English messages and that both languages can be displayed simultaneously on the signage in conformance with California MUTCD guidelines.

Physical

Inspection

N33

FD-VMS-016.2 VMS shall display bilingual messages on a single message phase Physical

Inspection

N33



VERIFICATION

NEED TRACE

FD-VMS-017 All field installations shall conform to Baja California state and regional guidelines and practices for installation of VMS equipment.

Physical

Inspection

N48

FD-VMS-018 The site and field cabinet design shall ensure security and integrity of the equipment. Physical

Inspection

N48


207


VERIFICATION

NEED TRACE

FD-VMS-019 VMS within the RBMS region on the Mexican side shall display information primarily in the Spanish language.

Physical

Inspection

N33

FD-VMS-019.1 VMS shall enable the display equivalent English translations of Spanish messages , so long as these messages are sufficiently abridged or condensed to fit the same number of characters as the Spanish messages and that both languages can be displayed simultaneously on the signage in conformance with SCT Guidelines

Physical

Inspection

N33

FD-VMS-019.2 VMS shall display bilingual messages on a single message phase Physical

Inspection

N33

2.4 POE Gate/Lane Status System

POE Gate/Lane Status (GLS) System shall provide detection of OME cargo and passenger primary inspection lane status and report Open or Closed status to the RBMS for each lane. The physical presence of a vehicle within the lane at primary inspection shall be relayed as Present or Non-Present status. The POE GLS System shall also report on the status of the facility gate to the cargo inspection zone, which is closed during a certain portions of the day.


208


209


The following table defines the functional requirements for the POE GLS System.


VERIFICATION

NEED TRACE

FD-POG-01 The POE GLS System shall receive GLS indications from its field sensors. Input

Test

N51

FD-POG-01.1 The POE GLS System shall receive updated Swing Gate Position indications from all OME equipped POE Lanes.

Input

Test

N51

FD-POG-01.2 The POE GLS System shall receive updated Entry Gate position indications from the USA and MEX entries to the OME Crossing.

Input

Test

N51

FD-POG-01.3 The POE GLS System shall receive updated Lane Status indications from all OME primary inspection lanes.

Input

Test

N51

FD-POG-02 The POE GLS System shall determine the Barrier System Status (i.e.: open/closed) for USA and MEX Entry Gates at OME.

Process

Test

N51

FD-POG-02.1 The gate shall report Closed status at the time of gate being closed and remain unchanged until gate re-opening.

Process

Test

N51

FD-POG-02.2 The gate shall report Open status at the time of the opening and remain unchanged until gate closing.

Process

Test

N51

Figure 45: RBMS Field Device POE Gate Status Detection Architecture


210


VERIFICATION

NEED TRACE

FD-POG-02.3 The POE GLS System shall connect with the gate closing mechanism in a manner that prevents false reading and without impacting operation of the gate.

Physical

Test

N51

FD-POG-02.4 The POE GLS System shall include programmable logic relay (PLR) that receives the gate status detection signal and connect to the wayside Ethernet communications system to transmit the gate status information to the RBMS Central System.

Process

Test

N51

FD-POG-02.5 The POE GLS System programmable logic relay shall accept a unique identification code. Performance

Test

N51

FD-POG-03 The POE GLS System shall determine the Barrier System Status (i.e.: swing gate position) for USA and MEX Swing Gates at OME.

Process

Test

N51

FD-POG-04 The POE GLS System shall determine the Lane Status (i.e.: open or closed status of lane as determined by customs authorities) for all USA and MEX primary inspection lanes at OME.

Process

Test

N51

FD-POG-04.1 The lane shall report Closed status at the time of the lane being closed and remain unchanged until the lane is re-opened.

Process

Test

N51

FD-POG-04.2 The lane shall report Open status at the time of opening and remain unchanged until the lane is closed.

Process

Test

N51

FD-POG-05 The POE GLS System shall determine its own Health Status. Process

Test

N49

FD-POG-06 The POE GLS System shall manage faults in determining Gate / Lane Status. Process

Test

N49

FD-POG-06.1 If the POE GLS System cannot receive indications, then the POE GLS System shall establish a System Alert.

Process

Test

N20


211


VERIFICATION

NEED TRACE

FD-POG-06.2 If the POE GLS System cannot determine the Swing Gate Position, Entry Gate position or Lane Status, then the POE GLS System shall establish an Operational Alert.

Process

Test

N19

FD-POG-07 The POE GLS System shall transmit updated status data via a Connection Session [IF01]. Output

Test

N54

FD-POG-07.1 The POE GLS System shall transmit updated GLS values to the RBMS Central System, consisting of:

a. Swing Gate Status upstream of Primary Inspection Lanes

Output

Test

N51

FD-POG-07.2 The POE GLS System shall transmit updated Health Status to the RBMS Central System. Output

Test

N49

FD-POG-07.3 The POE GLS System shall transmit its updated System Alert and Operational Alert information to the RBMS Central System.

Output

Test

N19, N20

FD-POG-07.4 If the Connection Session [IF01] is interrupted, then the POE Gate / Lane Status System shall re-establish the Connection Session [IF01].

Output

Test

N54


The following table defines the implementation requirements for the POE GLS System.


VERIFICATION

NEED TRACE

FD-POG-08 The POE facility gate systems shall use chain link roller type gates or similar mechanical gates and operate manually.

Physical

Inspection

N48, N51


212


VERIFICATION

NEED TRACE

FD- POG-08.1 The POE GLS System shall connect to the gate and positively detect gate opening and closing movements without human intervention.

Physical

Inspection

N48, N51

FD-POG-09 The POE GLS System equipment shall include all components required to generate gate and lane status information and transmit this data to the RBMS. Such components may include sensors, wiring, PLR enclosures, conduits and power/communications connections.

Physical

Inspection

N48, N51

FD-POG-010 The Contractor shall ensure placement of the POE GLS System equipment is inconspicuous to the approaching traffic.

Physical

Inspection

N48

FD-POG-011 The Contractor shall install the POE GLS System on each gate on the approach to POE, and for each primary inspection lane.

Physical

Inspection

N48

FD-POG-012 The Contractor shall ensure all components are vandal proof, installed out of public reach and/or in key locked cabinets.

Security

Inspection

N48

FD-POG-013 The POE GLS System equipment shall ensure continuous operation and not wear out by repeated opening and closing of gates.

Performance

Inspection

N48

FD-POG-014 The POE GLS System equipment shall provide fault free operation not requiring field adjustment or recalibration following installation.

Performance

Demonstration

N48

FD-POG-015 The POE GLS System equipment shall use a wired power connection to a 120/240 VAC 60Hz source which can supply the amperage necessary to operate all equipment.

Physical

Demonstration

N48

2.5 Point Vehicle Time Detection

The Point Vehicle Time Detection (PVTD) functionality shall identify unique vehicle tag IDs and timestamps within the OME Approach and Pre-Approach Zones required to determine wait times incurred at the OME Crossing.


213



VERIFICATION

NEED TRACE

FD-PVT-01 The PVTD System shall receive tag data from its radio frequency identification (RFID) field sensors.

Input

Test

N52

FD-PVT-01.1 The PVTD System shall receive Toll Probe Data from Commercial Vehicles via its toll tag RFID sensors.

Input

Test

N52

Figure 46: RBMS Field Device Point Vehicle Time Detection (PVTD) Architecture


214


VERIFICATION

NEED TRACE

FD-PVT-01.2 The PVTD System tag reading technology in the Border Crossing Approach Zones shall operate via radio frequency (RF) conforming to toll facilities operating in the state of California and Mexico, including:

a. ASTM E2213 (Dedicated Short Range Communication)

b. ISO 180006b

c. ISO 180006C

d. Title 21 / FasTrak

Performance

Test

N52

FD-PVT-01.3 The PVTD System shall receive Road Network Traffic Probe Data from Passenger Vehicles via its signature sensors (e.g.: Bluetooth or WiFi).

Input

Test

N52

FD-PVT-02 The PVTD System shall receive a local time reference from its GPS sensor. Input

Test

N52

FD-PVT-03 When the PVTD System receives updated point presence indications from field sensors, the PVTD System shall record the data with a timestamp based on the local time reference.

Process

Test

N52

FD-PVT-03.1 The RBMS PVTD readers shall use hashing or encryption (MD5 algorithm or more stringent) on all RF Tag IDs, WiFi MAC Addresses, or Bluetooth MAC Addresses collected prior to being sent back to the RBMS Central System, so as to prevent the transmission and collection of personally identifiable information.

Performance

Test

N52

FD-PVT-04 The PVTD System shall determine its own Health Status. Process

Test

N49

FD-PVT-04.1 If the PVTD System cannot receive field indications, then the PVTD System shall establish a System Alert.

Process

Test

N20

FD-PVT-04.2 If the PVTD System cannot determine a local time reference, then the PTVD System shall establish a System Alert.

Process

Test

N20


215


VERIFICATION

NEED TRACE

FD-PVT-05 The PVTD System shall transmit updated status data via a Connection Session [IF13]. Output

Test

N54

FD-PVT-05.1 The PVTD System shall transmit updated Toll Probe Data to the RBMS Central System from each reader location via an UDP feed, which specifically identifies the PVTD station number within five seconds.

Constraint

Test

N26, N52

FD-PVT-05.2 The PVTD System shall transmit updated Road Network Traffic Probe Data to the RBMS Central System.

Output

Test

N52

FD-PVT-05.3 The PVTD System shall transmit updated Health Status to the RBMS Central System. Output

Test

N49

FD-PVT-05.4 The PVTD System shall transmit updated System Alert information to the RBMS Central System.

Output

Test

N20

FD-PVT-05.5 If the Connection Session [IF13] is interrupted, then the PVTD System shall re-establish the Connection Session [IF13].

Output

Test

N54


2.5.2.1 General


VERIFICATION

NEED TRACE

FD-PVT-06 The Contractor shall install the PVTD System to monitor the border-bound direction of each zone only.

Physical

Inspection

N48


216


VERIFICATION

NEED TRACE

FD-PVT-06.1 The reader spacing shall not exceed ¼ mile within the one-mile distance of the POE inspection plaza.

Physical

Inspection

N48

FD-PVT-06.2 The Contractor shall install the last reader before the POE plaza within 120 feet of primary inspection.

Physical

Inspection

N48

FD-PVT-07 The PVTD System shall conform to manufacturer installation guidelines either on dedicated support structures, or structures erected for static signage or other ITS equipment. Where opportunity exists placement on bridges may be considered.

Physical

Inspection

N48

FD-PVT-08 Placement of PVTD shall conform to the construction of any roadway elements and not obstruct the view of any signs, cameras or signals.

Physical

Inspection

N48

FD-PVT-09 The PVTD System shall include all components required to generate and transfer the tag ID and timestamp data between the field readers to the RBMS via wired or wireless Ethernet based communication system.

Physical

Inspection

N48

FD-PVT-010 The PVTD System readers shall include all necessary power supply equipment to accept standard input voltage or solar power supply components capable of operating 24 hours per day, 7 days per week under the minimum average winter insolation conditions for the region.

Physical

Inspection

N48

FD-PVT-011 All reader types shall support static IP addressing and built in GPS for common time referencing and location data.

Performance

Demonstration

N55

FD-PVT-012 The PVTD System shall operate continuously with no regular field adjustments or recalibrations.

Performance

Demonstration

N48

FD-PVT-013 The PVTD System shall include a minimum two-year warranty against material and workmanship defects.

Performance

Inspection

N48


217



VERIFICATION

NEED TRACE

FD-PVT-014 All field installations shall conform to Caltrans guidelines and practices for installation construction of ITS equipment, conduits, cabinets and support structures.

Physical

Inspection

N48

FD-PVT-015 Placement of PVTD reader cabinets shall conform to equipment design constraints and distance limitations to the antennas.

Performance

Test

N48

FD-PVT-015.1 PVTD reader field cabinets shall include intrusion detection where possible. Performance

Test

N48

FD-PVT-016 The Contractor shall install all PVTD components out of public reach and/or in key locked cabinets.

Security

Inspection

N48

FD-PVT-017 As feasible, The Contractor shall install the PVTD System readers so that they are co-located with other field equipment (e.g.: RBMS Toll points) to share field cabinet, and communications and power connections.

Physical

Inspection

N48

FD-PVT-018 The PVTD System shall include any necessary licensing and authorization from the Federal Communications Commission (FCC) required to operate the equipment.

Performance

Analysis

N48



VERIFICATION

NEED TRACE

FD-PVT-019 The Contractor shall install PVTD System readers so that they are enclosed in a self-contained, field hardened unit consisting of the reader electronics, digital cellular modem and all required antennas.

Physical

Inspection

N48


218


VERIFICATION

NEED TRACE

FD-PVT-020 The Contractor shall install all PVTD components out of public reach, in key locked cabinets, or in other tamperproof enclosures with security features typical to the area to preserve equipment integrity.

Security

Inspection

N48

FD-PVT-021 The PVTD System shall include any necessary licensing and authorization from the Federal Telecommunications Institute (IFETEL) in Estados Unidos Mexicanos required to operate the equipment.

Performance

Analysis

N48

FD-PVT-022 The PVTD System readers within the Mexican Pre-Approach Zone shall receive Bluetooth, Wi-Fi or other signals from enabled vehicles traveling within the zone.

Input

Test

N52

FD-PVT-023 Mexican Pre-Approach Zone PVTD System readers shall conform to detection technologies which allow for wireless exchange of data.

Performance

Inspection

N26, N48, N52

FD-PVT-024 The PVTD System readers within the Mexican Pre-Approach Zones shall include cellular wireless service at each field unit providing a remote connection to the RBMS Communications Backbone to complete the tag matching and travel time calculations.

Performance

Test

N57

2.6 Vehicle Detection Station

Vehicle Detection Stations (VDS) shall be used to monitor traffic flow and queue formation resulting from vehicle volume build up, incidents or scheduled lane closures on the POE inbound and outbound lanes on both sides of the border.


219

Figure 47: RBMS Field Device - Vehicle Detection Station Architecture


220



VERIFICATION

NEED TRACE

FD-VDS-01 The VDS shall receive updated Occupancy Values from its field sensors. Input

Test

N53

FD-VDS-01.1 When the VDS receives updated Occupancy Values from field sensors, the VDS shall record the data with a timestamp.

Input

Test

N53

FD-VDS-02 The VDS shall receive Traffic Sensor Control (i.e.: configuration control parameters for the detector station) from the RBMS Central System.

Input

Test

N09

FD-VDS-03 The VDS shall determine Traffic Volume, Basic Classification and Direction at each of its sensor locations.

Process

Test

N53

FD-VDS-03.1 When determining Traffic Volume, the VDS shall determine separate values for Commercial and Passenger Vehicles using a Basic Classification determination.

Process

Test

N53

FD-VDS-03.2 Classification data shall provide counts for up to four classes of vehicles. Input

Test

N53

FD-VDS-03.3 When determining Traffic Volume, the VDS shall determine separate values for each Traffic Lane with a field sensor.

Process

Test

N53

FD-VDS-03.4 VDS shall determine volume detection accuracy at 95 percent per direction, 90 percent per lane minimum.

Performance

Test

N53

FD-VDS-04 The VDS shall determine the Occupancy Value at each of its sensor locations. Process

Test

N53

FD-VDS-04.1 When determining Occupancy Value, the VDS shall determine separate values for Commercial and Passenger Vehicles.

Process

Test

N53


221


VERIFICATION

NEED TRACE

FD-VDS-04.2 When determining Occupancy Value, the VDS shall determine separate values for each Traffic Lane with a field sensor.

Process

Test

N53

FD-VDS-04.3 VDS shall ensure occupancy detection accuracy to be ± 15 percent. Performance

Test

N53

FD-VDS-05 The VDS shall determine Vehicle Speed at each of its sensor locations with an accuracy of ± 3mph per lane.

Process

Test

N53

FD-VDS-05.1 When determining Vehicle Speed, the VDS shall determine separate values for Commercial and Passenger Vehicles.

Process

Test

N53

FD-VDS-05.2 When determining Vehicle Speed, the VDS shall determine separate values for each Traffic Lane with a field sensor.

Process

Test

N53

FD-VDS-05.3 VDS shall determine Vehicle Speed parameters over a speed range of 10 to 65mph. Input

Test

N53

FD-VDS-05.4 The VDS shall determine Average Vehicle Speeds at the roadside on a per lane basis, averaged continuously over a period of 20 seconds or less.

Performance

Analysis

N53

FD-VDS-06 The VDS shall determine its own Health Status. Process

Test

N49

FD-VDS-07 The VDS shall manage faults in determining Vehicle Speed, Traffic Volume, Occupancy Values , Direction and Basic Classification

Process

Test

N49

FD-VDS-07.1 If the VDS cannot receive field indications, then the VDS shall establish a System Alert. Process

Test

N20


222


VERIFICATION

NEED TRACE

FD-VDS-07.2 If the VDS cannot determine a Vehicle Speed, Traffic Volume, Occupancy Value then the VDS shall establish an Operational Alert.

Process

Test

N19

FD-VDS-08 The VDS shall transmit updated status data via a Connection Session [IF08]. Output

Test

N54

FD-VDS-08.1 The VDS shall transmit updated Vehicle Speed, Traffic Volume, Occupancy Value (including Parked Status when occupancy is 100%), and Direction to the RBMS Central System.

Output

Test

N53

FD-VDS-08.2 VDS data shall conform to NTCIP 1206 Object Definition for Data Collection. Performance

Test

N26

FD-VDS-08.3 The VDS shall transmit updated Health Status to the RBMS Central System. Output

Test

N49

FD-VDS-08.4 The VDS shall transmit updated System Alert and Operational Alert information to the RBMS Central System.

Output

Test

N19, N20

FD-VDS-08.5 If the Connection Session [IF08] is interrupted, then the VDS shall re-establish the Connection Session [IF08].

Output

Test

N54

FD-VDS-08.6 VDS shall transmit detection data, including the determined Average Vehicle Speeds, back to the RBMS Central System.

Output

Test

N53


223


2.6.2.1 General


VERIFICATION

NEED TRACE

FD-VDS-09 VDS shall determine volume, speed and occupancy on mainline traffic lanes and Freeway-to-Freeway ramps, in a continuous fashion.

Physical

Inspection

N48

FD-VDS-09.1 VDS shall determine volume, in a continuous fashion, only on arterial ramps or arterial approaches.

Physical

Inspection

N48

FD-VDS-10 The Contractor shall install VDS with other field equipment to share field cabinet, and communications and power connections.

Physical

Inspection

N48

FD-VDS-11 The Contractor shall install VDS so as not to interfere with the construction of any roadway elements or to obstruct the view of any signs, cameras or signals.

Physical

Inspection

N48

FD-VDS-12 The Contractor shall install VDS in each travel lane including ramps. Physical

Inspection

N48

FD-VDS-13 The Contractor shall install VDS at maximum spacing intervals of 1/4-mile in the inbound POE direction and 1/2-mile in the outbound POE direction.

Physical

Inspection

N48

FD-VDS-14 VDS placement shall provide any parameter change due to egress and ingress of vehicles. Physical

Inspection

N48

FD-VDS-15 The VDS equipment installation shall include all components required to provide and transmit the traffic data to the RBMS Central System.

Physical

Inspection

N48

FD-VDS-16 Each VDS shall include a unique identification number reflecting sequential placement of the sensor placement along the length of the roadway and identify traffic lane and direction.

Physical

Demonstration

N48


224


VERIFICATION

NEED TRACE

FD-VDS-17 VDS equipment shall include a minimum two- (2-) year warranty against material and workmanship defects.

Performance

Inspection

N48

FD-VDS-18 VDS equipment shall maintain calibration, requiring no field adjustments or recalibrations. Performance

Demonstration

N48



VERIFICATION

NEED TRACE

FD-VDS-19 All field installations shall conform to Caltrans guidelines and practices for installation of detection equipment.

Performance

Inspection

N48

FD-VDS-20 The Contractor shall ensure that the Installation limit be SR-11 from and including the 905/125/11 interchange to the split of car and truck lanes in the Approach Zone of the OME compound.

Physical

Inspection

N48

FD-VDS-21 The Contractor shall install all VDS components out of public reach and/or in key locked cabinets.

Security

Inspection

N48

FD-VDS-21.1 All VDS field cabinets shall include intrusion detection where possible. Security

Inspection

N48

FD-VDS-22 VDS equipment shall use a wired utility power connection to a 120/240 VAC 60Hz source which can supply the amperage necessary to operate all equipment.

Physical

Inspection

N48

FD-VDS-23 VDS within the RBMS region on the US side shall connect back to the wired RBMS Communications network.

Physical

Demonstration

N56


225



VERIFICATION

NEED TRACE

FD-VDS-24 All field installations shall conform to Baja California state and regional guidelines and practices for installation of detection equipment.

Performance

Inspection

N48

FD-VDS-25 The Contractor shall ensure the Installation limit is from the MX-2 interchanges to both the cargo and passenger vehicle dedicated access routes towards OME the entrance of the OME Compound.

Physical

Inspection

N48

FD-VDS-26 The Contractor shall install all VDS components out of public reach, in key locked cabinets, or other tamperproof enclosures with security features typical to the area to preserve equipment integrity.

Security

Inspection

N48

FD-VDS-27 The Contractor shall install VDS equipment with solar power supply components capable of operating 24 hours per day, 7 days per week under the minimum average winter insolation conditions for the region.

Physical

Inspection

N48

FD-VDS-28 VDS within the RBMS region on the Mexican side shall connect back to the RBMS Communications network via wireless connection.

Physical

Demonstration

N57

2.7 Variable Toll Message Signs

The Variable Toll Message Signs (VTMS) shall provide Border Wait Time and Toll Pricing in advance of travel decision points.


226

Figure 48: RBMS Field Devices - Variable Toll Message Signs Architecture


227



VERIFICATION

NEED TRACE

FD-VTM-01 The VTMS shall receive System Data as messages via a Connection Session [IF12]. Input

Test

N54

FD-VTM-01.1 The VTMS shall receive Roadway Information System Data from the RBMS Central System, including:

a. OME Border Wait Times for passenger and commercial vehicles both northbound and southbound of the border crossing

b. OMW Border Wait Time for passenger and commercial vehicles both northbound and southbound of the border crossing

c. San Ysidro Wait Time for passenger vehicles both northbound and southbound of the border crossing

d. OME Variable Toll Rates for passenger and commercial vehicles

Input

Test

N14

FD-VTM-02 The VTMS shall process received messages for display. Process

Test

N14

FD-VTM-03 The VTMS shall determine its own Health Status. Process

Test

N49

FD-VTM-04 The VTMS shall display messages on the variable block portions of the hybrid (i.e.: mix of static and variable) displays.

Output

Demonstration

N14

FD-VTM-04.1 The display placement, visibility, legibility, display configuration and maximum units of information per message displayed on the USA VTMS shall conform to the current edition of the California MUTCD.

Output

Demonstration

N14, N48

FD-VTM-04.2 The display placement, visibility, legibility, display configuration and maximum units of information per message displayed on the MEX VTMS shall conform to the Current edition of Manual De Dispositivos Para El Control Del Transito En Calles Y Carreteras.

Output

Demonstration

N14, N48


228


VERIFICATION

NEED TRACE

FD-VTM-04.3 The VTMS shall display a minimum of six characters of data. (i.e.: Closed). Maximum character limit will be defined during design.

Output

Demonstration

N14, N48

FD-VTM-05 The VTMS shall transmit status data via a Connection Session [IF12]. Output

Test

N54

FD-VTM-05.1 The VTMS shall transmit updated Health Status to the RBMS Central System. Output

Test

N49

FD-VTM-05.2 The VTMS shall transmit updated Roadway Information System Status (i.e.: confirmation of current message displayed on variable signage) to the RBMS Central System within five seconds.

Constraint

Test

N14

FD-VTM-05.3 VTMS shall display information related to wait times at alternative border crossings in the region (San Ysidro, Otay Mesa) to aid advance travel time/cost decisions by drivers.

Output

Test

N14

FD-VTM-05.3.1 The inclusion of information for particular alternative border crossings shall vary per sign, based on its placement within the roadway network upstream of specific decision points.

Output

Test

N14

FD-VTM-05.4 VTMS controller and communications protocol shall conform to the most recent version of the NTCIP standards including all approved or recommended amendments to these standards as of the same date.

a. NTCIP 1201: Global Object Definitions

b. NTCIP 1203: Object Definitions for Dynamic Message Signs (DMS)

c. NTCIP 2104: Ethernet Subnetwork Profile

d. NTCIP 2202: Internet (TCP/IP and UDP/IP) Transport Profile

Performance

Test

N26

FD-VTM-05.4.1 The VTMS shall ensure that the VTMS controller is accessible remotely and locally to perform maintenance and manage the display.

Performance

Demonstration

N14, N48


229


VERIFICATION

NEED TRACE

FD-VTM-05.5 If the Connection Session [IF12] is interrupted, then the VTMS shall re-establish the Connection Session [IF12].

Output

Test

N54

FD-VTM-05.5.1 The VTMS shall store default and Historic Data in the event of communication failures. Process

Test

N14


2.7.2.1 General


VERIFICATION

NEED TRACE

FD-VTM-06 VTMS shall include hybrid signs mostly static in nature, with a number of full matrix, color LED variable blocks to enable text and graphical symbol display.

Physical

Demonstration

N48

FD-VTM-06.1 Each Pixel in the VTMS shall individually connect to the controller to allow multicolor, graphics, and proportional font capability within the blocks.

Physical

Demonstration

N48

FD-VTM-07 VTMS shall display all English and Spanish characters including diacritics. Physical

Demonstration

N33

FD-VTM-08 VTMS shall provide information about current Border Wait Times at the San Ysidro crossing, OME crossing and the current OME Toll Rate.

Output

Test

N14

FD-VTM-08.1 The VTMS shall receive its variable component from the RBMS Central System through the RBMS Communications network.

Output

Test

N14

FD-VTM-09 VTMS form factor shall conform to MUTCD standards, dependent on the posted speed limit at sign location.

Physical

Inspection

N48


230


VERIFICATION

NEED TRACE

FD-VTM-09.1 On roadways where the posted speed limit is less than 50mph (80km/h), VTMS shall use a roadside, single footing for factor.

Physical

Inspection

N48

FD-VTM-09.2 On roadways where the posted speed limit exceeds 50mph (80 km/h), VTMS shall use a dual footing, overhead horizontal sign that covers all lanes of traffic.

Physical

Inspection

N48

FD-VTM-10 On single footing VTMS, VTMS shall use distinct sign instances to provide information for passenger and cargo vehicles.

Physical

Inspection

N48

FD-VTM-11 On dual footing overhead VTMS, VTMS shall display both passenger and cargo vehicle data on the same sign.

FD-VTM-12 The VTMS shall display only wait time and toll rates pertaining to general purpose lanes only.

Physical

Inspection

N14

FD-VTM-12.1 VTMS shall display no data pertaining to trusted traveler or secure trade lanes. Physical

Inspection

N14

FD-VTM-13 To the maximum extent possible, the VTMS shall display pictograms (e.g.: car, truck) for the static portions of the display, in order to minimize the amount of text to be read, and to facilitate understanding in a cross-border bilingual environment.

Physical

Inspection

N14, N48

FD-VTM-14 VTMS Pixels shall provide RGB color spectrum with spacing between Pixels no more than 1.3” / 34mm as measured from the center of one Pixel to the center of adjacent Pixels both horizontally and vertically with equal spacing between Pixels.

Physical

Demonstration

N48

FD-VTM-15 The sign case shall conform to the requirements of NEMA 3R outdoor enclosures. Physical

Inspection

N48

FD-VTM-16 LED Pixels shall support a rating for MTBF of 150,000 hours. Performance

Analysis

N48


231


VERIFICATION

NEED TRACE

FD-VTM-17 VTMS shall automatically adjust levels of luminous intensity according to ambient light conditions.

Performance

Test

N48

FD-VTM-18 VTMS shall include sign case, display elements, photocell sensor, controller, sign structure and footings and all other associated mechanisms and equipment required to form an operational display.

Physical

Inspection

N48

FD-VTM-19 All VTMS components shall support outdoor operation or be enclosed in an environmental enclosure designed for operation in the deployment area climate of Southern California/Northern Mexico.

Physical

Inspection

N48

FD-VTM-20 VTMS construction shall conform to NEMA TS 4-2005. Physical

Inspection

N48

FD-VTM-21 VTMS display shall provide individual LED boards that are easy to handle or replace. Physical

Inspection

N48

FD-VTM-22 VTMS shall support availability and accurately display data 99.95% of time. Performance

Inspection

N48

FD-VTM-23 The Contractor shall install all wiring between the VTMS sign case and the cabinets continuously, contained within the support structure and underground conduit.

Physical

Inspection

N48

FD-VTM-24 The VTMS cabinet sites may installed with other ITS equipment, as feasible and share field cabinet.

Physical

Inspection

N48

FD-VTM-25 The Contractor shall ensure that the VTMS be grounded in accordance with locally enforced Electrical Safety Code.

Physical

Inspection

N48


232



VERIFICATION

NEED TRACE

FD-VTM-26 VTMS field cabinets, support structures, footings, conduits and installation methods shall conform to the Caltrans standards for static signage and CMS, with the weight profile of the hybrid VTMS being between that of a static sign and a CMS.

Physical

Inspection

N48

FD-VTM-27 The Contractor shall install VTMS in border bound direction only:

a. On SR-905 upstream of La Media Rd (OM and OME info displayed)

b. On SR-905 upstream of the 905/125/11 interchange (OM and OME info displayed)

c. On SR-125 upstream of the 905/125/11 interchange (OM and OME info displayed)

d. On Enrico Fermi Dr. upstream of the entrance to SR-11 (OME info displayed)

Physical

Inspection

N48

FD-VTM-28 VTMS within the RBMS region on the US side shall display information in the English language.

Physical

Inspection

N33

FD-VTM-29 VTMS within the RBMS region on the US side shall connect back to the wired RBMS Communications network.

Physical

Demonstration

N56



VERIFICATION

NEED TRACE

FD-VTM-30 All field installations shall conform to Tijuana regional guidelines and practices for installation of static and variable message sign roadside equipment.

Physical

Inspection

N48

FD-VTM-31 The Contractor shall install VTMS in border bound direction only:

a. On Vía Rápida Oriente upstream of the junction to MX-2 (San Ysidro, OM an OME info displayed)

b. On MX-2 near Lago La Amistad upstream of the junction to Los Aztecas (OM and OME info displayed)

Physical

Inspection

N48


233


VERIFICATION

NEED TRACE

c. On Bulevar Héctor Terán-Terán upstream of the junction to MX-2 (OM and OME info displayed)

d. On MX-2 heading east upstream of the transfer to the passenger access to OME (OME info displayed)

e. On MX-2 heading west upstream of the transfer to the passenger access to OME (OM and OME info displayed)

f. On MX-2 heading east upstream of the transfer to the cargo access to OME (OME info displayed)

g. On MX-2 heading west upstream of the transfer to the cargo access to OME (OM and OME info displayed)

h. On De las Bellas Artes heading east upstream of the Chilpancingo access road (OM and OME info displayed)

FD-VTM-32 The site and field cabinet design shall ensure security and integrity of the equipment. Security

Inspection

N48

FD-VTM-33 VTMS within the RBMS region on the Mexican side shall display information in the Spanish language.

Physical

Inspection

N33

FD-VTM-34 VTMS within the RBMS region on the Mexican side shall connect back to the RBMS Communications network via wireless connection.

Physical

Demonstration

N57


234

3 RBMS Communications System

The RBMS Communications System will address the requirements to acquire data from field devices and hosts in real-time, consolidate this data on a high-reliability, secure and fault-tolerant network, and make it available with low-latency to system operators. The Communications System will also support full-duplex, real-time control of field devices by operators and sharing/re-dissemination of the gathered data to project partners and the general public through secure Wide Area Network (WAN) interfaces. A Network Management System will also form a requirement, in order to ensure optimal operation of the communications infrastructure going forward.

Figure 49: RBMS Communications Network Architecture


235

3.1 Real-Time Data Acquisition (US)

This function will support the edge/access level of the communications system for the United States side of the Otay Mesa East point of entry. It includes all Layer 2 switches, Small Form Pluggable transceivers, media converters, copper/fiber optic drop cables, copper/fiber optic patch cables, splice enclosures and patch panels required. On the United States side, Switchgear will link to field devices via primarily wireline connections. For the purposes of fault-tolerance the edge/access level of the communications system will be conceived with redundancy considerations, so as to eliminate a single point of failure to the maximum extent possible.

Figure 50: RBMS Communications Network Technology


236

3.1.1 US Side Port-of-Entry Area Wireline Access Network


VERIFICATION

NEED TRACE

IS-COM-001 A separate US Layer 2 Switching Device shall operate in a Caltrans standard communication system enclosure within 300 feet of each field device or field device group.

Physical

Inspection

N55

IS-COM-002 The US Layer 2 Switching Devices shall operate as 19-inch rack mountable or DIN rail mountable devices, including appropriate brackets and/or mounting hardware.

Physical

Inspection

N48

IS-COM-003 The US Layer 2 Switching Devices shall support the IEEE 802 specification family for hardware features implemented, including:

802.3u (Fast Ethernet 100 Mbps);

802.3z (Gigabit Ethernet 1000 Mbps fiber); and

802.3x (Full Duplex with flow control)

Performance

Demonstration

N26, N54, N55

IS-COM-004 Each US Layer 2 Switching Device shall support a minimum of 8x 100BASE-TX, full duplex, Power-over-Ethernet ports conforming to the 802.3at PoE+ standard.

Performance

Demonstration

N54, N55

IS-COM-004.1 Large groups of Field Devices supported by a switch shall include increased port count to support all devices with 25 percent spare port capacity.

Performance

Demonstration

N54, N55

IS-COM-005 Each US Layer 2 Switching Device shall support an additional 2x 1000BASE-LX, full duplex, gigabit SM fiber optic ports.

Performance

Demonstration

N54, N55

IS-COM-005.1 Each US Layer 2 Switching Device shall support switching Ethernet frames between each of their ports.

Performance

Demonstration

N54, N55

IS-COM-005.2 Each US Layer 2 Switching Device’s optical ports shall support hot-swappable Small Form Pluggable transceivers.

Performance

Demonstration

N54, N55

IS-COM-006 The US Layer 2 Switching Devices shall support 802.1p (QOS Priority Queuing) with eight (8) priority levels

Performance

Test

N54, N55


237


VERIFICATION

NEED TRACE

IS-COM-007 The US Layer 2 Switching Devices shall support 802.1q (Virtual Local Area Networks) with 255 simultaneous VLANs

Performance

Demonstration

N54, N55

IS-COM-008 The US Layer 2 switching devices shall support:

a. 802.1d (Spanning Tree Protocol);

b. 802.1w (Rapid Spanning Tree Protocol); and

c. 802.1s (Multiple Spanning Tree Protocol)

Performance

Test

N54, N55

IS-COM-009 The US Layer 2 switching devices shall support 802.3ad (Link Aggregation Control Protocol Port Trunking), with traffic load balancing

Performance

Demonstration

N54

IS-COM-010 The US Layer 2 switching devices shall support IGMP v1 and v2 with up to 255 multicast groups, including IGMP snooping and querying

Performance

Demonstration

N54, N55

IS-COM-011 The US Layer 2 switching devices shall exceed a minimum mean time between failures of 70,000 hours.

Performance

Inspection

N48

IS-COM-012 The US Layer 2 switching devices shall incorporate a field hardened design and shall conform to a temperature rating of 70o C/158oF and 10% to 95% non-condensing relative humidity

Physical

Inspection

N48

IS-COM-013 The US Layer 2 switching devices shall conform to EMI emission ratings as per FCC Part 15. Performance

Inspection

N48

IS-COM-014 The US Layer 2 switching devices shall accept external power through dual redundant integrated power supplies which accept input voltage of 115 VAC ± 15 percent, 60 Hz ± 5 percent.

Input

Demonstration

N48

IS-COM-014.1 Power supplies shall use IEC 60320 male connectors or hardwired screw block terminals with adequate protection for exposed wiring.

Physical

Inspection

N48


238


VERIFICATION

NEED TRACE

IS-COM-014.2 The Contractor shall provide two power supply cables of 6ft or longer terminated in a NEMA 5-15P plug connector with each Layer 2 switching device.

Physical

Inspection

N48

IS-COM-015 The Contractor shall provide twisted pair copper interface patch cables and connectors required to connect the US Layer 2 switching devices to local equipment and/or patch panels.

Performance

Demonstration

N48

IS-COM-015.1 Twisted pair copper interface path cables shall meet or exceed Outdoor Cat 6 rating, such as Commscope 6NF4+.

Performance

Demonstration

N48

IS-COM-016 The US Layer 2 Switching Devices shall support device management interfaces to allow for remote configuration and fault diagnostics.

Input

Demonstration

N38

IS-COM-016.1 The US Layer 2 Switching Devices shall include the following device management interfaces:

a. HTTP;

b. SNMPv3;

c. Telnet; and

d. SSH

Input

Demonstration

N38

IS-COM-017 For direct, out-of-band management, the US Layer 2 Switching Devices shall provide an RS-232 serial port for a console connection.

Input

Demonstration

N38

IS-COM-017.1 The US Layer 2 Switching Devices’ shall display default serial connection parameters on the device or in the documentation supplied.

Physical

Inspection

N38

IS-COM-017.2 The Contractor shall provide a console cable of appropriate length for the US layer 2 Switching devices to establish a console connection to a notebook computer.

Physical

Inspection

N38


239

3.2 Real-Time Data Acquisition (Estados Unidos Mexicanos)

This function will support the edge/access level of the communications system for the Mexican side of the Otay Mesa East point of entry. It includes all Wireless Access Points, transceivers, media converters, copper/fiber optic drop cables, copper/fiber optic patch cables, splice enclosures and patch panels required. On the Mexican side, Switchgear will link to field devices via either Wireless Access Points or Wired Layer 2 Switching Devices near the new Port-of-Entry. RBMS field devices further upstream on the northbound approach (e.g. approach VTMS) will be controlled via cellular connections. For the purposes of fault-tolerance the edge/access level of the communications system will be conceived with redundancy considerations, so as to eliminate a single point of failure to the maximum extent possible.

3.2.1 Mexican Side Port-of-Entry Area Wireless Mesh Access Network


VERIFICATION

NEED TRACE

IS-COM-018 A separate, pole mounted, outdoor rated, Mex Wireless Access Point shall operate within 70m (230ft) of each applicable field device or field device group.

Physical

Inspection

N55

IS-COM-019 The Mex Wireless Access Points shall operate as pole mountable, weatherproof devices and shall support outdoor installation. They shall include appropriate pole straps and/or mounting hardware.

Physical

Demonstration

N48

IS-COM-020 The Mex Wireless Access Points shall support the IEEE 802.11 specification family for hardware features implemented.

Performance

Test

N26, N54, N55

IS-COM-020.1 The Mex Wireless Access Points shall support, at a minimum:

a. 802.11n (Megabit MIMO Wireless Local Area Network, 5.8GHz); and

b. 802.11ac (Gigabit MIMO wireless Local Area Network, 5.8GHz); or

c. Latest applicable 802.11 standard

Performance

Test

N26, N54, N55

IS-COM-021 All Mex Wireless Access Point interfaces shall support encryption, employing the WPA2 (802.11i) standard or latest equivalent

Security

Test

N26, N59

IS-COM-022 The Mex Wireless Access Points shall support 802.1q (VLAN) 255 simultaneous VLANs Performance

Demonstration

N54, N55


240


VERIFICATION

NEED TRACE

IS-COM-023 Each Mex Wireless Access Point shall support a minimum of eight (8) distinct SSID, with each SSID having the capacity to be mapped to a distinct VLAN.

Performance

Test

N54, N55

IS-COM-024 The Mex Wireless Access Points shall operate in a mesh network, providing downlink connections to field devices and backhaul connections amongst themselves wirelessly, via distinct 802.11 control channels, operating in one of the following bands:

a. 5.15 GHz; or

b. 5.25 GHz; or

c. 5.47 GHz; or

d. 5.8 GHz

Performance

Demonstration

N54, N55

IS-COM-025 The Mex Wireless Access Point shall support 802.1x authentication, including Extensible Authentication Protocol and Protected EAP (EAP-PEAP)

Security

Test

N59

IS-COM-026 The Mex Wireless Access Points shall exceed a minimum MTBF of 70,000 hours. Performance

Inspection

N48

IS-COM-027 The Mex Wireless Access Points shall incorporate a field hardened design conforming to a temperature range of -22oF to 158oF and 10 percent to 95 percent non-condensing relative humidity

Physical

Inspection

N48

IS-COM-028 The Mex Wireless Access Points shall conform to free use frequency band regulations, as per the Instituto Federal de Telecommunicaciones.

Performance

Demonstration

N48

IS-COM-029 The Mex Wireless Access Points shall accept external power through dual redundant integrated power supplies which accept input voltage of 115 VAC ± 15 percent, 60 Hz ± 5 percent.

Input

Demonstration

N48

IS-COM-029.1 The Mex Wireless Access Points shall use IEC 60320 male connectors or hardwired screw block terminals with adequate protection for exposed wiring.

Physical

Demonstration

N48


241


VERIFICATION

NEED TRACE

IS-COM-029.2 The Contractor shall provide two power supply cables of 6ft or longer terminated in a NEMA 5-15P plug connector (or unconnectorized for hardwired connection to pole-mounted utility provided mains power source) with each Mex Wireless Access Point.

Physical

Demonstration

N48

IS-COM-030 The Mex Wireless Access Points shall support device management interfaces to allow for remote configuration and fault diagnostics, including all of the following:

a. HTTP;

b. SNMPv3,

c. Telnet; and

d. SSH

Input

Demonstration

N38

IS-COM-031 For direct, out-of-band management, the Mex Wireless Access Points shall provide an RS-232 serial port for a console connection.

Input

Demonstration

N38

IS-COM-031.1 Each Mex Wireless Access Point shall display default serial connection parameters displayed directly on the device or in the documentation supplied at each.

Physical

Inspection

N38

IS-COM-031.2 The Contractor shall provide a console cable of appropriate length with each Mex Wireless Access Point Field Device to establish a console connection to a notebook computer.

Physical

Inspection

N38

3.2.2 Mexican Side Port-of-Entry Area Wireline Access Network


VERIFICATION

NEED TRACE

IS-COM-032 A separate Mex Layer 2 Switching Device shall operate in an enclosure within 300 feet of each field device or field device group.

Physical

Demonstration

N55

IS-COM-033 The Mex Layer 2 Switching Devices shall operate as 19-inch rack mountable or DIN rail mountable devices including appropriate brackets and/or mounting hardware.

Physical

Demonstration

N48


242


VERIFICATION

NEED TRACE

IS-COM-034 The Mex Layer 2 Switching Devices shall support the IEEE 802 specification family for hardware features implemented.

Performance

Demonstration

N26, N54, N55

IS-COM-034.1 The Mex Layer 2 Switching Devices shall support, at a minimum, the following:

a. 802.3u (Fast Ethernet 100 Mbps);

b. 802.3z (Gigabit Ethernet 1000 Mbps fiber); and

c. 802.3x (Full Duplex with flow control)

Performance

Demonstration

N26, N54, N55

IS-COM-035 Each Mex Layer 2 Switching Device shall support a minimum of 8x 100BASE-TX, full duplex, Power-over-Ethernet ports.

Performance

Demonstration

N54, N55

IS-COM-035.1 Larger groups of Field Devices supported by Mex Layer 2 Switching Devices shall include enough ports to support all devices with 25 percent spare port capacity.

Physical

Demonstration

N54, N55

IS-COM-036 Each Mex Layer 2 Switching Device shall support an additional 2x 1000BASE-LX, full duplex, gigabit SM fiber optic ports.

Performance

Demonstration

N54, N55

IS-COM-036.1 Each Mex Layer 2 Switching Device shall support switching Ethernet frames between each of their ports.

Performance

Demonstration

N54, N55

IS-COM-036.2 Each Mex Layer 2 Switching Device shall support hot-swappable Small Form Pluggable transceivers.

Performance

Demonstration

N54, N55

IS-COM-037 The Mex Layer 2 Switching Devices shall support 802.1p (QOS Priority Queuing) with 8 priority levels

Performance

Test

N54, N55

IS-COM-038 The Mex Layer 2 Switching Devices shall support 802.1q (Virtual Local Area Networks) with 255 simultaneous VLANs

Performance

Demonstration

N54, N55


243


VERIFICATION

NEED TRACE

IS-COM-039 The Mex Layer 2 Switching Devices shall support:

a. 802.1d (Spanning Tree Protocol);

b. 802.1w (Rapid Spanning Tree Protocol); and

c. 802.1s (Multiple Spanning Tree Protocol)

Performance

Test

N54, N55

IS-COM-040 The Mex Layer 2 Switching Devices shall support 802.3ad (Link Aggregation Control Protocol Port Trunking), with traffic load balancing

Performance

Demonstration

N54

IS-COM-041 The Mex Layer 2 Switching Devices shall support IGMP v1 and v2 with up to 255 multicast groups, including IGMP snooping and querying

Performance

Demonstration

N54, N55

IS-COM-042 The Mex Layer 2 Switching Devices shall exceed a minimum mean time between failures of 70,000 hours.

Performance

Inspection

N48

IS-COM-043 The Mex Layer 2 Switching Devices shall incorporate a field hardened design conforming to a temperature rating of 158oF and 10 percent to 95 percent non-condensing relative humidity

Physical

Inspection

N48

IS-COM-044 The Mex Layer 2 Switching Devices shall conform to EMI emission ratings as per FCC Part 15.

Performance

Inspection

N48

IS-COM-045 The Mex Layer 2 Switching Devices shall accept external power through dual redundant integrated power supplies which accept input voltage of 115 VAC ± 15 percent, 60 Hz ± 5 percent.

Input

Demonstration

N48

IS-COM-045.1 The Mex Layer 2 Switching Devices shall use power supplies with IEC 60320 male connectors or hardwired screw block terminals with adequate protection for exposed wiring.

Physical

Inspection

N48

IS-COM-045.2 The Contractor shall provide two power supply cables of 6ft or longer and terminated in a NEMA 5-15P plug for each Mex Layer 2 Switching Device.

Physical

Inspection

N48


244


VERIFICATION

NEED TRACE

IS-COM-046 The Contractor shall provide twisted pair copper interface patch cables and connectors, meeting or exceed outdoor Cat 6 rating, such as Commscope 6NF4T, required to connect the Mex Layer 2 Switching Devices to local equipment and/or patch.

Performance

Demonstration

N48

IS-COM-047 The Mex Layer 2 Switching Devices shall support device management interfaces to allow for remote configuration and fault diagnostics, including the following:

a. HTTP;

b. SNMPv3,

c. Telnet; and

d. SSH

Input

Demonstration

N38

IS-COM-048 For direct, out-of-band management, the Mex Layer 2 Switching Devices shall provide an RS-232 serial port for a console connection.

Input

Demonstration

N38

IS-COM-048.1 The Mex Layer 2 Switching Devices shall display default serial connection parameters directly on the device or in the documentation supplied.

Input

Demonstration

N38

IS-COM-048.2 The Mex Layer 2 Switching Devices shall use a console cable of appropriate length to establish console connection to a notebook computer.

Physical

Inspection

N38

3.2.3 Mexican Side Port-of-Entry Pre-Approach Communications


VERIFICATION

NEED TRACE

IS-COM-049 Cellular communications shall transmit data from approach area Field Device upstream of the Port-of-Entry on the Mexican side

Performance

Demonstration

N57


245


VERIFICATION

NEED TRACE

IS-COM-050 The cellular communications system at each approach roadside field device cabinet shall include:

a. a Cellular Router inside the roadside cabinet;

b. an omnidirectional antenna mounted outside the cabinet;

c. a Cellular Data Plan and

d. a data interface cable to link the Cellular Router to an interface on the Field Device controller

Physical

Inspection

N48, N57

IS-COM-050.1 The cellular communications system at each approach roadside location on the Mexican side shall conform to US Caltrans standards including environmental control and vandal protection.

Physical

Inspection

N48, N57

IS-COM-050.2 The Service Provider shall establish electrical service from the local Mexican Utility company to power cabinets.

Physical

Inspection

N48, N57

IS-COM-051 The System Provider shall establish and support a Cellular Data Plan for each Cellular Router based upon the following: 12 months of cellular data service where the System Provider pays all activation and on-going service charges.

Input

Demonstration

N48, N57

IS-COM-052 The Cellular Router shall incorporate a field hardened design conforming to a temperature range up to 70 degrees Celsius (oC) (158oF) with relative humidity of 10 to 95 percent non-condensing.

Physical

Inspection

N48, N57

IS-COM-053 The Cellular Router shall support any particular telecommunications provider, conforming to Mexican Long Term Evolution (LTE) networks, with fallback to High Speed Packet Access depending on the availability of the network.

Performance

Demonstration

N48, N57

IS-COM-054 The Cellular Router shall include at least one, auto-negotiation 10/100 or 10/100/1000 BASE-TX port with RJ45 connector for establishing an Ethernet connection to the local field device controller.

Input

Inspection

N48


246


VERIFICATION

NEED TRACE

IS-COM-055 The Cellular Router shall support Network Address Translation with Port Forwarding, to ensure remote hosts on the US side of the Virtual Private Network (see Section 8.4.2.3) can communicate with devices connected on the router’s private LAN.

Performance

Demonstration

N55

IS-COM-056 The Cellular Router shall provide an ultra-reliable “always on” cellular connection with remote diagnostics, configuration and updates.

Performance

Test

N38, N49

IS-COM-056.1 The Cellular Router shall establish connection with the service provider upon power-up following a power reset.

Performance

Test

N38, N49

IS-COM-057 The Cellular Router shall include an HTTP server for remote device configuration over an IP network.

Performance

Test

N38

IS-COM-057.1 The Cellular Router shall support configuration via a direct console port serial link. Performance

Test

N38

IS-COM-057.2 The Contractor shall provide the Cellular Router with any additional software and applicable software licenses beyond a standard web browser if it required for remote configuration of a remote device.

Performance

Test

N38

IS-COM-057.3 The Cellular Router shall not require a power cycle after configuration changes are made. Performance

Test

N38

IS-COM-058 The HTTP configuration utility shall ensure password authentication for security. Performance

Test

N59


247


VERIFICATION

NEED TRACE

IS-COM-058.1 The HTTP configuration utility shall enable Users to remotely configure all necessary System parameters, including:

a. Private LAN and WAN Adapter IP configuration settings;

b. Routing and gateways;

c. Port-Forwarding configuration;

d. Network Address Translation configuration; and

e. SSL/TLS Based VPN settings.

Performance

Test

N59

IS-COM-059 The Cellular Router shall support SSL/TLS Based VPN tunneling with secure encryption based on the current US government mandated Advanced Encryption Standard to provide security for network traffic routed out through the WAN interface.

Security

Demonstration

N59

IS-COM-060 The Cellular Router shall include firewall functionality which allows administrators to establish specific IP addresses or blocks of IP addresses which will be granted or refused access to the modem’s network interfaces.

Security

Test

N59

IS-COM-061 The Cellular Router shall provide non-volatile storage for the retention of all configurable settings.

Performance

Test

N48

IS-COM-061.1 The Cellular Router shall enable the previously deployed configuration automatically pursuant to any power cycling of the device.

Performance

Test

N48

IS-COM-062 The Cellular Router shall accept external power using input voltage of 115 VAC ±15 percent, 60Hz ±5 percent with any necessary external power adapters/converters provided with the unit.

Input

Demonstration

N48

IS-COM-062.1 The Cellular Router shall use a maximum of 10 Watts power draw when transmitting. Input

Demonstration

N48


248


VERIFICATION

NEED TRACE

IS-COM-063 The Cellular Router shall include an external panel mountable antenna for Mexican Long Term Evolution and High Speed Packet Access frequencies, complete with connecting cable.

Physical

Inspection

N48, N57

IS-COM-064 The Contractor shall provide all interface cables and connectors required to connect the Cellular Router to the associated equipment and/or patch panels including all mounting hardware required for installation in EIA 480 millimeter (19-inch) equipment racks for ground level cabinets, or securely within a pole-mounted NEMA 4 enclosure where applicable.

Physical

Inspection

N48

3.3 Network Management

This function will support supervisory control and monitoring for the comprehensive Otay Mesa East RBMS network, extending from the Border Area real-time data acquisition access networks on the approaches in both countries, to the backhaul aggregation network bringing this data back to the RBMS Control Center, and the dissemination (or redistribution) component of the network. Simple Network Management Protocol (SNMP) v3, will be the management protocol of choice for supervisory control & monitoring functionality and a Network Management System (NMS) Server and Workstation will be present at the RBMS Control Center, to function as the user interface.

3.3.1 General


VERIFICATION

NEED TRACE

IS-COM-065 The NMS shall process the retrieval, storage, analysis and display of status information from all network devices attached to the system that are SNMPv3 and/or ICMP capable, independent of their vendor.

Performance

Test

N49

IS-COM-065.1 The NMS shall process remote configuration of SNMPv3 and/or ICMP capable network devices.

Performance

Test

N49


249


VERIFICATION

NEED TRACE

IS-COM-066 The NMS shall support viewing the network and its associated IP SNMPv3/ICMP enabled devices including field devices, field routers, consoles, Switchgear and other supported IP devices connected over the network

Performance

Test

N49

IS-COM-067 All communications system devices shall support remote network management and configuration capabilities and be managed devices.

Performance

Demonstration

N38, N49

IS-COM-067.1 At a minimum, the System network management/configuration shall display through:

a. a Graphical User Interface (GUI) over HTTP and HTTPS/SSL;

b. a command line interface through TELNET/SSH; and

c. a configuration management utility of the NMS.

Performance

Demonstration

N38, N49

IS-COM-068 All communications system devices shall support the ability to automatically disable and re-enable specific ports based on MAC/hardware address authentication of connected devices

Performance

Test

N38

IS-COM-069 All communications system devices shall support automated fault management functionality through SNMPv3.

Performance

Test

N49

IS-COM-070 The NMS shall provide real time Management Information Bases (MIBs) displays. Performance

Demonstration

N49

IS-COM-070.1 The NMS shall provide MIB variable data in tabular and graphical format based on User preference.

Performance

Demonstration

N49

IS-COM-070.2 The MIB displays shall provide various expressions such as utilization, percentage errors, and volumes.

Output

Demonstration

N49

IS-COM-071 The System Provider shall support SNMPv3 traps for all supported devices to be aggregated based on data supplied by the respective product manufacturers. SNMPv3 Traps and remote syslog logging must be established to transmit to the IP address of the NMS Server.

Input

Analysis

N49, N54


250


VERIFICATION

NEED TRACE

IS-COM-072 All communications system devices shall support the Remote Network Monitoring (RMON) management information database to enable network monitors and console systems to exchange network-monitoring data.

Performance

Test

N49

IS-COM-073 All wired communications system devices shall continually determine and provide external visible indication of:

a. Power status;

b. Link integrity on each electrical/optical port; and

c. Data activity on each electrical/optical port.

Output

Inspection

N49, N56

IS-COM-074 All wireless communications system devices shall continually determine and provide external visible indication of:

a. Power status;

b. Link integrity on each radio; and

c. Data activity on each radio.

Output

Inspection

N49, N57

IS-COM-075 The NMS platform provided for the RBMS Control Center shall provide the following functions:

a. Network discovery;

b. Topology mapping of network elements;

c. Event handling;

d. Performance data collection and graphical representation; and

e. Web browser based GUI

Performance

Demonstration

N49

IS-COM-076 The NMS shall include a site license and be scalable for management of service provider configurations.

Security

Inspection

N55

IS-COM-077 The NMS shall provide real-time monitoring of the entire network infrastructure enabling users to navigate with a graphical interface and easy to use network management tools.

Performance

Demonstration

N49, N54

IS-COM-078 The NMS shall provide event alerts to Users via: Output N18


251


VERIFICATION

NEED TRACE

a. Email;

b. On-screen alarm;

c. As an export XML feed; and

d. On demand, as an exported *.csv file for alarms latched during the time period selected.

Test

IS-COM-079 The NMS shall transmit reports automatically on a daily, weekly and monthly basis in formats including graphs, bar charts, distribution and summary.

Output

Test

N21, N22, N23, N24

IS-COM-079.1 The system shall support printing of these reports and also exporting the reports to other systems or web servers.

Output

Test

N21, N22, N23, N24

IS-COM-080 The NMS shall transmit notifications automatically to smartphone and offsite workstations for efficient response.

Output

Test

N25

IS-COM-081 The NMS shall display a simple map of the whole network as a tree enabling of direct selection of objects.

Output

Demonstration

N32

IS-COM-081.1 The system shall provide a navigation tree to display the current alarm status of each subnet.

Output

Demonstration

N32

IS-COM-081.2 The entire network shall support visibility in a single window with interface control supporting Pan/Zoom functionality.

Output

Demonstration

N32

IS-COM-082 The NMS shall enable the display of different colors for the links including red, green, orange, yellow, representing the status of the links and of the connected devices.

Output

Demonstration

N32

IS-COM-083 The NMS shall include polling agent functionality to aggregate status, changes or alerts from the local associated devices.

Performance

Test

N18

IS-COM-084 The NMS shall provide features for User authentication and accountability. Security N62


252


VERIFICATION

NEED TRACE

Test

IS-COM-084.1 The NMS shall record log files for any User access to configuration or platform changes. Security

Test

N62

IS-COM-085 The NMS User Interface shall provide different levels of security access, including:

a. Viewing;

b. Logging; and

c. Managing.

Security

Demonstration

N62

IS-COM-086 NMS hardware shall use IP addresses as provided by the RBMS Authority or their Designate.

Input

Demonstration

N55

IS-COM-087 The Contractor shall install and configure all hardware and software for the NMS as per the manufacturer’s recommended installation procedures.

Input

Demonstration

N54

IS-COM-088 The Contractor shall provide all license renewals and firmware upgrades to the RBMS Authority at no cost for a period of five (5) years.

Input

Demonstration

N65

3.3.2 NMS Server


VERIFICATION

NEED TRACE

IS-COM-089 The NMS Server shall support user authentication management providing a user session logging option.

Security

Test

N62


253

3.4 Data Backhaul to RBMS Control Center

This function will support the aggregation level communications system for the Otay Mesa East RBMS, which involves consolidating, routing and backhauling data from both sides of the Port-of-Entry back to RBMS Control Center in the South Bay Expressway facility. A node on this backbone network will also be included at the Airway Road Data Hub, in order to allow for center-to-center linkages between the RBMS Backbone and Partner Networks. Dynamic routing protocols and network security requirement will be included at this level of the communication system.

Figure 51: Border Region Fiber Optic Network


254

3.4.1 Backhaul of US Side Access Level Network


VERIFICATION

NEED TRACE

IS-COM-90 The Contractor shall install Distinct Layer 3 Routing Devices in enclosures at the minimum following node locations:

a. RBMS Control Center Node (South Bay Expressway Facility Equipment Room);

b. Caltrans Communications Data Hub Node (Airway Rd. Hub 13);

c. OME Port-of-Entry US CBP Facility Node; and

d. OME Port-of-Entry Mexican Aduanas Facility Node

Physical

Inspection

N55

IS-COM-91 The Contractor shall ensure the links between the RBMS Backbone nodes by using dark fibers on the existing SR-125, SR-905 and SR-11 fiber optic trunk cables.

Physical

Demonstration

N54, N55

IS-COM-92 The Contractor shall ensure the links between the RBMS Backbone nodes by using dark fibers on the existing SR-125, SR-905 and SR-11 fiber optic trunk cables.

Physical

Demonstration

N54, N55

IS-COM-93 The Contractor shall install spliced Optical fibers at appropriate interchange roadside vaults so as to connect the RBMS Backbone nodes in a closed ring.

Physical

Inspection

N54, N55

IS-COM-94 The Layer 3 routed link from the Mexican Aduanas facility node to the US CBP Facility Node shall transmit via the Interborder Communications Link.

Performance

Test

N55, N58

IS-COM-95 The Layer 3 Routing Devices shall support the ability to both switch Ethernet frames and route IP packets between each of their ports.

Performance

Test

N54, N55

IS-COM-96 The Layer 3 Routing Devices shall support the IEEE and IETF specification family for hardware features implemented, including:

a. Static routing;

b. Traffic prioritization;

c. Routing Information Protocol v1 and v2 [RFC 1058, RFC 2453]; and

d. Open Shortest Path First v2 [RFC 2328]

Performance

Test

N55


255


VERIFICATION

NEED TRACE

IS-COM-97 The Layer 3 Routing Devices shall support the Distance Vector Multicast Routing Protocol/Protocol Independent Multicast [RFC 1075, RFC 3973]

Performance

Test

N55

IS-COM-98 The Layer 3 Routing Devices shall support the Virtual Router Redundancy Protocol IP service [RFC 5798]

Performance

Test

N55

IS-COM-99 The Layer 3 Routing Devices shall support device management interfaces to allow for remote configuration and fault diagnostics, including the following:

a. HTTP;

b. SNMPv3,

c. Telnet; and

d. SSH

Input

Demonstration

N38

IS-COM-100 For direct, out-of-band management, the Layer 3 Routing Devices shall provide an RS-232 serial port for a console connection.

Input

Demonstration

N38

IS-COM-100.1 The Layer 3 Routing Devices shall display default serial connection parameters directly on the device or in the documentation supplied.

Input

Demonstration

N38

IS-COM-100.2 The Contractor shall provide a console cable of appropriate length with each device to establish a console connection to a notebook computer.

Input

Demonstration

N38

3.4.2 Interborder Communications Link


VERIFICATION

NEED TRACE

IS-COM-101 The System shall maintain a dual, uninterruptable interborder communications link, linking the Mexican side POE Access Network and the US side POE Access Network.

Performance

Test

N58, N59


256


VERIFICATION

NEED TRACE

IS-COM-101.1 The communications link shall operate two independent transmission methods:

a. Wireless point-to-point link on air interface across the international border threshold; and

b. Secure public internet SSL/TLS Based VPN.

Performance

Test

N58, N59

IS-COM-102 The dual, uninterruptable interborder communications link shall maintain both communications paths available at all times, in order to maintain link viability and integrity.

Performance

Test

N58, N59

IS-COM-102.1 Data traffic on the interborder communications link shall preferentially be transmitted over:

a. Wireless when available and

b. Internet SSL/TLS Based VPN when method (a) Wireless is unavailable.

Performance

Test

N58, N59

IS-COM-102.1.1 The interborder communications link shall operate an automatic network control mechanism to enforce these transmission priorities for the link.

Performance

Test

N58, N59

3.4.2.1 Wireless Point-to-Point Link


VERIFICATION

NEED TRACE

IS-COM-103 A wireless point-to-point link shall operate between the Mexican side POE access network and the US side POE Access Network.

Performance

Demonstration

N54, N57

IS-COM-104 The wireless link shall ensure a minimum bitrate of 100Mbps of full duplex throughput at a link distance of 200 meters (650 feet).

Constraint

Test

N54, N57

IS-COM-104.1 The end to end latency introduced by the transmission of data from the wireless link through its paired transceivers shall not exceed five (5) milliseconds.

Constraint

Test

N54, N57


257


VERIFICATION

NEED TRACE

IS-COM-105 The wireless link shall support operation at full rated bitrate in both rainy and windy environmental operating conditions.

Performance

Demonstration

N54, N57

IS-COM-106 The wireless link shall operate in either the common American-Mexican unlicensed spectrum (typ. 5.8 GHz band) or a mutually acceptable FCC/IFT public safety licensed band on both sides of the border (typ. 4.9GHz).

Performance

Test

N54, N57

IS-COM-106.1 In case of licensed band system operation, the System Provider shall ensure all licensing costs and/or administrative fees.

Performance

Test

N54, N57

IS-COM-106.2 In the case of licensed band system operation, the System Provider shall ensure all licensing costs and/or administrative fees.

Performance

Test

N54, N57

IS-COM-107 The wired network interface of the wireless link transceivers shall conform to the specifications of IEEE 802.3 100BASE-TX Ethernet.

Performance

Demonstration

N54

IS-COM-108 The wireless link transceivers shall support device management interfaces to allow for remote configuration and fault diagnostics, including all of the following:

a. HTTP;

b. SNMPv3,

c. Telnet; and

d. SSH

Input

Demonstration

N38

IS-COM-109 The wireless link transceivers shall support secure encryption based on the current US government mandated Advanced Encryption Standard for link security

Security

Demonstration

N59


258

3.4.2.2 Secure Internet VPN Link


VERIFICATION

NEED TRACE

IS-COM-110 A virtual, Internet SSL/TLS Based VPN-based link shall operate between the Mexican side POE Access Network and the US side POE Access Network.

Performance

Demonstration

N59

IS-COM-110.1 The Internet SSL/TLS Based VPN-based link shall include SSL/TLS based VPN-enabled interface to the public Internet via an Internet Service Provider (ISP), on either end of the link.

Performance

Demonstration

N59

IS-COM-111 The Service Provider may use any WAN medium available (including cable, DSL or serial) for last-mile connections to the Internet Service Providers on either end of the link, provided that high reliability and the minimum required throughput is ensured.

Performance

Test

N54, N55

IS-COM-112 The SSL/TLS Based VPN link shall support tunneling with secure encryption based on the current US government mandated Advanced Encryption Standard to provide security for network traffic.

Security

Demonstration

N59

IS-COM-113 The Internet SSL/TLS Based VPN link shall be used as a backup method to transmit and receive data directly between the OME Port-of-Entry US CBP Facility Node and the Mexican border approach field device sites which communicate over cellular-based links

Performance

Test

N55

3.5 Data Dissemination to Partners

This function will address the re-exporting of processed information from the RBMS Control Center via the Data Hub to the various project partners. The re-dissemination will take place largely over the backhaul network outlined in Section 1.1.1, on which the Data Hub also maintains a node. While the data processing requirements for the re-dissemination of data will be addressed in separate sections, this section will address the requirements from a network consideration.


259


VERIFICATION

NEED TRACE

IS-COM-114 The RBMS Control Center shall transmit processed data, destined for project partners via:

a. the RBMS Backbone Network; and

b. the public Internet

Output

Test

N43, N54

IS-COM-115 Over the RBMS Backbone Network which contains nodes at the RBMS Control Center and Caltrans Communications Data Hub Node (Airway Rd.), the RBMS Backbone Network shall establish a network routable path for the duplex transmission of processed data between the RBMS Control Center and the Caltrans communications Data Hub.

Output

Test

N43, N54

IS-COM-116 Over the RBMS Backbone Network which contains nodes at the RBMS Control Center and the OME Port-of-Entry on US side, the RBMS Backbone Network shall establish a routable network path for the duplex transmission of processed data between the RBMS Control Center and US OME POE Node.

Output

Test

N43, N54

IS-COM-117 Over the RBMS Backbone Network which contains nodes at the RBMS Control Center and OME Port-of-Entry US CBP Facility and through the routed Interborder Communications Link, the RBMS Backbone Network shall establish a routable network path for the duplex transmission of processed data between the RBMS Control Center and Mexican OME POE Node.

Output

Test

N43, N54

IS-COM-118 The RBMS Control Center shall maintain the capability to send out reformatted Operational Data via:

a. SMS;

b. Social media (min. Twitter); and

c. Email (typ. IMAP Server)

Output

Test

N42, N43

IS-COM-119 A suitable Firewall shall ensure the RBMS Control Center public Internet connection, with support for SSL/TLS Based VPN tunneling with secure encryption based on the current US government mandated Advanced Encryption Standard to provide security for traffic routed out through the wide area network to external hosts.

Security

Demonstration

N59


260

4 System Quality (Non-Functional) Requirements

This section of the requirements defines non-functional System quality requirements used to evaluate the performance of the System broken into two broad categories of external quality, such as install-ability, and internal quality, such as scalability.

4.1 External Quality Attributes

4.1.1 External Quality Requirements


VERIFICATION

NEED TRACE

SQ-EXT-01 The System shall support install-ability. Performance

Test

N66

SQ-EXT-01.1 The System shall conform with USDOT Standards, including the following:

a. dielectric strength specifications

b. EMC/EMI specifications

c. abrasion resistance specifications

d. mechanical shock and vibration specifications

e. temperature and humidity specifications

Physical

Test

N66

SQ-EXT-01.2 The usage of hazardous substances on the System shall conform to the Stakeholders’ safety program.

Performance

Test

N66

SQ-EXT-02 The Contractor shall ensure that the System is built with integrity. Performance

Test

N66

SQ-EXT-02.1 When the System operation is compromised, the System shall provide a mechanism for performance recovery to the RBMS User within 5 minutes.

Performance

Test

N66

SQ-EXT-02.2 If a failure occurs in the System, the System shall transition into degraded mode(s) of operation prior to a catastrophic failure mode.

Performance

Test

N64


261


VERIFICATION

NEED TRACE

SQ-EXT-02.2.1 Each degraded mode of operation shall enable provision for recovery to the next highest level of operation. (i.e.: via operator Intervention or automatic reset).

Performance

Test

N64

SQ-EXT-03 The System shall support measurable performance. Performance

Test

N60

SQ-EXT-03.1 The list of measured performance parameters shall include:

a. RTOS (Context) Thread Switching Latency (uSec)

b. Processor Utilization (Percent)

c. Processing Operations Per Second (FLOPS)

d. Dynamic Memory Utilization (Percent)

e. Static Memory Utilization (Percent)

f. Server Memory Utilization (Percent)

g. User Interface Haptic Feedback Latency (mSec)

h. Input Latency (Network Port to DRAM/register) (uSec)

i. Bit Error Rate (BER - all serial bus data)

j. Live Data Record Retrieval Latency (mSec)

k. Historic Data Record Retrieval Latency (mSec)

l. Maximum Data Record Retrieval Latency (mSec)

m. Internal Fault Detection Latency (uSec)

n. Internal Network Latency (Internal Ping - mSec)

o. Internal Network Bandwidth (bps)

p. Maximum External Latency (remote System Workstation Ping to/from RCC Workstation/server - mSec)

q. Minimum External Network Bandwidth (bps) between remote Workstation and RCC Workstation/server

r. I/O Fault Detection Latency (mSec)

Performance

Test

N60


262


VERIFICATION

NEED TRACE

SQ-EXT-03.2 Each performance parameter listed in this specification shall use an associated load test case (scenario).

Performance

Test

N60

SQ-EXT-03.3 The System Performance design shall include the following classifications and levels:

a. Support of the entire SR-11/OME Region

b. Support Inputs/Outputs associated with the above loading classifications

c. Support Simulation operation for the above loading classifications

Performance

Test

N60

SQ-EXT-03.4 System Processor shall operate under 50% utilization under each loading scenario. Performance

Test

N60

SQ-EXT-03.5 System memory shall operate under 50% utilization under each loading scenario. Performance

Test

N60

SQ-EXT-03.6 Each performance parameter shall include a design margin subject to approval by the Engineer.

Performance

Demonstration

N60

SQ-EXT-04 The System shall support necessary reliability and availability. Performance

Test

N60

SQ-EXT-04.1 When functions are classified as "High Criticality", mean time between System access failures (MTBSAF) shall exceed 2208 hours (92 Days).

Performance

Test

N60

SQ-EXT-04.1.1 When functions are classified as "Medium Criticality", MTBSAF shall exceed 1080 hours (45 days).

Performance

Test

N60

SQ-EXT-04.1.2 When functions are classified as "Low Criticality", MTBSAF shall exceed 336 hours (14 days).

Performance

Test

N60

SQ-EXT-04.1.3 The Contractor shall ensure that the minimum MTBSAF be 730 hours (30 days). Performance

Test

N60


263


VERIFICATION

NEED TRACE

SQ-EXT-04.2 The Contractor shall ensure that the maximum System Mean Time to Replace (MTTR) be two (2) hours for restoration of functionality.

Performance

Test

N60

SQ-EXT-04.3 Restoration of functionality requiring a temporary measure, final repair (i.e.: closure of the issue) shall not exceed a time frame of 45 days since the initial failure.

Performance

Test

N60

SQ-EXT-04.4 The Contractor shall ensure that the minimum availability for the System be 0.9973. Performance

Test

N60

SQ-EXT-04.5 The System shall include FRACAS functionality. Performance

Test

N60

SQ-EXT-04.5.1 The System FRACAS functionality shall connect with diagnostics functionality within the System.

Performance

Test

N60

SQ-EXT-04.6 When equipment is used in a redundant configuration on the System, the Contractor shall ensure that the common cause failure Beta factor is less than 5 percent in compliance with the Beta plus method.

Performance

Test

N60

SQ-EXT-04.7 The Contractor shall ensure the System is realized using a service-proven, extant subsystem elements.

Performance

Test

N60

SQ-EXT-04.8 The Contractor shall ensure that the System is realized with no Single Point of Failure (SPOF) responsible for a failure to complete functionality with a High Criticality rating.

Performance

Test

N60

SQ-EXT-04.8.1 The Contractor shall ensure that each System SPOF is documented with failure mode and effects analysis in compliance with system reliability, availability and maintainability.

Performance

Test

N60

SQ-EXT-04.8.2 The Contractor shall ensure that each System SPOF is constrained to fail in a controlled manner.

Performance

Test

N60


264


VERIFICATION

NEED TRACE

SQ-EXT-05 The System shall support maintenance activities. Performance

Test

N65

SQ-EXT-05.1 When an element in the System requires periodic maintenance, The Contractor shall ensure that a maintenance schedule is managed within the system.

Performance

Test

N65

SQ-EXT-05.1.1 Prior to an element in the System reaching its periodic maintenance threshold point, the system shall transmit a notice event for action by the maintenance role.

Performance

Test

N65

SQ-EXT-05.1.2 When an element in the System reaches its periodic maintenance threshold point, the system shall transmit an Alert Event for action by the maintenance role.

Performance

Test

N65

SQ-EXT-05.2 Mean Time To Diagnose (MTTD) shall not exceed 0.25 hours for each Line Replaceable Unit (LRU).

Performance

Test

N65

SQ-EXT-05.3 MTTD shall not exceed 1 hour for each LLRU. Performance

Test

N65

SQ-EXT-05.4 Mean Time To Replace (MTTR) shall not exceed 0.5 hour for each LRU Performance

Test

N65

SQ-EXT-05.5 Mean Time To Replace (MTTR) shall not exceed 2 hours for each LLRU. Performance

Test

N65

SQ-EXT-05.6 The System shall provide Configuration Data for each LRU configurable item in compliance with the Configuration Management process.

Performance

Test

N65

SQ-EXT-05.7 The System shall provide Configuration Data for each LLRU configurable item in compliance with the Configuration Management process

Performance

Test

N65


265


VERIFICATION

NEED TRACE

SQ-EXT-05.8 The System shall ensure that the System Configuration Status is available both remotely through the system Local Area Network (LAN), Wide Area Network (WAN), and locally at each LRU diagnostic port.

Performance

Test

N65

SQ-EXT-05.9 The System Configuration Management subsystem shall determine Configuration Data of each LLRU present in the system without manual intervention.

Performance

Test

N65

SQ-EXT-05.10 The System Configuration Management subsystem shall determine Configuration Data of each LRU present in the system without manual intervention.

Performance

Test

N65

SQ-EXT-05.11 The System shall conform to IS0 2000:2011 Information Technology - Service Management.

Performance

Test

N65

SQ-EXT-06 The System shall support Stakeholder safety programs. Performance

Test

N61

SQ-EXT-06.1 The System shall conform to the System Hazard and Operability Analysis provided by the Contractor.

Performance

Test

N61

SQ-EXT-07 The Contractor shall ensure that the System is secure. Performance

Test

N62

SQ-EXT-07.1 The System and its constituent subsystems, including the production environment, STF, and Training Environment shall conform to the System Security Plan (SSP).

Performance

Test

N62

SQ-EXT-07.1.1 The Contractor shall determine and implement the SSP; a comprehensive security plan and process that ensures that unauthorized users are denied access to the System.

Performance

Test

N62

SQ-EXT-07.1.2 The Contractor shall ensure that the security design as described in the SSP is based on a comprehensive threat analysis of the system components and the integration of these components.

Performance

Test

N62


266


VERIFICATION

NEED TRACE

SQ-EXT-07.1.3 The SSP shall ensure the three principal requirements for information security (Confidentiality, Integrity, and Availability) and have sections that cover security-related topics such as:

a. Compliance with System Security Policies

b. Security Fundamentals

c. Organizational Security Measures

d. Network Security

e. Computer Hardening

f. Operating System Security

g. Data and Control Flows

h. Threat Model

i. RBMS Security Design

j. File Transfer Security

k. Database Security

l. Authorization

m. Encryption

n. Interconnectivity between Facilities and SBX Facility

Performance

Test

N62

SQ-EXT-07.2 The System shall conform to Information technology - Security techniques - Code of practice for information security controls [ISO/IEC 27002].

Performance

Test

N62

SQ-EXT-07.3 The System shall ensure that Users are granted electronic access to the System pursuant to User Credentials.

Performance

Test

N62

SQ-EXT-07.4 The System shall ensure that access to the System is hierarchical, in accordance with the role associated with each User Credential.

Performance

Test

N62

SQ-EXT-08 The Contractor shall ensure that the System is usable. Performance

Test

N63


267


VERIFICATION

NEED TRACE

SQ-EXT-08.1 The Contractor shall ensure that all Human Interface devices (audible, visual and tactile) comply with Human Factors System Analysis Report.

Performance

Test

N63

SQ-EXT-08.2 The Contractor shall ensure that the System collects, processes and transmits all information elements required by User Roles in compliance with the Critical Task Analysis Report.

Performance

Test

N63

SQ-EXT-08.3 The Contractor shall ensure that the System provides the critical information required by all identified Roles in compliance with the Critical Task Analysis Report.

Performance

Test

N63

SQ-EXT-08.4 The Contractor shall ensure that System service and operational documentation is fully comprehendible to a person with a Grade 5 reading level, as scored using the Flesch–Kincaid Grade Level Formula methodology.

Performance

Test

N63

SQ-EXT-08.4.1 The Contractor shall ensure that warning notices are fully comprehendible to a person with a Grade 5 reading level as scored using the Flesch–Kincaid Grade Level Formula methodology.

Performance

Test

N63

SQ-EXT-08.4.2 The Contractor shall ensure that labels are fully comprehendible to a person with a Grade 5 reading level as scored using the Flesch–Kincaid Grade Level Formula methodology.

Performance

Test

N63


268

4.2 Internal Quality Attributes

4.2.1 Internal Quality Requirements


VERIFICATION

NEED TRACE

SQ-INT-01 The Contractor shall ensure that the System is modifiable. Performance

Test

N65

SQ-INT-02 The System shall conform to the System Lifecycle Support Plan. Performance

Test

N65

SQ-INT-02.1 The System's estimated Service Life from Beneficial Use until replacement or disposal shall exceed 20 years.

Performance

Test

N65

SQ-INT-02.2 The System Lifecycle Support Plan shall conform to the principles and framework provided in ISO/IEC/IEEE P24748 (Draft International Standard for Systems and Software Engineering – Life Cycle Management).

Performance

Test

N65

SQ-INT-02.3 The Contractor shall provide a comprehensive Spares Plan, as part of the System Lifecycle Support Plan incorporating the following factors:

a. Complete Spares List (all LRUs)

b. MTBF estimates for each LRU

c. Confidence level for each LRU MTBF Estimate

d. Probability of Repair for each LRU

e. Probability of Obsolescence for each LRU

f. Recommended Spare (Yes/No) classification for each LRU

g. Budgetary cost for each LRU

Physical

Analysis

N65

SQ-INT-02.3.1 The Contractor shall ensure that the Spares List is synchronized and updated with each System configuration change.

Physical

Analysis

N65


269


VERIFICATION

NEED TRACE

SQ-INT-02.4 The Contractor shall ensure that the initial spares budget is limited to 10 percent of the total cost of all System hardware.

Physical

Analysis

N66

SQ-INT-02.4.1 The RBMS authority shall maintain the right to re-allocate the Spares Budget. Physical

Analysis

N66

SQ-INT-02.5 The initial delivery of the System shall include one (1) spare for each LRU. Physical

Analysis

N66

SQ-INT-03 The System shall maintain functionality when the Operating System Software Code is changed.

Performance

Test

N65

SQ-INT-04 The System shall ensure that functionality not associated with the functional intent of the change is preserved when the System Application Code is changed.

Performance

Test

N65

SQ-INT-05 The System shall ensure that functionality not associated with the functional intent of the change is preserved when each System Configuration Parameter is changed.

Performance

Test

N65

SQ-INT-06 The Contractor shall ensure that the System is scalable. Performance

Test

N65

SQ-INT-06.1 The Contractor shall ensure that System functionality is greater or equal to previous functionality when the System platform configuration is expanded (i.e.: additional processors, memory, data storage, I/O, etc.).

Performance

Test

N65

SQ-INT-06.2 The Contractor shall ensure that System Performance levels are greater or equal to previous levels when the System platform configuration is expanded (i.e.: additional processors, memory, data storage, I/O, etc.).

Performance

Test

N65

SQ-INT-06.3 The Contractor shall ensure that the transient levels used for capacity planning calculations are based on empirical data.

Performance

Analysis

N65


270


VERIFICATION

NEED TRACE

SQ-INT-06.3.1 The Contractor shall ensure that the design margin of 20 percent is used in capacity planning calculations for the System.

Performance

Analysis

N65

SQ-INT-06.3.2 Each performance parameter shall include a design margin that includes capacity planning subject to approval by the Engineer.

Performance

Analysis

N65

SQ-INT-07 Wherever appropriate, The System shall use IEEE 1609.2 digital signatures, encryption and certificates for secure communication between System components

Security

Test

N62


271

Referenced Terms

Glossary Terms

* Indicates National ITS Architecture Term

TERM NAME DEFINITION

Aggregated Values Values that represent accumulations of other values, typically utilized to gain faster understanding of a situation or condition.

Alert* A classification of an event that has happened, typically communicated to a User, indicating an exception to the operating or business rules of traffic operations (i.e.: Operational Alerts) or the system itself (i.e.: System Alerts). Alerts predicate exception handling by the User or the System. Alerts can be audible and/or visual.

Approach Lane Variable Message Sign (VMS) System

An External Interfacing System to the RBMS central system; also an RBMS Field Device. A system which receives and displays VMS messages to the traveling public, facilitating traffic and demand management at the Border Crossing.

Approach Zone A region in advance of a Lane Allocations Zone where traffic management field devices are managed (i.e.: "controlled") by RBMS and/or other Systems, in order to provide instruction (e.g.: Lane Status) or guidance (e.g.: Lane Clearance Type) to vehicles to move between lanes, to manage their speed, or exit the border crossing in response to field conditions monitored by RBMS and its Users in the Approach Zone and adjoining zones.

Audit Trail A detailed list of changes made to a configuration item of the System. These include items such as the parameter adjusted, rationale for the adjustment, devices affected, etc.

Automated Incident Video Detection

Detects abrupt changes in traffic conditions in real time using CCTV and automatically alerts RBMS Users without undue delay.

Automatic Payment Terminal (APT) Device allowing drivers to pay toll fees through cash or electronic payment with no interaction with toll system personnel.

Barrier System Status* Current operating status of barrier systems. Barrier systems represent gates, barriers and other automated or remotely controlled systems used to manage entry to roadways. Status of the systems includes operating condition and current operational state.


272


Bluetooth Proprietary open wireless technology standard for exchanging data over short distances (using short wavelength radio transmissions in the ISM band from 2400-2480 MHz) from fixed and mobile devices.

Border Data for Broadcast * This data flow contains information concerning border crossing facilities needed to support the broadcast traveler information application. This data includes status information including border wait times, queue lengths, closures, incidents, and lane assignments.

Border Crossing See Port-of-Entry

Border Crossing Time The time it takes for a vehicle to exit the border crossing process after it joins the queue before CBP or Aduanas primary inspection booth.

Border Environment The environmental climate and impacted conditions on the roadway and other Border Crossing facilities.

Border Infrastructure Equipment and facilities, and associated details thereof (e.g.: type, location) at the Border Crossing.

Border Operations Data Report A Report containing details of the condition of the operational arena knowable to RBMS across all of the Regional Zones. Operations details may represent individual, collective, or calculated values, consistent with the newest version of the Traffic Management Data Dictionary (TMDD).

Border Operational Status Collective term for status indications regarding the condition of the operational arena knowable to RBMS across all the Regional Zones (i.e.: Greater San Diego Traffic Zone, Greater Tijuana Traffic Zone, San Ysidro Border Crossing, OMW Border Crossing, OME Border Crossing) via Interfacing Systems (i.e.: RBMS Field Devices, External Systems) and internal calculation and evaluation by RBMS. Individual status indications will be developed during design and implementation consistent with the ultimate configuration of the facility. This data includes: Traffic Status, Traffic Management Status, Road Works Management Status, Incident Management Status, Border Services Status, Environmental & Infrastructure Status, Aggregated Values Status, and System (op. impacting) Status.

Border Wait Time The time it takes for a vehicle to reach CBP’s or Aduanas primary inspection booth after it arrives at the end of the queue leading up to the primary inspection.

Broader Traffic Management The activities of planning, influencing, and monitoring traffic behavior in the San Diego/Tijuana Region surrounding the US-Mexico Border.


273


Buffer Index Expresses the amount of extra time needed to cross the border to be on-time 95 percent of the time. Indexing the measure provides a time and distance neutral measure calculated for each road segment and a weighted average calculated using vehicle-miles of travel as the weighting factor.

Camera Type Border Wait Queue Camera or regular traffic camera.

Cat 6 Category 6 cable, commonly referred to as Cat 6, is a standardized twisted pair cable for Gigabit Ethernet and other network physical layers that is backward compatible with the Category 5/5e and Category 3 cable standards

Cellular Data Plan A cellular provider data plan set up and paid for by the System Provider for the purposes of linking RBMS Field Devices to the RBMS Central System.

Cellular Router A cellular provider Layer 3 device set up and paid for by the System Provider for the purposes of linking RBMS Field Devices to the RBMS Central System via a cellular network

Connection Session A semi-permanent period of information exchange between the RBMS and an External Interfacing System governed by their common interface design standard.

Contractor A person or company that undertakes a contract to provide materials and/or labor to perform a service or do a job.

Current Data Data for events happening in real time provided to the RBMS from native RBMS field devices and External Interfacing Systems.

Data Age The length of time that data has been stored.

Data Hub An External Interfacing System to RBMS [IF-XX] that provides operational data from other zones in the region.

Data Item A piece of information within the RBMS purview.

Data Repository A location where Data Items are retained for future use.


274


Data Retention The continued storage of data for compliance or business reasons.

Data Store A location where Data Items are retained for current or future use.

Data Transfer The process of copying or moving data from one place to another, either via a direct connection or through a network.

Default Safety Plan A predetermined Traffic Management procedure defined in the design stage for use in situations when traveler safety is in question and where other Traffic Management plans cannot be implemented.

Demonstration A verification and validation procedure conducted under controlled circumstances and variables to show the existence of a property or feature of the system to a specific stimulus (i).

Departure Zone A region in advance of a Pre-Approach Zone (i.e.: the wider traffic region surrounding the SR-11/OME-II border crossing), where traffic management field devices are managed (i.e.: "controlled") by RBMS and/or other Systems, in order to provide instruction (e.g.: Lane Status) or guidance (e.g.: Lane Clearance Type) to vehicles to move between lanes, to manage their speed, or exit the border crossing in response to field conditions monitored by RBMS and its Users in the Pre-Approach Zone and adjoining zones.

Device Status Alerts Alerts provided by RBMS field devices and External Interfacing Systems that provide functionality so that the User has the capacity to understand, in a timely fashion and when required, the type and degree of a special condition detected.

Diagnostic Information System metadata describing the origin, type, severity, and evolution of physical, functional, or logical events or states in the system.

Dialogue An element of a User Interface that provides a User with capabilities to view and enter types of data.

Device Data* Data from detectors, environmental sensor stations, and traffic control devices including device inventory information.

Dynamic Data Items Information of a type that is not slowly changing in the system; that updates frequently.

Empty Commercial vehicle which is not part of a Primary Inspection subscriber program, where the commercial vehicle is empty of goods.

Engineer A person responsible for approving the design of Systems, interfaces, data processes, etc. for the RBMS.


275


Entry Gate A traffic barrier restricting access to the entry of the POE.

Environmental The condition that the roadway and surrounding region is in.

Event Log A permanent record of data states within the System.

External Alerts Alerts generated from Systems interfacing with the Regional Border Management System including the Datahub, SCT Tijuana Traffic Management Center, Caltrans District 11 Traffic Management Center, the Tolling/Congestion Pricing System, and Roadway Systems (US and Mexico).

External Interfacing System A System which is not within the RBMS boundary, but to which the RBMS application and/or RBMS Field Devices has an interfacing relationship to.

Free and Secure Trade (FAST) A commercial clearance program for known low-risk shipments entering the United States from Canada and Mexico.

Free-Text Information that is represented in normal language without any constraint of format allowing Users to enter notes, as opposed to numerical, coded, or structured data.

Field Device A device that is part of an Interfacing System.

Field Device Status* This data flow is used within the Manage Maintenance and Construction function to provide the operational status (state of device, configuration, and fault data) of a set of field equipment, collected from the roadside and from other center processes. The equipment includes sensors (e.g. traffic flow, speed, wind, chemical, temperature, precipitation) and other field devices (e.g., signals, ramp meter controllers, CCTVs. Vehicle traffic and environmental probe field equipment, in-vehicle signing equipment, automated roadway treatment systems, barriers, safeguard systems, and lighting systems). By monitoring this data flow, the receiving process can assess the health and current status of all field equipment and repair if deemed necessary. The data flow consists of the following data items each of which is defined in its own DDE: list_size{station_id + equip_identity + device_status}

Filter A feature of the system to be able to remove from presentation groups of information on a User's request.

Firewall A network security system that monitors and controls the incoming and outgoing network traffic based on predetermined security rules.


276


Greater San Diego Traffic Zone The managed, monitored, and trafficked region, observable by RBMS, in the vicinity of San Diego city.

Greater Tijuana Traffic Zone The managed, monitored, and trafficked region, observable by RBMS, in the vicinity of Tijuana city.

Graphical User Interface (GUI) A type of User Interface.

Hardware User Interface (HUI) A type of User Interface.

Health Status The fault, failure or error status of a device. Specific indications of health will vary by device type and whether or not the device is directly communicating to RBMS or if the health of the device is indicated through an interface with an external system.

Historic Data Recorded data of actual operations.

Historic System Store A store containing an historic account of the System's behavior and Historic Data.

Historic Traffic Store A store containing an historic account of the observed status of traffic in the border region; this information is sourced from external systems directly, internally calculated or evaluated, or User entered

Historic Trends Data Data containing information on conditions and events on the same day each year, gathered over time, to allow for trend analysis and decision-making.

Impacted/Derivative Secondary, subordinate events or calculations triggered as a result of other indirect changes elsewhere in the system.

Incident Duration* This data flow is used within the Manage Traffic function and gives the expected timeframe of an incident from its start time until the time at which it is expected that it will have no further effect on traffic conditions.

Incident History Information describing the evolution of an Incident over time.

Incident Information* Notification of existence of incident and expected severity, location, time and nature of incident. As additional information is gathered and the incident evolves, updated incident information is provided. Incidents include any event that impacts transportation system operation ranging from routine incidents (e.g., disabled vehicle at the side of the road) through large-scale natural or human-caused disasters that


277


involve loss of life, injuries, extensive property damage, and multi-jurisdictional response. This also includes special events, closures, and other planned events that may impact the transportation system.

Incident Management An Operational Activity whereby RBMS Users and other regional stakeholders observe and manage Operational Incidents in the border region scoped by the OME program.

Incident Management Plan A complete operating plan including pre-configured set of traffic management strategies to manage a reported or detected roadway condition in a certain manner, the System's mode of operation (i.e.: Staffed Mode, Unstaffed Mode). Incident Management Plans data includes: Incident type, Incident Manager, Incident location (Incident Zone), Incident management perimeter (Incident Management Zone), Traffic Management Strategy configurations, Duration, Start/End Time, Point of contact details General notes

Incident Management Strategy An Incident Management Strategy is a sub-set of a Traffic Management Strategy enabling the specific and additional functions necessary to respond to an Incident.

Incident Management Zone A portion of the roadway where traffic must operate in a manner adjusted from normal operations, such as not being permitted to enter parts of the roadway, utilize alternate lanes or reduced lane configuration, or operate at a reduced speed.

Incident Type* Classification or categorization of an Incident.

Incident Zone A portion of the roadway, or other location, where the incident is reported to have occurred within the RBMS region.

Incident/Impacted VMS A variable message sign that will require an impacted/derivative VMS message to be displayed as the result of reporting an issue in advance of it.

Information Layer A type of information that is added to a process or a User Interface.

Inspection A verification and validation procedure conducted under controlled circumstances and variables to examine the physical presence of a component of the system.

Interborder Communications Link The segment of the RBMS Backbone Network that links the node located near the CBP facility on the US side to the node located near the Aduanas facility on the Mexican side, reaching over the threshold of the international border crossing


278


Interface Control Document A document that describes the interface to a system or subsystem. It describes the inputs and outputs of a single system and the interface between two systems or subsystems.

Interface Requirement Specification A system description document that standardizes the interfacing relationship between two technology systems, typically RBMS and an External Interfacing System.

Interfacing System A machine-to-machine relationship between the RBMS application and an RBMS Field Device, or an External Interfacing System, such as the Data Hub. Specific Interfacing Systems for RBMS include the Data Hub; User Interfaces to RBMS Operators, CHP CVEF, CBP Watch Commander, and Aduanas Management; RBMS Field Devices; OME Toll System; and redundant communications path to SCT/Tijuana TMC.

Internet Group Management Protocol (IGMP)

A communications protocol used by hosts and adjacent routers on IPv4 networks to establish multicast group memberships. IGMP is an integral part of IP multicast.

Internet Message Access Protocol (IMAP)

An Internet standard protocol used by e-mail clients to retrieve e-mail messages from a mail server over a TCP/IP connection.

Internet Protocol (IP) An identifier assigned to each network connected device. An IP address serves the purposes of identifying the host or network interfacing and location addressing.

ITU-T H.264 ISO/IEC standard for video compression. It is also known as MPEG-4 Part 10, or MPEG-4 AVC (for Advanced Video Coding).

Key Performance Indicator (KPI) A quantifiable measure used to evaluate the success of RBMS performance objectives.

KVM Switch A KVM switch is a hardware device that allows a user to control multiple computers from one or more sets of keyboards, video monitors, and mice

Laden Commercial vehicle which is not part of a Primary Inspection subscriber program, where the commercial vehicle is transporting goods.

Lane Allocations Zone A region in advance of POE Lanes where traffic management field devices are managed (i.e.: "controlled") by RBMS and its Users, where individual vehicles (principally Commercial Vehicles) are instructed by RBMS or other Systems to move into a specific Exit Lane or POE Lane, which may or may not be the same as the lane they currently occupy, in response to field conditions monitored by RBMS and its Users.


279


Lane Designation The Type of lane leading to CBP/Aduanas Primary Inspection including general, SENTRI, Ready, Empty, FAST, Laden, NEEC, declare, no-declare, etc.

Lane Management Control* Information used to configure and control dynamic lane management systems.

Lane Management Information* System status including current operational state, violations, and logged information.

Law Enforcement Authorities organized to administer laws by discovering, deterring, rehabilitating, or punishing people who violate the rules as determined in the design stage and defined in Business Rules.

Layer 3 Routing Device A Router or Layer 3 Switch that functions at Layer 3 of the OSI Model, acting on datagrams at the Internetworking level.

Level 1 User User with administrative capabilities in the Regional Border Management System. These Users have the ability to make changes that affects other Users of the System including security settings, hardware and software, and other User accounts.

Live Data Data that is incident-related or generated in RBMS based on actual operations.

LLRU An identifiable sub-assembly (of an LRU) that can only be repaired or replaced in a certified OME service location (typically by the LRU or LLRU manufacturer).

Line Replaceable Unit (LRU) A hardware or software component that can be replaced at any RBMS physical location.

Management Information Base (MIB)

A database used for managing the entities in a communication network, most often associated with the Simple Network Management Protocol

Mex Layer 2 Switching Device A network switch or bridge located on the Mexican side of the RBMS, which switches traffic at Layer 2 of the OSI Model, acting on datagrams at the hardware address or data link level.

Mex Wireless Access Point A wireless access point located on the Mexican side of RBMS, which links field devices back into the RBMS Backbone Network.

MPEG Moving Picture Experts Group (MPEG), a working group of ISO/IEC charged with the development of video and audio encoding standards.


280


Navigation Features Features of a User Interface that enable a User to locate data within the System.

NEC National Electrical Code

Network Management System (NMS)

An NMS constantly monitors a computer network for slow or failing components and notifies the network administrator (via email, SMS or other alarms) in case of outages.

NMS Server Server on which the RBMS Network Management System resides.

Normal Passenger vehicle where the occupants are not subscribers to a Primary Inspection program

Normal Operations State An operational state where traffic operations are occurring within acceptable parameters of performance.

Obfuscated Vehicle Probe Data Hashed or encrypted data used to generate wait and crossing times without collection of personally identifiable information.

OME System Time The synchronized clock time utilized by the RBMS.

OME Toll System An External Interfacing System to RBMS Central System [IF-XX] that provides toll rate data for the OME border crossing. Also an RBMS Field Device.

ONVIF Open Network Video Interface Forum (ONVIF) protocol. ONVIF creates a standard for how video surveillance and other physical security areas communicate with each other.

Open Road Terminal Tolling payment method that does not require a vehicle to slow or stop. This payment method employs RF transponders placed in vehicles that are read by receivers placed above the roadway (e.g. Fastrak).

Operational Alerts Advisements or warnings (by agreed standards and means) describing aspects of the operational arena knowable to RBMS that is expected to be of value and significance to the RBMS Users.

Operational Incident An operational condition not intended in the operational plan having a potentially disrupting or degrading impact on the planned operation.

Operational Mode A manner in which the System operates, providing different capabilities under different modes of operation.


281


Operations Management The management of staff, their roles and responsibilities, and the operational mode of the System, typically performed by a Supervisor at a traffic management center.

Operations Manager A type of User who has privileges beyond a User to make modifications to traffic management strategies and operations management plans.

Order A feature of the system to be able to order information presented in groups (e.g.: "Date Modified") on a User's request.

Otay Mesa East (OME) Crossing The managed, monitored, and trafficked region, observable and governable by RBMS, of the SR-11/Otay Mesa East Border Crossing.

Otay Mesa West (OMW) Crossing The managed, monitored, and trafficked region, observable by RBMS, of the Otay Mesa West Border Crossing. Also known as OMEII Border Crossing.

Output A Data Item that exits the RBMS or a function within RBMS.

Performance Target The desired operations goals of a system, as measured using Key Performance Indicators (KPIs).

Permitted Words A library of words that are permissible to display on VMS to the traveling public. This list will be defined in the design stage.

Pixel An assembly of LEDs that collectively form an image-forming unit. All LEDs in a pixel are turned on or off in unison.

Point Vehicle Time Detection (PVTD) System

A vehicle detection system which anonymously determines the signature profile of a vehicle traveling within its detection zone and is able to match this common signature profile at additional detection sites, for the purposes of determining border wait time, crossing time or segment travel time

Port-of-Entry (POE) A place at the territorial land boundary between the US and the MEX consisting of roadways, checkpoints, facilities, systems, traffic operations, and security authorities where members of the traveling public and their goods (if applicable) are inspected and subject to security and authorization processes in order to cross from one country into the other.

POE GLS System An External Interfacing System to the RBMS Central System; also an RBMS Field Device. A system which provides indications of Gate and Lane Status at POE Lanes.


282


Potential Incident When the System understands from its data and features that an Operational Incident may have happened.

Pre-Toll Zone A region in advance of a Toll Zone where traffic management field devices are managed (i.e.: "controlled") by RBMS and/or other Systems, in order to provide instruction (e.g.: Lane Status) or guidance (e.g.: Lane Clearance Type) to vehicles to move between lanes, to manage their speed, or exit the border crossing in response to field conditions monitored by RBMS and its Users in the Pre-Toll Zone and adjoining zones.

Primary Approach Lane A type of Traffic Lane leading towards, and through, Primary Inspection

Primary Inspection Location where persons and vehicles entering the USA or MEX are inspected in accordance with customs and border protection processes prior to entry into the USA or MEX.

Primary Inspection Lane A type of Traffic Lane leading towards, and through, Primary Inspection booths.

Primary Inspection Lane Type The type of Primary Inspection entry program that is available at a specific Port of Entry, including: SENTRI, FAST, Empty, Laden

Primary Inspection Point

Primary Lane System The USA-CBP or MEX-Aduanas System that is used to designate the type of Primary Inspection to be carried out at a specific booth.

Process A transformation that RBMS, or a component of RBMS, undertakes.

Projected Data Data used for planning and selection of Traffic Management Plans. Projected Data uses current and historic data (from previous day, week, year, and/or same day last year) to forecast future conditions in areas knowable to the RBMS.

Public Advisory Information that is provided to the traveling public where the object is to raise awareness about a social issue including Real-Time alerts (e.g.: Amber, Silver Alerts), toll pricing, or something that will impact travel in the future (e.g.: a public event resulting in future closures).

PVTD Station An Interfacing System to the RBMS Central System; also an RBMS Field Device.


283


Random Access Memory (RAM) A form of computer storage used to store frequently used program instructions to increase the general speed of a system.

Redundant Array of Independent Disks (RAID)

A data storage virtualization technology that combines multiple physical disk drive components into a single logical unit for the purposes of data redundancy, performance improvement, or both.

RBMS Backbone Network Part of a computer network that interconnects various pieces of the network by providing a path for the exchange of information between different local area networks or subnetworks.

RBMS CCTV Cameras Camera devices that are native components of the RBMS CCTV Systems.

RBMS CCTV System An Interfacing System to the RBMS Central System; also an RBMS Field Device consisting of cameras native to the RBMS. A system which provides Users with Traffic Images, and if equipped and permitted, move in response to their control instructions.

RBMS Central System The central processing component of the RBMS System, providing the necessary mission and enabling services accessible by Users and Interfacing Systems.

RBMS Control Center Located at the South Bay Expressway facility, this is the control center for the Regional Border Management System. It connects to RBMS Field Devices and partner agencies via the RBMS Backbone Network node located at the center.

RBMS Field Devices ITS devices acquired specifically as part of the RBMS program and which have an interfacing relation with the RBMS application. In cooperation with other devices and systems, these devices provide the field monitoring and management enabling capability.

RBMS Management Interface An interface of the RBMS central system that allows Users with appropriate access to monitor, restart, or transition to alternate instantiations of the process or application.

Regional Zones The managed, monitored, and trafficked region, observable by RBMS, which encompasses the Greater San Diego, Greater Tijuana, San Ysidro Crossing, Otay Mesa West, Otay Mesa East crossings.

Report Type A category of historic report that is produced by the System per User specifications describing historic trends, events and their impacts at the OME Crossing.

Radio Frequency Identification (RFID)

The wireless use of electromagnetic fields to transfer data, for the purposes of automatically identifying and tracking tags attached to field sensors.


284


Road Network Conditions* Current and forecasted traffic information, road and weather conditions, and other road network status. Either raw data, processed data, or some combination of both may be provided by this architecture flow. Information on diversions and alternate routes, closures, and special traffic restrictions (lane/shoulder use, weight restrictions, width restrictions, HOV requirements) in effect is included along with a definition of the links, nodes, and routes that make up the road network.

Road Network Traffic Probe Data* Aggregated route usage, travel times, and other aggregated data collected from probe vehicles that can be used to estimate current traffic conditions.

Road Safety Refers to the avoidance of danger on the road.

Road Safety Rules Road safety rules represent traffic, regulatory, and advisory requirements placed on traffic or lane operations that ensure safe direction and operation by motorists. For example, rules guiding types of traffic, traffic directionality, lane availability, speeds, and other similar traffic laws, rules, and guidance.

Road Work Repair of part of all of a roadway or roadway infrastructure that requires the roadway to be occupied by road crews for a period of time.

Road Work Details Details that related to the performance of Road Works including Road Work Type, Location of the road work, start and end points on the roadway that is part of the Road Work Zone, Alert- Vehicle is detected travelling within OME Crossing Road Work Zone, start time of Road Work, Estimated and Actual End time of Road Work, Free-text notes for comments about the Road Work, lanes blocked, and agency in charge.

Road Work Management An Operational Activity whereby RBMS Users and other regional stakeholders plan and report traffic road works in the border region scoped by the OME program.

Road Work Management Plan A complete operating plan including pre-configured set of road work management strategies to manage the roadway in a certain manner, the System's mode of operation (i.e.: Staffed Mode, Unstaffed Mode).

Road Work Type The type of Road Work that is carried out, such as surface repairs to roadway, gantry maintenance.

Roadway Information System Data Information used to initialize, configure, and control roadside systems that provide driver information (e.g., dynamic message signs, highway advisory radio, and beacon systems). This flow can provide message content and delivery attributes, local message store maintenance requests, control mode commands, status queries, and all other commands and associated parameters that support remote management of these systems.


285


Roadway Information System Status *

Current operating status of dynamic message signs, highway advisory radios, beacon systems, or other configurable field equipment that provides dynamic information to the driver.

Real Time Operating System (RTOS) Intended to serve real-time applications which process data as it comes in, typically without delays.

Real Time Protocol (RTP) A network protocol of delivering audio and video over IP networks.

Real Time Streaming Protocol (RTSP)

Used for establishing and controlling streaming video access between two end points.

Safety Zone A segment of roadway or a Traffic Lane, where, if vehicles are detected to be moving within, triggers the creation of an Operational Alert.

San Ysidro Crossing The managed, monitored, and trafficked region, observable by RBMS, of the San Ysidro Border Crossing.

Serial Attached SCSI (SAS) A point-to-point serial protocol that moves data to and from computer storage devices such as hard drives and tape drives.

Serial ATA (SATA) A computer bus interface that connects host bus adapters to mass storage devices such as hard disk drives, optical drives, and solid-state drives

Search A feature of the system to be able to retrieve information on a User's request.

Security Blackout Mode An operational mode of the system where the reporting and recording of traffic operations are limited or precluded because of a security related concern.

SENTRI The Secure Electronic Network for Travelers Rapid Inspection (SENTRI) is a U.S. Customs and Border Protection (CBP) program that allows expedited clearance for pre-approved, low-risk travelers upon arrival in the United States.

Simulated Data Data that is generated by RMBS for the purpose of testing or training.

Small Form Pluggable The small form-factor pluggable is a compact, hot-pluggable transceiver used for both telecommunication and data communications applications. The form factor and electrical interface are specified by a multi-source agreement (MSA). It interfaces a network device motherboard (for a switch, router, media converter or similar device) to a fiber optic or copper networking cable.


286


SMS Short Message Service is a text messaging service component of phone, Web, or mobile communication systems. It uses standardized communications protocols to allow fixed line or mobile phone devices to exchange short text messages.

Snapshot Server A program that provides Users with access to the state of a system at a particular point in time, selectable by the User.

Simple Network Management Protocol (SNMP)

Ann Internet-standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks and more.

Version 3 of the standard is defined in RFCs 2271 through 2275 and 5591 and provides substantial support for authentication, privacy and access control

Secure Shell (SSH) A cryptographic network protocol operating at layer 7 of the OSI Model to allow remote login and other network services to operate securely over an unsecured network. It provides a secure channel over an unsecured network in a client-server architecture, connecting an SSH client application with an SSH server.

Service Set Identification (SSID) Used as an identifier for a wireless local area network and is intended to be unique for a particular area. Since this identifier must often be entered into devices manually by a human user, it is often a human-readable string and thus commonly called the "network name".

Staff Details Details of the traffic management staff on duty, including their shift duration, log-on/log-off times, name, rank, etc.

Staffed Traffic Management Mode The staffed operation configuration of the RBMS.

Standard Operating Procedures (SOP)

A set of step-by-step instructions compiled to help workers carry out routine Operations with the goal to achieve efficiency, quality output and uniformity of performance, while reducing miscommunication and failure to comply with industry regulations.

Static System Store A static, or very slowly changing information store that contains all details of the System's configuration, composition.


287


System Test Facility (STF) The test bench for the primary, secondary, and training systems. The STF provides software and hardware configurable to support unit testing, to verify and validate that the unit is ready to be installed and put into service.

Supervisor A type of User who has privileges beyond a User to make modifications to traffic management strategies and operations management plans.

Swing Gate Gate system at Primary Inspection points that works as a barrier to prevent vehicles traveling through a Primary Inspection booth.

Switch Gear Layer 1-3 Network hardware devices which together form the different working components of the RBMS Network

System (op. impacting) An element of RBMS whose operation is directly affiliated with the operational picture that is made available to RBMS Users.

System Administration The process of managing the configuration, upkeep and reliable operation of the System.

System Administrator A type of User who has privileges beyond a User to make modifications to the system's configuration.

System Alert A sub-type of Alert related to a condition that the System or a Field Device is in.

System Boundary Identifies where a system sizing starts and ends. The sizing of the system includes everything that particular system is responsible for and excludes any component that is a responsibility of another system.

System Control Capabilities that enable Users to navigate the System and provide input.

System Error The manifestation of System Faults, where a component, process, or Data Item is in a state that has already or will lead to a System Failure. System Errors are typically coded by type and provide Users and the System with a pre-configured response. They are also typically derived from User interaction with the System, e.g.: password log-on error.

System Failure Where a component or process does not behave as expected, i.e.: deviates from its designed behavior.

System Fault Where a component, process, or data contains an inherent defect, which may or may not lead to a System Failure if it continues to propagate in the System.


288


System Health The state of effectiveness of a physical or functional attribute of the system.

System Health Monitoring Monitoring the health of the system.

System Provider The implementing entity of the Regional Border Management System.

Target POE Lane A type of Traffic Lane leading towards, and through, Primary Inspection booths.

Telnet Telnet is an application layer protocol used on the Internet or local area networks to provide a bidirectional interactive text-oriented communication facility using a virtual terminal connection. User data is interspersed in-band with Telnet control information in an 8-bit byte oriented data connection over the Transmission Control Protocol.

Test A verification and validation procedure conducted under controlled circumstances and variables to definitely measure a specific response, or set of responses of the system to a specific stimulus (i) under specific metrics.

Test Configuration The configuration of the RBMS utilized for testing purposes.

Test Configuration Data Test parameters entered to configure the RBMS System Test Facility (STF).

Test Scenarios Scenarios that are utilized in the testing of RBMS functionality.

TFT LCD A thin-film-transistor liquid-crystal display is a variant of a liquid-crystal display that uses thin-film transistor technology to improve image qualities such as addressability and contrast.

Timestamp Tag Indications Indications from the roadway of vehicle occupancy which have been time stamped.

The Internet Control Message Protocol (ICMP)

Is one of the main protocols of the internet protocol suite. It is used by network devices, like routers, to send error messages indicating, for example, that a requested service is not available or that a host or router could not be reached.

Toll Lane Vehicle Type The classification of vehicle allowed to access a particular lane within the tolling area including passenger and commercial.

Toll Probe Data* Aggregate probe data derived from electronic toll collection operations. Data collected could include vehicle speeds and travel times for a given link or collection of links.


289


Toll Rate A price paid to use a particular road or crossing; can vary by time of day in response to demand.

Toll Zone An unstaffed zone containing toll-payment traffic lanes and Systems, through which vehicle drivers remit payment (electronically, cash, or bank card) for permission to utilize the SR-11/OME-II Border Crossing. Certain system elements and data in this zone are monitored by RBMS and/or other Systems.

Traffic A vehicle, or groups of vehicles that are stationary or moving on a road in the Regional Zone observable to RBMS.

Traffic Images * High fidelity, real-time traffic images suitable for surveillance monitoring by the operator or for use in machine vision applications.

Traffic Lane A division of roadway within which a vehicle travels.

Traffic Management The activities of planning and influencing traffic behavior through controlling of a variety of field deployed Systems, e.g.: Approach Lane VMS messages.

Traffic Management Mode The staffed or unstaffed operation of the RBMS system.

Traffic Management Plan A complete operating plan including pre-configured set of traffic management strategies to manage the roadway in a certain manner, the System's mode of operation (i.e.: Staffed Mode, Unstaffed Mode).

Traffic Management Scenario A User initiated procedure for nominating a course of action and calculating a future state of Traffic Movement.

Traffic Management Strategy An individual, or combination of, field implemented commands, codified in the System, available to assemble and enact in order to manage traffic in the border region in specific ways. This allows better context-driven decision making that facilitates the selection of appropriate strategies to manage traffic flow.

Traffic Movement Values that describe the location, direction, motion, and rate of motion of vehicles in the OME Crossing.

Traffic Probe Data * Vehicle data that is used to determine traffic conditions. In a basic implementation, the data could be limited to time stamped unique identifiers that can be used to measure a vehicle’s progress through the network. In more advanced implementations, the vehicle may report current position, speed, and


290


heading and snapshots of recent events including route information, starts and stops, and other information that can be used to estimate traffic conditions.

Traffic Safety Rules Methods and measures codified to avoid danger on the road.

Traffic Sensor Control* Information used to configure and control traffic sensor systems.

Traffic Speed The rate of movement of traffic over a defined period, over a defined length of roadway.

Traffic Volumes The number of vehicles crossing a segment of roadway per unit of time at any selected period.

Traffic Zone A geographic territory where RBMS monitors and/or manages traffic operations.

Training Environment The hardware, software, and training materials that are used to perform training activities in Training Sessions.

Training Mode An operational mode of the system utilized by System Trainers and Trainees who access the system for educational purposes, without impacting the operation of the production system.

Training Session A system state wherein a User (and optional trainer) performing a collection of activities in order to train the User in using the System.

Unstaffed Traffic Management Mode

The unstaffed operation configuration of the RBMS where RBMS itself manages and makes rudimentary decisions and implementations of traffic management strategies.

USA United States of America

US Layer 2 Switching Device A network switch or bridge located on the US side of the RBMS, which switches traffic at Layer 2 of the OSI Model, acting on datagrams at the hardware address or data link level.

USA CBP Ancillary Inspection Zone (Southbound)

A secondary USA-CBP staffed zone, containing Port-of-Entry traffic lanes, parking, and Systems, within which vehicles, drivers, and passengers undergo US CBP customs and border control processes prior to departure from the USA into MEX. This zone is neither monitored nor managed by RBMS nor its External Interfacing Systems.

USA CBP Inspection Zone A USA CBP staffed zone, containing Port-of-Entry traffic lanes, parking, and Systems, within which vehicles (Passenger and Commercial Type), drivers, and passengers undergo US CBP customs and border control processes. This zone is neither monitored nor managed by RBMS or its External Interfacing Systems.


291


USA POE Lanes A USA CBP staffed zone, containing Port-of-Entry traffic lanes and Systems, through which vehicles (Passenger and Commercial Type), drivers, and passengers undergo USA CBP customs and border control processes in order to gain access to the United States of America. Certain non-security critical system elements and data in this zone are monitored by RBMS and/or other Systems.

User An individual that will interact with the System directly. Users may be provided access and permission credentials based on their job title, area of responsibility, or other criteria as deemed necessary during system design and implementation.

User Account Properties Properties that describe a User's account, including authorizations to perform certain activities within the System.

User Actions Responses that a User enters into the RBMS.

User Interface The component of the System that embodies the physical and functional aspects that come into contact with, influence, or otherwise effect communication between humans and devices or Systems, including visual displays, audible alerts, haptic feedback, etc.

User Interface Management The process of management and modification of User Interfaces within the System.

User Session The presence of a User with unique credentials accessing the RBMS.

User Training The process of teaching a User to have an understanding of, interact with, and communicate with the RBMS System, its native devices, and External Interfacing Systems. It may involve training scenarios and/or in-person training.

Virtual Local Area Network (VLAN) Ay broadcast domain that is partitioned and isolated in a computer network at the data link layer (OSI layer 2).

Variable Message Sign (VMS) An individual device and class of RBMS Field Device that displays relevant traffic information to the traveling public within the greater border region.

Variable Toll Message Sign (VTMS) An individual and class of RBMS Field Device that displays relevant toll rate and crossing time information to the traveling public within the greater border region.

Variable Toll Message Sign (VTMS) System

An Interfacing System to the RBMS Central System; also an RBMS Field Device. A system which provides the traveling public with toll rates and crossing times by POE.


292


Vehicle Detection System (VDS) An Interfacing System to the RBMS Central System; also an RBMS Field Device. A system which detects vehicle occupancy and provides this to the RBMS Central System.

VDS Station Number An identifier exclusive to an individual vehicle detection system field device used to calculate travel time, border wait and crossing times, traffic volume, etc.

Video Surveillance Control* Information used to configure and control video surveillance systems.

Video Surveillance Feedback Information provided to Users with evaluations of CCTV actions after instruction is given by a User via Video Surveillance Controls.

Wi-Fi Local area wireless computer networking technology that allows electronic devices to network, mainly using the 2.4 GHz UHF and 5.8 GHz (6 cm) SHF ISM radio bands.

Work Management Zone A portion of the roadway where traffic must operate in a manner adjusted from normal operations, such as not being permitted to enter certain parts of the roadway, utilize alternate lanes or reduced lane configuration, or operate at a reduced speed.

Work Zone A portion of the roadway that is occupied by Road Work crews.

Action Verbs

VERB DEFINITION

Accept To obtain valid data into the service/system sent from a valid source and sending an acknowledgement response message to the originator.

Aggregate To combine data elements of similar format into a single data element that is a statistical representation of the original elements.

Conform Refers to the alignment of the system to an external standard - interface, workmanship, operating, etc.

Communicate The activity of exchanging information, data or messages to a recipient.


293

VERB DEFINITION

Connect To link to another entity by means of a communication circuit.

Determine To find out or calculate.

Display To present information to a system operator, typically through a graphical user interface or command line prompt.

Drift To vary or deviate from a set standard reference.

Enable To make other actions possible by supplying prerequisite information or resources required for the task or activity to take place.

Establish To begin or create something that will follow a prescribed set of rules governing the behavior such as an interface between entities.

Ensure To make safe, certain; or to guarantee an outcome or condition.

Exceed To go over a prescribed threshold or parameter.

Exclude To keep out from a group; to omit.

Identify To extract information from a message or an activity/process that matches certain criteria.

Include To create a message or report that contains certain elements that could be from multiple sources; or to have or regard or treat as part of a whole.

Install To set up for use or service.

Maintain To keep or retain possession of; to preserve or hold intact or within a certain set of parameters.

Manage To work upon or try to alter for a purpose - involving collecting information and acting on it based on predefined sets of thresholds or criteria.

Operate Describes the conditions in which the Core System is performing its services and functions.

Prioritize To evaluate a group of tasks and ranking them in their order of importance or urgency.


294

VERB DEFINITION

Protect To carry out certain procedures and setup predefined safeguards in order to maintain the status or integrity of an entity.

Process A series of actions, changes, or functions bringing about a result.

Provide To make available, present, or furnish information or data (e.g., certificates, service coverage area, list of services) to a recipient.

Receive To obtain valid data into the service/system sent from a valid source, but sending no acknowledgement response to the originator.

Record To add information into a set of data (database, log, files) to be organized with other data.

Report To create an output either to a System User or a System Operator that is organized to include one or more data elements that could be combined from multiple sources and may be arranged in a prescribed format.

Request To send a message to another entity to cause that other entity to reply with data that is called out in the 'request' message.

Route The process of determining the communication link path for moving a packet of data from a source to a destination.

Send To dispatch, by a means of communication, data from one entity to another without the expectation of receiving an acknowledgement response from that entity.

Sign To apply a digital certificate, or electronic "identification card" that establishes the credentials of the sender of an electronic message.

Store To place or leave in a location (e.g., computer memory, disk, database) for preservation or later use or disposal.

Support To implement an interface or service in agreement with or in accordance with an external standard definition or established protocol.


295

VERB DEFINITION

Synchronize To occur or operate at the same time or rate.

Transition To change from one state or mode to another.

Transmit To dispatch, by a means of communication, data from one entity to another with the expectation of receiving an acknowledgement response from that entity.

Update To modify or change the existing data or information to new data or information.

Use To apply or utilize, such as data in a message.

Validate To authenticate, sanction or provide authoritative approval.

Vary To change in value, either up or down (positively or negatively).

Verify To confirm or substantiate the truth, accuracy, or reality of something - credentials, identity, configuration.

Business Data Dictionary

The following data dictionary represents some of the specific and unique elements of the RBMS data stores. There are numerous data elements intrinsic to traditional traffic management systems that are well defined within industry and widely available in commercial-off-the-shelf solutions. All data is expected to be TMDD v3.0 or newer compliant where such data is covered by that standard (this applies to all data that may be made available to external databases, systems, and/or interfaces) with RBMS. The elements included in the table below have been grouped by Data Store.

Primary Store Data Item Name Description Composition or data type (if applicable)

Live System Store Live System Store A dynamic conceptual information store that contains the most current account of the observed RBMS system status; this information is sourced from RBMS central system components, RBMS field devices, and interfaces to External Systems.

Structured


296


Live System Store System (op. impacting) Alerts

An Alert indicating an issue of attention with the RBMS, its constituent interfaces and Field Devices.

Live System Store System (op. impacting) MOP

Measures of performance of the RBMS and its constituent interfaces and Field Devices.

Live System Store System (op. impacting) Status

Status of the RBMS and its constituent interfaces and Field Devices.

Live System Store System Alerts Store A static, or very slowly changing conceptual information store that contains the logical rules for detecting, classifying, and distributing Alerts to Users and retaining in System logs

Structured

Live System Store System Logon Status Information provided of which Users have an active user session within the RBMS.

User Name User Location Session Time

Live Traffic Store Aggregated Values Alerts

An Alert based on comparison and/or calculation of multiple Alerts or values. For example, an Aggregated Values Alert that is created when speeds fall below a certain speed and a lane is designated as closed.

Live Traffic Store Aggregated Values Status

A whole status value formed by combination of parts - other status values. For example, the aggregated values of wait times calculated across several lanes inclusive of a category of traffic.

Live Traffic Store Average Vehicle Speed The average value of speed of vehicles over a section of roadway, or within a zone, by lane or aggregated by lanes, for an interval of time.


297


Live Traffic Store Border Crossing Performance Metrics

Metrics of the operational performance of the border crossing, encapsulating not only traffic movement, but also management actions, road works, incident clearance, facility status, service status, and other operationally impacting concerns.

Traffic Status Metrics Traffic Management Metrics Incident Management Metrics Road Works Management Metrics Border Service Metrics System Metrics (certain impacting) Infrastructure Metrics

Live Traffic Store Border Crossing Rate The number of vehicles that traverse between two fixed points per interval of time. This would be most directly represented by volumes of traffic traversing the primary inspection points either northbound or southbound.

Live Traffic Store Border Crossing Time The time it takes for a vehicle to exit the border crossing process after it joins the queue before CBP or Aduanas primary inspection booth.

Live Traffic Store Border Operational Alerts

Advisements or warnings (by agreed standards and means) describing aspects of the operational arena knowable to RBMS that is expected to be of value and significance to the RBMS Users.

Traffic Alerts Traffic Management Alerts Road Works Management Alerts Incident Management Alerts Border Services Alerts Environmental & Infrastructure Alerts Aggregated Values Alerts System (op. impacting) Alerts


298


Live Traffic Store Border Operational MOPs

Measured quantities (by agreed standards and means) describing aspects of the operational arena knowable to RBMS across all the Regional Zones via External Interfacing Systems and internal calculation and evaluation by RBMS.

Traffic MOP Traffic Management MOP Road Works Management MOP Incident Management MOP Border Services MOP Environmental & Infrastructure MOP Aggregated Values MOP System (op. impacting) MOP

Live Traffic Store Border Operational Status

Collective term for status indications regarding the condition of the operational arena knowable to RBMS across all the Regional Zones (i.e.: Greater San Diego Traffic Zone, Greater Tijuana Traffic Zone, San Ysidro Border Crossing, OMW Border Crossing, OME Border Crossing) via Interfacing Systems (i.e.: RBMS Field Devices, External Systems) and internal calculation and evaluation by RBMS. Individual status indications will be developed during design and implementation consistent with the ultimate configuration of the facility.

Traffic Status Traffic Management Status Road Works Management Status Incident Management Status Border Services Status Environmental & Infrastructure Status Aggregated Values Status System (op. impacting) Status

Live Traffic Store Border Operations Data Collective term for data providing details of the condition of the operational arena knowable to RBMS across all the Regional Zones (i.e.: Greater San Diego Traffic Zone, Greater Tijuana Traffic Zone, San Ysidro Border Crossing, OMW Border Crossing, OME Border Crossing) via Interfacing Systems (i.e.: RBMS Field Devices, External Systems) and internal calculation and evaluation by RBMS. Depending on the specific field devices and methods of interfacing with external system, operations


299


data may represent individual, collective, or calculated values, but should be consistent with TMDD v3.03 or newer.

Live Traffic Store Border Services Alerts Alerts of Border Service conditions. Example, an alert provide by an RBMS operator or external system impacting the availability of the border crossing, portions of the crossing, hours of operation, etc.

Live Traffic Store Border Services MOP Measures of performance of Border Services. Detailed MOPs will be based around wait times, crossing times, border crossing volumes, and related metrics. MOPs will involve various border operations data elements, such as lane type, lane status, lane directionality, etc.

Live Traffic Store Border Services Status The state or condition that Border Services are in, generally available or not.

Live Traffic Store Border Wait Time The time it takes for a vehicle to reach the CBP’s or Aduanas primary inspection booth after it arrives at the end of the queue leading up to the primary inspection.

Live Traffic Store Business Rules Store A static, or very slowly changing conceptual information store that contains the logical rules for calculating Performance Measures, Traffic Management Strategies

Structured

Live Traffic Store Data Item Property An attribute that a Data Item has. Attributes are defined by the type of field device, field device capabilities, system functionality, and data structure. Where possible data elements should comply with TMDD v3.0 or newer


300


Live Traffic Store Direction of Travel The direction in which vehicles are instructed to, and in which, they travel.

Live Traffic Store Entry Gate Position The position (open or closed) of the Entry Gate at the POE. Note entry gates refer to approach lane entry to the Mexico or US POE properties and not traffic management or control gates and barriers within the POEs.

Live Traffic Store Environmental Alerts Alerts of weather-related conditions. For example, this might include wild-fire impacts to the POE operations.

Live Traffic Store Environmental MOP Measures of performance of the System during different weather conditions. Effectively defines combining weather as a factor in MOP measurement to understand how weather may impact factors such as throughput, wait times, etc.

Live Traffic Store Health Status The fault, failure or error status of a device. Specific indications of health will vary by device type and whether or not the device is directly communicating to RBMS or if the health of the device is indicated through an interface with an external system.

Live Traffic Store Incident Codes Coded values for types of operational incident that happen in the field.

Live Traffic Store Incident Details Details about an incident that occurs in the field.

Incident Type Location of the Incident Start and end points on the roadway that is part of the Incident Zone Start time of the Incident Estimated End Time of the Incident


301


Actual End Time of the Incident Responders Type of Damage Vehicle Type Blocked Lanes Free-text notes for comments about the Incident

Live Traffic Store Incident Help Content Data items that help users to resolve incidents. Recommended response activities Sequence of those activities Points of contact to consider coordination with

Live Traffic Store Incident Management Alerts

Alerts of Incident and Incident Management conditions.

Live Traffic Store Incident Management Controls

The User-available, user-implementable commands in RBMS to implement incident management action in the field.

Live Traffic Store Incident Management MOP

Measures of impact of Incidents on regular operations. In particular for RBMS this would relate to items such as border wait times, crossing times, border crossing volumes, etc.


302


Live Traffic Store Incident Management Plan

A compiled operating plan including pre-configured set of traffic management strategies to manage a reported or detected roadway condition in a certain manner, the System's mode of operation (i.e.: Staffed Mode, Unstaffed Mode).

Incident type Incident Manager Incident location (Incident Zone) Incident management perimeter (Incident Management Zone) Traffic Management Strategy configurations Duration Start/End Time Point of contact details General notes

Live Traffic Store Incident Management Status

Details about the current configuration of Incident Management Plans and Traffic Management Strategies implemented in the field.

Live Traffic Store Incident Manager The individual who is responsible for managing the Incident in RBMS.

Live Traffic Store Incident Zone A region of the roadway where an Incident is occurring and where normal traffic operations may be impacted.

Live Traffic Store Infrastructure Alerts Alerts of infrastructure conditions.

Live Traffic Store Infrastructure MOP Measures of performance of RBMS infrastructure items.

Live Traffic Store Infrastructure Status The state or condition that infrastructure elements are in (e.g., "damaged", "inoperable", "fully functional")

Live Traffic Store Lane Access The accessibility of the Traffic Lane to vehicular traffic in time, whether it is open or closed to vehicles.

Lane Access Status Start/End Location Time of change action Duration of change


303


Live Traffic Store Lane Access Status The instructed open or closed status of a Traffic Lane.

Live Traffic Store Lane Direction The intended direction of traffic movement across a point on a Traffic Lane.

Lane Direction Status Start/End Location Time of change action Duration of change

Live Traffic Store Lane Management Information

Messages that are sent to Variable Message Signs describing what to display, where, and when.

Live Traffic Store Lane Speed Advisory The vehicle speed that vehicles are advised to travel at in the OME Border Crossing Zone.

Live Traffic Store Lane Vehicle Type The Vehicle Type that is permitted to travel in a Traffic Lane. This could represent types of vehicle (passenger vehicle or truck) or it could represent Primary Inspection Types (SENTRI, READY, GENERAL, FAST, EMPTY, LADEN, DECLARE, NO-DECLARE, PEQUENOS - small shipments, etc.).

Lane Vehicle Type Status Start/End Location Time of change action Duration of change

Live Traffic Store Live Traffic Store A dynamic conceptual information store that contains the most current account of the observed status of traffic in the border region; this information is sourced from external systems directly, internally calculated or evaluated, or user entered

Structured

Live Traffic Store Occupancy Values An indication of a vehicle detection at a specific location.


304


Live Traffic Store Operational Alerts Advisements or warnings (by agreed standards and means) describing aspects of the operational arena knowable to RBMS that is expected to be of value and significance to the RBMS Users.

Traffic Alerts Traffic Management Alerts Road Works Management Alerts Incident Management Alerts Border Services Alerts Environmental & Infrastructure Alerts Aggregated Values Alerts System (op. impacting) Alerts

Live Traffic Store Operations Profile What traffic operations capabilities a User or a User team is entitled to have.

Live Traffic Store POE Lane The Primary Inspection Lane Type per Traffic Lane at Primary Inspection.

Live Traffic Store Primary Inspection Type

The type of Primary Inspection entry program that is available at a specific Port of Entry vehicle crossing lane.

Live Traffic Store Road Work Details Details that relate to the performance of Road Work such as start/end time, type of Road Work, and impacted closures.

Live Traffic Store Road Work Management Alerts

Alerts of Road Works and Road Works Management conditions.


305


Live Traffic Store Road Work Management Status

The configuration of Road Work Management action that is implemented in the field.

Live Traffic Store Road Work Plan A description of road work impacting access roads, facilities, or infrastructure of interest to the RBMS area of control.

Road Work type Road Work Manager Road Work location (Work Zone) Road Work management perimeter (Work Management Zone) Traffic Management Strategy configurations Duration Start/End Time Recurring schedule (e.g.: every other Sunday 9pm-1am) Point of contact details General notes


306


Live Traffic Store Road Work Plan Details A Data Item that describes the parameters for adjustments to traffic necessary to accommodate Road Works that are taking place. Details of the road works themselves are also recorded.


Live Traffic Store Road Work Type The kind of Road Work that is carried out, such as surface repairs to roadway, gantry maintenance, etc.

Live Traffic Store Shift Schedules Timeframes of typical shifts maintained by users of RBMS.

Live Traffic Store Swing Gate Position The position of a gate or swing arm controlling the approach or lane management elements of RBMS. Positions may be binary or multi-positional based on ultimate facility designs. Swing gate positions will be used as aggregated values and alerts to compare with road safety rules to ensure safe directionality and alignment of lane access, vehicle types, etc.

Live Traffic Store System Configuration Store

A static, or very slowly changing conceptual information store that contains the central system’s configuration, including

Structured


307


hardware versions, software configurations, configuration item settings, the System User Model

Live Traffic Store Toll Lane Status The open/closed status of a lane at the OME Toll Crossing.

Live Traffic Store Toll Price The cost, per vehicle type, in US or MX currency to travel through the OME Toll Crossing.

Live Traffic Store Traffic Flow Rate See Traffic Volumes.

Live Traffic Store Traffic Images Imagery captured from the RBMS traffic surveillance and border wait cameras, either static or moving (video).

Live Traffic Store Traffic Lane A division of a roadway within which a vehicle travels that is marked appropriate with US or Mexico guidance or signage.

Live Traffic Store Traffic Management Alerts

Alerts of Traffic Management conditions that are configurable within RBMS based on the data received and configuration of elements and "roadway" segments within the system.

Live Traffic Store Traffic Management Controls

The user-available, user-implementable commands in RBMS to implement traffic management action in the field.

Live Traffic Store Traffic Management Dialogue

A User Interface or portion of a User Interface, that enables a User to enter and review traffic management plans details and information.

Lane Status Dialogue Lane Direction Dialogue Lane Vehicle Type Dialogue Lane Speed Advisory Dialogue POE Target Lane Dialogue Public Advisory Dialogue

Live Traffic Store Traffic Management Mode Advisory

An advisory given to a User to change the Traffic Management Mode of the System, either the result of an event that has occurred or scheduled event.


308


Live Traffic Store Traffic Management MOP

Measures of performance of Traffic Management action particularly as it impacts border wait times, achieving desired performance goals, and border crossing volumes.

Live Traffic Store Traffic Management Plan

A complete operating plan including pre-configured set of traffic management strategies to manage the roadway in a certain manner, the System's mode of operation (i.e.: Staffed Mode, Unstaffed Mode).

Live Traffic Store Traffic Management Plan Status

Indicates if a Plan is active, scheduled to become active, or inactive.

Live Traffic Store Traffic Management Status

Details about the current configuration of Traffic Management Plans (incl. Road Work Management Plans, Incident Management Plans, staffed/unstaffed mode) and Traffic Management Strategies implemented in the field.

Lane Status Primary Inspection Type Lane Direction

Live Traffic Store Traffic Management Status

Details about the current configuration of Traffic Management Plans (incl. Road Work Management Plans, Incident Management Plans, staffed/unstaffed mode) and Traffic Management Strategies implemented in the field.

Live Traffic Store Traffic Management Strategy

An individual, or combination of field implemented commands, codified in the System, available to assemble and enact of in order to manage traffic in the border region in specific ways. Automated traffic management strategies are configurable by Users.

Modify Lane Status Modify Lane Direction Manage Primary Inspection Lane Approach Modify Traffic Speed Advisory Assign Unique Primary Inspection Lane Public Advisories to Public


309


Live Traffic Store Traffic Management Strategy Advice

Advice is provided to a User to address or resolve a condition that the System has detected, or which is requested by a User directly.

Modify Lane Status Modify Lane Direction Manage Primary Inspection Lane Approach Modify Traffic Speed Advisory Assign Unique Primary Inspection Lane Public Advisories to Public

Live Traffic Store Traffic Status The collection of measures by which traffic condition and performance is evaluated.

Border Wait Time Border Crossing Time Traffic Volume Border Crossing Rate

Live Traffic Store Traffic Status Alert An alert provided to a User regarding Traffic Status condition that requires their attention, and possible management intervention.

Live Traffic Store Traffic Status MOP Measures of performance of Traffic. Border Crossing Wait Time Traffic Volume Average Vehicle Speed

Live Traffic Store Traffic Volume The number of vehicles that traverse between two fixed points over a fixed duration of time.

Live Traffic Store Vehicle Presence A Data Item that describes that a vehicle has been detected at a location at a point in time.

Live Traffic Store Vehicle Type The commercial category of a vehicle.


310


Live Traffic Store Video Surveillance Control

Control instructions that are provided to RBMS CCTV Cameras. These parameters may cover things such as camera pan, tilt, and zoom, plus other picture controls.

Pan Tilt Zoom

Live Traffic Store What-If Traffic Management Strategy

A future projection of border operations describing the outcome based of a selected Traffic Management Strategy.

Live Traffic Store Work Management Zone Speed Limit Advisory

The advisable speed within the Work Management Zone. Work Management Zone Lane Speed Advisory

Static Border Store Historic Data Store An historic conceptual information store that contains an historic account of the observed status of traffic in the border region; this information is sourced from external systems directly, internally calculated or evaluated, or User entered

Structured

Static Border Store Historic Operations Data

Historic (i.e., past) border operations data.

Static Border Store Incident Codes Coded values for types of operational incident that happen in the field.

Static Border Store Incident Details Details about an incident that occurs in the field. Type of Incident Location/Physical Extent where the Incident Response is occurring (i.e.: Incident Zone)Incident/impacted vehicles, lanes, facilities, servicesStart Time of IncidentEnd Time of Incident


311


Static Border Store Incident Help Content Data items that help users to resolve incidents. Recommended response activities Sequence of those activities Points of contact to consider coordination with

Static Border Store Incident Management Plan

A complete operating plan including pre-configured set of traffic management strategies to manage a reported or detected roadway condition in a certain manner, the System's mode of operation (i.e.: Staffed Mode, Unstaffed Mode).

Incident type Incident Manager Incident location (Incident Zone) Incident management perimeter (Incident Management Zone) Traffic Management Strategy configurations Duration Start/End Time Point of contact details General notes

Static Border Store Incident Management Plan Status

Details about the current configuration of Incident Management Plans and Traffic Management Strategies implemented in the field.

Static Border Store Incident Manager The individual who is responsible for managing the Incident in RBMS.

Static Border Store Operations Profile What traffic operations capabilities a User or a User team is entitled to have.


312


Static Border Store POE Lane The Primary Inspection Lane Type per Traffic Lane at Primary Inspection or range of types that are allowable for that lane.

Static Border Store Road Work Plan A data item that describes the parameters for adjustments to traffic necessary to accommodate Road Works that are taking place. Details of the road works themselves are also recorded.


Static Border Store Shift Schedules Timeframes of typical shifts maintained by users of RBMS.

Static Border Store Static Border Store A static, or very slowly changing conceptual information store that contains the border region infrastructure configuration including roadways, roadway gantries, location of field ITS equipment, locations and layout of border region facilities such

Structured


313


as CPB, Aduanas, tolling facilities, ground topology, intersecting transportation routes (bus, rail), among others

Static Border Store Swing Gate Position The detected open or closed status of a POE Gate.

Static Border Store Traffic Management Mode Advisory

An advisory given to a User to change the Traffic Management Mode of the System, either the result of an event that has occurred or scheduled event.

Static Border Store Traffic Management Plan

A complete operating plan including pre-configured set of traffic management strategies to manage the roadway in a certain manner, the System's mode of operation (i.e.: Staffed Mode, Unstaffed Mode).

Static Border Store Traffic Management Pre-Configurations

Lane Status Pre-Configuration Lane Direction Pre-Configuration Lane Vehicle Type Pre-Configuration Lane Speed Advisory Pre-Configuration Public Advisory Pre-Configuration

Static Border Store Traffic Management Strategy Advice

Advice that is provided to a User to address or resolve a condition that the System has detected, or which is requested by a User directly.

Lane Access AdviceLane Vehicle Type AdviceLane Direction AdviceLane Speed Advisory AdvicePublic Advisory AdviceIncident Management Advice


314


Static Border Store Vehicle Presence A data item that describes that a vehicle has been detected at a location at a point in time.

Static Border Store Work Management Zone Speed Limit Advisory

The advisable speed within the Work Management Zone. Work Management Zone Lane Speed Advisory

System Configuration Store

Environmental Status Dialogue

A User Interface or portion of a User Interface that enables a User to enter weather and other environmental information manually.


Incident Management Dialogue

A User Interface or portion of a User Interface that enables a User to enter and review incident management details and information.


Incident Report Dialogue

A User Interface, or portion thereof, where a User may create and modify a reported details of an Incident (Incident Report) as well as creating and modify an Incident Management Plan.


Operational Dialogues A User Interface, or portion of a User Interface, that enables a User to receive and enter Traffic Status information manually.

Traffic Status Dialogue Traffic Management Dialogue Road Works Management Dialogue Incident Management Dialogue Border Services Dialogue Environmental Status Dialogue Infrastructure Dialogue Aggregated Values Dialogue System (op. impacting) Dialogue


315



Road Work Dialogue A User Interface, or portion thereof, where a User may enter Road Work details, including creating and modifying a Road Work Plan.

User Interface Elements


Road Work Plan Details Composition of data elements in a Road Work Plan.


Traffic Status Dialogue A User Interface, or portion of a User Interface, that enables a User to enter Traffic Status information manually.

User Needs

NEED DEFINITION

Border Traffic Monitoring Section 1.7.1

N01 The ability to provide live situational awareness data to Users based on system-generated sources, in order for the complete real-time picture to be known.

N02 The ability to record Incident Details, share Incident Details with other System Users, and make Incident Details available to External Interfacing Systems, for full Incident dissemination and documentation.

N03 The ability to record Road Work Details, share Road Work Details with other System Users, and make Road Work Details available to External Interfacing Systems, for full Road Work dissemination and documentation.

N04 The ability to record, share with other System Users, and make available to External Interfacing Systems all other necessary Details about the operation or environment of the System, for full dissemination and documentation of operations.

N05 The ability to present operational alerts, system alerts, and/or key performance indicators (KPIs) in order for Users to effectively manage traffic

N06 The ability for Users to see and confirm what is happening in the field with real-time video images, so that a visual feedback can reinforce data provided in a tabular fashion.


316

NEED DEFINITION

Traffic Video Surveillance (Section 1.7.2)

N07 The ability for Users to control the field of view on native RBMS CCTV cameras and share certain video images with other Users for collaboration and collective review.

N08 The ability for the System to monitor video images in order to automatically detect Incidents for Users.

Border Traffic Management (Section 1.7.3)

N09 The ability to manage traffic with System-provided controls, in order to put in place targeted policies for specific time periods or scenarios.

N10 The ability to support approach lane management and distribution of traffic up to primary inspection points, in order to improve the safety and efficiency of border operations.

N11 The ability for Users to select different Traffic Management Strategies based on current field conditions and/or pre-determined plans, in order to adapt Strategies to specific situations.

N12 The ability for the System to automatically suggest different Traffic Management Strategies, subject to User Approval, based on its understanding of best practices, in order to standardize responses and increase efficiency.

N13 The ability for Users and/or the System to access, load new plans, and use default emergency and fallback response plans, in order to standardize responses and increase efficiency.

N14 The ability for the System to automatically populate variable message and variable toll message sign displays, in order to aid the traveling public with targeted route options and real-time toll pricing.

N15 The ability for the System to provide advice and recommendations to help Users evaluate conditions and make effective traffic management decisions.

N16 The ability to manage System responses under automated mode so that suitable System Operations can take place with minimal User interaction, outside of standard working hours.

Border Traffic Analysis (Section 1.7.4)

N17 The ability for the System to provide operational trends data for Users, so that informed decisions can be made based on an understanding of the ground truths that existed during comparable historical periods.

Alert Management (Section 1.7.5)


317

NEED DEFINITION

N18 The ability for the System to provide User Alerts from External Interfacing Systems, so that RBMS Users may make fully informed decisions.

N19 The ability for an authorized User to configure specific Operational Alerts requiring action, such that the level of required User feedback is kept to a manageable level.

N20 The ability for an authorized User to configure specific System Alerts requiring action, such that the level of required User feedback is kept to a manageable level.

System Reporting (Section 1.7.6)

N21 The ability for the System to produce standard reports providing needed information on Border Operations Data, such that information is always provided to Users in a consistent manner.

N22 The ability for Users to create and produce ad hoc reports in the System, in order to provide flexibility for initially unforeseen report types.

N23 The ability for Users to access all the raw System data utilized for standard and User-created reports, so that generated reports may be comprehensive.

N24 The ability for Users to retrieve an archived report, in order to make informed decisions based on historical data.

N25 The ability to distribute reports to a broad set of internal and external stakeholders, for the purposes of collaboration and collective review.

Data Management (Section 1.8.1)

N26 The ability for the System to acquire and process data from internal and external systems using a standards-based approach, which will ensure regional interoperability.

N27 The ability for the System to automatically quality check the data, in order to ensure reliability and accuracy.

N28 The ability for the System to provide data in an accessible format for use by external systems, which will ensure regional interoperability.

N29 The ability for the System to store data for a minimum of ten years, for forensic and auditing purposes.

N30 The ability for Users to modify business rules as conditions/needs change over time, in order to provide flexibility for initially unforeseen circumstances.


318

NEED DEFINITION

User Interface Management (Section 1.8.2)

N31 The ability for the System to provide a user-friendly graphical user interface (GUI) that provides for role-based functionality and access permissions for Users, in order to provide ease-of-use and security.

N32 The ability for the System to provide Users a graphical user interface (GUI) that includes map-based functionality, so that a visual feedback can reinforce data provided in a tabular fashion.

N33 The ability for Users to interact with the System in either English or Spanish according to the nation in which they are situated, thus promoting ease-of-use.

N34 The ability for the System to support industry-standard User Interfaces (UIs), for ease-of-use and effective ergonomics.

N35 The ability for the System to provide UI displays in formats that work for Users' business needs, in order to maximize User efficiency and productivity.

N36 The ability for the System to provide real-time responsiveness for User controls on displays, in order to prevent outdated data from being misinterpreted as current

System Administration (Section 1.8.3)

N37 The ability for the System to provide real-time detection of faults in the System and correct them, so as to maximize system uptime while minimizing User intervention.

N38 The ability for Users to change System configuration over time, in order to provide flexibility and forward compatibility.

N39 The ability for Users to test changes in the System configuration, in order to ensure that changes have been proven prior to reaching the production environment.

N40 The ability for the System to automatically generate a trail of changes in System configuration, for forensic and auditing purposes.

N41 The ability for the System to maintain rollback functionality for System changes so that reverting to an earlier stable configuration can be easily performed at all times.

System Interface Management (Section 1.8.4)

N42 The ability for the System and/or Users to manage connection relationships and sessions between the System, Data Hub, and external systems, so as to maximize system uptime while minimizing User intervention.


319

NEED DEFINITION

N43 The ability for the System to send/receive data to/from external systems through a common Data Hub, in order to ensure regional interoperability.

User Training (Section 1.8.5)

N44 The ability for the System to provide a comprehensive and interactive electronic System training environment for Users, so that training activities can be performed outside of the production environment.

N45 The ability for the System to train Users with scenarios that will mimic the operational realities they will face when confronted with the production environment.

N46 The ability for Users to both self-train and train with an instructor, to effectively accommodate different learning styles.

N47 The ability for Users to create and implement new training scenarios that can account for the operational realities of the production environment, including initially unforeseen circumstances.

Field Devices (Section 2)

N48 The ability for the System to provide central and field device hardware suitable for the environmental and security considerations of the US-Mexico border region, for compliance with regional standards, regulations and conditions.

N49 The ability for the System Field Devices to support auto-reporting of device health status, so as to maximize system uptime while minimizing User intervention.

N50 The ability from the System to limit exposure of sensitive areas within the border region through limits on surveillance camera coverage, in order to comply with privacy and national security requirements.

N51 The ability for the System to ascertain the operational status of primary inspection lanes and the position of barrier systems, which are managed and controlled by the border authorities, in a manner which in no way interferes with agency jurisdiction.

N52 The ability for the System to collect necessary information at adequate sample rates, in order to calculate accurate border wait times at 15-minute or better intervals.

N53 The ability for the System to collect and calculate traffic volume, speed, and occupancy data in the pre-approach and approach zones, in order to accurately gauge traffic flow.

Communications (Section 3)


320

NEED DEFINITION

N54 The ability for the System to provide a private or virtual private communications network with sufficient bandwidth and reliability to support the secure transmission of data from all remote field devices to the central system.

N55 The ability for the System to provide a multilayer communications network topology, in order to ensure scalability, flexibility, and efficiency.

N56 The ability for the System to make use of existing and planned fiber optic communications, in order to leverage regional infrastructure investments.

N57 The ability for the System to make use of wireless communications where fiber optic communications are not available, in order to mitigate significant additional capital costs where these may not be warranted.

N58 The ability for the System to provide a connection between the US and Mexican sides of the Port-of-Entry, in order to ensure continuing cross-border, binational System operations.

N59 The ability for the System to provide a communications network that is properly secured or encrypted whenever data flows over non-private segments of the network, in order to protect privacy and data integrity.

System Quality (Section 4)

N60 The ability to support high reliability, availability, and maintainability, so that the System can function effectively and its useful life can be maximized.

N61 The ability for the System to effectively support the safety of the travelling public, which needs to remain the primary focus at all times.

N62 The ability for the System to provide sufficient security, in order to protect field devices from unauthorized access.

N63 The ability for the System to provide a user-friendly and efficient environment, in order to minimize unnecessary distractions and User fatigue.

N64 The ability for the System to be designed such that staged degraded modes of operation can be achieved through the isolation of faulty components, in order to protect against a global catastrophic system failure.

N65 The ability for the System to allow for live updates to be deployed with minimal disruption to ongoing system operations, in order to ensure updates can actually be applied successfully where there is no permitted downtime.

N66 The ability for the System to be provided with sufficient spare components inventory that is continuously refreshed, to ensure the capability for comprehensive on-going maintenance, without disruption to System operations.


321