Rail OCC Control Software Replacement Project · 6/14/2003 · Rail OCC Control Software . Replacement Project . For . Washington Metropolitan Area Transit Authority. Scope of Work

Rail OCC Control Software

Replacement Project

For

Washington Metropolitan Area Transit Authority

Scope of Work

Task Order Number:

13-FQ10060-CENI-17

January 7, 2014

Gannett Fleming/Parsons Joint Venture

100 M Street SE, Suite 1100, Washington DC 20003

Rail OCC Software Replacement Statement of Work - Draft

Table of Contents 1. GENERAL INFORMATION ................................................................................................................................ 9

1.1 SUMMARY STATEMENT ........................................................................................................................................ 9 1.2 THE RAIL OPERATIONS CONTROL CENTER (ROCC) .................................................................................................. 10 1.3 LIST OF WMATA CONTROL CENTERS ................................................................................................................... 10

2. PROPOSAL REQUIREMENTS ......................................................................................................................... 12

2.1 QUALIFICATION OF BIDDER ................................................................................................................................. 12 2.1.1 Maintenance Experience ...................................................................................................................... 12 2.1.2 Form of Proof ....................................................................................................................................... 12

2.2 TECHNICAL PROPOSAL INSTRUCTIONS ................................................................................................................... 12 2.2.1 Introduction and Letter of Transmittal ................................................................................................ 12 2.2.2 Technical Submittal .............................................................................................................................. 12 2.2.3 Compliance Statement ......................................................................................................................... 13 2.2.4 Additional Instructions ......................................................................................................................... 13 2.2.5 Additional Information......................................................................................................................... 13

3. PROJECT REQUIREMENTS ............................................................................................................................. 14

3.1 PROJECT PHASES .............................................................................................................................................. 14 3.1.1 Contractor Development Environment ................................................................................................ 14 3.1.2 WMATA Development Enviroment ...................................................................................................... 14 3.1.3 Shadow Railroad from JGB ROCC ......................................................................................................... 14 3.1.4 Operate Railroad from JGB ROCC ........................................................................................................ 14 3.1.5 Shadow Railroad from CTF ROCC ......................................................................................................... 14 3.1.6 Operate Railroad from CTF ROCC ........................................................................................................ 14 3.1.7 Simulate and Train from JGB ROCC ...................................................................................................... 14 3.1.8 Periodic Maintenance & Upgrades of ROCC Software ......................................................................... 14

3.2 OPTIONAL FEATURES ......................................................................................................................................... 15 3.3 EXISTING OPERATIONS ....................................................................................................................................... 15 3.4 PROJECT MANAGEMENT .................................................................................................................................... 15

3.4.1 Project Team ........................................................................................................................................ 15 3.4.2 On-Line Collaboration .......................................................................................................................... 16 3.4.3 Contract Data Requirements List ......................................................................................................... 17 3.4.4 Action Items ......................................................................................................................................... 17 3.4.5 Kick-Off Meeting .................................................................................................................................. 17 3.4.6 Project Review Meetings and Teleconferences .................................................................................... 18 3.4.7 Project Status Reports .......................................................................................................................... 18 3.4.8 Change Orders ..................................................................................................................................... 18 3.4.9 Project Plan .......................................................................................................................................... 19 3.4.10 Project Office ....................................................................................................................................... 19 3.4.11 Deliverables.......................................................................................................................................... 19 3.4.12 Project Management Plan ................................................................................................................... 19

3.5 CONCEPT OF OPERATIONS (CONOPS) ................................................................................................................... 22 3.6 SAFETY AND SECURITY CERTIFICATION PROGRAM .................................................................................................... 23

3.6.1 General ................................................................................................................................................ 23 3.6.2 Safety and Security Certification Process Requirements ...................................................................... 23

3.7 QUALITY PROGRAM .......................................................................................................................................... 23 3.7.1 General ................................................................................................................................................ 23 3.7.2 Quality Assurance ................................................................................................................................ 24

Page 2


3.7.3 Source Quality Control ......................................................................................................................... 25 3.7.4 Software Source Code Version Verification .......................................................................................... 25 3.7.5 WMATA Quality Assurance .................................................................................................................. 26

3.8 SYSTEMS INTEGRATION PROGRAM ....................................................................................................................... 26 3.8.1 General ................................................................................................................................................ 26 3.8.2 SI Program Details ............................................................................................................................... 26 3.8.3 SI Program Hardware/Software Special Requirements ....................................................................... 27

3.9 IMPLEMENTATION PROGRAM .............................................................................................................................. 27 3.10 PROJECT DOCUMENTATION PROGRAM (CDRL T112) ............................................................................................. 28

3.10.1 Document and Design Review and Approval ....................................................................................... 28 3.10.2 Accuracy and Completeness of Documents ......................................................................................... 29 3.10.3 Standard Document Review ................................................................................................................. 30 3.10.4 Modified and Custom Document Approval .......................................................................................... 30

3.11 CONFIGURATION MANAGEMENT PROGRAM .......................................................................................................... 30 3.12 RISK MANAGEMENT PROGRAM ........................................................................................................................... 31 3.13 CYBER SECURITY PROGRAM ................................................................................................................................ 31

3.13.1 Secure Architecture .............................................................................................................................. 31 3.13.2 Vulnerability Management .................................................................................................................. 32 3.13.3 Coding for Security ............................................................................................................................... 33

3.14 PROJECT SCHEDULE ........................................................................................................................................... 34 3.14.1 General ................................................................................................................................................ 34 3.14.2 Schedule Activities ............................................................................................................................... 35 3.14.3 Schedule Milestones ............................................................................................................................ 36 3.14.4 Training Schedule ................................................................................................................................. 37 3.14.5 Test Schedule ....................................................................................................................................... 37

3.15 PROJECT PHASING AND TECHNICAL MILESTONES .................................................................................................... 37 3.15.1 General ................................................................................................................................................ 37 3.15.2 Preliminary Design ............................................................................................................................... 37 3.15.3 Software Detailed Design..................................................................................................................... 39 3.15.4 Hardware Detailed Design ................................................................................................................... 39 3.15.5 System Test Design .............................................................................................................................. 39

3.16 IMPLEMENTATION ............................................................................................................................................. 40 3.17 DESIGN REVIEWS .............................................................................................................................................. 40

3.17.1 Conceptual Design Review (CDR) ......................................................................................................... 40 3.17.2 System Requirements Review (SRR) ..................................................................................................... 41 3.17.3 Preliminary Design Review (PDR) ......................................................................................................... 42 3.17.4 Final Design Review (FDR) .................................................................................................................... 42 3.17.5 Test Readiness Review (TRR) ................................................................................................................ 43

3.18 SOFTWARE MAINTENANCE AGREEMENT ............................................................................................................... 45

4. GENERAL SOFTWARE REQUIREMENTS ......................................................................................................... 46

4.1 SYSTEM ARCHITECTURE ...................................................................................................................................... 46 4.2 DATA ACQUISITION ........................................................................................................................................... 46

4.2.1 Data Sources ........................................................................................................................................ 46 4.2.2 Front End Processors (FEP) ................................................................................................................... 48 4.2.3 Run-Time Database.............................................................................................................................. 50 4.2.4 Data Processing User Interface ............................................................................................................ 50 4.2.5 Data Processing Failure Handling ........................................................................................................ 51

4.3 INFORMATION STORAGE AND RETRIEVAL ............................................................................................................... 51 4.3.1 Historical Data Collection..................................................................................................................... 51 4.3.2 Information Retrieval User Interface ................................................................................................... 56 4.3.3 Information Storage and Retrieval Failure Handling ........................................................................... 57

4.4 PLAYBACK ....................................................................................................................................................... 57 4.4.1 Playback Functionality ......................................................................................................................... 57

Page 3


4.4.2 Integration of Playback with Radio Communication ........................................................................... 58 4.4.3 Integration of Playback with CCTV Video Management System ......................................................... 58 4.4.4 Playback Session Data Retrieval .......................................................................................................... 58 4.4.5 Playback Execution .............................................................................................................................. 58 4.4.6 Playback User Interface ....................................................................................................................... 60 4.4.7 Playback Failure Handling .................................................................................................................... 61

4.5 REPORTING...................................................................................................................................................... 61 4.5.1 Report Creation .................................................................................................................................... 62 4.5.2 Pre-Defined ROCC Reports ................................................................................................................... 62 4.5.3 Reporting Management User Interface ............................................................................................... 63 4.5.4 Reporting Failure Handling .................................................................................................................. 66

4.6 SIMULATION .................................................................................................................................................... 67 4.6.1 Simulation Functionality ...................................................................................................................... 67 4.6.2 Simulation Sessions .............................................................................................................................. 69 4.6.3 Simulation Session Data Retrieval ....................................................................................................... 69 4.6.4 Simulator Functionality for Training .................................................................................................... 69 4.6.5 Updates to the OCC Simulator ............................................................................................................. 70 4.6.6 Simulation User Interface .................................................................................................................... 70 4.6.7 Failure Handling ................................................................................................................................... 71

4.7 DISPLAY CONTROL ............................................................................................................................................ 71 4.7.1 Displays ................................................................................................................................................ 72 4.7.2 Display Selection .................................................................................................................................. 75 4.7.3 General Window Characteristics .......................................................................................................... 75 4.7.4 Print Control ......................................................................................................................................... 77 4.7.5 Display Control User Interaction .......................................................................................................... 77 4.7.6 Master Time ......................................................................................................................................... 79

4.8 ALARM PROCESSING REQUIREMENTS .................................................................................................................... 80 4.8.1 Alarm Definition ................................................................................................................................... 80 4.8.2 Alarm Presentation .............................................................................................................................. 82 4.8.3 Alarm Detection ................................................................................................................................... 83 4.8.4 Alarm Interactions ............................................................................................................................... 83 4.8.5 Alarm User Interface ............................................................................................................................ 85 4.8.6 Alarm Logging ...................................................................................................................................... 87 4.8.7 Alarm Failure Handling ........................................................................................................................ 87

4.9 ACCESS CONTROL PROCESSING ............................................................................................................................ 87 4.9.1 Function Access Assignments ............................................................................................................... 88 4.9.2 Area Assignments ................................................................................................................................ 89 4.9.3 Remote Access ..................................................................................................................................... 89 4.9.4 Log-on/Off ............................................................................................................................................ 89 4.9.5 Active User List ..................................................................................................................................... 90 4.9.6 User Classifications .............................................................................................................................. 91 4.9.7 Access Control User Interface .............................................................................................................. 91 4.9.8 Access Control Failure Handling ........................................................................................................... 92 4.9.9 Modifications to Access Control rights and privileges ......................................................................... 92

4.10 ADMINISTRATION AND MAINTENANCE PROCESSING ................................................................................................ 92 4.10.1 Database Management ....................................................................................................................... 92 4.10.2 Display Generation and Management ................................................................................................. 98 4.10.3 Reporting ........................................................................................................................................... 102

4.11 SUPPORT APPLICATIONS ................................................................................................................................... 102 4.11.1 Online Help and Documentation ........................................................................................................ 102 4.11.2 Software Utilities ............................................................................................................................... 104 4.11.3 Network Services ................................................................................................................................ 106 4.11.5 Support Application User Interface .................................................................................................... 110 4.11.6 Support Application Failure Handling ................................................................................................ 111

Page 4


4.12 EVENT MANAGEMENT ..................................................................................................................................... 111 4.12.1 Incident Reporting System (IRS) ......................................................................................................... 111

4.13 PROCESS GUIDANCE ........................................................................................................................................ 114 4.13.1 Tunnel Ventilation .............................................................................................................................. 114 4.13.2 Single Track Routing .......................................................................................................................... 115 4.13.3 Work Forms ........................................................................................................................................ 115 4.13.4 General Every Day Incidents .............................................................................................................. 115

5. HARDWARE ................................................................................................................................................ 116

5.1 HARDWARE PROCUREMENT .............................................................................................................................. 116 5.2 HARDWARE DESIGN ........................................................................................................................................ 116 5.3 HARDWARE INSTALLATION ................................................................................................................................ 117

6. INTERFACES ................................................................................................................................................ 117

6.1 CORE SYSTEM CONNECTIONS/REDUNDANCY ........................................................................................................ 118 6.2 DTS – DATA TRANSMISSION SYSTEM ................................................................................................................. 118 6.3 AEMS – AUTOMATED ENERGY MANAGEMENT SYSTEM......................................................................................... 118 6.4 FURTHER DTS/AEMS DEVELOPMENTS .............................................................................................................. 119 6.5 TRACK CIRCUIT OCCUPANY REPORTS .................................................................................................................. 119 6.6 PASSENGER INFORMATION DISPLAY SYSTEM (PIDS) .............................................................................................. 119 6.7 TRAIN-TO-WAYSIDE COMMUNICATIONS (TWC)................................................................................................... 119 6.8 CB-EMIS/PROTECT ........................................................................................................................................ 120 6.9 TRACK CIRCUIT MONITOR TOOL (TCMT) ............................................................................................................ 120 6.10 SCHEDULE ..................................................................................................................................................... 120 6.11 MAXIMO ....................................................................................................................................................... 121 6.12 TRAIN PROGRESS SERVER - /* BID OPTION */ ................................................................................................... 121 6.13 RAIL PERFORMANCE MONITOR (RPM) - /* BID OPTION */ ................................................................................ 121 6.14 INTEGRATION OF PLAYBACK WITH RADIO COMMUNICATION - /* BID OPTION */ ..................................................... 121 6.15 INTEGRATION OF PLAYBACK WITH CCTV VIDEO MANAGEMENT SYSTEM - /* BID OPTION */ ..................................... 122 6.16 LIST OF APPLICATIONS USED AT OCC .................................................................................................................. 122

7. SOFTWARE FUNCTIONALITY – RAIL TRANSIT OPERATIONS ........................................................................ 125

7.1 ROCC TAKE CONTROL BUTTON......................................................................................................................... 125 7.2 SIGNAL SYSTEM MONITORING AND CONTROL ...................................................................................................... 126

7.2.1 Topographic Database ....................................................................................................................... 126 7.2.2 Control Functions ............................................................................................................................... 126 7.2.3 Traffic/Direction Control .................................................................................................................... 127 7.2.4 Blocking .............................................................................................................................................. 127 7.2.5 Miscellaneous Signal Devices, Controls, and Indications ................................................................... 129 7.2.6 Control Action Validation ................................................................................................................... 129 7.2.7 Alarms and Advisories ........................................................................................................................ 130 7.2.8 User Interface .................................................................................................................................... 130 7.2.9 Miscellaneous Systems ...................................................................................................................... 133 7.2.10 SCADA Device Monitoring and Control .............................................................................................. 134 7.2.11 Failure Handling Control Action Failure ............................................................................................. 134

7.3 TRAIN MONITORING AND CONTROL ................................................................................................................... 134 7.3.1 Train Tracking Identification .............................................................................................................. 135 7.3.2 Route Alignment ................................................................................................................................ 135 7.3.3 Schedule Display ................................................................................................................................ 140 7.3.4 Single Track ........................................................................................................................................ 141 7.3.5 Train Identification ............................................................................................................................. 142 7.3.6 Train Record ....................................................................................................................................... 143 7.3.7 Train Propagation .............................................................................................................................. 143 7.3.8 Multiple Occupancies of a Single Track Circuit .................................................................................. 145

Page 5


7.3.9 Train ID Data ...................................................................................................................................... 145 7.3.10 Schedule Adherence ........................................................................................................................... 146 7.3.11 Train Run Origination ......................................................................................................................... 146 7.3.12 Changing Train Icon ........................................................................................................................... 146 7.3.13 Reversing Direction ............................................................................................................................ 146 7.3.14 Train Run Termination ....................................................................................................................... 147 7.3.15 Train Tracking Alarms and Advisories ................................................................................................ 147 7.3.16 Train Tracking User Interface ............................................................................................................. 149 7.3.17 Squiggle Lines..................................................................................................................................... 150

7.4 SCHEDULE MONITORING AND CONTROL .............................................................................................................. 150 7.5 TRACTION POWER MONITORING AND CONTROL ................................................................................................... 151

7.5.1 Traction Power System Design Requirements ................................................................................... 151 7.5.2 Traction Power User Interface ........................................................................................................... 153 7.5.3 Traction Power System Operations .................................................................................................... 154

7.6 TUNNEL VENTILATION MONITORING AND CONTROL .............................................................................................. 154 7.6.1 Tunnel Ventilation System Design Requirements .............................................................................. 155 7.6.2 Tunnel Ventalation User Interface ..................................................................................................... 157 7.6.3 Tunnel Ventalation Operation ........................................................................................................... 158

7.7 TUNNEL DRAINAGE MONITOR AND CONTROL....................................................................................................... 159 7.7.1 Tunnel Drainage System Design Requirements ................................................................................. 160 7.7.2 Tunnel Drainage User Interface ......................................................................................................... 161

7.8 PASSENGER INFORMATION DISPLAY SYSTEM ........................................................................................................ 162 7.9 WORKER AHEAD WARNING SYSTEM .................................................................................................................. 162 7.10 STATION MEP EQUIPMENT – /* BID OPTION */ ............................................................................................... 163 7.11 RAIL YARD MONITORING – /* BID OPTION */................................................................................................... 163 7.12 SCADA FOR USE OUTSIDE OF THE ROCC – /* BID OPTION */ ............................................................................. 163 7.13 100 PERCENT TRAIN TRACKING – /* BID OPTION */ .......................................................................................... 164 7.14 SYSTEM WIDE TRAFFIC REGULATION/MODELING – /* BID OPTION */ .................................................................. 164 7.15 OVERVIEW OF RAIL SYSTEM .............................................................................................................................. 164

8. TEST AND COMMISSIONING ....................................................................................................................... 165

8.1 MASTER TEST PLAN ........................................................................................................................................ 165 8.1.1 Plans and Processes ........................................................................................................................... 166 8.1.2 Variance Tracking Program ............................................................................................................... 168 8.1.3 Commissioning and Transition ........................................................................................................... 171 8.1.4 Inspection ........................................................................................................................................... 172 8.1.5 Preventive and Corrective Maintenance ............................................................................................ 173 8.1.6 Availability and Reliability Demonstration Tests ............................................................................... 173

8.2 FACTORY ACCEPTANCE TESTS ............................................................................................................................ 174 8.2.1 Pre-Factory Acceptance Testing ......................................................................................................... 176 8.2.2 Hardware Integration Test ................................................................................................................. 176 8.2.3 Functional Performance Test ............................................................................................................. 177 8.2.4 Integrated System Test ...................................................................................................................... 178 8.2.5 Hardware and Function Simulation ................................................................................................... 178

8.3 SITE TESTS ..................................................................................................................................................... 179 8.3.1 Site Installation Test ........................................................................................................................... 180 8.3.2 Site Performance Test ........................................................................................................................ 180 8.3.3 Site Update Period ............................................................................................................................. 181 8.3.4 Site Integrated System Test ............................................................................................................... 181

8.4 STARTUP AND FAILOVER ................................................................................................................................... 182 8.4.1 Processor Groups ............................................................................................................................... 182 8.4.2 Devices Controlled by Processors ....................................................................................................... 183 8.4.3 Error Detection and Failure Determination ....................................................................................... 184 8.4.4 Data Integrity ..................................................................................................................................... 184

Page 6


8.4.5 Processor Redundancy ....................................................................................................................... 185 8.4.6 Device Redundancy ............................................................................................................................ 185 8.4.7 Startup ............................................................................................................................................... 185 8.4.8 Failover .............................................................................................................................................. 186 8.4.9 Restart ............................................................................................................................................... 186

8.5 RELIABILITY, AVAILABILITY, AND MAINTAINABILITY ................................................................................................ 187 8.5.1 Functional Availability ........................................................................................................................ 188 8.5.2 Hardware Availability ........................................................................................................................ 188 8.5.3 Individual Device Availability ............................................................................................................. 189 8.5.4 Availability Analysis ........................................................................................................................... 189 8.5.5 Reliability, Availability, and Maintainability Program Plan ............................................................... 189 8.5.6 Reliability Calculations ....................................................................................................................... 190 8.5.7 On-going RAM Monitoring ................................................................................................................ 190

9. OPERATIONS AND MAINTENANCE ............................................................................................................. 191

9.1 OCC CONTROL PROTOTYPING ........................................................................................................................... 191 9.1.1 Prototyping System ............................................................................................................................ 191 9.1.2 Prototyping Activities ......................................................................................................................... 192 9.1.3 Prototype Configuration Management .............................................................................................. 194 9.1.4 Prototype Tracking and Documentation ............................................................................................ 194

9.2 PERFORMANCE/RESPONSE TIMES ...................................................................................................................... 195 9.2.1 General Performance/Response Time Criteria ................................................................................... 195 9.2.2 Control and Indication Transmission Response Time ......................................................................... 196 9.2.3 External System Interface Transmission Response Times .................................................................. 196 9.2.4 Response Time to User Input ............................................................................................................. 197 9.2.5 Display Response Time ....................................................................................................................... 197 9.2.6 Display Update Rate .......................................................................................................................... 197 9.2.7 Scaling and Translation Response Time ............................................................................................. 197 9.2.8 Alarm and Event Response Time ........................................................................................................ 197 9.2.9 Report Response Time........................................................................................................................ 197 9.2.10 Hardware Resource Utilization .......................................................................................................... 197

9.3 SUPPORT SERVICES ......................................................................................................................................... 198 9.4 CONTRACT AND CONTRACTOR MAINTENANCE ...................................................................................................... 198

9.4.1 Maintenance Plan .............................................................................................................................. 199 9.4.2 Maintenance Records ........................................................................................................................ 199 9.4.3 Maintenance Database ...................................................................................................................... 199 9.4.4 Display Control Graphical Library Maintenance ................................................................................ 200

9.5 RECOVERY & REBUILD UTILITIES & EQUIPMENT .................................................................................................... 202 9.5.1 Rebuild & Recovery Kit ....................................................................................................................... 202 9.5.2 Test Equipment .................................................................................................................................. 203

10. TRAINING ............................................................................................................................................... 204

10.1 GENERAL REQUIREMENTS ................................................................................................................................. 204 10.2 MASTER TRAINING PLAN .................................................................................................................................. 204

10.2.1 Top-level Master Training Plan .......................................................................................................... 205 10.3 DETAILED MASTER TRAINING PLAN .................................................................................................................... 205 10.4 TRAIN-THE-TRAINER ........................................................................................................................................ 205 10.5 TRAINING SCHEDULE ....................................................................................................................................... 205 10.6 TRAINING MATERIAL ....................................................................................................................................... 206

10.6.1 Instructor’s Guide ............................................................................................................................... 207 10.6.2 Participant’s Guide ............................................................................................................................. 208

10.7 TRAINING AIDS ............................................................................................................................................... 209 10.8 MAINTENANCE MANUALS ................................................................................................................................ 209 10.9 ELECTRONIC MEDIA FOR MANUALS AND GUIDES .................................................................................................. 209

Page 7


10.10 TRAINING METHODS ................................................................................................................................... 209 10.10.1 Multi-media, Computer-based and Web-based Training .............................................................. 209 10.10.2 Use of Software During Training .................................................................................................... 210 10.10.3 Video-Based Training ..................................................................................................................... 210 10.10.4 Video Recording of Instructor-led Courses ..................................................................................... 210 10.10.5 Contractor Instructor Qualifications .............................................................................................. 210 10.10.6 Pilot Program ................................................................................................................................. 211 10.10.7 Trainee Skill Level ........................................................................................................................... 211

10.11 TRAINING COURSE DESCRIPTIONS .................................................................................................................. 211 10.11.1 Operational Training ...................................................................................................................... 212 10.11.2 Maintenance Training Courses ...................................................................................................... 213 10.11.3 System Course Quantity and Class Size Requirement .................................................................... 215

11. DOCUMENTATION REQUIREMENTS ....................................................................................................... 217

11.1 PROJECT MANAGEMENT DOCUMENTS ................................................................................................................ 217 11.2 HARDWARE DOCUMENTATION .......................................................................................................................... 219 11.3 SOFTWARE DOCUMENTATION ........................................................................................................................... 222 11.4 PROTOTYPING DOCUMENTATION ....................................................................................................................... 226 11.5 TEST DOCUMENTATION ................................................................................................................................... 228 11.6 RELIABILITY, AVAILABILITY, MAINTAINABILITY DOCUMENTATION.............................................................................. 228 11.7 FINAL AS-BUILT DOCUMENTATION .................................................................................................................... 228 11.8 ROCC SOFTWARE USER MANUAL ..................................................................................................................... 229 11.9 DOCUMENT QUANTITIES .................................................................................................................................. 229

12. APPENDIX ............................................................................................................................................... 230

12.1 DEFINITIONS & ABBREVIAIONS .................................................................................................................. 230 12.2 CONTRACT DATA REQUIREMENTS LIST (CDRL) .................................................................................................... 233

Page 8


1. General Information

1.1 Summary Statement

The Washington Metropolitan Area Transit Authority (WMATA) intends to purchase Rail Operations Control Center (ROCC) software and configuration services to replace the existing software. The new ROCC Software should make the rail system safer for customers and employees, provide improved customer satisfaction through more reliable and efficient operation, increase fault tolerance by minimizing and simplifying equipment configurations and provide a platform that will allow WMATA to exploit new advances in technology.

The Contractor shall provide a turnkey software installation complete with testing, commissioning, and documentation. The software shall operate on WMATA supplied computer and network equipment. The Contractor shall provide ALL software, including operating systems, security applications, databases, utilities, maintenance or management programs, and other ancillary programs required for full service. The new software must be fully functional prior to replacing the existing ROCC software currently installed.

The new ROCC software shall be constructed so as to have a long service life and high return on investment. The new software shall be a Commercial-Off-The-Shelf (COTS) product supporting the greatest variety of industry standard protocols and interfaces.

As a minimum the new software shall provide the same functionality contained in the existing software including full system redundancy and hot standby features. The new software shall integrate with existing WMATA procedures and communications infrastructure. The new ROCC software must be flexible and robust enough to support planned and unplanned changes to WMATA communication infrastructures in the future.

The System shall provide 99.999% availability as a minimum. This is defined as no more than 6 minutes of System downtime in any 12 month period. System downtime would be the unscheduled unavailability of a dispatch center either JGB or CTF. System downtime and availability statistics shall be continuously calculated and displayed on a system maintenance console. The Contractor shall submit for approval a RAMS calculation that indicates the availability of each item including those items provided by WMATA (e.g. network devices, front end processors, console hardware). System availability shall be automatically measured and displayed on the ROCC supervisor’s console. The RAM calculation shall separate the hardware from the software reliability.

Ease of use is a key software design element. The new ROCC software shall include automation to reduce operator workload, shall have a similar look, touch and feel to the existing software package, and shall have an enhanced simulation and training capability.

Contractor selection will be based upon a number of factors including the overall feature package, ease of use, benefits of operation, initial procurement cost, and long term operating cost. These factors are described in the Technical Source Selection Plan.

The Work under this contract includes systems analyses and development of software, integrated processes, guidance documents, studies, technical reports, implementation plans and Hardware definition.

It further includes: Systems implementation, project staffing, documentation, System related training, all phases of train operation training, Contractor support, configuration management (CM), automated Systems requirements, reliability and maintainability, System support, safety, test and support equipment, maintenance planning, certification, and overall supportability requirements. The Contractor shall set up a software development lab, the Parallel Development Environment, specifically for this project and maintain this lab through the life of this contract and follow in maintenance agreements.

The ROCC software shall provide the Line Supervisors (including Assistant Line Supervisors and Transportation Superintendents) with a modern computer-based Centralized Traffic Control System (CTC) to monitor and control train movements. Interface will be provided to the SCADA system to acquire and display 3rd rail energization status, traction power, tunnel ventilation, and drainage equipment operation, as well as interface to provide view-only capability of the Video Display Wall to all individuals within the OCC facility.

Page 9


The Video Display Wall will allow many others to have a real-time view of the operation. The Overview display will depict key elements of service delivery including train locations, train types, and off-normal conditions such 3rd rail de-energization and the Workers Ahead Warning System (WAWS).

All of the functions that are identified herein are specified in greater detail within the Contract Documents.

1.2 The Rail Operations Control Center (ROCC)

The Rail Operations Control Center (ROCC) consists of the software, hardware and personnel that operate the WMATA Rail System. Functional components include:

a) Train Operations – operates the rail system and are the primary users of the ROCC software.

b) SCADA – operates the DC traction power and underground MEP systems and is controlled by the line supervisors.

c) Information – personnel that control the human information flow from the ROCC. They operate the various passenger information signs and other Systems and are also the interface to the media.

d) Maintenance – observes System behavior and reacts to System troubles by dispatching maintenance personnel, coordinating activities, and other means.

e) MMI - Human Factor Interface with Man Machine Interface (MMI) which is the display and control mechanism by which users interact with the System.

There is a ROCC located at the Carmen Turner Facility (CTF) and another at the Jackson Graham Building (JGB.) Either location shall be able to operate the entire railroad. Both locations function identically but there are differences in the room layout. This project shall replace the ROCC software at both locations. The computer hardware shall be supplied by WMATA using existing DELL and Cisco order agreements. This project shall also seek to improve integration of the ROCC software with other existing Systems.

The current ROCC software is the Advanced Information Management (AIM) software provided by the ARINC Corporation. This software was solicited by WMATA in 2002 and has undergone software improvements and corrections since the original installation. It was modified in 2007/2008 to enhance the Track Asset Management functionality. The current ROCC software is a mission-critical function used in daily operation of the passenger rail system and must maintain the highest level of safety integrity.

Currently, WMATA provides the day-to-day maintenance and support of ROCC software. Technical Staff is on-site 24 hours per day, 7 days each week, and Software Engineers are on-site five days per week (Monday through Friday, exclusive of holidays) with on-call/call-in availability for after-hours problems. The Rail Operations Control Center is staffed 24 hours per day 365 days per year.

1.3 List of WMATA Control Centers

Control Centers Primary Secondary Operations Critical

Rail Operations Control Center - ROCC CTF JGB YES Bus Operations Control Center - BOCC CTF JGB YES Maintenance Operations Control/Power - MOC CTF JGB YES Emergency Command Center (war room) CTF None YES Police Dispatch CTF JGB YES Security Operations Control Center – under construction

Pennsy None YES

Network Operations Center JGB None YES Main Data Center JGB CTF NO

Page 10


The Rail Operations Control Centers at CTF and JGB run on ARINC provided Advanced Information Management (AIM) software running on MS Windows. The AIM software interfaces with legacy field equipment (serial RTU’s) and newer QEI RTU’s for Traction Power.

The ROCC talks to a number of other transportation and security control centers as well as media outlets.

Page 11


2. Proposal Requirements

2.1 Qualification of Bidder

The Contractor shall be a systems integrator or software supplier with demonstrated experience of at least five (5) years in the design, installation, and testing of Rail OCC software or large scale, industrial grade SCADA systems. Specifically, the Contractor shall have demonstrated successful experience in providing at least two Rail OCC systems with the following characteristics or larger:

Two (2) Redundant Control Centers 250 Remote Terminal Units (RTUs) 100,000 input/output Points 50 Workstations/Consoles

2.1.1 Maintenance Experience

The Contractor shall demonstrate his capability to provide WMATA with multiyear on-call, on-site maintenance support for the Rail OCC software.

Provide an overview of the Proposer’s experience and capabilities rendering services similar to those included in this RFP. This description shall include a summary of the services offered, the number of years the Proposer has provided these services, the types of clients and geographic locations that the Proposer currently serves, and a synopsis of the Proposer’s experience including the general scope of the voice and data needs assessment and channel implementation plans that have been or are currently being developed.

Up to three references from its customers who are capable of substantiating the Proposer's ability to manage projects of comparable size, similar technical requirements and complexity

Each client reference shall be from a client for whom the Proposer provided service and shall include the name of client organization, the Name, title, and telephone number of point of contact for client organization, the value, type, and duration of contract(s) supporting client organization, and the services provided, scope of the contract, and objectives satisfied.

2.1.2 Form of Proof

The form of proof to be submitted with the Proposer’s technical proposal is to be an attachment to the Executive Summary that is a self-certification showing at least two deployments that meet all the described minimums as stated in Section 2.1. One reference for each deployment shall also be submitted to permit independent validation. All references will be contacted.

2.2 Technical Proposal Instructions

2.2.1 Introduction and Letter of Transmittal

The Introduction and Letter of Transmittal shall provide the necessary certification that the Proposal is a bona fide Proposal from the Proposer, and that the signer of the Proposal is authorized to make this Proposal on behalf of the Proposer. The letter shall designate by name not more than two individuals authorized to negotiate and sign the contract with the Purchaser on behalf of the Proposer. An executive summary may be provided as an attachment to the letter of transmittal. The letter shall contain a description of the scope of the project and the Proposer’s general plan for implementation. The letter of transmittal may also briefly set forth any particular information the Proposer wishes to bring to the Purchaser’s attention.

2.2.2 Technical Submittal

The Technical submittal shall provide a point-by-point response to the RFP using the same number sequence as the RFP and shall include a Compliance Statement as well as a Response to Additional Instructions section.

Page 12


2.2.3 Compliance Statement

The Proposer shall provide a compliance statement by completing the compliance matrix contained within this RFP. The compliance matrix provides space for a compliance response and explanation for each section of the RFP. There are three valid responses:

Any other response or lack of response will be assumed to be an exception.

2.2.4 Additional Instructions

In some RFP sections, additional instructions are included for Proposers. These instructions request specific information to be included in the Proposal, such as details on the feature specified in that section, equipment specification sheets or Proposer guarantees.

The outline of this section of the Proposal shall correspond to the outline of the RFP. For example, if Proposal instructions are included in Section 12.4 of the RFP, the information requested shall be provided in Section 12.4 of the Proposal point-by-point response.

2.2.5 Additional Information

After the point-by-point response, the Proposer may include any additional information, such as a discussion of the Proposer’s competitive advantages.

The Proposer’s technical proposal, not including the point-by-point response, shall be limited to 100 pages.

Response Meaning

Comply Proposal fully complies with the entire numbered section. When in doubt about the applicability or intent of a section, use this response and provide an explanation of your understanding of the section.

Exception

Proposal does not comply with requirements of the section. Explain the nature of the exception(s). If you take exception to more than one part of a section, identify the number of exceptions taken and provide explanations for each. Any item not explicitly identified as an exception in the Proposal will be considered compliant.

Not Applicable The section does not apply to the Proposer’s Proposal or system configuration. Use this with caution.

Page 13


3. Project Requirements

Proposal Requirement: The Proposer shall provide in his technical proposal detailed information about the Conformance to the Contract Requirements.

3.1 Project Phases

3.1.1 Contractor Development Environment

The Contractor shall assemble a complete mockup including operator consoles in the contractor factory or office. WMATA shall provide the hardware and the Contractor shall assemble the development environment.

3.1.2 WMATA Development Enviroment

The Contractor shall install the software into a WMATA assembled development environment. Provide a complete design for the development environment.

3.1.3 Shadow Railroad from JGB ROCC

The Contractor shall install the software into the ROCC at JGB. Shadow railroad operations from this location. Once it has been determined that the software is functioning properly, training shall be performed for operators and maintainers of the software

3.1.4 Operate Railroad from JGB ROCC

The Contractor shall demonstrate the ability to fall back to existing controls at CTF and then perform startup and acceptance testing from the JGB ROCC. The Contractor shall operate the railroad from JGB for a sufficient period of time to demonstrate the reliability of the software.

3.1.5 Shadow Railroad from CTF ROCC

The Contractor shall install the software into the ROCC at CTF. Shadow railroad operations from this location. Shadow the railroad from CTF for a sufficient period of time to demonstrate the reliability of the software.

3.1.6 Operate Railroad from CTF ROCC

The Contractor shall demonstrate the ability to fall back to existing controls at JGB and then perform startup and acceptance testing from the CTF ROCC. Operate the railroad from CTF for a sufficient period of time to demonstrate the reliability of the software.

3.1.7 Simulate and Train from JGB ROCC

The Contractor shall demonstrate the ability to fall back to existing controls at JGB and then perform startup and acceptance testing from the CTF ROCC. Operate the railroad from CTF for a sufficient period of time to demonstrate the reliability of the software.

3.1.8 Long Term Maintenance of ROCC Software

The Contractor shall provide development, testing, and advancement of the software package for the ten year period following final acceptance. The Contractor shall oversee the periodic maintenance of the ROCC Software package.

Page 14


3.2 Optional Features

The Contractor shall also include separate bid options not to be included in the Contractor’s base bid. In these proposed bid options, the Contractor shall propose how, or if, the ROCC software will incorporate any or all of several functions specifically called out in the Contract Documents as bid options. Labeled in the specifications with the marker /* BID OPTION */, the Contractor shall propose solutions for each of these identified optional functions, along with pricing of each broken out separately in the Contractor’s bid. These optional functions will be included in the Work only if WMATA and the Contractor can reach mutual agreement on the scope and pricing of the functions. Each optional function shall be negotiated separately.

3.3 Existing Operations

WMATA is a tri-jurisdictional government agency organization that serves the Washington, DC market. It falls under FTA jurisdiction. It has five lines, 86 stations, and about 107 miles of track. 47 stations and about 50 miles of track are underground. It provides over 700,000 trips per workday. The System is organized with a spoke-hub distribution architecture.

The original ROCC/ROCS was housed in the first basement level of JGB in downtown Washington DC. This System dated to the early days of Metro. As the System aged, technology advanced, and more services were desired, WMATA constructed a new facility at the suburban CTF. CTF houses security and other control centers in addition to the OCC. The JGB ROCC was updated to the new ROCS operating System. JGB also houses WMATA’s Network OCC, a 24/7 operation.

From Metro’s inception JGB was intended as the main control facility and it has ready access to all communications facilities. Later WMATA outfitted a new operational control center at CTF to both update capabilities and to create a more resilient System by having a back-up facility. CTF is near the end of the Orange Line and is served by redundant fibers on that branch.

JGB currently functions as a backup control center to the CTF location. As such it performs a mission critical function. This Contract shall work with WMATA to determine how the new System can be installed at JGB while maintaining the existing fail over capability. JGB has raised floors which may allow the existing dispatch positions to be relocated within the space while the new equipment is being installed, tested and certified.

3.4 Project Management

The Contractor shall provide project management services for this project.

The Contractor shall designate a single Design Build Project Manager (DBPM) to supervise and coordinate the Contractor’s work and to act as the primary point of contact for all project-related issues. The DBPM’s home office shall be located within 50 miles of the WMATA operating area. The intent is that the DBPM can respond to same-day meeting requests.

The Contractor shall prepare a Project Management Plan (PMP) (CDRL T102) that includes all tasks and milestones necessary to complete the requirements defined in the Statement of Work.

Proposal Requirement: The Proposer shall provide in his technical proposal contact information for the DBPM including: Name, Shipping address, Office phone number, Fax number, Mobile phone number, E-mail address

3.4.1 Project Team

The Proposer’s project team shall have experience with projects of similar size and scope as the proposed system. Team members shall be qualified and have experience in performing the tasks they are expected to perform in this project.

Page 15


The Contractor shall notify WMATA of its intent to replace key personnel assigned to the project. The Contractor shall provide names, resumes and three project references for proposed replacement personnel. WMATA shall have the right to approve or reject proposed key personnel.

Proposal Requirement: The Proposer shall provide in his technical proposal detailed information about the proposed project organization that as a minimum includes the following:

Provide names, resumes and proposed project responsibilities of key personnel and organizations for approval. Include, as a minimum;

DB Project Manager DB Software Design Manager DB System Integration Manager DB System Safety & Security Manager DB QA Manager

Provide a list of subcontractors, outlining the portion of the work for which each one is responsible. Provide names, resumes and proposed project responsibilities for each subcontractor’s key personnel for approval.

Provide an overall organization chart for the proposed project team for approval by WMATA. An organization chart of the Proposer shall be provided showing all major component units, which component(s) will perform the requirements of this Contract, where the management of this Contract will fall within the organization, and what corporate resources will be available to support this Contract in primary, secondary, and back-up roles.

3.4.2 On-Line Collaboration

The Contractor shall use PROCORE (www.PROCORE.com) as its on-line collaboration and project management tool. The Contractor will be granted access to WMATA’s PROCORE system and shall utilize PROCORE for storage and handling of all project documentation. The Contractor shall maintain the project information current and up-to-date in this system. The Contractor shall have a Procore Administrator whose primary responsibility is administration of the Procore on-line collaboration systems. All project staff from all parties involved shall be included on the distribution list.

PROCORE will be a centralized location for accessing these types of information:

a) Contract documents b) Design documents c) Project correspondence d) Project records: meeting minutes, action item lists, etc. e) Approved schedule and calendar coordination f) Contract changes and modifications g) Other documents that would benefit the project

3.4.2.1 Submittals

All submittals throughout the length of the project shall be uploaded to PROCORE and the Contractor shall utilize the submittal log generated by PROCORE.

3.4.2.2 Transmittals

All transmittals throughout the length of the project shall be uploaded to PROCORE.

A transmittal refers to documentation not included on the project submittal schedule, such as meeting agendas, meeting minutes, and change order requests.

Page 16


3.4.3 Contract Data Requirements List

The Contractor shall provide the documentation identified in the Contract Data Requirements List (CDRL). The CDRL is a list of the documentation and data deliverables to be produced and submitted by the Contractor as defined in this Statement of Work (SOW). A copy of the project CDRL can be found in Appendix 12.2 – Contract Documents Requirements List.

CDRL items are numbered in sequential order, starting with the section number. Documents shall retain the CDRL number when submitted. A suffix shall be added to the CDRL for each subsequent revision of the submittal. A letter shall be added to the CDRL number for each element of the submittal. All CDRL items shall be submitted to PROCORE via the submittal process.

The Contractor shall provide CDRL items by the required due date listed in the CDRL. WMATA is not responsible for delays which arise from late submittals. The CDRL shall be maintained by the Contractor and provided to WMATA on request and as part of the monthly reports.

The Contractor shall coordinate all work with WMATA’s scheduling requirements. This may require the Contractor to perform specific elements of the work (such as cutovers, installation of non-fixed equipment, etc.) outside of normal working hours.

3.4.4 Action Items

The Contractor shall develop and maintain an Action Item List (CDRL-T119). The action item list shall include the following information for each identified action item:

a) Item number b) Date opened c) Open/closed status d) Description e) Responsible party/parties f) Close date g) Action log

The Contractor shall update the action item list after each project meeting or teleconference and submit it to WMATA within five business days.

3.4.5 Kick-Off Meeting

The Contractor shall conduct a project kickoff meeting within 2 weeks from NTP. WMATA and the Contractor shall create and distribute the meeting agenda; however the Contractor should be prepared to discuss the following items during the kickoff meeting:

a) Introductions b) Project work plan c) Project review meetings d) Project teleconferences e) Action items f) Submittals g) Transmittals h) Punch-lists i) Project status reports j) Project understanding k) Status of project l) Sites m) Schedule n) Payment schedule o) Safety

Page 17


p) Quality control and quality assurance (required submittal) q) Subcontractors r) Action items s) Schedule for meetings and teleconferences t) Other items as needed

3.4.6 Project Review Meetings and Teleconferences

The Contractor shall conduct project review meetings each month during each phase of this project. The Contractor shall also conduct regular project teleconferences every two weeks in between the project review meetings.

The agenda (CDRL T101) for all project review meetings and teleconferences shall follow this general outline:

a) Review of minutes from last meeting/teleconference b) Activities from previous period c) Current project issues/concerns d) New issues and action items e) Plans for next period f) Schedule review g) Action item review h) Risk item review i) Date and time of next meeting or teleconference

The Contractor shall update the action item list, produce meeting minutes, and email meeting minutes to the Project Team within five business days after the project review meeting or teleconference for approval by WMATA (CDRL-0313.D).

3.4.7 Project Status Reports

The Contractor shall submit monthly project status reports to WMATA for the duration of the project (CDRL-0313.E). These monthly status reports shall describe:

a) Work completed during the previous month b) Scheduled items for the next month c) Red flag items d) Action items e) Updated project schedule f) CDRL actions g) Transmittal log h) Punch-list items i) Submittal schedule

Project status reports are to be submitted for approval by WMATA within five working days after the end of the month.

3.4.8 Change Orders

The Contractor shall promptly submit change order requests to WMATA for any contract change that has an impact on schedule, cost, system operation, or performance. Change order requests shall include the following information:

a) Customer name b) Project number and title c) Issue date d) Tracking number e) Contractor name

Page 18


f) Reason for change g) Description of change h) Contractor’s perception of cost impact i) Schedule impact j) Operational or performance impact

3.4.9 Project Plan

WMATA deems certain plans critical to the project’s overall success. After the award is made, the selected Contractor shall be required to provide a detailed Project Plan utilizing information gathered from their analysis efforts. The Contractor is expected to complete and deliver the plans in accordance with the proposed delivery schedule.

3.4.10 Project Office

The Contractor shall establish a project office in the WMATA service area and within one-half mile from a Metro station. The office shall open within 30 days of award of contract and remain open until completion of the warranty period. The local office shall be staffed during normal business hours on all days WMATA administrative offices are open for normal business. The DBPM shall be based in the Contractor's local office.

The Contractor shall provide adequate project staff assigned to the project throughout the term of the Contract to ensure that proper and timely responses can be made to WMATA requests and to ensure that the System is designed and deployed according to the project schedule.

3.4.11 Deliverables

Deliverables shall be submitted in draft within the specific time frames set forth in the Contract Documents. WMATA will provide approval or disapproval, with or without written comment within 15 workdays of submission by the Contractor. The Contractor shall revise the document based on WMATA comments and submit the revised version within five working days. WMATA reserves the right to approve or disapprove all revisions until approved.

3.4.12 Project Management Plan

The contractor shall provide a Project Management Plan that documents the Project Management Program. The Project Management Program (CDRL T102) be sufficiently comprehensive to enable The Washington Metropolitan Area Transit Authority (WMATA) to ascertain, with a high degree of confidence, that the Contractor will meet the requirements of the Contract Documents, and to enable WMATA to monitor the contractual effort. The Contractor shall establish an organization to properly manage the Work. The Contractor shall provide and maintain a secure, on-line document review website via Procore to manage and maintain copies of all project documentation, reviews, correspondence, submittals, and all other project documents. This Procore website shall be accessible by authorized WMATA project staff. Unless otherwise identified, all project documentation and information shall be loaded to and maintained by this secure document review and sharing System. Should the performance of any individual within the Contractor’s project team not meet the expectations of WMATA, the Contractor shall replace the individual with one approved by WMATA. This change in the Contractor’s project team shall not adversely affect the development, implementation, installation, and acceptance schedule as defined and shall require no modifications to compensation to the Contractor. Additional technical deliverables will be found in the Contract Documents.

Finalize the Preliminary Project Management Plan. Include, at a minimum, the following information:

a) Project title b) Organization Chart

• DBPM and other key personnel. • Definition of levels of responsibility and authority within the Contractor team • Qualifications of all personnel therein

c) Scope of the project

Page 19


d) Project description (narrative) e) Structure/organization of the project f) Core project team members (by positions, skill sets, and roles) g) Key tasks (with detailed descriptions)

• Planned/actual start and end dates for key tasks • Significant milestones (deliverables, decision points, etc.)

h) The methods and communications to be used to control the program schedule, design reviews, technical performance, program changes, subcontracts, purchase orders, in-service support, warranty, Systems assurance analysis, tests, and demonstrations.

i) Provide a description of the process and on-line document control tools to track and control project correspondence.

j) Critical success factors k) System performance criteria. l) A Submittal List and schedule listing drawings, documents, and data to be submitted for review and

approval during the design review phase of the program, and a schedule for the submittal of this information. Include a Contract Deliverables Requirement List (CDRL) based on the requirements identified in each Section of the Contract Documents. The CDRL shall contain the consolidated listing of all required data including specific format, quantity, frequency, and paragraph reference of submittal as required by the Contract Documents. Submittals include, but are not limited to, schedules, plans, procedures, reports, certificates, samples, certifications, test results, and as-built drawings. Every CDRL shall be updated to reflect the changes in design throughout the design, implementation, and warranty period so that the final set of CDRLs delivered at the end of the project shall represent the System design in place at the conclusion of the contract.

m) The CDRL list shall be in accordance with the following column headings: • Item Number; • Deliverable Description; • Requirements Reference Paragraph (i.e. location of requirement within the Contract Documents); • Scheduled Delivery Date(s); • Current WMATA acceptance status (i.e., pending, approved, conditionally approved,

disapproved); • Quantity: Number of documents, units, or copies required.

Page 20


3.4.12.1 Project Organization Chart

WMATA PROJECT MANAGER

WMATA PROJECT MANAGER

DIRECTOR, ROCC

DIRECTOR, ROCC

DB CONTRACTORPrincipal In ChargeDB CONTRACTOR

Principal In Charge

DB Project Manager

DB Project Manager

DB QA Manager

DB QA Manager

DB System Integration Manager

DB System Integration Manager

DB System Safety & Security Manager

DB System Safety & Security Manager

DB Software Design Manager

DB Software Design Manager

WMATA ROCC SOFTWARE REPLACEMENTPROJECT ORGANIZATION CHART

Part Time Position

Part Time Position

Full Time Position

Full Time Position

3.4.12.2 Design Build Project Manager (DBPM)

The Contractor shall designate a responsible individual on a full-time basis, fluent in English and subject to approval by WMATA (CDRL T103), to serve as DBPM for the entire term of the project. This individual shall have prior experience in management of large, integrated System procurements and be familiar with design, subcontractor equipment procurements, construction, test, and inspection of similar Systems. WMATA reserves the right to request the DBPM to be replaced with written notification provided to the Contractor. When notification is received, the Contractor shall replace the DBPM and this replacement shall be subject to approval by WMATA. Removal or replacement of the DBPM by the Contractor shall only be with the consent of WMATA upon written notification from the Contractor, describing the reason for removal or replacement.

The DBPM shall be granted full authority to render decisions on behalf of the Contractor pertaining to technical and commercial decisions on the Project. The DBPM shall serve as the Contractor’s representative in all meetings with WMATA and/or their duly appointed representatives. No substitution of the DBPM will be permitted without WMATA’s prior approval. Promptly notify WMATA of any problems or difficulties that may affect the timely or effective completion of the project or any scheduled deliverables. The DBPM shall be responsible for support provided by personnel or groups outside the project team during the period of performance for this contract, and shall have full authority to assign task priority as needed to meet the requirements of the project.

The DBPM shall represent the Contractor during progress meetings, design review meetings, warranty, contract change negotiations, and open item meetings with WMATA and with the DBPM’s supporting staff, be capable of addressing all issues on the agenda for each scheduled meeting. The DBPM shall arrange to have supporting staff members available for participation in these meetings, as required. The DBPM shall ensure that all elements of the design, development, and deployment meet the technical and contractual requirements, including:

a) Ensure that the project tasks are completed on time and within budget; b) Coordinate design and engineering activities;

Page 21


c) Furnish all submittals to WMATA; d) Be the sole point of contact between WMATA and the Contractor’s project team, unless otherwise

mutually agreed between the Contractor and WMATA; e) Keep WMATA fully informed of the status of the project; f) Participate in project status meetings at WMATA;

3.5 Concept of Operations (ConOps)

The Contractor shall submit for approval a ROCC software Concept of Operations (ConOps) (CDRL T104). This ConOps shall be developed in cooperation with WMATA personnel. Prominent in creation of the ConOps will be a thorough understanding and application of the rules described in the Metrorail Safety Rules and Procedures Handbook (MSRPH.) Describe the characteristics of the proposed OCC Control System from the viewpoint of each individual who will use that System, focusing on Train Control Supervisors and Radio Console Supervisors. Include a detailed review of the MSRPH and how its policies are implemented by the ROCC and aided by the ROCC software. The ConOps shall communicate the quantitative and qualitative System characteristics to all stakeholders. The ConOps will identify the each work element of the ROCC, if it is contained in the ROCC software or not. The ConOps process is a key design function and will define the requirements of the ROCC software software to be executed.

The ConOps shall include the following users:

a) Train Control (Button Pushers) b) Maintenance Personnel Train Controller; c) ROIC Communication Specialist; d) ROIC Liaison; e) Car Maintenance Controller; f) ELES Dispatcher; g) ELES Supervisor; h) MOC Supervisor – Power; i) MOC Supervisor – Communications; j) MOC Supervisor – Train Control; k) MOC Service Dispatcher; l) MOC Assistant Superintendent; m) ROC Assistant Superintendent; n) ROC Superintendent; o) System Administrator; p) Trainer; q) Trainee; r) System Support; s) Maintainer(s).

Prepare, with WMATA assistance, ready to execute procedures to continue Rail operations in the event of a categorized (minor to extreme) disaster or network/service disruption. The plan will include the components of a standard disaster recovery plan inclusive of the minimum necessary hardware and maintenance for support, and staffing.

As an additional deliverable deriving from the ConOps the Contractor shall provide a Functional Requirements Definition (FRD) (CDRL T105). This shall provide a complete list of all functional components and activities of the ROCC software. As a minimum it shall define how each Operator activity is carried out, how incoming data is integrated into the System, and how exported data is delivered. This Definition shall be used in Final Acceptance Testing to evaluate how well the delivered System meets design requirements.

The ConOps and FRD shall be maintained as living documents as the project progresses. All changes to the ConOps and FRD require the formal configuration management and appropriate approvals.

Page 22

http://en.wikipedia.org/wiki/System

http://en.wikipedia.org/wiki/Quantitative_property

http://en.wikipedia.org/wiki/Qualitative_property

http://en.wikipedia.org/wiki/Stakeholder_(corporate)


3.6 Safety and Security Certification Program

The Contractor shall conduct a Safety & Security Certification Program (SSCP) CDRL T106) for the ROCC Software. The end results shall be to comply with Federal Transit Administration (FTA) regulations related to Safety and Security Certification process and WMATA procedures including Hazard Analysis (CDRL T107)

3.6.1 General

This section is provided to clarify the process used to certify that the equipment and system supplied to WMATA under this contract complies with the specified safety and security requirements. The purpose of the WMATA Safety and Security Certification is to ensure that:

a) The design, construction, installation, testing and commissioning of all safety critical facility and system elements have been evaluated for compliance with the safety and security requirements, including applicable codes and standards, and to verify their readiness for operational review.

b) WMATA’s system is fully compliant with the technical specifications and the operational requirements identified in this document, and that it is safe and secure for customers, employees and the general public.

c) The objective is to achieve an acceptable level of safety and security risk through a systematic approach to safety hazards and security vulnerability management through adherence to the technical specifications, and testing and commissioning verification.

3.6.2 Safety and Security Certification Process Requirements

The Contractor shall participate in the WMATA Safety and Security Certification program throughout the duration of this contract. As a minimum the Contractor shall:

a) Prepare and submit a Certifiable Items List (CIL) (CDRL-0315) for the Safety and Security Certification process for review and approval.

b) Participate in working groups with WMATA safety, Security and project staff, whose purpose will be to review the certification status of the items in the CIL.

c) Demonstrate that the final design complies with the identified safety and security requirements for those items on the CIL.

d) Demonstrate that the construction, fabrication and installation comply with the safety security requirements for those items on the CIL.

e) Conduct tests and inspections to demonstrate compliance with the safety and security requirements for those items on the CIL.

f) Maintain a document management system that enables retrieval of verification documentation that demonstrates compliance with the safety and security requirements in designs, construction, fabrication, installation and testing for each item on the CIL. Verification documentation may consist of approved design drawings, analysis or calculation sheets, inspections, tests results, certificates or other supporting documentation.

g) Complete the design, construction/installation and testing sections on the WMATA Safety and Security Certification Compliance Checklist, as compliance with the requirements listed on the compliance check list is achieved.

h) Cooperate in providing the required verification documentation to WMATA. i) Manage and oversee compliance with the above WMATA safety and Security Certification Program

requirements.

3.7 Quality Program

3.7.1 General

The Contractor shall submit for approval a Quality Program Plan (CDRL T108) that addresses control of the quality of the Contractor’s design, installation workmanship, testing, training, and documentation. This Program shall also include reliability analysis of all elements.

Page 23


The Quality Program shall describe the methods for planning, implementing, and maintaining quality, schedules, and cost. The Quality Program shall contain a company policy statement that clearly defines the responsibilities of QA personnel. An organization chart shall be included to show the reporting relationships of all QA staff, and shall indicate the Contractor’s QA/QC representative, who shall be a full-time employee of the Contractor. The QA/QC representative shall report to the Contractor’s Principal In Charge.

The Quality Program shall at minimum, include procedures for the following activities:

a) Objectives, responsibilities, approach, methods, procedures, and tools to be used for ensuring quality products and services.

b) Proposed quality assurance staff and their responsibilities c) Purpose and scope data and scenarios (acceptance criteria) d) Adherence of products and activities to the applicable standards, procedures and requirements. e) Test activities and procedures f) Description of functional and technical testing approaches and methods g) Factory inspection and test processes and record maintenance. h) Timing/scheduling. i) How and when affected groups and individuals are to be informed of QA activities and results. j) How defects in the work products are to be identified corrected and retested. k) Reporting mechanism and frequency. l) Problem resolution escalation rules. How and when noncompliance issues that can’t be resolved

within the project are to be addressed by senior management. m) Procedures and records for equipment handling; inventory; storage; delivery; design control; changes

to documents; drawings; data; and specifications; release for shipment; shipping; evidence of compliance; corrective action; calibration/verification of measuring equipment and audit.

3.7.2 Quality Assurance

Provide a Software Quality Assurance Program (CDRL T109) (SQAP), consistent with that indicated in IEEE Standard 730, IEEE Standard for Software Quality Assurance Plans.

The SQAP shall include:

a) Quality Assurance program requirements for subcontractors. b) System installation, inspection, and test processes and records. c) Surveillance over all work, including subcontractors, for conformance and verification thereof with all

Contract requirements.

Establish technical and administrative surveillance and/or audit methods to ensure the highest degree of quality, and to correct potential problems without affecting the Contract schedule.

a) Discrepancy control. b) Evaluation and assessment of subcontractors’ QA programs. c) Feedback of problems, their resolutions to the Contractor’s engineering and production departments,

and corrective action. d) Qualification and certification of all personnel performing work for this Contract.

Engage an adequate number of skilled professionals who are thoroughly trained, experienced, and familiar with the specific requirements and methods needed for the proper performance of the work.

Verify that the required quality control inspection, testing, and documentation activities have been performed to assure that the equipment, materials, and construction comply with the requirements of the Technical Specification.

Monitor quality control over suppliers, manufacturers, fabricators, products, services, site conditions, workmanship, and installation to produce work of the highest quality.

Page 24


Take corrective actions in a timely manner to identify undesirable conditions affecting the quality of Work and the contract schedule.

All test results shall clearly include a statement that the item tested or analyzed conforms or fails to conform to the contract requirements. Each report shall be conspicuously stamped on the cover sheet in large red letters a minimum of ½ inch high "CONFORMS" or "DOES NOT CONFORM" to the Specifications as the case may be.

All test reports shall be signed by a testing laboratory's authorized person and countersigned by the Contractor. The Contractor shall provide all tests, reports, certifications and other documentation to the WMATA Project Manager promptly after the completion of tests.

The Contractor shall promptly reject work, which does not comply with the requirements of the Contract Documents. If the Contractor elects to propose that WMATA accept work that is nonconforming, the Contractor shall reimburse WMATA for the costs associated with the review of the nonconforming work by WMATA's Project Manager.

Develop quality assurance forms in a format acceptable to WMATA for all major elements of the work including any additional elements. See also Section 6.0 – Test and Commissioning for additional specifications for testing and quality requirements.

3.7.3 Source Quality Control

Document that each manufactured product, fabricated item, and software product is produced and tested to comply with highest quality standards. The Contractor shall perform required audits to maintain level of quality.

Document all software and System controls utilized during the analysis, design, build, test, and implementation including the CDS.

Do not deliver any product until certified quality assurance documents are satisfactorily reviewed by WMATA.

Do not schedule any factory tests/inspections by WMATA until these documents are satisfactorily reviewed by WMATA. Twenty-one (21) day’s prior written notice is mandatory for (re) scheduling any factory tests/inspections by WMATA.

WMATA reserves the right to source inspect the manufactured product or fabricated item after acceptance of the certified quality assurance documents. Any and all costs related to re-inspection(s) by WMATA shall be the responsibility of the Contractor.

The certified quality assurance documents shall identify and include any changes made to the material, manufactured product or fabricated item as compared to the Contract requirements and approved shop drawings. The Contractor shall describe as to how each change will affect the installation, space, and subsequent operations.

WMATA's review of certified quality assurance documents and inspections shall not relieve the Contractor from its "primary" responsibility for the quality of work

3.7.4 Software Source Code Version Verification

After delivery or escrow of the System software, at any time desired, WMATA will have the capability to ascertain the versions of the software source code supplied and to verify these versions against those installed in the equipment in service. All software source code shall be provided (i.e. delivered to WMATA or placed in escrow in accordance with the requirements of the Contract). Provided software shall consist of:

a) Contractor developed software, object code, source code with comments, and documentation, together with all Contractor developed programming tools, text editors, compilers, and supporting materials necessary for providing an executable version of the software.

Page 25


b) Programming contained in ROMs, PROMs and for firmware. c) Also included shall be any utilities developed or off the shelf programs used to trouble shoot the

software and or hardware. d) In addition, third-party software and supporting materials necessary for providing an executable

version of the software shall also be provided to WMATA. Each time that any version is revised, the provided software source code shall be updated accordingly.

e) All provided software source code shall be available for verification each time there is a modification to the software by the Contactor. When this software is accessed by WMATA, verification of the source code and tools shall be performed at the discretion of WMATA.

f) Using the source code and all uninstalled and unmodified third party software and software tools, and following the directions provided by the Contractor, WMATA shall generate the executable code software. Each software module shall generate and provide the proper version information when the executables are generated.

3.7.5 WMATA Quality Assurance

WMATA may, at its discretion, perform its own QA monitoring of work done under this Contract, including monitoring of the Contractor’s or subcontractor’s QA activities including performing industry standard audits. Such activities shall not reduce or alter the Contractor’s QA responsibilities, nor reduce or alter the Contractor’s obligation to meet the requirements of this document, including the schedule requirements.

After NTP, WMATA or its designee will have the right of free access to facilities of the Contractor and subcontractors. This right will permit WMATA to inspect, examine, and test items during manufacture and prior to shipment. On demand, the Contractor’s Quality Assurance Plan, procedures, and records shall be made available to WMATA for inspection and audit. In addition, copies of all drawings, diagrams, schedules, changes, and deviations shall be made available promptly upon request.

3.8 Systems Integration Program

3.8.1 General

The Contractor shall submit for approval a Systems Integration Plan (CDRL T110) that addresses how the Contractor will control the various interfaces to the System including software, hardware, the Human Machine Interface, needs of various departments within and outside the OCC, coordination with parallel projects, coordination of information and requirements between various plans, testing and certification.

The System Integration Plan shall contain a company policy statement that clearly defines the responsibilities of System Integration (SI) personnel. An organization chart shall be included to show the reporting relationships of all SI staff, and shall indicate the Contractor’s DB Systems Integration Manager, who shall be a full-time employee of the Contractor and assigned full time to this project. The Systems Integration Manager shall report to the DBPM.

3.8.2 SI Program Details

The Systems Integration Plan shall at minimum, include procedures for the following activities:

a) Identifying all work scope items and assuring they are appropriately assigned b) Identifying all stake holders and assuring they have appropriate notification c) Identifying all parallel projects and identifying the interfaces d) Procedures for identifying interfaces and their stake holders e) Facilitating meetings and discussion to resolve interface issues f) Procedures for tracking interfaces from identification, through technical resolution, test development,

testing, QA, Safety and Security certification, and final acceptance. g) Procedures for documenting the interface and document storage to provide a durable record of how the

interface works and why the interface was designed as it was. h) Procedures for escalating issues to assure resolution in a timely manner.

Page 26


i) Periodic reporting methods to document interface identification, status, and adherence to schedule. j) Procedures for modifying the database, networks and mapping/polling of the I/O from the existing

Horton RTU protocol to the Genysis Protocol. WMATA will be in the process of transitioning the field during this contract.

WMATA will post the current IO mapping, including required interlocking information, on the project Procore site. The Contractor will use these drawings as the basis of information to develop Systems integration solutions, including test plans. Test plans will be posted to Procore for review and approval.

3.8.3 SI Program Hardware/Software Special Requirements

Provide a list of all the hardware WMATA will need to purchase in order to support the ROCC Software deployment. Provide a list of equipment for each location. WMATA will procure all equipment. The Contractor shall assist WMATA in making these purchases. The Contractor shall provide all software including operating Systems, and virus protection required to provide a fully functional System. Coordinate with WMATA when reasonable choices exist. See also Documentation Requirements for Specification of the Hardware Specifications.

3.9 Implementation Program

The Contractor shall submit for approval an Implementation Plan (CDRL T111) that describes how the Contractor intends to effect the Work describing how the System shall be tested, cut over, and certified to function within the WMATA operational system. Include how the software shall be sequenced. It shall be coordinated with the Project Schedule and shall describe all major activities, giving the salient features and concerns. The Implementation Plan shall describe the process by which implementation details shall be defined and submitted for approval including look ahead time, coordination meetings, and review cycles.

As a minimum, the Implementation Plan shall describe in detail how the Contractor intends to stand up JGB, certify it, transfer operation from CTF to JGB, stand up CTF and certify, and then transfer operation back to CTF. Temporary operation with only one control center working is prohibited. Coordinate the Implementation Plan with the Transition Plan describe in Test and Commissioning.

The Implementation Plan shall also describe how the Contractor shall work with WMATA to receive hardware from WMATA, configure it, factory test, and return it to WMATA for installation. This shall include the network hardware necessary to create a full simulation.

This plan shall address (at a minimum):

a) Purpose and scope b) Objectives and stakeholders c) Activities and procedures prior to cutover (migration) d) Activities and procedures after cutover (migration) e) Description of interface strategy f) Description of interface process flow g) Strategy for identification of source and target files h) Strategy for ensuring non-interference with WMATA revenue operation generation i) Methods (batch vs. real time) j) Data element mappings k) Data translation requirements l) Data routing and distribution m) Timing n) Volume metric o) Interface program unit test execution and validation p) Contingencies

Both existing control centers (CTF and JGB) must remain fully functional and capable of fall back operation until the new ROCC software is completely installed and tested at both CTF and JGB. The Contractor, working

Page 27


with WMATA, shall develop a cut-over strategy that will support this requirement. For proposal purposes only assume that the initial installation will occur at CTF and that sufficient room will exist at CTF to deploy and test JGB System prior to moving it to and installing in JGB and performing final tests. After award, the Contractor shall work with WMATA to develop a detailed cut-over strategy based upon field conditions as they evolve in the interim.

3.10 Project Documentation Program (CDRL T112)

All documents shall be provided electronically (e.g., on CD) and in hard copy to WMATA and soft copies will be posted to a WMATA documentation service, Procore. All deliverables shall be in the WMATA standard, currently MS Word, unless otherwise agreed to in writing by the WMATA Project Manager. The format of all electronic submissions shall be reviewed and approved by WMATA prior to the Contractors first submission. Provide a template for each type of document so that there is a consistent look and feel between documents. Indicate the delivery schedule including interim submittals, and suggested reviewers.

Provide, develop and maintain an on-line library of all project documents and deliverables. The library shall be made available to all WMATA staff involved in this project. The on-line library will be located on WMATA intra-net with appropriate security access. Provide a reporting mechanism and frequency.

3.10.1 Document and Design Review and Approval

To ensure that the proposed ROCC software conforms to the specific provisions and general intent of the Specification, the Contractor is required to submit documentation describing of each ROCC software to WMATA for review and approval.

The Contractor shall schedule WMATA review of all submittals and response of written comments as a minimum twenty (20) working days after receipt of the documents for each 200 pages, or fraction thereof, of technical information inclusive of all written and drawing content. Documents will not be approved without appropriate time for review regardless of the milestone schedule impact.

Minimum WMATA review time allocated in Contractor schedules shall be based on page limitations such that title pages, table of contents, indices, and other non-technical data shall not be considered part of the page count limitation for submittals.

The Contractor shall request WMATA approval to schedule submittals that exceed the page limitations, for a lesser review turnaround period.

Documents requiring correction shall be resubmitted by the Contractor to WMATA for approval as soon as possible, but not more than fifteen (15) working days from the time WMATA comments were received, unless approved by WMATA.

The Contractor shall schedule WMATA review of resubmitted documents a minimum of ten (10) working days after receipt of the document. No implementation schedule relief will be given for documents requiring further correction and resubmission to WMATA.

The Contractor shall revise and resubmit within ten (10) working days of receipt of returned documentation, all documentation that has been reviewed by WMATA and has not been approved.

The Contractor shall be permitted to make a partial submission of documentation only upon written request by the Contractor and agreement by WMATA.

a) In the event a partial submission is made, the corresponding sections of the Functional Requirements Definition (FRD) (CDRL T105) shall be provided to aid WMATA in review of the submission.

b) In the event a partial submission is made, the Contractor shall provide corresponding sections of Engineer requested documentation to aid WMATA in review of the submission.

Page 28


The Engineer will have the right to require any changes, omissions and additions to be made in submittals that fail to meet the requirements of this contract. Should a submittal not be approved by WMATA, then WMATA may communicate the specific reasons for failure to the Contractor as follows:

a) Return ‘marked’ copies of the failed submittal with the necessary corrections and changes indicated in red thereon;

b) Return written comments in a standard WMATA comment form enumerating each deficiency, concern, issue, or discrepancy along with indication of the associated location(s) within the submittal;

c) Return a combination of ‘marked’ copies and written comments.

The Engineer may reject and return submittals to the Contractor where WMATA has been given insufficient information to evaluate them properly or the submittal fails to meet the majority of requirements associated with the submittal.

All resubmission of documentation shall include a written disposition of all comments from the previous submission. These dispositions shall be provided with the resubmission and shall be provided in electronic format as well as hard copy.

Resubmission of documentation shall include change markings (i.e. highlighted text, change bars) for all changes to the document except where the document has been completely rewritten. In the case of a complete rewrite, the document revision notice shall clearly state which material has undergone complete update.

Stagger the release of documents over the time allocated in the Project Schedule for document review. Make any necessary documentation changes at no additional cost to WMATA to achieve conformance with the Specification.

Any purchasing, manufacturing, or programming implementation initiated prior to written approval of WMATA of the relevant formal design reviews, documents or drawings is at the Contractor's risk. Review and approval by WMATA shall not relieve the Contractor of its overall responsibilities to satisfy system functions in accordance with the Specification.

The Engineer retains full approval rights over all documentation regardless of the document classification: standard, modified, or custom classification. The Engineer has full approval rights over the format of displays and user interface pertaining to ROCC software functions.

3.10.2 Accuracy and Completeness of Documents

Review all equipment and system operation, maintenance, and programming instructional material supplied by product manufacturers and installers for accuracy, completeness and clarity prior to submittal of the material to WMATA.

Ensure that the personnel preparing of each ROCC software documentation required by this Specification, have a thorough understanding of the requirements and design to the degree appropriate to the phase in which the document is being produced.

Ensure that the personnel preparing ROCC software, Operations, and Maintenance documentation required by this Specification, have a thorough understanding of each ROCC software operations and maintenance and are sufficiently skilled in technical writing to properly communicate complete system operational and maintenance information.

Prior to submitting documents for Engineer review, the Contractor shall quality check submittals for both form and content. Points to be checked shall include:

a) Conformance to the Specifications; b) Usability; c) Logical grouping and arrangement of the matter; d) Accuracy;

Page 29


e) Consistency of presentation; f) Grammar; g) Pagination; h) Legibility; i) Neatness; j) Line quality; k) Lettering quality; l) Reproducibility; m) Inclusion of Contract specified interfaces with related contracts.

To be accepted for review the Contractor's Quality Assurance representative must check and sign all documents, or the documents.

3.10.3 Standard Document Review

Furnish documentation of the Contractor's standard hardware, software, and firmware. Provide all standard documentation in conformance with these Specifications that accurately and completely describe all features and options of the hardware, software, and firmware that pertain to WMATA's ROCC software. Ensure that documentation does not describe features or options of the hardware, software, and firmware that do not pertain to of each ROCC software, and that documentation provides all required information necessary to meet the requirements of these Specifications.

3.10.4 Modified and Custom Document Approval

The Contractor is responsible for modifications to standard hardware, software, or firmware documentation. Modification or customization of standard documentation by the Contractor shall be in full conformance to all Contract requirements. Changes and modifications to standard Contractor products shall be documented in a complete and clear manner in accordance with the approved documentation standards.

3.11 Configuration Management Program

The Contractor shall submit for approval a Configuration Management Program Plan (CDRL T113). This plan shall include procedures, and records for change control and version management for both hardware and software.

Identify the roles and responsibilities of WMATA, the user community, the Contractor and other Contractor team members in performing configuration management. Indicate software, hardware, and documentation configuration management activities planned. Identify problem resolution escalation rules

Identify objectives, responsibilities, approach, methods, procedures, and tools to be used for managing the configuration of the System including change control and problem reporting and corrective action.

Describe how and when software work products are to be identified, controlled, and made available, as well as how and when affected groups and individuals are to be informed of the status and content of software/document product baselines.

All software including all source code, compilers, etc. shall be escrowed and maintained in the current operational configuration, along with copies of all previous operational configurations. These files shall be maintained so that the ROCC software can be restored and deployed at any time.

Changes shall include the following:

a) Fixes: corrections of malfunctions (“bugs”) that are required in order to meet functional requirements as specified in this specification.

b) Updates: new software releases provided by the Contractor, whether for application software, operating System software, or third party software.

c) Enhancements: changes that provide improvement in the operation.

Page 30


d) Modifications: changes necessitated by program changes. e) Upgrades: augmentation and/or replacement of any System hardware. f) Any other modifications to the hardware or software not specifically identified above. g) Coordinate with the variance tracking requirements found in Section 6.0 – Test and Commissioning,

and Section 10.0 – Documentation Requirements.

3.12 Risk Management Program

The Contractor shall submit for approval a Risk Management Plan (CDRL T115). This plan shall identify and manage potential risks that threaten to increase project costs, lengthen the project schedule or compromise project performance. The Risk Management Plan shall include the formal four-step process that includes Risk Planning, Risk Identification, Risk Analysis, and Risk Control. The Risk Management Plan shall include an associated Risk Management Process that continues throughout the project with the monitoring of potential risks and a well-planned response to correct problems as they occur.

Address (at a minimum) the following:

a) Overall risk management strategy and approach b) Contractors processes and procedures to identify, categorize, analyze, and mitigate risks including the

roles and responsibilities of WMATA, the Contractor and its partners (subcontractors) c) Managing multiple transitions at geographically dispersed locations across various entities

simultaneously and for managing risks associated with schedule slippages d) Managing cost growth and schedule slippages of subcontractors e) Determination of risk status and measure the progress of risk mitigation efforts. f) The process and included software functionality for performing hardware scans. Hardware scans

should be able to run automatically on a schedule and would include reports on items such as: memory, hard disks, processors, partitions, printers, modems, mouse devices, monitors, video cards, network adapters, USB devices, SMBIOS data, IPX addresses, IP addresses, PCI devices, and storage devices

g) Reporting mechanism and frequency h) Problem resolution escalation rules.

3.13 Cyber Security Program

The Contractor shall submit for approval a Cyber Security Program plan (CDRL T623). This plan shall detail how cyber security shall be implemented. It shall include a detailed description of technologies, processes and practices designed to protect networks, computers, programs and data from attack, damage or unauthorized access and that appropriate protection measures applied are commensurate with the risks (i.e., consequences and their probability) of loss, misuse, or unauthorized access to or modification of information. All Information systems which are defined as a set of information resources organized for the collection, storage, processing, maintenance, use sharing, dissemination, disposition, display, or transmission of information must have proper cyber security countermeasures engineered into the overall system design.

The Contractor shall agree in writing that the terms of this Contract shall apply to Contractor’s employees, as well as to third party contractors and subcontractors that will be employed by Contractor for the Contract.

The existence of these requirements does not forego engineering practices. The prime requirements, functions, design, and expected system behaviors need to be taken into account prior to modifying security requirements. Each topic should be considered individually.

3.13.1 Secure Architecture

Post contract award, the Contractor shall document secure network architecture where the higher-security zones originate communication to less-secure zones in collaboration with WMATA stakeholders.

Post contract award, the Contractor shall provide and document the design for all communication paths between networks of different security zones.

Page 31


Post contract award, the Contractor shall verify and document that disconnection points are established between the network partitions and provide the methods to isolate subnets to continue limited operations.

Post contract award, the Contractor shall provide and document tailored filtering and monitoring rule recommendations for all security zones and alarm for unexpected traffic.

Post contract award, the Contractor shall define all sources and destinations with enforced communication origination even during restart conditions between security zones.

3.13.2 Vulnerability Management

Vulnerability Management is the cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities. The expected result is to reduce the time and money spent dealing with vulnerabilities and exploitation of those vulnerabilities. Proactively managing vulnerabilities of systems will reduce or eliminate the potential for exploitation and involve considerably less time and effort than responding after exploitation has occurred.

Vulnerability Management encompasses two primary activities:

a) System Hardening b) Sustainability & Supportability

3.13.2.1 System Hardening

The Contractor shall implement and document mandatory configuration settings for information technology products employed within the information system that reflect the most restrictive mode consistent with operational requirements based on the Center for Internet security configuration benchmarks.

The Contractor shall implement cyber security best practices for any information system that does not have a documented Center for Internet Security benchmark available. Best practices include but are not limited to practices published by the Department of Homeland Security, National Institute of Standards & Technology, Contractor Security Guides and Industrial Control organizations with an established cyber security program.

The Contractor shall provide a Vulnerability Matrix (CDRL T116) that denotes required deviation from the Center for Internet Security benchmark requirements for WMATA Metro IT Security acceptance.

3.13.2.2 Sustainability & Supportability

Post-contract award, the Contractor shall provide documentation detailing all applications, utilities, system services, scripts, configuration files, databases, and all other software required and the appropriate configurations, including revisions and/or patch levels for each of the computer systems associated with the control system.

The Contractor shall provide a listing of services required for any computer system running control system applications or required to interface the control system applications. The listing shall include all ports and services required for normal operation as well as any other ports and services required for emergency operation. The listing shall also include an explanation or cross reference to justify why each service is necessary for operation.

The Contractor shall verify and provide documentation that all services are patched to current status. The Contractor shall provide, within a pre-negotiated period, appropriate software and service updates and/or workarounds to mitigate all vulnerabilities associated with the product and to maintain the established level of system security for the life of this contract vehicle.

The Contractor shall remove and/or disable all software components that are not required for the operation and maintenance of the control system prior to deployment. The Contractor shall provide documentation on what is removed and/or disabled. The software to be removed and/or disabled shall include, but is not limited to:

Page 32


a) Device drivers for network devices not delivered b) Messaging services c) Servers or clients for unused Internet services d) Software compilers in all user workstations and servers except for development workstations and

servers e) Software compilers for languages that are not used in the control system f) Unused networking and communications protocols g) Unused administrative utilities, diagnostics, network management, and system management functions h) Backups of files, databases, and programs used only during system development i) All unused data and configuration files j) Sample programs and scripts k) Unused document processing utilities (MicrosoftWord, Excel, PowerPoint, Adobe Acrobat,

OpenOffice, etc.).

3.13.3 Coding for Security

3.13.3.1 Application Development

The Contractor shall take all actions necessary to protect information regarding security issues and associated documentation, to help limit the likelihood that vulnerabilities in operational Purchaser’s software are exposed.

Consistent with the provisions of this Contract, the Contractor shall use the highest applicable industry standards for sound secure software development practices to resolve critical security issues as quickly as possible. The “highest applicable industry standards” shall be defined as the degree of care, skill, efficiency, and diligence that a prudent person possessing technical expertise in the subject area and acting in a like capacity would exercise in similar circumstances.

Pre-contract award, the Contractor shall provide written documentation detailing their application development, patch management and update process. The documentation shall clearly identify the measures that will be taken at each level of the process to develop, maintain and manage the software securely.

The Contractor shall provide secure configuration guidelines in writing that fully describe all security relevant configuration options and their implications for the overall security of the software. The guideline shall include a full description of dependencies on the supporting platform, including operating system, web server, and application server, and how they should be configured for security. The default configuration of the software shall be secure.

Pre-contract award, the Contractor shall specify in writing to what industry security standards and level of care that they follow.

3.13.3.2 Development Environment

a) Secure Coding • The Contractor shall disclose what tools are used in the software development environment to

encourage secure coding. b) Configuration Management

• The Contractor shall use a source code control system that authenticates and logs the team member associated with all changes to the software baseline and all related configuration and build files.

c) Distribution • The Contractor shall use a build process that reliably builds a complete distribution from source. This

process shall include a method for verifying the integrity of the software delivered to Client. d) Disclosure

Page 33


• The Contractor shall document in writing to the Purchaser all third party software used in the software, including all libraries, frameworks, components, and other products, whether commercial, free, open-source, or closed-source.

e) Evaluation • The Contractor shall make reasonable efforts to ensure that third party software meets all the terms of

this agreement and is as secure as custom developed code developed under this agreement.

3.13.3.3 Testing

a) General • The Contractor shall provide and follow a security test plan that defines an approach for testing or

otherwise establishing that each of the security requirements has been met. The level of rigor of this test process shall be detailed in the plan. The Contractor shall implement the security test plan and provide the test results to WMATA in writing.

b) Vulnerability Test • The Contractor shall agree in writing that prior to production the application shall undergo

vulnerability a test.

Post production, the Contractor shall perform contractually agreed upon security scans (with the most current signature files) to verify that the system has not been compromised during the testing phase.

The Contractor shall provide written documentation of the results of the scans and tests along with a mitigation plan. The Contractor shall agree in writing that these vulnerabilities shall be mitigated within a pre-negotiated period.

3.13.3.4 Delivery of Secure Application

The Contractor shall provide a “certification package” consisting of the security documentation created throughout the development process. The package shall establish that the security requirements, design, implementation, and test results were properly completed and all security issues were resolved appropriately.

The Contractor shall resolve all security issues that are identified before delivery. Security issues discovered after delivery shall be handled in the same manner as other bugs and issues as specified in this Agreement.

3.13.3.4.1 Self-Certification

The Security Lead shall certify in writing that the software meets the security requirements, all security activities have been performed, and all identified security issues have been documented and resolved. Any exceptions to the certification status shall be fully documented with the delivery.

3.13.3.4.2 No Malicious Code

Developer warrants that the software shall not contain any code that does not support a software requirement and weakens the security of the application, including computer viruses, worms, time bombs, back doors, Trojan horses, Easter eggs, and all other forms of malicious code.

3.14 Project Schedule

3.14.1 General

The Contractor shall submit for approval a detailed Project Schedule (CDRL T117) (e.g., a Gantt chart) including a Work Breakdown Structure, WBS milestones, and deliverables, over the life of the project using Microsoft Project. The Project Schedule shall cover all phases of the work and shall include the following:

a) Work item descriptions that convey the scope of work indicated. Work items shall be discrete items of work that will be accomplished in execution of this Contract. Work items shall include the scheduled

Page 34


dates for submittal and required response dates for approval of Contractor drawings and documentation. Work items shall also include specific line items for all defined Milestone Payment Schedule payment events from the Contract Milestone Payment Schedule. It shall include the schedule for design reviews, procurement of materials and equipment, fabrication of materials and equipment and their installation and testing, delivery of WMATA-furnished and other third party items and information, qualification tests and delivery, and testing. Estimated work item duration in whole working days shall be indicated for each work item of the schedule.

b) The sequence, successor, and predecessor interrelationships among work items shall be considered in developing the schedule and shall be included as indicated.

c) Work item descriptions shall be accompanied by narrative explanation of what the work item comprises and the basis for the estimated work duration.

d) Sufficient detail shall be provided to indicate the manufacturing, testing, shipment, storage, and installation status of each type of equipment.

e) Sufficient detail shall be provided for the analysis, design, build, test, and implementation of each of the applications on the application server. Work details shall include, but not be limited to, review of legacy applications being replaced, gap analysis, data conversion plan, interface plan, integration plan, development milestones, milestone reviews, test plan, implementation plan and post-production support.

f) The Contractor’s initially submitted schedule that is approved by WMATA shall become the Base Line schedule. Subsequent schedule updates shall show performance against the original Base Line schedule.

g) The Contractor’s schedule shall include work breakdown activities of sufficiently short duration to facilitate adequate tracking of each activity by both the Contractor and WMATA.

h) The Project Schedule shall indicate the quantity of resources (e.g. personnel) required for all work performed on WMATA property and for Non-Contractor Activities.

i) Color code activities: • Green: on schedule, • Yellow: late but not affecting the Critical Path, or • Red: affecting the critical path.

3.14.2 Schedule Activities

The Project Schedule (CDRL T117) shall contain all Contractor activities integrated with WMATA activities and schedules, including but not limited to the following:

a) Project Design Reviews; b) Management/Progress Reviews. c) Documentation preparation and submission; d) Documentation revision and submission following WMATA’s comments; e) Formal design reviews and milestones; f) Hardware purchases, development, and integration; g) Fact finding meetings with Contractors and Owners personnel; h) Prototyping cycles; i) Requirements analysis: including ConOps and Functional Requirements Definition (FRD) (CDRL

T105); j) System assurance analyses (timing analysis, reliability, availability, and maintainability); k) Safety and Security Certification Program defined activities (SSCP – including hazard analysis)

(CDRL T106); l) Software implementation, unit testing, and integration; m) System integration; n) Pre-factory testing and factory testing; o) Shipment and installation; p) Field testing; q) Transition periods; r) Availability and Reliability testing; s) Maintainability demonstration; t) Training;

Page 35


u) Final deliverables; v) Facility work outside the Control Centers; w) Field Equipment installation, wiring, and testing; x) Systems checkout; y) Contractor Quality Audits;

Actual progress shall be tracked against the original schedule and risk analysis shall be performed to identify areas that may present potential delays. The Contractor shall perform a risk analysis of the Project Schedule and submit a risk assessment report to WMATA monthly at each progress meeting.

The Project Schedule shall include all activities that are performed by others, in which the Contractor is dependent on those activities to progress ROCC software work, including:

a) Prototype review and approval; b) CDRL review and approval; c) Database review and approval; d) Display review and approval; e) Report review and approval; f) Dependent Force Account activities; g) System interface support; h) Control center construction (building modifications); i) Participation in Pre-FAT and FAT; j) Participation in installation and test; k) Participation in site testing and site update period; l) Participation during the transition period; m) Participation in availability and reliability testing; n) Training in the use of each ROCC software for service delivery; o) Participation in Training.

3.14.3 Schedule Milestones

The Contractor shall incorporate major schedule milestones in all Project Schedule. Schedule each milestone with sufficient time allocated for Engineer review of milestone materials, correction and resubmission, and Engineer approval of all milestone materials prior to initiation of milestone review.

The Project Schedule shall define:

a) Mobilization, including but not limited to establishing all offices where work on the project will be performed (including the project office), to finish within ten (10) weeks from NTP.

b) Delivery of Engineer approved Process Plans, as required during System Analysis and Definition phase.

c) Each milestone within the Project Schedule. d) System Requirements Review (SRR) (CDRL T152) to be completed and accepted by WMATA. e) Delivery of Engineer approved Requirements Analysis phase outputs, . prior to initiation of SRR. f) Preliminary Design Review (PDR) (CDRL T153) to be completed and accepted by WMATA. g) Final Design Review (FDR) (CDRL T154) to be completed and accepted by WMATA. h) Test Readiness Review (TRR) (CDRL T155) to be completed and accepted by WMATA. i) Pre-Factory Acceptance Test (pre-FAT) to be completed and accepted by WMATA (FAT readiness),

prior to initiation of Factory Acceptance Tests (FAT). j) The shipment of each ROCC software from the factory after Engineer approved completion of FAT. k) Site Integrated System Tests to be completed and accepted by WMATA. l) Phase 1 Transition for each separate ROCC software to be started after Engineer approved completion

of Field Update Period activities. m) Completion of all ROCC software training courses conducted by the Contractor prior to the start of

Phase 1 Transition. n) Phase 2 Transition to be started immediately following Phase 1 Transition completion and approval by

WMATA.

Page 36


o) Beneficial Use separately for each ROCC software following completion and Engineer approval of Transition Phase 1.

p) The Availability and Reliability Demonstration Test to start after completion and acceptance by WMATA of all Transition phase activities.

q) Substantial Completion following completion and Engineer approval of Availability and Reliability Demonstration Test.

At least one month shall be reserved in the Project Schedule between the completion of the Site Installation and Performance Test and the beginning of the Site Integrated System Test.

3.14.4 Training Schedule

The Contractor shall provide a recommended Training Schedule, for all proposed training courses. Contractor may submit a single overall Training Schedule covering required training for all applicable ROCC software package or may deliver a Master Training Schedule along with separate submittals for each ROCC software.

The Training Schedule shall:

a) Be tailored to meet the needs of WMATA and shall account for the need for training to be conducted and successfully completed prior to the start of any site testing for the applicable system.

b) Account for the constrained availability of WMATA personnel involved in the daily delivery of service, to participate in training.

c) Ensure that user training is performed as close to the start of site testing as is possible without deviating from other requirements of this Specification.

3.14.5 Test Schedule

Maintain a separate Test Schedule (CDRL T118) that indicates when the test will be conducted and where. Coordinate the test schedule with WMATA and to accommodate their schedule and facilitate witnessing by WMATA personnel. Submit the coordinated Test Schedule monthly providing at least one month notice of all tests.

3.15 Project Phasing and Technical Milestones

3.15.1 General

In development of the ROCC software, a comprehensive program and plan must be followed. Specific Implementation and Commissioning Stages will be implemented and a set of phases and processes must be followed as part of this program. This program must be planned to include the acceptance criteria for completing each Implementation and Commissioning Stages and within each stage the acceptance criteria for each phase and outputs of the phase.

The Contractor shall define all project phases as part of the Project Management Plan. The Contractor shall not proceed to work in a successor phase until approval from WMATA of the predecessor phase has been received. All required work outputs of a phase shall be completed and approved by WMATA prior to start of a formal milestone Technical Review.

The Contractor shall schedule a formal milestone Technical Review at the completion of each project work phase. The Technical Reviews shall represent milestones in the development, scheduled with sufficient time for Engineer review and approval cycles prior to beginning the next phase. The Contractor may begin work from successive phases early but it is at the Contractors risk.

3.15.2 Preliminary Design

The Contractor shall prepare and deliver a refinement of all prototypes (iteration 2), for the ROCC software. Each refinement of a prototype must clearly incorporate resolutions to WMATA issues raised in the prior submission as well as reflect agreements to design issues raised during the current design phase.

Page 37


The Contractor shall update and resubmit for Engineer approval all previously approved documentation that was modified as an outcome of architectural design activities. The Contractor shall deliver for Engineer approval the Functional Requirements Definition (FRD) (CDRL-T105), updated as a result of software and hardware architectural design activities. The Contractor shall document and deliver the preliminary version of the Programmer/System Administrator User Documentation. The Contractor shall deliver for Engineer approval the Preliminary Design Review (PDR) materials required, at the completion of all detailed design activities.

3.15.2.1 Software Architectural Design

The Contractor shall transform the software requirements for each SCI, documented in the SRS, into an architecture that describes its top-level structure and identifies the software components. The Contractor shall ensure that all requirements for the SCI are allocated to its software components and further refined to facilitate detailed design.

a) The Contractor shall document the overall architecture of SCIs within the Software Architectural Design Document (SADD) for each applicable ROCC software.

b) The Contractor shall document those SCIs that are identified as standard SCIs in the Standard Software Documentation for each applicable ROCC software.

The Contractor shall develop and document, for each applicable ROCC software, a top-level design for the database in a High Level Database Design Document (DBDD). The Contractor shall update the mapping of the software requirements defined during the Software Requirements Analysis Phase to the SADD and High Level DBDD in the FRD. The Contractor shall deliver software verification and validation results in an updated VVR for software architectural design phase activities.

Upon successful completion of reviews, audits, and inspections of the outputs of the Software Architectural Design Phase the Contractor shall prepare and deliver the materials required for Preliminary Design Review (PDR.)

The Contractor shall deliver for Engineer approval the Software Architecture Design Document (SADD) developed and documented during this phase. The Contractor shall deliver for Engineer approval the Standard Software Documentation (SSD). The Contractor shall deliver for Engineer approval the High Level Database Design Document (DBDD), developed and documented during this phase. The Contractor shall deliver the Software Configuration Items List, updated with breakdown of SCI to software components.

3.15.2.2 Hardware Preliminary Design

The Contractor shall:

a) Perform a complete and comprehensive preliminary design of the hardware and hardware installation starting with the hardware requirements identified during requirements analysis.

b) Identify all hardware necessary to fulfill the hardware requirements. c) deliver for Engineer approval

• Updated Hardware Specifications, including a preliminary set of all catalog cut sheets and all preliminary calculations.

• Updated Hardware Configuration Block Diagrams including updated system level drawings and all subsystem level drawings to the assembly level. Board level drawings are not required in this phase.

• Updated Hardware Installation Documents, including all cableways and cabling routings. • A preliminary Hardware Inventory. • Rack and Enclosure Assembly Drawings. • Preliminary Hardware Test Configuration Drawings. • Final Design

Page 38



a) Prepare and deliver the final refinement of all prototypes (iteration 3). This final refinement of each prototype must clearly incorporate resolutions to all WMATA issues raised against the prototype as well as reflect agreements to design issues raised during the current design phase.

b) Update and resubmit for Engineer approval, all previously approved ROCC software documentation that was modified as an outcome of detailed design activities.

c) Deliver the Functional Requirements Definition (FRD), updated as a result of detailed design activities.

d) Deliver the Final Design Review (FDR) at the completion of all detailed design activities.

3.15.3 Software Detailed Design


a) Develop a detailed design for each software component defined as part of the software architecture. b) Ensure that all software requirements are allocated from the software components to software units. c) Develop and document, as part of the SDDD, the detailed design for the interfaces external to the

software item, between the software components, and between the software units. The detailed design of the interfaces shall provide all information that is required to allow for complete coding of software.

d) Develop and document the detailed design of all databases in the Detailed DBDD. The Detailed DBDD shall be an update to the High Level DBDD produced during Software Architectural Design.

e) Update the mapping of the software requirements defined during the Software Requirements Analysis Phase to the Software Detailed Design Document (SDDD) and Detailed DBDD in the FRD.

f) Update the preliminary versions of the Programmer/System Administrator User Documentation created during Software Architectural Design into final versions.

g) Upon successful completion of reviews, audits, and inspections of the outputs of the Final Design Phase the Contractor shall prepare and deliver the materials required for Final Design Review.

h) Deliver the Software Detailed Design Document (SDDD) developed and documented during this phase.

i) Deliver the Standard Software Documentation (SSD), updated for software detailed design. j) Deliver the Final Detailed Database Design Document (DDBDD), developed and documented during

this phase. k) Deliver the Software Configuration Items (SCI) List, updated to include detailed software unit

identification for SCIs.

3.15.4 Hardware Detailed Design

Deliver the Final Design versions of all Hardware Specifications and installation documentation.

3.15.5 System Test Design

The Contractor shall document and submit:

a) FAT Test Procedures, b) Site Test Procedures, for each test including:

• Site Installation Test Procedures; • Site Performance Test Procedures; • Site Integrated System Test Procedures.

c) Availability and Reliability Test Procedures. d) Maintainability Demonstration Test Procedures. e) Transition Plan.

Page 39


3.16 Implementation

The Contractor shall submit for approval a System Implementation schedule and a Transition Plan (CDRL-T606). The system implementation schedule shall take into account the strict requirement that there are zero disruptions to revenue operation and any non-revenue disruption be minimal in frequency and duration. The Transition Plan shall identify all requirement which need to be completed prior to cutover as well as detail all items required to verify proper operation of the ROCC software

Prior to cutover, the Contractor shall resubmit all approved documentation that was modified as an outcome of implementation activities, submit a complete hardware inventory (with all hardware serial numbers), submit Test Readiness Review material, complete all training of essential personnel, and implement/populate each software database with ROCC software data.

3.17 Design Reviews

The Contractor shall conduct a series of formal design reviews. The Contractor’s personnel responsible for the development of the milestone shall participate in the milestone reviews.

The formal technical review process shall include:

a) Conceptual Design Review (CDR) (CDRL T151); b) System Requirements Review (SRR) (CDRL T152); c) Preliminary Design Review (PDR) (CDRL T153); d) Final Design Review (FDR) (CDRL T154); e) Test Readiness Review (TRR) (CDRL T155).

Following acceptance of the FDR, the Contractor shall implement the system, including hardware and software implementation and test. A Test Readiness Review (TRR) shall be conducted when the software and hardware development testing (i.e., unit, module, and integration testing) are 100% complete. Each milestone review shall consist of a formal presentation and discussion of the system design or implementation, including discussion relative to outputs of the associated development phase.

The presentation portions of the reviews shall be conducted by the Contractor at WMATA’s facilities and shall be scheduled after WMATA has had sufficient time to review the corresponding review materials, and each required document submittal has been approved or approved as marked.

a) Review agendas and presentation material shall be made available to WMATA for review and approval at least two (2) weeks prior to the presentation as part of the Milestone Review Package.

b) Milestone Reviews shall be rescheduled by the Contractor, two (2) weeks later, should the presentation material for a milestone review not meet the requirements of these Specifications.

Each formal review shall cover each subsystem, function, software and hardware component. Each succeeding level of formal technical review shall present an update of all material from the previous review (the CDR shall update the Contractor’s proposal), as well as progress the system design to the next level. Review and approval of a formal technical review or milestone review by WMATA shall not relieve the Contractor of its overall responsibilities to satisfy system functions and the documentation thereof in accordance with the Specification.

3.17.1 Conceptual Design Review (CDR)

The Conceptual Design Review (CDR) (CDRL-T151) shall present the work activities and outputs of the ConOps and Functional Requirements Definition (FRD.) For CDR, the Contractor shall present the design approach of each ROCC software and all major subsystems. The CDR shall address the overall control center space layout and design, total system requirements, system functional descriptions, interlocking rules description, software system overview and preliminary designs, computer architecture and computer system configuration, data communications and systems interfaces, and console layout.

Page 40


For the CDR include:

a) CDR agenda and presentation materials; b) A review of how the ConOps and FRD were developed, explain the process used and guiding

documents. c) Concept of Operations – ConOps d) Functional Requirements Definition – FRD e) The Systems Description Document (SysDD);

• A Functions List consisting of a complete master listing of all functions and capabilities of each ROCC software including all maintenance and diagnostics functions (in addition to operational functions);

• A brief description of each function and any special/unusual attributes or variances from Specification of the function shall be included;

• The Functions List shall be updated from the preliminary list provided in the Contractor’s proposal;

f) A review of major system interfaces including the interface contact and an analysis of future challenges;

g) Space requirements and control center layout plans showing equipment space requirements, address phasing needs;

h) Interlocking Rules Document, Executive Section; i) Display Conventions and Guidelines Document; j) Preliminary layouts and content of all ROCC software displays and reports;

• Displays and reports shall be provided both in hardcopy format and via the Contractor-provided display and report review workstation;

• The user interaction with each display shall be described;

k) Prototype Plan; l) Prototype Users Manual; m) Prototype documentation for the first iteration of all prototypes; n) Preliminary Hazard Analysis (PHA); o) System Response Timing Analysis, allocations to configuration items; p) Top-level Training Plan outline; q) Quality Assurance and Configuration Management Plans

3.17.2 System Requirements Review (SRR)

The System Requirements Review (SRR) (CDRL T152) shall present the work activities and outputs of the Requirements Analysis phase. The System Requirements Review shall include a review of all of the design activity to date.

The following outputs of the requirements analysis phase and additional documentation shall be provided for SRR as part of the SRR Milestone Review Package:

a) SRR agenda and presentation materials; b) Updated versions of CDR documentation; c) The Functional Requirements Definition (FRD) showing all requirements mapped to SRR level

documents; d) Software Requirements Specification ; e) Software Configuration Items List; f) Prototype Description Documents for the 2nd and 3rd iterations; g) Preliminary Hardware Specification; h) Preliminary Hardware Configuration Block Diagrams;

Page 41


i) Preliminary Hardware Installation Design; j) EMI/EMC Control Plan; k) Interlocking Rules Document, at least one site section; l) System Response Timing Analysis, allocations to components; m) ROCC software Transition Plan; n) Master Test Plan; o) FAT Test Plan; p) Site Installation Test Plan; q) Site Performance Test Plan; r) Site Integrated System Test Plan.

3.17.3 Preliminary Design Review (PDR)

a) The Preliminary Design Review (PDR) (CDRL T153) shall present the work activities and outputs of the Architectural Design phase. The Preliminary Design Review shall include a review of all of the design activity to date.

b) The following outputs of the architectural design phase and additional documentation shall be provided for PDR as part of the PDR Milestone Review Package:

c) PDR agenda and presentation materials; d) Updated versions of SRR and CDR documentation; e) An FRD showing all requirements mapped to the PDR level documents; f) Interlocking Rules Document, all site specific sections; g) Software Architectural Design Documents; h) High Level Database Design Documents; i) Firmware Document; j) Standard Software Documents; k) Updated Software Configuration Items List; l) Prototype documentation for second iteration of all prototypes; m) Human Factors Study Report; n) Detailed Training Plan, including schedules and resources; o) Preliminary Hardware Inventory; p) Hardware Rack and Enclosure Drawings; q) Hardware Test Configuration Drawings; r) Preliminary Hardware Implementation Plan; s) Subsystem and Operations Hazard Analyses; t) Fault Tree Analysis, Stage 1; u) Critical/Catastrophic Items List.

3.17.4 Final Design Review (FDR)

The Final Design Review (FDR) (CDRL T154) shall present the work activities and outputs of the Detailed Design phase. The following outputs of the detailed design phase and additional documentation shall be provided for FDR as part of the FDR Milestone Review Package:

a) FDR agenda and presentation materials; b) Updated versions of PDR, SRR and CDR documentation; c) An FRD showing all requirements mapped to the FDR level documents; d) Software Detailed Design Document; e) Hardware Inventory; f) Hardware Rack and Enclosure Drawings; g) Hardware Test Configuration Drawings;

Page 42


h) Hardware Implementation Plan; i) System Response Timing Analysis, allocations to hardware and software units; j) Detailed plans, procedures, requirements, and schedule for the installation and commissioning of each

ROCC software; k) System Test Procedure documents, showing scheduled tests, environments, and resources (quantity

and skill level) required for all testing: • FAT Test Procedures; • Site Installation Test Procedures; • Site Performance Test Procedures; • Site Integrated System Test Procedures

l) Copies of each ROCC software report and color copies of the complete set of ROCC software

displays; m) Prototype documentation for final iteration of all prototypes; n) Fault Tree Analysis, Stage 2.

3.17.5 Test Readiness Review (TRR)

The Test Readiness Review (TRR) (CDRL T155) shall present the work activities and outputs of the Implementation phase. The Test Readiness Review shall present the identification of all final hardware and software components and units identified in the final design and verification results. The following outputs of the Implementation phase and additional documentation shall be provided for TRR as part of the TRR Milestone Review Package:

a) TRR agenda and presentation materials; b) Updated versions of FDR, PDR, SRR, and CDR documentation; c) An FRD showing all requirements mapped to TRR level documents; d) Final software and database version control reports; e) VV results for all software testing; f) Copies of system database files; g) Copies of all system generation files, including data, scripts, configuration; h) Final Software Configuration Items List ; i) Final Hardware Inventory; j) Hardware Shop Drawings of all racks and assemblies k) Hardware Reference Manuals and Instruction Books; l) Maintenance Manuals; m) Diagnostic Program User’s Manual; n) Operator’s User Manual; o) Test results validating the proper assembly and operation of the hardware.

Page 43


FAT – at Contractors Factory

JGBEqpt.

CTFEqpt.

Traffic Simulator

Preliminary Test – at CTF

WMATANetwork

JGBEqpt.

CTFEqpt.

Preliminary Cut Over Test – between JGB and CTFUsing parallel connections to WMATA network

WMATANetwork

JGBEqpt.

CTFEqpt.

Local fibers

Local fibers

WMATA provided dark fiber

WMATANetwork

JGB LocationCTF Location

MAJOR TEST CONFIGURATIONS - CONCEPT

Page 44


3.18 Software Maintenance Agreement

The Contractor shall submit for approval a Software Maintenance Agreement (CDRL-XXX). This Software maintenance agreement shall start after system acceptance. This agreement shall be a Service Level Agreement, renewable annually for up to five years total. The agreement shall, at a minimum detail the following:

a) Detailed description of warranty and maintenance services proposed by Offeror b) Assurances that Offeror will meet warranty and maintenance requirements. c) Yearly Option for On Site Support d) Help Desk Support for COTS products e) Yearly Upgrades of the COTS products f) Test & Installation of Operating System patches g) Test & Installation of Virus Protection h) WMATA anticipates procuring annual maintenance contracts guaranteeing a specified performance

level through a Service Level Agreement (SLA.) The maintenance contract will require an on-site maintenance technician for every normal WMATA working day (Include a list of WMATA holidays?). WMATA will provide space at CTF and the use of the local development lab. The SLA will specify: • System availability of 99.999% MINIMUM. Defined as the software system, primary and back

up, are available to dispatch trains and perform other core duties at all stations. Each failure exceeding this limit will result in a 5% reduction of contract value for each event.

• Mean Time to Repair of any system fault shall be under 24 hours. This will be assessed at the end of the yearly cycle. Failure to meet this requirement will result in a contract reduction of 5% for every additional 6-hours.

• Mean Time to Recovery of either the CTF or JGB shall be under 24 hours. This will be assessed after each event that causes a system to become unavailable. Failure to meet this requirement will result in a contract reduction of 5% for every additional 6-hours.

• Offeror’s may present alternative solutions for consideration but need to propose on the above base requirement.

Page 45


4. General Software Requirements

4.1 System Architecture

The Contractor shall submit for approval to WMATA the architecture of the proposed software and hardware. The architecture shall be developed using an architectural model tool such as Rational. The architecture submittal shall provide a top down view of the ROCC software and detail the hardware installation, operating systems, data paths, connectivity and other technical aspects of the software package. The Contractor shall keep this documentation up to date throughout the project. At the conclusion of the project, Contractor will transfer the graphical portrayal System/database and all software-related licenses to WMATA. See attached drawing package for the existing connectivity and interfaces as well as the new conceptual System Architecture. (CDRL-T114)

Proposal Requirement: The Proposer shall provide in his technical proposal detailed information about the general software functionality. Include shall be a system architecture, IO limitations, existing software interfaces, security provisions, fail over switching, and other information required to evaluate the basic software functionality.

4.2 Data Acquisition

The ROCC software shall communicate with both other software applications and with field devices. Communications to field devices shall be bidirectional and shall include both the input and output (I/O) of real world data. The I/O handling for real-time interfaces is described in this section. The physical interface requirements and message protocols for all real-time and non-real-time interfaces are described elsewhere in the Contract Documents.

As a minimum, the ROCC software shall provide supervisory monitoring and control of train control, train performance, traction power, station power, ventilation fans, drainage pumps, and fire intrusion alarms over all of WMATA revenue territory and many important parts of WMATA non-revenue territory.

The term “telemetry” is used in the global sense within these Specifications to refer to all real-time or real world data that is acquired remotely through interfaces to systems external to the ROCC software. Thus, all real-time data from the external system interfaces as well as the groups listed herein are considered telemetered data.

Proposal Requirement: The Proposer shall provide in his technical proposal detailed information about the Data Collection ability of the software.

4.2.1 Data Sources

The Contractor shall supply and configure software that communicates to existing and future Field Devices. Furthermore, the Contractor shall support the gradual transition of existing field devices to the next generation of field devices. This transition from an existing situation to a future situation may happen one individual location at a time. The Contractor must support and integrate this future WMATA work. The ability to do this is a key technical evaluation factor.

The ROCC software shall communicate with and acquire real-time data from Field Control Units (FCUs), Horton RTUs, MERCS and the future units (such as Genisys) located throughout the WMATA rail system. WMATA currently uses the following protocols; S9600, Modbus, DNP3 and will be adding Genisys in the near future.

Currently OCC does not use Genisys for supervisory communications. WMATA uses S9600 protocol to TRW S9600 RTU’s and compatibles (including Ferranti and Horton) located in train control rooms. Dulles Phase 1 (Silver Line) shall require communications with Modbus and DNP3 protocols. The ROCC software shall supply native support for all industry standard train control supervision protocols including Genisys and Datatran.

During this Contract, WMATA will be upgrading the existing locations to new standard protocols. The Contractor shall work with WMATA with this migration and provide procedures and methods for the continual migration from the existing Ferranti and Horton RTUs to the new standard protocols (I.E. Genisys and

Page 46


Datatran). The method of transitioning between protocols should not require the entire OCC Software to be shut down and restarted.

The ROCC software shall contain an interface application to communicate with and acquire real-time data from WMATA’s Power Supervisory Control and Data Acquisition (SCADA) CG Automation RTU which is located in the WMATA TPSS, TBS and AC room facilities. The ROCC software shall contain an interface to communicate with and acquire real-time data from existing field devices:

a) These remote monitoring components are simultaneously monitored and controlled by the CG Automation Automated Energy Management System (AEMS).

b) The CG Automation RTUs has separate communications channels for Operations and Maintenance data. The communications protocol for both channels is DNP3.

a)

4.2.1.1 Integration with the WMATA Master Time Source

The ROCC software shall communicate with and acquire real-time time data from the WMATA Master Time Source. Regardless of the source, all data collected by the ROCC software shall be subject to the requirements contained in these Specifications:

b) The ROCC software shall asynchronously acquire identical data from all data sources over WMATA Ethernet networks for all real-time redundant interfaces (i.e., up to two sets of data from each source (Normal and Standby) for field units that have such redundancy; each field unit shall communicate [redundantly where so equipped] over redundant WMATA networks to two office locations, the CTF and the JGB.) No failure on any one data feed or network shall cause a failure on any other WMATA network or system.

c) The ROCC software shall continuously monitor the health and integrity of the data communication. d) The ROCC software shall ensure that data from only the primary designated data source is used as

operational data. e) The ROCC software shall ensure that only acquired data received from a data source that is

functioning properly is used as operational data.

4.2.1.2 Real-Time Data Source Initialization

Upon start-up of the ROCC software, the ROCC software shall scan all data sources for an image of the current states of the data stored by the data source:

a) The ROCC software shall display all field FCU data associated with a data source as not available until the initialization scan has been successfully completed.

b) The ROCC software shall display a flashing alarm when the communications between the field FCU and the Office are not operational.

c) The ROCC software shall log an alarm when the communications between the field FCU and the Office are not operational.

The ROCC software shall display a flashing alarm when the communication between the individual points and the office are not operational (communication to individual points are available with the WMATA newly-upgraded power SCADA systems). During interface initialization, the ROCC software shall request a full data dump to receive the health and status from each data source. The ROCC software shall select as primary, the data source defined as primary in the ROCC software database as default during interface initialization, when all data sources are operational.

Page 47


4.2.1.3 Designation of Primary Devices

The ROCC software shall automatically switch over to the available backup data source in the redundant communications system when communication with the primary data source has failed. The ROCC software shall select the operational backup data source if the source is available and indicated as the default interface in the initialization in the ROCC software database, when all data sources are operational.

Capability shall be provided for Authorized Users to transfer on-demand primary status from the current primary data source to a specified operational backup data source. After primary and backup data sources swap roles, the former primary data source shall become the new backup data source.

The ROCC software shall provide the capability for Authorized Users to designate data sources as off-line or down. Attempts to manually transfer a primary data source to another state that would result in loss of data source communication (i.e., no available backup) shall not be allowed and a user guidance message shall be displayed.

The ROCC software shall provide user adjustable scheduling of automatic transfer of designated primary and backup data sources. The ROCC software shall notify Authorized Users of all automatic failovers to data sources. All automatic failovers to redundant data sources shall be logged.

4.2.2 Front End Processors (FEP)

The ROCC software FEPs shall receive data from all real time field data devices. Currently, these are the Horton RTUs, CG Automation RTU, MERCS devices, and the legacy S9600 through MERCS. Genisys units will be included and tested during this project:

a) The ROCC software shall monitor each field device as is currently programmed. b) The ROCC software FEP shall trigger an alarm if any of the field devices fail to send the office a

health status within a configuration-specified time.

All Front End Processors shall be sized to accommodate a minimum of 50% future expansion.

4.2.2.1 Status Input Processing

The ROCC software shall monitor the states of telemetered status points for all changes of state of ROCC software controllable devices. The ROCC software shall monitor the states of telemetered status points and check for predefined alarm conditions and uncommanded changes of state of ROCC software controllable devices:

a) Alarm conditions shall include incomplete, invalid, unreasonable, or out of sequence data, and incomplete, invalid, or failed communications.

b) All detected alarm conditions and uncommanded changes of state shall be reported by visual and audible means based on the severity of the alarm condition.

The ROCC software shall perform all data translation for specific telemetered status points, as defined in the ROCC software database:

a) The ROCC software shall include the capability to convert the state of the status input point to the opposite state (Inversion) prior to storing the point in the database.

b) Points for which the states of two status inputs are combined into three legal states (for example: switch normal, reverse, or out-of-correspondence) and one illegal state (switch normal and reverse) shall be translated by the ROCC software.

Page 48


4.2.2.2 Periodic Calculations

The ROCC software shall have the ability to execute periodic calculations, as required, defined in the ROCC software database. The ROCC software shall provide the capability to define periodic calculation algorithms that utilize database values, constant variables, and arithmetic and logical operations.

4.2.2.3 Control and Status Updating

In addition to the ROCC software receiving indication and status data from the disparate native-protocol field devices, the ROCC software also transmits control data and status information to the field devices. Control and status updates are triggered by the ROCC software function generating the control or modifying the state of the associated data points.

Except where control transmission delay is required for a control sequence (e.g., N/X route exit selection waiting for available exit indication from the field), real-time ROCC software status and control data shall be transmitted without delay (subject to functional requirements), to all field devices at the time the control is set or status change occurs within the ROCC software.

The ROCC software shall format and transmit all status data to the field devices according to the native protocol of each device:

a) Where required by data transmission protocol, the ROCC software shall perform all necessary handshaking or acknowledgement as part of the message transmission.

b) When transmitting data to redundant field data sources, identical data shall be transmitted over both networks to all active data sources and clients.

c) Answer-back shall be provided for all control operations. d) The maximum delay time from an office input (switch throw and / or signal request) to time of

field implementation of that request and indication displayed both locally and at the control center shall not exceed eight (8) seconds.

4.2.2.4 Field Device Inhibit and Restore

This feature shall provide the ability to remove a failed field device from receiving and sending status and controls based upon user-configurable option. Authorized Users shall have the capability to ignore or process an individual field device status or control from the ROCC software based upon user-configurable option. Authorized Users shall have the capability to mark individual or multiple telemetered or status points inhibiting or restoring the field processing. Individual points or combinations of points modified with this feature shall be alarmed.

4.2.2.5 Data Source Restoration

Interface devices or communication links that have failed shall be capable of being either automatically restored to service or shall be manually reinstated dependent on the setup configuration for each communications link to the field device:

a) The ROCC software shall reinstate a failed data source either automatically or manually dependent on the configuration in the ROCC software database.

b) Capability shall be provided for Authorized Users to be able to configure each data source individually for either manual or automatic restoration mode.

c) Upon reinstatement, any interface initialization required for the specific data source shall be performed.

d) In the automatic restoration mode, the ROCC software shall periodically check to see if communications can be restored.

e) The periodic checking of an out-of-service data source shall be performed by the ROCC software at an Authorized User adjustable rate (default rate of every 30 seconds, 1 second resolution).

Page 49


f) The automatic restoration mode shall be the default mode of operation. g) The ROCC software shall place a data source back in service when communications are possible when

detected in automatic restoration mode. h) An event message shall be issued whenever a data source is restored to service. i) The restore event message shall identify the data source that was restored to service and the time of

restoration. j) If a device continues to fail, an Authorized User shall have the ability to set the restoration to manual

restoration mode.

4.2.3 Run-Time Database

The ROCC software Database shall be a run-time database that will include all operational data and databases necessary to support the operation of the ROCC software. The pertinent content from the run-time database shall be loaded into memory-resident ROCC software structures during system operation to ensure acceptable performance. Changes or additions to the run-time database shall not require that the ROCC software be shut down or restarted in order for changes to take effect in the on-line production ROCC software environment when such changes are loaded into memory-resident ROCC software structures.

The ROCC software shall establish and maintain the run-time database, which describes the real-time state of the ROCC software. The run-time database shall consist of all telemetered status points, including FCUs, SCADA, and WMATA Master Time Source; status update data sent to interfaced systems; calculated data point values, including all intermediate data; manually entered data; and the quality codes, tags, and other flags applicable to each point. The run-time database shall also include, for each point, the alphanumeric point identification, alarm states or limits, alarm priorities, functional partitioning, static system data, and all other data required to meet the functional requirements of these Specifications. The Contractor shall implement the run-time database as part of the ROCC software Database.

The ROCC software Run-Time Database shall be expandable in accordance with the expandability requirements in this Specification. Expanding the ROCC software Run-Time Database shall not require reprogramming and recompilation of any program. The ROCC software Run-Time Database shall be sized to accommodate a minimum of 50% future expansion.

4.2.4 Data Processing User Interface

Deletion from, and restoration to scan for data sources, individual points, or combinations of points, shall be provided from all ROCC software displays that include the data source or points. Where multiple devices exist of a type, Authorized Users shall be able to select one specific device or combination of devices to delete from or to restore to scan without affecting the other devices of that type. As an example, a user may select one specific FCU to delete from scan without affecting the scan status of any other FCU:

a) When a data source or data point is deleted from scan processing, the data source or data point shall be distinctively displayed as out-of-scan on all displays in which the data source or point appear.

b) When a data source is taken out-of-scan and displayed as such, all individual data points associated with the data source shall also be displayed as out-of-scan.

c) All displays shall be subject to prototyping.

4.2.4.1 Device Status Entry

Authorized Users shall have the capability to manually enter data values for data points where the telemetry failure quality indicator is set, on any ROCC display that includes the data point. Authorized Users shall have the capability to manually enter data values for data points where the quality code indicator for out-of-scan is set, on any ROCC software display that includes the data point.

Page 50


Upon manual entry of data point data, the quality code for the data point shall be marked as manually entered on all displays and reports containing the value. Manual data entry shall be inhibited for selected device types, configurable by Authorized Users, subject to prototyping.

4.2.5 Data Processing Failure Handling

The ROCC software shall perform corrective actions when device or communication failures are detected in order to recover from error and failure conditions:

a) The ROCC software shall alarm unrecoverable data source device or communication failures. b) The ROCC software shall alarm whenever a device or communication link failover occurs.

If a data source device or communication fails or a data source fails to respond to a control request or timeout occur, all individual points of the data source shall be marked in the database with a data transmission failure quality code.

Calculated variables that are dependent on telemetered data that are missing due to transmission failures or detected errors in input processing shall be flagged and logged as “telemetry failure” in the ROCC software database until the error condition clears:

a) The ROCC software shall ensure that stale data (i.e., old data that has not been updated) from a failed data source is not used as operational data. In the event that the system detects a failed device or is unable to communicate to a device in the filed the indications and controls shall be changed to a cyan color. This feature will be subjected to prototyping.

b) The ROCC software shall alarm whenever there is a control that has been requested and the corresponding indication state for that control is not received from the field within a specified time.

c) The alarm shall cause a popup to be displayed informing the Authorized User that the request has timed out.

In the event of a major failure at the ROCC, the ROCC software shall have the capability to be monitored and controlled from JGB.

4.3 Information Storage and Retrieval

4.3.1 Historical Data Collection

The ROCC software shall collect and store Historical Data on all ROCC software operations and provides facilities for this data to be retrieved, queried, played back, added to reports, displayed, and printed. The stored data shall be date and time stamped and contains sufficient information to efficiently access the data.

All ROCC software data whether received from external sources, generated from Authorized User actions, calculated by the ROCC software, or in any other way processed by the ROCC software shall be logged and stored as Historical Data.

The complete set of data to be logged and archived as Historical Data shall be determined subject to prototyping and as directed by WMATA. The complete set of data to be logged and archived as Historical Data shall be documented in the Software Requirements Specification (CDRL T308). All logged Historical Data shall be date and time stamped with the time of the event occurrence (not the time that it was logged).

The ROCC software Historical Data function shall timestamp all data to minimally a one millisecond resolution. The ROCC software shall log all data that is necessary to produce all ROCC Reports as defined elsewhere in the Contract Documents. The ROCC software shall log any ad-hoc reports that have been requested to be saved by Authorized Users.

All Authorized Users interactions that result in an ROCC software action, state change, or other response (e.g., open a display, issue a control, generate a report, perform a calculation, data entry, generate an alarm) shall be

Page 51


logged as Historical Data. Individual cursor positioning or keyboard operations that do not result in a system event need not be logged.

The ROCC software shall log the initial entry of data on a form and all subsequent changes to data items that are presented on forms. The following shall be logged for each new/modified data item:

a) Date/time data was entered/modified; b) Name/pass number of person entering/modifying the data; c) Department/section of person entering/modifying the data; d) Field name and content of field before modification; e) Field name and content of field after modification.

The ROCC software shall log requests by Authorized Users to generate a Pre-Defined Report:

a) The ROCC software shall provide the ability for Pre-Defined Reports to be named and saved for repeated execution by an Authorized User at a later date.

b) The ROCC software shall log the requester’s name/pass number, Report name and date/time of the request.

All changes of User-adjustable parameters made by Authorized Users shall be logged as Historical Data. All data entered by Authorized Users shall be logged as Historical Data. Authorized User data is considered entered upon completion of the data entry by the user (i.e., after entering data the user selects an ‘OK’ button, after entering data the user moves the cursor to another field or object on the display). All data calculated by the ROCC software, regardless of the reason or the function for which it was calculated shall be logged as Historical Data. All data transmitted to or received from any system interfaced to the ROCC software shall be logged as Historical Data. All data received from any system interfaced to the ROCC software, including data which is received from backup redundant devices shall be logged as Historical Data. Logging shall be performed at the time the data is acquired, regardless whether the data is to be processed by the ROCC software (i.e., data points or device data out of scan).

All failure conditions detected by any function of the ROCC software, whether or not a threshold for the failure resulted in a system alarm, shall be collected and archived. Sufficient data shall be logged to determine the exact failure condition at the time of detection, subject to approval of WMATA:

a) The ROCC software shall log separately events where a failure or alarm threshold has been reached or exceeded, including identification of the condition or data failed, the threshold limit, and the value that exceeded the threshold.

b) The complete set of failures and alarms to be logged and archived as Historical Data shall be documented in the Software Requirements Specification (CDRL T308).

c) The Contractor shall define all Historical Data items to be identified, collected, and logged by the ROCC software, as part of the Software Requirements Specification (CDRL T308).

d) The Contractor shall further refine the complete set of Historical Data items, along with details of the logging of each, within the Software Architecture Design Document (CDRL T309).

4.3.1.1 Configuration Data Collection

Historical Data shall be used to recreate system conditions and behaviors at a later time. For example, periodic snapshots of the system configuration (e.g. a snapshot of the database and/or flat files) may be necessary so that playback can be initialized from the snapshot and proceed forward. Historical Data will be accessible for any time period (e.g. for a variable or group of variables, which may or may not exist in the existing WMATA ROCC system). The design shall be such that stored data is not affected by changes to the database or regeneration of the ROCC software configuration. For example, stored data may be retrieved and analyzed provided the appropriate database and system configuration associated with that Historical Data is also restored. Authorized Users shall be able to recreate incidents and conditions for playback purposes, and/or to use during execution of a simulation scenario.

Page 52


The ROCC software shall log all configuration and operational data that is required to re-recreate a past time-period to enable access to Historical Data (for simulation and/or playback purposes), including but not limited to:

a) System configuration files; b) System Databases and Database definitions; c) Graphical display layouts; d) Pre-Defined Forms; e) Pre-Defined Report templates; f) Authorized User stored Pre-Defined Report templates and forms; g) System parameters; h) Version information for all databases, applications, drivers, software products, or other component

necessary to enable access to Historical Data at a later time; i) System initialization data; j) Manually adjusted or entered data; k) System startup files; l) All other data determined during prototyping and development.

The ROCC software shall log the version number and date of installation for each of the following:

a) ROCC Database version(s); b) Software release version(s), including all COTS and non-COTS components; c) Graphical display layouts; d) Pre-Defined Forms; e) Pre-Defined Report templates; f) COTS releases/version and installed patches.

Logged and archived Historical Data shall be stored such that it is unalterable and in no way affected by subsequent system events, database changes, failovers, User actions, system failures, or regeneration of the ROCC software.

Previously logged and archived Historical Data shall be protected such that modification of said data is not possible. The complete set of configuration data to be logged shall be subject to prototyping and Engineer approval. The ROCC software shall provide Authorized Users the capability to export all Historical Data into business applications provided with the System, such as Microsoft Word, Excel and Access. Data associated with any chosen Pre-Defined or ad-hoc Report shall be capable of being exported into such business applications together as an exported Report.

4.3.1.2 Administration/Management Data Collection

All logon/logout actions performed at a ROCC Workstation shall be logged, including console name/number, user name/pass number entered, date/time of logon/logout, access rights assigned/designed, and other information pertinent to the action undertaken. All failed logon or log-off attempts, either user authentication failures or suspected illegal access attempts, shall be logged with sufficient data relative to the failed attempt:

a) Logging of failed logon/log-off attempts, including suspected illegal access attempts, shall include the date, time, and location of the illegal access attempt, the user name under which illegal access was attempted, and the number of consecutive attempts at the same location.

b) All territory and function assignments, including temporary and permanent reassignments shall be collected and logged.

c) The complete set of Administration/Management data to be logged shall be subject to prototyping and Engineer approval.

d) All Administration/Management data to be logged and archived as Historical Data shall be documented in the Software Requirements Specification (CDRL T308).

Page 53


4.3.1.3 Device State Data Collection

The ROCC software shall automatically store as part of the Historical Data, at one minute intervals, status information or snapshots of the complete system states and operational data, including all data necessary to support future playback initiation from any selected date and time (at a one minute resolution) without noticeable delays in playback function response:

a) The ROCC software shall log each change of state for each ROCC software monitored device (e.g. switch reverse, signal clear).

b) The ROCC software shall log each Authorized User-requested control action for each controllable device (e.g. request signal clear, request switch normal).

c) All processor and device state changes (e.g. on-line primary, on-line backup, off-line/down) shall be logged.

d) All changes to the operational state (e.g. failed, out-of-scan) of ROCC software processors and devices shall be logged.

e) The ROCC software shall log and store all detected data source device and communication failures.

All detected device or communication errors and returns to normal shall be logged and stored for subsequent analysis; however repetitively identical errors in subsequent scans shall not be logged. Logging of processor or device state changes shall minimally include the following:

a) State prior to the change of state; b) State after the change of state: c) The associated device identifier/name; d) The device location; e) Date/timestamp of state change; f) Method of the state change (i.e. user-initiated, automatic routing).

The complete set of data to be logged for each processor or device state change shall be subject to prototyping and Engineer approval. All data for each processor or device state change to be logged and archived as Historical Data shall be documented in the Software Requirements Specification (CDRL T308).

4.3.1.4 Alarms Data Collection

All alarm conditions detected in the ROCC software shall be logged. Each occurrence of an alarm condition and return-to-normal condition shall be logged, including but not limited to:

a) Assigned alarm priority; b) Alarm message(s) generated (text in alarm summary lists); c) Users/Workstation(s) receiving the alarm; d) Time alarm condition was detected.

All Authorized User alarm processing interactions shall be logged including: a) System alarm inhibit/uninhibited state change;

• Identity of Authorized User initiating the change; b) Local alarm inhibit/uninhibited state change;

• Identity of Authorized User initiating the change; • Alarm condition(s) selected for change;

c) Deletion of alarm; • Identity of Authorized User performing the deletion; • Alarm(s) deleted; • Method of deletion (i.e., Alarm Summary List selection, Track Diagram);

d) Alarm acknowledgement; • Identity of Authorized User performing the acknowledgement; • Alarm(s) acknowledged; • Method of selection (i.e., Alarm Summary List selection, Track Diagram);

e) Alarm silencing/audible restoration; • Identify of Authorized User performing the change.

Page 54


The complete set of data to be logged for each alarm shall be subject to prototyping and Engineer approval. All data for each alarm to be logged and archived as Historical Data shall be documented in the Software Requirements Specification (CDRL T308).

4.3.1.5 Schedule Data Collection

The ROCC software shall log all validated Schedule files. The ROCC software shall log the complete Schedule, upon initial generation and then for all modifications whether made by Authorized Users or as a result of ROCC software processing.

The ROCC software shall log for each schedule, all attributes defined as part of the schedule database and maintained by the ROCC software. This shall include but not be limited to, schedule arrival and departure times in the planned schedule at every station location, adjusted scheduled arrival and departure times (including all adjustments and modifications, such as flexes or adding running time) at every station location.

The complete set of data to be logged for Schedules shall be subject to prototyping and Engineer approval. All data for each Schedule to be logged and archived as Historical Data shall be documented in the Software Requirements Specification (CDRL T308).

4.3.1.6 Operational Data Collection

The ROCC software shall log all operational and Run-Time Database data modifications, including the following as a minimum:

a) Source and/or destination location of data; b) Old data value, if applicable; c) New data value, if applicable; d) Quality code change, if applicable; e) Identity of entity making the change (i.e., Authorized User ID, function or process ID); f) Date/Time of change.

The operational data logged shall include all data received from or sent to field Train Control devices. Where redundant devices are interfaced, the ROCC software shall log all data received for each device separately.

The operational data logged shall include all data received from or sent to SCADA system(s). Where redundant interfaces exist, the ROCC software shall log all data received from each separately.

The operational data logged shall include all Train Records created, modified, or closed in the ROCC software. The complete set of data elements of each Train Record shall be logged regardless of the modification made to the Train Record.

The operational data logged shall include all Blocking controls and data created, modified, or closed in the ROCC software. The complete set of data elements maintained for each form shall be logged regardless of the modification made to the form:

a) The operational data logged shall include all control actions. b) The operational data logged shall include all Database generation and modification. c) The operational data logged shall include all modifications to the Topographical Database.

The operational data logged shall include all data calculated, generated, or manually entered for generation or population of any ROCC Report, regardless of whether the data is processed into a Report (i.e., the Report or related query/filter was run).

The operational data logged shall include all data calculated, generated, or manually entered for generation or population of any ROCC Display, regardless of whether the data is processed into a Display (i.e., the Display or Form was opened on any RROCC Workstation).

The complete set of operational data to be logged shall be subject to prototyping and Engineer approval. All operational data to be logged and archived as Historical Data shall be documented in the Software Requirements Specification (CDRL T308).

Page 55


4.3.1.7 Data Storage and Archiving

System data, Historical data and reports shall be logged to redundant Historical Data servers connected to the ROCC software Application Servers. ROCC software shall retain all logged Historical Data collected for the most recent 180-day period online. The Online data format utilized should be best suited to immediate access during playback. Logged online data that is older than 180-days shall be automatically transferred to a WMATA-provided ROCC software Archive Server and stored for at least two (2) years. The ROCC software shall not delete any Historical Data from online Historical Data servers unless it has been successfully transferred to the ROCC software Archive Server. The ROCC software shall provide the capability for Authorized Users to initiate on-demand transfers of the currently logged online Historical Data and ROCC Reports to ROCC software Archive Server and removable media devices. The ROCC Information Storage and Retrieval function shall automatically adjust for 23 and 25 hour days to accommodate the changeover to and from daylight saving time, as well as Leap Year. Date and time stamps of online and offline Historical Data shall maintain synchronization with the ROCC software time at all times. All online and archived Historical Data shall be accessible from any time period regardless of the ROCC software changes made after storage of that data (e.g., it shall be possible to retrieve stored data for a variable which no longer exists in the ROCC software).

All data collected or archived as part of the Information Storage and Retrieval function, whether available on-line or in the archive system, shall be retrievable for Authorized User viewing, playback, simulation, or reporting purposes as specified in this Specification. The ROCC Information Storage and Retrieval function shall ensure that archived data is not modifiable or able to be deleted.

4.3.2 Information Retrieval User Interface

All data captured by the ROCC software and stored in either short-term or long-term storage shall be displayable on Historical Data Review Displays:

a) The Historical Data Review Displays shall allow selective retrieval and review of the data collected by Authorized Users.

b) The Historical Data Review Displays shall contain headings, which define the time period of the historical data.

c) The ROCC software shall automatically determine if requested data is available off-line (not available online) and will provide sufficient information to the user for retrieving the data for access by ROCC software.

d) The Authorized User shall have the capability to select the historical data to be displayed by specifying the date and time period, ROCC software Workstation and User, event type, device, and other criteria. All historical retrieval criteria shall be approved as part of prototyping.

e) Authorized Users shall have the capability to request hardcopy output of retrieved historical data. f) All historical data displayed and printed shall be presented in a decoded format. The user shall not be

required to decode unformatted messages in order to determine the meaning of the displayed data. g) The Information Storage and Retrieval function shall provide the displays necessary for System

Administration management and configuration control for historical logging and archiving Historical Data.

h) Capability shall be provided for Authorized Users to generate reports on ROCC software archived data.

i) The Historical Data Review Displays shall provide Authorized Users the capability to export Report data into business applications provided with the System, such as Microsoft Word, Excel and Access.

j) All Historical Data Review Displays shall be determined subject to prototyping and as directed by WMATA.

Page 56


4.3.3 Information Storage and Retrieval Failure Handling

The ROCC software shall continuously monitor for failure conditions of the archive storage devices and provide notification to the System Administrator upon detection. The ROCC software shall notify the System Administrator when the archive system requires media replacement, when the current remaining archive capacity reaches a System Administrator threshold. This threshold shall be defined as both percentage full and estimated time before full.

4.4 Playback

The ROCC software includes a Historical Data Playback capability, which enables Authorized Users to selectively retrieve Historical Data from either online (short-term) or off-line (long-term) historical archive storage and to Playback the historical system conditions via ROCC software displays and devices.

For the purposes of this section, the term Playback Control Displays is used to denote any displays that allow an Authorized User to initiate, execute, control or terminate a Playback session. ROCC Playback Displays are those displays that are invoked during a Playback session and are populated with Playback data during the Playback session.

4.4.1 Playback Functionality

Any ROCC Playback Displays invoked during a Playback session, including Playback Control Displays, shall be distinguishable from those displays presented during actual operations, so that an operator cannot mistake Playback operation from real-time operation.

The Playback function shall recreate the ROCC software states and conditions, and their corresponding displays, which were present during the selected Playback time period. The Playback function shall display and populate any ROCC Display as is used for actual operations, except that a clear, distinguishing attribute (e.g. such as a combination of text with a uniquely colored border) shall be included on every display to distinguish displays presented during Playback from those presented during actual operations. The visual attributes for distinguishing ROCC Playback Displays during playback shall be subject to prototyping:

a) During Playback, Authorized Users shall have the capability to stop or pause the Playback session and request a hardcopy output of any graphical or text-based display that is part of the Playback session.

b) The printed ROCC Playback Displays shall contain all static objects, dynamic objects, and object states including train icon locations displayed at the time of the print request. • The printed ROCC Playback Displays shall include the content of all open text-based display(s) at

the time of the print request. • The method of representing all objects states and attributes in printed output of ROCC Playback

Display output shall be subject to prototyping. • All printed or hardcopy output of ROCC Playback Displays shall contain a border that clearly

identifies that the output was generated from a Playback session and shall include: c) The date and time of Playback initiation of the printout; d) The date and time period of live operations that is represented in the printed output of the ROCC

Playback Display. Authorized Users shall not be required to logoff their RROCC Workstation or perform a separate log-on to initiate a Playback session. Entry into the Playback function shall be intuitive and seamless. Cumbersome ‘loading’ and ‘unloading’ of files shall not be necessary. The method for entering and exiting Playback shall be subject to prototyping. The ROCC software shall prevent alteration of real-time or existing Historical Data by the Playback execution or Authorized Users.

Page 57


4.4.2 Integration of Playback with Radio Communication

/* BID OPTION */ As a separate bid option not to be included in the Contractor’s base bid, the Contractor shall propose how, or if, the ROCC software will incorporate stored WMATA radio into the Playback function:

a) WMATA wishes for historical radio feeds to be synched with the ROCC software displays and interactions from the chosen time period for replay during playback.

b) Third party software currently being used at WMATA is from NICE Systems, but the Contractor shall be aware that WMATA changes audio software often and that multiple video/audio products are likely to be used during the expected life cycle of the ROCC software.

c) The cost to WMATA for such integrated audio functionality shall be presented as an option and not included in the Contractor’s base ROCC software bid price.

d) Reference – Selection Process for additional information concerning how the Contractor should present bid options in their proposal and bid.

e) The Playback function shall provide the capability to execute from any RROCC Workstation.

4.4.3 Integration of Playback with CCTV Video Management System

/* BID OPTION */ As a separate bid option not to be included in the Contractor’s base bid, the Contractor shall propose how, or if, the ROCC software will incorporate stored WMATA CCTV Video into the Playback function:

f) WMATA wishes for historical CCTV video images to be synched with the ROCC software displays and interactions from the chosen time period for replay during playback.

g) Third party software currently being used at WMATA is from CNL. h) The cost to WMATA for such integrated video functionality shall be presented as an option and not

included in the Contractor’s base ROCC software bid price. i) Reference – Selection Process for additional information concerning how the Contractor should

present bid options in their proposal and bid. j) The Playback function shall provide the capability to execute from any RROCC Workstation.

4.4.4 Playback Session Data Retrieval

The ROCC software shall retrieve the Playback data that matches the selected date and time period, through the Information Storage and Retrieval Database Tracking System.

a) The maximum time period for a single Playback data retrieval shall be configurable by an Authorized User.

b) The Playback data retrieved shall include the appropriate versions of system databases, software versions, and control data to form a complete and accurate version of the ROCC software for the requested Playback time period.

c) ROCC Playback shall automatically determine if the data files required for the Playback session are available for online access and shall notify the user of any data that must be loaded from external media.

d) Authorized Users shall be able to specify that retrieved data be stored onto an archival medium.

4.4.5 Playback Execution

Authorized Users shall only have the capability to execute a Playback session after satisfying the following conditions:

a) The requesting Authorized User must have no control responsibility for any rail territory (territories must be reassigned to an active workstation);

b) The requesting Authorized User must have no function access rights for control that are not currently assigned to another logged on Authorized User;

c) All pending controls initiated by the Authorized User must be completed. The ROCC software shall notify the requesting Authorized User that all control functions shall be unavailable during the Playback session and require confirmation from the user prior to initiating the Playback session. The

Page 58


ROCC software shall not provide the capability for an Authorized User participating in a Playback session to perform any on-line functions:

a) The Playback function shall not issue any control commands nor modify the state of the ROCC software during a Playback session.

b) The Playback session shall begin processing of the Historical Data at the specified start date and time represented by the Historical Data, to within a one-minute accuracy, without having to playback time periods prior to the start time or begin processing at a time period after the specified start date and time.

During Playback any ROCC software displays opened as ROCC Playback Displays by Authorized Users during a Playback session shall be automatically populated and dynamically updated with Playback-generated outputs. In the absence of Authorized User Playback filter criteria, the ROCC software shall default to Playback and display of all Playback data.

The Playback function shall process all Authorized User control requests including fast forward, start, stop, pause, and resume the Playback session:

a) While a Playback session is in pause mode, the Playback processing shall suspend until the Authorized User requests that the session resumes, restarts or the stops. When a paused Playback session resumes, processing shall continue at the point at which the Playback was paused without any loss of or skipping of data.

b) While a Playback session is in pause mode, no updates shall be made to the OCC Playback Displays. The time displayed, representing the period being processed, on the ROCC Playback Displays and Playback Control Displays shall not increment while a Playback session is paused, and no user interactions with the Playback system shall be allowed except for Playback controls. While Playback is in pause mode, Authorized Users shall have the capability to issue Playback control commands (i.e. start, stop, resume):

a) The ROCC software shall provide a virtually infinite variable selection of Playback speeds not to be

limited by only a few selected pre-set speeds. b) The Playback processing shall adjust the speed of the playback session, such that Playback processing,

will increase or decrease at the specified speed increment. c) All data inputs, processing and outputs shall be processed at the Authorized User selected speed such

that all ROCC Playback Displays show the same sequence of events as occurred during real-time processing.

An Authorized User request to single-step through the Playback session shall result in the ROCC Playback Displays being updated in Authorized User-specified single-step time increments:

a) During a single-step operation all ROCC software processing shall occur at the normal data processing rate up to and including the next step time interval.

b) Once a single-step operation completes, Playback processing shall pause until the next step is initiated by the Authorized User.

c) The range of selectable single-step time intervals shall be developed subject to prototyping.

A request to advance (jump to a new time period) shall result in the Playback session being advanced to the specified time period. Playback shall process all Historical Data from the point in the data representing the Playback session at the time an advance request was made until the point in the data representing the time to advance to without noticeable delay to the User executing the session. An advance may require the Playback function to perform a stop of the current session and a start at the new time period.

The ROCC software shall provide the capability for Authorized Users participating in a Playback session to call up any ROCC software display or request any ROCC software Report available in the ROCC software at the time the Historical Data was logged, whether or not the ROCC Display or ROCC Report was opened or

Page 59


generated at the time. Authorized Users shall have the capability to perform any display control function defined in Section 2.8. At any point during Playback, the user shall have the capability to record the Playback session to a Playback Video Export File for viewing at a later time. A Playback Video Export File shall be able to be played on non-ROCC software platforms, including standard desktop or laptop computers.

The Playback Video Export File shall be of a standard video format (e.g .mp4, .mov, or .avi), capable of being copied to a portable storage device and played on any standard computer without the need for special Contractor-provided hardware or software. The video format to be used for the Playback Video Export File shall be reviewed and approved by WMATA during ROCC software design. Later viewing of the Playback Video Export File on a non-ROCC software platform shall look identical to the original playback session as it appeared on the ROCC software. Upon termination of a Playback session by Authorized Users, the ROCC Workstation shall become available for online operation.

4.4.6 Playback User Interface

The Playback User Interface shall control the progression of Historical Data based on Playback control requests from Authorized Users involved in the Playback session including, progressing at real-time, moving faster or slower than real-time, moving one event at a time, stop or pause, and restart at a specified time and date.

4.4.6.1 Playback Control Display

Playback Control Displays shall be provided to allow Authorized Users to select Historical data, to be retrieved or Playback, for any time period. Playback session is not limited by location of Historical Data in the ROCC software (online or offline). The Playback Control Displays shall provide the capability for Authorized Users to enter the following for retrieval of the Playback data from the Historical Data archives:

a) Start date; b) Start time, including (HH:MM); c) End date; d) End time (HH:MM).

The Playback Control Displays shall provide Authorized Users the capability to control the execution of the Playback data from retrieved Historical Data.

Playback Control Displays shall provide Authorized Users the following Playback selection criteria that may be entered in conjunction with the Playback controls, or may be entered at any time during a Playback session:

a) Playback data present at an RROCC Workstation(s) logged in at the specific point in time (include remote Workstations);

b) Playback data associated with an Authorized User(s) logged in at the specific point in time; c) Playback data associated with Territory(ies) at the specific point in time.

Playback Control Displays shall provide Authorized Users the capability to control the Playback session including:

a) Date to start execution of Playback; b) Time (HH:MM) to start execution of Playback; c) Date to end execution of Playback; d) Time (HH:MM) to end execution of Playback; e) Stop; f) Start;

Page 60


g) Pause; h) Resume; i) Alter the speed, j) Single-step; k) Advance.

The Playback Control Displays shall provide the capability for Authorized Users to change (e.g. with a single button selection) between the selected faster/slower than real-time rates and the real-time rate within the Playback session. The Playback Control Displays shall provide the capability for Authorized Users to advance to a specific time (HH:MM) or advance based on an offset from the current time (i.e. x hours/minutes from now).

Playback Control Displays shall provide the capability for Authorized Users to terminate a Playback session. The Playback system shall provide Authorized Users to select specific Historical Data points to be summarized, in chronological order, on Playback Data Summary Displays (e.g. FCU commands and indications, device changes of state, User-initiated commands).

4.4.7 Playback Failure Handling

The Playback system shall notify the User when an attempt to select an end period is less than or equal to the start period. The Playback system shall notify the User when a start and/or end time for Playback is not within the range of the data retrieved.

4.5 Reporting

A comprehensive reporting capability shall be provided that enables ROCC software Historical Data (online or within archival storage) to be retrieved, processed, and incorporated into a report:

a) All Historical Data within the ROCC software shall be available for querying and reporting. b) Reports and queries to the database shall be made using a standard, COTS product that is for that

express purpose. c) The COTS product used for Report Management shall be identified in the ROCC Software Design

Plan (SDP), subject to the approval of WMATA. d) The utilization of the selected COTS product shall not release the Contractor from the contractual

obligations to satisfy the functional, availability, capacity, expandability, and other requirements of these Specifications.

e) All versions of the Report Management COTS product shall be the latest version unless approved by WMATA.

f) The Report Management function shall be delivered as part of the ROCC software. g) The Report Management function shall operate with all RDBMS tools and applications implemented

as part of the ROCC software. h) The ROCC software reporting function shall support both pre-defined reports to be produced either on

demand or on a periodic basis, along with an ad-hoc reporting capability. The following common report features and presentation styles shall be uniform and standardized within various classifications of reports (summary sheets, logs, data reports); Headers and footers, User entry characteristics, General overall layout and Titles. Reports produced by the ROCC software shall be user definable for the following:

a) Reporting period (date and time); b) Time report is produced; c) Report format and content; d) Report calculations to be performed; e) Report distribution (both printed and electronic distribution); f) Online retention period (to allow system users to display the report)

Page 61


4.5.1 Report Creation

The Report Management function shall include an easy to use graphical user interface that allows an Authorized User to create and modify Pre-Defined Reports without performing code or programming changes. The Report Management function shall provide Authorized Users with a list of all available data items for inclusion in a selected Report template:.

g) All ROCC software Historical Data, whether online or stored in an off-line archive, shall be selectable for inclusion in a specific Report template.

h) Where listings of data items available for inclusion in a specific Report template are displayed to the Authorized User, each data items shall include the name and a brief description.

Report Management function shall allow Authorized Users to save and re-use Report objects, such as text objects and formulas. The Report Management function shall support the creation of standard Report presentation formats. Each Report generated by the Report Management function shall include the following on each page of the Report:

a) Report Title; b) Date and Time of the Reporting period; c) Date and Time that the Report was generated; d) Page Number in the format Page X of Y, where X is the current page number and Y is the total number

of pages in the Report.

Authorized Users shall be able to define textual row and column headings to be included in a Report.

Authorized Users shall be able to define specific calculations and expressions to be evaluated for individual fields within the Report:

a) Report expressions and calculations shall be definable using any pre-defined function within the Report Management COTS product, including basic arithmetic operations, basic logical operation, column and row totaling and subtotaling, and means, medians, maximums, and minimums of selected variables or groups of variables.

b) The Report Management function shall provide Authorized Users the capability to define the default location for presentation of the Report (i.e. requesting user’s monitor, printer identifier, or text file).

c) The Report Management function shall provide Authorized Users the capability to configure Report menus.

d) The Report Management function shall provide Authorized Users the capability to add new Pre-Defined Report templates to Report menus.

e) The Report Management function shall provide Authorized Users the capability to delete Pre-Defined Report templates from Report menus.

f) Access to Report menus by Authorized Users shall not require any ROCC software function to be stopped, paused, or restarted.

g) The Report Management function shall provide Authorized Users the capability to define function access rights for newly created Reports.

4.5.2 Pre-Defined ROCC Reports

A partial list of the pre-defined reports with which the ROCC software shall be delivered include, but are not limited to, the following:

a) Alarm Log; b) System failures; c) User Controls; d) Field data alarms report; e) Loss of Shunt Report; f) Schedule Adherence Report; g) System Performance On Time Summary Report (SPOTS);

Page 62


h) Line Performance “Squiggly Line” Report.

The ROCC software shall be delivered with all of the pre-defined “canned” OCC reports that are defined in the appendix of existing WMATA pre-defined reports. The Contractor shall work in conjunction with WMATA to define the complete list of pre-defined reports that are to be developed and delivered with the ROCC software. These pre-defined ROCC reports shall be included into the prototyping of the system.

4.5.3 Reporting Management User Interface

The ROCC software shall have all the tools necessary for a user to prepare reports and modify existing report structures. The Report Management function shall include interactive displays, menus, and dialogs to support all Report Management operations Report generation shall use native, natural field names and shall not require an Authorized User to employ the use of codes or cryptic keys to denote field names, and/or report names. Report generation shall support, at a minimum, multidimensional tables, multiple data views, provide flexible formatting, saving of report views for use by others. Report generation shall provide the capability to produce charts (e.g., pareto, x-bar, range), histograms, and scatterplots and allow the export of these graphic files for use by other ROCC software users. Report generation shall provide the capability to save a query to be run later that prompts for user-supplied parameters.

The Report Management function shall include a Report “wizard” to assist Authorized Users with Report creation:

a) The Report Management function “wizard” shall include templates for all Report types necessary to support specified OCC Reports, as well as those most commonly used or provided with the approved tool.

b) The Report Management function shall provide Authorized Users with the capability to design and apply customized templates in order to establish consistent formatting of Report data and consistent calculation of Report data.

c) The Report Management function shall provide Authorized Users with the capability to select a Pre-Defined Report to be used as a template.

d) The Report Management function shall guide the Authorized User in defining the Report format using the provided templates.

e) The Report Management function “wizard” shall assist Authorized Users in connecting Reports to data sources, selecting, grouping, sorting and summarizing Report data.

The Report Management function shall provide the following Report output destinations for Authorized User selection:

a) Display in Color on-screen; b) Print Report to a color printer; c) Print Report to a Black and White printer (converting color to gray tones); d) Save to Authorized User specified file.

The Report Management function shall provide Authorized Users the capability to export Report data into business applications provided with the System, such as Microsoft Word, Excel and Access. The Report Management function shall provide Authorized Users the capability to save any manually or Ad-Hoc generated Report to archive media.

The capability shall be provided for an Authorized User to define the report distribution (both printed and electronic distribution) for any report produced by the ROCC software. The capability shall be provided for an Authorized User to define the online retention period before storage to archive for any report produced by the ROCC software. The capability shall be provided for an Authorized User to define the Authorized User access, by user access type for any report produced by the ROCC software. All OCC Reports shall have a display format that incorporates appropriate controls for viewing, entering, modifying, and saving data; running queries and filters; and printing. All available required pre-programmed

Page 63


“canned” reports shall be gathered together in a single location where, grouped by function, the titles shall all be presented to an Authorized User and made available for execution. This “canned report screen” shall make all predefined reports available to be run upon demand (i.e. “run now”) or to be scheduled to be run at some time in the future of an Authorized User’s choosing. Execution of any report shall be logged as Historical Data. Information to be logged for each execution shall include:

a) Name/number of the report; b) Identification of the user who executed the report; c) Time the report was executed; d) Date the report was executed; e) Console Workstation from which the report was executed; f) Printer/file location to which the report output was directed.

4.5.3.1 Manual Report Execution

The Report Management function shall provide Authorized Users the capability to generate Pre-Defined Reports by selecting the Report template from the menu:

a) The Report Management function shall provide Authorized Users the capability to select the filter criteria that will be used in generating the pre-defined Report.

b) The Report Management function shall provide Authorized Users the capability to sort the data in the Report.

c) The Report Management function shall provide Authorized Users the capability to override the default location for Report presentation.

4.5.3.2 Ad-Hoc Reporting

The Report Management function shall provide Authorized Users the capability to produce Ad-Hoc Reports at any time. Ad-Hoc Reports are those where a predefined Report format does not exist:

a) The Report Management function shall provide Authorized Users the capability to generate Ad-hoc Reports by selecting data fields from a pre-established list of fields, subject to prototyping.

b) The Report Management function shall provide Authorized Users the capability to establish sort criteria for the data on the Ad-hoc Report.

c) The Report Management function shall provide Authorized Users the capability to select the location for Report presentation.

d) The Report Management function shall provide Authorized Users the capability to save a formatted Ad-Hoc Report as a selectable pre-defined Report template accessible to Authorized Users.

e) The Report Management function shall provide Authorized Users the capability to create Ad-hoc Reports in accordance with the requirements for pre-defined report creation, including headers, footers and page numbers.

4.5.3.3 Automatic Data Entry

The ROCC software shall automatically provide all data required in each of the specified reports available in the ROCC software on-line database(s), archive storage, or which can be calculated from the ROCC software data. The ROCC software shall provide, with minimal human intervention, the data required in each of the specified reports that is available in the ROCC software archive files. Default values shall be defined where it is viable to do so.

4.5.3.4 Manual Data Entry

The ROCC software shall provide the user the ability to manually-enter data, not automatically entered, into the reports by the ROCC software:

a) Users shall only be required to enter report data that is not available on the ROCC softwares. b) The ROCC software shall provide the user the capability to perform multiple user entries in a report.

Page 64


c) The ROCC software shall perform validity checks of all manually entered data that can be subjected to validity checks, such as data within range, correct data type (integer, alphanumeric, etc.), data within limits, specific data entities valid, and others.

d) The ROCC software shall prevent report fields, specified to be non-modifiable, from being updated by an ROCC software User.

All manual entries shall be logged with at least the following information stored; the field name, old value, value provided and the logon (person) changing the value. The ROCC software shall provide the user a convenient means of entering data into any free-form report fields and allow users to enter, edit, copy, drag and drop, and delete text in the free-form report fields in a way typically found in modern, state-of-the-art word processing programs. The System shall perform validity checks of all manually entered data that can be subjected to validity checks.

4.5.3.5 Report Closure

The ROCC software shall provide the capability for an Authorized User to close reports, immediately archive one or more closed reports, even if the user specified timeframe has not been reached for that report. Closed OCC Reports shall be available on the ROCC software for the user specified timeframe before automatic archival.

4.5.3.6 Report Filtering

Reports produced by the ROCC software shall be filterable using the following criteria:

a) Date and time covered by Report; b) Date and time report was produced; c) Report types; d) Service.

4.5.3.7 Report Printing

The ROCC software shall provide an Authorized User the capability to print any reports available on the ROCC software. Report printing shall have a formatted output (not a print screen capability) that includes all the information available on the particular report (including the information that requires scrolling on the display):

a) All available required pre-programmed “canned” reports shall be gathered together in a single location where, grouped by function, the titles shall all be presented to an Authorized User and made available for printing.

b) This “canned report screen” shall make all predefined reports available to be printed upon demand (i.e. “print now”) or to be scheduled to be printed at some time in the future of an Authorized User’s choosing.

c) All printed Reports shall be formatted so that there is no loss of information if the Report is printed in black and white (e.g. printed Reports must be formatted without reliance on specific color to convey information).

d) The Report Management function shall provide Authorized Users the capability to select the number of copies of the Report to be printed.

e) Report printing shall have a print preview capability on all reports.

4.5.3.8 Predefined Reports User Interface

The predefined report titles shall all be presented to the user, by function, for selecting (one or many) report(s) for immediate execution. The predefined report titles shall all be presented to the user, by function, for selecting (one or many) report(s) for execution automatically at any time in the future. Selection of predefined report(s) shall allow for automatic execution of predefined reports at any future date (month, day, and year) and time of day. Selection of predefined report(s) shall allow for automatic execution of predefined reports at regular time intervals where the choices include, but are not limited to; Daily, Weekly, Bi-weekly; Monthly, Quarterly, Annually and on a specified date, with a specified execution time of day. For example, it provides a user the ability to schedule a report to be executed for “every Friday at 11:30 p.m.,” or “midnight on the 13th of each month.”

Page 65


The pre-defined report produced by the ROCC software shall provide the capability for the user to define the reporting period (e.g. start and end time of data in the report). The ROCC software shall provide the ability to update pre-defined reports with manually entered data that is not available on the ROCC software, even if this requires multiple user entries. Facilities shall be provided to allow users to enter, edit, copy, move, and delete text (providing the functionality, features, and ease-of-use typically found in modern, state-of-the-art word processing programs) for any free-form user entry fields within pre-defined reports. The ROCC software shall provide the capability for the user to define any report calculations to be performed in the pre-defined report. The prompts, data entry fields, and displayed information shall be customized for the particular report type and also based upon previous entries in the report fields (e.g. incident report fields are customized based on the entry of an incident type). Automatic execution of pre-defined reports shall take place at the user-specified time, without user intervention.

4.5.3.9 Custom Reports User Interface

The ad hoc reports capability shall provide Authorized Users the ability to format the ad-hoc report for easy reading where the choices include, but are not limited to; formatting the report with common report features and presentation such as headers and footers, adding the report title, adding page numbers and specifying human-readable row and column names:

a) The ROCC software and hoc reports capability shall provide the user the ability to create situation-specific queries from the database containing user selectable reporting points (e.g. one or many table/field names and one or many data limiting selections).

b) Any ad-hoc report produced by the ROCC software shall provide the capability for the user to define the reporting period (e.g. start and end time of data in the report).

c) Any ad-hoc report produced by the ROCC software shall provide the capability for the user to define the time the report was produced.

d) The ROCC software shall provide the capability for an Authorized User to define any report calculations to be performed within the ad-hoc report

e) The ROCC software shall provide the ability to update ad-hoc reports with manually entered data that is not available on the ROCC software, even if this requires multiple user entries.

f) The ROCC software shall provide the capability for saving ad hoc reports and turning them into named standard reports (i.e. “pre-defined” or “canned” reports), at the discretion of the user.

The named standard report titles shall all be presented to an Authorized User for selecting (one or many) report(s) for immediate execution. The ROCC software report generation tool shall be equipped with the ability to output query response data to standard word processing and spreadsheet tools, allowing for further data analysis. Facilities shall be provided to allow Authorized Users to enter, edit, copy, move, and delete text (providing the functionality, features, and ease-of-use typically found in modern, state-of-the-art word processing programs) for any free-form user entry fields within ad-hoc reports. The ROCC software shall notify the requester if the requested report format file or generated report is not available or has something wrong with the file and cannot be viewed. An out-of-scan indication shall be propagated to all consumers of the variable so that all calculations and reports are suitably flagged.

4.5.4 Reporting Failure Handling

The ROCC software shall notify the requester if the requested report format file or generated report is not available or has something wrong with the file and cannot be viewed.

Errors detected during Report generation shall be documented into a Report Generation Error Report:

Page 66


a) Report Generation Error Reports shall include the date and time of the Report generation, identification of the User that initiated the Report generation if manually initiated, a description of the errors including the data points that failed, and the values at the time of error detection.

b) Report Generation Error Reports shall be ASCII text, readable without reference material. c) When an error is encountered, the Report generation function shall attempt to continue processing the

Report in an effort to detect all existing errors before terminating. d) The Authorized User responsible for the Report shall be notified of the name and location of the

Report Generation Error Report at the time one is created.

Invalid data entry errors, such as illegal expression definition or invalid data type into a Report list, shall be detected and a user advisory message presented to the Authorized User:

a) Invalid entries detected by the Report Management functions shall not be entered or saved to the Report.

b) When the Report Management functions detect data entry errors, the Authorized User shall not be required to repeat steps that were correctly executed prior to the erroneous action.

4.6 Simulation

The OCC Simulator shall include a capability to simulate the operation of the WMATA ROCC software including train control and all SCADA functioning (e.g. traction power, tunnel ventilation, and drainage) in such a way as to provide the capability for training of Authorized Users in an off-line environment running operational scenarios and for testing of updates to the OCC software and databases. Within the Simulation scenario, Authorized Users shall inherit all access rights based upon their user classification (Instructor, Trainee, Tester) at log-on. Execution of the Simulation function on the on-line ROCC software shall be prevented except that the Contractor may do so for Factory and Site Testing phases prior to the start of the Transition period as defined elsewhere in the Contract Documents. The ROCC software shall have the capability to perform concurrent execution of different Simulation scenarios. This shall include the capability for:

a) Instructors to monitor, configure, and control operations at Trainee Workstations involved in the same Simulation session.

b) Up to 10 Authorized Users to participate in the same Simulation session. c) Accessible from any ROCC Workstations.

4.6.1 Simulation Functionality

The Simulation shall be populated with Simulation data manually input by an Authorized User input or from execution of one or more Simulation scenarios. Upon startup of any Simulation the session shall be automatically started in a clear (un-initialized) state at the initiating workstation. This shall include emulation of field ROCC software operation, control, and indication, interfaced to the OCC for real-time data acquisition and control.

The Simulation shall simulate various device failure conditions as necessary to demonstrate the proper responses to these failures, the entry and progression of trains through WMATA Rail Territory in accordance with an Engineer selected schedule. The Simulation shall be used to demonstrate the proper train dispatching, train tracking, train identification, and data sharing with interfacing external systems.

Simulation shall replicate user interaction with all elements of the WMATA SCADA system including, but not limited to, the following:

a) Traction Power – this module shall provide monitoring and control simulation of traction power via an interface with the existing power grid in the field through the WMATA MERCS, accurately simulating tracking and display the locations, energization status and other pertinent data of all plate circuits in the ROCC monitored territory.

Page 67


b) Tunnel Ventilation – this module shall provide control and monitoring simulation of WMATA tunnel ventilation system and all associated devices, including, but not limited to, fans and dampers. Simulation shall mimic zone control of the ROCC monitored territory such that ventilation of a specific area can be accomplished with a single operator action. Fan sequencing shall be accurately and comprehensively simulated and shall be suitable to adequately train operators in emergency operations.

c) Tunnel Drainage – this module shall provide control and monitoring simulation of WMATA drainage monitoring system and all associated devices including, but not limited to, pumps. Simulation shall mimic zone control of the ROCC monitored territory such that drainage of a specific area can be accomplished with a single operator action.

d) During execution of the Simulation System, all OCC functionality shall be executing and performing real-time processing using simulated external inputs.

e) When running in a simulated environment, the OCC functions shall interface with simulated external devices and systems in the identical way for receiving inputs and sending outputs, as in real-time operation.

The ROCC software, when configured to operate for Simulation (i.e., as part of the Training System) shall provide the capability for manual input of Simulation data by an Authorized User as well as include external system Simulation functions (simulators) for all OCC interfaces as defined elsewhere in the Contract Documents:

a) The external system Simulation functions shall include complete and accurate Simulation of the input, output, and processing of each external system and device.

b) The OCC external system Simulation functions shall simulate the operation and functionality of the associated external device or system using data received from the OCC, data generated by the Simulation scenario, and manual inputs from Authorized Users.

c) The OCC Simulation System shall include the capability to simulate both normal and error responses to data received from the OCC, data generated by the Simulation scenario, and manual inputs from an Authorized User.

d) All simulated outputs from the external interface simulators (i.e., track circuit occupancies, device state changes, etc) shall be dynamically adjusted based upon data generated by the Simulation scenario, and manual inputs from Authorized Users.

The ROCC Simulation System shall simulate the data exchange, messages and failure scenarios in the communication protocol for the following:

a) CTC System; b) SCADA System, including Traction Power, Tunnel Ventilation, & Tunnel Drainage; c) GPS Time Facility; d) Video Display System.

Simulation shall support the simulation of all conditions and functions supported by the ROCC software. Simulation shall:

a) Display all forms and graphic displays that comprise the ROCC software, including providing identical displays for all systems;

b) Provide safeguards to ensure that no training action results in the control of a field device or impacts the real-time ROCC software;

c) Simulate responses to all trainee actions in a realistic manner identical to the real-time ROCC software responses;

d) Provide the ability to create, modify and execute scenarios that depict various operating conditions, including normal operations, fault conditions and emergencies;

e) Provide the ability to run the simulation program at both “slower than real-time” and “faster than real-time” to adjust to the skill levels of the trainee;

f) Provide the ability to record and play-back the ROCC software responses and results that would arise on the real-time ROCC software as a consequence of the trainee’s actions.

Page 68


Simulation is to be relatively simple and intuitive to operate and shall be able to be performed by an Authorized User with the control system knowledge of an ROCC software Trainer:

a) The user interface to the Simulation function shall be developed for, focused on, and be ‘natural’ to WMATA Operations personnel (i.e. terminology shall be common OCC Line Supervisors and the existing Traction Power interface.)

b) Simulation shall be subject to review and approval through user interface prototyping. c) A Simulation sequence shall be able to be run without setup or other assistance from an individual

versed in computer systems, WMATA data acquisition, or any other specialized skill other than that which would be possessed by an ROCC software Trainer.

4.6.2 Simulation Sessions

The ROCC software shall initially include a minimum of 15 pre-defined Simulation scenarios, to be defined during prototyping. Authorized Users shall have the capability to create, modify, and delete Simulation scenarios. Each Simulation scenario shall be capable of storing and processing up to 24 hours of data. Authorized Users shall have the capability to execute a Simulation session with or without running a pre-established Simulation scenario. Stopping and/or pausing a Simulation session shall cause the Simulation System to stop processing simulated inputs. While a Simulation session is stopped or paused, the ROCC software shall continue to process all OCC functions not related to the Simulation function, such as Authorized User requests for displays and reports. Resuming a paused Simulation session shall cause the Simulation to begin processing simulated input at the point at which the Simulation was paused.

The ROCC software shall provide a virtually infinite variable selection of Simulation speeds not to be limited by only a few selected pre-set speeds. Accelerating and decelerating the speed of the Simulation shall cause the Simulation to either increase or decrease the rate at which the simulated inputs are received and processed by the Simulation System. The ROCC software shall continue to process all OCC functions not related to the Simulation function, at the normal real-time rate.

4.6.3 Simulation Session Data Retrieval

The ROCC software shall retrieve archived Historical Data through the Information Storage and Retrieval Historical Database Tracking System:

a) The Simulation shall provide the capability for Authorized Users to define the use of Historical Data as Simulation data.

b) Authorized Users shall have the capability to store retrieved Historical Data or prepared Simulation Data either online or on the archive system.

c) Stored Simulation data shall be distinctively identified to prevent use in functions requiring archived actual operational data.

Simulation shall be fully backwards compatible such that future updates of the ROCC software must be able to run Simulation off of any data set from any release of the ROCC software, regardless of the version or age of the data.

4.6.4 Simulator Functionality for Training

The OCC Simulation System shall accommodate Simulation sessions with one or more Instructors and Trainees per session. Concurrent Simulation sessions shall be capable of executing different scenarios on different sets of Simulation data.

4.6.4.1 Instructor Functionality

An Authorized User operating a workstation as an Instructor shall have the capability to control, in real time, the Simulation of all Trainee workstations participating in the Simulation session. The Instructor shall have the capability to:

Page 69


a) Monitor, in real time, the activity of all Trainee workstations participating in the associated Simulation session.

b) Remotely access a Trainee’s workstation such that the Instructor can work concurrently with the Trainee on the Trainee’s workstation.

c) Interact with the Simulation to inject incident conditions, modify field responses, modify parameters, induce operator errors and inject simulator outputs.

Output from the Trainee’s Simulation session shall be presented to the Instructor, such that it can be easily determined which output corresponds to which Trainee, subject to prototyping.

4.6.4.2 Trainee Functionality

Upon Trainee log-on, each Trainee Workstation shall be automatically configured as defined by the Instructor for the specific Simulation session. The Trainee’s Simulation System shall reflect the result of all Instructor initiated Simulation commands (i.e. injected incident conditions, modified field responses, modified parameters, induced operator errors and injected simulator outputs). Each Trainee shall interact with the Simulation session independently from other Trainees logged into the same session. Actions initiated by a Trainee at a given workstation shall not affect the operation of the Simulation session at another Trainee’s workstation.

4.6.5 Updates to the OCC Simulator

Specific updates to the OCC software or the database may require updates to be generated for the OCC Simulator. Except where modified for testing, the Simulation function shall be identical to the real-time operational ROCC software functionality.

Authorized Users shall have the capability to update the Simulation System through the tools and utilities provided with the ROCC software including but not limited to:

a) Modifications to operational rules; b) Modifications of wayside logic restrictions; c) Modifications to system constraints; d) Modification to routes; e) Modifications to field signaling system characteristics and equipment; f) Modifications of topological features; and g) Modifications of database attributes.

The System Administrator shall have the capability to update the protocols or the interface (to include all transmission and reception messages and failures) for data communications to/from the:

a) CTC System; b) SCADA System, including Traction Power, Tunnel Ventilation, & Tunnel Drainage; c) GPS Time Facility; d) Video Display System.

4.6.6 Simulation User Interface

The Simulation Displays shall provide the capability for Authorized Users to select one or more pre-defined OCC Simulation scenarios to run in a specific or random order during a Simulation session. Authorized Users shall have capability to:

a) Establish the initial state of the OCC for Simulation based upon user inputs, configure all parameters (i.e. territory assignments, function access assignments, user classifications) and to select the service schedule that shall be used to dispatch trains.

Page 70


b) Dynamically inject all possible incident conditions in order to modify the behavior of the system during scenario creation or execution of a Simulation session. Incident conditions shall include but not be limited to disabled trains, service blockages, system failures, failed field devices such as track circuits or switches not completing a throw, fires, failed communications links, failed computer equipment, failed equipment/functions.

c) Change specific field responses to simulated conditions, including both normal and defined error responses to user actions and commands, during scenario creation or execution of a Simulation session.

d) Dynamically modify parameters such as train speeds (based on simulated track circuit occupancy indication states), dwell times that are settable per station, and wayside logic restrictions, during scenario creation or execution of a Simulation session. The initial set of user-adjustable parameters modifiable as part of Simulation shall be defined subject to prototyping.

e) Dynamically induce train operator errors such as overrunning red signals or proceeding before departing lights permit during scenario creation or execution of a Simulation session. The initial set of Authorized User-induced train operator errors shall be developed subject to prototyping.

f) Manually interject Simulation outputs (e.g. traction power status), whose states are not determined by the simulator (e.g. states cannot be determined based on the inputs to the simulator or cannot be determined by the Simulation rules/logic).

g) Enter Simulation data through menus and dialogs that are accessed through graphical displays such as the track diagram.

For those Simulation parameters that are associated with a device, a pop-up menu or dialog shall be invoked by clicking on the associated device. For example, the user will select “emergency switch release activation” alarm from a pop-menu that is invoked from the switch. The Simulation Display shall provide the capability for an Authorized User to start/stop, pause and resume, accelerate/decelerate a Simulation.

4.6.6.1 Scenario Creation Display

Simulation scenarios provide a means to control the behavior of an external system Simulation function by injecting or overriding inputs and outputs to simulate a specific condition. Scenarios can be developed to specify the data to be used to control the Simulation function over any period of time and for the Simulation of any possible conditions applicable to the operation. The Scenario Creation Displays shall provide the capability for Authorized Users to:

a) Create, modify and delete Simulation scenarios. b) Name and store Simulation scenarios for future access. c) Populate a Simulation scenario with Historical Data retrieved by the Information Storage and Retrieval

Historical Database Tracking System or which has been stored on external archive medium. d) Copy Simulation scenarios from existing scenarios to create or modify another scenario.

All Simulation data, necessary to control and generate simulated inputs and expected outputs and states, shall be stored within the Simulation scenario.

4.6.7 Failure Handling

A user advisory message shall be presented if the requested Simulation data, Simulation scenario, or retrieved Historical Data cannot be located online or on external archival media. An alarm shall be generated if a scenario stops running without an Authorized User stopping or pausing the scenario.

4.7 Display Control

This section describes the types of displays that comprise the ROCC software and the requirements for navigation through the displays. This section also describes how the User will interact with the system via windowing techniques, menus, selection lists, dialogs, and point and click.

Display control requirements specified herein shall apply to all graphical elements displayed in the ROCC software including those displayed as part of train control and SCADA functions:

a) All graphical elements to be displayed in the ROCC software shall be stored in and retrieved from the Display Control Graphical Library.

Page 71


b) Reference – Contract and Contractor Maintenance for requirements related to creation, modification, and update of the Display Control Graphical Library.

All features and standards for development of ROCC software Displays shall be defined in the Display Conventions and Guidelines Document (CDRL T201).

4.7.1 Displays

Authorized Users will interface to the ROCC software through the use of a menu system, graphical displays and text-based displays (e.g. tabular displays, dialogs and report forms). All ROCC software Displays and menus shall be represented and apply to all ROCC monitored devices (i.e. signal system, traction power, tunnel ventilation, and tunnel drainage).

All ROCC software Displays shall mimic the existing ROCC system in both appearance and function to the greatest extent possible, in an effort to minimize retraining of OCC personnel:

a) The Contractor shall be obligated to obtain documentation from WMATA regarding the control system currently in use and shall observe WMATA operations prior to ROCC software design as part of the effort to duplicate the existing ROCC system user interface to the greatest possible degree.

b) The user interface for the ROCC software shall be subject to prototyping and WMATA approval. c) The Contractor shall implement all of the existing user interface displays as described in Specification

Section 2.2 WMATA Signal System Monitoring and Control.

All ROCC software Displays shall be opened, manipulated, and closed in a manner consistent with using the standard windowing techniques as defined in these Specifications and subject to user interface prototyping, unless otherwise specified.

4.7.1.1 Graphical Displays

The ROCC software shall mimic all displays in the existing ROCS system and shall make use of a world coordinate system that will represent the WMATA rail territory track alignment and associated devices. Users will interact with the world coordinate system via graphical displays that are presented ROCC Workstation monitors and on the OCC Video Display Wall.

Objects shown on graphical displays are a function of the display type (e.g. overview, detailed area). The displays will provide the ability to “declutter” objects and text and this will be determined during user interface prototyping.

Authorized Users shall interact with the ROCC Workstation via an optical mouse. The ROCC software graphical displays shall present real-time dynamic information to Authorized Users via graphic objects. Updates to the graphic objects shall be event driven. Each Authorized User shall be provided the capability to request and interact with multiple graphical displays at the ROCC Workstation, without affecting the displays that are presented at another User’s ROCC Workstation.

4.7.1.1.1 Declutter Levels

The ROCC software shall support a minimum of 32 declutter levels. The set of declutter levels to be initially provided in the ROCC software are subject to user interface prototyping and Engineer review and approval.

4.7.1.1.2 Applying Declutter Levels

The ROCC software shall include declutter level functions that provides the capability for Authorized Users to control the amount of graphic objects that are shown on their graphical displays by applying a declutter level:

a) A declutter level shall add the graphic objects associated with the declutter level to the User-selected display.

b) Removing a declutter level, shall remove the graphic objects from the User-selected graphic display.

Page 72


Users shall be provided the capability to apply/remove declutter levels on their ROCC software Displays only, without affecting the display at another User’s ROCC Workstation. The manner by which Users will select the declutter levels to be displayed shall be determined during prototyping. Declutter levels shall also be applied in accordance with the selected zoom level such that only a selected declutter level will be displayed on selected zoom levels, subject to prototyping.

4.7.1.1.3 Defining Declutter Levels

The complete set of ROCC software declutter levels shall be developed during Prototyping for Engineer review and approval.

Authorized Users shall be provided the capability to assign graphic objects to declutter levels:

a) Graphic objects shall be assignable to one or more declutter level(s). b) Authorized Users shall be provided the capability to apply text to each declutter level independently

from the other displayed declutter levels.

Authorized Users shall have the capability to create, modify delete and assign a name to each declutter level.

4.7.1.2 Text-Based Displays

Text-based displays will typically display textual information to the User and/or require a user to input information into a form. Tabular displays are a form of text-based display, where data is presented to the User in a list and/or a table. An example of a tabular display is the Alarm Summary Display.

Text-based displays that require the display to be updated dynamically with real-time data are identified as such within these Specifications. The ROCC software shall include dynamic text-based displays as required within these Specifications. Updates to the real-time, dynamic, text-based displays shall be event driven.

Text-based displays with multiple pages shall include page numbering on each page in the form: Page N of M (where N represents the current page number, M represents the total number of pages), in the window’s title bar. Presentation of the page numbering for multiple page text-based displays shall be subject to prototyping.

The ROCC software shall provide the capability for the User to select multiple entries on a text-based display by using accelerator keys:

a) The User shall be able to select an adjacent range of entries on the display by selecting the first entry, then depressing an accelerator key (e.g. the SHIFT key) and selecting the ending entry.

b) The User shall be able to select multiple non-adjacent entries on the display by depressing an accelerator key (e.g. the CTRL key), then selecting each entry.

c) After selection, the User shall be able to select the appropriate action for the selected entries (e.g. delete, acknowledge, inhibit).

d) In the event the Contractor’s standard product does not behave in this fashion, the Contractor shall propose an equivalent process for Engineer review and approval as part of the user interface prototyping.

Text-based displays that show summary or tabular data shall be formatted with column headings and page numbers when appropriate:

a) The format of the summary and tabular displays shall be determined during prototyping. b) The User shall be able to page through text-based displays using the next page/previous page keys. c) The next page/previous page keys shall cause the replacement of the information currently shown with

information directly after it or preceding it respectively. d) Paging forward from the last page of a series of display pages shall present the display’s first page. e) Paging backward from the first page of a series of display pages shall present the display’s last page. f) Column and row headers shall remain in a fixed position on the display as the User pages through the

display. g) Capability shall be provided to single step through the display, where a step is a single text line, row or

column.

Page 73


4.7.1.2.1 Dialogs

The ROCC software shall utilize dialog boxes for presenting information or feedback to a User or where requests for information or actions are required from a User. All dialogs shall require an action from the User and upon completion of the User action, shall be removed. Dialogs shall have a widget (e.g. button) that allows the User to:

a) Indicate completion and acceptance of entered data or actions, such as an “OK” button. b) Indicate acceptance of entered data or action without closing the dialog, such as an “Apply” button. c) Cancel the request for data or action, such as a “Cancel” button.

Dialogs shall disappear upon the cancellation or completion of the dialog, unless otherwise noted in these Specifications.

4.7.1.2.2 Control Action Confirmation

During interaction with the ROCC software, the User may request an action that requires a secondary acknowledgement by the User. Control Action Confirmation is the process in which actions that are initiated by the User are delayed pending verification from the User that the action requested is desired.

Where an action is defined to be subject to Control Action Confirmation, the ROCC software shall display a Control Action Confirmation dialog. The Control Action Confirmation dialog shall be subject to the constraints of normal dialogs, but shall not have the “Apply” button widget.

The ROCC software shall not perform the associated action until the User has indicated acceptance of the Control Action Confirmation dialog. If a Control Action Confirmation dialog is cancelled by the Authorized User, such as selection of the “Cancel” button, the associated action shall be cancelled by the ROCC software.

4.7.1.2.3 User Guidance Message

During user interaction, a user may not follow the correct procedure, or may otherwise need to be alerted to a problem or may need additional guidance information. In these cases, a dialog called a user guidance message will be displayed to the User advising him or her of the problem. The User Guidance Message shall provide a North American English text message giving the User the appropriate guidance.

Where an action is defined to need a user guidance message, the ROCC software shall display a User Guidance Message within a dialog box or as a pop-up display. The User Guidance Message dialog shall be subject to the constraints of normal dialogs, but shall not have the “Apply” or “Cancel” button widgets and be closed upon indication of acceptance (e.g. clicking the “OK” button).

4.7.1.3 Menus

The ROCC software shall incorporate a menu system that provides Authorized User access to all ROCC software Displays, including graphical and text-based displays. The menu system shall include the use of a Main Menu bar, pop-up menus, cascading menus and pull-down menus.

Pop-up menus shall appear temporarily when a selection is made with the mouse or with a function key and Pull-down menus shall appear directly beneath the item that has been selected by a user with the mouse. Cascading menus shall be used to group menus options, such that options are further refined at each subsequent menu level.

4.7.1.3.1 Main Menu

The ROCC software shall incorporate a single Main Menu bar. The Main Menu bar shall:

a) Contain a list of pull-down menus that provide access to ROCC software functions and displays. b) Automatically be displayed upon successful Authorized User log-on. c) Not be capable of being resized, minimized or closed by the User. d) Not be covered or obstructed by any display, i.e. always on top.

Page 74


e) Not exceed the width of one ROCC Workstation monitor.

An Authorized User shall be provided the capability to open any ROCC software Display from the Main Menu bar. The Main Menu bar shall be automatically reconfigured based on User access rights at a ROCC Workstation. Menu bar selections and lists that are not authorized for User access shall not be accessible to the User (e.g., inaccessible items shall be ‘desensitized’, or may be ‘grayed out’ in color).

The default location of display windows opened from the Main Menu bar shall be subject to prototyping.

During user interface prototyping, the Contractor shall propose the default location (monitor) of the Main Menu bar and any specific attributes of the Main Menu bar for review and approval by WMATA.

4.7.1.4 Selection Lists

The ROCC software shall utilize selection lists to support user input. Selection lists shall allow single selection and multiple selections. Selection lists shall be automatically populated from system databases with data that is relevant to the list and shall not require software source code modification to modify the selection list. At a minimum, selection lists shall be utilized for User selection of station names, location names, train identifiers, device identifiers and employee identifiers. The complete set of selections lists shall be defined by the Contractor and reviewed by WMATA in conjunction with prototyping.

As the User types into a selection list, the list shall scroll to the selection that most closely matches the entered characters. In the event there is one or more exact matches in a selection list, the first match shall be displayed and highlighted with up to ten additional exact matches visibly listed below the first. Selection lists shall be ordered according to the application being performed (i.e. a station name list may be in geographical order, whereas an employee identifiers may be in numerical order).

4.7.2 Display Selection

This section describes how the User will select displays to be viewed at a ROCC Workstation. ROCC software Displays are configured as a single “screen.” For ROCC Workstations, the screen encompasses the display areas of all monitors. The cursor can be moved through the entire screen (across multiple monitors, where provided). The “Main Menu” described in a separate sub-section, will be the primary access point for user interface activities and display selection.

ROCC Workstations (inclusive of all monitors) shall be configured as a single screen. ROCC Workstations equipped with more than one monitor, the single screen shall encompass the display areas of all monitors that the ROCC Workstation is configured to use.

The ROCC software shall allow Authorized Users to control the configuration of displays presented on the OCC Video Display Wall. Authorized Users shall be provided the capability to define and save definitions of display level configurations for the OCC Video Display Wall.

Authorized Users shall be provided the capability to select at any time, the display configuration to be presented on the screen of the ROCC Workstation at which the user is logged on using the Custom Console Configuration display.

4.7.3 General Window Characteristics

This section defines how the User will interact with windows that are displayed on the screen. The contents of the window could be a graphical display, a text-based display, a dialog, a menu, or a selection list. Each display will have a set of attributes that are established by an Authorized User when the display is created. These attributes will include the size of the display, the default location of the display on the screen when invoked and whether the window should always appear “on-top” (meaning totally viewable and not covered by other displays). The displays that must always be “on-top” and the default position of displays will be reviewed in conjunction with the prototype console. The User will be able to move the display and resize it through the use of the window requirements specified herein.

Page 75


4.7.3.1 Title Bars

Each window that contains a graphical display and/or a text-based display shall include a title bar. Title bars shall identify the title (i.e. full name) of the display. The Window title bars shall be presented using a consistent color, font, font style, font size, and consistent position. The title and page numbering information (where necessary) shall be displayed at a consistent location within the title bar for all windows.

4.7.3.2 Displaying Windows

All windows that contain dialogs, pop-ups, and/or pull-down menus shall be displayed within the display area of the monitor in which they open and they shall not be “stretched” across the display area of more than one monitor:

a) All other windows, when invoked, shall be able to be displayed across the display areas of one or more display monitors, subject to prototyping.

b) Once opened, a pop-up or pull-down menu window will not be required to move with the window from which the pop-up/pull-down was initiated.

c) A pop-up or pull-down menu window shall close if the Authorized User selects another window including the window in which the pop-up/pull-down appears from or was initiated.

All windows that contain dialogs, pop-ups, and/or pull-down menus that are associated with display objects and are presented to initiate controls or display information (such as non-critical alarms and messages) shall adhere to the following rules:

a) Appear within the display area of the monitor on which the display object; b) Be located in close proximity to the display object; c) Not obscure the device(s) being controlled; d) Not obscure the device control target areas; e) Be sized such that it is visible in a window of minimum size, subject to user interface prototyping and

approved ergonomic criteria.

All windows that contain dialogs, pop-ups, and pull-down menus shall open when invoked in an area that will not obscure areas of the displays with pending or in-progress control actions.

Overlapping windows shall be visible (i.e., the window and its display shall not be completely obscured by another window) according to the following priority order of visibility:

a) Windows presenting critical alarm displays shall always be “on top” whether or not the window has the focus;

b) Windows presenting menus, dialogs, pop-ups, and other windows used to initiate controls; c) Windows displaying track displays; d) Windows containing other displays such as reports, system status displays, non-critical alarms, etc.; e) For windows of the same visibility priority, a window selected by the User shall be “on top”. When not

selected, the last window selected by the User shall remain “on top”; f) In multi-monitor user positions, windows may be defined to appear in the display area of one monitor,

or simultaneously on all monitors.

4.7.3.3 Window Manipulation

Window functionality that is unique to a particular display, i.e. is not a general characteristic of all windows, will be included with that display’s requirements. Unless otherwise specified, windows shall be user resizable by selecting and dragging the cursor from any corner or side of window area. Unless otherwise specified, the User shall be able to adjust the window size to the full dimensions of the screen or the display area of a single monitor (i.e. “maximize”). A window that is maximized shall not be capable of being moved.

Unless otherwise specified, windows shall be movable within the screen (i.e. to any location on any monitor) by selecting and dragging the Title Bar using a “drag and drop” technique. The User shall be provided the capability to overlap, cascade or tile the windows in accordance with the requirements for overlapping windows.

Page 76


Changing the size of the window shall allow for additional text and/or graphics to be displayed within the window. For example, enlarging the window size on a graphical display will allow additional area to be viewed. Unless otherwise specified, windows shall be capable of being minimized and restored. Window dimensions shall be independently adjustable to a screen resolution of four pixels or less.

4.7.3.4 Display Scrolling within a Window

Displays that are larger than the window shall include up/down and left/right scroll bars as necessary, for navigating the entire display. Scrolling of the displays shall include directional arrows in the scroll bars indicating that additional information can be viewed by scrolling in the direction the arrows point.

Scroll bars shall continue to be visible when a window is resized, unless the window is resized such that the entire display fits within the window. The User shall be able to select and drag scroll bars using the mouse.

4.7.4 Print Control

Authorized Users shall be able to select any display or report for printing. The ROCC software shall provide print preview capability for User preview of any display or report to be printed. Each display and report shall provide a consistent mechanism for printing, such as an icon on the window title bar or a command button located on a dialog or text-based display, subject to prototyping.

Selecting the print option shall present a dialog requesting the User to select a printer:

a) The print dialog window shall default to an Authorized User-defined default printer, based on the type of display.

b) All displays shall default to a black and white printer, unless otherwise defined by an Authorized User.

Authorized Users shall be able to select the number of copies to print to the selected printer. The number of copies for all print requests shall be defaulted to one. The printed display/report shall contain headers, footers, page numbers, current date and time, name of the display/report and the requestor. The print function user interface shall be subject to prototyping.

Authorized Users shall be provided the capability to:

a) Select a portion of the graphical display for printing. The method of selecting the graphical area for printing shall be subject to user interface prototyping.

b) Select a screen print, which captures only the data that is presented within the window for printing. c) Print a formatted report of the data presented within the display, regardless of how much data is shown

within the window frame. For example if a five-page text-based display is displayed, the formatted report shall contain all five pages of data.

d) Select any ROCC software printing device for printed output, selectable on a per job basis.

4.7.5 Display Control User Interaction

4.7.5.1 Cursor Positioning

The ROCC Workstation shall emulate and display cursor motion along any axis proportional to the motion of the optical mouse. The slew rate (that is, the number of pixels moved per unit movement of the mouse) shall be directly proportional to the speed of mouse movement. The mouse shall move the cursor to the desired location on the monitor to a resolution of one pixel and be able to move the cursor across the single screen, spanning multiple monitors. Spinning the mouse wheel shall allow users to magnify or shrink the text and graphics on the screen.

Each user shall be presented with their own user profile that will permit personalization of their individual “user space”. User profiles shall provide users with the ability to define the windows, rail territory, or applications appear on their screens upon user login. Any “mouse personalization” features (e.g. using mouse wheel to magnify text) shall be capable of being toggled on and off on a per-user basis.

Page 77


4.7.5.1.1 Object or Field Selection

The User shall be able to select an item within a graphical display, text-based display, or menu via a single mouse click action (e.g. positioning the cursor over the item and clicking the mouse), as determined during prototyping.

On non-graphical displays, the User shall be able to change the keyboard focus in the following manner with a single keystroke, subject to user interface prototyping:

a) Move the focus to previous object or field; b) Move the focus to next object or field; c) Move the focus to first object or field; d) Move the focus to last object or field.

Cursor targets on displays shall be sufficiently large to permit rapid selection of the target without excessive movement of the mouse. The size of each display target shall subject to user interface prototyping. An action that triggers the appearance of a pop-up or pull-down menu shall move the cursor within that menu field if the next user step requires cursor selection from that menu.

The ROCC software shall support a rubber banding technique, which allows the User to select a number of co-located devices on the graphical display for control by placing a box around the devices using the mouse. Other techniques of multiple object selection may be proposed for Engineer approval during user interface prototyping:

a) The User shall be provided the capability to select objects of similar type with a rubber banding technique.

b) The User shall be provided the capability to select objects of different type with a rubber banding technique.

Controllable graphic objects or selection fields shall be highlighted in a distinctive manner when they have been selected. Capability shall be provided for Authorized Users to select a graphic object on a graphical display and drag that object to another area on the graphical display. The set of graphic objects that shall provide “drag and drop” capability shall be defined during prototyping.

Authorized Users shall be provided the ability, via a single mouse action, to invoke a pop-up menu or control window that displays all actions that may be taken relative to a controllable graphical or tabular object. A set of parameters shall be presented in pop-up menus appropriate to the item type and operation to be performed. For example, selecting a device for control shall cause a menu of control actions to be presented.

When a user selects the parameter(s) associated with a menu of operations for a desired display item, the requested action shall begin immediately. The ROCC software shall provide the capability for an Authorized User to select the default action associated with the controllable graphic object or selection field via a single mouse action.

4.7.5.2 User Input and Control Actions

There will be several ways for the User to enter information or modify the ROCC software during operation. The ROCC software will perform several reasonability checks on any user input before action is performed on the database or system.

The ROCC software will provide user guidance during each step of a control action. User guidance will be in the form of English text messages, as well as changes in colors of device symbols and changes in menu selection. The User must at all times know the status of his control request and how to remedy an error, should one occur. All colors utilized by the Contractor shall be sufficiently unique as to not cause confusion where users could easily mistake one color for another. All colors utilized shall vary by hue and intensity so that any user with normal color vision will not confuse colors. The colors used throughout the ROCC software displays shall be subject to prototyping.

Page 78


The ROCC software shall respond to all Authorized User input actions and control actions indicating whether the action was accepted, not accepted or pending. When an action is not accepted, the reason for the rejection shall be clearly stated.

The User shall have the capability to end user input or control actions at any time, by selecting a cancel command clearly related to the action being performed. When user input is canceled, the process shall terminate, all data value changes are discarded (original data value(s) remain unchanged), and the associated dialogs and/or menus close.

For multi-step procedures, the ROCC software shall provide user feedback at each step. The ROCC software shall utilize visual indications as a means of providing feedback to Users, such as text messages, color changes to display elements, blinking, and others defined during user interface prototyping.

Display items such as menu items, tabular lists, and graphical representations that are not available for selection at that time shall be “grayed out” and desensitized on the display. The definition and use of function keys and keyboard shortcuts shall be reviewed during prototyping.

4.7.5.3 Data Entry

When text data entry is initiated by an Authorized User, the ROCC software shall automatically establish a separate text-entry cursor at the display location where text entry is to be performed. Display of the mouse may be inhibited while text entry is in progress; in which case, the mouse shall reappear if the mouse is moved.

Enterable data fields authorized for User access shall be highlighted, such that they are uniquely identified when a display is presented. Authorized Users shall be provided the capability to enter a value anywhere within an enterable data entry field and to enter or modify a portion of a data value in an enterable data field.

To ensure that accurate data is accepted and processed, the ROCC software will perform validity checks after each user input or supervisory control interactive procedure. The ROCC software will also check the input fields for validity and consistency. It is acceptable and expected that the same display appear concurrently in multiple windows at multiple consoles. It is not acceptable, however for the ROCC software to accept conflicting data entries from multiple users.

When the User indicates completion of a user-input action on any type of a text-based display, the ROCC software shall check the data entries for consistency and validity to ensure that data is within range, is of the correct data type (integer, alphanumeric), and is within defined data limits.

The ROCC software shall verify all Authorized User entries into forms and dialogs, against appropriate ROCC databases to ensure that valid data has been entered. When the Authorized User indicates completion of the text-based display or action (e.g. clicks “OK”), the data entries are successfully validated, and the action is performed (e.g. data written to the database), the associated dialogs or menu options shall be closed.

4.7.6 Master Time

The Contractor shall utilize the existing WMATA Master Time Source to synchronize the time across all computers within the ROCC software and Master Time Display. The WMATA Master Time Source utilizes an NTP “Network Time Protocol” satellite clock that is installed and maintained by the WMATA IT Neworking Department.

The Contractor shall provide software (e.g. WinDiscovery) and services to synchronize all ROCC software components with the existing WMATA Master Time Source, including all workstations, servers, displays, and terminals.

Master Time Display shall be used to display the time in the OCC operating theater:

a) One Master Time Display shall be located in the OCC at Carmen Turner Facility; b) One Master Time Display shall be located in the OCC at JGB.

Page 79


The Master Time Display shall be synchronized with the WMATA Master Time Source. The Master Time Display will be provided by WMATA, but shall be integrated into the ROCC software by the Contractor. The current system time in 24 hour military time in HH:MM:SS format shall be displayed at all times in at least one monitor for each ROCC Workstation and one instance on the Video Display Wall.

4.8 Alarm Processing Requirements

The ROCC software shall detect and issue an alarm when a specified alarm conditions occur. Alarm processing shall determine the Authorized User(s) to receive the alarm, the Users that are authorized to interact with the alarm, the alarm actions associated with the alarm, and the display and annunciation attributes when alarm conditions are triggered.

Alarm conditions shall include, but not be limited to, the following:

a) Uncommanded changes of state of monitored devices; b) Failure to receive the health status message from each field device within a given defined time; c) Application program generated alarm conditions, (e.g., train backing up alarm, red signal overrun,

etc.); d) Telemetry source communication errors resulting in loss of data; e) Telemetered or calculated value limit violations; f) Hardware or software errors and failures; g) Monitored device alarm conditions; h) Device to external system interface errors and failures.

Where ROCC software devices or devices monitored by the ROCC software operate as redundant pairs or in groups greater than two, each unit of the group shall be separately alarmed, as well as an alarm provided for when all functions of the group are unavailable.

Data communication failures between the ROCC software and devices or device groups (those internal and external to the ROCC software) shall be alarmed separately from failure alarms of the units of the groups.

An Authorized User shall have the capability to define alarm conditions for those devices that are capable of reporting such conditions and for abnormal operating conditions within the ROCC software applications.

An Authorized User shall have the capability to assign specific alarm text, alarm partitions, alarm types to individual alarm conditions.

All alarms shall be recorded and logged as Historical Data immediately upon occurrence, to a millisecond granularity. The complete list of alarms shall be defined by the Contractor, and shall include, but not be limited to, any and all alarms that are specified in this Section. Any alarm condition that may adversely affect the operational availability of the system shall be included.

The Contractor shall develop a comprehensive set of alarm conditions, subject to review and approval by WMATA during Prototyping. The list of Contractor-defined alarms shall be subject to review and approval by WMATA as part of the Software Requirements Specification (CDRL T308).

4.8.1 Alarm Definition

An Authorized User shall have the capability to add, modify and inhibit alarm conditions. All alarms shall be fully configurable. Configuration options for each alarm shall include, but not be limited to, the following:

a) The user(s) to which the alarm is routed. b) Whether the alarm is a visual and/or audible alarm. c) Whether the alarm shall require acknowledgement.

The ROCC software shall include the capability to assign each alarmable condition, including calculated values, non-telemetered data or devices, and data associated with applications functions, to one or more alarm partitions.

Page 80


Alarmable conditions from all RTUs shall be capable of being granular down to the specific RTU point and shall not be limited to a generic “alarm from RTU x”. The ROCC software shall provide the capability for assignment of alarm conditions to multiple partitions and to add and modify the alarm message text associated with an alarm condition.

4.8.1.1 Alarm Partitions

Alarm partitions, or categories, shall group alarms by functional area. The ROCC software shall include a minimum of 16 alarm partitions, including the following:

a) Field Locations (non-reporting); b) Auxiliary Equipment; c) WMATA Central System Equipment; d) WMATA Field Equipment; e) Field Communications Equipment f) Select individual Alarm Point.

The ROCC software shall include the capability for an Authorized User to add, modify and delete alarm partitions. A sample of alarm partitions and alarms is presented below. The alarm list below is in no way to be interpreted as comprehensive and is only a partial list of alarms that must be included in the final ROCC software. The Contractor shall present a comprehensive, complete list of alarms to be implemented in the ROCC software as part of the SRS, as specified elsewhere in this Section.

4.8.1.1.1 Field Based Alarms

The ROCC software shall indicate alarms received from the code system including as a minimum:

a) AC Power Off; b) DC Power Off; c) Ground Detected; d) Smoke Condition; e) Intrusion detection; f) Bulb out – signal light or amber light; g) Code Line A Off; h) Code Line B Off; i) Loss of Remote Control capability; j) ATC Circuit Power Failure.

The ROCC software shall include system diagnostics as a component in support of field based alarms. Such diagnostics shall permit ROCC software users to ascertain the specific field environment that could have caused the alarm.

4.8.1.1.2 CTC Device Alarms

All field circuited alarms shall be detected and indicated on displays and in alarm lists. CTC alarms shall include but not be limited to:

a) Field Control Failures; b) Field Indication Failures; c) Server and client failures; d) Field “Not Reporting” failures; e) Code Line Failures.

4.8.1.1.3 SCADA Device Alarms

SCADA system alarms shall include but not be limited to:

a) 3rd Rail energization change of status; b) 3rd Rail Communication Failures; c) Tunnel vent fan change of status; d) Tunnel vent fan Communication Failures;

Page 81


e) TVS fan sequencing errors; f) Drainage pump change of status; g) Drainage pump Communication Failures; h) Field Control Failures; i) Field Indication Failures; j) Field “Not Reporting” failures.

4.8.2 Alarm Presentation

Each alarm shall have visual and/or audible attributes as determined and assigned to alarms during user interface prototyping.

4.8.2.1 Alarm Annunciation

The ROCC software shall include no fewer than four distinct audible annunciation alarm tones. One distinct audible annunciation alarm tone shall be assigned to each of the three alarm types – Reactionary, Advisory, and System.

A fourth distinct audible annunciation alarm tone shall be reserved for assignment to “special” or “critical” alarms at WMATA discretion. A potential application for the fourth tone might be for an alarm that WMATA personnel want to ensure is noticeable as a critical, out of the ordinary event, such as a signal overrun.

The ROCC software shall include the capability to define and assign additional distinct audible annunciation alarms at a later time of WMATA choosing. Later addition of distinct audible annunciation alarms shall be capable of being performed by WMATA personnel without the need for assistance from the Contractor or any other outside agency.

Any individual alarm partition shall be able to be silenced at WMATA discretion. Any individual alarm shall be able to be silenced at WMATA discretion. Audibly silenced alarms shall still be indicated on OCC Displays and logged as normal.

4.8.2.2 Alarm Visual Attributes

The ROCC software shall provide the ability for ROCC software Displays to flash devices and symbols that have the ability to be alarmed when an alarm becomes active. Visual presentation of alarms shall include graphical symbols and/or textual descriptions on the ROCC software Displays if an alarm is configured as such. The visual attributes for this icon for the alarm included in the ROCC software and assignments shall be defined subject to Prototyping.

4.8.2.3 Alarm Types

The alarm type of an alarm condition establishes the alarm presentation attributes (visual and audio annunciation) as well as Authorized User interaction with the alarm:

a) An Authorized User shall have the capability to define the attributes of each alarm type. b) An Authorized User shall have the capability to assign only one alarm type to each alarm condition. c) The ROCC software shall ensure that every alarm condition is assigned at least one alarm type. d) All alarms shall be designated as being one of three types of alarms, Reactionary, Advisory, or System. e) Reactionary (Type R) – Reactionary alarms require prompt attention since they are generated by some

unusual event.

Advisory (Type A) – Advisory alarms are generated by events which are not as critical as Reactionary alarms, but still require attention. System (Type S) – System alarms appear when there is an error in the system that is less critical than Advisory alarms for the operator.

4.8.2.4 Alarm States

For each alarm, the ROCC software shall process the following alarm states:

a) Alarmed but not acknowledged;

Page 82


b) Alarmed and acknowledged; c) Not in alarm.

4.8.3 Alarm Detection

Upon detection of an alarm condition, the alarm shall be highlighted on all associated ROCC software Displays, including but not limited to the Alarm Management Window and Track Display (where configured). The alarm state of a field device shall be presented on the Track Display in association with the graphic object that represents that device for all alarms that are configured to do so. All alarm conditions shall be presented on the Alarm Management Window.

Upon detection of an alarm condition the ROCC software shall generate an audible annunciation at each ROCC Workstation where an Authorized User responsibility for responding to the alarm condition. Each occurrence of an alarm condition and return-to-normal condition shall result in an alarm message being logged to the Alarm Management Window.

4.8.4 Alarm Interactions

Alarm interactions shall only be permitted by Authorized Users which are logged-on into the ROCC software.

4.8.4.1 Alarm Acknowledgment

The ROCC software shall provide Authorized Users, assigned responsibility for the alarm, the ability to acknowledge the alarm. An alarm shall be acknowledged by Authorized User selection of an alarm acknowledge command when the item in alarm is selected from:

a) Any display showing the device or value in alarm (e.g. Track Display); b) Any display showing the alarm message (e.g. Alarm Management Window).

When an alarm message has been selected on a display showing the alarm message, a visual indication of the alarm message selection shall be provided. The visual indication shall be subject to Prototyping.

Alarm Acknowledgement shall cause the ROCC software to change the visual highlighting of the alarm condition to the acknowledged state on all displays on which the alarm appears and to turn off the audible annunciation, if present. Alarms shall not require multiple acknowledgements on different displays or from different Authorized Users.

The ROCC software shall provide Authorized Users the capability to select individual alarms for acknowledgment, select multiple individual alarms for acknowledgement, or select multiple alarms by partition from the Alarm Management Window.

When a return-to-normal message is acknowledged, the ROCC software shall delete both the return-to-normal message and its associated message in the Alarm Management Window unless the alarm type requires manual deletion. The remaining messages in the Alarm Management Window shall be realigned to present a continuous listing of alarms.

4.8.4.2 Alarm Message Deleting

Authorized Users shall have the capability to delete an acknowledged alarm message from the Alarm Management Window.

The ROCC software shall provide Authorized Users the capability to delete specific acknowledged alarms from their Alarm Management Window or multiple alarms from their Alarm Management Window. Following deletion of an alarm message(s) from the Alarm Management Window, the remaining messages on the Alarm Management Window shall be realigned to present a continuous listing of alarms. The ROCC software shall provide Authorized Users the ability to select individual alarms for silencing, select multiple alarms for silencing or select all audible alarms at their console for silencing.

Page 83


Deleting an alarm message from the Alarm Management Window shall not cause the alarm condition highlighting of any value or device on any other OCC Display to change or cease. Deleting an alarm message from the Alarm Management Window shall not cause the alarm condition to be removed from the Historical Data log.

4.8.4.3 Alarm Inhibit/Enable

The ROCC software will provide the ability to inhibit alarms for any alarm condition at the User level and at a global level. Alarm inhibiting of an alarm condition at the User level shall only affect the alarm presentation of that occurrence of the alarm condition at that User’s ROCC Workstation while currently logged on. Alarm inhibiting at the global level shall inhibit all alarm presentation of the selected occurrence of the alarm condition for all Users.

The ROCC software shall allow Authorized Users to inhibit alarm processing for a device, system value, state, or other alarmable condition at their ROCC Workstation. Inhibiting of alarm processing at the User level for a specific alarm condition shall not affect the calculation, storage, or other functional processing of the device or value associated with the suspended alarm condition.

a) For example, if an Authorized User inhibits a track circuit failure alarm for a given track circuit, not all track circuits in the Authorized User’s territory shall be inhibited, nor shall the given track circuit be inhibited at another User’s console.

b) Authorized Users shall have the capability to select individual alarm conditions, multiple alarms by partition, multiple alarms by selection, or all alarm conditions for local inhibiting.

c) Inhibiting a specific alarm condition at a User level shall not affect the processing of the alarm condition (i.e. track circuit failure of other track circuits) at another ROCC Workstation (i.e. the same track circuit failure at other workstations).

d) Inhibiting a specific alarm condition at a User level shall not affect the logging of the alarm in the Historical Data database. User-inhibited alarms shall still be logged.

e) Alarm inhibiting at the User level shall cause the ROCC software to cease all further alarm presentation for the alarm condition including symbol flashing, audible annunciation and highlighting at the User’s ROCC Workstation.

f) Alarm inhibiting at the User level shall cause the ROCC software to present an alarm inhibit indicator or quality code next to the alarmed device or value for which is applies on every display (displayed or printed) containing the item at the User’s ROCC Workstation.

g) Alarm inhibiting at the User level shall cause the ROCC software to present a message identifying the inhibited alarm on the Alarm Inhibit Summary Display at the User’s ROCC Workstation and at the ROCC Workstation of the User’s Supervisor.

h) The inhibiting of an alarm condition shall remain in effect until the User logs off or the User re-enables alarm processing of that alarm condition.

i) Alarm enabling at the User level shall cause the ROCC software to resume normal alarm processing and presentation of the alarm condition at the User’s ROCC Workstation.

j) Alarm enabling at the User level shall cause the ROCC software to remove the inhibit message from the Alarm Inhibit Summary Display at the User’s ROCC Workstation and the ROCC Workstation of the Users Supervisor.

k) Alarm enabling at the User level shall cause the ROCC software to remove the alarm inhibit indicator or quality code from the value or device on all displays at the User’s ROCC Workstation that include the item.

The ROCC software shall allow Authorized Users to inhibit alarm processing for an alarm condition globally. Inhibiting of alarm processing shall not affect the calculations, storage, or any other function performed on the inhibited value or device associated with the alarm condition. For example, if an Authorized User inhibits the alarm for a specific track circuit globally, the alarm processing of that particular track circuit on all displays and reports will be inhibited:

a) Authorized Users shall have the capability to select individual alarm conditions, multiple alarms by partition, multiple alarms by selection, or all alarm conditions for global inhibiting.

b) Inhibiting alarm processing of an alarm condition globally shall remain in effect until an Authorized User turns off the alarm inhibit.

Page 84


c) Alarm inhibiting shall cause the ROCC software to cease all further alarm presentation for the alarm condition including symbol flashing or highlighting on all WMATA displays.

d) Alarm inhibiting shall cause the ROCC software to present an alarm inhibit indicator or quality code next to the alarm condition on every display and report containing the item.

e) Alarm inhibiting shall cause the ROCC software to present the inhibited alarm on the Alarm Inhibit Summary Display for all Users.

f) Inhibiting a specific alarm condition at a global level shall not affect the logging of the alarm in the Historical Data database. Globally-inhibited alarms shall still be logged.

g) The ROCC software shall provide Authorized Users the ability to re-enable alarm processing for the alarm condition globally.

h) Alarm enabling of an alarm condition globally shall cause the ROCC software to resume normal alarm processing and presentation at all User ROCC Workstations.

i) Alarm enabling of an occurrence of an alarm condition globally shall cause the ROCC software to remove the inhibit message from the Alarm Inhibit Summary Display at all User ROCC Workstations.

j) Alarm enabling of an occurrence of an alarm condition globally shall cause the ROCC software to remove the alarm inhibit indicator or quality code from the alarm condition on all displays.

Alarm inhibiting (at the User level and globally) shall cause the ROCC software to log the time alarming was inhibited and by whom on all affected Alarm Inhibit Summary Displays and in the Historical Data database.

Alarm enabling (at the User level and globally) shall cause ROCC software to log the time the alarm was enabled and by whom in the Historical Data database. The method of inhibiting and enabling alarms at the User level and global level shall be developed during Prototyping.

The ROCC software shall incorporate a means of identifying and automatically inhibiting multiple alarms caused of the same alarm condition and automatically inhibiting multiple alarms of the same condition and/or recurring alarms of a condition that have been acknowledged by an Authorized User. The complete set of alarm conditions that shall be available for alarm inhibiting shall be defined as part of Prototyping.

4.8.4.3.1 Alarm Mitigation

The preponderance of alarms in the existing RROCC software poses a problem for WMATA rail operations that the ROCC software shall address and correct. An excessive volume of alarms occur incessantly in the existing RROCC software such that the resultant alarm log has become so much ‘noise’ and of little use to rail superintendents.

The Contractor shall cooperate with WMATA during System design to identify a practical means to define and implement alarm management with the goal of providing a flexible alarm management system that permits WMATA to define and manage alarms so that important information is flagged and reported without creating an unusable flood of data.

4.8.4.4 Audible Alarm Silencing

Authorized Users shall have the capability to silence individual alarm conditions multiple alarms by partition, multiple alarms by selection, or all audible annunciation of alarms at their ROCC Workstation. Audible alarm silencing shall remain in effect until the User restores the audible alarm annunciation. The audible alarm silencing shall be performed at the User ROCC Workstations.

4.8.5 Alarm User Interface

4.8.5.1 Alarm Management Window

The Contractor shall supply an Alarm Management Window as part of the ROCC software. Characteristics of the Alarm Management Window shall include, but not be limited to, the following:

a) The Alarm Management Windows shall be dynamically updated to represent the real-time state of the alarm condition.

b) A manual “refresh” of the Alarm Management Windows by Users shall not be required but shall be available for on-demand refresh.

Page 85


c) Authorized Users shall have the capability to sort/filter the information of the Alarm Management Windows by the following criteria and combinations of criteria: • Date/time; reverse chronological is the default; • Alarm partition; • By location; • Alarm state.

d) The window shall list information about each alarm. Alarm information to be presented shall include:

• Date and time; • Alarm type; • Location; • Acknowledgement status; • Device ID; • Alarm text, or description.

For Reactionary and Advisory alarms the window shall also show the date and time associated with an alarm flash until the alarm is acknowledged. The buttons labeled Reactionary, Advisory, and System shall allow an Authorized User to choose any or all types of alarms to view in the window. By default, all alarm types shall be selected.

The buttons labeled Acknowledged and Unacknowledged shall allow the authorized user to view only the unacknowledged alarms, only the undeleted acknowledged alarms, or both types of alarms at the same time. By default, both buttons shall be selected:

a) Unacknowledged alarms shall always be visible to the authorized user. b) The Alarm Management Window shall provide the authorized user with an Acknowledge button. c) The Acknowledge button shall acknowledge that the Authorized User has seen the selected alarm(s),

and shall turn off the audible alert for that alarm. d) Alarms shall be automatically deleted and removed from the display when acknowledged and the

alarm condition no longer exists. e) The Alarm Management Window shall provide an Authorized User with an Inhibit button. f) The Inhibit button shall move the selected alarm from the Active Alarms window to the Inhibited

Alarms window and shall eliminate any newer identical alarms for the same device from the Active Alarms window.

g) The inhibit function shall require that an alarm be acknowledged prior to being inhibited. h) Upon being inhibited, the original alarm shall remain in effect until being properly acknowledged and

future occurrences of the alarm shall be inhibited. i) Inhibited alarms shall continue to be logged to the Historical Data database. j) Alarm inhibits shall stay in effect until the authorized user enables the inhibited alarm, until eight

hours have passed, or until there is a new logon. k) The Alarm Management Window shall provide the authorized user with a Delete button. l) The Delete button shall remove the selected alarm(s) from the display. Unacknowledged alarms cannot

be deleted. m) The Alarm Management Window shall provide the Authorized User with a GoTo button. n) The GoTo button shall cause the display to pan to the location of the selected alarm in the Active

Alarms window. o) Upon System logon, any unacknowledged alarms routed to the user shall be presented to the user for

acknowledgement.

Alarm messages shall be presented in chronological order by default on the Alarm Management Windows.

When alarm messages do not fit on a single displayable page of the Alarm Management Window, multiple pages shall be provided. Each Alarm Management Window shall be capable of displaying a minimum of the most current 500 alarm messages. If an Alarm Management Window becomes full, the oldest acknowledged messages shall be automatically removed from the display and the newest messages shall be added.

Page 86


Element highlighting (developed during display prototyping) shall be provided to distinguish unacknowledged alarms from acknowledged.

Element highlighting (developed during display prototyping) shall be provided to distinguish alarms from a previous service day(s) from the current day’s alarms. The Alarm Management Windows shall provide the full text of alarm message. Alarm message text for each alarm shall be determined during user interface prototyping.

The ROCC software shall include the capability to attach a textual comment to one or more alarm messages. The text comment shall be up to 80 characters in length. The text comment shall have the capability to be modified and deleted by an Authorized User. Text comments shall be created, modified and deleted only by Authorized User with alarm interaction capability.

4.8.5.2 Alarm Inhibit Summary Display

The ROCC software shall maintain an Alarm Inhibit Summary Display that lists alarm conditions for which a User has inhibited alarm processing. The Alarm Inhibit Summary Display shall be an information-only display; no User interaction shall be associated with it.

4.8.5.3 Alarm Definition Display(s)

The ROCC software shall include the displays necessary to define and assign alarm partitions, types, conditions, messages.

4.8.6 Alarm Logging

Information logged to the Historical Data database upon occurrence and available for query, for each alarm shall include, but not be limited to, the following:

a) Alarm name; b) Alarm class – Reactionary, Advisory, or System; c) Time & Date of alarm notification; d) Time & Date of alarm acknowledgement (if applicable); e) Identity of person who acknowledged alarm (if applicable); f) Specifics of the alarm (if applicable) including, but not limited to, the following:

• Nature of the alarm (e.g. threshold exceeded; failure; reinstatement; etc.); • Device(s) involved; • Location(s) involved.

The data returned as a result of queries of alarms, including all result sets represented above, shall be available to authorized users for reporting purposes.

4.8.7 Alarm Failure Handling

The ROCC software shall notify an Authorized User when a requested change to alarm limits for telemetered, calculated, and program generated alarms is not valid. No change to the limits for alarm conditions shall be made to the ROCC software when invalid data exists.

4.9 Access Control Processing

The Access Control function shall regulate the secure access to the ROCC software. Security shall be provided in the form of log-on authentication, function access assignments.

Territories or Locations (portions of the WMATA monitored system) can be assigned to workstations or user classifications and displayed onto multiple monitors.

Page 87


4.9.1 Function Access Assignments

All ROCC software functions shall be assignable to any or all user classifications and any or all workstations within the Primary ROCC or Secondary ROCC. The ROCC software shall have an Authorized User-assignable default mode that establishes predefined function access assignments for each RROCC Workstation and each user classification.

Default function assignments shall be restored upon request of an Authorized User. Default function access assignments when invoked shall be in effect until function assignments are modified by an Authorized User.

Each User shall, upon log-on, be permitted access to ROCC functionality according to the intersection of the functionality assigned to that User within their user classification and to the RROCC Workstation where the log-on occurs.

Any modification to function access assignments by an Authorized User shall take effect immediately for all affected user classifications and ROCC Workstations. All ROCC software functions shall be separately assignable to individual user classifications and workstations. The Contractor shall define the complete list of functional access partitions within the OCC Software Requirements Specification for Engineer review and approval.

Authorized Users shall have the capability to modify function access assignments for selected Authorized Users currently logged-on to the ROCC software. Function access added or removed for the selected Authorized User shall remain in effect until the assigned User logs out or is modified by an Authorized User.

Access to individual OCC functions shall be assignable as monitor or view-only access, such that Authorized Users can monitor the status of the function but not perform control. Access to individual OCC Displays, dialogs, forms, and reports shall be assignable as review or view-only access, such that assigned Users can view the contents of the dialogs, displays, forms and reports but not modify contents.

Access to individual OCC functions shall be assignable as full control access to OCC functions, such that Authorized Users can interact with specific functions, displays, dialogs, forms, and reports, including modifications to states, manual data entry, and control selection and execution. The ROCC software shall disallow modification to function access assignments that would leave one or more functional capabilities unassigned to any workstation and user classification.

4.9.1.1 System Area Definition and Assignment

WMATA rail territory shall be partitioned into areas in order to facilitate control and monitoring of the Train Control along the railway. The ROCC software shall provide all necessary facilities for WMATA to be able to divide rail territory into smaller logical territories for purposes of assigning specific areas of territory to specific workstations and by user classifications.

The basic unit of area definition shall be the interlocking, including intermediate locations assigned to interlockings. Partitioning may occur where the interlocking areas are separated by back-to-back signals, or where physical signals do not exist such as between the two ends of a crossover. Interlockings in which OCC software partitioned sub-interlockings are to be provided are indicated on the Contract Drawings. Each interlocking and sub-interlocking shall be a separately assignable control territory.

Interlocking limits of control shall be as defined by the field Train Control Systems. Approximate limits of control for each interlocking are depicted in the Contract Drawings. The locations between interlockings shall be associated with the bounding interlockings.

An Authorized User shall be able to associate and redefine the locations between interlocking with bounding interlockings. The initial definition of divisions of the Locations between interlockings and association with bounding interlockings will be provided by WMATA.

Page 88


4.9.2 Area Assignments

The ROCC software shall support the assignment of areas for signal control by workstation and by user classification. The ROCC software shall allow users to login onto multiple workstations. All controls requested from each workstation shall be logged, including:

a) Workstation; b) User; c) Device; d) Location; e) Requested control.

Each User shall, upon log-on, be permitted access to the area assigned to the ROCC Workstation where they are logged-on. The ROCC software shall have an Authorized User-assignable default mode that establishes predefined area assignments for each ROCC Workstation set up for Primary OCC or Secondary OCC Operators:

a) The predefined area assignments for the ROCC Workstation shall be continuously displayed on the

workstation monitors displaying the entire controlled WMATA system. b) Predefined area assignment defaults when invoked shall be in effect until modified by the System

Administrator.

The ROCC software shall limit routing and switch control authorization for each interlocking or sub-interlocking in the way that only the workstation that initiated the start of a control can finish the control. i.e., the workstation that initiated an entrance using NX can be the only workstation that can initiate an exit for that set of controls.

The method for limiting assignment and automatically re-assigning routing and switch control authorization shall be demonstrated for Engineer approval during prototyping. The ROCC software shall provide indication to Authorized Users of routing and switch control responsibility on all displays, subject to User interface prototyping.

4.9.3 Remote Access

The ROCC software shall support the assignment of areas for signal monitoring by remote location. Specific WMATA-chosen locations outside of either the Primary ROCC or Secondary ROCC shall be granted access to the ROCC software. Such extra-ROCC access shall be limited to the WMATA-chosen locations only, governed by location and not by user ID or user classification. The Contractor shall propose to WMATA a secure solution to remote access of the ROCC software. The Contractor shall research the existing WMATA communications network and propose a network solution to provide secure remote access. The Contractor shall include a network diagram in the Contractor technical proposal to illustrate the proposed network solution to secure remote access to the ROCC software. Train Control System operation via remote access shall be monitoring (i.e. read-only) access exclusively. It shall not be possible to control WMATA rail traffic from a remote access ROCC software workstation, with the exception of local control panels at the wayside.

4.9.4 Log-on/Off

ROCC software Users shall be required to log-on to the ROCC software by entering a valid User name and a password. The log-on/log-off function shall be an application level log-on/log-off for ROCC software access at the particular ROCC Workstation. Execution of log-on/log-off shall not affect any ROCC software application processes except as applicable at the affected ROCC Workstation.

Page 89


Only a single ROCC software log-on shall be required for User access to all functions (subject to function access right assignments). The log-off function shall not cause the ROCC Workstation processor to change state, i.e., shutdown, standby, operating system log-off.

The ROCC software shall provide the capability for a User to perform a log-on / automatic log-off as part of a shift change, on any ROCC Workstation. An Authorized User’s log-on shall automatically log-off the currently Authorized User without any acknowledgement from the current user.

Log-on/log-off shall be subject to user interface prototyping. The log-on function shall include the Controller’s Notes feature.

Controller’s Notes are a log that shall be maintained on each active ROCC software user of significant operational notes that need to be tracked and passed on to the next user who will assume control of the active user’s territory upon shift change.

The Controller’s Notes function shall encapsulate the current status of the railroad for a new user logging-on to the ROCC software in a single place and in a convenient and consistent format and which the user must acknowledge and accept before log-on can successfully be completed.

Controller’s Notes shall include, but not be limited to, active alarms, operational orders, slow orders, active Roadway Worker Protection areas, or active Worker Ahead Warning System areas.

The complete list of significant operational notes that is maintained per user and make up the Controller’s Notes shall be determined by the Contractor in consultation with WMATA personnel during system design. As items from the Controller’s Notes are completed (e.g. an alarm condition corrected, or an operational order expires), they shall be removed from the Controller’s Notes in a real-time fashion.

Upon log-on, the user signing onto the ROCC software shall be obligated to accept and acknowledge any pending Controller’s Notes for the territory being assumed. The ROCC software shall present the user logging-on with the list of pertinent Controller’s Notes and enforce the acknowledgement of pending Controller’s Notes.

The log-on process shall not be successfully complete until pending Controller’s Notes have been acknowledged by the user who is attempting to log-on.

The ROCC software shall provide the capability for an Authorized User to log-off at any time, provided that all Rail Territory is presently under control by another Authorized User. A concurrent log-on by another User is not required for the Authorized User to log-off that same workstation, provided that the log-off does not leave Rail Territory uncontrolled.

An ROCC Workstation that has no Authorized User logged-on shall display Default as the current User with one of the workstation displays. The ROCC software shall execute only log-on functions at an ROCC Workstation at which no User is logged-on. No ROCC functions other than log-on shall be executing at a workstation until a successful log-on has been completed. The ROCC software shall not display the Log-on dialog box until the assigned requested using hot keys (I.E. CTRL – L). Multiple simultaneous log-ons shall not degrade system performance.

4.9.5 Active User List

Log-on to the ROCC software shall only be permitted by currently active WMATA employees. Log-on identities shall be checked against WMATA active users list. Upon removal of a user name from the WMATA active users list, that name and all associated log-on rights shall automatically and immediately be removed for the list of possible ROCC software log-on identities.

If Contractor and WMATA come to a mutual design decision to tie the ROCC software to the WMATA Corporate Network, then the ROCC software shall use WMATA’s Active Directory (AD) directory service to authenticate and authorize all user log-ons.

Page 90


4.9.6 User Classifications

A user classification is a way to group Users such that function access assignments can be more easily applied. User classifications correspond to a user’s job function. Each User is assigned a user classification. The ROCC software shall utilize user classifications to define the level of authorization to assign to a group of Users.

At a minimum, 60 user classifications shall be supported by the ROCC software. The complete set of user classifications, subject to prototyping, shall include the following:

a) Train Controller; b) ROIC Communication Specialist; c) ROIC Liaison; d) Car Maintenance Controller; e) ELES Dispatcher; f) ELES Supervisor; g) MOC Supervisor – Power; h) MOC Supervisor – Communications; i) MOC Supervisor – Train Control; j) MOC Service Dispatcher; k) MOC Assistant Superintendent; l) ROC Assistant Superintendent; m) ROC Superintendent; n) System Administrator; o) Trainer; p) Trainee; q) System Support; r) Maintainer; s) 30 Spares or Future

Capability shall be provided for an Authorized User to be able to assign priorities to user classifications such that some user classifications have precedence over others for the same functions assignments.

4.9.7 Access Control User Interface

4.9.7.1 Function Assignment Display

The ROCC software shall include Function Assignment Displays that provide Authorized Users the capability to review and modify function access assignments to user classifications and to ROCC Workstations.

4.9.7.2 Log-On/Log-Off Displays

The ROCC software shall include a Log-on Display that provides Authorized Users the capability to access the system, including during a concurrent log-on/shift change. The ROCC software shall include a Log-off Display that provides Authorized Users the capability to initiate the end of a session, including during a concurrent log-on/shift change. The Log-on and Log-off Displays shall provide Users the ability to manually input a User name and password.

4.9.7.3 User Administration Display

The ROCC software shall include User Administration Displays that provide an Authorized User with the capability to add, delete, or modify User definitions. Each User definition shall minimally include full name, User name, password, user classification, job title, limitation on hours and timeframes of usage, and other information determined during prototyping.

4.9.7.4 User Classifications Display

The ROCC software shall include User Classification Displays that provide an Authorized User with the capability to:

a) Define, modify and delete user classifications;

Page 91


b) Define user classification priorities.

The User Classification Displays shall provide an Authorized User the capability to modify the assignment of Users to the user classification.

4.9.8 Access Control Failure Handling

The ROCC software shall provide a User advisory when an attempt to modify function access assignments would result in one or more functional capabilities being unassigned to a ROCC Workstation and user classification.

The ROCC software shall provide a User advisory and cancel the log-out function when an Authorized User attempts to log-out such that areas of the rail territory or functional capabilities would be unassigned to a ROCC Workstation and user classification.

The ROCC software shall provide a User advisory and cancel the territory reassignment operation when an Authorized User attempts to reassign a territory that would result in an area of the rail territory being unassigned to a ROCC Workstation and user classification.

The ROCC software shall detect all log-in attempts and alarm any 5 successive failures to log on to a specific ROCC Workstation within an Authorized user-defined time period.

The ROCC software shall detect all log-off attempts during a shift change operation and alarm any 5 successive failures at a specific ROCC Workstation.

4.9.9 Modifications to Access Control rights and privileges

The Contractor shall develop the software, policies, and procedure to ensure the security of the database that control user’s rights and privileges. Changes to the Access Control database shall require two factor authentication and two people must approve the changes at the same time.

4.10 Administration and Maintenance Processing

4.10.1 Database Management

4.10.1.1 Database and Database Management

The database and database management function shall manage the creation of display symbols and their behavior within all databases that will be part of the ROCC software. The Contractor shall supply the ROCC software Database, which shall consist of all the component databases as described herein.

The ROCC software Database shall be a dedicated computer processing capacity that supports an on-line Relational Database Management System (RDBMS) for instantaneous data access, retrieval and reporting. An RDBMS provides for the generation of statistical, database management, operational and other reporting capabilities from the data that is retained.

Database engine selection shall be undertaken with full knowledge of existing WMATA information systems, including the existing operating environment. The database engine that is ultimately selected shall be a standard COTS product, and shall be adaptable for use with other WMATA databases. Therefore, the ability for data exchange between the ROCC RDBMS and other WMATA RDBMS is required, in native format or via standard COTS conversion methods. It shall not be acceptable for the ROCC software Database to be implemented using a Contractor-developed “homegrown” proprietary database solution.

The ROCC software Database shall be an Oracle or SQL Server product, unless otherwise approved in writing from WMATA:

a) WMATA has an active, unlimited license with Oracle for use of Oracle databases throughout WMATA properties.

Page 92


b) The active, unlimited license that WMATA has with Oracle is available to the Contractor for use at no charge. If the ROCC software is implemented using Oracle as the ROCC RDBMS, Oracle will be available at no cost to the Contractor.

The Contractor shall be responsible for demonstrating the interoperability between the chosen ROCC RDBMS and other WMATA RDBMS. The selected RDBMS shall contain all of the tools to support on-line database maintenance, electronic form generation, database administration functions and database reports.

The Contractor shall be responsible for ensuring that the chosen RDBMS includes tool(s) that provide the end user with the ability to monitor database performance and enable WMATA to modify the database after initial implementation for the purpose of database optimization.

Such optimization tool(s) shall include, but are not limited to, the ability to ascertain, display and modify the database schema. Another required optimization tool shall be the ability to run queries and objectively measure database performance via benchmarks that are reported by the query tool.

If the selected RDBMS does not include such optimization tools, then the Contractor shall be obligated to supply a separate third-party product to provide the required functionality. The selected RDBMS shall have an efficient data-integrity architecture that provides a universal interface to the data is set oriented and eliminates the need to specify access paths.

The selected RDBMS shall utilize SQL, eliminating the need for separate data definition and data manipulation languages. The selected RDBMS shall be capable of being accessed through at least two processors as a safeguard against potential CPU failure, and shall provide an automatic roll-back feature.

Redundancy of the RDBMS server shall be accomplished through designed failover. Regardless of the machine that is serving the RDBMS, querying, reporting, playback and all other features shall remain fully functional and available at all times.

The Contractor shall ensure that the ROCC software shall lose absolutely no data in the event of an RDBMS server failure. Maximum flexibility in report generation is required through the use of standard, commercially available software utilities for relational database management, sorting, merging, report writing and random and indexed accessing.

The Contractor shall provide an ROCC software Database, an RDBMS that shall integrate all system component reporting in one location. The ROCC software Database shall incorporate all SCADA, train control, graphic display devices and all other ROCC software reporting.

The ROCC software Database RDBMS shall be easy to modify, new reports shall be easy to format and prepare, data integrity shall be maintained, and the system shall be easily expandable. Expansion of the ROCC software Database shall require the addition of minor hardware components such as disk drives and minor software changes only.

Ease of Modifying Fields – The ROCC software Database RDBMS shall provide the capability to easily add, delete, or modify data elements, element attributes, data fields and data records. Changes or additions to the RDBMS shall not require that the ROCC software be shut down or restarted in order for changes to take effect in the on-line production ROCC software environment.

4.10.1.1.1 Data Handling

All data shall be consistently formatted and stored in a manner that is consistent with WMATA MIS department guidelines:

a) The Contractor shall be responsible for ascertaining any and all WMATA data guidelines that are applicable at the time of the ROCC software implementation, either through review of printed WMATA material and/or interviews of WMATA MIS department personnel.

b) The Contractor shall ensure that the appropriate relationships are established between the data elements. One-to-one, one-to-many, many-to-one and many-to-many relationships shall be established.

Page 93


c) All transaction data from the on-line system shall be collected and stored in the ROCC software Database. As data is prepared for RDBMS storage, the data shall be verified for accuracy.

d) The ROCC software Database shall conform to ANSI/X3.135-1986 Standard Database Language SQL.

4.10.1.1.2 Database engine

The Contractor shall deliver the ROCC software Database as a portion of the ROCC software, fully populated with data as defined in this Section and ready for revenue train service through the WMATA Rail Territory.

The database engine that is ultimately chosen for use as the ROCC software Database shall be a standard COTS product, and shall be compatible with other WMATA databases, and capable of exchanging and/or sharing data with these databases. It shall also support the use of Structured Query Language:

a) The ROCC software Database shall be a COTS RDBMS residing on the ROCC software Database Servers.

b) The database products shall be identified in the ROCC Software Development Plan (SDP) (CDRL T305), subject to the approval of WMATA.

c) All versions of the ROCC software Database and associated modules shall be the latest version unless approved by WMATA.

d) The ROCC software Database shall not be an internally developed in-house product of the Contractor.

The ROCC software Database shall be a dedicated computer process that supports an on-line RDBMS for the purpose of storing, retrieving, accessing and reporting ROCC software-related data. The ROCC software Database shall be properly structured for ease of use, accuracy, data security and the ability to establish “one-to-one,” “one-to-many,” “many-to-one,” and “many-to-many” relationships.

The ROCC software Database shall be delivered equipped with, capable of, and fully providing and supporting the following functions:

a) On-line database maintenance; b) Forms generation; c) Database administration functions; d) Database reports.

The ROCC software Database shall manage all data using a set of System databases, including a Global Database for management of initialization data and non-real time data, and Run-Time Databases for all system real-time data.

The Global Database shall contain all structure definitions and initialization data necessary to support the functional requirements of the ROCC software. The Contractor shall implement the Global Database. Real-time application and processing data shall be managed in the Run-Time Databases.

The ROCC software shall include consistent, coordinated procedures to manage and access the Global Database regardless of the location of the data or the residency of ROCC software Database Management functions.

The delivered ROCC software Database shall be sized to handle all the points required for the ROCC software plus an additional 50% expansion.

The Contractor shall be responsible for implementing the ROCC software Database structure and deriving the initial data required for all functions specified in this Specification.

The Contractor shall perform complete verification and validation of the ROCC software Database components as part of the comprehensive testing program defined in Section 6.

The ROCC software shall provide the capability for an Authorized User to interact with the Database Management functions described herein, interactively from any ROCC software Workstation.

Page 94


4.10.1.2 Database Management

The Database Management tools and applications necessary to generate, integrate, and test the ROCC software Database shall be delivered with the ROCC software.

The Database Management function shall include software utilities that produce listings of database elements by point name and determine how these database elements are being used within the ROCC software:

a) The Database Management function shall include software utilities to find all uses of a point name in displays, reports, and application functions.

b) These search utilities shall be used to find and revise name references when a point name is changed. c) The Database Management function shall include the means for an Authorized User to graphically

produce a data map/data model that depicts all database tables with their relationships.

It shall be possible for multiple Authorized Users to edit the database concurrently, protected by record-level locks. The Database Management function shall provide recovery features in the event the database becomes corrupted or off-line.

The Database Management function shall enable an Authorized User to:

a) Backup the entire database; b) Backup only changed entries; c) Recover a database; d) Restart a database.

The Database Management function shall support full backup and incremental backups of the ROCC software at time periods (e.g. daily, weekly) configurable by an Authorized User.

Execution of the Database Management function in any processor of the ROCC software shall not interfere with the updating of each processor’s Run-Time Database.

The database structure shall be defined and modified through SQL-based generating and editing procedures.

The Database Management function shall provide the capability for an Authorized User to modify the database schema, data files, records, fields and stored procedures without additional database coding or source code modifications.

Extensive reasonability, integrity, and referential integrity checks (e.g. ensure all data is linked and ensure data falls within a defined range) shall be made on user entries to detect errors at the time of entry.

The Database Management function shall modify ROCC software data by interfacing with all database structures and have access to all portions of a database regardless of where it is stored. The location of database items shall be transparent to the user performing database maintenance.

The Database Management function shall provide the capability to resize the entire database or a subset of the database and to redefine the structure of any portion of the Global Database.

4.10.1.2.1 Data Point Definition

All Database Management function data shall be identified by unique data point names within the ROCC software databases. All references and linkages to any database point shall be through the use of the data point name. Where a distributed database is implemented, the residency of the database item shall be transparent to the application.

The Database Management function shall provide the capability to add, modify, and delete:

a) a telemetered point within the Global Database; b) a data source (e.g., FCU or data link) within the Global Database; c) a local I/O point within the Global Database;

Page 95


d) a non-telemetered point within the Global Database; e) a calculated point within the Global Database; f) an application program data within the Global Database

The Database Management function shall provide the capability to create new database attributes and new database types within the Global Database. All newly defined points shall be initially presented to the user with default values for all parameters and characteristics where defaults are meaningful. The function shall provide the capability to initialize a new database point description from an existing database point description.

The Database Management function shall present all required entries for any database item selected for changes to the Authorized User. Authorized Users shall be guided by the Database Management Function to enter new data, confirm existing data, and change default values as required.

When parameters are entered that require other parameters to be specified, the additional queries, prompts, and display areas required to define the additional parameters shall be presented automatically by the Database Management Function.

4.10.1.3 Database Generation

Within this section, the term “loadable database” is being used to describe the database that is accessed by the run-time application software. The “loadable database” is derived from the Global Database and is the result of the successful generation of the Global Database.

The Database Management function shall generate loadable Run-Time Databases from the Global Database.

Global Database structure changes shall not require regeneration of the entire Global Database.

When changes are made to the structure of the Global Database, the Database Management function shall determine which portion of the Global Database must be regenerated and which displays, reports, and software functions must be re-linked.

An Authorized User shall be notified of either successful completion, completion with errors, or termination of the database generation process.

4.10.1.3.1 Data Retention

When a new loadable Run-Time Database is being generated, the database generation process shall retain and utilize data from the current ROCC software Database in the newly generated database, even when a newly generated database contains structure changes.

Data to be retained across database generation cycles shall include all database fields and data. Data attributes to be retained shall include:

a) Field state changes; b) Operator Requests; c) Login / Logout; d) Calculations; e) Quality codes; f) Manual entries; g) Tags; h) Historical data; i) Tuning parameters.

4.10.1.3.2 Database Editing

It shall be possible to modify the contents of the Global Database (not the structure) without requiring a Global Database generation.

Page 96


Editing the Global Database shall not affect the operation of any processor in the ROCC software nor shall it require that data transfer between primary and backup processors be suspended.

It shall be possible to implement changes to the content of the Global Database in all applicable ROCC software processors without system downtime.

On-line database changes shall not affect the system’s reaction to hardware and software failures nor shall it require that the exchange of data among processors for backup purposes be suspended.

The Database Management function shall include a utility function that creates a snapshot of the current values within the Run-Time Database. The snapshot file shall be accessible by an Authorized User such that it can support the editing functions within the Global Database.

4.10.1.4 Tracking Database Changes

Audit trail files shall be maintained by the Database Management function for all changes made to the database, including changes to the database schema and data items.

The audit trails shall identify each change (including values prior to the change), include a date and time stamp for each change, and identify the user making the change.

An Authorized User shall be provided the capability to enable/disable logging of changes to the database schema and data items and select specific database elements or database element types for logging.

The Database Management function shall provide a version control system that allows for rollback to a version of the database prior to the most recent set of changes.

The version control system shall provide the capability to roll forward to a version of the database that was active prior to the rollback.

4.10.1.5 Database Management User Interface

The Database Management function shall include displays that provide Authorized Users the capability to perform the following:

a) manage the ROCC software Database; b) generate and integrate the ROCC software Database; c) perform utility functions such as finding a data point name, producing listings of database elements

and rolling forward or back to versions of the database; d) perform database recovery functions; e) modify the structure of the ROCC software databases; f) add, modify and delete data points and link those data points to display symbols as specified herein

4.10.1.6 Database Management Failure Handling

When errors are detected during Run-Time Database generation, the failed items shall be flagged and rejected, and the errors shall be documented into a Database Generation Error Report.

Database Generation Error Reports shall include the date and time of the database generation, identification of the User that initiated the database generation, a description of the error including the data points that failed, and the values at the time of error detection.

a) Database Generation Error Reports shall be ASCII text, readable without reference material. b) When an error is encountered, the database generation function shall attempt to continue processing

the database in an effort to detect all existing errors before terminating. c) The Authorized User performing the database generation shall be notified of the name and location of

the Database Generation Error Report.

Page 97


Invalid data entry errors, such as entering an invalid data type or attempting to define contradictory characteristics for a database point, shall be detected and a user advisory message presented to the Authorized User. Invalid entries detected by the Database Management functions shall not be entered or saved to the database. When the Database Management functions detects data entry errors, the Authorized User shall not be required to repeat steps that were correctly executed prior to the erroneous action.

The Database Management function shall detect any inconsistencies between redundant databases and data on all ROCC software processors and take actions to resolve the inconsistencies. This function shall alarm any detected database inconsistencies.

4.10.2 Display Generation and Management

The Display Generation and Management functions are used for managing ROCC software displays and developing display elements. Displays include graphical displays and text-based displays such as tabular displays and dialogs.

The Contractor shall develop and provide all graphical displays and all text-based displays as required within these Specifications as part of the ROCC software.

The Display Management function shall include all display elements, as described herein, used to develop the graphical and text-based displays. All display elements and displays shall be named, such that they can be accessed by the ROCC software applications using these names. The function shall include an interactive Graphics Management Tool that enables Authorized Users to maintain all graphical displays and associated display elements.

The Graphics Management Tool shall include the capability for Authorized Users to create, modify, and delete all ROCC software displays and display elements including:

a) Graphic primitives; b) Display symbols; c) Segments; d) Dynamic data linkages; e) Display layers.

All ROCC software graphical displays and display elements defined herein shall be implemented using the Graphics Management Tool.

The Display Management function shall include all display elements that are described in the WMATA Track Display Symbol Catalog.

a) The Display Management function shall include all display elements such that they adhere to all color and display symbol conventions described in the approved ROCCC Display Conventions and Guidelines Document.

b) The Display Management function shall include a library of all display elements for review by WMATA through the use of the prototype system.

c) The Contractor shall only use Engineer-approved display elements to develop graphical and text-based displays.

The Display Management function shall implement text-based displays using a COTS product such as Xdesigner or FormBuilder, or an Engineer-approved equal:

a) The utilization of a Display Management COTS product shall not release the Contractor from the contractual obligations to satisfy the functional, availability, capacity, expandability, and other requirements of these Specifications.

b) All versions of the Display Management COTS product shall be the latest version unless approved by WMATA.

Page 98


c) The Display Management COTS product shall be an interactive tool that allows an Authorized User to create, modify, and delete all ROCC software text-based displays using widgets of the standard toolkit for OSF/Motif and/or Windows.

The Display Management function shall include all tools and applications necessary to generate, integrate, and test the text-based displays, the graphical displays and the associated display elements:

a) The Display Management function tools and applications shall be delivered with the ROCC software. b) All Display Management function tools and applications shall be defined, prior to use, within the

Software Development Plan.

4.10.2.1 Display Definition

4.10.2.1.1 Display Symbols

The following graphic primitives shall be developed and provided as part of the ROCC software:

a) Vectors; b) Rectangles; c) Circles; d) Arcs; e) Polygons; f) Text (represented by true type fonts); g) Additional primitives defined during user interface prototyping.

The Display Management function shall provide the capability for an Authorized User to maintain the set of graphic primitives and construct custom graphic primitives through the use of the Graphics Management Tool.

The Display Management function shall provide the capability for an Authorized User to create display symbols that represent all graphic objects that will be depicted on the Track Displays including Train Control devices, and 3rd Rail SCADA indications. The Display Management function shall provide the capability for an Authorized User to create new display symbols, using any existing display symbol, graphic primitive, or any combination of display symbols and graphic primitives.

The Display Management function shall provide the capability for an Authorized User to copy a display symbol and modify it to create a new display symbol as well as to merge one display symbol with another to create a new display symbol. Display symbols and graphic primitives within the Display Management function shall be saved within symbol libraries. Display symbols shall be defined at a predefined arbitrary scale factor, adjustable by an Authorized User.

The Display Management function shall provide the capability for an Authorized User to associate text labels with the display symbols. Text labels shall be placed on a separate display layer from the display symbol, such that the text label can be assigned to a declutter level.

The Display Management function shall provide the capability for an Authorized User to modify the color of the display symbol to that is associated with a given device state.

4.10.2.1.2 Segments

Segments are logical groupings of display symbols, graphic primitives and dynamic linkages. For example, the user may choose to group all interlocking devices (switches, tracks and signals) into a segment, such that the same segment can be placed in multiple areas of a track display. Segments will be stored and retrieved from the segment library for quick application to displays.

Display segments shall consist of any combination of display symbols, graphic primitives, segments, and dynamic linkages to the database and user interface.

The Display Management function shall include all graphic display segments as defined herein and include the ability for the Authorized Users to maintain graphic display segments.

Page 99


The Display Management function shall provide the capability for an Authorized User to create segments for

The Display Management function shall provide the capability for an Authorized User to create a segment by selecting multiple display symbols from the symbol and segment libraries or from an existing graphic display using any ROCC software selection method, as described in these specifications.

The Display Management function shall support the addition, deletion, and modification of segments, including the merging of one segment with another to create a new segment. Segments shall be defined at a predefined arbitrary scale factor, adjustable by the Authorized User.

The Display Management function shall include a base library of segments commonly used by display builders and all segments included in ROCC software displays. Additional specific segments to be provided in the base library of segments shall be defined during prototyping.

4.10.2.1.3 Dynamic Data Linkages

Dynamic state changes are performed on display symbols and display segments based upon dynamic linkages to the associated data points within the ROCC software database. All dynamic linkages to the ROCC software database shall be via symbolic point names. Each display symbol or segment stored in a Display Management function library shall include its dynamic linkages.

During real-time operation of the ROCC software, as a device changes state in the field, the associated data point shall change in the database and the display symbol and display segment shall dynamically change on associated displays.

4.10.2.1.4 Display Layers

Display layers will provide the means to add more detail to a graphic display or remove detail from a graphic display by controlling the set of devices that are drawn on each layer. For example, track segments names may be placed on layer 1, where signals may be placed on layer 2, and emergency exits on layer 3. A graphic display can then be created by combining the layers. Authorized Users will control the amount of information that is shown on their graphic display through adding/removing declutter levels as specified herein.

The ROCC software displays and the Display Management function shall include all display layers such that the layers support the approved set of declutter levels as specified herein.

The display layers shall support the requirements for decluttering all devices of a specific type, such as SCADA 3rd Rail devices, or specific devices such as emergency exits.

The Display Management function shall provide the capability for an Authorized User to construct and define display layers by placing graphic primitives, display symbols and segments in to the coordinate space.

An Authorized User shall be able to select display elements from the associated library and place the element(s) onto on one or more display layers. There shall be no restriction on the placement of any display element on a display layer.

The Display Management function shall provide the capability for an Authorized User to place display symbols on graphic displays in the proper relation to other display symbols in accordance with the physical relationship of the devices that they represent.

The Display Management function shall provide the capability for an Authorized User to interactively combine elements and linkages in order to create display layers.

The Display Management function shall provide the capability for an Authorized User to merge one display layer with another to create a new display layer.

Page 100


The Display Management function shall provide the capability for an Authorized User to replicate (copying of elements to other locations within the layer and between layers) individual elements and sets of elements.

The Display Management function shall support the following static transformation of primitives, display symbols, and segments as the elements are placed on the layers:

a) Rotation of the element about a center point; b) Scaling of the element; c) Flipping the element about any axis (reflection); d) Snapping the element to a static grid, where dimensions (in pixels) are Authorized User –adjustable.

Defined static transformations on a display layer shall apply to individual display elements and to sets of predefined elements, adjustable by an Authorized User.

4.10.2.2 Display Generation

The Display Management function shall provide the capability for an Authorized User to build a new display starting with a blank display, copying an existing display, or import formatted files (e.g. AutoCad or MicroStation). Formatted files shall be used as either static graphical displays (no user interaction) or shall be used to create graphical displays, such as Configuration Monitoring and Control Displays depicting the status of the network topology.

The Display Management function shall provide the capability for an Authorized User to modify or delete an existing display and support the integration of new and edited displays into the active display library. The function shall provide the capability for an Authorized User to configure display dimensions. Displays shall not be limited by the size of the viewable area of the screen. Authorized User to configure the default coordinates of the display placement on the screen and to configure whether the display must always stay on top (not covered by other displays). Unbroken viewing of the display image being built as the Authorized User extends the size of the display beyond the screen size limits shall be allowed. Each display shall include the display coordinates definition that will permit Authorized Users to navigate successfully to the portion of the display that is of interest.

Authorized User shall be able to interactively combine display layers into displays. Each display shall be capable of displaying up to 32 display layers. The definition of each layer shall include a range of scale factors over which the layer shall be visible. Manual control of layer visibility shall determine the layers on view. Each display shall incorporate manually selectable and automatically (by scale factor) displayed layers.

All ROCC software text-based displays shall have a consistent look and feel. Control buttons, such as Okay, Cancel, and Delete shall appear in a consistent location on each text-based display.

To protect against loss of display work when a system hardware or software failure occurs that aborts the display generation process, the current work shall be automatically saved every one minute to an auxiliary memory file. The function shall check a display for errors before integrating the display into the display library.

It shall not be necessary to regenerate any display following a complete or partial system database generation unless the database points linked to the display have been modified or deleted.

4.10.2.3 Display Management User Interface

The Display Management function shall include an interactive user interface, including all displays, menus, and toolbars necessary to provide Authorized Users the capability to create, modify, and delete display symbols, segments, dynamic data linkages and display layers.

The interactive Graphics Management Tool shall provide the displays that allow for creation, modification and deletion of graphic and text-based displays. The interactive Graphics Management Tool shall provide displays to manage the display symbols and display libraries.

Page 101


4.10.2.4 Display Management Failure Handling

Errors that are detected during Display Management operation, including creation of display elements and displays, shall be detected and reported in a user advisory message. Invalid entries detected by the Display Management function shall not be entered or saved to the library files. When the Display Management function detects invalid entries, the Authorized User shall not be required to repeat steps that were correctly executed prior to the erroneous action.

4.10.3 Reporting

The Report Management function supports the development of Report content and format, and provides Report management. The Contractor will develop a set of Pre-Defined Reports that will be provided with the ROCC software. Pre-defined Reports are those Reports that have a fixed format and content. Authorized Users will be able to create new Pre-Defined Reports and modify existing Reports through the management tools described herein. Authorized Users will also be able to generate formatted Reports by selecting the Report from a Report menu. Pre-Defined Reports will also be available for scheduled execution. Authorized Users will be able to create customized Reports on-demand through the Ad-hoc Reporting function.

4.11 Support Applications

4.11.1 Online Help and Documentation

A convenient and consistent means will be provided to the ROCC User for Online Help relevant to the most recent user activity or current selected displays and dialogs. The help will either be provided immediately within a popup text box, indirectly through hypertext (providing additional information), or as a hypertext link to an appropriate section of online documentation. System maintenance personnel will be provided with the capability to update and add to the Online Help functionality.

Authorized Users shall be able to access Online Help by selecting topics off of a Help pull down menu. The Help menus shall be organized such that the user can quickly access topics relating to the display that they are currently working on, and/or error messages that relate to the active display. The organization of the Help menu and topics to be covered within the Online Help system shall be reviewed during Prototyping.

Authorized Users shall be able to access Online Help associated with a field or context sensitive area on a display/dialog, by selecting the field/area, subject to prototyping.

The Online Help system shall provide hypertext links to all online documents, such that the user can be directed to information relating to the selected topic, field or context sensitive area within the appropriate document. Hypertext containing specific information and explanations about fields and icons (and their associated status), diagrams, operations, instructions, static symbology and background shall be linked to the appropriate related item identified by cursor position or most recent user activity.

4.11.1.1 Online Manuals

A convenient means to access, via ROCC Workstations, electronic copies of WMATA manuals and other reference material will be provided to aid the user. WMATA personnel will also be provided a means to update and add to the available online documentation. ROCC manuals and reference material will contain hyperlinks to help pages, specific sections within the document and links to other documents:

a) The Contractor shall provide all manuals and online reference, maintenance, etc. material to WMATA separately in MS Word Format.

b) All online documentation shall be easily accessible through the ROCC menu system. c) The Table of Contents for each online document shall contain hyperlinks to sections, pages, tables

and/or figures within that document. d) A “search” feature shall be provided for all online documentation that locates matching text, based on

an entry of a key word(s), “wildcard”. e) The method of performing the “search” operation shall be reviewed during Prototyping.

Page 102


f) User access to online documentation shall be controlled based upon user classification and function access assignments.

g) The Contractor shall identify key words and key concepts within the body of each online manual such that they provide hyperlinks within the document and to other online documents.

h) The hyperlinks within each online manual shall be reviewed during system prototyping. 4.11.1.1.1 System Users Manual

Online Manuals will be included as online documentation for use by Users. Online Manuals will be part of the Online Help system, as they provide instruction to users on how to operate the system, to correct system errors and diagnose system problems. The online manuals therefore require hypertext links to be established within the body of the manuals, such that users can quickly navigate through the manuals.

At a minimum, the following manuals shall be incorporated into the ROCC system as part of the online documentation system:

a) Service Delivery User’s Manual; b) Programmer/System Administrator User Manuals for ROCC Configurations c) Hardware Reference Manuals; d) Maintenance Manuals; e) Operating Rules Manuals; f) Diagnostic Program User’s Manual (CDRL T412).

4.11.1.1.2 Online Reference Material

Reference material will be included as online documentation for use by WMATA personnel. The Contractor is not required to provide hyperlinks within the body of the reference document. However, the Contractor is required to provide hyperlinks from the Table of Contents to other portions of the document.

At a minimum, the following documentation shall be incorporated into the ROCC system as part of the online documentation system:

a) All final Engineer approved ROCC system documentation (hardware and software) including all CDRLs;

b) All final Engineer approved ROCC system ICRSs; c) Interlocking Rules Documentation (CDRL T504) (Executive, as well as all site-specific sections) shall

be incorporated in the ROCC system online library; d) WMATA schedule sheets; e) WMATA headway sheets; f) WMATA Incident and Emergency handling procedures; g) WMATA rulebook; h) Dictionary; i) Thesaurus.

The following information shall be presented in separate lists and in alphabetical order as part of the online documentation system:

a) Acronyms; b) Symbol Definitions; c) Term Definitions.

4.11.1.2 Online Document Maintenance

Authorized Users, will have the ability to add, remove, and modify online documentation.

A tool, easily distinguishable from the Online Help viewing applications, shall be provided for an Authorized User to edit the Online Help.

Page 103


Through the Online Help editing tool, an Authorized User shall have the ability to add, modify, or delete text within each Help item and/or associated with each existing link.

Through the Online Help editing tool, an Authorized User shall have the ability to add, modify, or delete hyperlinks to online documents.

Updates to the Online Help shall occur in real-time and a restart of the ROCC system or any ROCC Workstation shall not be necessary to refresh the Online Help.

Capability shall be provided to import the WMATA Rulebook via electronic file transfer capability or an Engineer approved process.

The Contractor shall provide a utility to convert all documentation that is to be part of the online documentation library to a consistent format.

An Authorized User shall be able to add, delete, modify, or replace electronic documents within the online documentation library and edit electronic documents using a commercially available text and graphics editor such as Microsoft Word.

The ROCC software shall automatically re-establish the hyperlinks of all Online Help files and online documentation to the appropriate document sections, pages, tables and/or figures within the document and within reference documents.

The ROCC software shall automatically re-establish the hyperlinks to all key words and key concepts within the body of the online manuals.

The ROCC software shall provide a User Advisory to an Authorized User if a hyperlink cannot be re-established automatically and shall allow the user an opportunity to manually correct the link.

Any addition, deletion, modification, or replacement of online documentation shall be subject to Control Action Confirmation.

Updates to online documentation shall occur in real-time; a restart of the ROCC software or any ROCC Workstation shall not be necessary to refresh the library documents.

4.11.2 Software Utilities

4.11.2.1 Code Management System

The Software Utilities shall include a Code Management System that provides the capability for Authorized Users to document and control revisions to all programs, data files, test files, generation files, and database structures. The Code Management System shall:

a) Manage the modification of all system generation files, data files, scripts, and test files that are used in the generation, linking, testing, simulation, and execution of the ROCC software.

b) Maintain a library of source, object, and executable image code. c) Provide the capability for Programmers and System Administrators to setup, rename, modify, and

delete code management libraries. d) Provide the capability for the Programmer and System Administrator to save a copy of selected files or

folders as interim versions. e) Provide protection to versions to ensure that files and version histories are not overwritten or

accidentally deleted. f) Provide the capability for the Programmer and System Administrator to recall a database structure

related to a specified software version. g) Retain a complete history of all file accesses, additions, deletions, and modifications to each item

within the library, including the identification of the user, the date and time, file revision number, user comments, and any other pertinent information.

Page 104


h) Provide the capability to select files to be added (checked-in) to a library, deleted from a library, moved or copied to another library, or retrieved (checked-out) of a library. This includes; validation checking on all check-in operations and perform authorization verification for all Code Management System operations.

i) Provide the capability to compare two files, resolve file differences, and perform merging of files to create a composite merged result.

j) Support the insertion of keywords into the source code, data files, and binary files for automated documentation and audit trail generation.

k) Provide the capability to label software releases and identify all files related to the release.

The Code Management System shall create a variety of reports upon System Administrator or Programmer request including:

a) Report of all locked files; b) Report all unlocked files; c) Report revision history for a file, set of files, or library; d) Report files and history status for a library or set of libraries; e) Report differences between selected file revisions; f) Report of all revisions locked by an user, or set of users; g) Report all revisions created after a labeled release; h) Report all revisions created by a single user, or set of users; i) Report revisions created between two dates; j) Report all revisions that have a given label; k) Report any revision including a revision comment that contains a user specified text string; l) Report all files that are different from the latest checked in revision.

The Code Management System shall provide the capability for the Programmer and System Administrator to select and execute available reports.

Program dependencies shall be included in the Code Management System library for user reference.

4.11.2.2 File Management

File Management Services shall be provided which allocate, create, modify, copy, search, list, compress, decompress and delete program files, data files, and display files on auxiliary memory and archive storage.

The File Management Services shall:

a) Provide memory segmentation facilities to separate files into directories and logical WMATAs. b) Provide the capability to protect and unprotect files and directories. c) Provide the capability to remove viruses from corrupted files. d) Support logical file names to manipulate and access files. e) Provide a memory usage optimization feature. (Remove unnecessary files as specified by the System

Administrator or Programmer and organize segmented programs efficiently to provide the maximum spare memory.)

f) Maintain a record of the auxiliary memory allocation of all programs, displays, and data. g) Be available for display and printing upon System Administrator or Programmer request.

4.11.2.3 Auxiliary Memory Backup

The ROCC software shall include Backup Utility software to backup processor and workstation auxiliary memory files onto a user-selected auxiliary memory or archive device. The initiation of the Backup Utility process shall be scheduled by a Programmer or System Administrator and, except for the replacement of the archive media, shall proceed unattended to completion.

The Backup Utility shall:

a) Include the capability to backup all processor and workstation auxiliary memories located throughout the ROCC software onto a single target auxiliary memory or archive device.

Page 105


b) Ensure that the source auxiliary memory files are captured properly regardless of caching activity. c) Provide the capability for System Administrator and Programmer selection of the files to be saved

based on; processor and workstation, file names (including directory and wildcard designations), file creation or modification date and time, whether or not the file was modified since the last backup, global request for all files from a selected memory device.

d) Maintain a database of all files backed up to auxiliary memory and archive devices, including the file name, WMATA where file originated, size of file, type of file, date and time backup was performed, and all additional information necessary for later retrieval of the file. This includes; providing the capability for Programmer and System Administrator searches of the Backup Utility database to locate data stored to auxiliary memory or archive devices and the capability to search the Backup Utility database to identify archived or stored file(s) by specifying filter criteria including original file WMATA(s), device(s), folder(s), filename(s), and file contents by string or data; wildcards shall be allowed.

4.11.2.4 Utility Services

The ROCC software shall include a Copy utility that transfers data or files from any storage device to another storage or output device, including automatic format conversions where necessary, upon Authorized User selection.

A Data Transfer utility shall be provided that will support the capability of an Authorized User to load and dump all or portions of auxiliary memory from and to other storage or input/output media and provide verification of the transfer.

The ROCC software shall include a Comparison utility that performs comparisons of data or program logic on any combination of input or storage devices specified by a Programmer or System Administrator. The Comparison utility shall include comparisons of multiple sets of source code or data files. This shall include a File Search utility that provides Authorized Users with the capability to perform main and auxiliary memory searches for selected text strings, data values, source code or files:

a) File Search logic shall support searching by single or multiple patterns, date and time frames, and file attributes. The use of wildcards shall be included.

b) Source code searches by selected device(s), folder(s), or file(s) shall be provided as part of the File Search utility.

c) When a source code File Search is successful, the source shall be identified (document name, location(s) in the source document, source line text), displayed, and/or printed, as selected by the Authorized User.

An ROCC software Inventory database shall be maintained online, accessible by Authorized Users, identifying all ROCC software hardware (including spare replacement parts), software, and documentation included as part of the ROCC software. The database shall be searchable using filters that include component type (i.e. hardware, document, software), component name, manufacturer, component location, and all other inventory data maintained in the Software Configuration Items List and Hardware Configuration Items List (see Section 8.4.1).

The ROCC software shall include Printer utilities that monitor and present the status of all printer queues upon request of an Authorized User, including identification of jobs that are in the queue, the status of the jobs, the originator of the print job, and any error conditions such as whether the printer is out of paper.

4.11.3 Network Services

The ROCC software shall support data communications within the ROCC software configuration and interfaces to external networks to which the ROCC software is connected. The design shall include a dual network design such that all communications to each device on the network is redundant and include software for network communications, security, services, and management.

Page 106


The ROCC software network operating structure shall be of an open architecture conforming to the IEEE 1224 Open System Interconnection (OSI) Abstract Data Manipulation – Application Program Interface (API) Standards for interface with other software applications.

The Contractor shall propose a Network Operating System (NOS) that meets all requirements of this Specification. The proposed NOS, along with justification for the selection shall be identified in the Software Development Plan (SDP), for Engineer review and approval.

The Engineer’s approval and purchase of the Contractor’s proposed NOS products shall not release the Contractor from the contractual obligations to satisfy the functional, availability, capacity, expandability, and other requirements of these Specifications.

ROCC software Network Services shall be provided for all Authorized Users access to network functions necessary to support the functional requirements of the ROCC software. The software shall monitor and control routing of Authorized User access to the services. ROCC software Network Services provided shall include:

a) Network file management and transfer; b) Network printing management; c) Remote procedure call; d) Remote terminal session; e) Network time synchronization; f) Network backup.

The ROCC software Network Services software shall maintain performance, resource usage, and error statistics for all managed links and devices.

The ROCC software Network Services software shall include all node interface functions and data necessary to connect a node to the ROCC software Network. The software shall provide the node interface functions and data for each type of network node provided with the ROCC software. The functions shall be licensed for the quantities and types of nodes defined for the ultimate ROCC software configuration.

The ROCC software shall read the time and date from the GPS source and compare it to the time and date maintained by the ROCC software at least once every fifteen minutes. If the time difference is a greater than System Administrator-adjustable synchronization time, the current system time shall perform synchronization to the GPS source time automatically.

Authorized Users shall have the capability to manually adjust the date and time locally within the entire ROCC software, overriding the external GPS time source input. The ROCC software shall calculate time and data based on the local data and time when external GPS time source is overridden.

The ROCC software shall maintain the same time and date at each workstation and subsystem, such that there is no time drift between processors.

The ROCC software shall also update the current time on the existing systems within CTF and JGB as well as the field FCUs. An Authorized User shall have the ability to set the time interval in which to reset the CTF/JGB systems as well as the field FCUs.

4.11.3.1 Network Communications

Authorized Users and processors shall be able to communicate within the ROCC software network of local and remote workstations, processors, and peripheral devices operating as described in this Specification.

The ROCC software shall include a common communications network, using a standardized network protocol, such as TCP/IP, which the Contractor demonstrates to the satisfaction of WMATA that it meets or exceeds all requirements of this Specification without exception. The network communications software shall link dissimilar hardware nodes, including terminals, workstations, and applications and communications processors, into a common data communications network allowing communications among these devices.

Page 107


The ROCC software shall provide trend analysis tools that enable an Authorized User to review the performance of each data communications channel and LAN over a designated period. Capability shall be provided for an Authorized User to define monitoring threshold values (e.g. minimum, maximum, average) for each monitored channel and LAN. The system shall provide a user advisory and log an event when the threshold values are reached or exceeded.

4.11.3.2 System Performance Monitoring

The ROCC software NOS shall include a System Performance Monitoring function that continuously monitors the performance of all hardware devices, including all processors and workstations and gathers associated performance statistics.

The System Performance Monitoring function shall monitor the amount of available online disk capacity currently in use for each ROCC software processor and shall provide a user advisory message to Authorized Users whenever the online disk usage has reached or exceeded a pre-defined capacity, adjustable by an Authorized User.

The System Performance Monitoring function user advisory message indicating disk usage has been exceeded shall continue to be sent at an interval established by an Authorized User until the condition no longer exists (e.g. every x minutes). The interval shall be Authorized User adjustable. The System shall collect data in real-time with no interference or degradation to any other ROCC software functions.

The period over which the System Performance Monitoring function statistics are gathered shall be ROCC software Administrator adjustable.

System Performance Monitoring function statistics shall be recorded by the Information Storage and Retrieval function of the ROCC software; reset of the System Performance Monitoring function will not affect previously stored statistics.

The accumulated System Performance Monitoring function statistics shall be stored and then reset at an Authorized User adjustable collection start time.

The System Performance Monitoring function statistics shall be available for printout and display after the completion of each collection period (for final accumulations in a collection period) and on demand (for current accumulations during a collection period).

4.11.3.3 Processor Usage Resource Monitoring

The ROCC software Performance Monitoring function shall include on-line services to provide Authorized Users the capability to individually enable, disable, and initialize processor usage resource monitoring. The monitoring function shall collect the following statistics:

a) Processor busy time in percent; b) Total processor idle time in percent; c) Processor idle time during main/auxiliary memory transfers in percent; d) Total number of transfers to/from auxiliary memory; e) Total transfer time for each auxiliary memory in percent; f) Time in percent when one or more tasks were blocked waiting for memory resources; g) Peak number of items in the various system and I/O queues; h) Page fault rate; i) Percent usage of the modified page file.

The ROCC software Performance Monitoring function shall separately collect and report the processor resources it uses.

4.11.3.4 Program Usage Monitoring

The ROCC software Performance Monitoring function shall calculate individual program usage in each processor and the associated operating system overhead. An Authorized User shall specify the ROCC software

Page 108


applications and programs for which performance statistics are to be gathered in each processor, the period over which statistics are to be accumulated, and the statistics to be collected.

The function shall collect the requested statistics and generate a complete summary after the collection period completes that reports the accumulated statistics for each application and program over the specified period. The function shall include on-line services to provide Authorized Users the capability to individually enable, disable, and initialize program usage monitoring function for each processor. The program usage statistics to be collected and calculated shall include:

a) Processor time used by the program in percent; b) I/O wait time in percent; c) Device usage statistics; d) Page fault rate; e) Time spent waiting for page faults in percent; f) Average number of pages in use in main memory; g) Average number of pages in use in the modified page file.

4.11.3.5 Failure Analysis

The ROCC software Performance Monitoring shall include Failure Analysis to detect and analyze each operating system and application program fatal and non-fatal failure. The information collected shall be presented in a user-oriented format acceptable to WMATA. The format shall be defined in the Software Development Plan, for Engineer approval. The information shall be recorded as part of the Information Storage and Retrieval historical records. Upon request from an Authorized User the collected Failure Analysis data shall be presented on displays or printed. Failure analysis information collected shall include the following items:

a) Time and date of failure; b) The most recent operating system service routine requested; c) The pending, executing, and completed programs; d) I/O activity per system device at time of failure; e) The current system resource allocation; f) Contents of pertinent system software tables; g) Contents of hardware registers; h) Contents of mapping tables; i) The contents of main memory; j) Paging parameters and tables.

4.11.4 Maintenance and Diagnostics

Diagnostic functions shall be provided for testing and monitoring all ROCC software devices and associated interfaces. The Contractor shall work in conjunction with WMATA personnel in order to determine the number and scope of maintenance and diagnostic functions that are necessary for ROCC software users to adequately maintain the ROCC software.

Included in the design of Maintenance and Diagnostic functions shall be the determination, in conjunction with WMATA personnel, of which user classifications will be designated as Authorized Users of these functions.

Diagnostic status of all ROCC software processors and devices shall be depicted on System Configuration Monitoring and Control Display. Access to detailed Diagnostic data for selected ROCC software processors and devices from the System Configuration Monitoring and Control Displays shall be provided to Authorized ROCC software users. As well as an On-line Diagnostic function shall verify the readiness for failover and the operability of all redundant backup devices.

Diagnostic data shall be collected from all ROCC software devices, including but not limited to ROCC software processors, main and auxiliary memory, peripherals, workstations, Video Display Wall components, data links, and communication interfaces at each of the following locations:

a) CTF; b) JGB;

Page 109


c) Remote Workstations.

An Authorized User shall have the capability to schedule the frequency of testing and the repeat rate of execution of diagnostics on ROCC software components:

a) An Authorized User shall have the capability to schedule testing to execute automatically at the specified time and frequency and to start and stop tests on-demand.

b) Diagnostics shall operate automatically after initialization by the Authorized User without the need for further user intervention.

c) On-line Diagnostic functions shall test all ROCC software hardware components, as scheduled, without interfering with or degrading the operation of any ROCC software function.

d) Independent off-line Diagnostic functions shall be provided for troubleshooting and testing the detailed operation of all ROCC software devices, including processors, main and auxiliary memory, peripherals, data links, console equipment, communication equipment, and communication interfaces.

e) These off-line Diagnostic functions shall provide comprehensive test configuration, display, printout, and user interaction capabilities through a single integrated set of Diagnostic displays.

f) Any failure detected by the off-line Diagnostics shall be recorded with sufficient test and failure details necessary to identify, troubleshoot, and correct the problem.

g) Off-line Diagnostics shall provide the capability to select the component(s) to be tested and the type of testing (full test, partial device test).

4.11.5 Support Application User Interface

The ROCC software shall include all displays necessary to allow Authorized Users (including the System Administrator and Programmer) the ability to initiate and execute Software Utility functions:

a) The Software Utilities displays shall allow Authorized Users the ability to initialize startup parameters associated with each software utility prior to or at the time of execution of software utility functions.

b) All Software Utilities of the ROCC software shall provide the capability to display requested information to the initiating processor terminal or ROCC software Workstation, to print to any output, log, or to be included as part of a report generated as part of the Software Utility service.

c) The displays necessary to perform individual functions of the Software Utilities shall be provided as an integrated set of displays.

The ROCC software shall include a Printer Control Display that allows the Programmer and/or System Administrator to perform management and review of any printer and print queue accessible to Authorized Users. The Programmer and/or System Administrator shall have the capability to interact with the Printer Control Display to perform the following functions:

a) Specify the default selection printer; b) Modify printer attributes available to the user; c) Review printer status; d) Review current jobs in and status of the printer queue; e) Delete, pause, and restart print jobs accessible to the user.

4.11.5.1 Network Services Displays

4.11.5.1.1 System Performance Monitoring Displays

The ROCC software shall include displays that present System Performance Monitoring data to Authorized Users:

a) Failure analysis data; b) Diagnostic data; c) System performance monitoring statistics; d) Processor usage resource monitoring statistics; e) Program usage monitoring statistics.

The System Performance Monitoring function displays shall provide the Authorized User with the capability to configure and administer the functions.

Page 110


The processor resource utilization for each ROCC software processor shall be displayable on-demand by Authorized Users both textually and graphically on the System Performance Monitoring Display.

The resource utilization for each ROCC software database shall be displayable on-demand by the Authorized Users, both textually and graphically on the System Performance Monitoring Display.

4.11.5.1.2 Communications Error Statistics

The Contractor shall provide Communications Error Statistics Displays that present the communications error statistics collected by the ROCC software for each of the following:

a) ROCC software Network data communications to ROCC software processors (workstations, servers), network devices, and peripherals;

b) FCUs; c) Data links to all computer systems that are interfaced to the ROCC software.

The period for which Communication Error Statistics shall be collected shall be an Authorized User-adjustable time period, configurable at 1 minute intervals from 1 minute to 30 days.

4.11.6 Support Application Failure Handling

Any failure detected by the Diagnostic functions or failure to perform a Diagnostic function shall be alarmed and reported to the Programmer and/or System Administrator.

The ROCC software Network Services software shall issue alarms when error conditions or resource usage problems are detected.

4.12 Event Management

4.12.1 Incident Reporting System (IRS)

This section describes the requirements for the development of an Incident Reporting System that shall provide the ROCC software with the capability to collect and enter information concerning rail incidents. The Incident Reporting System (IRS) shall be part of the ROCC software in order to allow for both automatic and manual entries into a system intended for tracking rail incidents. An entry in the IRS shall enable the tracking of a particular event or incident from the time of its occurrence through its eventual resolution.

Throughout the course of daily events in the OCC, incidents occur that are out of the ordinary. An incident can be anything from a vehicle with a diagnostic anomaly to an accident. Any such incident may or may not result in a deviation from planned service schedules. In any case, all incidents represent “exception conditions,” to one degree or another. All such exception conditions shall be ultimately defined by the Contractor after consultation with WMATA and shall have the ability for the tracking of each to be toggled on and off.

The Incident Reporting System (IRS) is the method by which exception conditions shall be communicated to the WMATA Customer Service department via the ROCC software Historical Data, which is then able to track past incidents.

Through prior definition, the ROCC software shall determine when an exception condition requires an incident report to be created and shall do so automatically:

a) The facility for manual creation of an incident report shall also be provided. b) Upon creation of an incident report, the IRS shall capture and log information related to that incident.

A user shall be able to add information to the incident report at a later date and time. c) IRS design shall ensure that information is entered into the ROCC software one time only and is

accessible by all. d) Incident reports shall remain open until closed by the appropriate users.

The Incident Reporting System shall provide on-line assistance based on the type of incident that was detected.

Page 111


All incident reports shall be logged to the ROCC software Historical Data in order to be able to create the necessary detail and summary reports.

4.12.1.1 Incident Reporting System Design Requirements

The Incident Reporting System shall allow ROCC personnel to track an incident from the time of its occurrence to its conclusion.

Particular exception conditions shall be able to be defined as resulting in the immediate, automatic initiation of an entry in the Incident Reporting System, or ROCC personnel can manually create an incident.

An incident shall remain “open” until an Authorized User designates the incident as “closed”:

a) Once initiated, an incident shall be logged into the ROCC software Historical Data. b) An open incident shall be reviewable by all authorized personnel through the Incident Reporting

System. c) A closed incident shall be reviewable by all authorized personnel through ROCC software Historical

Data. d) A closed incident shall be capable of being reopened and having additional information added at an

Authorized User’s discretion.

The IRS shall include tools to assist in the prevention of recording duplicate information.

As incremental entries are made into the IRS concerning a particular incident or event, the new information shall be sent to the existing WMATA Maximo system for integration into that external system. Reference Section 2.12 – Support Applications for additional information regarding the interface between the ROCC software and the Maximo system.

4.12.1.2 Incident Reporting System User Interface

The Contractor shall implement an Outstanding Incident screen in order to alert ROCC personnel to an incident report, and allow them to acknowledge and otherwise track an incident report. The Outstanding Incident screen shall show all open incidents that pertain to a particular user, ordered by date and time. Incidents shall be represented on the Outstanding Incident screen immediately upon their creation.

The Incident Reporting System shall be implemented in such a fashion as to allow selective routing of an incident to the appropriate personnel as the incident is reported.

The Contractor shall provide the capability for an incident report to be created via several different mechanisms. Creation Mechanisms – An incident report may be generated automatically or manually:

a) Automatic Generation – Upon the occurrence of a previously defined exception condition, an incident report shall be automatically generated by the ROCC software. Automatically-generated incidents shall be implemented in such a way that the generation of an incident shall be capable of being enabled or disabled at any time. For example, if a major incident occurs, the potential exists for hundreds of subsequent incident reports to be generated by related, consequential disruptions to the operating schedule or as detour/flex routings are implemented, operator assignments are changed, etc. (The generation of incident reports based on these hypothetical occurrences would be dependent upon which events are defined as incident-generating.) The ROCC software must account for such occurrences and provide for the convenient, immediate suppression of one or many automatically-generated incidents.

b) Manual Generation – The capability shall exist for a user to choose to manually create and edit an incident report.

The ROCC software shall include an incident creation form per the requirements below to allow for consistent data collection into the IRS.

Data Entry – All known data shall be automatically entered into the generated incident report. The data automatically entered by the Incident Reporting System shall include, but is not limited to:

Page 112


a) Date, time, a marker indicating whether the incident has been automatically or manually generated, and the ROCC crew-on-duty identification (i.e., Train Controller, MOC Supervisor, etc.);

b) The alarm that precipitated the automatic creation of the incident, and all particulars concerning same; c) Operator ID and vehicle ID, if the incident is vehicle-related; d) Track ID and territory “owner,” if the incident is track-related. e) Other data on the electronic form shall include, but not be limited to, the following: Originator;

Individual in charge of the pertinent territory where the incident has taken place, if applicable; Explanation of the Occurrence – A full-text explanation of the incident responsible for the issuance of the incident report; Occurrence Code – A standard set of codes that achieves a uniform coding strategy and provides a consistent search target for Historical Data queries. The selection list for this field shall include codes approved by WMATA.

Serial Incident Number – An incident shall be automatically assigned a serial incident number that conforms to WMATA’s incident numbering scheme.

Incident Modification – The Incident Reporting System shall provide the user with the opportunity to immediately modify the incident report on their screen.

The user shall have the opportunity to supply additional information to the incident:

a) Additional information may be entered immediately after creation of the incident, or at any other time, at the discretion of ROCC personnel.

b) A previously closed incident remains subject to having additional information entered. An incident shall be able to be reopened at a later date.

Particular automatically entered fields shall be protected. These fields (e.g., date and time) shall not be available to the user for modification. The complete list of protected fields on the incident report is subject to review and approval by WMATA.

Incident Copy – The Contractor shall provide the capability to copy an existing incident report for inclusion on another, separate incident report.

Incident Closure – The Contractor shall provide the capability to close an incident once all known data is entered onto the report:

a) The Incident Reporting System shall be implemented such that once an incident is created (either automatically or manually), the incident shall appear on the Outstanding Incident screen with a designation of “open” until the incident is completed and designated as “closed.”

b) An open incident may be closed by either the originating user or else another Authorized User. The hierarchy of Authorized Users shall be prepared by the Contractor, and submitted to WMATA for review and approval.

c) The Contractor shall provide a mechanism to allow WMATA to alter this eventually-determined hierarchy of Authorized Users at a later date. If the hierarchy of Authorized Users is modified, the new hierarchy shall become immediately active, without the need of application restart.

4.12.1.3 Definition of all Exception Conditions

The Contractor, in concert with WMATA, shall develop the Exception Condition List identifying all situations that could potentially result in the triggering of an automatic entry into the Incident Reporting System.

The Exception Condition List shall result from a comprehensive Contractor study of ROCC Facility operations and be compiled with input from ROCC personnel:

a) The Exception Condition List of “automatically triggered incidents” is subject to review and approval by WMATA before it may be implemented.

b) An example of incidents that would result in the automatic creation of an incident shall include, but is in no way limited to, violation of a slow order, operator engagement of the automatic train stop bypass switch with or without approval by ROCC personnel, and field engagement of an operator’s panic button.

Page 113


c) The Contractor shall provide the ROCC software with the ability to modify the list of predefined conditions that shall result in the triggering of an automatic entry into the Incident Reporting System. This modification facility shall involve the ability to inhibit an event that previously triggered an automatic Incident Reporting System entry, and shall also provide the ability to designate an event that will trigger an automatic entry. The automatic generation of an incident due to a specific exception condition shall be capable of being turned ‘on’ and ‘off’.

4.12.1.4 Incident Historical Data Logging

Once an entry is created in the Incident Reporting System, the entry shall be logged to the ROCC software Historical Data:

a) Logging of an incident shall include all data from the Incident Reporting form, including, but not limited to, the complete text, including any and all later additions to the incident.

b) Historical Data logging shall also note all activities related to the incident, along with the time of occurrence.

c) Each of the later additional entries of data shall be stored such that it is possible to determine, upon reviewing the incident record, which entries were made when, and by whom.

d) It shall be easy to ascertain what information was entered upon the original creation of the incident versus what was entered upon the second, third and all subsequent additions to the incident. It shall also be evident as to which user made each entry to the incident report.

Once an incident is created, it shall be available for on-line review by any ROCC personnel with the appropriate security permissions, as determined by function access definition, to review incidents. This on-line review mechanism shall be included as part of the Incident Reporting System:

a) The on-line review mechanism shall reflect the current status of the incident record. b) The ability to determine each and every discrete entry to the incident report shall be provided as part of

Historical Data.

The criteria for retrieving an incident for review shall include, but are not limited to, incident number; date; route; location; operator ID; vehicle ID; originator; closing agent; explanation of the occurrence; and keywords.

4.13 Process Guidance

The Contractor shall configure the ROCC software to provide process guidance where possible. Specific examples of process guidance are included. However, as the project matures, WMATA shall request additional process guidance be provided to make the rail road either safer or more efficient to operate.

Process guidance shall present a set of steps or pertinent information to the user that is context-sensitive and which assists the user with the current situation. The process guidance steps shall be presented in such a fashion (e.g. checklist) that the user marks off steps as they have been completed.

Capability shall exist within the ROCC software for WMATA to add process guidance scenarios at a later date without intervention from the Contractor or any other third party .Capability shall exist within the ROCC software for WMATA to modify existing process guidance scenarios at a later date without intervention from the Contractor or any other third party. The Contractor shall present various methods (textual, graphical) of displaying process guidance information to a user for review and approval during prototyping.

4.13.1 Tunnel Ventilation

Process guidance shall be provided for use within the Tunnel Ventilation Control (TVC) subsystem. The TVC shall be designed to assist ROCC personnel in emergency response by identifying the location of the emergency and/or vehicle(s) that are involved in the emergency. TVC shall automatically identify:

a) Vehicle specifics (vehicle type, operator, etc.); b) The evacuation zone; c) The nearest emergency exits;

Page 114


d) The nearest escalator, elevator or stairs; e) The nearest station or stop; f) The cross streets; g) The nearest interlocking; h) The station street address; i) The nearest emergency telephone; j) Status of the traction power system; k) Status of the signal system; l) Notification list, including emergency response phone numbers (both WMATA and outside agencies).

TVC shall identify the distance from the emergency location and/or vehicle to any of the items listed in the aforementioned list as well as provide for the automatic dialing of emergency response phone numbers. As a component of Tunnel Ventilation process guidance, the Contractor shall implement all parts of the WMATA Emergency Ventilation Operation Plans (EVOP). The Contractor shall work in conjunction with WMATA to develop the precise evacuation procedures using the WMATA-commissioned Kiser Report and existing WMATA Mode Tables for ventilation-equipped areas.

TVC emergency response shall follow all vehicle evacuation rules as defined in the WMATA Metrorail Safety Rules and Procedures Handbook (MSRPH).

4.13.2 Single Track Routing

Process guidance shall be provided for use when single track routing is required to go around a stopped or otherwise disabled train.

Train Tracking shall include process guidance to provide information concerning the procedures that WMATA wishes ROCC software users to utilize when routing trains through a location on a single track.

The Contractor shall work in conjunction with WMATA to develop a set of predefined ‘canned’ single track scenarios that a user can call up and use to assist the user through known, repeating single track situations.

a) An example of a known, repeating single track condition could be where a Line Supervisor instructs an Assistant Line Supervisor to run trains two in one direction, followed by two trains in the other direction, then one train in each direction, and then repeat the process.

b) Single Track Routing process guidance shall assist the user in performing this or any other defined single track scenario that WMATA wishes.

The Contractor shall implement Single Track Routing process guidance in such a manner as to allow WMATA to define other, future single track scenarios in an ad hoc fashion at a later date.

4.13.3 Work Forms

Process guidance shall be provided for use in conjunction with the ROCC software implementation of Work Forms. Upon a Work Form taking effect on a particular track segment or section of track segments, process guidance shall be provided to assist Line Supervisors in alerting rail personnel via radio:

a) Via radio, train operators shall be instructed to reduce train speeds through the Work Form zone.

4.13.4 General Every Day Incidents

The Contractor shall become familiar with WMATA operations and develop process guidance to aid users of the ROCC Software. Process guidance shall be provided for use in managing and recovering from the following everyday incidents on the rail system:

a) Sick Passenger Off-Load

Page 115


b) Police Incident c) Cracked Rail d) Foul Time Request e) Loss of Communication f) Switch Malfunction g) Station Crowding h) Traction Power System Malfunction

5. Hardware

5.1 Hardware Procurement

The Contractor shall develop and submit for approval a complete hardware design based on hardware and networking equipment from WMATA approved Contractors. The current suppliers are Dell and Cisco. The Contractor shall develop detailed AutoCAD design drawings showing all communication and power connections. The design shall specify, and formally list all equipment necessary to support a fully functional ROCC software as described in these Specifications. Hardware quantities shall be precisely enumerated in the Hardware Specifications by location and by major equipment types. The Contractor shall:

a) Create a list of hardware to be procured and installed by WMATA at CTF OCC, JGB OCC, and the PET Facility.

b) Create a list of hardware to be procured by WMATA and installed by the Contractor at his Facility. c) Where applicable solid state hard drives shall be used. d) Utilize a thorough, planned process for designing and developing the ROCC software hardware, e) Develop final detailed requirements, designs, Specifications, drawings, and Bill of Material

documentation for all ROCC software hardware in accordance with these requirements, f) Specify ROCC software equipment power supply cabling and rack-to-WMATA network console

cabling, g) Specify the interface of ROCC software equipment to WMATA SONET/ATM network backbone data

communications systems. h) Specify, formally list, test, and commission network hardware i) Test and commission the ROCC hardware in accordance with the requirements of Section 6.0 – Test

and Commissioning,

The Contractor shall specify and formally list the required quantity of ROCC software hardware, as well as all ancillary and support equipment that is necessary for the interconnection and operation of the hardware (such as equipment enclosures and enclosure cabling) identified in the Contract Documents. This shall include specific and formal lists of any and all devices, equipment, and documentation necessary for operation and maintenance of the ROCC software, but which may not have been anticipated in these Specifications.

Proposal Requirement: The Proposer shall provide in his technical proposal sufficient information for WMATA to understand the hardware requirements of the ROCC Software design.

5.2 Hardware Design

WMATA will install the hardware as designed by the software supplier. WMATA will provide all physical devices including computers, work stations, servers, switches, routers, modems, racks, desks, monitors, cable tray, furniture, and display screens. Items such as furniture, desks, and display screens are already in place or will be installed by WMATA. In the case of work stations some will be provided directly to the Contractor for his use in setting up a lab and for development work. The balance will be installed by WMATA.

Page 116


The Contractor shall provide a list of all items such as wire, cable, grounds, connectors, power strips, etc. needed to make a complete and serviceable installation to WMATA for procurement. This includes the design for CTF, JGB, and WMATA’s PET Room for testing off the software and hardware.


a) Provide as-built drawings of each rack as delivered for installation, b) Work with WMATA to document the final installation and provide comprehensive as-built drawings

documenting all interfaces including power, c) Plan and design all installation work in accordance with an approved staging plan and present the

planning and design in a comprehensive Hardware Installation Design developed in coordination with WMATA.

5.3 Hardware Installation

The Contractor shall develop and submit for approval a detailed, comprehensive Hardware Installation Design that provides planning for all of the work and work responsibilities, and defines and describes the requirements for the installation of the ROCC software equipment, cabling, cableways, power connections, and power distribution.

The Hardware Installation Design shall include installation drawings, Specifications, design calculations, and narratives documented in the Hardware Installation Design Package.

For equipment cabinets installed in aisle ways, equipment cabinets shall be installed such that with both sets of equipment cabinet doors open into an aisle, sufficient space remains for personnel with an equipment cart to maneuver through the aisle.

All design calculations shall be included as part of the design.

Design calculations for all CTC equipment, cabling, and temporary work shall include at a minimum:

a) Cable and wire sizes; b) Cableway fill calculations per conduit or cable tray run; c) Cable bending radii by cable type; d) Filled cableway weight per attached/support point; e) Equipment weight per enclosure; f) Equipment electrical loads per supply source; g) Equipment breaker and fuse sizes; h) Heat budget per room.

The Contractor shall perform and/or document all installation consistent with required submittals including, but not limited to, the following:

a) Hardware Design Description (CDRL T403) b) Hardware Specification (CDRL T404) c) Hardware Inventory List (CDRL T405) d) Hardware Configuration Block Diagrams (CDRL T406) e) Rack and Enclosure Assembly Drawings (CDRL T407) f) Hardware Test Configuration Drawings (CDRL T408) g) Hardware Installation Design (CDRL T409) h) Interfaces

6. Interfaces

The ROCC utilize several WMATA External Systems for additional support of WMATA rail transit operations. The ROCC software shall integrate with the WMATA External Systems to provide a seamless interface across all supporting systems.

The purpose of interfacing to the WMATA External Systems shall be to import data for use by the ROCC software and/or to provide data to the WMATA External Systems for external system internal use.

Page 117


The WMATA External Systems that shall be interfaced include the following:

a) Passenger Information Display System (PIDS) b) Automated Energy Management System (AEMS) c) Trapeze Scheduling System d) Maximo e) Train-to-Wayside Communications (TWC) f) Track Circuit Monitor Tool (TCMT) g) Train Progress Server (TPS) h) Rail Performance Monitor (RPM) i) WMATA video systems j) WMATA radio systems

The Contractor shall perform an analysis of current WMATA rail transit operations to determine and document how the WMATA External Systems are presently integrated and how the ROCC software will handle integration of these external systems, subject to prototyping.

At the current time WMATA has some non-Ethernet based interfaces. The Contractor shall assume that within the time duration of this Project all non-Ethernet based interfaces will be replaced with Ethernet based interfaces. Throughout this contract there are descriptions of interfaces to legacy or new systems. The Contractor shall work with WMATA to define the required interface, identify the necessary hardware, rack mount and test the hardware. WMATA will procure the hardware.

6.1 Core System Connections/Redundancy

WMATA will provide 4 dark single mode fibers from CTF to JGB through a space diverse path for the purpose of synchronizing the CTF and JGB ROCS systems. The Contractor shall identify the desire network interface hardware, which WMATA will supply.

6.2 DTS – Data Transmission System

WMATA’s original SCADA system (DTS – Data Transmission System) used synchronous technology which carried all train control and select other data such as fire alarm, select breaker control, and ventilation controls. That legacy system has since been converted to work over Ethernet via specialized firmware (MERCS – Modbus Embedded RTU Communications Server.) This legacy system controls the entire system except for the new Dulles extensions (Silver Line.) These legacy devices will sometimes be called the Horton system or Horton RTU. This data is contained and communicated/connected to the existing ROCS control system.

WMATA is presently migrating from an S9600 via the MERCS to a Genisys protocol over Ethernet. The Contractor shall be required to communicate via both systems while WMATA is in transition. Each protocol will utilize a separate network.

6.3 AEMS – Automated Energy Management System

WMATA eventually installed an additional SCADA system (AEMS – Automated Energy Management System) based upon a Quindar/QEI solution. This system monitors additional power substation and tie breaker points not normally reported through the DTS system. WMATA maintains a QEI head-end and reports this data to the control center for display on maintenance desks, not the dispatch desks.

WMATA utilizes an Automated Energy Management System (AEMS) provided by supplier CG Automation to perform management functions of the Traction Power system connected in the field. The Controls and indications are independent between the existing ROCC software and AEMS, except that they communicate via separate paths to the field RTUs. The ROCC software shall coordinate with WMATA IT services to determine what data needs to be passed between the ROCC software and Traction Power RTUs in the field in order for AEMS to continue performing in a real time fashion.

Page 118


6.4 Further DTS/AEMS Developments

The Silver Line will use native Ethernet communications, in part QEI based and in part using other systems. The normal segregation of traffic observed between DTS and AEMS will not be continued. The Contractor shall extract data from both systems as necessary. The Contract scope initially involves mapping only the existing data points. At time of bid the Contractor shall consult with WMATA to obtain direction in regards to additional data points.

For purposes of system design, the Contractor shall be aware that SCADA Traction Power will communicate with the listed systems via the following mechanisms:

a) ROCC software – via current MERCS interface and also via DMP3 interface being currently deployed; b) Automated Energy Management System (AEMS) – via DMP3 interface being currently deployed; c) Displays outside of OCC – via Modbus; d) WMATA customer service Webpage – via HTML.

6.5 Track Circuit Occupany Reports

The existing ROCS outputs track circuit occupancy data in text files to be used by the Train Progress Server and CB-EMIS/Protect computer. The Train Progress Server is a WMATA developed application/hardware package which uses track occupancy information from the ROCS and other data to generate a variety of reports. These reports are widely used for operational purposes throughout WMATA and are critical to normal operation. The CB-EMIS/Protect is a Chemical/Biological detection system that also uses these text based reports to inform automatic responses. In both cases these are output only, ROCS takes no input from either system. WMATA desires that these text reports be retained to drive the existing systems and for future additional use. The Contractor shall work with WMATA to define these text based output needs and supply them in the ROCC software as desired by WMATA.

6.6 Passenger Information Display System (PIDS)

The existing ROCS provides customized train prediction data to a legacy system. WMATA is in the process of updating that system to a ComNet system. The Contractor shall be required to provide interfaces to both systems as the transition takes place. The legacy signage interface (AIM PIDS CLIENT) resides in existing ROCS software and drives a LightLine 3.0 server. The Contractor will need to research and document and duplicate this interface. The Contractor shall be required to work with WMATA and ComNet to define that interface. The Contractor shall assume that the ComNet interface will be via a Ethernet connection.

WMATA utilizes a Passenger Information Display System (PIDS) that alerts riders of the status of train traffic. Presently the PIDS is an Inova Systems product, but WMATA is in the process of migrating PIDS to a new CommNet system. It is scheduled to be completed prior to NTP of this contract.

The Contractor shall provide the same existing data, format and protocol to the PIDS system. This includes all train performance data being communicated from the ROCC software to PIDS.

The ROCC software shall coordinate with WMATA IT services to determine what data needs to be passed to PIDS in order for PIDS to continue performing in a real time fashion.

6.7 Train-to-Wayside Communications (TWC)

Train-to-Wayside (TWC) Communications are presently accomplished via three discrete installed systems. TWC provides the car numbers, destinations codes, and other information to the ROCC software. The Contractor shall interface with TWC.

The ROCC software shall provide an interface with WMATA’s Train-to-Wayside Communications (TWC). The ROCC software shall provide support to, including indications of, all of the data currently exchanged by TWC including, but not limited to the following:

a) Vehicle door status – open or closed; b) Three-character train number;

Page 119


c) Two-character train destination; d) Vehicle length; e) Vehicle operational status – automatic or manual; f) Automatic Train Protection – on or off; g) Automatic Train Stop.

6.8 CB-EMIS/Protect

The existing software supports the CB-EMIS/Protect computer. The CB-EMIS/Protect computer requires train progress information in order to perform its functions. The Contractor shall mimic the WMATA “9001 Port” in order to provide an interface with the CB-EMIS/Protect computer. The ROCC software shall provide an interface with WMATA’s PROTECT CBEMIS system manufactured by Smiths Detection.

Process guidance shall be provided for use in conjunction with WMATA’s existing biological chemical monitoring system, CBEMIS.

CBEMIS works with another biological monitoring system PROTECT.

a) The ROCC software shall provide process guidance to assist users in processing situations whenever the CBEMIS-PROTECT systems report a hazardous condition.

b) The Contractor shall work in conjunction with WMATA to develop the assistance scripts for assisting users during CBEMIS-PROTECT events.

6.9 Track Circuit Monitor Tool (TCMT)

The ROCC software shall provide an interface with WMATA’s Track Circuit Monitor Tool (TCMT). The functions performed by TCMT including, but not limited to loss of shunt detection. The Contractor shall consult with WMATA to research, analyze, and incorporate all TCMT functions into the ROCC software.

The ROCC software will interface with TCMT as necessary to provide support for the Loss of Shunt Report. All track circuit occupancy data from the field shall be provided to the TCMT.

6.10 Schedule

WMATA has a dedicated schedule department which prepares and publishes the schedules. WMATA is currently using Trapeze Scheduling System software but is in the process of purchasing new software, of unknown Contractor. The Contractor shall work with WMATA and the scheduling software provider to develop the appropriate interface between the two systems and the processes by which the schedules will be loaded, and maintained on the ROCC software.

WMATA currently utilizes a Trapeze Scheduling System to manage personnel and rolling stock schedules. WMATA is in the process of procuring a new scheduling system. The Contractor shall work with the new Contractor of the scheduling system to provide a “hands off” interface that provides WMATA operations the ability to select schedules and have them automatically loaded into the ROCC Control Software.

The ROCC software shall download the WMATA schedule for use in train tracking and identification. The Contractor shall coordinate with WMATA IT services to determine what data needs to be exchanged between the ROCC software and the WMATA Scheduling System.

The ROCC software shall include the ROCC software Schedule Viewer – a user interface for viewing WMATA schedules. The Schedule Viewer shall provide an Authorized User with the ability to select and view any of the variety of schedules in the WMATA scheduling system.

WMATA is presently considering options concerning the choice of internal scheduling software and will likely be moving away from the current Trapeze application within the timeframe of this Contract. The Contractor shall work in conjunction with WMATA during system design and is obligated to provide ROCC software support of the chosen WMATA internal scheduling software when/if a new product is selected within the implementation timeframe of this Contract. The Contractor shall meet all requirements for the new WMATA internal scheduling software as are specified herein for the Trapeze scheduling software.

Page 120


6.11 Maximo

The ROCC software shall interface with Maximo, the internal WMATA incident/event management system. The interface will be varying according to which options may be selected. The ROCC software shall pass event information to Maximo, including Incident Reporting System (IRS) data. Furthermore, all data from the Incident Reporting System to Maximo as it is entered into the IRS in near real time shall be included.

The ROCC software shall pass train movement information to Maximo.

The ROCC software shall implement and be delivered with a number of ‘canned reports’ that are currently used by WMATA. The reports to be supplied include, but are not limited to, the following:

a) Schedule Adherence Report b) System Performance On Time Summary Report (SPOTS) c) Line Performance “Squiggly Line” Report d) Incident Summary Report e) Speed Restriction Report f) Other TBD (Quantity = 10)

The canned reports to be provided as part of the ROCC software shall be listed in an Appendix to the Contract Documents. All canned reports shall be provided, with the list above being just a subset.

Precise design of the format and content of all information to be transferred from the ROCC software and Maximo shall be determined by meetings between the Contractor and WMATA to take place during ROCC software design.

6.12 Train Progress Server - /* BID OPTION */

As a separate bid option not to be included in the Contractor’s base bid, the Contractor shall propose how, or if, the ROCC software will provide an interface to, or replacement of, the WMATA Train Progress Server:

a) The ROCC software shall interface with, or replace, WMATA’s Train Progress Server. b) The connection to the Train Progress Server or replacement shall be via the existing WMATA server

9001 Port. c) The ROCC software shall exchange data with the Train Progress Server or replacement to the extent

needed in order to obtain any data that is required to produce all of the reports as have been provided to the Contractor in the Procore project data store.

d) The ROCC software shall transmit all Historical Data to the Train Progress Server or replacement. e) The Contractor shall work in conjunction with WMATA personnel to determine the precise format that

any agreed exchange of data should take.

6.13 Rail Performance Monitor (RPM) - /* BID OPTION */

As a separate bid option not to be included in the Contractor’s base bid, the Contractor shall propose how, or if, the ROCC software will provide an interface to, or replacement of, the WMATA Rail Performance Monitor:

a) The ROCC software shall interface with, or replace, WMATA’s Rail Performance Monitor. b) The ROCC software shall exchange data with the Rail Performance Monitor or replacement as needed

to provide for the exchange of train progress data. c) The ROCC software shall exchange data with the Rail Performance Monitor or replacement as needed

to provide an interface to WMATA rail yard control panels. d) The Contractor shall work in conjunction with WMATA personnel to determine the precise format that

any agreed exchange of data should take.

6.14 Integration of Playback with Radio Communication - /* BID OPTION */

As a separate bid option not to be included in the Contractor’s base bid, the Contractor shall propose how, or if, the ROCC software will incorporate stored WMATA radio into the Playback function:

Page 121


a) WMATA wishes for historical radio feeds to be synched with the ROCC software displays and interactions from the chosen time period for replay during playback.

b) Third party software currently being used at WMATA is from NICE Systems, but the Contractor shall be aware that WMATA changes audio software often and that multiple video/audio products are likely to be used during the expected life cycle of the ROCC software.

c) The cost to WMATA for such integrated audio functionality shall be presented as an option and not included in the Contractor’s base ROCC software bid price.

d) The Playback function shall provide the capability to execute from any RROCC Workstation.

6.15 Integration of Playback with CCTV Video Management System - /* BID OPTION */

As a separate bid option not to be included in the Contractor’s base bid, the Contractor shall propose how, or if, the ROCC software will incorporate stored WMATA CCTV Video into the Playback function:

a) WMATA wishes for historical CCTV video images to be synched with the ROCC software displays and interactions from the chosen time period for replay during playback.

b) Third party software currently being used at WMATA is from CNL. c) The cost to WMATA for such integrated video functionality shall be presented as an option and not

included in the Contractor’s base ROCC software bid price. d) The Playback function shall provide the capability to execute from any RROCC Workstation.

6.16 List of Applications used at OCC

A table of software applications that currently operate in the Rail OCC Center are contained in the table below. The ideal software package would interface with a wide range of these applications. The Contractor shall detail in his technical proposal which software applications interface with the baseline ROCC software and which are options to the ROCC Software.

Page 122


Application Usage

AIM OCC Monitor and Control

AIM PIDS Application providing train information to Comnet

AIM 9001 Provides train information to other vital applications

Automated Energy Management System (AEMS)

Provides Monitoring and Control to Substations, Elevators, Escalators and other devices

Automatic Car Identification System is currently not functioning

Call Center Customer Support

Chemical Biological– Emergency Management Information System

Security Application for Stations

Documentum Document management/change control

General business tools – MS apps, etc.

Productivity Software

GIS Graphic Information Systems

IT Security AnitVirus and other security related measures

Maximo Asset & management, Trouble tickets , Maintenance scheduling

MERCS Embedded RTU Communications Server

PeopleSoft Business tools

PM Software Project Management process/procedure

Rail Progress Server Railcar milage and Yard Management, gateway to Maximo

SpecTech Specifications & Standards generation

TCMP Track Circuit Monitor Program

Page 123


Train Progress Server Provides tracking, monitoring and reports of operating trains

Trapeze Existing Run cutting/scheduling

Page 124


7. Software Functionality – Rail Transit Operations

The ROCC software shall provide rail and tunnel operations monitoring and control software modules to include, but not be limited to, the following:

Train Tracking Identification Schedule Display Real Time Schedule Modification Single Track Train Identification Train Record Train Propagation Multiple Occupancies of a Single Track Train ID Data Schedule Adherence Train Run Origination Changing Train Icon Reversing Direction Train Run Termination Train Tracking Alarms and Advisories Train Tracking User Interface Traction Power Tunnel Ventilation Drainage Pumps Route Alignment, including Manual Mode Route Selection, Entrance/Exit (N/X) Routing, Route Canceling, Through Routing, Train Order Indications, Fleeting, Call-On, Auxiliary Switch Control, Track Out of Service, and Locking Indications.

All functions and software modules shall be subject to user interface prototyping. The Contractor may be required to perform studies and make recommendations to develop the final software modules.

Proposal Requirement: The Proposer shall provide in his technical proposal detailed information about the Rail Transit functionality of the software.

7.1 ROCC Take Control Button

The Contractor shall provide a ROCC Take Control button on the ROCC Supervisors console display. Using two factor authentication, this button shall transfer control of the rail road to whichever ROCC initiated and confirmed the request from the button. The ROCC Supervisors console in both ROCCs shall be notified of a requested change. The Contractor shall work with WMATA to develop the policies and procedures required to make this transfer of control happen.

The ROCC Supervisor console shall display the status of the ROCC. Status shall be In Command, Standby, Shadow, Training, Playback, Simulate, or other.

The default operational scenario for ROCC Control transfer shall involve a hand-shaking between the two facilities at the time of transfer:

a) The capability shall be provided for the Standby ROCC to assume command without Active ROCC hand-shaking in the event that the Active ROCC is catastrophically incapacitated.

b) The Contractor shall design the communications between the Active ROCC and the Standby ROCC I/O equipment to facilitate the transfer of control to the Standby ROCC in real time and with no loss of data.

c) The Contractor shall ensure that the transfer from the Standby ROCC to the Active ROCC can be initiated from both ROCC, when the time comes to return control to normal operations.

d) The Contractor shall ensure that it is possible for one and only one OCC to be in control of the WMATA rail territory at any one time. Furthermore, an alarm shall be initiated with if a conflict tries to exist.

Page 125


7.2 Signal System Monitoring and Control

The Contractor shall provide and configure the new ROCC software to monitor and control the entire WMATA field signal system and signaling devices through interface to Field Code Units (FCU). See Contract Drawings for a plan of the existing WMATA controlled signal territory. WMATA is undergoing changes to data collection and the Contractor must be able to adapt to these changes.

The ROCC software shall transmit control data to the FCUs and receive device status indications from FCUs over the code system interface. Typical control and indication data are provided elsewhere in the Contract Documents. (Scan sheet will be provided on WMATA’s Procore) Typical code system data and location point counts (quantities of control and indication data) per location are also provided elsewhere in the Contract Documents. Currently, WMATA’s ROCC software contains 50,000 points and it is being increase with the new Silver line with an additional 30,000 points. (Scan sheet will be provided on WMATA’s Procore) The Engineer will furnish code charts describing serial communication of control and indication data for each FCU location in accordance with these Specifications. The code charts will be furnished after award in a time frame so as to not impact the Contractor’s final design. The Contractor software package shall be able to handle unlimited data points.

To the extent defined by this Specification, the display and control functionality of the new WMATA ROCC software shall emulate the existing WMATA ROCC system displays and control functionality. The WMATA ROCC software is currently operational at the CTF and the JGB. WMATA ROCC system shall be as defined within this Specification and as determined during prototyping.

7.2.1 Topographic Database

A topographic structure of the database will be implemented so that future changes and revisions may be incorporated with minimal modifications to the existing database:

a) The ROCC software database shall provide Authorized Users the ability to query and sort the database by field interface devices and physical locations.

b) The ROCC software shall incorporate and maintain a Topographic Database (TopoDB) of the entire WMATA system, exclusive of non-monitored areas. Non-monitored areas will be modeled for future monitoring.

c) The TopoDB shall include all features and locations of the ROCC software monitored devices and static infrastructure necessary to support the ROCC software functionality.

d) The TopoDB shall include the following data descriptions of the WMATA system, as a minimum:

• System infrastructure including track network, stations, bridges, tunnel portals, etc.; • Signal system devices and facilities including the locations of all switches, signals, train stops,

track circuits, bridges, towers, relay rooms, etc.; • SCADA system devices and facilities including 3rd rail sections, ventilation fans, drainage pumps,

and emergency “blue light” box trip, emergency exits, substation locations, etc.

The TopoDB tables describing the monitored territory shall be sized to handle additional data without requiring reprogramming or recompilation to support modifications. The TopoDB data expansion capability shall not be limited.

7.2.2 Control Functions

7.2.2.1 Routing Control

Routing and other functions shall be performed through Authorized User interaction with graphical ROCC software Displays that replicate the layout of the control territory:

Page 126


a) The ROCC software shall provide monitoring and control of the field signal system based on the assigned control mode: Automatic Control, Remote Control, or Local Control.

b) Remote Control of the field devices shall facilitate office control and monitoring of locations through the ROCC software at either the CTF or the JGB ROCC.

c) Local Control shall provide for monitoring without control by the ROCC software, with control exercised from a Local Control Panel in a wayside room.

7.2.2.2 Automatic Control

Under Automatic Control the field location train arrival and routing shall be based upon Train ID (TID) in the field logic. Destinations shall be based on and driven by the TID in the train cab in conjunction with the Train-to-Wayside-Control (TWC) units in the field.

Automatic Control mode shall be the default mode of operation for each interlocking location when not assigned to Local or Remote Control Mode by an Authorized User. Convenient means shall be provided for Authorized User to switch between control modes, subject to system prototyping. Control mode assignment and processing with the ROCC software shall be on per interlocking basis.

7.2.2.3 Remote Control

The ROCC software shall only transmit controls to the field signal system when a location is in Remote Control, with the following exceptions:

a) Requests to assert control of a location; b) Employee call devices.

Whenever interlocking control is assigned to a location in Local Control, the ROCC software shall inhibit both user-entered and ROCC software software-generated control and routing requests to the associated location signaling devices. The ROCC software shall continue to indicate the status of all devices and update all ROCC software Displays for all interlockings in Local and/or Automatic Control.

7.2.2.4 Local Control

Control from a location other than from the ROCC software is referred to as “local control”. When location is not in local control, the interlocking location is by default in automatic control.

When control is transferred from Remote or Automatic Control for a location to Local Control, the ROCC software shall require Confirmation Validation from an Authorized User in the OCC prior to completing the transfer. Local Control cannot be assumed in the field without authorization from the ROCC software.

When a location is in the Local Control mode, the ROCC software shall not alarm uncommanded changes of state for those devices that are controllable from the local control panel.

7.2.3 Traffic/Direction Control

The ROCC software shall provide traffic controls and indication of traffic direction where provided in the field signal system. Train routes shall be established using both the beginning and the end of the route. All ROCC software train movements or track operations shall follow all applicable Standard Operating Procedures as defined in the WMATA Metrorail Safety Rules and Procedures Handbook (MSRPH).

7.2.4 Blocking

Activities occur on every railroad and transit system that do not shunt the signal system and which require “protection”. These activities can include such things as the occupancy or movement of track cars that do not shunt or reliably shunt the signal system, tracks out-of-service for maintenance work, etc.

This “protection” can be in the form of not throwing a switch or other device, not clearing a signal, not aligning a route, etc. Blocking is a technique for assisting Authorized Users in providing such protection. WMATA currently provides protection via application of blocking devices on control levers of the exiting CTC machines,

Page 127


and in the case of the new ROCC software & existing WMATA ROCC system, blocking circuitry in the field signal system:

a) The ROCC software shall support all existing blocking functionality (office and field blocking). b) The ROCC software shall validate all Authorized User blocking requests against field device

capabilities prior to completing a block. c) WMATA utilizes multiple blocking types which the ROCC software shall support.

The Contractor shall coordinate with WMATA personnel to analyze the blocking methods used by WMATA and shall provide them with the ROCC software. The blocking structures that are provided as part of the ROCC software shall replicate the blocking structures as defined in the WMATA Metrorail Safety Rules and Procedures Handbook (MSRPH).

The blocking methods to be supported shall include the following:

a) Absolute Block; b) Filler Block; c) Heel Block; d) Interlocking Block; e) Latch Block; f) Permissive Block; g) Switch Block; h) Terminal Block; i) Traffic Block.

7.2.4.1 Switch/Device Blocking

For all interlockings, the ROCC software shall provide the capability for Authorized Users to apply switch blocking to selected devices in a manner that emulates the existing CTC equipment, except as modified by these Specifications.

Authorized Users shall have the capability to remove switch blocking from selected devices, consistent with existing CTC equipment operation except as modified by these Specifications. The ROCC software shall provide the same capabilities for Authorized User control of both office blocking and field based switch blocking as provided in the current signaling.

Switch/device blocking shall be indicated on all ROCC software Displays, regardless of application type, office blocking or field blocking. A means of distinguishing blocking type on ROCC software Displays shall be defined during prototyping. When a switch is blocked, the office ROCC software shall inhibit controls that would cause the switch to move. This shall include but not be limited to preventing the interlocking from being placed in an automatic mode that could cause the switch to operate:

a) Switch blocking shall not prevent routes from being aligned over the switch in the blocked position. b) Switch blocking shall be applicable to all controllable, movable devices such as derails and smash-

boards.

Authorized Users shall have the capability to perform switch blocking operations on selected devices by selecting the switch on the ROCC software Display and selecting the desired operation from a pop-up menu.

7.2.4.2 Track and Exit Blocking

For all interlockings, the ROCC software shall provide the capability for Authorized Users to apply track and exit blocking to selected devices in a manner that emulates the existing WMATA ROCC CTC system equipment, except as modified by these Specifications.

Track and Exit blocking shall be provided that prevents a route from being requested into the blocked track section. The block shall not prevent routes from being aligned leaving a blocked section. Likewise, the ROCC software shall implement a Prohibit Exit function which will make a particular exit unavailable until the Prohibit Exit is removed. Authorized Users shall have the capability to remove track or exit blocks from

Page 128


selected devices, consistent with existing WMATA ROCC CTC system equipment operation except as modified by these Specifications.

The ROCC software shall provide the same capabilities for Authorized User control of both office blocking and field based track and exit blocking. When a track or exit is blocked (or prohibited), the office ROCC software, shall inhibit any control that would establish a route into a blocked track. Control inhibits shall include preventing the interlocking from being placed in an automatic mode that could cause the route to be aligned.

7.2.4.3 Signal Blocking

For all interlockings, the ROCC software shall provide the capability for Authorized Users to apply signal blocking to selected devices in a manner that emulates the existing WMATA ROCC CTC system equipment, except as modified by these Specifications:

a) Authorized Users shall have the capability to remove signal blocking from selected devices, consistent with existing WMATA ROCC CTC system equipment operation except as modified by these Specifications.

b) The ROCC software shall provide the same capabilities for Authorized User control of both office blocking and field based signal blocking.

c) The ROCC software shall provide the capability for blocking a signal whenever the selected signal is set for and indicating stop and the signal is not running time.

d) When a signal is blocked, the office ROCC software shall inhibit any control that would cause the signal to clear in the field. Control inhibits shall include preventing the interlocking from being placed in an automatic mode that could cause the signal to clear.

e) Signal blocking shall not prevent routes from being aligned past the signal in the opposite direction to that which it governs, i.e., using the signal location as a route exit.

7.2.4.4 Roadway Workers Protection (RWP)

The ROCC software shall implement a condition for WMATA referred to as Roadway Workers Protection. An Authorized User shall have the ability to mark a section of track as being an active Roadway Workers Protection area:

a) The boundaries of a Roadway Workers Protection area shall be denoted on the ROCC software Displays, including the overview, with an unambiguous marking, subject to prototyping.

b) Any switches and signals that are located within the boundaries of a Roadway Workers Protection area shall be blocked such as to prevent a train from reverse running within the boundary.

c) Roadway Workers Protection shall follow all RWP rules as defined in the WMATA Metrorail Safety Rules and Procedures Handbook (MSRPH).

d) The Contractor shall be obligated to work with WMATA personnel to provide an acceptable implementation of Roadway Workers Protection as used on WMATA Rail Territory.

7.2.4.5 Additional Office Blocking Requirements

The ROCC software Office Blocking logic shall address any “through routing” and/or “alternative routing” capability that exists. The ROCC software shall inhibit any control that would cause a blocked switch to move, a blocked signal to clear, or a route to be cleared/aligned into a blocked exit or track.

7.2.5 Miscellaneous Signal Devices, Controls, and Indications

7.2.5.1 Employee Call

The ROCC software shall provide Authorized Users control of all Employee Call devices. Control and indication shall be consistent with the existing WMATA ROCC CTC system. Applicable ROCC software Displays shall provide current status indications of all Employee Call devices.

7.2.6 Control Action Validation

Subject to user interface prototyping, Control Action Validation shall minimally include the following checks:

Page 129


a) Entrance button: no route exiting at the entrance or trailing point switch locked against the entrance, no entrance or signal block, no other entrances selected at the interlocking;

b) Exit button: an entrance has been selected, traffic not locked against the exit, no exit or track block, switch not locked in a position away from the exit;

c) Switch: switch not locked or blocked, including no Roadway Workers Protection; d) Signal: no route exiting at the signal, signal not blocked, trailing point switch not locked against the

route; e) Fleeting: entrance or signal requested; f) Call-on: approach track occupied; g) Switch Blocking: normal or reverse, i.e., in “N/X” mode.

Where a control request fails Control Action Validation, a user advisory shall be provided to the appropriate Authorized User requesting the control with a description of the reason the control request failed. Descriptions of reasons for control request failure shall be in normal English and shall be understandable without need to reference a list of error codes.

7.2.7 Alarms and Advisories

The ROCC software shall display, annunciate and provide acknowledgement of alarms in a manner consistent with the existing WMATA ROCC system, subject to prototyping. It is noted that WMATA control center operations is dissatisfied with the handling of alarms in the existing WMATA ROCC system. Specifically, the existing WMATA ROCC system produces an excessive number of alarms so as to render the constant crush of alarms essentially moot. The Contractor shall work in concert with WMATA control center operations to identify and report the number of alarms that are necessary to alert personnel to notable conditions in the field without overloading the alarm notification system with an excessive amount of “noise”.

7.2.8 User Interface

All user interface displays and Authorized User interactions shall be subject to user interface prototyping, including the user interface elements and interactions described in these Specifications:

a) SCADA shall include Traction Power, Tunnel Ventilation, and Tunnel Drainage as documented elsewhere in the Contract Documents.

b) All CTC and SCADA user interface displays shall conform to the requirements regarding display control as described in Specification Section 2.8 WMATA Display Control.

Displays shall be provided that indicate static and dynamic states of devices monitored by the ROCC software through interfaces to all systems, and that facilitate Authorized User interactions with the monitored devices that are also controllable.

Pop-up menus shall be provided for each object on all ROCC software Displays including objects that appear on more than one type of ROCC software Display, to minimally select display of object properties, but also to initiate any control actions available for the object and/or select submenus. All monitored devices shall be capable of displaying a “Properties” sub display via selection on the device’s popup menu.

The Properties shall minimally provide the following information:

a) Object type and name; b) Stationing (location) in chains + feet; c) Associated interlocking; d) Current states; e) Associated code unit the device is monitored and controlled (as applicable) from; f) Any and all associated active operational conditions; g) All quality codes; h) For controllable devices, current CTC/TP User(s) with control responsibility assigned.

Quality indicator or code status shall minimally include: scan monitoring, alarm inhibits, manual data insertions.

Page 130


7.2.8.1 Displays – General

Samples of all display objects and states shall be identified by the Contractor during prototyping. Review of the Contractor’s development of the initial samples, as well as additional display objects and states will be determined during user interface prototyping.

Track displays of the ROCC software Displays shall depict the entire WMATA rail territory and right-of-way infrastructure (such as stations) and shall include all monitored and unmonitored territory:

a) The Contractor shall modify the ROCC software and track displays as territory changes for the duration of the contract.

b) The Contractor shall include yard territory in the displays. Currently, only the yard at West Falls Church and the proposed Dulles extension has indicating track circuits.

c) The Contractor shall provide an option to work with WMATA and develop displays for the yards without indicating circuits.

d) The Contractor shall submit for approval a “Display Conventions and Guidelines Document” (CDRL T201) that provides approved ergonomic guidelines for track design and optimizes the amount of territory that can be viewed per display device. Efficient use of display device viewing area is a major objective of WMATA.

e) All ROCC software monitored devices shall be represented individually on ROCC software Displays. f) All features and standards for development of ROCC software Displays shall be defined in the Display

Conventions and Guidelines Document. g) All display objects on ROCC software Displays shall be in their proper relation, although not to scale,

to other objects as the actual track network and devices that they represent. h) Any and all alarms associated with monitored devices shall be able to be presented and acknowledged

on any and all ROCC software Displays. Presentation of alarm states on the ROCC software Displays shall be subject to user interface prototyping.

7.2.8.2 Control Displays

ROCC Control Displays shall be developed to facilitate Authorized User interaction of controls on graphically formatted displays. The ROCC software shall be capable of supporting all ROCC Control Displays as indicated in the Contract Drawings, Specifications, or Scope of Work.

All Authorized User interaction request states, user advisories, and system feedback information shall be displayed. As a minimum, the following devices and operational conditions shall be displayed at the default magnification, on the ROCC Control Displays:

a) All mainline and yard trackage, yard leads, route alignment, track circuit and reporting point occupancy and routing states;

b) Stations; c) Controlled Signals and numbers; d) Automatic Signals and numbers; e) Train stops; f) Track Circuit numbers; g) All train icons, real-time train location, and train status. At default zoom, train ID numbers shall be

displayed in train icons; h) All monitored device status; i) 3rd rail energization status (normally de-cluttered, unless deenergized); Breakers associated with each

3rd rail section; j) Blocked devices; k) Tunnel ventilation equipment, (normally de-cluttered); l) Drainage pumps (normally de-cluttered); m) Emergency exits, (normally de-cluttered); n) Track topography (normally de-cluttered):

• Underground track; • Viaduct or otherwise elevated track; • At-Grade track;

Page 131


• Pronounced incline or decline (> x%); • Pronounced curve (> x%); • Adjacent railroad (which side);

o) Traffic direction and states; p) All control and routing modes; q) Device and locations Alarms; r) Time Clock; s) Device selection response and all system feedback control responses; t) Notifications and control action confirmation; u) Other device indications defined during prototyping.

The following devices can removed from view when a simple Authorized User command is selected on each interlocking:

a) Automatic Signals; b) Signal numbers (controlled and automatic signals); c) Switch numbers; d) Track circuit numbers; e) Tunnel ventilation equipment; f) Emergency exits.

Capability shall be provided for Authorized Users to place and arrange ROCC Control Displays on any other ROCC monitor.

7.2.8.3 Overview Displays

Overview Displays shall be developed separately from ROCC Control Displays specifically to present a macro-view of the operation, and to facilitate management oversight as well as the Video Display Wall. These displays will be used on the Video Display Wall. Additionally, if desired, the Overview Display shall be capable of also being displayed on an RROCC Workstation monitor. The ROCC software shall be capable of supporting all Overview Displays as indicated in the Contract Drawings, Specifications, or Scope of Work.

The Overview Display shall be a continuous, geographically correct layout of the entire monitored rail territory. “Geographically correct” means at least to the extent that all display objects on the Overview Display shall be in their proper relation, although not to scale, to other objects as the actual track network and devices that they represent.

Capability shall be provided for Authorized Users to display all or selected portions of the Overview Display in a window or windows on an RROCC Workstation monitor. When less than the entire territory is displayed in a window, scroll bars and/or panning shall be provided for Authorized Users to navigate along the railway.

Control actions associated with display objects and icons presented on the Overview Displays shall be facilitated from the Overview Displays. Yard leads shall be depicted on the Overview Displays. At WMATA approved default magnification, the following devices and operational conditions shall at a minimum be displayed on the Overview Displays:

a) All mainline trackage, yard leads, route alignment, track circuit and reporting point occupancy and routing states;

b) Stations; c) Yards; d) Controlled Signals; e) All train icons, real-time train location, and train status; f) 3rd rail energization status; g) Engineer selected blocked device types; h) Tunnel ventilation equipment; i) Emergency exits; j) Traffic direction and states; k) Office control modes;

Page 132


l) Time Clock; m) Event Clock; n) Other device indications defined during prototyping.

Subject to Engineer direction during user interface prototyping, devices and states represented on Overview Displays, e.g., controlled signals may be different/simplified than the same symbols and device states on the ROCC software Displays.

7.2.8.4 Alarm Window Displays

See elsewhere in the Contract Documents for the specification of alarm windows.

7.2.8.5 Time Clock

The Contractor shall provide the display of the current time on each workstation as well as the Video Display Wall. The attributes of the Time Clock that will be displayed on the Video Display Wall and each ROCC Workstation shall be determined during prototyping. Time synchronization shall be across all machines, all applications, and all devices. See Specification Section 2.8 WMATA Display Control for additional specification of Master Time requirements.

7.2.8.6 Restriction Summaries

Restriction Summaries shall be provided that list all blocked devices, all data points, devices and data sources that are out-of-scan (not being updated), and all alarms that are inhibited. If an entire telemetry data source such as a pair of redundant field devices are out-of-scan (office restriction), the Restriction Summary Display shall identify the data source as “Not Reporting”. Each device and data value of the data source shall not be individually identified.

The Restriction Summaries shall be capable of being sorted and filtered by:

a) Device type; b) Restriction type (blocks, devices and sources not reporting, etc.); c) Blocking type; d) Locations.

Capability shall be provided for Authorized Users to view and print a report formatted version of the Restriction Summaries.

7.2.9 Miscellaneous Systems

7.2.9.1 Auxiliary Lights

The ROCC software shall provide on/off controls and status indications for Train Departing Lights where implemented in the field.

The ROCC software shall provide indications of Door Opening from the field. An alarm shall be raised if any of a number of conditions exist at the time of Door Opening including, but not limited to, the following:

a) Train is not berthed at the correct position; b) Incorrect door is opened; c) Key position is incorrect.

7.2.9.2 Emergency Trip Stations (ETS)

The ROCC software shall provide status indications for Emergency Trip Stations installed at various locations throughout the field. ETS, commonly referred to as blue light stations, provides the ability for individuals standing at the wayside to activate an emergency deenergization of the 3rd Rail section associated with the ETS. Each ETS location shall be physically depicted on the ROCC Displays.

The ROCC software shall provide one general ETS activation alarm at each TPSS and TBS with live ETS pushbutton indications on the rail schematics:

Page 133


a) The depiction of the ETS on the ROCC Display and Historical Data log of the event shall clearly indicate if the ETS has been activated.

b) Indication shall identify the precise ETS button that was activated and not just an ETS “zone”. c) Activation of an ETS is a critical emergency event; indication of an activated ETS on the ROCC

software shall visually and audibly be commensurate with the criticality of this event. The ROCC software alert of an ETS event shall ensure that ROCC software users do not “miss” this occurrence.

d) Upon activation of the ETS the ROCC Displays shall indicate the deenergized 3rd Rail section.

7.2.10 SCADA Device Monitoring and Control

a) The ROCC software shall monitor, control, and display 3rd rail energization status. b) The ROCC software shall have the ability to open and close breakers throughout the entire WMATA

Rail Territory. c) The ROCC software shall be able to remove or restore power to 3rd Rail sections which will display

the 3rd rail gap corresponding to track circuits throughout the entire WMATA Rail Territory. d) The ROCC software shall provide a conversion tool that will provide Controllers with the exact circuit

breakers to engage for (de)energization of a track area if chain markers are supplied for the targeted territory.

e) The ROCC software shall provide the ability to monitor, control, and display tunnel ventilation throughout the entire WMATA Rail Territory, including implementation of evacuation fan sequences.

• A fan sequence shall establish the state of all fans in a zone.

f) The ROCC software shall provide the ability to monitor, control, and display tunnel drainage throughout the entire WMATA Rail Territory.

g) The Existing Blue light stations are indicated in the current ROCC Software but the only show the position of the buttons / lights.

The new system shall have the ability to bring in all the discrete indication points from all the blue light stations. This shall be indicated in the new ROCC Software. The de-energized section of 3rd rail shall be indicated on both the SCADA and Train Control displayed. This shall trigger a separate alarm and log all data.

7.2.11 Failure Handling Control Action Failure

Unless specifically cited otherwise, all controls shall be subject to requirements for control action failure alarms. Unless specifically cited otherwise, all controls shall be subject to requirements for report-back delay time control canceling and alarm generation.

Control action failure alarms shall not be triggered due to normal reporting delays associated with delayed clearing of a signal in the field. Control action failure alarms shall not be triggered due to normal reporting delays associated with delayed clearing of a route in the field.

7.3 Train Monitoring and Control

The Centralized Traffic Control (CTC) System shall provide a Graphical User Interface (GUI) to allow for monitoring and control of all WMATA train types and train movements that operate on the WMATA system including all scheduled and unscheduled, revenue and non-revenue, work train and on-track maintenance equipment, and special train movements.

The new ROCC software shall accurately track and display the locations, identities, train schedule and other pertinent data of all trains operating in the ROCC monitored territory. The train tracking and identification function shall update train locations on all displays and applications as new data are received from the field. Other CTC functions to be provided shall include, but not be limited to, route alignment, manual mode route selection, entrance/exit (N/X) routing, route canceling, through routing, train order indications, fleeting, auxiliary switch control, track out of service, switch locking, route locking, and time locking. CTC shall also include scheduling functions including tools that assist in administering schedule adherence, schedule display and real time schedule modification.

Page 134


All functions shall be subject to user interface prototyping.

7.3.1 Train Tracking Identification

The Contractor shall be responsible for acquiring a thorough understanding of WMATA train types and train movements that operate on the WMATA system including all scheduled and unscheduled, revenue and non-revenue, work train and on-track maintenance equipment, and special train movements. WMATA will assist the Contractor in meeting this requirement by meeting with the Contractor, answering Contractor’s questions, providing relevant documentation, and permitting a limited number of Contractor personnel to witness train operations at the Primary Rail Operations Control Center at CTF and at the Secondary Operations Control Center at JGB. All of the above WMATA assistance will be subject to WMATA scheduling, availability, and organizational security rules.

Currently all of WMATA mainline interlocking equipment support entrance-exit routing. WMATA utilizes individual switch calls that are available at all mainline locations. Switch calls are used to support procedures for movement of non-shunting vehicles, for example.

The new ROCC software shall accurately track and display the locations, identities, train schedule and other pertinent data of all trains operating in the monitored WMATA rail territory as defined in these Specifications and subject to prototyping.

Train propagation shall be based on the indicated track circuit occupancies, the positions of track switches, signal states, and other pertinent data as defined in these Specifications and subject to prototyping.

Data relating to train identities and attributes shall be obtained from the ROCC software schedule database, and data calculated as each train triggers a set of site-specific conditions. The facility to import the WMATA schedule from the WMATA RPM system and into the ROCC software shall be included by the Contractor as a component of the supplied ROCC software.

The train tracking and identification function shall update train locations on all displays and applications as new data are received from the field. The Contractor shall include in the TTI portions of the System Description Document (SysDD) (CDRL T503), detailed descriptions of all of the TTI algorithms.

The ROCC software shall make a distinction between regular/revenue and “special” trains. For purposes of this Specification, “special” trains will include any and all unusual movements that deserve and/or require special attention by the Authorized Users. Special trains can include non-revenue (“lite”/“deadhead”) movements, single-tracked trains, work trains, scheduled regular/revenue movements, etc.

The ROCC software shall track trains based on train type assigned to each train: regular/revenue train or a special train. Regular/revenue trains shall be denoted in all CTC Displays as solid train icons of the proper color (red, orange, green, blue, yellow, or silver).

Special trains shall be denoted in all CTC Displays as an “outlined” train icon:

a) The Contractor shall perform a detailed analysis of train representation in the existing CTC system and mimic that representation as closely as possible, subject to prototyping.

b) All CTC Displays shall be shown in the Display Conventions and Guidelines document (CDRL T201) and shall be subject to prototyping.

Distinguishing colors and display characteristics shall be subject to Engineer approval during prototyping; the ability to discern both the “field color” of a train (because that determines how the train will be automatically routed by the field logic) and whether the occupancy is a regular/revenue train or a special train is necessary for proper ROCC software operation.

7.3.2 Route Alignment

The ROCC software shall provide the capability to align all routes whether initiated by entrance/exit (NX) or Unit Lever in the field signal system. The ROCC software shall send route entrance and exit request commands

Page 135


to the field in accordance with the field signal system or individual switch position and signal clear commands in manual sequence (mimic Unit Lever) to the field as appropriate for the requested route(s).

As described in these Specifications the ROCC software shall incorporate logic to validate route alignment requests prior to transmitting control requests to the field signal system.

The Office NX method of route request shall be provided for all interlockings regardless of the configuration of the field signal system (field NX or Manual Mode). The Office NX method of route request shall be the default method of route selection.

The ROCC software shall be responsible for the proper sequencing of route request commands to the field signal system to prevent mis-routes. For field NX interlockings, the ROCC software shall not transmit the exit request to the field signal system until validating that the available exit indication is received from the field signal system that matches the user’s selected available exit. The sequence shall be:

a) Authorized User selects an entrance; b) CTC transmits the entrance to the field if it passes validations and CTC displays available exits based

on office logic; c) The user selects an available exit; d) The ROCC softwares transmits the exit request only after the appropriate available exit indication is

received from the field signal system.

For field Unit Lever interlockings in which the Authorized User is utilizing Office NX route selection, the ROCC software shall determine the appropriate switch commands to transmit to the field and wait for the proper switch correspondence indications before transmitting the signal request. The sequence shall be:

a) Authorized User selects an entrance; b) CTC displays available exits based on office logic; c) The user selects an available exit; d) The ROCC software determined the switch positions required for the selected route and transmits to

the field signal system switch position requests for any switch requiring a change; e) When all switches in the route indicate their proper position, the ROCC softwares transmits the signal

clear request to the field signal system.

After choosing an entrance, all route requests shall time out if an exit is not selected after a user-configurable timeframe, in seconds. Auto-routing shall be provided as an available routing mode. WMATA uses the following Terminal, Destination, and approach routing.

When a user applies the Prohibit Exit function, all Auto-routing through that exit shall be canceled as a safety precaution. All interlockings in the field signal system shall have the capability for Authorized Users to utilize manual operation whereby the User selects individual switch and signal clear commands to transmit to the field signal system.

Commands for toggling between modes at locations (Manual or Office NX) shall not be required to use either route selection method. Once an Authorized User initiates the route selection process via one of the selection methods (Manual or Office NX), the other method shall be disabled for that route until control action procedures are completed or canceled.

All control actions, feedback, controls and indications to/from the field signal system for manual route lining of each route shall be fully described in the Interlocking Rules Documentation (CDRL T504).

The CTC functionality shall provide the capability for Authorized User selection and execution of routine operations in an efficient fashion, eliminating the necessity for navigating through multiple displays, dialogs, menus, and text, subject to prototyping. The proposed user interface shall be fully described and illustrated in the Display Conventions and Guidelines document (CDRL T201) shall be subject to prototyping.

The ROCC software shall indicate on the OCC Displays whenever a user performs an “aux call” of a switch (i.e. manual operation of a switch from the OCC).

Page 136


The ROCC software shall include logic such that if a user attempts to choose an exit that is inconsistent with the destination of the train, a warning will be issued that requires the user to reconfirm the chosen exit before the route will be established.

The ROCC software shall include a Work Form (often referenced in the industry as a “Form D”) that shall allow a user to place in any non-standard operations currently active on the system. The exact form and design of the Work Form shall be established during development of the ConOps document during system design.

The ROCC software shall implement Work Forms graphically on the OCC Displays in a similar manner as the existing ROCS by depicting track segments that are affected by a Work Form as being blue in color. The ROCC software shall assist the Line Supervisors by providing Process Guidance upon the enactment of a Work Form for alerting rail personnel.

7.3.2.1 Automatic Field Routing Valadation – Misroutes

The Automatic Field Routing is a field based system and routes trains by destination codes at interlockings. These destination codes are manually implemented by train operators within the CAB of the train and received by the field equipment. These destination codes shall be used in the train tracking system and displayed within the train IDs.

The Contractor shall develop a method within the OCC Software that tracks train by destination codes and compare these codes to the current train schedule alarming any variations that may be considered a misroute. Misroutes are trains that have a different destination code compared to the train schedule. I.E. Trains that are traveling is a specific direction opposite to the terminal station with that destination code shall be alarmed and the train symbol shall flash until corrected.

7.3.2.2 Manual Mode Route Selection

The ROCC software shall provide Authorized Users the capability to establish routes and clear signals using the Manual techniques provided by selecting on the signal and switch graphic on the CTC control screens.

If every switch in a route is not in Office NX mode and properly aligned and in correspondence, CTC shall provide the capability for clearing those signals using Office NX functionality. The CTC control screens for Unit Level operation shall provide Authorized Users the capability to clear signals by selecting ”To Set (Clear)” by selecting the signal on the ROCC software Displays.

The ROCC software shall provide the capability to cancel a cleared signal through the CTC control screens by making a single click on the signal graphic, and then selecting a “cancel signal” from the popup. The ROCC software shall provide the capability to request a call-on after the route request is first established in the normal manner with a single click on the signal graphic and then selecting “call-on” from the popup menu.

The ROCC software shall implement manual routing past a red signal as follows:

a) The user selects a route past a Red signal; b) The route is highlighted without a Clear signal; c) The Line Supervisor will talk the train operator past the Red signal.

7.3.2.3 Entrance/Exit (N/X) Routing

Any and all internal logic execution differences between entrance/exit routing and Office NX operation shall be transparent to the Authorized User, i.e., no discernable difference in user interaction and function execution.

N/X Routing shall require selection of a valid entrance and exit route at an interlocking by the same Authorized User. That is, once a valid entrance is selected by an Authorized User, no other entrance by the same or different Authorized User, or exit by a different Authorized User shall be accepted by the ROCC software until the user that selected the asserted entrance has selected a valid exit or cancelled the entrance:

a) An Authorized User shall have the capability to initiate a route in N/X by selecting a valid entrance from the ROCC software Displays.

Page 137


b) Upon Authorized User selection of a valid route entrance, the ROCC software shall determine all valid available exits for the route and display them on the ROCC software Display.

c) Available Exits shall be displayed based on the following criteria:

• A valid entrance has been selected; • The exit is not a selected or implement route entrance; • A potential route exists from the entrance to the exit, no switches are locked against the route; • The exit is not currently prohibited; • Traffic is established in the proper direction.

d) Route selection shall be completed upon selection of a valid available exit route by the Authorized User from the ROCC software Display.

7.3.2.3.1 Route Canceling

Authorized Users shall have the capability to cancel a route request at any time prior to the alignment of the route in the field, or before a train enters the route, through the ROCC software Display.

a) Authorized Users shall have the capability to cancel a signal, cancel a Call-on, or ‘cancel all’ for a selected signal through the ROCC software Display.

b) Fleeting shall be automatically cancelled for a signal when an Authorized User cancels a signal or issues a cancel all command for a selected signal.

c) When an Authorized User performs a Cancel Fleeting command, the signals involved shall not be automatically cancelled by the ROCC software.

7.3.2.3.2 Through Routing

Through routing shall be implemented on a per interlocking basis, not between two or more interlockings. Through routing shall be automatically initiated when appropriate based on the exit that is selected. Canceling a through route shall require that each cleared signal be canceled individually.

The ROCC software office logic shall evaluate Through Routes for office blocking and prevent transmission to the field signal system of route requests that would result in violation of an Office Block or a Prohibit Exit. The ROCC software shall notify the Authorized User when a requested Through Route is prevented due to violation of an Office Block.

7.3.2.3.3 Train Order Indications

Train Order Indications are used to request a train to come to a stop and call the control center, via telephone or radio, so that instructions can be given to the train operator. In present WMATA operations, in order to get a train operator to radio back to OCC, a “Hold at Platform” command can be issued which will remove speed commands and inhibit the ability for a train to move out of a platform.

The ROCC software shall provide monitoring and control of field Train Order indicators. Train Order Indication commands shall be provided and transmitted to the field Signal systems to set Train Order indications.

Authorized User interactions for Train Order Indications shall be available through selections on a Train Order icon, via a left click, and associated pop-up menu or control dialog.

7.3.2.4 Fleeting

Fleeting causes a signal to be re-cleared automatically over the same route following each train movement. All fleeting is Field (as opposed to office) fleeting, which means that controls need to be transmitted to the field Train Control system to assert and cancel fleeting. A cancel fleet command is provided. In addition, canceling a route will cancel any fleeting that is established for the route.

All controlled signals that are fleetable in the field shall be fleetable by the ROCC software. When in Office Mode, office logic validation shall check that a request for a route entrance to be cleared is made prior to, or

Page 138


concurrent with, an Authorized User request for a signal to be fleeted, or that a route entrance has already been established.

A “Cancel Fleet” command shall be provided and be capable of being transmitted separately from other route commands such that the fleeted state is removed for the signal without canceling, or otherwise altering the signal. Distinctive “fleet request”, “fleet established”, and “fleet cancel request” status indications shall be provided, separate from “signal clear” status indications.

7.3.2.5 Call-On

A signal call-on is used to provide a request for a route from a signal to an exit path that would not otherwise be available due to track occupancy.

Authorized Users shall have the capability of initiating a Call-on request for a selected Controlled Interlocking Signal, subject to ROCC software validation.

a) The ROCC software shall validate that a train occupies the approach track circuit of the signal and that a route request has been established prior to initiating the Call-on request.

b) The ROCC software shall validate that the Call-on is not implemented in conjunction with fleeting or through routing prior to completing the request.

Authorized User interactions for Call-ons shall be available through selections on a pop-up menu or control dialog.

7.3.2.6 Auxiliary Switch Control

Authorized Users shall be provided the capability to request setting a selected switch to normal, reverse, or NX mode. Switch control shall be performed by Authorized User selecting (i.e., left clicking) the desired switch on the track display of the ROCC software Display and selecting the appropriate command from a pop-up menu.

When a switch has been placed in a specific position (normal or reverse) by an Authorized User and is not in the NX mode, the ROCC software shall not allow any controls to be issued that would directly or indirectly cause the switch to move. The ROCC software shall provide the capability for NX requested routes (in addition to manual Signal requests) to be cleared over a switch, in the proper position, when the switch is not in NX mode.

Switch indications shall be indicated on the track display of the Overview and ROCC software Displays. The ROCC software shall provide the capability for Authorized Users to block switches in the normal or reverse position when they are not in the NX mode and when they are indicated to be in the position for which blocking is desired (normal or reverse).

The ROCC software shall provide the capability for Authorized Users to initiate switch blocking either making a left click on the switch in the track display of the ROCC software Display and selecting from a pop-up menu.

When a switch has been blocked, the ROCC software shall not allow the switch to be changed to the NX mode. When a switch has been blocked, the ROCC software shall not allow any controls to be issued that would directly or indirectly cause the switch to move. The ROCC software shall provide the capability for routes to be cleared over a switch, when blocked in the proper position. Switch blocking shall be indicated on the Track display of the Overview and ROCC software Displays.

7.3.2.7 Track Out of Service

The ROCC software shall display track out of service on all ROCC software Displays where indicated from the field signal system. The Contractor shall provide functionality that assists rail personnel in detecting out of service track, including the Track Circuit Monitor Tool (TCMT) that WMATA presently utilizes. The Contractor shall coordinate with WMATA personnel to research and implement the TCMT.

7.3.2.8 Locking Indications

The ROCC software shall implement switch, route, and time locking indications.

Page 139


7.3.2.8.1 Switch Locked

The ROCC software shall provide switch locked indications based on information received from the field signal system.

7.3.2.8.2 Route Locked

Route locking indications shall be determined by CTC office logic based on field signal system indications of signal clear status, switch lock status, and track circuit occupancy.

7.3.2.8.3 Time Locked

The ROCC software shall provide time locked indications based on information received from the field signal system.

7.3.3 Schedule Display

The ROCC software shall contain a schedule of revenue train movements. The schedule shall be displayed within the ROCC software.

The ROCC software shall provide the capability for Authorized Users to import the scheduled data for all revenue train movements from the WMATA scheduling system (currently Trapeze, but ROCC software shall support whatever scheduling system that WMATA puts in place, per requirements stated in Section 2.12 – Support Applications):

a) The ROCC software shall permit the WMATA schedule to be imported automatically. b) A scheduling feature shall be included so that the WMATA schedule can be imported into the ROCC

software on a user-configured schedule. c) The ROCC software shall permit the WMATA schedule to be imported manually upon command by

an Authorized User. d) The CTC shall provide a display of the Schedule Data. The Schedule Data Display shall be presented

in the Display Conventions and Guidelines document (CDRL T201) e) Capability shall be provided for Authorized Users to designate the date of the Schedule to display. f) Multiple Schedule Displays shall be capable of being displayed concurrently at one or more CTC

Workstations.

7.3.3.1 Terminal Station Queue

A feature of the schedule display system shall be a “Train Queue” of the next five trains to depart any terminal station. This feature shall be displayed on the overview display wall as well as the OCC Control workstation. All terminal stations and any stations that WMATA uses as temporary terminal stations shall include a terminal station queue. These queues shall include:

a) Train ID, Destination and Train Number b) Departure Time c) Service Type; Local, Express, Non-Revenue d) Consist e) Crew Number

7.3.3.2 Real Time Schedule Modification – Rules, Priorities, and Suggestions

The ROCC software shall provide the capability for Authorized Users to create and apply rules and priorities within the train schedule that will automatically route trains according to these established regulations. The ROCC software shall provide the capability to create, modify, and delete schedule rules that regulate running train traffic.

a) Rules shall provide Authorized Users with the ability to establish running parameters against which each train is actively measured. Train runs that fall outside of the given parameters shall be automatically route-adjusted to come back within the rule-established running parameters.

Page 140


b) For example, a rule might be established that twenty-minute headways will be enforced. If a particular train falls outside of the headway rule, it shall be automatically routed out of turn in an effort to return it to within the established headway.

The ROCC software shall provide the capability to create, modify, and delete train priorities that regulate running train traffic.

a) Priorities shall be capable of being automatically or manually assigned. b) Authorized Users shall have the ability to manually assign a priority to an actively running train from

the predefined list of priority values. c) Priorities shall be automatically assigned based on WMATA guidelines concerning train operation.

• The Contractor shall actively work with WMATA personnel to establish the guidelines to be used to assign priority levels to running trains.

d) Priorities shall be taken into account actively as a train negotiates its run. Train priorities shall be actively adjusted in real time to account for previously-established WMATA priority guidelines. Based on assigned priorities, a train shall be potentially rerouted to either wait for or be routed in front of another train.

• For example, a guideline might be established that any individual train run cannot be “bumped” three times in a particular run. Once that a train has been held up twice due to another running rule, the priority of that train shall be modified such that it cannot be “bumped” again during the active run.

The ROCC software shall be capable of making real time schedule suggestions, based on established WMATA guidelines.

a) The ROCC software shall include the capability for increasing or decreasing train dwell times in order to put trains back on schedule.

b) Based on predefined algorithms, the ROCC software shall have a “suggestion mode” where the system will, upon determining a more efficient routing for a particular train, prompt the line supervisor that an optimized route has been discovered. The line supervisor will then be given an option to adopt the new routing or abandon the new routing.

c) The Contractor shall actively work with WMATA personnel to establish the guidelines to be used to make real time schedule suggestions.

7.3.4 Single Track

The ROCC software shall account for and support the single-tracking of trains (i.e. routing on a single track around a disabled or otherwise failed/incapacitated train; taking tracks out of service; single track schedules) and adjust accordingly. This shall take in the ability to implement an Early Out feature; which is when WMATA’s maintenance personnel are able to start earlier and beginning to single track.

If a failed train is between interlocking, an Authorized User shall be presented with the option to initiate action that will mark the track as out of service and the ROCC software shall then automatically route trains around the situation.

The ROCC software shall include the ability to route patterns of trains. For example, a “pattern” could be the routing of two trains in one direction and then two trains in the other direction, at an Authorized User’s discretion. The ROCC software shall be able to track trains during single tracking and pass the modified train routing to the Passenger Information System.

The ROCC software shall include misroute warning to controllers when routing trains during Single Tracking to destinations inconsistent with train destination to help prevent routing mistakes. The ROCC software shall account for and support single track schedules.

Page 141


7.3.5 Train Identification

The ROCC software shall automatically assign a unique train identification (Train ID) to each train operating within or ready to enter the monitored territory.

a) The Train ID to be assigned shall be based on the ATD schedule and shall be coordinated with WMATA operating procedures.

• Per the ATD schedule, Train ID shall be a function of train number, destination code, and length. • Train IDs, as displayed on the OCC Displays, shall be a combination of a two-character alpha

code indicating train destination followed by a three-character numeric code indicating the train number, for example “LA405”.

b) Operator intervention shall be possible but not required in order for a train to assume the correct Train ID according to the predefined ATD schedule.

c) Train ID is typically established by the train operator via a thumbwheel in the vehicle cab. This Train ID is then transmitted to the OCC via Train-to-Wayside (TWC).

• The capability shall be provided to allow the ROCC software to override the Train ID that has been established by the thumbwheel in the vehicle cab.

b) Train ID assignment shall be subject to review during prototyping.

Clicking on a Train ID on the ROCC software Displays shall provide the user with that ability to view the following information for the train:

a) Consist information; b) Crew information; c) Operator information; d) Power status (dead rail/emergency lighting/normal power).

Obtaining information such as schedule, consist, and operator data to be included within the ROCC software shall obligate the Contractor to interface with other external WMATA systems (e.g. WMATA RPM System). Such external data shall be obtained and brought into the ROCC software to be made available to ROCC software users on the CTC Workstation.

7.3.5.1 Unscheduled Train Identification

The ROCC software shall automatically assign four-character alphanumeric Train ID designations sequentially to unscheduled trains as determined by analysis of current WMATA operations. The ROCC software shall maintain separate records of each Train Run associated with individually assigned Train ID.

7.3.5.2 Adjusting Train Icons

Under very unusual scenarios it will become necessary for Authorized User modification to add, move or delete a train icon. Such situations include two trains combining and becoming one train, and one train splitting into two trains.

Authorized Users shall have the capability to add, move, or delete trains in the WMATA monitored territory, resulting in the modification to train run records, displayed train icons, and all displays and internal representation of the affected train data.

Authorized User modification to Train data shall be denied if the result would allow the train to pass an interlocking home signal unless that signal was cleared for the movement, and only for the route that is aligned. If two trains pass a signal displaying a call-on, or if a train is authorized to pass a red/stop signal, it is understood that manual adjusting of the train icon will be required.

The ROCC software shall provide automated and manual mechanisms for establishing the data associated with each train operating in the monitored territory, and for linking the data to track circuit occupancy indications.

Page 142


In addition, the ROCC software shall include functionality necessary to rapidly re-establish the train data-to-track circuit occupancy associations in the event of a condition resulting in the loss of the association. The ROCC software shall provide Authorized Users with the displays and dialogs necessary for train data under all situations, as approved by WMATA during prototyping.

7.3.6 Train Record

The ROCC software shall maintain a complete record (the “Train Record”) of all aspects of each planned and actual train run including any and all Authorized User modifications to the Train Record data. Train Records shall be created and maintained by the System for each Train Run whether or not a train is scheduled or is an unplanned movement.

The ROCC software shall automatically create a Train Record based on detected indication sequences that replicate train movements for all unscheduled trains. The ROCC software shall automatically create a Train Record based on detected indication sequences that replicate train movements for all scheduled trains that are not verified prior to Train Run origination.

The ROCC software shall detect and identify isolated track circuit failures and power outages that cause track circuits to indicate occupied, and shall not create Train Records in such instances. The Train record shall include the planned train service data in addition to the actual data, for all trains that are scheduled.

As a minimum, Train Record data shall include:

a) Header Information:

• Run date and time (start date and time for pending Train Record, current date and time for open Train Record, and close date for closed Train Record);

• Status of the Train Record: “pending” (not yet run), “active”, “closed”; • Current location of the “pending” (scheduled run origination location) and “active” trains. The

location identification e.g., track circuit or signal number;

b) Trip Information:

• Train type; • Schedule in effect for the subject train (identifier, date and time); • Total vehicle mileage, for each individual car in a consist;

c) Remarks and Communication:

• Authorized User entered remarks.

The ROCC software shall provide for Train Runs to be initiated (i.e., a Train Record opened) and terminated (i.e., Train Record is closed) manually by Authorized Users, as well as automatically by the System. A closed Train Record shall be stored and archived, such that the completed Train Record data is able to be retrieved upon re-open request by an Authorized User.

Train Record data shall make it possible for WMATA to easily determine the mileage accrued by each individual car in the WMATA fleet for any chosen time period. Capability shall be provided for Authorized Users to edit train type and train ID data.

7.3.7 Train Propagation

The ROCC software shall automatically propagate train IDs as the trains transition from track circuit to track circuit.

Page 143


7.3.7.1 Track Circuit Occupancy

The term “track circuit” as used herein refers to indications of occupancy that are received in the ROCC software ‘office’ from the field. One such indication sent to the office can reflect multiple track circuits in the field. The ROCC software tracking shall utilize each individual track occupancy indication received from the field separately, (i.e., track occupancy indications will not be combined).

Train ID movement shall utilize the maximum resolution possible with the available track circuit occupancy data. All of the contiguous track circuits occupied by a train shall be depicted behind (based on the direction of train travel) the train icon and shall be colored per the field indications.

All ROCC software Displays shall depict the field indication for each track circuit separately/individually. The field indication for each track circuit shall be visible at all times; when a track circuit is occupied, the length of an indication circuit shall be displayed to be longer than the length of a train icon so that the field indication for that track circuit is visible as a “tail” behind the icon, subject to prototyping.

7.3.7.2 Multiple Occupancies Closed In Together

When two trains occupy two or more contiguous track circuits, the icon for the first train shall be displayed at the very front of the first track circuit with the icon for the second train displayed at the very front of the of the second track circuit.

The track circuit that the front of a train is in shall be displayed as a “tail” behind that icon, the color of which shall be based on the field indication for that track circuit. All occupied track circuits shall be displayed per the field “color”.

The ROCC software shall display individual train icons for each train as defined herein (i.e., at the front of the first track circuit) when the number of trains closed in together is equal to or less than the number of occupied contiguous track circuits.

When the number of trains closed in together exceeds the number of contiguous track circuits that are occupied, the ROCC software shall assign the first train’s icon (to the front of) the first track circuit, the second train’s icon shall be assigned (to the front of) the second track circuit, etc.

a) In the case of “n” track circuits, the nth train’s icon shall be assigned to the front of the nth track circuit.

b) That train’s icon shall clearly be noted in a manner to be approved by WMATA that clearly indicates the number of additional following trains.

c) For example, in the case of seven (7) trains occupying four (4) contiguous track circuits, the fourth train’s icon shall clearly be noted as “+3” to indicate that there are three (3) following trains that are not represented by icons.

d) In instances where the ROCC software is unable to display each train icon due to the situation where the number of trains closing in together exceeds the number of contiguous track circuits that are occupied, the sequence and identify of following trains not displayed shall be easily determined by an Authorized User in a manner to be determined during prototyping. A suggested solution could be to display all pertinent Train IDs via a right click function, from where any one of the ‘additional’ trains can be selected.

For multiple train occupancies, ROCC software Displays shall show all occupied track circuits colored to the “field color” for that occupancy. When a contiguous occupancy of two trains separates into two occupancies, the icon for the second train shall be moved as required to be placed at the front end of the second occupancy.

Scenarios under which a contiguous occupancy of more than two trains divides into separate occupancies can result in uncertainty as to where intermediate (not the first or last) trains are located. The Contractor shall develop and implement algorithms to handle such situations subject to approval by WMATA.

Regardless of the uncertainties that can arise in these situations, the ROCC software shall accurately keep track of and display the number and sequence of trains between successive interlocking home signals. Whenever the

Page 144


train ID and icon are suppressed for some following train(s) for reasons as explained herein, it shall be provided that Authorized Users can easily determine the sequence and identity of all following trains for which icons are not displayed.

Whenever an occupancy moves past an interlocking home signal on a cleared signal, only one train ID and icon shall be automatically moved past the signal, and only for the route that is aligned. When contiguous occupancies separate and the number of trains being tracked between successive interlocking signals again equals the number of separate/distinct occupancies, the ROCC software shall automatically adjust train icons as required to be properly associated on a one-to-one basis with each occupancy.

7.3.8 Multiple Occupancies of a Single Track Circuit

When more than one train occupies a single track circuit, a number indicating the quantity of additional trains in the track circuit shall be displayed next to the lead train icon. When the front train occupies the next up-stream track circuit, a train icon and the train ID of the first follower train in the sequence shall be displayed on the second occupied track circuit. A numeric shall be displayed next to the first follower train icon if additional followers are in the track circuit.

If the first follower train again co-occupies the lead train’s track circuit (and unoccupies the down-stream track circuit) the display for the lead train shall include display the numeric quantity of the additional trains in the track circuit.

7.3.9 Train ID Data

The ROCC software shall include an enhanced Automatic Train Dispatch (ATD) capability. The ATD function shall provide the capability to receive/import train timetable data from the existing WMATA Trapeze scheduling system, as well as the ability to create and store such data.

This ATD timetable data shall include for each terminal and service the scheduled departure time of each train from that location for each service. The ATD function shall provide the capability for handling timetable data scheduled to the desired second of time, for data where seconds are omitted and trains are scheduled to the even minute.

The timetable data for each scheduled train departure shall also include the Train Type designation for each train, a regular/revenue train or a special train. In the case where no data is entered for this parameter, the default status shall be a regular/revenue train.

When a train is “added” by an Authorized User, the ROCC software shall prompt for Train Type before accepting the Train addition to the system (regular/revenue train or special train). An “added” Train departure shall be automatically assigned by the ATD function to be next scheduled run and shall be sequenced and go ahead of an overdue/late departure.

ATD shall account for any single-tracked trains and adjust accordingly. The ROCC software ATD function shall include an office logic-based “Push” feature that provides an Authorized User the capability to set a schedule early dispatch adjustment for specified terminals, either globally (applicable to all terminals), individual terminals, or groups of selected terminals.

Authorized Users shall be provided the capability to add, edit, or delete ‘Push’ values at any time. Authorized Users shall be provided the capability to apply multiple ‘Push’ values in the ROCC software simultaneously applied to different terminals, limiting one value per terminal.

Valid “Push” values shall be between 0 and 180 seconds, in one second increments. When the “Push” value is set to 0, trains shall be dispatched at the exact time as scheduled. If the “Push” value is set to 120 for a location, the ATD function shall dispatch the trains 120 seconds earlier than would otherwise occur.

Page 145


The ROCC software ATD function shall also include an office logic-based “Minimum Turn Time” (MTT) feature that provides an Authorized User the capability to set a minimum turn time schedule adjustment for individual terminals.

An Authorized User shall be provided the capability to add, edit, or delete MTT values per individual terminal. Authorized Users shall have the capability to apply multiple MTT values in the ROCC software simultaneously applied to different terminals, one value per terminal.

Valid MTT values shall be between 0 and 300 seconds, in one second increments. When the MTT value is set to 0, trains shall be dispatched as they normally would without this feature being available. If the MTT value is set to 120 for a location, the ROCC software shall not dispatch a train until either its scheduled departure time or until 120 seconds after the train has arrived at the terminal and cleared the last track circuit before the station berth, whichever time is later.

7.3.10 Schedule Adherence

Train ID icons shall graphically indicate their adherence to the established train schedule, including but not necessarily limited to:

a) On-time train b) Late train c) Very late train d) Early train e) Very early train

An Authorized User shall have the ability to establish/modify the parameters for determining late/early trains.

7.3.11 Train Run Origination

When ATD requests a route for a departure at a terminal based on the timetable, the associated and appropriate Train ID shall be automatically assigned to that occupancy. This shall be based on the scheduled departure time only, ignoring any “Push” or MTT value.

When an outbound route at a terminal is aligned, other than automatically by ATD control, such as manually, that train shall automatically “use” the next scheduled train and departure time of that service at that location and shall automatically be assigned the Train ID thereof. The Authorized User would override automatic scheduled train assignment by using the ‘add’ train capability for the departure.

7.3.12 Changing Train Icon

Once a train icon is assigned to an occupancy at a terminal or non-terminal as specified herein, the train ID text shall stay with that icon until the train reaches a termination point and either leaves the monitored territory or makes a reverse movement as defined herein.

Authorized Users shall have the capability at any time to easily change a train’s Train Type from one type to another type at any time or location via the Train Record Display. Upon change to a train’s Train Type, all train icon representations shall be automatically updated on all ROCC software Displays.

7.3.13 Reversing Direction

Train reversal shall automatically be determined by the ROCC software on the basis of at least two events indicating train movement in the opposite direction. Capability shall be provided for Authorized User to manually designate a train direction reversal.

Where a train occupies more than one track circuit and a reversal occurs, the train icon will be automatically relocated by the ROCC software to the new ‘lead’ track circuit in the new direction of train travel. If a train reverses direction in the monitored territory (except for the normal “turning of trains at terminals), the

Page 146


movement shall automatically be assigned a special train icon. In these cases, the next sequential unscheduled Train ID shall be assigned.

When a train reverses direction, the new Train ID for reverse trip shall be placed at the front end of the occupancy for the new direction of movement. Train reversals automatically detected by the ROCC software and occurring outside of the “normal” Terminals and Train Run origination points shall be alarmed.

7.3.14 Train Run Termination

The stations listed herein are included as typical termination points only, for Contractor information. The ROCC software shall not require pre-definition for any routing whatsoever.WMATA has a special schedule every weekend to facilitate maintenance. This shall require that all stations be looked at as a potential Terminal Station. Any station shall be able to be a terminal station:

a) The ROCC software schedule interface shall be the determinant of the train termination station, destination, and any other element of a route.

b) At no time shall software modification be necessary in order to enable a particular route. Trains shall be able to be routed to any destination at any time.

Terminal stations are defined by destination codes of which the Contractor shall be aware. The typical termination points for each line shall be considered as follows:

a) Red Line – Shady Grove and Glenmont b) Orange Line – Vienna and New Carrollton / Largo Town Center c) Yellow Line – Greenbelt and Franconia-Springfield / Huntington d) Green Line – Greenbelt and Branch Avenue e) Blue Line – Franconia-Springfield and Largo Town Center f) Silver Line – This is an in-development extension; terminal stations to-be-determined.

7.3.15 Train Tracking Alarms and Advisories

Train tracking shall issue advisory messages to the appropriate Authorized User upon detection of duplicate tracking data on active trains such as Train ID which are required to be unique.

7.3.15.1 Irregular Track Circuit Indications

The ROCC software shall alarm track circuit occupancies not associated with a train movement.

In the case of a “bobbing” track circuit (i.e., flips indication from unoccupied to occupied and back), Authorized Users shall have the capability to suppress audible alarms for specific track circuits.

a) Authorized Users shall have the capability to re-instate alarms for specific track circuits. b) Authorized Users shall have the capability to view and modify the list of track circuits for which the

alarming of a false occupancy is suppressed. c) The ROCC software shall automatically re-instate alarms for specific track circuits independently after

a predefined time has expired. d) Any such predefined time limit shall be configurable by an Authorized User.

7.3.15.1.1 Disappearing Train

Field failures, a track car, and other conditions can cause the occupancy of a train (including track cars) being tracked to “disappear”. Disappearing trains shall also include, but not be limited to, a train that backs up or any other “non normal” train not otherwise accounted for in this Section.

When the ROCC software detects an unexpected unoccupancy condition under a train tracked into a track circuit or circuits, the condition shall be logged and alarmed and the train’s icon shall stay in the last reported position. When the ROCC software detects occupancy for the same or a contiguous track circuit where a ‘disappearing train’ was alarmed, the train’s icon shall be automatically adjusted to the occupied location.

Page 147


Authorized Users shall have the capability to suppress ‘disappearing train’ alarms for specific trains (such as specific track cars) being tracked and have the capability to restore the normal functioning of these alarms by individual train. Authorized Users shall have the capability to view and modify the list of trains for which the alarming of a “disappearing” occupancy is suppressed.

7.3.15.1.2 Signal Overrun Alarm

The ROCC software shall alarm the detected passing/overrunning of a stop signal by a train as defined in this Specification.

A

2T

3T

B

C1T 4T

Figure 1: Signal Overrun Example

An illustration of this functionality based on the above figure is as follows:

If Track Circuits (TC) 1T, 2T, 3T and 4T all show unoccupied (refer to Figure 1), and if TC 1T then shows occupied, the TC 1T occupancy indication shall be treated as a false occupancy as described elsewhere in these Specifications.

If TC 1T shows unoccupied while TC 2T, 3T and/or 4T show occupied (refer to Figure 1), and if TC 1T then shows occupied while no signal is cleared, the TC 1T occupancy indication shall be alarmed as an apparent signal overrun.

If TC 1T shows unoccupied while one of the three signals is cleared (refer to Figure 1), and if TC 1T then shows occupied while the TC approaching the cleared signal shows occupied (such as Signal B cleared while TC 3T occupied), it shall be assumed that the train that was approaching the cleared signal was the one that passed the cleared signal and no alarm shall be issued.

If TC 1T shows unoccupied while one of the three signals is cleared (refer to Figure 1), and if TC 1T then shows occupied while the TC approaching the cleared signal is not occupied, and if the TC approaching at least one of the other two (non-cleared) signals is occupied, the TC 1T occupancy indication shall be alarmed as an apparent signal overrun.

In the case of a red signal overrun, the ROCC software shall not automatically move the train’s icon past the interlocking home signal.

The Contractor’s design for this function shall take into account “timing issues” related to the reception of field indications to ensure that false alarms are not issued.

Page 148


7.3.16 Train Tracking User Interface

7.3.16.1 User Commands

This section identifies train tracking user commands; additional user interactions are specified elsewhere within this section of the Specification.

The ROCC software shall include control displays and menus that provide Authorized Users the capability to insert, edit, and delete train data affecting all displays in which the data appears, including at a minimum linking updates from ROCC software Displays to control displays. When Train Run data is edited in one control display, the ROCC software shall update all instances of the same data in all related databases, displays, and dialogs.

Authorized Users shall have the capability to move trains from one location along the track to another, (e.g., as may be necessary to correct situations under which train tracking incorrectly placed a train).

a) Authorized Users shall have the capability to select a train icon on a track display (e.g., depress and hold the left mouse button (drag and drop)), and move the selected train icon to a new track location anywhere within the WMATA monitored territory.

b) The ROCC software shall provide special highlighting of a track circuit when a train icon being moved by an Authorized User is within a programmer adjustable distance to the track circuit.

c) When an Authorized User completes the move of a train icon to a new track circuit (i.e., releases the left mouse button), the ROCC software shall insert the train icon on the track circuit identified (and highlighted) by the ROCC software. The track circuit special highlighting shall be removed from the track and special highlighting shall be applied to the train icon.

• If the track circuit to which a train icon is moved is occupied by another train, the ROCC software shall prompt the Authorized User performing the move to specify the order to insert the train.

• The ROCC software shall display a Control Action Confirmation dialog to the Authorized User in control of the location to where the train icon was moved.

• If the Authorized User in control of the territory in which the train icon has been moved fails to acknowledge the move or if a Authorized User adjustable timer expires before the move is completed, the train icon shall be returned to the track circuit last recorded by the ROCC software, special highlighting shall be removed from the train icon, and a user advisory shall be issued to the Authorized User that initiated the move.

Train tracking and identification displays and command dialogs shall automatically update in real-time in accordance with train movements, modifications to train identifications and associated data, and train tracking operations.

7.3.16.2 Display of Train Icons

The trains shall be represented on mainline rail territory and for trains entering and leaving yards on yard lead portions of track displays by a graphical train icon. Train icons including Train IDs shall be placed in the trackline of track displays.

On all CTC Displays the train icon of the first train in one or more contiguous occupied track circuits shall be displayed at the very front of the occupancy – at the front end of the first track circuit occupied by the train for the direction of travel.

The representation of train icons shall be subject to approval by WMATA during prototyping; design of train icons must ensure that the “field color” and the “office data” including the train ID text can all be easily discerned.

Status information concerning trains shall be indicated by the coloring and other display attributes of the train icon on the CTC Displays. An example of train status that shall be apparent by observing the depiction of the

Page 149


train icon will include, but not limited to, non-revenue trains, manual operation trains, ATP cut-out trains, duplicate-ID trains, and unidentified trains.

The train ID text for each “train color” shall be in a color and style that makes the text most discernable. Each separately indicating track circuit shall be long enough to contain the train icon.

The established direction of travel of a train shall be indicated by a pointed end of the train icon. Train icons shall be placed horizontally, vertically, or diagonally consistent with the track line.

Rules and algorithms for placement of train icons in the conditions described in these Specifications shall be fully described in the Software Requirements Specification (CDRL T308) and Software Detailed Design Document (SDDD) (CDRL T310).

The train icon shall be placed at the first/last facing point within a single track circuit. Where a train occupies more than one track circuit, the train icons shall be placed in the leading track circuit occupancy in the established direction of travel.

All aspects of presentation of Train IDs and movement on displays shall be subject to Engineer approval during user interface prototyping.

7.3.17 Squiggle Lines

The Contractor shall create a headway report in which WMATA has termed “Squiggle Lines.” This function shall provide an “on-time” module that can be displayed on any workstation. A sample report has been included with the Contract Documents.

The report shall include the following:

a) Day, Date and time of the report b) vertical scalable bar listing times c) horizontal scalable bar listing the stations d) operating trains by schedule times e) operating trains by actual times f) Train Numbers

7.4 Schedule Monitoring and Control

The Contractor shall work with WMATA’s schedule Contractor to design and implement an interface that provides WMATA with a “hands off” approach to linking the schedule database, extracting the required data, formatting within the ROCC software for tracking, scheduling and providing reports. The Contractor shall prepare an interface document that clearly indicates this interface.

Within the ROCC software, the Contractor shall provide a schedule software module that provides WMATA with additional features which includes:

a) Method of storing daily schedules within the OCC Software Database. b) Provide the user the ability to select various schedules within the OCC Control Software c) Display Headway Sheets with the OCC Control Software d) Indicate which trains are operating, the status of the trains, as well as indicating them in relationship to

WMATA’s standard Headway Sheet. e) Display the Headway Sheet by operating Line f) Display to indicate the next 5 trains departing from station indicated as a terminal station. This shall

include train ID and destination codes. g) Displays indicating Crew #s, Revenue/Non-Revenue trains. h) Displays indicating trains in operation, stored on the line or located in a specific yard. i) Display in real time reports such as “On-Time Performance.”

The Contractor shall provide the ability within the OCC Control Software to add, copy, modify, save and delete schedules within a library that can be recalled at a later time and initiated within the software. A Validation

Page 150


process shall be included that checks all schedules being implemented in the OCC Control Software to known acceptable parameters. Any schedule that does not meet these parameters shall be clearly indicated and logged.

The Schedule HMI displays shall subject to prototyping.

7.5 Traction Power Monitoring and Control

The ROCC software shall provide a software module to monitor and control the traction power system. This software module shall contain an animated graphic of the Traction Power system. The animated graphic shall be updated from real time, real world data. The software module shall have very high level of accuracy, detail, availability and deploy a modern GUI. Operator actions shall be privilege based and contain built in checks to prevent operator errors.

The new ROCC software shall accurately track and display the locations, energization status and other pertinent data of all plate circuits in the ROCC monitored territory as defined in these Specifications and subject to prototyping. The TPS shall provide monitoring and control of all status points and control points that the in-field RTUs are capable of supporting, including analog values.

The Contractor shall be responsible for acquiring a thorough understanding of WMATA traction power as it currently exists. The ROCC software shall provide monitoring and control capability of traction power via an interface with the existing power grid in the field provided through the WMATA MERCS. The resulting subsystem shall be referred to as the ROCC software Traction Power System (TPS). The TPS shall consist of an operations portion and a maintenance portion. WMATA will assist the Contractor in meeting this requirement by meeting with the Contractor, answering Contractor’s questions, providing relevant documentation, and permitting a limited number of Contractor personnel to witness power operations at the CTF and the . All of the above WMATA assistance will be subject to WMATA scheduling, availability, and organizational security rules. It is not anticipated that another power interface that is currently in place, the CG Automation Automated Energy Management System (AEMS) power system, will be replaced. Rather, AEMS shall continue as a standalone system for use by others. AEMS functions by interfacing with PLCs directly in the field.

The TPS shall account for all industry standard power protocols including, but not limited to, DNP3 and Modbus.

All SCADA graphical elements to be displayed in the ROCC software shall be stored in and retrieved from the Display Control Graphical Library.

7.5.1 Traction Power System Design Requirements

The TPS shall be capable of providing, at a minimum, all status points and control points that the in-field RTUs are capable of supporting, including analog values. The TPS shall provide all industry standard monitoring of analog values, including but not limited to high and low threshold monitoring and alarming of analog values.

All possible control points, status points and analog values that the field RTUs are capable of processing shall be exchanged with the ROCC software. The ROCC software shall be sized to provide a 50-percent spare capacity of points. The TPS shall process all current indications in addition to future indications that can reasonably be expected to be added in the future to the WMATA system. For example, local and remote modes do not currently appear on WMATA scan sheets but are being made available on the new Silver Line and will appear throughout the WMATA system as SCADA system equipment is upgraded.

TPS design shall support the addition of graphic displays, which shall depict the associated control and status points. These status points shall consist of both digital and analog values.

The ROCC software shall recognize the operational mode of the traction power system.

a) The operational mode shall be able to be manually selected from within the substation by operating the local/remote lever on each circuit breaker.

Page 151


b) The operational mode shall be either local, meaning the breaker is being operated from within the substation, or in remote, meaning the breaker is being operated by the ROCC software.

c) The operational mode for each breaker shall be reflected on all appropriate graphic display diagrams.

When the system is in local mode, the ROCC software shall be prohibited from sending controls to the field.

a) Local control shall include monitoring and control of TPS elements from a field location. b) In the event of a user performing TPS local control, the ROCC software shall indicate such local

actions on OCC Displays.

• Local power actions appearing on OCC Displays shall be displayed in such a manner as to be immediately distinguishable from TPS actions from the ROCC software.

• Local power actions shall not generate superfluous ROCC software alarms. Only uncommanded actions shall be alarmed when a field agent assumes local control. Regardless, all actions shall be logged.

c) When the system is in remote mode, only the ROCC software shall be capable of sending controls to the field.

d) Monitoring of the traction power system devices by the ROCC software shall occur in either operational mode.

The TPS shall enable the user to issue a Trip command, which shall trigger the issuance of controls to trip the associated field device.

a) The TPS shall only inhibit the Trip command in the event that a lockout is applied to the device. b) The TPS shall perform validation prior to executing a Trip command for an electrically operated third

rail switch if either or both legs of the switch are energized.

The TPS shall enable the user to issue a Close command, which shall trigger the issuance of controls to close the associated field device. The TPS Shall:

a) Inhibit the Close command in the event that a Lockout is applied to the device, or another control has been issued to the device, and is still pending or in progress.

b) Perform control validation for an electrically operated switch if either or both legs of the switch are energized.

c) Enable the user to issue an Emergency Close command, which shall trigger the issuance of controls to close the associated field device. The same controls to the field device shall be issued for both the Close and Emergency Close commands.

d) Be capable of determining whether a device failed to close or if it closed on a fault and subsequently tripped open. Appropriate alarms shall be issued in either case.

The TPS shall enable the user to remove or apply power to a section of third rail by selecting the entire section of third rail for which an appropriate sequence of commands is issued as one operation.

a) The TPS shall support identifying sections of third rail to be energized or de-energized shall be supported by identifying the circuit breakers and/or electrically operated switches that bound that section.

b) When processing a command to apply or remove to a section of third rail, the system shall automatically identify and execute the necessary sequence of operations (such as opening a circuit breaker before opening an electrically operated switch and then re-closing the breaker) required to avoid operating an electrically-operated switch while any leg of the switch is energized. In determining the sequence of operations necessary to accomplish the removal or application of power, the system shall be bound by the following rules:

• The TPS shall provide users with a Lockout function to control inhibit, or “lockout” control points to field devices including circuit breakers, motor operated disconnects, relays or contactors and other devices. Lockouts shall be available for all devices in the monitored territory. It shall be possible to apply a Lockout to a device which is closed. Such a Lockout will inhibit trip requests for the device. The function of applying or removing Lockouts shall be accomplished by selecting one or more devices, and then ‘Lockout,’ from the device control dialog box. The devices selected

Page 152


for a Lockout operation shall hereinafter be referred to as the ‘Lockout selection set.’ A display shall appear containing controls for both applying and removing lockouts.

• The TPS shall enable the user to issue a Trip and Lockout command. A Trip and Lockout command shall issue a Trip command and then apply a Lockout.

• The TPS shall provide a Tag (Operator Notice) function. A Tag shall be textual data associated with a device. The system shall enable users to apply, remove, and modify Tags for all devices in the controlled territory. The presence, absence, or content of a Tag shall have no effect on the operation of the device.

WMATA operations distinguish between two different types of de-energized statuses:

a) A Supervisory outage is a de-energized status that occurs when the TPS initiates the outage. b) A Red Tag outage occurs when a worker in the field physically removes a breaker from the cabinet and

then hot sticks the rail.

The TPS shall graphically distinguish between a Supervisory and Red Tag outage on all ROCC software Displays.

The Contractor shall provide a complete list of all TPS controls and indications as a part of the Software Requirements Specification. (CDRL T308) The controls and indication list shall include the following:

a) Controls (Open/Close) b) Indications c) Alarms d) Analog Functions

The TPS shall have logic to provide for transfer-trip for all DC feeder breakers; the logic shall be such that it waits for a predetermined time delay before tripping the corresponding feeder breaker(s) in the protected power zone.

The Contractor shall provide a means to allow an Authorized User to establish upper and lower thresholds for each analog point. As analog values are processed by the TPS, the value shall be compared against the thresholds. If the value is out of the range established by the upper and lower thresholds, then that data shall be logged to the Historical Data system

Both the TPS and train control systems shall be designed such that a software malfunction or program fault in one system shall not affect the performance of the other. TPS shall provide simulation software for testing, training, cut-over, expansion and management.

a) The Contractor shall provide a TPS device simulator. The device simulator shall be capable of simulating all existing, new and future control points, status points and analog values provided by the various field devices.

b) The simulator shall be used during the testing phase of this Contract for the purpose of verifying TVC device tabling and operation.

c) The simulator shall be used during ROCC personnel training exercises as described in Section 8.0, WMATA Training.

7.5.2 Traction Power User Interface

If a closed and energized breaker is selected for opening, it and all circuitry fed by it shall flash slowly in its de-energized color before the send command is given:

a) The track diagram configuration shall clearly denote any sections of track that have been de-energized. b) The ROCC software shall recognize a section of track as being de-energized and shall not allow any

routes to be cleared into that area.

The Contractor shall provide a substation power diagram for each traction power substation.

a) The substation power diagram shall be accessed either via a pulldown menu, or by clicking on the substation icon on the track diagram configuration.

Page 153


b) The substation power diagram shall provide a dynamic representation of the distribution of power as supplied from the electric company to the substation.

c) The diagram shall include monitoring of the voltage supplied from the electric company.

WMATA personnel responsible for mainline operations shall be able to monitor and control the Traction Power System from the track diagram configuration and the substation power diagram. All ROCC software traction power operations shall follow all applicable Standard Operating Procedures as defined in the WMATA Metrorail Safety Rules and Procedures Handbook (MSRPH).

Graphical displays for TPS device indications shall generally operate as follows:

a) Closed devices shall be shown in red; b) Open devices shall be shown in green; c) Devices in their normal state shall be shown in outlined form; d) If a device is in “Abnormal” status the coloring will be a bright version of the appropriate

device/condition color; e) Circuit breakers shall be shown as circles; f) Switches shall be shown as diamonds; g) Prohibit Close shall be shown as a blue box around a device.

• Prohibit Close shall be added whenever a device has been opened by either a control or a trip. • The user shall be required to remove the Prohibit by exercising an “Enable Close” control. • The device shall then be eligible for closing via the normal Close Device control.

The system shall show third rail state on the track display. The colors of the track segments shall be customizable for each of the following states:

a) Energized; b) De-energized; c) Surmised to be de-energized by the power tracking function but requiring verification in the field.

7.5.3 Traction Power System Operations

Contractor shall become familiar with existing TPS Operations and mimic the existing functionality, look and feel.

TPS Operations functions shall include, but not be limited to, the following:

a) Energize and de-energize 3rd rail sections. b) The 3rd rail sections are calculated using the breaker information. c) Currently no voltages are included for the substations. d) Traction battery chargers.

7.6 Tunnel Ventilation Monitoring and Control

The ROCC software shall provide a software module to monitor and control the tunnel ventilation system. This software module shall contain an animated graphic of the Tunnel Ventilation system. The animated graphic shall be updated from real time, real world data. The software module shall have very high level of accuracy, detail, availability and deploy a modern GUI. Operator actions shall be privilege based and contain built in checks to prevent operator errors.

The ROCC software shall provide for the control and monitoring of the WMATA tunnel ventilation system. The software shall provide a software module and all associated devices in a system that is referred to as Tunnel Ventilation Control (TVC) software module

The SCADA components making up the TVC that shall be supplied under this Contract consist of ROCC software to control the tunnel ventilation system RTUs with redundant communication links located throughout the WMATA rail territory.

Page 154


The TVC shall provide monitoring and control of all tunnel ventilation devices including, but not limited to, fans, dampers, and alarms. Zone control of the in the ROCC monitored territory shall be provided such that ventilation of a specific area can be accomplished with a single operator action.

TVC shall include an emergency response feature that implements fan sequences as the primary component. Emergency response will assist Line Supervisors with evacuation of passenger areas via a single mouse click.

The TVC shall provide zone control of the monitored WMATA rail territory such that ventilation of a specific area can be accomplished with a single operator action as defined in these Specifications and subject to prototyping.


7.6.1 Tunnel Ventilation System Design Requirements

ROCC personnel shall bear the primary responsibility for actions in response to fire alarms and similar emergency conditions (e.g., de-energizing traction power, activating emergency ventilation fans for smoke-removal purposes when in the appropriate mode, etc.).

Fans and dampers that comprise the tunnel ventilation system shall be controlled either individually or via pre-programmed fan sequences.

a) A fan sequence shall establish the state of all fans in a zone. b) Fan sequences shall exist for both normal and emergency operations. c) Under normal operations, the fans and dampers shall be automatically activated according to the

normal operations fan sequence.

During an emergency condition within a tunnel, ROCC personnel shall manually initiate either an inbound or outbound evacuation fan sequence. Each evacuation fan sequence shall differ based upon the associated evacuation zone.

TVC emergency response shall follow all vehicle evacuation rules as defined in the WMATA Metrorail Safety Rules and Procedures Handbook (MSRPH). TVC shall act in concert with the Train Control system and the Traction Power system in order to provide ROCC personnel with integrated decision making and seamless operation.

a) TVC shall provide a continuous system operation without reducing the safety of personnel or equipment.

b) TVC shall also be sufficiently flexible so that tunnel ventilation system modifications can easily be incorporated.

TVC shall recognize the operational mode of the tunnel ventilation system. The operational mode is manually selected from within the fan room by selecting local or remote on the local control panel.

a) The operational mode shall be either local, meaning operated at the local control panel, or remote, meaning operated by the ROCC software.

b) The operational mode for each fan area shall be reflected on the track diagram configuration. c) When the system is in local mode, the ROCC software shall be prohibited in sending controls to the

field. d) When the tunnel ventilation system is in remote mode, only the ROCC software shall be capable of

sending controls to the field. e) Monitoring of the tunnel ventilation system devices by the ROCC software shall occur in either mode

of operation. f) The software/firmware related to the control and monitoring of the tunnel ventilation system shall be

considered “safety-critical.”

Page 155


All possible control points, status points and analog values that the field RTUs are capable of processing shall be exchanged with the ROCC software. The ROCC software shall be sized to provide a 50-percent spare capacity of points.

Both the TVC and train control systems shall be designed such that a software malfunction or program fault in one system shall not affect the performance of the other.

TVC shall provide simulation software for testing, training, cut-over, expansion and management.

a) The Contractor shall provide a TVC device simulator. The device simulator shall be capable of simulating all existing, new and future control points, status points and analog values provided by the various field devices.

b) The simulator shall be used during the testing phase of this Contract for the purpose of verifying TVC device tabling and operation.

c) The simulator shall be used during ROCC personnel training exercises as described in Section 8.0, WMATA Training.

TVC shall record all controls, indications and alarms using the Historical Data system.

a) The Contractor shall provide a means to allow an Authorized User to establish upper and lower thresholds for each analog point. As analog values are processed by the TVC, the value shall be compared against the thresholds. If the value is out of the range established by the upper and lower thresholds, then that data shall be logged to the Historical Data system.

Examples of events to be logged include, but are not limited to, the following:

a) Vent Fan high speed forward control b) Jet Fan reverse control c) Vent Fan emergency control d) Cross Passage Fan off control e) Stair Pressurization Fan off f) Vent Fan low speed reverse g) Vent Fan Damper opened h) Track Damper open closed i) Vent Fan alarm indications:

• Vent Fan Fault • Motor Vibration • Bearing Temp • Motor Winding High Temp

j) Ventilation Control Panel in local k) Vent Plant intrusion l) Vent Plant Fire / Smoke Alarm m) Vent Plant High Temperature Alarm n) Substation High Temperature Alarm o) Emergency sequence selected p) Emergency sequence aborted q) Emergency sequence cancelled r) Total cumulative operating hours of all ventilation equipment

TVC shall maintain data concerning all field devices in order to provide WMATA with the ability to generate reports in regards to the usage and maintenance of all ventilation field devices. The Contractor shall provide a complete list of all TVC controls and indications as a part of the Software Requirements Specification. (CDRL T308). The Contractor shall confirm the device type, associated states and location of each tunnel ventilation system device.

More precisely, the Contractor shall include the following as part of the Software Requirements Specification:

a) A table or matrix of all TVC zones, including zone designations and physical boundary limits.

Page 156


b) A table or matrix of all TVC devices including fans, dampers, controls, and indications associated with each zone.

c) A table or matrix of all TVC control logic and operating modes defining the state of all fans and dampers during normal and emergency operation. This shall include information to assist operators in selecting the appropriate operating modes.

d) A table or matrix of TVC emergency sequences and other automatic operation associated with control modes.

e) Information regarding interlocks, inhibits, or time delays associated with individual TVC fans, or groups of fans.

7.6.2 Tunnel Ventalation User Interface

ROCC personnel shall be provided with graphic display diagrams that shall allow control and monitor of all TVC devices.

a) Each tunnel ventilation system device shall be represented by an icon on the track diagram configuration. Each icon shall reflect the type of device it is representing, for example, under platform ventilation fans shall be distinguishable from booster fans.

b) ROCC personnel shall have the capability to select an apparatus for control by keyboard and/or mouse. If a device is selected via keyboard and/or mouse, the user shall have the capability to de-select it without canceling the entire command.

c) All TVC monitored devices shall be represented individually on ROCC software Displays and shall be subject to prototyping.

d) All features and standards for development of ROCC software Displays shall be defined in the Display Conventions and Guidelines Document (CDRL T201).

All user-initiated commands shall be accomplished through a three-step process. This three-step process shall:

a) Accept the user’s request; b) Display a preview of the state of the device to be affected by the control; c) Allow the user to execute the command (i.e., send to the field) or abort the command (retain the

current control).

Contractor shall implement the TVC such that any particular individual ventilation device may only be controlled by a single user at any one time. Once a control has been sent to a device, that device shall remain locked out to all other Authorized Users until the control request is either executed (i.e. requested control implemented), cancelled, or after a configurable timeout period.

The track diagram configuration shall uniquely display icons to reflect the following conditions:

a) Provide a preview of device states; b) Provide an indication that controls have been sent to the field; c) Provide an indication that the field has responded to the control.

Fan sequencing capability shall be provided for use in either normal or emergency operations as described more fully elsewhere in this Section.

Manual operations, such as individual fan control, manual fan sequence control and the aborting of a fan control sequence shall be accomplished through the three-step process described herein.

The preview of a fan sequence shall reflect the state of each device as dictated by the selected fan sequence.

All icons associated with the control action (individual fan control or fan sequence) shall reflect the state of the device. For example, if the evacuation inbound fan sequence is initiated, then the appropriate fans shall indicate in exhaust state, supply state, etc.

Those fans having an associated damper state shall reflect both the fan state and the damper state.

Page 157


Specific error messages shall be provided to ROCC personnel to inform them of field conditions. The error messages shall identify the failed component; this is especially critical in a multi-step control. For example, if an error occurred when placing an emergency fan into exhaust mode, ROCC personnel shall be informed as to which of the following actions occurred:

a) The bypass damper failed to close; b) The fan damper failed to open; c) The fan failed to activate in forward mode.

Not every control or indication is valid for every fan type. The menu for each fan icon shall reflect only those controls which are valid for the selected fan. ROCC personnel responsible for mainline operations, in concert with maintenance personnel in the field, are responsible for exercising tunnel ventilation system devices to ensure proper operations.

a) TVC shall provide for a maintenance mode whereby the tunnel ventilation devices can be exercised by the ROCC software.

b) The ROCC software shall recognize when each device is being exercised and shall log all associated controls and indications as such.

TVC shall process tunnel ventilation system alarms. Alarms shall appear on both the graphic diagram and the Alarm Management Window, as described in Section 2.9 WMATA Alarm Processing. The following alarm conditions, at a minimum, shall be processed:

a) Fire alarm; b) Fire trouble; c) Intrusion alarm; d) Intrusion trouble; e) Standpipe alarm; f) Electrical alarm; g) Methane alarm; h) Methane trouble; i) Water alarm; j) NOX alarm; k) Fan trouble; l) Heat detectors; m) Emergency thermal override; n) Loss of communications with RTU; o) Pump alarm; p) Emergency generator alarm.

TVC alarms shall be displayed on the graphic displays relative to the location where the alarm condition has occurred.

7.6.3 Tunnel Ventalation Operation

The Contractor shall implement fan sequences as the primary component of emergency responses.

Fan Sequences – The Contractor shall provide the means to control fans and associated dampers either individually or in preprogrammed groups of fan sequences.

a) TVC shall provide a user-friendly mechanism of tabling fan sequences. Each fan sequence shall be capable of being timer driven, where the fan sequence shall take effect on a given date/time, or the fan sequence shall be valid every day for a given time period.

b) TVC shall, at a minimum, support fan sequences for the following operational modes: • Normal operation; • Evacuation inbound; • Evacuation outbound; • Abort and/or manual operation.

Page 158


c) The Contractor shall provide the means to manually initiate inbound and outbound evacuation fan sequences for each of the evacuation zones.

d) The Contractor shall provide an example of the evacuation zones and associated evacuation inbound/outbound icons as a part of the Software Requirements Specification, subject to user interface prototyping.

e) ROCC personnel shall be provided with an indication of the fan sequence and the operational mode that is in effect.

f) The indication of a heat and/or smoke alarm shall alert ROCC personnel to initiate the appropriate fan sequence.

ROCC personnel shall be able to abort a fan sequence, manually execute a fan sequence and manually control individual fans.

As an Example; in the event of an emergency (within a tunnel, for instance), Authorized Users shall be able to initiate evacuation fan sequences as described below:

a) The train operator will call the ROCC stating that there is an incident at Chain xyz+qq. b) The ROCC software track alignment graphical display shall contain icons representing fan banks and

individual fans/dampers. c) The ROCC Authorized User shall be able to select the icon on the graphical display that corresponds to

the fan bank at the location indicated by the train operator. d) Upon selection of the icon, an incident control popup shall appear on the ROCC software screen. e) The ROCC Authorized User shall then be prompted to select the evacuation direction for passengers

and personnel from the location of the incident. f) The ROCC Authorized User shall then be presented with options to Accept, Cancel, Exhaust, Stop or

Exit the incident control popup. • Selecting “Accept” shall place the fan bank into a fan sequence that will facilitate evacuation in

the chosen direction. • Selecting “Stop” shall reset the ventilation mode to normal, i.e. off. • Selection “Exhaust” will place the system into emergency mode – all fans in exhaust.

In the event that the user wants to change the active running mode, the Authorized User shall need to begin the same selection process. The Authorized User shall select on the desired location of the incident and the previous popup will appear again. The Authorized User shall select the direction and either clicks on “Accept” to begin the mode change or “Cancel” to clear the mode selection. To exit the popup the Authorized User shall select on “Exit”. During the Mode change all fans shall be set to “Stop” and then restarted if required by the new mode. After the request for the stop the process will begin for the start of the new mode. Process guidance shall be provided to assist ROCC personnel in emergency response.

7.7 Tunnel Drainage Monitor and Control

The ROCC software shall provide a software module to monitor and control the tunnel drainage system. This software module shall contain an animated graphic of the Tunnel Drainage system. The animated graphic shall be updated from real time, real world data. The software module shall have very high level of accuracy, detail, availability and deploy a modern GUI. Operator actions shall be privilege based and contain built in checks to prevent operator errors. This software module shall referred to as the Drainage Monitoring System (DMS).

The DMS shall provide monitoring and control of all tunnel drainage devices including, but not limited to, pumps, valves, motors, VFD, etc. The DMS shall provide zone control in the ROCC monitored territory such that drainage of a specific area can be accomplished with a single operator action. Pumps that comprise the Drainage Monitoring System shall function automatically, but may also be controlled individually.


Page 159


7.7.1 Tunnel Drainage System Design Requirements

The DMS shall provide for the monitoring and control of all pumps that are located throughout the tunnel sections of the WMATA rail territory. Pumps that comprise the Drainage Monitoring System shall function automatically, but may also be controlled individually. Automatic pump operation shall always override manual operation. If the pump sensors determine that a pump must engage, manual operation shall not prevent any such automatic pump engagement.

DMS shall recognize the operational mode of the Drainage Monitoring System. The operational mode is manually selected from within the pump room by selecting local or remote on the local control panel.

a) The operational mode shall be either local, meaning operated at the local control panel, or remote, meaning operated by the ROCC software.

b) The operational mode for each pump area shall be reflected on the track diagram configuration. c) When the system is in local mode, the ROCC software shall be prohibited in sending controls to the

field. d) When the Drainage Monitoring System is in remote mode, only the ROCC software shall be capable of

sending controls to the field. e) Monitoring of the Drainage Monitoring System devices by the ROCC software shall occur in either

mode of operation.

All possible control points, status points and analog values that the field RTUs are capable of processing shall be exchanged with the ROCC software. The ROCC software shall be sized to provide a 50-percent spare capacity of points.

Both the DMS and train control systems shall be designed such that a software malfunction or program fault in one system shall not affect the performance of the other.

DMS shall record all controls, indications and alarms using the Historical Data system.

a) The Contractor shall provide a means to allow an Authorized User to establish upper and lower thresholds for each analog point. As analog values are processed by the DMS, the value shall be compared against the thresholds. If the value is out of the range established by the upper and lower thresholds, then that data shall be logged to the Historical Data system.

Examples of events to be logged include, but are not limited to, the following:

• Normal • Running • Not running (normal state) • Abnormal • Running when device should be off • Not running when device should be on • Running but not draining sufficient volume • Total cumulative operating hours of all drainage equipment

b) DMS shall maintain data concerning all field devices in order to provide WMATA with the ability to generate reports in regards to the usage and maintenance of all drainage field devices.

The Contractor shall provide a complete list of all DMS controls and indications as a part of the Software Requirements Specification. (CDRL T308)

The Contractor shall confirm the device type, associated states and location of each Drainage Monitoring System device.

Page 160


7.7.2 Tunnel Drainage User Interface

ROCC personnel shall be provided with graphic display diagrams that shall allow control and monitor of all DMS devices.

a) Each Drainage Monitoring System device shall be represented by an icon on the track diagram configuration. Each icon shall reflect the type of device it is representing, for example, different types of pumps shall be distinguishable from one another.

b) ROCC personnel shall have the capability to select an apparatus for control by keyboard and/or mouse. If a device is selected via keyboard and/or mouse, the user shall have the capability to de-select it without canceling the entire command.

c) All DMS monitored devices shall be represented individually on ROCC software Displays and shall be subject to prototyping.

d) All features and standards for development of ROCC software Displays shall be defined in the Display Conventions and Guidelines Document (CDRL T201).

The DMS shall be designed such that future user-initiated commands will be accomplished through a three-step process. This three-step process shall:

a) Accept the user’s request; b) Display a preview of the state of the device to be affected by the control; c) Allow the user to execute the command (i.e., send to the field) or abort the command (retain the

current control).

Contractor shall implement the DMS such that any particular individual drainage device may only be controlled by a single user at any one time. Once a control has been sent to a device, that device shall remain locked out to all other Authorized Users until the control request is either executed (i.e. requested control implemented), cancelled, or after a configurable timeout period.

The track diagram configuration shall uniquely display icons to reflect the following conditions:

a) Provide a preview of device states; b) Provide an indication that controls have been sent to the field; c) Provide an indication that the field has responded to the control.

Not every control or indication is valid for every pump type. The menu for each pump icon shall reflect only those controls which are valid for the selected pump. ROCC personnel responsible for mainline operations, in concert with maintenance personnel in the field, are responsible for exercising Drainage Monitoring System devices to ensure proper operations.

a) DMS shall provide for a maintenance mode whereby the tunnel drainage devices can be exercised by the ROCC software.

b) The ROCC software shall recognize when each device is being exercised and shall log all associated controls and indications as such.

DMS shall process Drainage Monitoring System alarms. Alarms shall appear on both the graphic diagram and the Alarm Management Window, as described in Section 2.9 WMATA Alarm Processing. The following alarm conditions, at a minimum, shall be processed:

a) Loss of communications with RTU; b) Pump alarm; c) Additional alarms as determined by the Contractor in conjunction with WMATA personnel.

DMS alarms shall be displayed on the graphic displays relative to the location where the alarm condition has occurred.

Page 161


7.8 Passenger Information Display System

The ROCC software shall integrate with the Passenger Information Display System. The Contractor shall replicate the existing interface between the existing OCC Control Software and the CommNet PIDS system, as shown on the Contract Drawings.

The ROCC software shall provide accurate train arrival information to the WMATA PIDS system during single tracking or other abnormal events.


a) Prepare an Interface Document (design and implementation approach), b) Perform Software development, c) Perform Integration Testing, d) Provide Documentation, e) Provide Training.

7.9 Worker Ahead Warning System

The ROCC software shall provide a software module to monitor and control the Worker Ahead Warning System (WAWS). This software module shall contain an animated graphic of the WAWS. The animated graphic shall be updated from real time, real world data. The software module shall have very high level of accuracy, detail, availability and deploy a modern GUI. Operator actions shall be privilege based and contain built in checks to prevent operator errors. This software module shall referred to as the Worker Ahead Warning System.

WMATA is currently working to define, design, and install a Worker Ahead Warning System throughout the WMATA rail territory. The Contractor shall work with WMATA to develop the screen indications and finalize the policies and procedures required for this warning system. Commonly referred to as the amber light caution system, WAWS consists of physical lights located along the track at the wayside that indicate the presence of a worker in the immediate area of the amber light when illuminated.

Once concept being investigated for the WAWS consists of numerous zones; typically a zone is a single track segment from one station to the next. Control and status for each zone shall be provided. The zone status shall be displayed at the Operator Console as a graphical indication. Individual amber light failures should be displayed on the Maintenance Console:

a) A number of amber lights are wired together in series around any one location. Upon entering the location, a worker can toggle the lights ‘on’ to illuminate all of the amber lights in the series. Upon reaching the other end of the location, the worker then toggles the lights ‘off’.

b) At the time of Contract award, WAWS is implemented on the new Silver Line to Dulles Airport. WMATA intends to continue rolling out WAWS to the remainder of the WMATA rail territory.

c) The ROCC software shall provide the capability to control all amber lights, including the functionality to toggle the amber lights on or off for any given location.

d) The ROCC software shall monitor the status of all amber lights, indicating on or off. e) Amber light indications shall appear on all ROCC Displays, at the lowest level of declutter. That is,

amber lights shall be on the same declutter level as signals. f) The amber lights that exist at the wayside are numerous. The number of amber lights that are actually

physically depicted on the ROCC Displays shall be dependent upon zoom level. g) At varying levels of zoom, one amber light on a Display may represent one amber light in the field or

many amber lights in the field. h) There shall never be less than one amber light per location depicted on the Display even at the widest

level of zoom. i) Regardless of zoom level or amber light granularity, the amber light(s) depicted on the Displays shall

clearly relay whether the amber lights for that location are on or off. j) Contractor shall provide an alarm for a burned out amber light bulb, including which specific amber

light is out.

Page 162


The ROCC software shall provide an “auto reminder” feature where it shall be continuously annunciated to ROCC software users at a user-configurable time interval when the WAWS has been activated..

7.10 Station MEP Equipment – /* BID OPTION */

The ROCC software shall provide a software module to monitor and control the Passenger Station Mechanical / Electrical / Plumbing systems (MEP) systems. This software module shall contain an animated graphic of the MEP systems. The animated graphic shall be updated from real time, real world data. The software module shall have very high level of accuracy, detail, availability and deploy a modern GUI. Operator actions shall be privilege based and contain built in checks to prevent operator errors. This software module shall referred to as the Passenger Station MEP systems.

The ROCC software shall provide for the control and monitoring of WMATA Passenger Stations MEP Equipment and all associated devices in a system that is referred to as the Passenger Station Electrical Rooms. Typical MEP equipment include:

a) High Voltage Breakers b) Transformers c) PLCs d) Secondary Main Breaker e) Low Voltage Tie Breaker f) UPS g) Battery Room Ventilation h) Access Control i) Fire Alarm

The ROCC software shall provide the software licenses and functions necessary for Authorized Users to monitor the MEP equipment at all stations throughout the WMATA rail territory.

Each station has two power sources, an AC Power component, and a Traction Power component.

a) Each power source, AC Power and Traction Power shall be monitored independently of one another. b) The ROCC software shall provide the capability to show AC Power and Traction Power separately.

7.11 Rail Yard Monitoring – /* BID OPTION */

The ROCC software shall provide a software module to monitor and/or control the Rail Yards. This software module shall contain an animated graphic of the Rail Yards. The animated graphic shall be updated from real time, real world data. The software module shall have very high level of accuracy, detail, availability and deploy a modern GUI. Operator actions shall be privilege based and contain built in checks to prevent operator errors. This software module shall be referred to as the Rail Yards Control Panel. A workstation shall be installed in every Yard Control tower.

There are nine rail yards in WMATA’s rail system. One yard currently has an Allen-Bradley PLC connected to the rail yard switches and other devices. WMATA has plans to install some type of monitoring hardware in the remaining rail yards. The Contractor may be required to provide manual inputs for these locations to support the deployment until WMATA provides electronic data collection throughout the rail yards.

7.12 SCADA for use outside of the ROCC – /* BID OPTION */

The ROCC software shall provide a SCADA software module for use outside of the ROCC. The SCADA for use outside of the ROCC software module shall have a wider user’s base and gather electronic information from a broad collection of transit related MEP systems. A SCADA System for use outside of the ROCC shall be designed, installed, tested and Commissioned in accordance with these specifications. This Maintenance SCADA System shall communicate directly to the wayside SCADA PLCs, RTUs, and other field devices and may receive an additional 1,000,000 I/O Points.

This system shall follow all the same requirements within this specification used for the development of the ROCC software. The Contractor shall include the following requirements and features within this system:

Page 163


a) Separate Front End Processors (FEPs), Servers, Switches, Workstations, Databases, etc. b) Separate Networks are being developed by WMATA within the overall rail network. A separate

SCADA Maintenance Network will be created that will link all field units. This will include connections to both Control Centers. The Contractor shall design the OCC Networks and connections in accordance with these specifications. This network will be connected to WMATA’s corporate network to provide a path between the field units and SCADA Maintenance personnel for configuration of field devices.

c) Separate logins from the Operational ROCC software. d) Separate Graphical displays screens, tables, charts and graphs for all points. (Typical screens, charts

and graphs will be provided on Procure.) Same look and feel of the ROCC software being provided. e) Historical event log for all data points f) Addressable URL links on display screens to bring up configuration displays g) Connections into the WMATA’s Maximo Database

7.13 100 Percent Train Tracking – /* BID OPTION */

The Contractor shall provide an option for 100 percent automated train tracking. WMATA shall be able to search on a Train ID number and the location within the rail system shall be identified. The Contractor shall provide an analysis of the existing WMATA rail road infrastructure and electronic data gathering and offer a solution to provide 100 percent tracking of rail vehicle(s) on the WMATA rail system. This will include dark areas in the WMATA rail yards.

7.14 System Wide Traffic Regulation/Modeling – /* BID OPTION */

The ROCC software shall provide a software module to model and regulate system wide rail traffic. This software module shall provide recommended adjustments to system wide train movements to achieve major objectives such as consistent headway times or surge evacuations.

An example of a consistent headway time would be a switch goes out of correspondence in the down town section of the rail road and the ROCC software temporary adjusts the departure times at the end of line stations to avoid bunching near the affected switch. An example of a surge evacuation would be to evacuate large crowds departing a major sporting or political event.

7.15 Overview of Rail System

The ROCC software shall output a general overview display of railroad operations for use throughout the authority. This display shall be view only and be provided through very tightly controlled one way security portals from the WMATA ROCC software.

Page 164


8. Test and Commissioning

All components of the ROCC software shall be fully tested during development, first at the lowest unit level and then integrated into software systems and hardware systems. After completion of the software development testing and hardware development testing, the hardware and software shall be integrated and tested in the factory to verify that the system was built to design. Following completion of factory testing, the fully tested system shall be installed at the site and tested to verify that the design is correct and the system is properly connected and communicating with external interfacing Systems.

Proposal Requirement: The Proposer shall provide in his technical proposal detailed information about the Test and Commissioning process for software.

Throughout this section of the Specification the term ‘stage’ is used to refer to an implementation stage of implementation and commissioning. The implementation of the ROCC software shall be undertaken as a series of planned System implementations or stages. The test and commissioning activities apply to specific phases of the development life-cycle therefore the term ‘phase’ as used in this section of the Specification refers to the test phases of the development life-cycle.

8.1 Master Test Plan

The Contractor shall develop a comprehensive testing program that includes complete verification and validation of all hardware, software, maintenance, and operation of ROCC software:

a) The Contractor shall document all processes, activities, guidelines, and methodologies for implementing and controlling the Test Program in the Master Test Plan, (CDRL T601).

b) The Contractor shall plan and perform all test, implementation, and commissioning activities for each implementation stage as defined in WMATA approved Implementation and Commissioning Staging Plan. (CDRL T111)

c) The Contractor’s comprehensive testing program shall verify and validate the ROCC software against the complete set of requirements as defined in these Specifications, as well as those defined and derived by the Contractor during all phases of development, including prototyping. The complete set of System requirements shall be defined in the Functional Requirements Definition (FRD). (CDRL T105)

The Master Test Plan shall include all required Test Plan components, with emphasis on:

a) Definition of all phases of testing; b) Relationships between each phase; c) Relationships of testing between the new OCC Software and existing systems, i.e., dependencies; d) Overall test and commissioning methodology; e) Regression test strategy to be implemented as part of each test phase; f) Identification of the test documentation to be developed and used for each phase; g) The overall test program schedule; h) Responsibilities (Contractor and Engineer) for testing; i) Criteria to be applied to determine successful completion of each phase and the method to be used to

measure completion; j) Risk identification, control, and management; k) Variance Tracking Program; l) Methodology to assure that all functionality, user operations, performance, normal and abnormal or

perturbed conditions are completely and successfully tested prior to control of revenue trains or traction power.

The Master Test Plan shall describe the procedures and include forms for recording the ROCC software hardware and software configuration for each test or series of tests that includes the name and version number of each software module and hardware component.

The Master Test Plan shall describe the procedures for controlling and documenting all changes made to the hardware and software of a System after the start of testing.

Page 165


The Master Test Plan shall describe the procedures and include the forms for test record keeping during the test, analyzing and recording test results and use of the Variance Tracking Database. This shall include all record-keeping forms and describe the procedures for the use of each form, a description of the Variance Tracking Database that will be used during all phases of testing and procedures for monitoring, analyzing, correcting, regression testing and re-testing of variances.

Should any inspections or tests indicate that hardware, software, or documentation does not meet the specified requirements; the appropriate items shall be repaired, replaced, upgraded, or added by the Contractor at no additional cost to WMATA, as necessary to correct the noted deficiencies.

In the event that changes and/or modifications are made during, or resulting from testing, WMATA has sole authority to determine any and all tests that the Contractor shall repeat and/or additional tests that shall be performed.

8.1.1 Plans and Processes

Test Plans and Test Procedures (CDRL T601, T602, T603, T604; see below) shall be provided by the Contractor for all tests and demonstrations to ensure that each system, factory, and site test is comprehensive and verifies the proper performance of ROCC software elements under test.

The Contractor shall prepare software development Test Plans and Test Procedures that comply with the specific requirements defined in these requirements.

During the development of Test Plans and Test Procedures for the ROCC software, emphasis shall be placed on:

a) Testing each functional requirement, system feature, and system design detail, organized by subsystem, under the full range of operating situations and conditions including error conditions;

b) Defining the evaluation criteria for test results; c) Schedule and timeframes for testing; d) Documenting the test equipment and simulation techniques used; e) Documenting the reporting and data logging methods used to record the results.

The Test Plans and Test Procedures shall be organized into one or more repeatable test segments (or test cases) that combine to form a series of tests that together fulfill the purpose and objectives of a test.

All test documentation, including Test Plans, Test Procedures, and test results, shall be in compliance with the latest issue of IEEE 829, Standard for Software Test Documentation.

All factory and site Test Plans and Test Procedures shall be submitted to WMATA for approval and shall be approved prior to the initiation of the test phase for which they apply.

The Contractor shall develop all testing that impacts WMATA operations and existing systems such that it minimizes disruption to the operation and is consistent with WMATA labor contracts and hours of service.

8.1.1.1 Implementation and Commissioning Staging Plan

The commissioning of the ROCC software is being specified as a set of implementation stages. The complete implementation and commissioning of each implementation stage must be fully and completely defined prior to the start of the work for the current stage.

The Implementation and Commissioning Staging Plan (CDRL T111) shall identify and define in detail the activities and controls necessary to ensure adequate testing and commissioning of the current implementation stage, minimally including the following:

a) Schedule identifying all critical activities and responsible parties; b) Plans and procedures applicable to all test and commissioning stage activities defined for the

implementation stage;

Page 166


c) Contractors activities and detailed description of each activity; d) Engineer preparation and participation requirements; e) Requirements for data inputs and outputs; f) Qualitative assessment of impacts and adjustments to WMATA personnel, and facilities; g) Coordination with other WMATA on-going work; h) Qualitative assessment of impacts and adjustments to the Control Center environment; i) Qualitative assessment of impacts, disruptions, and adjustments to reconstruction; j) Regression test activities related to current operational territory, functions, and operation; k) Risk assessment and mitigation strategies for implementation and commissioning of the ROCC

software.

8.1.1.2 Test Plans

The Test Plans shall identify the Test Organization, test personnel, the responsibilities of the Contractor and Engineer for implementing the Test Plan, identify the responsibilities of individuals assigned by the Contractor to administer and implement the Test Plans and identify the responsibilities and skill levels of individuals assigned to conduct the tests.

The Test Plans shall describe the overall test process and shall include:

a) An overview of the plan for conducting all tests; b) A description of the test progression (when the tests are progressive or cumulative); c) Outline and format for Test Procedures; d) Identification of all Test Procedures that make up the test(s) defined by the Test Plan; e) A description of the purpose and objectives of each test and series of tests that includes the test type

(such as interface test, load test, timing test, invalid input test, stress test, etc.); f) Identification of the test site(s); g) Test configuration, including identification of Contractor and WMATA-supplied external devices for

factory tests; h) Record keeping assignments, procedures, and forms; i) Problem resolution and procedure for handling variances; j) Provisions for retest; k) Test tools, environments, simulators, test software, and other test components, as applicable.

The Test Plans shall include a schedule that defines:

a) estimated duration of each test; b) the sequencing of test procedures; c) dependencies and/or restrictions on the execution of test procedures; d) test equipment and test personnel including Contractor and Engineer witnesses.

Test schedules shall be updated and submitted on a weekly basis to include the following:

a) Document the status of the tests that have been executed during the prior week; b) Identify tests to be executed in the upcoming week; c) Identify the associated test procedures to be run.

8.1.1.3 Test Procedures

Test Procedures shall define all test segments to be performed and include a description of the purpose and objectives of each test and test segment.

The Test Procedures shall describe:

a) Individual test segments and the steps comprising each segment, including detailed descriptions of the methods and processes to be followed;

b) The techniques and scenarios to be used to simulate system field inputs, controlled equipment and data exchange;

c) Setup and conditions for each test segment; d) Any certified test data to be used;

Page 167


e) The name of the function to be tested; f) The unique functional requirement identification for each functional requirement tested by the test

procedure; g) References to the functional, design, user, and other documents describing the function; h) All software tools, test data files, special test software, and special display dialogs required to conduct

the test and include descriptions and user instructions for test software tools and displays; i) Step-by-step instructions and all applicable safety warnings for setting up the test environment,

specific inputs and user actions for each test step, expected results, pass/fail criteria to be applied.

8.1.1.4 Test Records

Complete Test Records of all factory and site acceptance tests results shall be compiled and maintained by the Contractor and delivered to WMATA at the completion of each test. Complete Test Records of all software and hardware component test results shall be compiled and maintained by the Contractor.

Test Records shall include:

a) unique test record identifier; b) name and version number of each software component c) the date and actual duration of the test. d) identify the Contractor’s test engineer and or Engineer’s test representative. e) test data and simulation files included in the test, by name, version number, and location in the test

configuration f) outputs including reports, display copies, and any other printed or electronic records such as event and

alarm logs, generated as part of the test g) reference to the test procedure and document any deviation from the test procedure in the form of a

description of any test conditions, configuration, input data, output, display, or user actions differing from that described in the test procedure;

h) passed/failed indication.

8.1.2 Variance Tracking Program

The Contractor shall implement a comprehensive Variance Tracking Program. The Variance Tracking Program shall be, documented in the Master Test Plan. The Contractor shall define the processes associated with the identification, collection, tracking, and reporting of variances over the life of the project and who is permitted to change the status of a variance, under what circumstances, and the timeframe for change. All deficiencies, errors, inaccuracies, or other issues identified during any phase of the System development that fail to adequately fulfill the system requirements shall be handled as part of the Variance Tracking Program. This Variance Tracking Program shall incorporate the requirements of this Specification.

After correction of a deficiency, all tests necessary to verify the effectiveness of the corrective action shall be repeated and regression testing shall be conducted to the satisfaction of WMATA.

The Variance Tracking Database shall be implemented and maintained as a single database, accessible at all times by authorized Contractor personnel for the reporting, tracking, and reviewing of variances defined within this Specification.

The following information shall be included in the variance report:

a) A sequential identifying number assigned to the variance; b) The date and time the variance was detected; c) Appropriate references to the Test Procedures related to the variance and the requirements tested by the

Test Procedures; d) A description of the test conditions at the time the variance was detected and a methodology for

reproducing the variance; e) Identification of Contractor staff member assigned to correct the variance f) Identification of Contractor and Engineer’s representatives responsibilities, such as Assignment,

Correction, Signoff, Retesting, Acceptance and Closure of variances;

Page 168


g) A description of the cause of the variance, the affected System(s), system elements and corrective actions taken (or to be completed as part of the variance resolution process);

h) Identification of documentation and other data items that require update or are updated; i) A dated signature line for WMATA and Contractor representatives to signify correction of the

variance.

Each variance shall be assigned, subject to the approval of WMATA, to one of three variance classes defining the action to be taken to resolve the variance:

a) Class 1–Testing will immediately stop and the Contractor will evaluate and correct the variance before testing is resumed;

b) Class 2–Testing will continue and the variance will be evaluated and corrected by the Contractor at the end of the current test session (i.e., test segment as defined in the approved Variance Tracking Program defined in the Master Test Plan) but prior to further testing;

c) Class 3–Testing will continue and the variance will be evaluated and corrected at a mutually agreed upon time.

The Contractor shall define variance class assignment based on analysis on categorization of the failure as follows:

a) Class 1 failures: critical failures that prevent further testing of the function under test where no workaround is possible. Failures of this type include those that cause the system to cease functioning or freeze; where a menu option is missing or selectable items required to continue with operation are missing; where security permissions required for access to a function is missing; or where the system functionality or user interface executes in an erroneous or random manner resulting in loss of operational control;

b) Class 1 failures: major defects to critical functions that cause the system under test not to function as expected or designed where the functionality fails to meet requirements such that a workaround may require a reboot, System Administrator parameter change, database change, or design change. These types of failures include inaccurate system calculations; the wrong field in a display, report, database, or file from being updated; the wrong data being retrieved by the system; a critical refresh or update that fails to complete; exceeding of system response and performance; or failure to record or log historical data;

c) Class 2 failures: defects to critical functions that cause the system under test to not conform to standards and conventions for which workarounds exist to achieve functionality objectives. Examples of this type of failure includes delay in alarm notification; display errors that do not affect system operation and cosmetic defects; test procedure omissions or errors not affecting the continued operation or result assessment of the test;

d) Class 2 failures: defects to non-critical functions that do not affect the critical functionality of the system:

e) Class 3 failures: defects which do not affect the functionality of the system. Examples of this include inconsistencies between documentation and system operation where the documentation is incorrect; improper formatting, grammatical errors, or spelling in documentation.

The Contractor shall maintain and periodically distribute a variance summary, as requested by WMATA. The variance summary shall list the following for each variance:

a) The report number; b) A brief description of the variance; c) The class of variance; d) The current status of the variance (identified, cannot recreate problem, fix delayed, scheduled for

fixing, fixed but untested, tested, incorporated into a build, retested, fixed, closed).

As a minimum, a variance summary listing all open variance reports shall be provided by the Contractor at each monthly Progress Meeting.

8.1.2.1 Resolution of Variances

The Contractor shall document all actions taken to correct variances on the variance report.

Page 169


The variance report shall:

a) Document the functional areas impacted by a variance and associated corrective actions b) Include any instructions necessary to incorporate the resolution of the variance into the software

release.

Sufficient information shall be provided to enable WMATA’s representative to determine the need for and extent of re-testing, the need for testing interactions of the correction with any previously tested hardware or software, the need for new additional testing not previously included and the need for updating appropriate documentation.

A variance shall be deemed resolved only when all re-testing has been performed to the satisfaction of WMATA and after the Contractor’s and WMATA’s representatives acknowledge correction of the variance on the variance report.

8.1.2.2 Test Initiation

Before starting any test, the Contractor shall provide documentation that confirms that all relevant prerequisite testing has been completed and all variances recorded during prior tests and development phases shall be mitigated and corrected to the satisfaction of WMATA.

All Test Plans and Procedures and relevant documentation for the test (including drawings, lists of deliverables, requirement and design documents, and user manuals) shall be approved by WMATA prior to starting any test.

In order to enable subsequent recreation of the system and software environment for re-testing the Contractor shall save all software for the system under test to archive media prior to the test, in addition to maintaining software under strict configuration control.

The Contractor shall demonstrate to the satisfaction of WMATA that all software (including all operating system parameters, files, and configuration information, all database, display, and report definitions, and all source code libraries) required to re-establish the system under test has been saved to archive media prior to the test and that software under control of the Software Configuration Management System is unaffected.

The Contractor shall demonstrate to the satisfaction of WMATA that installation of all software, including COTS and non-COTS executable software, non-executable files, and data, and recreation of the ROCC software to a fully functional and operational state, is in conformance to the installation procedures defined in the Installation Plan

8.1.2.3 Test Completion

A test shall be deemed to be successfully completed only when:

a) All variances have been resolved to the satisfaction of WMATA; b) All test records have been transmitted to WMATA; c) Engineer acknowledges, in writing, successful completion of the test.

The Contractor shall not initiate any test activity until the prior test phase is deemed successfully completed.

8.1.2.4 Test Suspension

If WMATA believes, at any time, that the quantity or severity of ROCC software variances warrants suspension of any or all testing, the test shall be halted, remedial work shall be performed, and the complete test shall be repeated.

The repeat of any suspended test shall be scheduled for a date and time agreed upon by both the Contractor and WMATA.

Page 170


8.1.2.5 Future Testing – Parallel Development Environment

The Contractor shall support the establishment of a Parallel Development Environment to be installed at a location of WMATA’s choosing on WMATA property.

The Parallel Development Environment shall be a comprehensive, complete development workstation on which WMATA personnel will have full software development capabilities in addition to hardware testing capabilities.

The Parallel Development Environment shall provide a platform for WMATA to test all software and system configuration changes.

Software or configuration changes tested on the Parallel Development Environment shall be able to be rolled out to the on-line production ROCC software via utilities loaded directly onto the Parallel Development Environment:

a) It shall not be necessary to load changes tested on the Parallel Development Environment onto another system or device before being deployed onto the on-line production ROCC software.

b) The Contractor shall supply the process(es) necessary to roll-out software and configuration changes to the on-line production ROCC software which will be reviewed and confirmed to be consistent with WMATA operational procedures.

The Parallel Development Environment shall provide a complete software development environment consisting of source code, object files, linkers, compilers, debuggers, CASE Tools, class browsers, licenses, and anything else that might be required to produce the ROCC software.

The Contractor shall specify all hardware that is necessary for the Parallel Development Environment in the Hardware Specifications.

8.1.3 Commissioning and Transition

The Contractor shall include within the Master Test Plan, a method of Commissioning and Transitioning from the existing OCC Control software to the new OCC Control Software. The period of time while the software is being phased over from the existing CTF software, to the new OCC Control Software installed at JGB is referred to as the Transition. Transition consists of 2 Phases:

a) Gradual ramp-up to full operation starting with periods of low risk, such as weekend nights, to periods of higher demand; eventually achieving full control during rush hours.

b) Contractor supported full operation. Pre-requisite for starting transition is the satisfactory completion of all site acceptance tests including all performance and operational tests.

The Contractor shall develop and implement a complete and comprehensive plan, the Transition Plan (CDRL T606), describing the process and activities involved in transitioning operation of the existing OCC Software to the new OCC Control Software. The Transition Plan shall define the responsibilities of Contractor and WMATA personnel during each phase of transition. The Transition Plan shall define the following:

a) schedule for transition activities, b) all activities and processes to be implemented during each phase of transition, c) process of defining and mitigating risks associated with successful transition, d) Cutover Plan, including definition of what existing territory partitions will be implemented in a

specific order and definition of functions to be transferred in a specific order.

• The Cutover Plan shall be an extensively detailed step-by-step set of directions for implementing the system cutover.

The OCC Control Software shall be installed and operated in “shadow” mode (monitor-only) where all indications are received without impact to existing operations. This method shall be used during transition for

Page 171


transferring between control centers. WMATA will furnish personnel to operate the JGB consoles during the transitions for testing.

During this period JGB shall operate a complete complement of equipment and all functions shall be available. The Contractor’s responsibilities during the transition period shall include maintaining variance reporting; immediately responding to and correcting any and all variances; answering WMATA questions, and working closely with WMATA to assist in preparation for WMATA to maintain the new ROCC software.

The Contractor shall develop transition plans that are acceptable to WMATA operations. The Contractor shall adjust the quantity of work and/or operational territory as directed by WMATA to minimize adverse impact and risk to the operation.

At no time shall the Primary ROCC software be active without the Secondary ROCC software being available and at the ready for immediate failover.

8.1.3.1 Transition Plan Guidelines

The following represents a proposed approach to testing and transition of the ROCC software. This shall be considered as a suggested guide only. The Contractor Transition Plan shall contain extensive additional detail and shall not be constrained by the suggested guidelines herein.

a) WMATA will post relevant IO mapping, including interlocking information, on the project Procore web site.

b) The Contractor shall prepare the ROCC software software in accordance with the provided information, the accepted ConOps, and other directive information as provided within the Contract Documents..

c) The Contractor shall develop the ROCC software software application at the Contractor’s facility (or alternatively at the CTF site) based upon the information contained herein.

d) At the Contractor’s facility, the ROCC software application shall be installed on the actual production servers intended for use with the deployed production ROCC software. Communications shall be established through test fibers to the intended network switches/routers.

e) The Contractor shall develop a test traffic simulator to exercise the ROCC software servers in order to demonstrate that the servers are appropriately configured (e.g. size and performance) for the anticipated live ROCC software load, and can transition between primary and secondary and back as intended.

f) The ROCC software equipment shall then be delivered and set up at CTF as the Primary OCC. g) The Contractor shall provide a test interface to the existing, live WMATA field network. The interface

will allow the Primary ROCC software equipment to function with the incoming data without transmitting any data.

h) Using the not-yet-live system, demonstrate fail over and recovery at CTF. Demonstrate display screens and interface with WMATA system at CTF. Test interlocking operations.

i) Upon successful completion of Primary ROCC software tests CTF move the Secondary ROCC software to JGB. Secondary ROCC software tests shall be performed at JGB after moving equipment.

j) Cut over to new Primary ROCC software and the Secondary ROCC software.

8.1.4 Inspection

The Contractor shall provide Authority representatives free and unrestricted access into Contractor or Subcontractor facilities or shops where the OCC Software System design, fabrication, and testing are taking place, and into any mill, shop, or factory where hardware or software is being produced.

The Contractor shall provide to Authority representatives, at no cost, all reasonable facilities, equipment, and documentation necessary to verify that the ROCC software is being produced in accordance with the Specification.

The inspection rights described above shall not apply to facilities of the Contractor’s subcontractors supplying unmodified standard or Commercial off the Shelf (COTS) items or unit components such as peripheral equipment or operating systems. Such items will be inspected and tested by Authority representatives at the

Page 172


Contractor’s manufacturing site.

8.1.5 Preventive and Corrective Maintenance

The Contractor shall be responsible for performing repairs and recommended preventive maintenance on all system software elements during development, integration, and testing through final acceptance of the ROCC software.

The Contractor shall supply all necessary diagnostic tools, support, and expertise to assist in the repair and maintenance of WMATA-supplied system hardware elements.

Both a repair log and a preventive maintenance log shall be kept for the ROCC software.

The repair log shall include the following:

a) Identification of item repaired; b) Date and time malfunction was detected; c) Description of malfunction; d) Date and time malfunction was corrected; e) Description of corrective action taken.

The preventive maintenance log shall include:

a) Identification of the element being maintained; b) Date and time maintenance was performed; c) Description of the maintenance procedures performed; d) Description of problems encountered.

Entries in both logs shall be initialed by the engineer or programmer performing the task. Both logs shall be available to the Authority at all times and shall be submitted to the Authority upon completion of the field performance test.

8.1.6 Availability and Reliability Demonstration Tests

A continuous Availability and Reliability Demonstration Test shall be conducted by the Contractor to verify that the ROCC software meets or exceeds the specified availability and reliability. The test shall be fully documented including planned tests and results in the Availability and Reliability Demonstration Test Plan (CDRL T610.1).

During the Availability and Reliability Demonstration Test WMATA will furnish personnel to run the ROCC software and the Contractor shall furnish personnel to monitor the test, prepare and maintain test documentation, provide assistance in response to failures/variances, and answer questions.

Representatives of WMATA and Contractor shall monitor and witness the Availability and Reliability Demonstration Testing.

The Availability and Reliability Demonstration Test shall be:

a) conducted following the Transition Period and after all software and hardware documentation is received and approved by WMATA;

b) verified, functionally (both full functionality and critical functionality), c) a fixed length test of six months of operation, properly and consistently documented through test logs. d) consist of normal ROCC software operations without special test equipment or procedures.

The Availability and Reliability Demonstration Test shall be conducted while the ROCC software is controlling revenue service and in an operational environment, including, but not limited to, train service, power control, operating modes, temperatures, electromagnetic interference, shock and vibration.

Page 173


Reliability is demonstrated through test, which is described as a definitive period of time in which to determine the probability that the ROCC software equipment, software, and functions actually exhibit the specified level of reliability. The probability of accepting equipment with a true mean-time-between-failure (MTBF) equal to the lower test MTBF is measured as the Consumer’s risk. Well defined test methods are described in MIL-HDBK-781A and are required to be applied by the Contractor. The test parameters to be used in the determination of Consumer’s risk are specified in this Contract, including acceptable confidence level (WMATA risk) and discrimination ratios. The discrimination ratio is measured as the ratio of the upper test MTBF to the lower test MTBF.

The Availability and Reliability Test Plan shall be provided for the Preliminary Design Review, and a final version provided for the Final Design Review. This plan shall include a detailed test schedule, include identification of resources necessary for testing including facilities, support equipment, spare parts and coordination procedures with WMATA and/or Representatives. Demonstration tests shall be consistent with MIL-HDBK-781.

8.1.6.1 Availability and Reliability Test Satisfaction

Test records shall be examined by the Contractor after the first 6 months of valid test time, and weekly thereafter, to determine conformance with the availability and reliability criteria. If test objectives have not been met, the Contractor shall take whatever remedial measures are required to implement corrective action, including but not limited to any necessary repair, replacement and redesign work. Satisfaction of the test shall only be met when the specified availability and reliability is achieved based on a consecutive six-month period of test time, exclusive of “holdtime”.

In the event that in ten consecutive calendar months from test initiation, a consecutive 6-month period of testing is not achieved in which the requirements of the test are met, and all ROCC software errors are not corrected to the satisfaction of WMATA, the demonstration test shall be considered failed.

To establish that all failures have been satisfactorily repaired prior to the end of the Availability and Reliability Demonstration Test, no downtime, intermittent (holdtime) failures, or more than one uncommanded failover shall have occurred within 240 hours of the test’s conclusion. The test shall be extended (up to the ten consecutive calendar months), if necessary, to satisfy this requirement.

8.1.6.2 Availability and Reliability Demonstration Test Assessment

The Contractor shall prepare and submit an Availability and Reliability Demonstration Test Assessment Report (CDRL T610.2) after completion of all subsystem and equipment testing. The report shall summarize all Reliability Test Logs obtained during the Availability and Reliability Demonstration Test including; test results, actual reliability growth achieved, mathematical analyses, and engineering analyses to ensure that the ROCC software reliability meets or exceeds the MTBF requirement for each system configuration. The report shall be submitted to WMATA for approval within 2 weeks of meeting the test satisfaction requirements.

8.2 Factory Acceptance Tests

The Factory Acceptance Tests (FAT) represents a substantially complete and properly functioning system that is ready for shipping the ROCC software for installation and site testing.

The Contractor shall prepare and perform demonstration tests of the ROCC software in the factory prior to shipment to demonstrate to the satisfaction of WMATA that the ROCC software has been fully developed and is ready for installation.

The Factory Acceptance Tests (FAT) shall demonstrate the full operational state of the ROCC software, as well as the operations under designated load conditions as defined in Appendix C.

Page 174


The Contractor shall prepare and submit for Engineer approval a Factory Acceptance Test Plan, (CDRL T601.1), defining the complete test plan for Pre-FAT and FAT. The FAT Test Plan shall include a comprehensive plan to successfully perform all FAT tests defined in this Specification:

a) The FAT Plan shall include a description in text and diagrams of the configuration of the ROCC software during FAT including all simulators and test support devices.

b) The FAT Plan shall document FAT objectives and roles and responsibilities of all participants including WMATA and Engineer’s representatives.

The Contractor shall prepare and submit for Engineer approval, ROCC software FAT Test Procedures, (CDRL T601.2), defining the complete set of test procedures to be used during Pre-FAT and FAT.

The ROCC software FAT Test Procedures shall include the individual Test Procedures for execution of each FAT. The Contractor shall collect all FAT results from each individual FAT into the ROCC software Factory Acceptance Test Results, (CDRL T601.3), and submit within 6 weeks of the successful completion of FAT.

Formal Factory Acceptance Tests shall be conducted on the ROCC software including the simulation of a representative set of Field Control Units (FCU). The ROCC software shall be fully tested prior to shipment to the field by using software or hardware interfaces to simulate the field I/O.

The latest controlled version of the deliverable hardware and complete and fully functioning ROCC software software shall be concurrently tested. The substitution of hardware or software for the deliverable items shall be allowed only with the written permission of WMATA.

Responsibility for the conduct of all factory tests shall rest with the Contractor. The Contractor shall permit WMATA’s representatives to witness all tests and have a time period reserved to perform hands-on execution of the Factory Acceptance Test Procedures as selected by WMATA.

Contractor representatives knowledgeable in the design, operation and testing of the ROCC software shall be present at all times to assist in the testing and assist WMATA’s representatives with factory testing as needed.

Unless authorized in writing by WMATA, WMATA or WMATA’s representative shall witness all factory acceptance tests as a condition of approval. Approval of the FAT demonstrations does not constitute final acceptance of any portion of the ROCC software.

The FAT shall consist of three separate tests and the requirements for Test Plans and procedures, test records, test initiation, test satisfaction, test suspension and Unstructured Testing shall apply separately for each of the following FAT tests:

a) Hardware Integration Test; b) Functional Performance Test; c) Integrated System Test.

The Contractor shall successfully validate the Factory Acceptance Test Procedures during ROCC software pre-FAT, prior to formal Factory Acceptance Tests.

Prior to initiation of the FAT the Contractor shall perform Pre-Factory Acceptance Testing, consisting of a complete dry-run of all of the FAT tests, to verify all FAT Test Procedures and assure that the ROCC software is complete and ready to pass all FAT tests.

The Contractor shall ensure that all documents, configuration items, and materials necessary for pre-FAT testing, as defined in the approved ROCC software FAT Test Plan, are complete and approved for use. The Contractor shall ensure that all variances detected during pre-FAT testing are documented and corrected prior to starting FAT testing, unless approved by WMATA.

The Contractor shall ensure that all documents, configuration items, and materials modified during pre-FAT are revised, maintained under configuration control, and re-approved for use prior to beginning FAT. Prior to

Page 175


initiating the FAT, the Contractor shall apply and verify all changes to ROCC software software, hardware and documentation resulting from the Contractor’s development testing and the Pre-Factory Acceptance Testing.

The Contractor shall ensure that all Variances generated during the developmental testing and all phases prior to FAT have been satisfactorily mitigated and closed, prior to beginning Factory Acceptance Tests.

8.2.1 Pre-Factory Acceptance Testing

The Contractor shall verify that the ROCC software is ready for the FAT by performing preliminary testing of the FAT, designated as pre-FAT prior to formal demonstration of the FAT.

At the earliest possible point during integration but no later than Final Review, the Contractor shall conduct Pre-FAT tests by performing dry-run testing of all FAT tests (excluding, at the Contractor’s option, the Integrated System Test) using the approved Test Plans and Procedures:

a) The Contractor shall prepare a checklist of all functions, subsystem, interfaces, devices, and territory location(s) to be tested during pre-FAT as part of the FAT Test Plan.

b) The Contractor shall complete the checklist during pre-FAT as each item successfully completes testing as part of the record of pre-FAT Test Results.

At least one week prior to FAT, the Contractor shall submit written Pre-FAT Certification (CDRL T601.4) of completion of Pre-FAT testing to WMATA for approval. The Contractor shall prepare and submit as part of the Pre-FAT Certification, complete Pre-FAT Test Results. The Engineer’s representative shall be permitted to witness and participate in the Pre-FAT tests, as deemed necessary by WMATA. Successful completion of pre-FAT shall not relieve the Contractor of any responsibilities of Factory Acceptance Tests (FAT).

Neither pre-FAT nor FAT shall be designated as or substitute for the Contractor’s ROCC software developmental testing, but rather shall demonstrate to the satisfaction of WMATA the substantially completed ROCC software prior to implementation in the field.

8.2.2 Hardware Integration Test

The Hardware Integration Test shall verify that the ROCC software hardware conforms to the requirements of this Specification and the Contractor-supplied hardware documentation. The Hardware Integration Test shall be initiated and conducted after successful completion of the Pre-FAT and prior to the initiation of the Functional Performance Test.

A representative set of all ROCC software hardware, excluding the Video Display Wall equipment shall be installed in the Contractor’s factory prior to the Hardware Integration Test:

a) The Contractor shall define the representative set of hardware to be installed in the Contractor’s factory sufficient to support all factory testing. The set of hardware for factory test support shall include all ROCC software facilities including all ROCC softwares, playback and simulation, training, and simulators.

b) Sufficient workstation equipment, comprising of all workstation types and configurations, shall be installed in the Contractor’s factory to support all factory testing.

c) Sufficient server equipment, comprising of all server types and configurations, shall be installed in the Contractor’s factory to support all factory testing. Server configuration must include redundancy necessary to support failover test and demonstration.

d) Simulation of field devices, comprising field locations and configurations, shall be installed in the Contractor’s facility to support all factory testing.

The operation of each hardware item shall be verified in both a stand-alone mode and as an integral part of the ROCC software. Applicable hardware tests and diagnostics shall be used to verify that each hardware component is completely operational and assembled into a configuration capable of supporting software integration and factory testing of the ROCC software. The Hardware Integration Test shall also verify equipment expansion capability.

Page 176


8.2.3 Functional Performance Test

The Functional Performance Test shall be initiated and conducted after successful completion of the Hardware Integration Test and prior to the Integrated System Test.

The Functional Performance Test shall completely verify that all functions of the ROCC software hardware and software, including normal and abnormal conditions, conform to the requirements of these Specifications:

a) The Functional Performance Test shall include inspection of all equipment for conformance to drawings, implementation of the latest versions of hardware and software, and satisfactory construction and appearance.

b) The Functional Performance Test shall include testing of the proper functioning of all software, including normal and exception test cases, field and user-entered inputs and field responses to outputs.

c) The Functional Performance Test shall include simulation of field inputs. d) The Functional Performance Test shall include simulation of local and field input transient error and

failure conditions. e) The Functional Performance Test shall include simulation of control outputs to suitable indicators. f) The Functional Performance Test shall include verification of data links with external interfacing

systems and installed FCUs. g) The Functional Performance Test shall include simulation of FCUs (including sampling of each type of

FCU protocol), MERCS, and data transmission errors and channel failures, including but not limited to incorrect check codes, illogical data and random channel noise bursts.

h) The Functional Performance Test shall include testing of all user interface functions, including random tests to verify correct database linkages and correct handling of bad input data.

i) The Functional Performance Test shall include test and demonstration of ROCC software failover and startup functionality.

j) The Functional Performance Test shall include test and demonstration of the ROCC software training functions.

k) The Functional Performance Test shall include test and demonstration of the ROCC software playback and simulation functionality.

l) The Functional Performance Test shall include test of all interfacing systems and functionality. m) The Functional Performance Test shall include simulation of hardware failures and input power

failures to verify the reaction of the ROCC software to processor and device failure. n) The Functional Performance Test shall include testing of the proper generation and presentation of all

alarms, events and logs in response to failure conditions. o) The Functional Performance Test shall include demonstration of all features of the database, display,

and report generators and all other software maintenance features. p) The Functional Performance Test shall include demonstration of the software utilities. q) The Functional Performance Test shall include verification that the ROCC software meets or exceeds

the required performance requirements under simulated peak loading conditions. Loop back tests shall be performed to measure the transmission time between the ROCC software and field control equipment and FCUs.

r) The Functional Performance Test shall include verification of the accuracy of hardware and software documentation and maintenance procedures via random tests.

s) The Functional Performance Test shall demonstrate that the ROCC software meets all specified spare utilization, spare capacity, and timing requirements under off-peak and peak load conditions while monitoring and controlling the entire WMATA system by Territory.

t) All off-peak load and peak load performance tests, as defined in Appendix C, shall be performed to demonstrate these capabilities.

u) ROCC software activity during off-peak and peak periods shall be simulated using the simulation and test tools, delivered with the ROCC software.

v) The simulation and test tools shall simulate the motion of trains based on initial conditions; defined scenarios; and expected train progression, based on average train speed, dwell times, switch settings, track circuit lengths, automatic traffic regulation control algorithms, signal status and other field device status, and wayside logic restrictions.

w) Scenarios containing relative starts time, initial movement directions, train initial positions and system parameters shall be used during each test; scenarios shall approximate the operation of actual and

Page 177


enhanced service schedules. A convenient means of loading these “test” scenarios and establishing initial conditions shall be provided.

8.2.4 Integrated System Test

Final hardware and software must be tested together in the factory as an integrated system prior to shipment. The Integrated System Test shall successfully demonstrate the fully tested path of data originating in the field at the wayside through the communications system into the ROCC software in the office, then back out again to the field.

The Integrated System Test shall be initiated and conducted after successful completion of the Functional Performance Test and prior to shipping the ROCC software for installation and site testing. The Integrated System Test shall verify the stability of the ROCC software hardware and software.

The Integrated System Test shall demonstrate to the satisfaction of WMATA that the ROCC software is free of improper interactions between software and hardware while the ROCC software is operating as an integrated whole.

During the Integrated System Test, all ROCC software functions and all Contractor supplied equipment shall run concurrently and operate for a continuous 96-hour period. The Integrated System Test shall be considered to have failed, if any uncommanded functional restarts, processor failovers, or device failovers occur during the test. If the Integrated System Test fails, the test shall be extended or repeated, at no cost to WMATA, until the ROCC software passes the test.

8.2.5 Hardware and Function Simulation

The Contractor shall develop a comprehensive methodology for simulating ROCC software hardware, software and functionality, and WMATA interfaces and devices.

The simulation methodology to be implemented by the Contractor shall be defined in a Hardware and Function Simulation Methodology Plan (HFSMP), (CDRL T517) and delivered for Engineer approval initially at System Requirements Review (SRR) and then refined and updated for PDR and FDR:

a) The HFSMP shall provide definition of all test equipment and simulation equipment to be provided for ROCC software.

b) The HFSMP shall define how each simulation or test tool will used for each phase of testing. c) The HFSMP shall define the method to be used to verify and validate any simulation or test tools for

completeness and correctness against the actual component or data which it simulates. d) The HFSMP shall analyze and describe the effect of using simulation or test equipment to simulate

ROCC software components not connected during each test. e) The HFSMP shall define for each simulation and test tool:

• The hardware configuration and components; • The software configuration and components; • The database, data, file, and/or scenario configuration and components; • User interface capabilities for accessing, selecting, creating, modifying, deleting, and control of

scenarios and injected data to ROCC software; • Limitations on data, capability, performance, capacity, configuration, interface, and other

attributes of the tool; • Restrictions on usage; • Schedule for developing, implementing, and validating each simulator and test tool; • Training requirements for WMATA personnel involved in testing; • All other issues related to the development, delivery, and implementation of ROCC software

simulation and test tools.

The Contractor shall deliver as part of the ROCC software, all test equipment and all simulation hardware and software required to allow the ROCC software to be thoroughly tested. All simulation and test equipment

Page 178


hardware, software and documentation developed and/or used in the development and testing of the ROCC software shall be delivered to WMATA as part of the final system.

Simulators and test tools shall be developed and implemented independent of the ROCC software under test:

a) All simulation and test equipment that simulates the operation of the ROCC software or WMATA systems shall be verified and validated for correctness and completeness, to the satisfaction of WMATA, prior to use during testing.

b) Results of simulator and test tool verification and validation activities shall be Engineer approved prior to the initiation of any test phase in which the simulator or tools shall be used.

c) The Contractor shall utilize the processes and procedures defined under the approved ROCC software Software Quality Assurance Plan and ROCC software Software Verification and Validation Plan (CDRL T301.1) for verification and validation of the simulation and test equipment.

d) All simulators and test tools that perform, support, or interface with critical ROCC software functionality or field train control operation shall be qualified by the Contractors approved Signal Engineer at least 60 days prior to the start of factory tests.

Simulation equipment shall provide means to create, modify, select, and delete scenarios to be used during testing and other activities designated by WMATA. Simulation, emulation or substitution of any ROCC software function(s) shall not be permitted, i.e. the complete functionality of the ROCC software shall be concurrently demonstrated utilizing the actual software and to the maximum extent practical, the hardware configuration of the complete ROCC software. Simulation shall only be used to an extent necessary (as approved by WMATA) to provide for stimuli of devices external to the ROCC software.

8.3 Site Tests

Site testing shall be performed to verify that the ROCC software has been properly installed, and that the ROCC software satisfies all performance, availability, and functional requirements while communicating with a full complement of devices under actual service conditions.

Responsibility for the conduct of all site tests shall rest with the Contractor but be coordinated with and approved by WMATA. The Contractor shall schedule all testing involving any and all existing equipment at least 45 days in advance of the need for the equipment. All testing involving the control of field devices shall be performed during off-peak hours.

The Contractor shall permit WMATA’s representatives to witness all site tests. Contractor representatives knowledgeable in the design, operation and testing of the ROCC software shall be present at all times to assist in the testing and assist WMATA’s representatives with site testing, as needed.

Prior to site testing, the Contractor shall review all maintenance records and identify all hardware and software modified, repaired, or replaced between the completion of factory tests and the start of site testing and submit as ROCC software Pre-Site Test Maintenance Records (CDRL T602).

Interfaces to all communications circuits shall be established by the Contractor and the proper operation of these circuits shall be verified prior to the beginning of site testing. During the execution of site testing, the Contractor shall update all drawings and simulation software to incorporate discrepancies found during testing.

The site tests shall consist of three separate tests and the requirements for Test Plans, Test Procedures, Test Records, test initiation, test satisfaction, and test suspension shall apply separately for each of the following site tests:

a) Site Installation Test: • Site Installation Test Plan, CDRL T603.1; • Site Installation Test Procedures, CDRL T603.2; • Site Installation Test Results, CDRL T603.3;

b) Site Performance Test: • Site Performance Test Plan, CDRL T604.1; • Site Performance Test Procedures, CDRL T604.2;

Page 179


• Site Performance Test Results, CDRL T604.3; c) Site Integrated System Test:

• Site Integrated System Test Plan, CDRL T605.1; • Site Integrated System Test Procedures, CDRL T605.2; • Site Integrated System Test Results, CDRL T605.3.

8.3.1 Site Installation Test

The Site Installation Test shall be initiated and conducted after all ROCC software hardware and software has been installed and interconnected in the final ROCC software configuration and prior to the Site Performance Test.

The Site Installation Test shall demonstrate that all ROCC software hardware and software has been delivered and that all ROCC software hardware and software is properly installed.

The Site Installation Test shall include the testing of all cables for opens, shorts, grounds and high resistance:

a) At the completion of installation testing, the Contractor shall certify that all wire and cabling has been installed in accordance with the manufacturer’s recommendations; that no damage to wire cable occurred during installation; and that wire and cable has test values that meet or exceed the requirements for long term operation.

b) The Contractor shall replace in its entirety, and be retested, any cable(s) damaged during installation or failing to pass a test.

c) All cables that have been disturbed (including being moved from a secured position) during or after a test (on the cable, another cable, or a device) shall be completely retested.

The Site Installation Test shall include a complete system inspection including but not limited to proper installation, grounding, cabling, conformance to plans and drawings, neatness, equipment access and installed versions of hardware and software.

Random system operations including but not limited to device failover and change-out shall be conducted as directed by WMATA. The Contractor shall be responsible for the conduct of the Site Installation Test.

The Contractor shall permit WMATA’s representative to witness all site tests and to perform hands-on execution of the Test Procedures as selected by WMATA.

8.3.2 Site Performance Test

The Site Performance Test shall be initiated and conducted after successful completion of the Site Installation Test and prior to the site update period. The Site Performance Test shall include a complete validation and communication check for the full ROCC software database against the field system interfaces.

The Site Performance Test shall demonstrate that all ROCC software hardware and software, functions properly in the on-site environment. The Site Performance Test shall consist of running on-line and off-line diagnostics on the ROCC software equipment and conducting a subset of the factory Functional Performance Test.

The Site Performance Test shall verify the proper operation of all ROCC software functions as defined by the complete set of ROCC software requirements, operating in their final installed and connected environment:

a) Accurate real-time tracking of all trains throughout the entire ROCC software Monitored Territory shall be demonstrated during the Site Performance Test.

b) The Site Performance Test shall verify the proper operation of all manual and automatic routing functions throughout the entire ROCC software Monitored Territory.

c) The Site Performance Test shall verify the proper operation of all ROCC software commands when controlling the actual field devices.

d) The Site Performance Test shall demonstrate accurate system timing using the Master Clock time and frequency.

Page 180


e) Proper operation of all alarm processing shall be tested during the Site Performance Test. f) Proper operation of the service monitoring and control and report generation functions shall be tested

during the Site Performance Test. g) The Site Performance Test shall demonstrate system loading and response times with all ROCC

software functions, users, and equipment on-line and operating. h) The Site Performance Test shall verify the proper operation of all Information Storage & Retrieval

(IS&R) functions, playback, and simulation.

The Site Performance Test shall also include tests for ROCC software functions and features, including failover and all related functions, which could not be tested during the factory tests. All ROCC software functions tested during the factory testing including those affected by corrections and changes since the factory testing shall be tested during the Site Performance Test. ROCC software functions that utilized simulation facilities or were only partially tested during the factory performance test shall be tested during the Site Performance Test.

The Site Performance Test shall include testing of the proper operation of all data communication channels including communication with:

a) All FCU’s; b) All external systems; c) All remote ROCC software Workstations.

The Site Performance Test shall include a complete point-to-point test of the entire data-set/database of the code system that includes an end-to-end (ROCC software user workstation to FCU input/output) verification of the proper operation of each data point.

The Contractor shall fully test and demonstrate “shadow” operation to ensure the ability to successfully transfer from ROCC software control to non-ROCC software control:

a) During “shadow” operation it shall be verified that all indications are received correctly and monitored for every location.

b) During “shadow” operation it shall be verified that no controls are sent to any field equipment.

8.3.3 Site Update Period

The Contractor shall provide for a site update period to enable WMATA to monitor and verify the performance of non-ROCC software systems and their interfaces to the ROCC software. The site update period shall be scheduled after the Site Installation and Performance Tests and before the Site Integrated System Test.

During this period, the Contractor shall provide assistance as requested by WMATA on an “as-needed” basis. The Contractor shall be responsible for providing and installing corrections for all ROCC software variances found during this period prior to the start of the Site Integrated System Test. The Site Update Period shall be performed per the approved test schedule.

8.3.4 Site Integrated System Test

After the Site Update Period and the correction and resolution of all variances, the Site Integrated System Test shall be initiated and conducted. The Site Integrated System Test shall test the entire ROCC software operating as a fully integrated system under simulated peak and maximum loading conditions, as well as monitoring of “live” operations.

The proper operation and performance of all ROCC software features and functions shall be verified during this Site Integrated System Test. The Site Integrated System Test shall demonstrate that the ROCC software meets all specified spare utilization, spare capacity, and timing requirements under off-peak and peak load conditions while monitoring and controlling the entire WMATA Territory. The Contractor shall execute test threads through the ROCC software during the Site Integrated System Test. Test Threads shall be tested by executing Test Scenarios as approved by WMATA.

All WMATA performance scenarios shall be demonstrated during the Site Integrated System Test:

Page 181


a) Off-peak load and peak load testing in the field shall be performed after all ROCC software equipment and interfaces to external systems have been connected.

b) Off-peak and peak load tests conducted in the field shall be conducted under both simulated and actual operating conditions.

c) Full system peak period operation and loading shall be tested, implementing at a minimum, a full schedule of trains, all routes, and all operations.

At the successful completion of this test as determined by WMATA, the ROCC software shall be ready to be placed in revenue service.

8.4 Startup and Failover

The ability of the ROCC software to provide all required functions under all conditions is of paramount importance to WMATA. Of greatest concern is the ability of the new ROCC software to execute all critical functions without exception in the manner specified in this Specification to meet the required reliability, maintainability, and availability goals of WMATA.

Proposal Requirement: The Proposer shall provide in his technical proposal detailed information about the Cutover Process and Schedule for the software.

All ROCC software functions shall be classified as ‘critical functions’ with the exception of the following functions classified as ‘non-critical’:

a) General File Transfer; b) Interface to Video Display Walls c) Report Generation; d) Display Development; e) Report Development; f) Data Playback; g) Simulation; h) Software Utilities; i) Online Applications; j) Printing; k) Training functions.

Where the criticality of a specific function cannot be determined from the definition as specified, those functions shall be considered ‘critical functions’, subject to the discretion of WMATA.

8.4.1 Processor Groups

The requirements for processor groups, as defined herein, apply to ROCC software. For example, one processor group may be configured to perform all train control system monitoring and control functions, while another processor group performs train control system reporting and historical storage and retrieval functions.

A processor group shall be defined as one or more processors that perform a subset of System tasks in either a primary/secondary (hot-standby) manner or distributed manner (where the on-line functions performed by the processor group are distributed among multiple primary processors). This Specification presumes the use of local area networks provided by WMATA for all processor interconnections.

Processor groups may be configured as redundant or as non-redundant. Redundant processor groups are to be used to implement all functions and databases with the exception that workstations and the processors performing playback, simulation, training, and development functions may be implemented in non-redundant processors.

Within the ROCC software configuration, redundant interconnections shall be provided among all processors within a processor group, among all processor groups, among all processor groups and all consoles located in the CTF, and among all processor groups and all consoles located with the JGB.

Page 182


When restart and failover operations take place the processor and device states shall identify the operating condition of each processor and peripheral device in the ROCC software and shall be used to determine the system’s reaction. Processor and device states shall be assigned automatically by the function restart, processor and device failover functions, and manually by user command.

An Authorized ROCC software User, utilizing the System Configuration Monitoring Displays, shall have the capability to initiate a manual switchover (i.e., failover) from the primary processor or device (in a redundant group) to the standby. Switchover may be used to facilitate periodic off line maintenance and disaster recovery practice drills.

Each processor in the ROCC software shall be assigned to one of the following states: Primary, Secondary (also referred to as Hot-Standby), or Off-line (also referred to as Down). Primary processor(s) shall perform maintenance functions at the discretion of the System Administrator. Capability shall be provided for maintenance functions to be performed concurrently with the execution of all assigned on-line functions and shall not degrade or adversely impact the performance of the critical functions.

Secondary processors shall perform the following:

a) All on-line functions assigned to the associated primary processor; b) Inhibit/block control functions with devices c) Inhibit/block user interaction (input/output) other than maintenance, diagnostic, and Systems

Administrator functions; d) Monitor the status of all data communication channels and monitored devices e) Communicate with the primary processor(s) to maintain fully synchronized backup databases,

operating data, and to monitor the state of the primary processor(s).

A secondary processor shall assume operational control of the functions implemented by a primary processor in the event of primary processor failure or upon user command to transfer control without loss or degradation of operation.

When more than one secondary processor is online in a processor group, a secondary processor in the ROCC software shall take precedence over a processor at JGB for assuming control, should the primary processor fail or upon user command to transfer primary control.

8.4.2 Devices Controlled by Processors

The term “devices” includes, but is not limited to equipment that are not general purpose computing equipment such as printers, data storage arrays, data comm. equipment, field equipment and user interface equipment:

a) Each device in the ROCC software shall be assigned one of the following states: Primary, Secondary, Dependent or Down.

b) If a primary processor fails and its functions are reassigned to a backup process in the failed processor group or another primary processor, the logical attachment of the primary device(s) shall follow the reassigned functions.

c) A device shall be able to be assigned to the secondary state by the restart function of a processor or by action of the System Administrator.

Device(s) assigned the dependent state, also referred to as dependent devices, shall be logically attached to a designated processor and the state of the processor shall affect the state of the device. All devices associated with a processor group, excluding processor terminals, auxiliary memory, and optical disks operating in the dependent state, shall be accessible by any processor within the group without communicating through another processor.

There shall be no restrictions on the assignment of workstations, System Administrator terminals, field control units (FCU), external device interfaces, or printers among processors. The state of each processor connection to a LAN and the LAN itself shall be changeable by the user.

The LAN interconnections shall support:

Page 183


a) The exchange of data for the purpose of executing on-line and maintenance functions and maintaining backup databases;

b) Access to peripheral devices and the connection of processor terminals to processors.

8.4.3 Error Detection and Failure Determination

All processors, devices, and on-line and maintenance functions in the ROCC software shall be monitored for fatal and recoverable errors. All fatal and recoverable errors of all locally and remotely located peripheral devices and interfaces to other WMATA systems shall be detected and recorded by the ROCC software and handled by:

a) Recoverable device and interface errors shall be retried. b) Each type of recoverable error (e.g., recoverable processor error) shall be assigned a threshold number

of retries allowed within a specified time period by the System Administrator. When the count of consecutive recoverable errors exceeds this threshold (e.g. retries within the specified time period), a fatal error shall be declared.

c) A fatal device or interface error shall result in the declaration of a device failure. d) Device and system interface failures shall be detected and alarmed. e) Fatal software errors shall result either in termination of the function or shall be handled as a fatal

processor error. f) User Advisory messages shall be presented to the System Administrator for all device, processor, and

system interface recoverable errors. g) All errors shall be recorded on the ROCC software and logged for review by maintenance personnel.

Failure analysis programs shall be provided on the ROCC software to produce operating system and application program failure analysis information for analyzing the cause of fatal and non-fatal program failures.

Failure analysis information shall include the following items:

a) Time and date of failure; b) The most recent operating system service routine requested; c) The pending, executing, and completed programs; d) I/O activity per system device at time of failure; e) The current system resource allocation; f) Contents of pertinent system software tables; g) Contents of hardware registers; h) Contents of mapping tables; i) The contents of main memory; j) Paging parameters and tables.

8.4.4 Data Integrity

Backup copies of all databases shall be maintained so that operation of the ROCC software will continue in the event of processor, device, or software failure.

The backup databases shall be continuously updated with the current contents of the primary databases such that all changes to a primary database are reflected in all backup databases.

Failure of a processor shall not preclude access to a backup database by the processor assuming the functions of the failed processor:

a) The backup databases shall be maintained in such a manner as to be protected from corruption due to processor and device failure.

b) Backup databases shall be preserved during system input power disruptions of any duration.

Page 184


8.4.5 Processor Redundancy

Except as noted below, each processor group shall be redundant and include at least one on-line processor operating as the primary processor and at least one on-line processor operating in hot standby as a secondary processor.

Redundant processor groups shall be used to implement the ROCC software functions and databases with the exception that the following functions may be implemented with non-redundant processor groups:

a) Simulation; b) Playback; c) General file transfer capability; d) Display Development; e) Database Development; f) Report development software; g) Software utilities; h) Training functions.

When a failure of a primary processor in a redundant processor group is detected, the ROCC software shall invoke the appropriate failover and restart actions so that on-line functions assigned to the failed processor are preserved.

When a failure of a primary processor in a non-redundant group is detected, the ROCC software shall not invoke failover or restart actions. Functions assigned to a failed processor in a non-redundant group may be lost until the failed processor is restored to service.

All processor failures and reinstatement actions shall be annunciated by alarms. The alarms shall identify the failed processor(s), all processor state changes, and the success or failure of any restart and failover operations. If fault-tolerant computers are used to satisfy the processor redundancy requirements, fault-tolerant computers shall be designed to be repairable without interrupting the ROCC software functions.

8.4.6 Device Redundancy

When a failure of a redundant device is declared, the ROCC software shall automatically invoke the appropriate failover actions so that on-line functions using the failed device are preserved. Device failover shall be invoked to recover from all redundant device failures except that processor failover may be used to recover from redundant device failures where allowed herein. When a failure of a non-redundant device is declared, the ROCC software shall not invoke processor or device failover or function restart actions.

Consoles, workstations, console base stations, keyboards, mice, speakers, microphones, wired headsets, wireless headsets and visual and audible alarm devices shall be configured as non-redundant devices. Console failover logic shall ensure that all of the areas of responsibility assigned to a failed console are assigned to at least one other console. If one or more areas are not assigned, the areas shall be assigned to a default console in the control room and an alarm shall be generated at that console. The interfaces with FCUs, FEPs, and RTUs shall be configured in a redundant configuration. Other interfaces need not be redundant.

8.4.7 Startup

Startup establishes the processor operating environment prior to restart of the ROCC software functions. Establishment of the operating environment may include execution of self diagnostics, reloading the operating system and system services, and connection to and verification of communications LANs.

Processor start-up shall be initiated when commanded by a user or when processor input power is interrupted for more than 100 milliseconds and then restored. Processor start-up shall establish the operating environment of the processor prior to restarting the on-line functions.

Page 185


Subsequent to processor start-up, a function restart shall bring the processor(s) to the appropriate processor state. Processor start-up shall be completed within five minutes of initiation and restoration of power to the processor and all devices needed to support processor operation.

8.4.8 Failover

This section includes requirements for processor and device failover.

8.4.8.1 Processor Failover

In the event of failure of any primary processor in a redundant processor group, the ROCC software shall initiate a failover operation, and the functions of the failed processor are assumed by a functioning processor in the group.

Immediately upon detection of a primary processor failure, the failed primary processor’s state shall be changed to down and all primary devices assigned to the failed primary processor shall be reassigned to the secondary or primary processor which shall assume the failed processor’s on-line functions.

All dependent devices assigned to the failed processor which can be accessed only through the failed processor shall be changed to the down state and other dependent devices manually assigned to the failed processor shall be released from the dependent state. The Contractor shall provide for the ROCC software, as part of the System Description Document (refer to Section 12.2, CDRL List), identification of processor failover criteria.

8.4.8.2 Device Failover

The device failover function shall direct an orderly transfer of operation in the event of any primary, redundant device failure. The assignment of specific secondary devices to replace failed primary devices shall be made by the System Administrator on-line.

The failover assignment scheme shall allow for multiple levels of failover. That is, if a primary device fails and its secondary device then fails or if the secondary device is failed at the time of failure of the primary device, the system shall attempt to use the secondary assigned to the secondary device. All functions associated with both failed devices shall then be directed to use the new device.

Device failover actions shall be completed and the secondary device shall be operating within fifteen seconds of detection of the device failure. If the ROCC software has failed, any FCU, FEP, remote I/O, other data source, or the data transmission channel connecting the ROCC software to the device(s) or data source, (including the modem/controller), data transmission with the device(s) or data source shall be retried at a periodicity specified by the System Administrator. This periodicity shall be different from the normal periodic scan rate of the FCU, FEP, remote I/O, or data link.

When reliable data transmission is reestablished, as determined by a System Administrator-adjustable number of consecutive, successful retries (initially three), the FCU, FEP, remote I/O, other data source, or data transmission channel shall be automatically returned to operation.

8.4.9 Restart

Function restart is the assignment of a function or functions to a secondary processor and the initiation of these functions. Function restart assumes processors and devices to be in an operational state consistent with the assignment and execution of the functions.

Function restart shall be invoked manually by a user and automatically to recover from hardware and software failures. Function restart shall proceed to completion without user intervention, except to obtain time and date information where the time facility is not operational or as noted below.

Secondary processor(s) of a redundant group shall be executing in a hot-standby mode, therefore all functions assigned to the processor group are at all times executing within each processor of the group. Any failover of a

Page 186


processor involved shall automatically implement a full recheck of all FCU indication data. FCU data recheck shall be to the actual FCUs, and not database, buffer, or file of FCU data.

Any non-critical on-line functions (Playback, Simulation, General File Transfer, Display Development, Report Development, Software Utilities, and Training) that may be executing in the restarting processor shall be suspended until all other on-line functions are restored.

Restart shall update all data and databases to be current. Databases may be updated from primary processor databases or, if necessary, from backup databases or from static, initialization database copies stored on auxiliary memory depending on the nature of the restart.

8.5 Reliability, Availability, and Maintainability

This section identifies the reliability, availability and maintainability requirements and objectives for the OCC Control Software. The RAM requirements are applicable to all software and hardware. Prior to designing the ROCC software, the Contractor shall engage in a review of existing WMATA operations and the RAM implications thereof to produce a Pre-design RAMS Report:

a) The Pre-design RAMS Report shall identify any and all single points of failure within the existing WMATA operations environment.

b) The Contractor shall provide a Pre-design RAMS Report of the existing control centers that will impact the RAMS of the ROCC software once that it is installed.

c) The Contractor shall subsequently provide the Pre-design RAMS Report to WMATA to be reviewed by the various WMATA departments who actively maintain the implicated equipment.

All reliability, availability, and maintainability calculations, verifications, and demonstrations shall be performed for the ROCC software’s Software and Hardware:

a) The Contractor shall supply all necessary software to support the RAM requirements stated herein. b) The Contractor shall specify all necessary hardware for inclusion on the Hardware Specifications to

support the RAM requirements stated herein.

From the set of all functions (which include hardware and software), a set of critical functions is defined, see Section 6.2. The System availability defined for the ROCC software is based on the system performing all critical functions without loss, failure, or degradation. The device availability is based on the devices performing (all functions) as intended without loss, failure, and degradation. Both availability factors are based on reliability however and System availability is defined on a subset of the whole at a functional level; with redundancy there is a reduction in system reliability due to more equipment but there is an increase in System Availability since under failures requiring repair, the ROCC software shall continue to function.

The ROCC software shall provide all critical and non-critical functions, including functions necessary to support the continuous operation as defined in this Specification. Mean Time Between Failure (MTBF) for components, subsystem, and systems shall be calculated in general conformance to applicable Sections of military handbook MIL-HDBK-217, latest revision:

a) The Contractor shall perform predictions of the reliability of all software components beginning with the allocation of the system reliability objectives to the software architecture, evaluation of the software architecture at the lowest design level, fault estimation and identification during implementation, and reliability estimation/forecast during all stages of test.

b) Software reliability prediction and estimation methodologies shall be defined in the Reliability, Availability, and Maintainability Program Plan.

The Contractor shall design the ROCC software to meet or exceed all availability and maintainability requirements without exception. The Contractor shall define the ROCC software configurations in the form of block diagrams to be used as the basis of the reliability, availability, and maintainability analyses. This shall include the following block diagrams:

a) Complete System Availability Block Diagram, b) Complete System Reliability Block Diagram.

Page 187


Availability and maintainability requirements shall be maintained during any system modifications, upgrades, or maintenance functions. The Contractor shall perform all reliability, availability, and maintainability analyses utilizing a COTS analysis tool such as Relex® Analytical Tools. The COTS analysis tool chosen by the Contractor shall be subject to the review and approval of WMATA. The Contractor shall identify the system assurance tools to be used, in the Reliability, Availability, and Maintainability Program Plan.

The System Configuration shall have a total system availability, including critical function availability (Section 6.3.1) and hardware availability (Section 6.3.2), of not less than 99.999%. That is, the ratio of total time (262,800 minutes) minus downtime, to total time shall be equal to or greater than 0.99999.

Each System shall be designed so that the failure of any single component (software or hardware), processor, or device shall not render the system unavailable or a critical function non-operative.

The MTTR for the complete ROCC software shall meet a maximum MTTR of 0.5 hours. The MTTRs are to be demonstrated at the consumer’s risk of 10 percent (10%). The MTTR value shall be met or improved upon through design and analysis.

8.5.1 Functional Availability

All ROCC software critical functions and functions necessary to support critical functions of the ROCC software (inclusive of all software and data supporting those functions) without exception, shall execute as specified and without degradation in response times for the system to be considered available as a Critical System. All ROCC software functions of the ROCC software that are not critical or are not necessary to support critical functions without exception, shall execute as specified and shall not degrade or adversely affect the performance or response times of the critical functions or functions necessary to support critical functions for the system to be considered available as a Critical System.

All ROCC software functions without exception (inclusive of all software and data supporting those functions), shall execute as specified and without degradation in response times for the system to be considered a fully functional. When a backup processor is not available, the functions normally performed on a backup processor shall be available on a primary processor for the system to be considered available (either fully functional or for critical functions only).

Response times for functions that normally are performed on a backup processor may be proposed to be degraded when these functions are operating on a primary processor as a result of a backup processor being unavailable. Proposed degraded response times shall be subject to the approval of WMATA.

8.5.2 Hardware Availability

This section defines the minimum complement of hardware that must be operational for the ROCC software to be considered available. This hardware availability definition may be modified by WMATA to reflect the specific configuration as approved by WMATA, including any options purchased.

The following minimum complement of hardware shall be operational for the System Configuration to be considered available:

a) All application and data processors, with all main memory and processor terminals, processor interconnections, auxiliary memory, and storage devices to execute the ROCC software functions at the scheduled periods/cycle times and response;

b) All system printers within the CTF, Computer Room Area, and JGB Area; c) All of the workstations in the CTF, JGB, installed in non-Operating Theater areas of the Control

Center, and at all remote locations outside the Control Centers; d) All application and data processors, with all main memory and processor terminals, processor

interconnections, auxiliary memory, and storage devices to execute the ROCC software Reporting and external data functions;

Page 188


Workstations shall be considered available when the workstation processor, keyboard, mouse, and all monitors are available.

8.5.3 Individual Device Availability

In addition to meeting the system hardware availability requirements, each device, including processors, shall individually exhibit a minimum availability of 99.9%. Individual device availability shall be calculated as the ratio of time available to total time multiplied by one hundred (100).

8.5.4 Availability Analysis

The Contractor shall prepare and furnish an Availability Analysis (CDRL T607) of the ROCC software. The Availability Analysis shall be based on a corresponding availability block diagram and shall state the Mean-Time-Between-Failures (MTBF) and the Mean-Time-To-Restore (MTTR) of all System components.

The Availability Analysis shall describe in detail the historical, statistical, and experimental basis for each analysis. All assumptions, such as level of training of maintenance personnel, availability of spare parts, maintenance response time, and preventative maintenance for each device, shall be described for each Availability Analysis.

The Availability Analysis shall be refined and updated during each development phase and submitted for Engineer approval prior to CDR, SRR, PDR, FDR, IR, and TRR. The Availability Analysis provided at CDR shall be the initial submission, allocating availability requirements to ROCC software conceptual components. The final Availability Analysis of all Systems shall be completed a minimum of six weeks prior to the start of Transition Phase.

8.5.5 Reliability, Availability, and Maintainability Program Plan

The Contractor shall establish and maintain an Engineer approved Reliability, Availability, and Maintainability Program Plan (CDRL T608) that is planned and developed in support of the specified reliability, availability, and maintainability requirements and objectives in general accordance with applicable provisions of the latest version of military standard MIL-STD-785.

The Reliability, Availability, and Maintainability Program Plan (RAMPP) shall be delivered and updated for Conceptual Design Review, Preliminary Design Review, and Final Design Review. The RAMPP shall define the reliability, availability, and maintainability program standards and objectives.

The RAMPP shall define the methodology the Contractor will use to verify that the Systems meet or exceeds the availability and reliability objectives for the system, function (both full functionality and critical functionality), hardware, software, and individual device availability The WMATA preferred methodology is for a fixed duration demonstration test. The RAMPP shall define the organization and the personnel responsible for managing the reliability and maintainability program.

The RAMPP shall include the name of the individual assigned by the Contractor, responsible for the management and administration of the Reliability, Availability, and Maintainability Program. The RAMPP shall be updated and resubmitted at the time of Contractor reassignment of the individual responsible for the management and administration of the Reliability, Availability, and Maintainability Program.

The RAMPP shall define the techniques for allocation of quantitative requirements to lower level functional elements of a subsystem and to the piece part level. The RAMPP shall contain provisions for source selection, first article inspection, and surveillance of subcontractor’s reliability and maintainability activities.

The RAMPP shall define procedures and controls, including piece part selection and screening, manufacturing process controls, procurement controls, and test procedures, to be utilized during production to assure achievement of reliability and maintainability requirements.

Page 189


The RAMPP shall define procedures to determine the efficacy of built-in diagnostic functionality in the ROCC software design, including both hardware and software. The RAMPP shall define procedures for estimating the projected reliability growth to be achieved during ROCC software development.

The RAMPP shall define a failure reporting system to assure that problems are detected, investigated, and that effective timely corrective actions are taken to reduce or prevent repetition of the failures.

a) The failure reporting system shall include a closed loop data collection system for collection, analyzing, and recording all failures that occur during in-plant tests and those that occur during on-site testing prior to acceptance.

b) The analysis and recording of failures shall differentiate between those due to design or workmanship and those due to other causes such as errors in handling, transporting, storing, and operating the ROCC software.

c) Failure reporting system forms shall be contained in the RAMPP and shall be approved by WMATA.

8.5.6 Reliability Calculations

The Contractor shall perform and provide to WMATA detailed Reliability Calculations (CDRL T609) and allocations to substantiate the design of the ROCC software software and equipment configuration. Once approved by WMATA the predicted reliability will become the minimum reliability objective for each System.

The Reliability Calculations shall be provided for approval as an initial version prior to Conceptual Design Review, updated for SRR, PDR, FDR, TRR, completion of FAT, and as a final version 6 weeks prior to the start of Cutover. The Contractor shall obtain Engineer’s approval of the Reliability Calculations prior to release of the design for implementation.

The Reliability Calculations shall include component failure rates (or MTBF) assumed in each calculation and the basis of the figure used. The Reliability Calculations shall calculate the reliability growth of the ROCC software to ensure that the ROCC software reliability objectives will be met.

8.5.7 On-going RAM Monitoring

After the ROCC software is commissioned and running as a component of normal WMATA business operations, RAM shall still be monitored through a variety of tools to be supplied by the Contractor. The ROCC software shall provide functions for Authorized Users to ascertain the current and historical RAM status.

An Availability Report shall be provided for execution by Authorized Users on ROCC Workstations:

a) The Availability Report shall display an overall availability number that represents current and historical availability statistics.

b) The Availability Report shall display separate current and historical availability statistics for various key ROCC software components.

Page 190


9. Operations and Maintenance

9.1 OCC Control Prototyping

The Contractor shall undertake extensive system behavioral prototyping of the ROCC software, working closely with WMATA. The prototyping activities will facilitate interaction between the Contractor and WMATA’s operations and engineering personnel to define detailed system behavioral and functional requirements of the ROCC software, and allow WMATA to review and comment on the design of all displays, user interactions, and functions early in the software and functions development cycle, prior to implementation.

It is not the intention that prototype development result in implementation of the actual software product. The Contractor will utilize tools in the development of the prototype systems that allow emulation of the behavior of the user interface and functionality but that does not necessarily rely on actual software and databases. Prototype software development will be independent from the software development with the exception that prototype review results will be incorporated into the design.

The Prototyping System, all prototypes, supporting documentation, and methodology for recording Engineer comments, disposing comments and incorporating the comments into successive iterations of the prototypes, as well as the design, shall be subject to approval of WMATA.

9.1.1 Prototyping System

The Contractor shall furnish, support, and maintain at WMATA facilities designated by WMATA, a Prototyping System, including Authorized User interface workstations. The Contractor shall identify workstation and printer quantities and locations as part of the Hardware Specifications:

The Prototyping System shall support concurrent user sessions of all Prototyping System workstations and be located in space provided by WMATA in the CTF.

9.1.1.1 Prototype Model

The Prototyping System will be based on a specific model that represents WMATA’s existing system look and feel and will provide interactive end to end operation, incorporating all existing control functions, and configured to account for all of the variations encountered in WMATA’s system. It is expected that the prototype model will encompass the entire Train and Traction Power Control Systems.

The Contractor shall develop a model of the ROCC software for prototyping. The Contractor shall define the complete prototype model of the WMATA system as part of the Prototype Plan.

The prototype model/Plan shall:

a) Represent the entire actual WMATA system, modified to reduce redundant types of track configuration, operation, and functionality in the model, subject to the approval of WMATA.

b) Represent the ability to operate trains from one end of the modeled system to the other end, into and out of yards, storage tracks, stations, terminals, the various Lines (territories) and other specific system configurations, using the operating rules and functional capabilities defined under this Specification.

c) Include detailed drawings of the system represented by the prototype model, lists of all routes through the modeled system, definition of any extrapolations of non-WMATA system included in the model and the purpose to the overall integrity of the model, and assumptions made to the completeness of the model.

d) Define the locations and area of the WMATA System represented in the prototype model that will be prototyped. Where specific areas of the WMATA System are not to be included in the display prototype, the Contractor shall provide a detailed justification for not including the specific location.

As a minimum the prototype model shall incorporate the following WMATA System:

a) Overall Display for the Video Display Wall; b) Area Displays for the Workstations.

Page 191


9.1.2 Prototyping Activities

The Contractor shall perform and document all prototyping activities as defined in WMATA approved Prototype Plan. All administration, maintenance, operation, and configuration of the Prototyping System and prototype software as defined in WMATA approved Prototype Plan. Prototypes shall be developed and modified on the Prototyping System furnished, installed and maintained by the Contractor at WMATA facilities.

Iterations and modifications to the prototypes after the initial or first iteration shall be made by Contractor personnel where the Prototyping System is installed on Contractor’s workstation(s) separate and distinct from the workstations for WMATA’s use. The Contractor is responsible for additional workstations and/or equipment interfaced to the Prototyping System necessary for Contractor personnel access, modification, and administration of the Prototyping System. This equipment is not considered part of the Prototyping System as defined in this Specification.

All configuration control of the prototype shall be maintained at the site where the modifications and iterations are generated, with the exception of the initial or first iteration.

The Prototyping System shall be fully functional within 6 months of Notice To Proceed (NTP), including all hardware (provided by WMATA), communications, and software necessary to support all prototype development, review, evaluation, and management activities defined in this Specification. This includes all hardware and software tools, applications, and commercial products necessary to perform all prototype development, modification, administration, maintenance, operation, review, and evaluation activities defined in this Specification. All prototyping activities inclusive of final prototype iteration comment resolution shall be completed and approved prior to Final Design Review.

The Contractor shall provide full time engineers at WMATA’s facility throughout the prototyping activities, assigned to the prototyping effort only, as determined by the Contractor and Engineer. Contractor’s on-site personnel responsibilities shall consist of:

a) Developing and modifying all prototypes; b) Maintaining the Prototyping System; c) Implementing the configuration management of the Prototyping System and all prototypes; d) Providing technical support to WMATA and WMATA prototype evaluators; e) Supporting Engineer reviewers by responding to questions or making adjustments or modifications to

the prototype; f) Training WMATA and WMATA’s personnel in the operation of the Prototyping System and

modification of the prototypes.

9.1.2.1 Prototype Elements and Functions

Rapid prototyping techniques will be utilized similar to those described under ASTM Standard, E1340-96 Standard Guide for Rapid Prototyping of Computerized Systems. Rapid prototyping techniques utilized will include static, dynamic and robust prototypes. All prototypes will be based on the prototype model system and operation approved under the Prototype Plan.

For the ROCC software, two types of prototypes shall be developed:

a) Static/dynamic (S/D), and b) Interactive/functional (I/F).

Each static/dynamic prototype shall be fully documented in the Display and Report Prototype Description Document.

Static/dynamic prototypes shall include, but not be limited to static images of all graphical and tabular displays, reports, menus, and dialogs. Static/dynamic prototypes shall include for each display, report, menu, and dialog, default positioning and sizing when opened, viewed, or selected on a workstation.

Page 192


The S/D prototypes shall be dynamic to the extent of invoking all displays and the action of all controls of a display, dialog, or menu.

a) S/D prototypes shall be populated with data representative of the actual ROCC software and WMATA operational data.

b) The prototype graphical and tabular displays shall include a representative sample (as defined in the approved Prototype Plan) of active display and function selection graphical symbols to allow WMATA to accurately assess the user interface interactions of the displays. For example, a representative set of entrance and exit graphical symbols for a representative set of interlockings.

c) Prototypes shall be designed for all Video Display Wall and all workstation displays and reports as defined by WMATA approved prototype model.

d) As part of the Static/dynamic prototypes all alarm, advisory, and event messages shall be developed and documented.

Interactive/functional prototypes shall consist of prototypes of functionality that exhibit the behavior of the functions, including responding to user inputs and executing algorithms of functions.

a) Interactive/functional prototypes shall be developed and provided, encompassing all functionality. b) Interactive/functional prototypes shall be capable of simultaneous, multiple train operation throughout

the prototype model area representative of actual operation and load, including operation through the entire system, into and out of yards, storage and pocket tracks, stations, terminals, and all other WMATA configurations.

c) Interactive/functional prototypes shall represent train operation without the need for user intervention not functionally necessary for train operation as defined in this Specification. The need for the prototype user to start or stop, invoke train moves not consistent with real world and WMATA train operation, or the need to utilize multiple different prototype sessions in order to continuously move trains from one area of the system to another via an established route is not acceptable.

Each interactive/functional prototype shall be fully documented in the Function Prototype Description Document.

All prototypes shall reflect the actual WMATA operation, and Engineer approved prototype model. Limited use of samples from non-Train Control projects may be acceptable to WMATA, but shall be subject to approval of WMATA.

9.1.2.2 Prototype Program

The Contractor shall develop a prototype program that meets the Specification requirements and shall define procedures for developing, modifying and tracking prototypes and WMATA comments to prototypes delivered for Engineer approval.

A minimum of three formal iterations of each prototype element and function shall be developed by the Contractor, an initial submission and at least two submissions revised in accordance with WMATA’s direction.

a) The initial submission of a prototype shall not be considered an iteration until approved as such by WMATA.

b) The Engineer will not consider a prototype element or function as an initial iteration until it exhibits its full planned capability.

c) The initial iteration of the prototypes must completely incorporate and exercise WMATA approved prototype model.

d) Prototypes provided for specific displays, reports, or functions that exhibit less than full/final capability (such as updates provided by the Contractor subsequent to a formal iteration to address specific Engineer comments or a prototype with less than complete detail provided prior to the initial iteration) shall be complete for the elements or functions for which it relates and shall be considered an interim prototype. Any review of a prototype prior to its full planned capability shall be considered interim. Under no circumstances will an interim prototype be accepted as a formal iteration and under no circumstances will Engineer comments to an interim prototype constitute or replace formal iteration comments.

Page 193


The Contractor shall perform and document all prototyping activities as defined in WMATA approved Prototype Plan.

9.1.2.3 Prototype Process

The prototyping process will be defined in WMATA approved Prototype Plan.

The Contractor shall be responsible for complete disposition of WMATA comments in the prototypes, including update to all project documentation affected by the change. As well as update the Functional Requirements Definition (FRD) (CDRL T105) for all requirements that are derived from the agreements and understandings reached between the Contractor and Engineer as part of the prototyping process. All prototype derived requirements shall be updated to the FRD at the time agreements are reached and shall be marked as ‘supplemental’. All submittals affected by agreements and understandings reached during the prototyping process, all affected documents, shall be updated and submit for Engineer approval as part of the prototype iteration it relates.

Following completion of all prototype iterations and approval by WMATA, all prototype documentation shall be updated to a complete and final state. All Engineer prototype comments shall be addressed and provided for Engineer approval, prior to submission of a new prototype iteration. Prototype iteration will not be accepted as complete and a new iteration considered until all Engineer comments are addressed to the satisfaction of WMATA.

Upon delivery of a new prototype iteration, the Contractor shall make a presentation to WMATA. The presentation shall describe the changes in the prototype since the last iteration, instructions on the use of new functionality, and an overview of the goals and objectives of the new prototypes.

Prior to the first prototype iteration, interim prototypes shall be built-up from simple aspects to aspects that are more complex. Initial elements shall include object shapes and states, colors, element highlighting, display layouts by type, and standard user interaction techniques. The first prototype iteration (inclusive of all static/dynamic prototypes and interactive/functional prototypes) shall be submitted prior to System Requirements Review (SRR). Engineer approval of the first prototype iteration will be required for acceptance of SRR.

All prototype elements and functions shall be based on the specified human factors standards of this Specification, as well as Display Conventions and Guidelines.

9.1.3 Prototype Configuration Management

The Contractor shall implement strict Configuration Management (CM) of the Prototyping System configuration, software, and prototype iterations. All aspects of the prototype CM, tools used, elements under CM, version identification, controls, version audit capability, etc. shall be described in the Prototype Plan and shall be subject to approval of WMATA.

Each prototype display and function shall be uniquely identified in its initial release. Once the identification of a prototype display or function is accepted, the identification shall not be changed without approval of WMATA. The version of the prototype shall be visible on each prototype display, report, and dialog.

9.1.4 Prototype Tracking and Documentation

The Contractor shall fully document the prototypes during all stages of prototype activities, and shall record and track all Engineer comments and comment dispositions.

9.1.4.1 Prototype Comments Tracking Tool

The Contractor shall develop and maintain a Prototype Comments Tracking Tool to record and respond to all Engineer comments on the prototypes. The Tracking Tools shall utilize a commercial database (COTS software) application that meets the requirements for the tool and is compatible with the Prototyping System

Page 194


hardware and software. The COTS software to be used to implement the Prototype Comments Tracking Tools shall be identified in the Prototype Plan for Engineer approval.

The Contractor shall provide copies of the Prototype Comments Tracking Tool comment status and resolution with each prototype release (including interim releases), as part of the Prototype Version Description Document, addressing Engineer comments from prior prototype release, as well as upon request by WMATA. Comment status and resolution shall not be required for the initial prototype release.

The Prototype Comments Tracking Tool shall minimally provide a database that documents for each Engineer comment:

a) Identification of the prototype item being reviewed; b) Identification of the reviewer(s); c) Version of the prototype; d) Unique comment numbering; e) Fields for reviewer comment collection; f) Date and time of the comment(s); g) Contractor disposition of the comment(s); h) Date and time of the disposition; i) Final resolution; j) Date and time comment resolved; k) Reference to requirements in the Functional Requirements Definition (FRD) (CDRL T105) directly

related to the comment or disposition; l) Reference to all project documentation directly impacted by or related to the comment or disposition; m) Other relevant information defined in the approved prototype plan; n) Other relevant information, as directed by WMATA during the prototype process necessary to

understand and approve the prototype.

The Prototype Comments Tracking Tool shall have a read-only, querying capability to generate reports as directed by WMATA. Input forms shall be provided that are simple to use and provide help to the user in identifying the prototype element and supporting material including, but not limited to, the contract requirement(s) the prototype element addresses.

Authorized Prototyping System Users shall be able to input all comments on a display and functions basis within the Prototype Comments Tracking Tool using input forms approved as part of the Prototype Plan.

9.2 Performance/Response Times

The following sections specify the performance required of the user interface. Averaged or other statistically processed response and update times are not acceptable as a measure of performance.

9.2.1 General Performance/Response Time Criteria

Remote workstation response times shall only differ from those specified, by the WMATA data communications network delay time from the Control Centers to the offsite remote workstation. Remote workstations are additional workstations placed outside the core network and have additional communications or network layers between the workstation and the ROCC software network switches.

Real-time data values shown on two or more display devices shall be updated on all displays simultaneously and within the response times required by this Specification. For example, in the absence of user interaction which would occupy the resources at a particular workstation, track circuit occupancy shall appear simultaneously on all display locations (Video Display System and all workstations) where the track segment depicting that track circuit is displayed. In all cases, however, display updates shall occur within the time frames presented in this section.

Satisfactory response time to all user requests and other performance requirements described in this Specification shall be demonstrated during factory and field testing under simulated peak and maximum loading conditions. The Contractor shall prepare and submit for approval a System Response Timing Analysis, (CDRL

Page 195


T622), which fully and completely analyzes and describes the system response to numerous operating conditions and user activities. The System Response Timing Analysis shall be submitted for Engineer approval prior to SRR and updated and refined at all technical reviews, and finalized within twenty days of the successful completion of Site Testing.

Successive updates of the System Response Timing Analysis shall reflect improved characterization of the system and its timing response as a result of information developed through the design process. For example, general estimates of server and workstation performance in initial versions of this document will be replaced with specific characterizations of the deliverable hardware and software components as the design proceeds. Furthermore, the detail to which these components are characterized in the timing analysis shall be consistent with the detail to which they are developed in the design documentation.

9.2.2 Control and Indication Transmission Response Time

The total time from initiation of a control action actuation by an Authorized User at an OCC Control Workstation or automatic function, to energization of the Field Control Units (FCU) output in the field shall not exceed 1 second (1000ms) under peak and maximum loading conditions. Under normal conditions, the total control time allocation for OCC Control Workstation to FCU output shall be consistent with the following breakdown:

a) Workstation and Video Display System user interface device stimulus (i.e., displays, keyboard, mouse, etc.): 200ms;

b) Central Primary and Backup system processing: 400 ms; c) WMATA’s Communications Backbone1: 200 ms; d) FCU energization2: 200 ms.

1 WMATA is responsible to furnish backbone services meeting the indicated time frames. Times will be measured from the time that the WMATA backbone receives data to the time that the WMATA backbone transmits the same data to the next element in the communication links. Communication protocol times to establish data transmission will be part of the Contractor’s time allocation.

2 Processing time will be measured from the time an input/output changes state until data transmission to/from the FCU is initiated, not including time for transmission protocol to establish communications. Communication protocol times to establish data transmission will be part of the Contractor’s time allocation.

Total times for control and indication transmission times to/from FCUs in this Specification shall not be exceeded.

9.2.3 External System Interface Transmission Response Times

The ROCC software shall process (under peak and maximum loading conditions), all indications from external systems (inclusive of all protocol overhead) and process and display such data within 2 seconds. That is, at any and all times, the maximum time from the time any and all data is received by the ROCC software, to the time any such data is displayed on any and all displays, the data is logged, database values are changed, and any and all other initial/primary responses/processes and/or values affected by the data are updated, shall not exceed two seconds.

The total of all responses/processes affected by input data changes shall not exceed 2 seconds. Total responses/processes include, but are not limited to report updates, calculations, and initiation of responses.

WMATA responsibility to furnish backbone services shall be measured from the time that the WMATA’s backbone receives/transmits data. Communication protocol times to establish data transmission shall be part of the Contractor’s time allocation.

Page 196


9.2.4 Response Time to User Input

The ROCC software shall respond to all user commands, display requests, data entry operations, and other user entries within a maximum of 200 ms at any Workstation. That is, from the time the user completes the input and initiates control to the System until the time that the ROCC software recognizes and initiates action on the user input shall not exceed 200ms.

9.2.5 Display Response Time

When any display is requested (measured from the time the user initiates the request), the display, complete with data values shall appear on the screen within one second at any Workstation.

When data entry is performed on a display, the data entry operation shall be completed within 200 ms on Workstations. That is, when a user completes data entry on a display and initiates control to the System measured until the System completes data validation, records newly entered values, and updates relevant displays with the newly entered data.

9.2.6 Display Update Rate

Displays shall be periodically updated as well as when changes occur to ensure integrity of displayed data. The data on Workstation displays shall be refreshed no less often than every 2 seconds. A display update shall be completed within 100 ms at any Workstations.

9.2.7 Scaling and Translation Response Time

An image shall be translated in a continuous manner from one screen border to the opposite screen border within one second at Workstations.

A user request to jump to a different window of the world coordinate display shall cause the display to be presented within 500 ms at Workstations.

9.2.8 Alarm and Event Response Time

All alarm and event messages shall be displayed within 500 ms at Workstations and Video Display System, measured from the time the alarm or event is detected within the System, including interfaces to external systems, interface to the field equipment, or within any component of the System or subsystem.

The alarm and event actions shall include message production, highlighting of alarm conditions, and audible and visual annunciation. Alarm acknowledgement and deletion from all displays shall be completed within 500 ms at Workstations after the user initiates the acknowledgement.

9.2.9 Report Response Time

Requests for reports shall be acknowledged within one second at any Workstation with an indication the report is being processed, measured from the time a report request is made, the report is validated, and report generation begins.

All external connections to existing WMATA servers; e.g. interfaces to RPM, EMS, PROTECT, PIDS, Trapeze, and other systems shall be within 1 second. Printing of reports shall begin within 10 seconds of their scheduled time, regardless of the level of activity.

9.2.10 Hardware Resource Utilization

The System shall support all functions described in this Specification concurrently executing utilizing no more than 40% of the processing capability of each processor under the peak loading conditions. The System shall support all functions described in this Specification concurrently executing utilizing no instance of more than

Page 197


90% of the processing capability of each processor for a duration exceeding 100 milliseconds under the peak loading conditions.

Processor time waiting for I/O transfers (including auxiliary memory transfers) shall be included as idle time to a maximum of 10% of processor capacity only if the processor is available for other processing. The Contractor shall demonstrate compliance with all processor utilization requirements during site performance testing, under peak loading conditions for a continuous period of time not less than one hour.

The System shall support all functions described in this Specification utilizing no more than 40% of the available access and transfer capacity under the peak loading conditions, for all controlled LAN access. The System shall support all functions described in this Specification utilizing no more than 50% of the capacity of each type of storage device under the peak conditions.

9.3 Support Services

Support services will be put in place to facilitate a mechanism for supporting the ROCC software as it is designed, implemented, tested, installed, and commissioned. Support services are also required during the Warranty Period. Support services involve the Contractor supplying all levels of system support for the ROCC software as described below. The level of support services that are required can be grouped as follows:

a) Notice to Proceed (NTP) through Site Acceptance Testing; complete Contractor responsibility to maintain all equipment in like-new condition and keep complete records of such maintenance;

b) System commissioning till completion of System Acceptance; on-site 5am to 7pm covering AM and PM rush hours at a minimum.

c) Services provided at CTF and JGB during installation of hardware, interfaces to existing interfaces and testing of interfaces.

d) From the first day of commissioning until the system is finally accepted by WMATA.

Support Services shall be provided by competent personnel of WMATA’s approval. If necessary, and at their sole discretion, WMATA may require a change of support personnel. The Contractor shall provide engineering data and services, as required by WMATA, starting at NTP and ending at the completion of the Warranty Period.

9.4 Contract and Contractor Maintenance

The Contractor shall be responsible for all ROCC software maintenance activities from NTP through the completion of the Transition Period. System maintenance activities shall include, but not be limited to performing repairs and preventative maintenance on all ROCC software elements located in the CTF and JGB control centers, including equipment calibration, tuning, circuit troubleshooting and alignments, correcting software defects, troubleshooting software problems, installing new software releases, and modifying system parameters.

All maintenance performed by the Contractor, Sub-Contractors, and OEMs shall be in accordance with procedures and schedules recommended by the OEMs. If the project schedule is delayed by any reason whatsoever, all maintenance Contracts and Contractor maintenance shall be extended an equal amount to ensure complete coverage of all phases defined under this Specification, including development, test, and maintenance phases.

In Addition, WMATA has requested that the Maintenance Plan continue after the Transition Period, with a series of one (1) year renewable contracts. These contracts shall be via Service Level Agreements. WMATA reserves the right to cancel these contracts and award them to others at their discretion.

Proposal Requirement: The Proposer shall provide in his technical proposal detailed information about the Maintenance of the software.

Page 198


9.4.1 Maintenance Plan

The Contractor shall develop and submit a Maintenance Plan (CDRL T501) in advance of the Final Design Review.

The Maintenance Plan shall:

a) define all preventative maintenance activities; b) include a schedule of preventative maintenance activities; c) describe how the Maintenance Database will be implemented; d) describe the tools supplied as part of the ROCC software that will support the software maintenance

activities; e) define all standard reports that shall be provided for reporting on maintenance activities; f) describe how to create and generate ad-hoc reports.

9.4.2 Maintenance Records

Corrective maintenance records shall include the following information:

a) Identification of the item repaired, replaced, or upgraded; b) Name of the person who performed the repair; c) Date and time when the malfunction was detected; d) Description of the malfunction; e) Date and time the malfunction was corrected; f) Description of the corrective action taken; g) Location of malfunction.

Preventive maintenance records shall include the following information:

a) Identification of the element being maintained; b) Name of the person who performed the maintenance; c) Date and time when the maintenance was performed; d) List of the maintenance procedures performed; e) Description of any problems encountered; f) Location of the element where maintenance was performed.

9.4.3 Maintenance Database

The Contractor shall provide a Maintenance Database that incorporates the maintenance schedule and facilitates tracking of maintenance activities and the collection of maintenance records. The Maintenance Database shall utilize a commercial database (COTS software) application that is compatible with the ROCC software hardware and software. The COTS software to be used to implement the Maintenance Database shall be identified in the Maintenance Plan for Engineer approval.

Preventative maintenance requirements (schedules, etc.) and maintenance activities shall be recorded in the Maintenance Database at the beginning of Factory Acceptance Testing. The Maintenance Database shall:

a) Include a minimum of five standard maintenance reports for scheduled and on-demand execution; b) Support the creation and storage of ad-hoc reports; c) Be available to WMATA at all times such that WMATA can review all maintenance records.

The Engineer shall be provided with the tools to sort and filter the database and produce standard maintenance reports on demand. The Contractor shall define the set of standard maintenance reports, and the associated content and format, for Engineer review and approval during prototyping.

Page 199


9.4.4 Display Control Graphical Library Maintenance

The ROCC software shall include the tools that are necessary to provide all software maintenance. The ROCC software shall include the capability to place all such software into service, for the following system components:

a) Train Control; b) SCADA System, including Traction Power, Tunnel Ventilation, & Tunnel Drainage.

All graphical elements to be displayed in the ROCC software shall be stored in and retrieved from the Display Control Graphical Library. Stated herein are the requirements related to creation, modification, and update of the Display Control Graphical Library.

Each physical field device shall be represented on the track diagram configuration and/or the graphic diagram as a graphic symbol, herein called an icon. The term “icon” is used to stand for “graphics display and control symbol.” The Contractor shall create a library of icons, consistent with WMATA operational needs. Each physical field device within the Train Control and SCADA communications systems shall be represented in the Display Control Graphical Library. Icons shall be defined and logically placed on a drawing surface through the Configuration Editor as described herein.

The Contractor shall develop and provide a library of “available-on-demand” graphic diagrams. The diagrams shall include track diagram configurations and support diagrams. The user shall be capable of selecting the graphic diagram that shall be displayed on the ROCC Workstation monitors and projected on the OCC Overview Display system. During the prototyping process the Contractor shall define and present to WMATA for review and approval each of the proposed graphic diagrams that are required for revenue operations.

9.4.4.1 Configuration Editor Requirements

The Contractor shall provide a Configuration Editor for the purpose of defining a Display Control Graphical Library of icons and a library of “available-on-demand” graphic diagrams. The Configuration Editor shall be an off-line tool that shall be accessed primarily via the ROCC Workstation, or any other console. The Configuration Editor shall provide the ability to draw an icon, and shall allow the user to define its display attributes, its type and its relationship to the device it represents. The design shall consider all requirements contained in this section and shall operate within the response time specified elsewhere in the Contract Documents.

9.4.4.1.1 Icon Definition and Modification

The Configuration Editor shall provide the means to define the look and display attributes of each icon.

The Contractor’s proposed design shall be based on providing a minimum of 100 different symbols in the final design. The graphic software that is provided shall have no practical limit on the number of different symbols that may be utilized by the ROCC software.

The Contractor shall develop a Display Control Graphical Library of icons that shall be displayed on each graphic diagram. The Display Control Graphical Library of icons shall consist of train control, SCADA and other operational icons, which shall be designed using the Configuration Editor. Since the graphic diagrams will integrate icons processed by various systems, the Contractor shall ensure the consistency of icon attributes between all software packages.

Icon Attributes – As icons are displayed on the graphic diagram, they may vary in appearance, depending upon the type of request by a console operator or by the status of the field. The definition of the various behaviors each icon may represent is called an icon attribute. Each occurrence of an icon shall be able to have different combinations of attributes assigned to it, depending upon the specific operating condition. Icon attributes shall be defined through the Configuration Editor. Changing the display attribute of an icon shall not require the reprogramming of any of the software systems. The Configuration Editor shall support the following icon attributes. In addition to the various attributes identified herein, the Contractor shall identify and present a minimum of five additional attributes to WMATA during the design review process:

Page 200


a) Shape – While the Contract Drawings present icon symbols and shapes that are acceptable to WMATA, experience may find that different symbols/shapes, or that alphanumeric text, may be required for a particular icon. It shall be possible to easily modify the shape of any icon. It shall also be possible to use a second shape for the same icon.

b) Size – It shall be possible to scale an icon such that the size of the icon may vary from one occurrence to the next.

c) Color – Each occurrence of an icon shall consist of any of the 256 available colors. d) Intensity – Three levels of display intensity are required. These are “off” intensity, “low” intensity, and

“normal” intensity. e) Orientation – It shall be possible to vary the orientation of the icon from one occurrence to the next. f) Blink – It shall be possible to have the icon display steady, with a slow blink, or with a fast blink, for

any occurrence of an event, state change, failure, etc. g) Background Color – This icon attribute requires each symbol to be surrounded by a rectangle (or other

Engineer-approved shape) to provide a background. The background color may be varied from one occurrence to the next. The design shall provide a transparent background, the normal screen background color, colors associated with cursor placement and any other combination of background/foreground colors using the 256 colors.

h) Location – The track diagram configurations are typically designed along a geographical layout. For the rail lines, the track segments relating to individual track circuits serve as the master for locating all other icons. Certain icons must be placed in absolute relation along the track centerline to their associated track circuits. These include station platforms, signals, switch points, vehicle arrow and any other icon that conveys information corresponding to physical placement of the track circuit boundaries. (Note: This does not require that each track segment be the same length, nor that the track segment be consistent with the actual field length of the track circuit.) However, these icons do not always have to be placed in absolute relation perpendicular to the track centerline. It is expected that the perpendicular distance will vary relative to the other icons that are to be included on the specific display.

i) Time to Display – Select occurrences of an icon may have an associated variable display time and these parameters shall be provided in a table to be easily reassigned. This shall include “display until turned off,” and multiple capabilities to “display for X minutes.”

j) Priority – Icons which require user response shall have a priority established. The priority attribute shall be used by the ROCC software to direct attention to the most pressing items. In addition, the system shall use the icon priority to determine how icons shall be layered on the track diagram configuration. The icons having the highest priority shall appear in the foreground, while those with a lesser priority shall appear in the background.

WMATA requires maximum flexibility in being able to assign different attributes to each icon. The design shall be such that the attributes can be assigned on a global basis, to one or more subsets of icon usage, or to a very specific application of an icon. The system shall also be designed to respond rapidly to the users request to add or delete icons, add or delete subsets of icon usage and add or delete icon attributes. The Configuration Editor shall provide a “user-friendly” method for maintaining this data after the system has been delivered. It shall be possible to implement a global modification (change a single item and have it automatically updated in the many locations that the item appears) to utilization or attributes. For example, if the phone number for ROCC changes, it shall be possible to modify with a single command the text for all icons where this text string appears. The Contractor shall present the method of maintaining and modifying icon attributes for review and approval by WMATA during the design review process.

9.4.4.2 Applying the Graphic Diagram to the On-Line System

Upon completion of a graphic diagram, the new graphic diagram shall be tested by running the system in simulation mode. Any errors resulting from these tests shall be corrected and retested prior to releasing the graphic diagram to the on-line system.

The release of a graphic diagram configuration to the on-line system shall be initiated by an Authorized User within WMATA. Upon release, the on-line system may then be prepared for the receipt of the new graphic diagram.

Page 201


If the release of a graphic diagram is the result of graphical changes to the diagram, then the on-line system shall not be restarted in order to place these changes into effect. The changes shall occur within 30 seconds of the release command being executed. If the release of a graphic diagram is the result of an addition, deletion or modification of a device and/or a device state, then only those software processes responsible for the processing of graphic- and/or device-related data shall be restarted.

The new graphic diagram shall be available within 30 seconds of the restart command being executed. There shall be no instance when the entire ROCC software shall be restarted due to the release of a graphic diagram configuration. The Contractor shall provide a detailed review of each of these scenarios during the design review process. Each graphic diagram must be archived to the Historical Data system for playback and reporting purposes.

9.4.4.3 Graphic Display Review

The Contractor shall use the user interface prototyping as a mechanism for reviewing the design and implementation of the graphics display management requirements. The review shall consist of the following at a minimum:

a) Review of the library of icons; b) Review of the icon attributes; c) Review of the Configuration Editor tool; d) Review of the library of “available-on-demand” graphic diagrams.

9.5 Recovery & Rebuild Utilities & Equipment

9.5.1 Rebuild & Recovery Kit

The Contractor shall provide WMATA a detailed Rebuild & Recovery kit (CDRL T502). The kit shall contain all software and utilities required to recover, restore or rebuild the system. Additionally, the Contractor shall deliver to WMATA a list of recommended, low level spare parts for the hardware provided by WMATA. This would include power supplies, hard drivers, RAM etc.

The Contractor shall preprogram and test a spare hard drive for each workstation and server included in the Rebuild & Recovery kit. For each spare hard drive the Contractor shall provide complete instructions (Step by Step) on how to rebuild each workstation, FEP, Server, and/or Historian computers. This shall include the Operation System software, ROCC software, network, display configurations, and all testing and misc. software required for each computer to be completely rebuild.

The Rebuild & Recovery kit shall be categorized by subsystem or component, assemblies and subassemblies identifying the part name, number, stock number, unit cost, types, makes, models, etc. of spare parts required to support and maintain the ROCC software. The Contractor shall maintain a computerized inventory of the Rebuild & Recovery kit using COTS database tools. The Rebuild & Recovery kit shall be updated/submitted (as required) prior to the start of FAT.

The Rebuild & Recovery kit shall be continuously updated throughout the performance of the Contract and shall include results derived from the following: testing the equipment; analyzing long term continuation of the required response and repair times.

If, after the FDR and prior to Substantial Completion of the ROCC software, it becomes necessary (as determined by WMATA) to modify the supplied hardware (e.g. use of a different type, size, or configuration of equipment) to meet the requirements of this Specification, the Contractor shall modify the Rebuild & Recovery kit to include any additional spare parts required to maintain the modified hardware.

WMATA will be responsible for purchasing and storing all spare parts for the ROCC software.

Page 202


9.5.2 Test Equipment

With the hardware provided by WMATA, the Contractor shall configure and load all necessary software onto the following test equipment:

a) Two (2) laptop Computers with diagnostic software for troubleshooting network, Server, FEP and software problems,

b) Simulation software used during the FAT testing.

Page 203


10. Training

General requirements for Contractor training of WMATA personnel on the ROCC software are described in this section of the Specification.

Proposal Requirement: The Proposer shall provide in his technical proposal detailed information about the Training provided with the software.

10.1 General Requirements

Two broad categories of training shall be developed and implemented by the Contractor: Operational Training and Maintenance Training. Operational Training pertains to the Users of the systems including, but not limited to Transportation Department personnel; Power, Signals, and Communications Department Personnel; and Systems Administration functions related to routine operations of the systems and user interactions. Maintenance Training pertains to alarm condition response, trouble shooting, preventative and corrective maintenance, failure management, system modification and updating, raid systems, troubleshooting, and system restoration.

The supportability of the ROCC software is a major concern to WMATA, and shall be a primary focus for the Contractor. The Contractor shall provide a comprehensive WMATA-specific training program that prepares WMATA’s personnel to fully utilize the ROCC software, including training for operations, preventive and corrective maintenance, and reconfiguration of railway, track and signal system changes. The Contractor shall deliver all training aids, simulators and materials necessary to conduct training.

All training shall be professionally video recorded (CDRL T704) and edited for future review and use by WMATA. These videos will serve as WMATA’s entrance level training program for operations and maintenance training. All training shall be implemented at a site designated by WMATA. The likely location for the training will be the CTF.

Customized training shall be developed both as rote type training for particular operations, maintenance and/or system or subsystem modifications, as well as scenario and “hands-on” training in which a variety of activities across subsystems must be performed. For example, scenario training shall be provided to instruct how to modify the ROCC software to accommodate changes in track topography such as adding or removing a crossover.

The Contractor shall employ and assign a training coordinator and shall be responsible for coordinating all training activities and for ensuring that all training requirements have been met to the satisfaction of WMATA. The training coordinator shall be responsible for implementing the approved Master Training Plan to WMATA’s satisfaction.

10.2 Master Training Plan

The Contractor shall provide a complete and comprehensive Master Training Plan (CDRL T701) for review and approval by WMATA. Use of the term “Training Plan” within these specifications refers to the Master Training Plan. The Master Training Plan shall cover the ROCC software and the interfaces to legacy WMATA interfaces.

The Master Training Plan shall define all training activities, processes, and resources necessary to ensure that all WMATA personnel are fully capable of operating, maintaining, and modifying the ROCC software, as defined in this Specification.

The training program shall be coordinated with the test and commissioning program and ensure that WMATA personnel are trained in a timely manner to support test and commissioning, and that any training tools, training equipment, training materials and test equipment necessary for training are available and not in conflict with the testing program.

The Master Training Plan shall contain a schedule of all training activities and describe all training activities in sufficient detail, such that WMATA can schedule all resources including classrooms and class

Page 204


participants. The Master Training Plan shall include a Top-Level Master Training Plan providing an overview of the training program and a Detailed Master Training Plan that expands upon the training program topics.

10.2.1 Top-level Master Training Plan

The Top-Level Master Training Plan shall be delivered for Engineer review and approval prior to the CDR.

The Top-Level Master Training Plan shall include:

a) a narrative description of the objectives and scope of the training program; b) a complete outline of the Master Training Plan; c) a description of the content of that section and subsection; d) pilot courses; e) train-the-trainer courses; f) criteria for refresher courses and any additional courses that the Contractor recommends, but are not

part of the Contractor-delivered training; g) a complete Training Catalog defining the recommended training courses by user type; h) describe the methodology that will be used to evaluate students and shall describe how to determine

whether a student will need to be retrained.

10.3 Detailed Master Training Plan

The Contractor shall expand upon those topics covered in the Top-Level Master Training Plan within the Detailed Master Training Plan. The Detailed Master Training Plan shall be delivered for Engineer review and approval prior to the Preliminary Design Review (PDR).

The Detailed Master Training Plan shall:

a) provide a detailed description of all training courses including pilot courses, train-the-trainer courses and refresher courses;

b) define the number of training sessions offered per training course c) define the number of participants, by user classification, in each session of each training course; d) define for each training course, the expected level of proficiency of the student after completing the

course; e) include a separate syllabus for all training courses, including the user level training course and the

managerial level training course; f) include an agenda, describing which topics shall be covered on which days, hours, start and end times. g) describe which proposed method(s) of instruction would be used to deliver the course instruction. h) the use of multi-media, computer-based training (CBT) and web-based training (WBT) materials; i) the location where training is to occur; j) Proposed trainer.

In the event the Contractor would like to perform training at a location other than WMATA’s facility, the Contractor shall identify the location and rationale for the proposed alternate location. The proposed alternate location is subject to approval by WMATA.

10.4 Train-the-Trainer

The Contractor shall develop a comprehensive train-the-trainer program and describe in the Master Training Plan how WMATA instructors will be trained to successfully deliver all Operational Training Courses. The train-the-trainer program shall ensure that WMATA Instructors are fully able to perform all monitoring and control functions of the ROCC software for each type of user.

10.5 Training Schedule

The Contractor shall be responsible for planning and scheduling and conducting all training courses.

The Training Schedule, including the resource requirements (quantity and skill levels) for each training course, shall be updated with the Conceptual Design Review (CDRL T701.1), System Requirements Review,

Page 205


Preliminary Design Review, Final Design Review, Implementation Review, and at the completion of Site Installation Test.

The term training sessions is used herein to define an iteration of a training course. Many of the training courses are required to be offered more than once, to give WMATA the flexibility of scheduling personnel to attend the courses.

The Contractor shall deliver all train-the-trainer courses such that WMATA may train all Operational personnel prior to the start of Transition Phase 1 and all maintenance personnel prior to the start of FAT. The Contractor shall conduct training at a time approved by WMATA. The times of the training shall be:

a) scheduled over a 24-hour period (three tours) consistent with WMATA employee’s reporting times; b) begin and end within the hours identified in each tour and shall not span tours; c) limited to six hours maximum per day inclusive of break-time, unless extended class time; d) structured such that a 15-minute break is given every 1.5 hours; e) provide a 30-minute meal-break in the middle of the session, at the request of WMATA.

The Contractor shall conduct training courses and adjust the training schedule to meet the availability of WMATA personnel. Many of WMATA participants in the training program will have full-time responsibilities other than those which will be assumed upon revenue operation of the ROCC software and which include work shifts other than 8 am to 4 pm, Monday through Friday.

10.6 Training Material

All training materials shall be in U.S. spellings of the English Language.

ROCC software Training Materials (CDRL T703) shall be developed and provided for training. Specific material may be provided in the form of different attachment material or in completely separate guides and instruction material, whichever is best suited to meet the needs of the instructor and/or trainee.

Presentations shall:

a) be developed using Microsoft PowerPoint; b) include all text and graphics required to support the instructor in presenting the course as described in

the Instructor’s Guide; c) include graphical animations or video clips where necessary to clearly illustrate the operation of the

system or device under discussion; d) be legible and include an area where the attendee can make notes; e) be incorporated into the Participant’s Guides and Instructor’s Guides.

The Contractor shall prepare self-study material as required and training exercises and submit as part of the training material. Training material shall include Participant’s Guides and Instructor’s Guides. The Contractor shall ensure that any variances (e.g. uncovered technical errors, omissions, and/or equipment system modifications) identified during any phase of the Contract are addressed accordingly in the training material and that the training material is resubmitted at the subsequent milestone.

As part of the final documentation, the Contractor shall furnish WMATA with all changes and revisions to all training material and supplementary training material. The Contractor shall develop test materials for each training course defined herein to determine the proficiency of each course participant.

a) Testing of trainees shall be provided for all training courses, regardless of the method of training that is used to conduct the course.

b) The test materials shall determine whether the course participant has met the expected level of proficiency.

c) The Contractor shall develop training courses, which provide remediation when it is determined that a trainee is not proficient in the skill being taught.

Page 206


All training material including all modifications and supplements requested shall become the property of WMATA at the conclusion of the Contractor furnished training courses. WMATA shall be allowed unlimited use and copying of all Contractor supplied training material.

10.6.1 Instructor’s Guide

This section defines the minimum required content of the Instructor’s Guide (T703.2). Instructor’s Guides will be used by WMATA to deliver the initial Operational Training Courses as well as on-going training that will be delivered by WMATA personnel after the Contractor’s training obligations have been met.

The Contractor shall provide detailed scripted Instructor’s Guides for each training course.

The Instructor’s Guides shall include:

a) all information, which shall allow a trained WMATA instructor to present the course; b) course preparation instructions for the instructors; c) a list of training course skills to be taught during the course d) a course description and objectives; e) a lesson plan, which shall break the training course into specific lessons/and or topics; f) a description of the graphics and text in the associated presentation, and instructions for the use of the

animations or other visual aids incorporated in the presentation; g) test materials for the training course; h) remediation materials such that a student can be retrained and retested; i) templates for the instructor to create evaluation reports for each student; j) references to the Participant’s Guide and other references as applicable.

The physical construction of the Instructor’s Guide shall be the same as required for Operations and Maintenance Manuals. Prior to starting work on the Instructor’s Guide submittals, the Contractor shall meet with WMATA and Training Personnel, and shall obtain sample Instructor’s Guides for reference.

10.6.1.1 Lesson Plan

The lesson plan shall describe which topics shall be covered on which days (i.e. day one, day two, day n) and the duration of each training topic.

The lesson plans for each of the Maintenance Training Courses shall be organized as follows and shall include the following detail:

a) Equipment Description;

• Purpose and functions of equipment and auxiliary equipment and systems; • Physical arrangement of equipment components and electrical supplies; • Control and monitoring functions;

b) Equipment Operation;

• Operating requirement for equipment to perform satisfactorily; • Typical operating characteristics; • Start-up and shutdown procedures; • Use of controls; • Option selection and adjustments;

c) Equipment Monitoring;

• Recommended routine instrument readings and operational checking, if any; • Early warning signs of developing operational or equipment problems;

d) Equipment Operational Trouble-shooting Procedures;

Page 207


e) Safety and Housekeeping;

• Safety features of the equipment; • Safe practices; • Housekeeping practices;

f) Description of the Use of the Equipment Manufacturer’s Operations and Maintenance Manual as Related to Operation;

g) Preventive Maintenance Requirements;

• Maintenance needs for equipment; • Identification of procedure to satisfy maintenance needs (relate to equipment manufacturer’s

Operations and Maintenance Manual, which should have detailed descriptions of maintenance procedures);

• Outline and summary procedures; • Recommended schedule for performing preventive maintenance; • Provide preventive maintenance record forms (if available);

h) Maintenance Inspection Program;

• Parts, components and areas of equipment to inspect for routine preventive maintenance; • Recommended frequency of inspection; • Inspection procedures; • Problem identification;

i) Maintenance Trouble-shooting;

• Sections in OEM Manual detailing trouble-shooting procedures; • Summarize trouble-shooting procedures; • Testing equipment used in trouble-shooting;

a. Demonstrate use of specialized testing equipment; b. Other testing equipment;

• Tests used to verify trouble-shooting findings;

j) Disassembly and Assembly;

• Summarize disassembly and assembly procedures; • Original Equipment Manufacturer (OEM) Manual coverage of subject; • Testing to verify success of corrective maintenance;

k) Equipment Calibration;

• Calibration needs and tolerances; • Calibration equipment; • OEM Manual listing of calibration ranges, tolerances and settings.

10.6.2 Participant’s Guide

The Contractor shall provide Participant’s Guides (CDRL T703.1) for each training course. The Participant’s Guide shall include the training course agenda, course overview, lesson objectives and a description of each topic that is taught during the training course, such that the trainee can follow along with the instructor’s lesson.

Prior to starting work on the Participant’s Guide submittals, the Contractor shall meet with WMATA and Training Personnel and shall obtain sample Participant’s Guides for reference. The format and organization of the Participant’s Guides shall match the samples provided by WMATA.

Page 208


10.7 Training Aids

The Contractor shall provide additional training aids, such as mock-ups, PowerPoint™ presentations, videotaped demonstrations, diagnostic testing equipment and any special tools required.

10.8 Maintenance Manuals

The Contractor shall provide Maintenance Manuals (CDRL T411) to WMATA that includes information, as approved during system design, to efficiently maintain the ROCC software elements and the equipment supplied under the Contract Documents. The manuals, collectively, shall include all information to troubleshoot and maintain the entire ROCC software. Where Contract maintenance may be employed, the manuals shall be the same type that the original manufacturers service representatives use. The Contractor shall also provide specifications and instruction manuals for all special tools and test and calibration equipment supplied under the Contract Documents.

Maintenance shall include, at a minimum, the following topics:

a) Preventive maintenance, including limits, settings and tolerances; b) Lubrication and cleaning, including frequency, methods, trade identification of recommended

materials and location and description of components; c) Corrective repair, at subsystem level, and component repair, including step-by-step procedures,

techniques, adjustments, use of diagnostic test equipment and use of special tools; d) Troubleshooting, including flow sheets, tables and symptom/cause/remedy charts; e) Replaceable parts, including generic names; f) Systematic fault isolation procedures; g) A full description of self diagnostics and embedded diagnostics.

The Maintenance Manuals are to be provided to trainees in support of the training effort as well as for reference during Maintenance. It is not intended to review these documents as part of the Training Program.

10.9 Electronic Media for Manuals and Guides

The Contractor shall supply all training materials on CD-ROM in the latest version of each of the following formats: Microsoft Word format, Adobe Acrobat PDF file format and in dynamic HTML format. The Contractor shall deliver six copies of each training programs on separate CD-ROM disks.

10.10Training Methods

Training courses shall consist of one or more of each of the following methods of training or combinations of training methods: classroom lecture, hands-on training, self-study, multi-media, computer-based and web-based.

10.10.1 Multi-media, Computer-based and Web-based Training

Multi-media, computer-based and web-based training courses shall be supported by the availability of qualified Contractor. The Contractor shall grant WMATA permanent use in the future any multi-media, computer-based or web-based training provided as part of the training. This training material shall be provide the training material in the most current MPEG or HTML format at the time training is delivered.

10.10.1.1 Computer-Based Training (CBT)

The CBT courses shall be developed in close coordination with the Participant Guides, such that the CBT reinforces the concepts described in the Participant Guides. The Contractor shall furnish 21 licenses of the selected CBT application software licensed for an Intel platform using the current Microsoft Windows operating system.

The CBT courses shall:

a) provide user interaction with the training material;

Page 209


b) integrate graphics, audio, video, and animation in order to introduce training concepts; c) provide simple emulation of concepts, such as controlling graphic devices; d) provide feedback to the trainee.

The CBT course shall allow students to interact with the training software at a personal computer. The CBT courses shall be developed incrementally, such that Engineer approval of CBT course material is reviewed in conjunction with the submittal milestones for training material.

10.10.2 Use of Software During Training

The OCC Control software application shall be used to during the training courses. Updates to the production software shall be added to all training during the life of the contract. The Contractor shall demonstrate the installation, execution and setup of the training configuration to WMATA prior to the first session of each training course.

10.10.3 Video-Based Training

Prerecorded training courses shall be supported by the availability of qualified Contractor, the Contractor’s subcontractor, third party software suppliers and/or OEM personnel to answer questions and provide in-depth discussion of topics. Pre-recorded training courses shall be provided on DVD or other Engineer-approved format.

10.10.4 Video Recording of Instructor-led Courses

All training courses led by the Contractor, the Contractor’s subcontractor, third party software suppliers and/or OEMs shall be video recorded by the Contractor and copies provided to WMATA.

The Contractor shall prepare the recording of the instructor(s) presenting each of the required training courses in a controlled environment (no students, pauses in appropriate places to permit viewers time to grasp points made, etc.). WMATA shall own all rights to the recorded training course including, but not limited to, the copyright thereto.

10.10.5 Contractor Instructor Qualifications

For each training course identified within these Specifications, the Contractor shall furnish the services of qualified training instructors to provide complete training courses. The instructors shall be able to communicate clearly and effectively in the English language using the terminology of WMATA as determined by WMATA. The instructors shall have a working knowledge of WMATA procedures relating to the subject matter of the course they are presenting.

The instructors provided by the Contractor, subcontractors, third party software suppliers, or OEMs shall have had previous formal classroom instructor training and relevant experience with the ROCC software hardware and software.

The instructors provided by the Contractor, subcontractors, third party software suppliers, or OEMs shall have full, precise and detailed knowledge of the design and functional characteristics of all aspects of the equipment and systems furnished with particular emphasis on operational and maintenance considerations and requirements.

The instructors provided by the Contractor, subcontractors, third party software suppliers, or OEMs shall be able to design practical and written tests to determine the extent to which trainees understand and can apply the information that has been taught.

All instruction requiring instructor presence shall be provided in person. The Contractor shall submit the qualifications of the proposed training instructor(s) for approval as part of the Master Training Plan. This includes; current resume, describe the experience relevant to the course; transit properties and dates in which they have performed past instruction.

Page 210


Upon approval of the qualifications of the proposed training instructor(s) by WMATA, the proposed instructor shall conduct the pilot program for their assigned course.

10.10.6 Pilot Program

The Contractor shall develop and deliver a pilot course of each training course 60 days prior to delivery of the first session of each training course, to permit WMATA to evaluate the course content, manner of presentation, training materials and the skills and proficiency of the proposed instructor. The Engineer’s evaluation will be made in conjunction with personnel from other WMATA departments.

All training materials, training aids, test equipment and training equipment associated with the training course, shall be used by the Instructor during delivery of each pilot. During each pilot, the proposed instructor shall demonstrate a thorough knowledge and familiarity of the training material, training aids, test equipment and training equipment used in the training courses.

If WMATA determines that there are extensive revisions to any aspect of the pilot presentation and/or training material, the Contractor shall update the corresponding training material and re-run the pilot presentation. The Contractor shall revise the Training Schedule to reflect dates for the re-run of the pilot presentation within 14 days of the initial presentation. All costs for initial and subsequent presentation of the pilot presentation shall be at the Contractor’s expense.

10.10.7 Trainee Skill Level

The Contractor is required to develop the training courses based upon the skill level and user classification of the trainees attending the course. Each of the training courses identified herein define the anticipated skill level of the trainees. Training courses shall be developed for and delivered to WMATA instructors, operational personnel, maintenance personnel and engineering personnel.

All course material designed for Operational personnel shall be developed for personnel with a high school education and a minimum of four years service on WMATA in a department responsible for the area of work to be performed. Tower operators and Power Directors are an example of operational personnel.

All course material designed for engineering personnel shall be developed for personnel with a four-year post-high school graduate degree in an area related to the work to be performed. WMATA programmer staff is to be considered engineering personnel.

All course material designed for managerial personnel shall be developed for personnel with some post-high school academic or professional experience in an area related to the work to be performed. Instructors and supervisory personnel are considered to be managerial personnel.

10.11Training Course Descriptions

This section defines the training courses that WMATA requires in order to efficiently operate and maintain the ROCC software. The Contractor is encouraged to review the training courses and recommend changes to the courses as necessary. It is required that each of the courses outlined herein will be broken down into more detailed courses and delivered individually.

Prior to developing the training courses, the Contractor shall visit WMATA’s maintenance and training facilities, review WMATA’s maintenance and training methodologies, and WMATA training personnel who shall be involved in the maintenance and training processes.

The Contractor shall evaluate the skills necessary to ensure effective operation, maintenance, and ongoing engineering, of the System(s) and subsystems associated with the training course. Training courses shall address both normal and abnormal operating conditions and system responses.

Page 211


The Contractor shall develop and/or provide extended, duplicate, or additional training for the ROCC software as deemed necessary by WMATA because of the following occurrences:

a) Any modifications of the hardware or software component, made after completion of the scheduled training courses, including any and all modifications to the hardware or software required after the in-service testing and to meet the maintainability requirements;

b) Delivery of any hardware or software component more than six months late.

10.11.1 Operational Training

The Contractor is required to first instruct WMATA instructors on how to operate the ROCC software so that they can perform the functions of any class of user that will be required to operate the ROCC software. The Contractor is then required to train WMATA instructors on how to use the training aids, training materials and facilities to teach the Operational Training courses to each class of user.

10.11.1.1 Operational Training Course

This section describes the course content that will be provided by the Contractor such that instructors and Operations personnel can be trained in the use of the ROCC software to perform their job functions.

Operational Training will be provided for all WMATA personnel that will be responsible for service delivery using the ROCC software. Operational training must be provided for every class of user that will be operating one of the workstations. The Contractor is expected to understand the type of functions that each user will need to perform their job function. The courses must be structured such that a user does not need to attend courses which have no applicability to their job function.

The WMATA instructors will deliver Operational Training Courses to all classes of users that will be given workstation equipment, including but not limited to:

a) Line Supervisors; b) MOC Line Supervisors; c) Assistant Line Supervisors d) MOC ATC/Comm Supervisors; e) CMNT; f) ELES; g) Emergency/ IT/ MTPD; h) RCOM2, RCOM1, RCOM Assistant; i) Management; j) Signal Supervisor; k) Engineers

The Contractor shall review the job functions of WMATA’s personnel to determine how to best organize the training material such that the Operational Training Courses can be logically presented to a given class of user.

The Operational Training Courses shall include, but not be limited to:

a) Introduction to Windows environment, describing the menu system, display navigation, and all associated graphical user interface functions and features;

b) Provide a thorough understanding of the user interface functions and features; c) Centralized Traffic Control functions, such as monitoring device status and controlling field devices; d) Schedule/timetable maintenance and modification such as importing and editing data relating to train

service; e) Train tracking functions, such as monitoring train movement, and editing train identifiers,; f) SCADA functions such 3rd rail energization status, EA box trip and automatic call functionality, and

tunnel ventilation status and control; g) Report generation functions; h) Playback functions; i) Access control functions such as log on/off, establishing passwords, establishing function access

assignments, user classifications and territory assignments;

Page 212


j) System administration functions, such as network security and system monitoring; k) Database administration functions such as adding data points and managing the real-time and global

databases; l) Alarm management functions; m) Graphical user interface functions and features;

10.11.1.2 Instruction Methods Training

The purpose of the Instruction Methods Training is for the Contractor to train WMATA instructors on how to use the training aids, training materials and facilities to deliver Operational Training to operational personnel. The Instruction Methods Training Courses shall be developed for the Operational personnel.

10.11.1.3 Instructor Simulator Training

The purpose of the Instructor Simulator Training Course is for the Contractor to train WMATA instructors on how to operate the simulation system, such that the instructor can create and execute hands-on training scenarios.

The Instructor Simulator Training Courses shall:

a) be developed for operational personnel; b) include detailed instruction on the procedures required to start, pause and stop the system simulator; c) include detailed instruction on selecting and executing training scenarios; d) include detailed instructions for developing new simulation scenarios and modifying existing

scenarios; e) detailed instructions for manually injecting simulation outputs; f) detailed instructions for modifying user-adjustable parameters; g) include detailed instructions for injecting errors.

10.11.2 Maintenance Training Courses

The Maintenance Training Courses shall be developed for instructors, maintenance personnel, technical support, and supervisory personnel. Maintenance Training Courses shall be provided for all equipment including, but not limited to central office equipment, and all software supplied under this Contract.

10.11.2.1 Hardware Training

Hardware training shall include training in system start-up, shut-down, failover of all systems and subsystems.

10.11.2.1.1 Training For Hardware Maintained by WMATA

The Maintenance Training Courses for equipment to be maintained by WMATA shall provide WMATA personnel or its selected third-party contractor with an in-depth working knowledge of the hardware and its operation, the associated interfaces with computer hardware, and the capabilities and operation of the diagnostic tools.

10.11.2.2 System Configuration, Display, and Report Training

The Contractor shall develop and present System Configuration and Maintenance Courses, Display Generation and Maintenance Courses and Report Generation and Maintenance Courses.

The System Configuration and Maintenance Courses, Display Generation and Maintenance Courses and Report Generation and Maintenance Courses shall be developed for the ROCC software maintenance personnel and software engineering personnel.

10.11.2.2.1 Device Definition Training

This section describes the requirements for training WMATA personnel in the tools and skills needed to represent field devices and their associated states within the ROCC software.

Page 213


The System Configuration Definition and Maintenance Course shall instruct the trainee on:

a) the methods to add, modify and delete data points; b) how to table the bit assignments (from the code function assignment sheet) for each device state; c) to define, modify and delete routes within the ROCC software; d) to define alarm conditions and associated alarm attributes, such that when a device-related alarm

occurs, the device icon will uniquely reflect the device state; e) how to generate a loadable run-time database for use by the on-line system; f) how to test the run-time database; g) how to change an infrastructure feature such as extend a platform; h) how to add/remove, a signal, a switch, or a track circuit; i) how to change a third rail section limits; j) how to add/remove a ROCC software workstation from configuration files.

10.11.2.2.2 Graphic Display Generation and Maintenance

This section describes the requirements for training WMATA personnel in the tools and skills needed to draw graphic objects and place those objects on graphical diagrams. The Graphic Display Generation and Maintenance Course shall instruct the trainee how to:

a) create, modify and delete graphic objects through the use of the interactive graphics management tool. b) to create, modify, and delete display segments; c) create modify and delete display layers; d) to create modify and delete libraries; e) create roll back & roll forward library versions; f) create, modify and delete graphical displays; g) to place graphic objects on a graphical display and link those graphic objects to a data point; h) partition a segment of the graphical display into a territory, such that the territory can be assigned to an

authorized user for control; i) create, modify and delete declutter levels, name declutter levels, and assign graphic objects to declutter

levels; j) create logical groupings of devices from the graphic objects in order to define interlockings.

10.11.2.2.3 Text-based Display Generation and Maintenance Training

This section describes the requirements for training WMATA personnel in the tools and skills needed to create text-based displays. The Text-based Display Generation and Maintenance Course shall provide participants with a thorough understanding of the procedures for creating, modifying and deleting text-based displays.

The Text-based Display Generation and Maintenance Course shall describe how to create, modify and delete widgets and store the widgets in a library for future access.

10.11.2.2.4 Report Generation and Maintenance Training

The Report Generation and Maintenance Course shall provide participants with a thorough understanding of the procedures for building, modifying, deleting, and installing report formats.

The Contractor shall provide an overview of the application data that is written to the report database and how often the data is written. Contractor shall describe how to:

a) select data fields from the report database and place that data onto a report; b) format a report for display on a monitor and for printed reports; c) incorporate pre-defined reports into the menu system; d) create templates for ad-hoc reporting; e) schedule report generation.

Page 214


10.11.2.3 Software Training

Software training shall be provided for (1) training on maintenance and upgrade of software to be supported by the maintenance contract and (2) training on maintenance and upgrade of software to be maintained by WMATA.

10.11.2.3.1 Programming Training

The Programming Courses are intended to instruct WMATA personnel in the use of the language(s) in which the ROCC software has been implemented. This course will instruct the students on how to compile, test and debug source code changes and integrate those changes into the “live” ROCC software. The Programming Courses shall be developed for software engineering personnel.

10.11.2.3.2 System and Application Software Training

The System and Application Software Courses shall include a detailed description of the hardware and software architecture for the ROCC software including a description of all libraries, objects, inter-process communication tasks, internal and external interfaces including field systems and WMATA systems.

The System and Application Software Courses shall describe the design for portability, expandability, scalability, availability, maintainability and reliability.

The System and Application Software Courses shall include a detailed discussion of each application program, a detailed description of its uses and capabilities, input and output data parameters, program data flow, interfaces to the database and other programs, and algorithms employed.

The System and Application Software Courses shall include a detailed description of the database structure, how data items are initialized, which processes write to and read from the databases, which are memory-resident and which are disk resident.

Contractor shall provide each trainee and instructor with pertinent sections of the Software Architectural Design Document (CDRL T309) as a training aid.

The Contractor shall provide each trainee and instructor with pertinent sections of the Software Detailed Design Document (CDRL T310) as a training aid.

10.11.2.3.3 Software Administration Training

This section defines the requirements for training WMATA personnel in the tools and skills required to manage the software development process. The Software Administration Courses shall be developed for software engineering personnel.

10.11.2.3.4 Database Administration

This section defines the requirements for training WMATA personnel in the tools and skills required to modify, maintain and administer the databases. The Database Administration Courses shall be developed for software engineering personnel.

10.11.2.4 System Administration Training

The Contractor shall provide System Administration Training Courses that will allow WMATA personnel to monitor the ROCC softwares hardware and software components and to trouble-shoot problems and maintain the system.

10.11.3 System Course Quantity and Class Size Requirement

This section provides the specific course quantities and class sizes for the ROCC software. The Contractor shall develop an overview module that provides an overview of the operation and systems, placing the ROCC software in its operating context to the existing CTF relevant to WMATA’s current operations.

Page 215


For each course, the Contractor shall deliver the number of trainee training sessions identified in the following Table.

ROCC software Courses

Quantity of Sessions to Instruct Trainees

Quantity of Sessions to Instruct Instructors

Quantity of Trainee Training Material/Aids

Quantity of Instructor Training Material/Aids

Operational Training Course 0 2 100 8

Instruction Methods Training Course

0 2 0 8

Instructor Simulator Training Course

0 2 0 8

Hardware Training 3 1 24 2

System Configuration Definition and Maintenance

3 1 24 2

Network Configuration, troubleshooting and Training

3 1 24 2

Hardware Replacement, troubleshooting and System Rebuilding

3 1 24 2

Programming 3 1 24 2

System and Application Software

3 1 24 2

Software Administration 3 1 24 2

Software Application Testing 3 1 24 2

Database Administration 3 1 24 2

System Administration 3 1 24 2

Table 10.11: Training Quantities

Page 216


11. Documentation Requirements

Proposal Requirement: The Proposer shall provide in his technical proposal detailed information about the Documentation provided with the software.

11.1 Project Management Documents

11.1.1 FRD – Functional Requirements Definition

The Functional Requirements Definition shall be prepared as described in the ConOps section. The FRD will be used by WMATA to verify that those defined requirements of the Specification have been addressed within the submitted deliverables. The FRD will be used when reviewing document submittals

The FRD shall be used in Final Acceptance Testing to evaluate how well the delivered system meets design requirements.

11.1.2 Interlocking Interface Documentation (ID)

Interlocking Interface Document (IID) provides information on the operation of the field Train Control systems. The IID serves as an interface requirements document, as well as documentation of the site-specific data engineering necessary to implement functionality. In the IID the Contractor shall document all of the field Train Control system capability, functionality and configuration as applicable to the ROCC software. Where possible, interlocking of identical function can be described by a single IID.

A complete set of IID’s shall be packaged into a single document with an Executive Overview. The Executive Overview section and each site-specific section shall be submitted separately for approval of WMATA.

The Executive Overview section shall encompass all Train Control territory types including:

a) Descriptions of the field Train Control and SCADA monitored devices, operations and operating modes, and logic;

b) All Train run origination and termination locations; c) Train run trigger types necessary for all locations; d) The superset of data exchanged between the System and field Train Control systems (controls and

indications) and SCADA and their application in System functions.

Site specific sections of the IID shall include:

a) Description of the site including: • A graphical track and route infrastructure depiction of the location; • Involved control facilities: Tower(s), Terminals, yards, and train storage areas; • The type(s) of field Train Control system(s) and SCADA devices used at the location; • 3rd Rail section limits; • Tunnel Ventilation equipment and operation; • Any route restrictions; • Any uncharacteristic or special capabilities such as Train Order Signals and Intrusion Detectors;

b) Data descriptions of the existing signal design documents including: • Through Routes; • All controls and indications data ;

c) All ROCC software office logic and function dependencies including: • Descriptions of data received from field Train Control systems and how they are converted into

usable data in the ROCC software; • Data descriptions of all routes; • Descriptions of usage of indications in ROCC software functions; • Permissible and non-permissible states of indications and indication sequences.

Page 217


The Contractor shall not commence development of application software for ROCC software prior to having received approval of Interlocking Rules Document, Executive Overview section and at least one of each type of Site-Specific location selected by WMATA, unless approval to do so is specifically granted by WMATA.

11.1.3 System Description Document

The Contractor shall develop and furnish a customized System Description Document (SysDD), which contains a high-level definition of the ROCC software hardware, software, and firmware, and the functions performed by each.

The System Description Document shall serve as a complete introduction to the ROCC software and to the more specific hardware and software requirements and documents.

The SysDD shall fully describe the Contractor’s standard product and identify areas needing to be adapted for the System and the nature of the modifications.

Identification of each individual function of the ROCC software including all maintenance and diagnostics functions (in addition to operational functions) shall be documented as a functions list in the SysDD. Include a brief description of each function and any special/unusual attributes or deviations from Specification of the function shall be included in the functions list.

Include an overview of the hardware configuration showing all major hardware components shall be included in the SysDD. Provide block diagrams in sufficient detail to show the interrelationships of major hardware components and the elements that comprise them. Block diagram shall define interfaces to all communications facilities, and other systems. The configuration items shall be categorized as either standard (COTS) or non-standard (non-COTS) for the ROCC software in the SysDD.

Include a description of the major hardware components, the elements that comprise them, their interrelationships, and the functions they perform shall be included in the SysDD.

Describe major requirements imposed on the configuration such as system availability, processor utilization, spare auxiliary memory, and expansion capabilities.

An overview of the major software components (Software Configuration Items [SCI]) describing the software, the interrelationship of software within a component, the relationship between components, and hardware interfaces shall be provided in the SysDD. Include high-level software diagrams shall be included to enhance the reader’s understanding of the overall capability of the ROCC software, identifying all SCIs and relationships. Allocation of each SCI to major hardware components shall be defined in the SysDD.

A complete description of the software and the individual functions performed by each SCI shall beprovided in the SysDD. Significant features, concepts, and algorithms pertaining to each function shall be described with special emphasis on equipment, software, interfaces, and features unique to the ROCC software.

An overview of all external interfaces to the system shall be provided in the SysDD. Description of the graphical user interface (input, graphical, textural), existing data interfaces, and existing equipment interfaces shall be included in the SysDD. The overview shall include block diagrams and textural information sufficient to show the relationship of each element to the functionality of the system. A description of each external interface and the elements of each, which interface with the system, shall be provided in the SysDD. Included in the description shall be descriptions of any control, special handling, or limitations of the interface.

An operational overview shall be included describing the planned/intended operation and maintenance of the ROCC software. “Normal” and perturbated conditions and response objectives to perturbations shall be described.

The Contractor shall document system-wide design decisions, such as decisions about the ROCC software Concept of Operations and interface characteristics, and decisions effecting the selection and design of configuration items as part of the SysDD.

Page 218


11.1.4 Interface Control Documents

The Contractor shall develop and submit Interface Control Requirement Specifications (ICRS) for each interface identified in the Systems Integration Plan. The Contractor shall ensure the completeness and accuracy of each ICRS.

As a minimum, each ICRS shall include complete and accurate information for the interface as follows:

a) The project-unique identifier for the interface; b) Identification of all interfacing entities; c) Interface diagrams depicting interface with all interfacing entities; d) Dependent system states or modes; e) Each individual data element that will be provided, stored, sent, accessed, or received including:

• Name/identifier; • Data type; • Size and format; • Units of measurement; • Range of possible values; • Accuracy and precision; • Priority, timing, frequency and other constraints; • Security constraints; • Sources and recipients; • Data element assemblies (records, messages, files, arrays, displays, reports, etc.).

11.2 Hardware Documentation

Provide documentation that describes all aspects of the hardware design, selection, assembly, layout, installation, operation, maintenance and upgrading capabilities. All drawings shall follow WMATA drawings standards. The Contractor shall request these standards prior to starting any drawings.

11.2.1 Hardware Design Description

The Contractor’s process for hardware design, processor and device selection, testing, and modification shall be fully documented in a Hardware Design Description (HDD). The Contractor is required to furnish this submittal prior to giving WMATA with the required hardware list.

The HDD shall:

a) describe and detail the Contractor’s hardware design organization, b) describe and detail the analyses and decision criteria used by the Contractor’s design team for selecting

hardware for use in the ROCC software, c) describe and detail the methodology for design modification, hardware upgrade and change throughout

the development phases, d) describe and detail the hardware organization interfacing process with software, system assurance

(reliability, availability, maintainability and safety), and test organizations, e) provide a drawing list with descriptions of each planned drawing type and organization or groupings of

drawings.

11.2.2 Hardware Specifications

The Hardware Specifications will document the results of the analyses used to select the hardware for the ROCC software. Hardware Specifications, (CDRL T404), shall define the hardware configuration items (HWCI) from the highest level, beginning with the major hardware components defined in the SysDD, to the lowest hardware component level. The Hardware Specifications shall include block diagrams in sufficient detail to show the interrelationships of HWCIs at each level. Each HWCI shall be described relative to the ROCC software requirements that each performs.

Page 219


Hardware Specifications shall: a) describe and detail the product Specifications including identification and description of all products

and assemblies and catalog cut sheet Specifications of products and assemblies. Catalog cut sheets included as part of the Hardware Specifications shall identify the make and model numbers,

b) include utilization of all processors and data communications channels under normal and peak load conditions,

c) document the spare capacity, expansion capability built into the system and available via modular upgrade, and spare parts,

d) include all of the diagnostics and maintenance access provided for each type of hardware as well as the diagnostic tools furnished,

e) include subsystem electrical load calculations, f) include power-up sequencing procedures.

11.2.2.1 Hardware Inventory

The Contractor shall generate, submit, and maintain a Hardware Inventory List (CDRL T405). The Contractor shall maintain the Hardware Inventory List through final acceptance. A commercially available database management system shall be furnished and used to maintain this listing. The Hardware Inventory List shall include inventory of all hardware including the manufacturer’s name, model number, serial number, input power requirements, weight, and overall dimensions.

a) The Contractor shall be obligated to coordinate delivery and inspection of hardware as it is delivered to WMATA property.

b) The Contractor shall update the Hardware Inventory List as hardware is delivered.

The Hardware Inventory List shall identify all assemblies, sub-assemblies, components, and other hardware installed and. This shall also permit the identification of where the materials will be used, including each specific part, component, sub assembly etc. Cross-references to the numbers used in the illustrated parts catalog (e.g., Contractor/OEM to Authority and vice versa) shall be provided. All non-custom parts and components shall be identified with generic industry nomenclature in addition to any Contractor-assigned part numbers. In addition, each part listed on the Hardware Inventory List shall reference the drawing(s) that contain the part. Parts numbering shall be consistent on the Hardware Inventory List and the drawings.

a) The Hardware Inventory List shall include all hardware for implementation and deployment of the ROCC software including Remote Access, Parallel Development Environment.

b) Spare parts shall be specified in a separate list, the Rebuild & Recovery kit (CDRL T502).

11.2.3 Hardware Drawings

In addition to the Hardware Design Description and Hardware Specifications, the hardware design will be documented in a complete set of drawings including:

a) Hardware Configuration Block Diagrams b) Rack and Enclosure Assembly Drawings c) Hardware Test Configurations Drawings (including simulators) d) Component construction and installation details e) Interconnection cabling.

All drawings shall be developed in a progression from inception to final documentation, minimally including:

a) Preliminary drawings providing information commensurate with the stage of system design and development at the time of submission

b) Detailed drawings depicting the final design c) Assembly and enclosure drawings depicting the physical construction of hardware racks, enclosures,

and assemblies. d) Shop drawings consisting of marked-up as-assembled/as-installed drawings e) Final system As-Built documentation drawings.

Page 220


Each drawing shall be stamped in a manner subject to approval of WMATA with the category of drawing identified above (e.g., As-Built).

The lowest level diagrams for all hardware shall include wire numbering and connector mapping (i.e., pinouts).

Hardware drawings shall include interconnections to other systems.

Each distinct drawing set shall have an index sheet and symbol sheet.

11.2.4 Hardware Configuration Block Diagrams

Hardware Configuration Block Diagrams, (CDRL T406), shall be developed that depict the logical and physical arrangement of ROCC software equipment and their interconnections with ROCC software equipment and other systems. Logical configuration block diagrams and physical configuration diagrams shall be depicted in separate drawing types.

In addition to overall System Configuration Block Diagrams and Interconnection Diagrams, major subsystems shall be depicted separately.

At a minimum, separate block diagrams shall be developed for all block diagram types furnished in the Contract Drawings, and minimally the following:

a) Central LAN and data communication interfaces; b) Field and remote data communication interfaces; c) Video Display System; d) User workstations; e) FCUs; f) Servers, peripherals, and workstations for each of the Systems, including training; g) Prototyping System; h) Cableway layout; i) Site layout and installation drawings.

11.2.4.1 Rack and Enclosure Assembly Drawings

Rack and Enclosure Assembly Drawings (CDRL T407) shall be provided showing the construction of the enclosure, as well as the layout, mounting, and interconnection of all ROCC software devices within an enclosure, and cableways for cabling entering/exiting the enclosure.

Rack and Enclosure Assembly Drawings shall identify each component by part number and revision level. Each Rack and Enclosure Assembly Drawing shall include interconnection wiring diagrams showing all interconnecting cables including data, ground, and power distribution cables. An individual enclosure assembly drawing shall be produced for each enclosure (including equipment cabinets and consoles). Each Rack and Enclosure Assembly Drawings shall clearly identify the location and room covered by the drawing.

11.2.4.2 Hardware Test Configuration Drawings

A set of Hardware Test Configuration Drawings shall be developed that show the configurations used for testing the System including connection of any simulators and all external devices used in testing, as well connections of any and all diagnostic equipment. Hardware Test Configuration Drawings, (CDRL T408), shall be developed for each location where testing is performed.

11.2.5 Hardware Installation Design

The Hardware Installation Design (CDRL T409) shall include a description of the installation process, defining all installation sites, schedule and methods of installation. The Hardware Installation Design shall be developed as a complete package for each site in which ROCC software equipment is installed. The Hardware Installation Design shall provide the organizational name, department or division, and telephone number of a point of contact for questions regarding the installation.

Page 221


The Hardware Installation Design shall include: a) Indices, Symbol identification, construction notes and references; b) Layout plans of each location; c) Methods to provide security for installed equipment before use; d) Existing conditions, removals, and facility modifications; e) Work staging plan including site offices, site egress, material storage and security of stored material,

and work staging area; f) Planned construction machinery and equipment; g) Methods of securing construction sites; h) Methods of assuring against System disruptions i) Detailed layouts of all cabinets, System equipment, and cableways; j) Point to point cable tabulations including cable and wire types, sizes, tagging, and cableway fill; k) Mounting details, clearance requirements, and environmental restrictions; l) Distance restrictions between cabinets; m) Temporary and permanent electrical power supply requirements and distribution; n) Grounding plan; o) Applicable Specifications.

A set of signed, approved Shop Drawings shall be available at the site and equipment locations at all times and subject to Engineer inspection from commencement of installation until receipt and of approved Final Drawings. The Hardware Installation Design shall be developed in two parts: Preliminary Site Plans and Detailed Installation Designs and Drawings. Preliminary Site Plans shall include preliminary layouts of cabinet, console, and peripheral device locations and cable routing for all Contractor-provided equipment being installed. The Detailed Installation Designs and Drawings shall include final design documentation for the installation of all ROCC software equipment and interconnection cabling.

Cable and wiring terminations shall be shown on drawings, and all terminal markings, cable connector markings, and cable lengths shall be clearly indicated. Description of the isolation of cabling, wiring, racks and equipment shall be provided.

The Hardware Installation Design shall include a narrative describing all aspects of the installation including work staging, material delivery and storage, site and material security, work methods and code compliance, and the methods to ensure that the delivery and installation does not interfere with the operational system. The Hardware Installation Design shall include a description of how the Contractor will control noise levels, air particulates, construction hazards, and other disturbances during installation.

The Hardware Installation Design shall include a description of the type, source, and quantity of support materials needed for the installation. Include electrical and heat budgets of the System equipment for all locations.

11.2.5.1 Hardware Reference Manuals and Instruction Books

Hardware Reference Manuals and Instruction Books (CDRL T410) shall be provided by the Contractor for all hardware prior to the Test Readiness Review (TRR). Assume all WMATA provided equipment will come with manuals and reference books which the Contractor will take custody of and present back to WMATA in a complete submittal. Reference Manuals and Instruction Books shall include documentation relating hardware, including descriptions, Specifications, theory of operation, installation information, and manufacturing drawings (to the printed circuit board level).

11.3 Software Documentation

The Contractor shall provide documentation for all provided software. In addition to the Contractor’s standard and purchased documentation, documentation shall be furnished which is specifically tailored and configured for the various levels and skills of users intended to operate and maintain the system.

Page 222


11.3.1 Software Configuration Items List

A detailed inventory of all software configuration items shall be maintained by the Contractor in the Software Configuration Items List (CDRL T306) and provided to WMATA as part of each development phase, with a report of CI status provided every month in conjunction with Project Status Meetings.

11.3.2 Standard Software Documentation

The Contractor shall submit existing documentation and users manuals for standard software to WMATA for review and approval of WMATA, as part of the Standard Software Documentation (CDRL T307).

11.3.3 Software Design Documents

Software design documents shall be provided by the Contractor. Software design documents shall be provided for each software system and subsystem and shall encompass all system functions.

11.3.3.1 Software Architecture Design Document

The Contractor shall document the software architectural or high level design in a Software Architectural Design Document (SADD) for each software system and subsystem (CDRL T309). All alarm, advisory, status, informational, or event message shall be described in the Software Architectural Design Document, either as an appendix referenced to related component design descriptions or as a separate subsection within each component design section.

11.3.3.2 Software Detailed Design Document

The Contractor shall provide the Software Detailed Design Document (SDDD) for each software component identified in the SADD (CDRL T310). The structure and format of the SDDD shall be consistent with the SADD and shall allow direct traceability from the SADD component to the details in the SDDD.

11.3.4 Database Documentation

Database Design Documents (DBDD) shall be provided describing the structure of the system database both textually and graphically. The Contractor shall develop the DBDD first at a high level, referred to as High Level DBDD (CDRL T312.1) and then updated to support the software detailed design, the Detailed DBDD (CDRL T312.2). Portions of the database schema and data structures developed specifically for WMATA’s System shall be identified and described in the DBDD.

11.3.5 Database Administrator User Document

Database Administrator User Document (CDRL T313) shall be provided by the Contractor that instructs the user in the preparation of data to be loaded into the Databases.

The Database Administrator User Document shall describe:

a) The overall organization of input records b) The format of each data record, including definition of tables c) Each data field and the valid entries and/or numeric ranges pertaining to the data field d) Connections between tables (e.g. keys).

Sufficient database user documentation shall be provided to enable the updating, restructuring, or regeneration of the database when inputs are changed and added, and as programs are modified and new programs are added. If a database management system or a database access routine is utilized by the Contractor, the appropriate user documentation shall be supplied. If the Contractor uses COTS products for designing the database, the standard documentation for these products shall be provided, but only as a supplement to the full set of documentation to be provided by the Contractor.

Page 223


If the standard techniques for database definition and maintenance from these products are used with no changes, the standard descriptions of the methods directly used may be referred to in the Contractor’s documentation without repeating the information. The Contractor shall be responsible for ensuring that all database documentation provided meets the description of the databases.

11.3.6 System Administrator User Documentation

System documentation shall be provided by the Contractor to guide WMATA systems administration personnel in the operation and procedures required to update the system, including system software and firmware, database, application software, and other elements.

Provide System Administrator User Manuals. Configuration manuals shall be submitted as System Administrator User Manuals for the System Configuration (CDRL T314).

Each System Administrator User Manual shall be in conformance to IEEE 1063, Standard for Software User Documentation unless otherwise approved by WMATA. For descriptions of software maintenance activities, the System Administrator User Manual shall comply with IEEE Standard 1219, Standard for Software Maintenance or Engineer-approved equal.

The System Administrator User Manual shall:

a) define the processes and procedures for software code management, including a description of the software configuration management tool and related scripts and procedures.

b) define process and procedures for document management. c) define process and procedures for software CASE tools. d) define process and procedures for network communications management. e) define process and procedures for processor configuration. f) be provided for:

• system performance monitoring. • system restart, failover management and diagnostic procedures. • database generation and management. • display generation and management. • report generation and management. • diagnostic programs. • all simulators provided as part of the System. • all test tools provided as part of the System. • software utilities. • all Contractor-supplied system software not specifically required but necessary.

g) include all system generation and management procedures. h) define all software maintenance activities necessary for generation, modification, and test of the

system software, databases, and data.

The software maintenance activities shall comply with the software maintenance plans included as part of the Software Project Management Plan (CDRL T304).

The System Administrator User Manual shall describe the activities and criteria necessary for software maintenance including the following:

a) Identification and classification of problems and/or modifications b) Feasibility analysis and detailed modification analysis c) Design and documentation modification d) Database data modification e) Verification and validation f) Acceptance test g) Software configuration management h) Software quality assurance i) Risk Management

Page 224


j) Metrics to be collected.

The System Administrator User Manual shall include references to Engineer approved, Contractor-supplied system documentation for details of activities relevant to software maintenance activities. The references shall be provided for additional support of the procedures detailed in the manuals and shall not be accepted in fulfillment of any manual requirement. The System Administrator User Manual shall reference standard COTS manuals where applicable.

11.3.7 Display and Reports Documentation

All display and report documentation shall be presented populated with data accurately representative of the data expected in the Functional Requirements Definition.

11.3.7.1 Display Conventions and Design Guidelines Document

The Display Conventions and Guidelines Document is intended to ensure the consistency of System displays. The guidelines should provide direction to all aspects of display development such that the look and user interactions with displays are consistent across the entire spectrum of System displays and display types. Once approved, the Document should be used by Contractor’s personnel as a complete set of guidelines for building system displays and will be used after commissioning to modify displays and build new displays.

A Display Conventions and Guidelines Document (CDRL T201) shall be provided by the Contractor for the System. The Display Conventions and Guidelines Document shall describe how the Contractor intends to meet the graphical user interface requirements defined within these Specifications. The Contractor shall ensure consistency between the Display Conventions and Guidelines Document and the approved Prototypes. Any special conventions or guidelines required for presenting displays on the Video Display Walls shall be clearly described within the Display Conventions and Guidelines Document.

The Display Conventions and Guidelines Document shall:

a) describe the general format and usage conventions of the System displays. b) describe the specific human factors design guidelines to be followed for the System displays. c) describe the display conventions and guidelines to be followed on all System graphical and tabular

displays, as well as control menus and dialog formats. d) encompass displays developed as part of the applications, as well as any displays developed or part of

COTS products. e) describe the conventions and guidelines to be followed on all displayable and printable formats of

displays for the System. f) include at a minimum:

• Identification and description of all workstation GUI user interaction devices • Description of how the user will navigate through the various menus and displays • Description of default locations of windows and locations of user guidance messages • A description the windowing system • A description of how each type of menu system (pop-up, cascade, pull-down) will be applied • A description of how each of the following with be applied within the System:

a. Window frames

b. Toolbars

c. Check Boxes

d. Radio Buttons

e. Pulldown menus

f. Option Menus

Page 225


g. Scales

h. List Boxes

i. Pop-up Lists

j. Combination Boxes

k. Scroll Bars

l. Page and display navigation

g) A description of all keyboard commands, function keys, mouse operations, and accelerator keys used to open and close displays, and for data entry

h) A description of how the user will apply various navigation techniques, including the navigation window, zoom, pan, scroll, de-clutter

i) A definition of the default zoom level for each display type j) A description of how element highlighting will be used, including use of color, flashing, and inverse

video k) A definition of all graphical displays, tabular displays, dialogs, the configuration of each type of

display and their method(s) of invocation and closing including keyboard and mouse operations l) A definition of how text will be presented, including fonts to be used and character size m) A description of how colors will be used n) A description of how fields will be presented, including data entry fields, input and output fields and

labels o) A definition and location of user interaction “buttons” and poke points on displays and dialogs p) A definition of conventions for track layouts at default magnification including:

• Object size, shape, distances and relationship to other objects • Line weights and text size • Setting minimum track circuit length based on the size of the short train icon • Maintaining object relationships the same as those of field devices • Criteria for laying out the track map, including relational scaling, angles, horizontal spacing

between tracks, and interlocking limits per window frame q) An object library depicting all graphical objects, their various states and control menus.

11.3.7.2 Display Description Document

A Display Description Document (CDRL T202) shall be provided which illustrates and explains the design, usage, features and functionality of each workstation. Each display shall be illustrated in the Display Description Document by means of an accurate color display copy with annotations, illustrating as many of the display features, device states, and types of displayed information as possible. The Display Description Document shall define the display hierarchy, static and dynamic fields, and controllable and selectable items for each display.

11.3.7.3 Report Description Document

A Report Description Document (CDRL T203) shall be provided which illustrates and explains the design, usage, and features. Each report shall be illustrated by means of an accurate copy, which illustrates as many of the report features and types of reported information as possible.

11.4 Prototyping Documentation

Comprehensive documentation of the prototyping process, prototype system, and each prototype shall be provided to WMATA for review and approval. The prototyping documentation shall provide guidance in the use of the prototype and detailed descriptions of prototype elements to be reviewed and commented on by WMATA in each iteration of the prototype. All documents that have changed as a result of prototype iterations shall be updated and submitted with each iteration of the prototype, plus a final version after all Engineer comments have been incorporated into the final prototype iteration.

Page 226


11.4.1 Prototype Plan

The Contractor shall develop a detailed a Prototype Plan describing all aspects of the prototyping requirements.

The Prototype Plan shall be submitted within 60 days of NTP, and as necessary to ensure accuracy and completeness of prototyping activities, responsibilities, and schedule.

The Prototype Plan, (CDRL T512) shall include, but not be limited to:

a) Description and identification of all elements and functions to be prototyped b) Identification of the Contract requirements, as defined by this Specification, that each element and

function to be prototyped addresses c) The schedule for development and release of each element and function to be prototyped and prototype

cycles, as well as the time allocations for Engineer review and comment, prototype modification in response to comments by the Contractor, and Engineer re-review

d) Description of the prototype development methodology, including design and coding procedures and standards, documentation procedures and activities, review and modification procedures, and software development environment

e) Definition of the tools to be used in the development of prototypes, features and application of each tool

f) Hardware necessary to support development and execution of the prototype g) Description of the methodology and tools for comment collection, tracking, disposition, and

incorporation into the design h) Description of the configuration management for the prototypes i) Description of all prototype documentation for each stage of prototype activity.

The Contractor may deliver the Prototype Plan as an appendix to the Software Development Plan, but doing so will not relieve the Contractor of any requirements identified the Prototype Plan.

11.4.2 Prototype Users Manual

The Contractor shall provide a detailed Prototype Users Manual (CDRL T513) defining the usage and maintenance of the prototypes and Prototyping System. The Prototype Users Manual shall be prepared and submitted for Engineer approval at least two weeks prior to the delivery of the Prototyping System. The Prototype Users Manual shall describe in detail, as a minimum, administration of the Prototyping System, procedures for usage including startup, login, failure handling, and all features of each prototype, maintenance procedures, and procedures for generation of the Prototyping System software and prototypes.

11.4.3 Prototype Version Description Document

The Contractor shall deliver a Prototype Version Description Document (PVDD) (CDRL T514) with each iteration of prototype provided to WMATA. The PVDD shall describe the prototype version, applicable Prototype Description Documents, WMATA prototype comments addressed in this version, and disposition of each addressed comment. Where revisions to the prototype are made prior to the next iteration or subsequent to the last iteration and delivered to WMATA for comment (referred to as interim releases), an addendum to the PVDD outlining the changes shall be prepared and submitted to WMATA. The PVDD addendum shall be delivered no later than 10 working days from the date of the revision.

11.4.4 Display and Report Prototype Description Document

The Contractor shall provide a Display and Report Prototype Description Document (CDRL T515) with each iteration of the Display and Report Prototype.

The Display and Report Prototype Description Document shall provide the following:

a) Detailed description of each S/D prototype, including, but not limited to: its purpose/usage, invocation, data entry fields and controls, and any other pertinent information

Page 227


b) The specific aspects of each display and report that WMATA is to provide comments on as well as those not to comment on

c) The Contract requirements that each display and report addresses.

11.4.5 Function Prototype Description Document

The Contractor shall provide a Function Prototype Description Document (CDRL T516) with each iteration of the Function Prototype.

The Function Prototype Description Document shall provide the following:

a) A detailed description of the operation of each I/F prototype b) The Contractor’s objectives for each function c) The specific aspects that WMATA is to provide comments on as well as those not to comment on d) The Contract requirements the prototype addresses.

11.5 Test Documentation

The Contractor shall provide test documentation in a timely manner and as specified in the Test and Commissioning section of the contract.

11.6 Reliability, Availability, Maintainability Documentation

All RAM documentation shall follow the requirements set forth in Section 6.05 – Reliability, Availability, and Maintainability.

Provide the following:

a) Reliability and Maintainability Program documentation. b) Reliability Calculations c) Availability Analyses d) Availability and Reliability Assurance documentation e) Maintainability Demonstration Test documentation

11.7 Final AS-Built Documentation

Final AS-Built Documentation (CDRL T102) shall be provided and delivered on electronic media in Microsoft Word, Excel, and PowerPoint, or an Engineer approved word processing, spreadsheet, and graphic processing tool that is commercially available. Final documentation shall conform to WMATA’s Safety and Security Certification Program requirements and other requirements as needed. Provide hard copies of all documents.

Final Documentation shall consist of all development documentation updated to include all changes made to the System up until final acceptance by WMATA (referred to as ‘As-Built’ versions). Documentation revisions or changes necessitated by inaccuracies, installation requirements, omissions determined by usage, and design or production alterations to system shall be supplied as part of the Final Documentation.

All changes shall be issued in the form of replacements for the affected drawings, diagrams, charts, graphs, tables, lists, and entire pages in the various documentation, as part of the Final Documentation. Where directed by WMATA, the complete document shall be re-issued.

All final Contractor-supplied documentation shall be easily reproducible. All documents or drawings larger than B-size (11” x 17”) shall be supplied as reproducible drawings in addition to the required paper copies.

In addition to hardcopies, all text documentation prepared specifically shall be furnished, as part of the Final Documentation, on computer-readable portable editable media using system tools.

All document formats shall be submitted to WMATA for approval. An index for all system documentation shall be included as part of the Final Documentation.

Page 228


11.8 ROCC Software User Manual

A ROCC Software User’s Manual (CDRL T511) shall be provided that contains detailed operating instructions and procedures. The Manual shall include a description of the operation of the system (hardware and software) as it relates to each user’s tasks. The Manual shall be customized for WMATA and shall be based on the delivered system. It will not be acceptable to describe the Contractor’s standard system and then identify differences between the standard and delivered system. The Manual shall only include those standard descriptions that apply to the delivered system.

The User’s Manual shall:

a) describe each function and how it is to be used. b) be written for use by control center personnel and not be written as a programmer’s document. c) include a copy of each type of user display used in the system along with a description of each

dynamic data field. d) describe procedures to be followed as a result of computer system restarts, failures, and failovers. e) have sufficient information to guide the User through starting and configuring the system, initiating

diagnostics, and interpret diagnostic and error output. f) have procedures shall be explained step-by-step with an explanation of how each step is performed,

which parameters can be adjusted, and the effects obtained by varying each parameter.

All user guidance and error messages shall be described in the Manual, along with the steps necessary to recover from errors. Each system function of this Specification and all other functions designed for users shall be included in the Manual. User instructions for all operator interactive procedures associated with the data fields on each display shall be provided for each display associated with the system functions. This information may be derived from the Display Description Document.

11.9 Document Quantities

The Contractor shall submit ten hard copies of each submittal.

At the request of WMATA, two additional hard copies of each submittal shall be delivered to WMATA’s Consultant, or other party designated by WMATA.

The Contractor shall submit five electronic copies of each submittal on Engineer-approved portable media, in Engineer-approved electronic file format(s).

At the request of WMATA, one additional electronic copy of each submittal shall be delivered to WMATA’s Consultant, or other party designated by WMATA.

Page 229


12. APPENDIX

12.1 DEFINITIONS & ABBREVIAIONS

ACI Automatic Car Identification

Adam 4572 Converts TCP to RS 485

AEMS Automatic Energy Management System

AIM Advanced Information Management – the ARINC provided train control software

AIM PIDS Client PIDS processes

BDN Business Data Network

BOCC Bus Operations Central Control

CB-EMIS/PROTECT Computer Based – Emergency Management Information System

COOP CTF Remote Operations

Customer Operations: & other LightLink 3.0 Worstations (ADA, Delay/disruption,

emergency messages) running LightLink 3 Client, with Message Editor, System

Manager

CTF Carmen Turner Facility – 3500 Pennsy Drive, Landover, Maryland

CTS/FON Carrier Transmission System/Fiber Optic Network

DarkSign Adds PIDS train arrival info to ROCS LiveMap (no ADA or delay info)

DarkSign System To ROCStechs, MOC & TSSM/COMM use DarkSign via Intranet to monitor PIDS

DCE Digital Communications Equipment

DRAC Allows web access to SCU power on/off reset & more

DTS Data Transmission System

CTS/DTS Carrier Transmission System/Data Transmission System

F&I Sensors/ADT Fire & Intrusion

FEP Front End Processor

GOTRS General Order and Track Right Authorization System

JERCS Jackson Graham Building Embedded RTU Communications Server

JGB Jackson Graham Building – 600 5th Street, NW Washington, DC

LightLink Manufacture of the software for the Passenger Information Systems

LSD Displays GMGR, DGMR, 506

Maximo Material & Maintenance Management System

MERCS Modbus Embedded RTU Communications Server

Metro Synonymous with WMATA

MOC Maintenance Operations Control

MSRPH Metrorail Safety Rules and Procedures Handbook (Operating Rules)

Netgate Server PIDS display status

OAP Operations Administrative Procedures

Definitions and Abbreviations – Continued

Page 230


OAS Outgoing Assistant Superintendent

OracleRECAP Report Description

Rail Events Chronological Activity Program

Status & control variables in historical data, used to analyze incidents such as station

over-runs

PET Programming, Engineering, and Test

PIDS Sniffer DB & web service

Adds PIDS train arrival info to ROCS LiveMap (no ADA or delay info)

PIDS on PDA

Pilot PIDS via LCS display

Dark Sign

PIDS.exe Interfaces AIM data to LightLink 3.0 Server

RAS Remote Access Server – sends messages, train arrival info, returns display status

RDDS Report Description

Display of train movement by line

ROCC RAIL Operations Control Center

ROCS Rail Operations Control System

ROCS LiveMap Yard Operators use ROCS LiveMap with Operator ID * consist mouse-over via

Intranet for dispatch

ROCS LiveMap w/ PIDS Station Mangers use ROCS LiveMap with PIDS via Intranet to monitor train

movement

RPM Rail Performance Monitor

SCU Station Control Unit – Dell PowerEdge 2650 running LightLink 3.0 Output Manager

with a DRAC board

SMB Sign Monitoring Board

Monitors & controls SMBs via RS-485 from SMC

Installed on each display/backplate power cable in each cabinet, monitors current to

display/backplate, sends error message to SMC if display is dark for more than 10

minutes

SMC Sign Monitoring & Control Unit with Adam 4055 – Installed in each PIDS cabinet,

monitors SMBs, DarkSign communications errors, sends error messages to

DarkSign, enables power recycle for each SMB and both display/backplates in PIDS

cabinet

SPOTS Report Description

Schedule Performance On-time System shows train ID, destination code,

enter/dwell/leave station, door open/close

Definitions and Abbreviations – Continued

Page 231


Squiggly Report Report Description

Real-time display of Rail schedule & performance

Status Report Data Source

Detailed bits from field (door open/closed, enter station/leave station, track circuit

occupied, breaker status, fire/intrusion alarms, etc.) & historical data

TCMT Track Circuit Monitor Tool – Report Description – Detects field equipment failures

potentially caused by loss of shunt

Trapeze Bus & Rail Scheduling & Dispatch System

TT Report Data Source

Train Table: Train ID, location, length (from TWC at ATO start, no update from

TWC,) consist (from RPM, not TWC.)

TWC Train to Wayside Communications

TWC Tool Report Description

Train status, location on platform, door open/closed, etc.

WMATA Washington Metropolitan Area Transit Authority

Page 232


12.2 Contract Data Requirements List (CDRL)

The following list identifies the data items required to be prepared and submitted by the Contractor during the CTC development. This list is referred to as the Contract Data Requirements List (CDRL). Should a conflict arise between the timeframes identified within the CDRL and other sections of this Specification, the CDRL timeframe is to be used, unless otherwise directed by WMATA. All days are working days

Project Data

CDRL No. TITLE Spec. Ref. Timeframe For Initial Submittal

and Key Resubmission 1. T101 Agenda 3.4.5 Meeting +5 2. T102 Project Management Plan 3.4 NTP+60 3. T103 DB Project Manager 3.4.11.3 NTP+10 4. T104 Concept of Operations ConOps 3.5 CDR, PDR, FDR 5. T105 Functional Requirements Definition

(FRD) 3.5 CDR, SSR, PDR, FDR, TRR

6. T106 Safety and Security Certification Program (SSCP)

3.6 CDR

7. T107 Hazard Analysis 3.6 CDR 8. T108 Quality Program 3.7.1 NTP+30 9. T109 Software Quality Assurance

Program 3.7.2 NTP+30

10. T110 Systems Integration Plan 3.8.1 CDR 11. T111 Implementation Plan 3.9 PDR, FDR 12. T112 Project Documentation Program 3.10 NTP+90 13. T113 Configuration Management

Program 3.11 CDR

14. T114 System Architecture 4.1 CDR, PDR, FDR 15. T115 Risk Management Program 3.12 NTP+90 16. T116 Vulnerability Metrix 3.13.2.1 CDR 17. T117 Project Schedule 3.14.1 NTP+30 18. T118 Test Schedule 3.14.5 F 19. T119 Action Item List 3.4.4

Page 233


Milestone Data CDRL

No. TITLE Spec. Ref. Timeframe For Initial Submittal and Key Resubmission

20. T151 Conceptual Design Review (CDR) Milestone Review Package

3.17 Two weeks prior to CDR CDR = NTP +120

21. T152 System Requirements Review (SRR) Milestone Review Package

3.14.3 Two weeks prior to SRR SRR = CDR +30

22. T153 Preliminary Design Review (PDR) Milestone Review Package

3.14.3 Two weeks prior to PDR PDR = SRR +60

23. T154 Final Design Review (FDR) Milestone Review Package

3.14.3 Two weeks prior to FDR FDR = PDR +60

24. T155 Test Readiness Review (TRR) Milestone Review Package

3.14.3 Two weeks prior to TRR TRR = FDR +90

User Interface

CDRL No. TITLE Spec. Ref. Development Phase For Initial

Submittal and Key Resubmission 25. T201 Display Conventions and

Guidelines Document 4.7 CDR

26. T202 Display Description Document 11.3.7.2 FDR 27. T203 Report Description Document 11.3.7.3 FDR

Software

CDRL No. TITLE Spec. Ref. Timeframe For Initial Submittal

and Key Resubmission 28. T301.1 Software Verification and

Validation Plan (SVVP) 8.2.5 CDR

29. T304 Software Project Management Plan (SPMP)

11.3.6 CDR

30. T305 Software Development Plan (SDP) 4.10.1.1.2 CDR 31. T306 Configuration Items List 11.3.1 32. T307 Standard Software Documentation 11.3.2 PDR, FDR 33. T308 Software Requirements

Specification (SRS) 4.3.1 SRR

34. T309 Software Architectural Design Document (SADD)

4.3.1 PDR

35. T310 Software Detailed Design Document (SDDD)

7.3.16.2 FDR

36. T312.1 High Level Database Design Document (DBDD)

11.3.4 PDR

37. T312.2 Detailed DBDD 11.3.4 FDR 38. T313 Database Administrator User

Document 11.3.5 60 days prior to FAT

39. T314 Programmer/System Administrator User Manuals

11.3.6 PDR

40. T315 Certifiable Items List 3.6.2

Page 234


Hardware


Submittal and Key Resubmission 41. T403 Hardware Design Description 5.3 CDR 42. T404 Hardware Specification 5.3 SRR, PDR, FDR 43. T405 Hardware Inventory List 5.3 PDR, FDR, TRR, completion of

FAT and Site Acceptance Tests 44. T406 Hardware Configuration Block

Diagrams 5.3 SRR, PDR, FDR, TRR

45. T407 Rack and Enclosure Assembly Drawings

5.3 PDR, FDR

46. T408 Hardware Test Configuration Drawings

5.3 PDR, FDR

47. T409 Hardware Installation Design 5.3 SRR, PDR, FDR 48. T410 Hardware Reference Manuals and

Instruction Books 11.2.5.1 TRR

49. T411 Maintenance Manuals 10.8 TRR 50. T412 Diagnostic Program User’s

Manuals 4.11.1.1.1 TRR

System Level


Submittal and Key Resubmission 51. T501 Maintenance Plan 9.4.1 FDR 52. T502 Rebuild & Recovery Kit 9.5.1 FDR, 60 days prior to the start of

FAT 53. T503 System Description Document

(SysDD) 7.3.1 CDR

54. T504 Interlocking Rules Documentation 4.11.1.1.2 CDR 55. T511 ROCC User’s Manual 11.8 TRR 56. T512 Prototype Plan 11.4.1 CDR 57. T513 Prototype Users Manual 11.4.2 CDR 58. T514 Prototype Version Description

Document 11.4.3 With each iteration of the prototype

59. T515 Display and Report Prototype Description Document

11.4.4 CDR, SRR for 2nd and 3rd iterations

60. T516 Function Prototype Description Document

11.4.5 CDR, SRR for 2nd and 3rd iterations

61. T517 Hardware and Function Simulation Methodology Plan (HFSMP)

8.2.5 SRR, PDR, FDR.

System Assurance


Submittal and Key Resubmission 62. T601 Master Test Plan 8.1 63. T601.1 Factory Acceptance Test (FAT)

Plan 8.2 SRR

Page 235



Submittal and Key Resubmission 64. T601.2 Factory Acceptance Test (FAT)

Test Procedures 8.2 FDR

65. T601.3 Factory Acceptance Test (FAT) Results

8.2 Within 6 weeks of completion of FAT

66. T601.4 Certification of Pre-FAT 8.2.1 At completion of Pre-FAT, one week prior to the start of FAT

67. T602 CTC Pre-Site Test Maintenance Records

8.3 After FAT, prior to start of Site Tests

68. T603.1 Site Installation Test Plan 8.3 SRR 69. T603.2 Site Installation Test Procedures 8.3 FDR 70. T603.3 Site Installation Test Results 8.3 Within 6 weeks of completion of

test 71. T604.1 Site Performance Test Plan 8.3 SRR 72. T604.2 Site Performance Test Procedures 8.3 FDR 73. T604.3 Site Performance Test Results 8.3 Within 6 weeks of completion of

test 74. T605.1 Site Integrated System Test Plan 8.3 SRR 75. T605.2 Site Integrated System Test

Procedures 8.3 FDR

76. T605.3 Site Integrated System Test Results 8.3 Within 6 weeks of completion of test

77. T606 Transition Plan 8.1.3 CDR, SRR 78. T607 Availability Analysis 8.5.4 CDR, SRR, PDR, FDR, TRR, final

6 weeks before Transition Phase I 79. T608 Reliability, Availability, and

Maintainability Program Plan (RAMPP)

8.5.5 CDR, PDR and FDR

80. T609 Reliability Calculations 8.5.6 CDR, SRR, PDR, FDR, TRR, FAT completion, final 6 weeks before Transition Phase I

81. T610.1 Availability and Reliability Demonstration Test Plan

8.1.6 PDR, FDR NOTE: RAY TO ADD.

82. T610.2 Availability and Reliability Demonstration Test Assessment Report

8.1.6.2 Within 2 weeks of verification completion

83. T622 System Response Timing Analysis 9.2.1 SRR, PDR, FDR, TRR, finalized within 20 days of the successful completion of Site Testing.

84. T623 Cyber Security Program Plan 3.13

Training


Submittal and Key Resubmission 85. T701 Master Training Plan 10.6.1 CDR, PDR 86. T701.1 Training Schedule 10.5 CDR, SRR, PDR, FDR, TRR, SIT

Page 236



Submittal and Key Resubmission 87. T703 Training Materials 10.6 FDR, updated for each training

seminar and course, submitted 30 days before each seminar and course

88. T703.1 Participant’s Guides 10.6.2 Prior to the CDR milestone 89. T703.2 Instructor’s Guides 10.6.1 60 days prior to the Management

Seminar 90. T704 Video Recordings 10.1 30 days after completion of training

course

Page 237