CHART Logocoordinated Highways Action Response Team

state highway administration

 

 

 

 

 

 

 


CHART II System Requirements

 

 

 

 

 

 

Contract DBM-9713-NMS

TSR # 9901961

Document # M361-RS-002R2

 

 

 

 

May 5, 2000

By

Computer Sciences Corporation and PB Farradyne Inc

 

CSC Logo
 


 


Revision

Description

Pages Affected

Date

0

Initial Release – R1B2 Baseline

ALL

February 25, 2000

1

Signature Copy – R1B2 Baseline

See Appendix B for changes affecting the R1B2 Baseline requirements

March 24, 2000

2

Signature Copy – full system

See Appendix B for changes from Revision 1

May 5, 2000

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

 

Contents

 

1 Introduction.................................................................................... 1

2 Reference...................................................................................... 1

3 Requirements................................................................................. 2

3.1 System Administration, Configuration, and Operation........................ 3

3.2 Device Management..................................................................... 22

3.3 Display Management.................................................................... 38

3.4 Message Management................................................................. 46

3.5 Plans.......................................................................................... 54

3.6 Traffic and Roadway Monitoring..................................................... 57

3.7 Activity Management.................................................................... 60

3.8 Web........................................................................................... 77

3.9 System Maintainability and Availability........................................... 79

3.10 Simulation................................................................................. 80

Appendix A - Initial R1B1 to CHART II Requirements Matrix............. 1

Appendix B – Document Update History........................................... 1

Appendix B.1 – M361-RS-002R1......................................................... 1

Appendix B.2 – M361-RS-002R2......................................................... 5

Acronyms.......................................................................................... 1

Glossary............................................................................................ 2

 


 

1 Introduction

 

The CHART II System Requirements Specification has been developed based on the requirements for the CHART Release 1Build 1 (R1B1) initial system (see DOORS module R1B1 and Appendix A of this document) and the CHART II Business Area Architecture Report.  This document presents the full CHART II system requirements and supercedes the R1B1 requirements.  The R1B1 initial system is to be replaced by a CHART II system meeting the requirements described in this document.  Until such time that a release of the CHART II system replaces capabilities or functionality described by an R1B1 requirement the R1B1 requirement is considered in effect.  Traceability from the R1B1 requirements to the CHART II System Requirements is provided through the DOORS requirements management tool.  Appendices to this document present tables listing the R1B1 initial system requirements and mappings to the CHART II requirements.

 

2 Reference

Reference materials supporting the specification or derivation of requirements are listed below.

 

1) Letter dated September 1, 1998, from Mike Zezeski, CHART Program Manager, to Ben Gianni, Operations Director, CSC, Sub: Request for Time and Cost Proposal.

 

2) Telecommunications Service Request (TSR) 9901961 dated September 14, 1998.

 

3) CHART II Process Design Meeting Minutes for work session on April 15, 1999, April 22, 1999.

 

4) CHART II Process Design Meeting Minutes for work session on April 29, 1999, May 3, 1999.

 

5) CHART II Process Design Meeting Minutes for work session on May 13, 1999.

 

6) Functional Specification for the FP9500ND-MDDOT Display, A316111-080, June 16, 1998, Revision: A6.

 

7) Maintenance Manual For The FP1001 Display Controller, 316000-443, January 30, 1987, Revision: E.

 

8) Application Guide  For The FP2001 Display Controller, A317875-012, May 14, 1991Revision:  8.

 

9) National Transportation Communications for ITS Protocol (NTCIP) GUIDE(Draft), Prepared by The NTCIP Joint Standards Committee, March 3, 1997.

 

10) The Windows Interface Guidelines for Software Design, Copyright © 1995 by Microsoft Corporation.

 

11) The CHART II Requirements Prototype.

 

12) CHART II Business Area Architecture/Accelerated Business Area Architecture Principles, Constraints, and Assumptions Workshop Minutes on March 19, 1999, March 31, 1999.

 

13) CHART II Business Area Architecture Report, April 30, 2000, M361-BA-005.


 

3 Requirements

The requirements specification has been divided into nine major sections to logically group requirements.  The sections are:

 

System Administration, Configuration, and Operations

Device Management

Display Management

Message Management

Plans

Traffic and Roadway Monitoring

Activity Management

Web

Reliability, Maintainability, Availability

Simulation

 

 

The tables that follow consist of four columns.  The first column contains the requirements organized in sections for ease of reading.  The second and third columns are the system release and build to which the requirement has been allocated.  The fourth column is the unique object identifier for the requirement.  When requirements are added the section headings for existing requirements may change however the object identifiers will not.

 

 


 

CHART System Requirements

Rel

Bld

Object Id

3.1 System Administration, Configuration, and Operation

This section lists requirements for the administration, configuration, and operation of the CHART II system.

 

 

 

5

 

3.1.1 Administration

The system will rely on underlying network, operating system and physical access controls for basic security.  CHART II system specific access control and system administration requirements are listed in this section.

 

 

 

6

 

3.1.1.1 The system shall provide a mechanism to define and enforce user functional rights.

 

1

 

1

 

7

 

3.1.1.1.1 The system shall support the grouping of user functional rights into roles.

 

1

 

1

 

359

 

3.1.1.1.1.1 There shall be at least one user of the system, with the role of administrator, who shall have full system functional rights.

 

1

 

1

 

8

 

3.1.1.1.1.2 The system shall allow an administrator to modify the functional rights of a role.

 

1

 

1

 

14

 

3.1.1.1.1.3 There shall be a role/Center for users belonging to the media.

 

 

 

967

 

3.1.1.1.1.3.1 The media role/Center shall filter out National Weather Service alerts.

 

 

 

968

 

3.1.1.1.1.3.2 The media role/Center shall have limited access to Incident information.

 

 

 

969

 

3.1.1.1.2 The system shall support the assignment of roles to users.

 

1

 

1

 

9

 

3.1.1.2 The system shall require a user to provide a userid and password in order to login.

 

1

 

1

 

10

 

3.1.1.2.1 The system shall disable a user's account after three consecutive failed login attempts.

 

 

 

374

 

3.1.1.2.2 The system shall not exceed 15 seconds to complete the user login function to the point where the system is ready to accept commands from the user.

 

1

 

1

 

21

 

3.1.1.3 The system shall allow a user to logoff.

 

1

 

1

 

11

 

3.1.1.3.1 The system shall not exceed 15 seconds to complete the user logout function.

 

1

 

1

 

22

 

3.1.1.3.2 The system shall not exceed 3 seconds after initiation of the user logout function to notify the user of any conditions that prohibit the completion of the logout function.

 

1

 

1

 

23

 

3.1.1.4 The system shall allow an administrator to create a new user account.

 

1

 

1

 

12

 

3.1.1.5 The system shall allow an administrator to delete a user account.

 

1

 

1

 

13

 

3.1.1.6 The system shall support the definition of Centers.

 

1

 

1

 

361

 

3.1.1.6.1 A Center shall have a name.

 

1

 

1

 

369

 

3.1.1.6.2 A Center shall have a location.

 

 

 

370

 

3.1.1.6.3 A Center shall have a defined geographical area of responsibility.

 

 

 

362

 

3.1.1.6.3.1 The geographical area of responsibility shall define the area from which the Center is to receive alerts.

 

 

 

368

 

3.1.1.6.3.2 The system shall support the definition of geographical area of responsibility for specific types of alerts from specific types of devices.

 

 

 

372

 

3.1.1.6.4 A Center shall have a defined set of functional responsibilities.

 

 

 

363

 

3.1.1.6.4.1 A Center's functional responsibilities shall include the functions that Center is allowed to perform.

 

 

 

365

 

3.1.1.6.4.2 A Center's functional responsibilities shall include the types of alerts that Center is to receive.

 

 

 

366

 

3.1.1.6.5 A Center shall have a hierarchical relationship with other Centers for the purpose of establishing a path for alert escalation.

 

 

 

364

 

3.1.1.6.5.1 An alert shall be passed up to the next Center in the heirarchy if the Center that currently has the alert does not respond in a specified amount of time.

 

 

 

371

 

3.1.1.6.6 The system shall assign an operations center to a user upon login.

 

1

 

1

 

15

 

3.1.1.6.6.1 The assigned operations center shall be the logical site of the workstation where the user logged into the GUI.

 

1

 

1

 

16

 

3.1.1.7 The system shall not allow the last user logged in to a Center to logoff while that Center has control of resources.

 

1

 

1

 

402

 

3.1.1.7.1 The system shall not allow the last user logged in to a Center to logoff while that Center has an open event assigned to it.

 

1

 

2

 

17

 

3.1.1.7.2 The system shall not allow a user to logoff while that user is in control of a camera.

 

 

 

384

 

3.1.1.8 The system shall provide a change user dialog that allows a new user to logon and an old user to logoff at the same Center in a single operation.

 

1

 

1

 

18

 

3.1.1.8.1 The change user function shall transfer the old user's responsibilities to the new user before logging off the old user.

 

1

 

1

 

19

 

3.1.1.8.2 The system shall not exceed 15 seconds to complete the change user function.

 

1

 

1

 

20

 

3.1.1.9 The system shall not exceed 3 seconds to notify the user that they lack the appropriate functional rights to perform an operation.

 

1

 

1

 

24

 

3.1.2 System Operations

This section lists requirements for the operation of the system.  Requirements listed here are general requirements for the system as a whole.  Requirements specific to one part of the system will be found in their respective sections.

 

 

 

25

 

3.1.2.1 The system shall provide an online Center notepad supporting the freeform entry of text.

 

 

 

373

 

3.1.2.1.1 A sufficiently privileged user shall be able to enter information into the Center notepad.

 

 

 

376

 

3.1.2.1.2 The Center notepad shall be viewable by any user logged into the Center.

 

 

 

377

 

3.1.2.2 The system shall provide an online operator notepad supporting the freeform entry of text.

 

 

 

375

 

3.1.2.2.1 A sufficiently privileged user shall be able to enter information into a personal operator's notepad.

 

 

 

378

 

3.1.2.2.2 An operator notepad shall be accessible only by the user that created it.

 

 

 

379

 

3.1.2.2.3 A user shall be able to use their operator notepad from any Center they log into.

 

 

 

380

 

3.1.2.3 The system shall provide a chat function to allow users to communicate interactively over the network.

 

 

 

381

 

3.1.2.4 The system shall provide the capability to define and maintain link information.

 

 

 

387

 

3.1.2.5 The system shall support the definition and maintenance of electronic versions of FITM plans.

 

 

 

389

 

3.1.2.6 The system shall provide a system monitoring function.

 

 

 

404

 

3.1.2.6.1 The system shall monitor the status of CHART servers.

 

 

 

405

 

3.1.2.6.2 The system shall monitor the status of CHART clients.

 

 

 

406

 

3.1.2.6.3 The system shall monitor the status of CHART software components.

 

 

 

407

 

3.1.2.6.4 The system shall monitor the status of CHART communications links.

 

 

 

408

 

3.1.2.6.5 The system shall monitor the status of CHART legacy systems.

 

 

 

409

 

3.1.2.6.6 The system shall provide the capability to automatically restart selected processes when they go down.

 

 

 

1067

 

3.1.2.7 The system shall not exceed 5 seconds to notify the user through the use of an appropriate cursor change (hourglass or watch) that the system is processing a command whenever completion of the command is not immediate.

 

1

 

1

 

26

 

3.1.2.8 The system shall return control to the user after the initiation of a command in a window such that the user is not prevented from performing activities in other windows on the desktop.

 

1

 

1

 

27

 

3.1.2.9 The system shall not exceed 5 seconds to provide the initiating user with a list of all operations centers with logged in users.

 

1

 

1

 

28

 

3.1.2.10 The system shall provide an on-line Help function.

 

1

 

2

 

29

 

3.1.2.11 The system shall provide the capability to automatically notify individuals of specific system events.

 

 

 

445

 

3.1.2.11.1 The system shall support the notification of individuals by FAX.

 

 

 

446

 

3.1.2.11.1.1 The system shall support the sending of at least four simultaneous FAXes.

 

 

 

1033

 

3.1.2.11.1.2 The FAX capability shall support distribution lists.

 

 

 

1037

 

3.1.2.11.2 The system shall support the notification of individuals by email.

 

 

 

447

 

3.1.2.11.2.1 The email package shall support distribution lists.

 

 

 

1034

 

3.1.2.11.3 The system shall support the notification of individuals by paging.

 

 

 

448

 

3.1.2.11.3.1 The paging capability shall support paging through multiple service providers.

 

 

 

1035

 

3.1.2.11.3.2 The paging capability shall support groups.

 

 

 

1036

 

3.1.2.11.3.3 The system shall support the sending of at least four simultaneous pages.

 

 

 

1038

 

3.1.2.11.3.4 The paging capability shall not be limited by the number paging service subscribers.

 

 

 

1039

 

3.1.2.11.4 The system shall support the management of distribution lists of individuals for notification.

 

 

 

449

 

3.1.2.11.5 The system shall provide the capability to specify the notification method(s) on an individual basis.

 

 

 

450

 

3.1.2.11.6 The system shall provide the capability to associate system events with lists of individuals to receive notification of those events.

 

 

 

451

 

3.1.2.11.7 The system shall record individual level notification events in the Operations log.

 

 

 

453

 

3.1.2.12 The system shall maintain a system operations log.

 

1

 

1

 

247

 

3.1.2.12.1 The system shall have the capability to store at least 14 days of operations log entries in the online system.

 

1

 

1

 

479

 

3.1.2.12.2 All operations log information shall be retained in an offline searchable archival form.

 

 

 

480

 

3.1.2.12.3 The system shall provide the capability to view operations logs.

 

 

 

481

 

3.1.2.12.3.1 The system shall provide a search capability allowing a user to search for a specific operations log entry.

 

 

 

482

 

3.1.2.12.3.2 The system shall provide a filtering capability to allow a user to select a specified set of operations log entries.

 

 

 

483

 

3.1.2.12.4 The system shall store identifying information with each operations log entry.

 

1

 

1

 

469

 

3.1.2.12.4.1 The system shall store the Date/time the operation was performed with each operations log message.

 

1

 

1

 

470

 

3.1.2.12.4.2 The system shall store the Workstation Identifier (if applicable) with each operations log message.

 

1

 

1

 

471

 

3.1.2.12.4.3 The system shall store a searchable category type identifying the type of entry with each operations log message.

 

1

 

1

 

472

 

3.1.2.12.4.4 The system shall store the User name of initiating user, or the identifier of the initiating application if system generated, with each operations log message.

 

1

 

1

 

473

 

3.1.2.12.4.5 The system shall store the associated Center with each operations log message.

 

 

 

474

 

3.1.2.12.4.6 The system shall store the Textual description of action taken with each operations log message.

 

1

 

1

 

475

 

3.1.2.13 The system shall log messages generated from operations activities.

 

1

 

1

 

274

 

3.1.2.13.1 The system shall log a message for User login.

 

1

 

1

 

275

 

3.1.2.13.2 The system shall log a message for Failed user login attempts.

 

1

 

1

 

276

 

3.1.2.13.3 The system shall log a message for User logout.

 

1

 

1

 

277

 

3.1.2.13.4 The system shall log a message for Adding users.

 

1

 

1

 

278

 

3.1.2.13.5 The system shall log a message for Modifying users.

 

1

 

1

 

279

 

3.1.2.13.6 The system shall log a message for Deleting users.

 

1

 

1

 

280

 

3.1.2.14 The system shall log operations messages associated with the monitoring of system status.

 

 

 

410

 

3.1.2.14.1 The system shall log a message for server status change.

 

 

 

425

 

3.1.2.14.2 The system shall log a message for client status change.

 

 

 

426

 

3.1.2.14.3 The system shall log a message for software component status change.

 

 

 

427

 

3.1.2.14.4 The system shall log a message for communications status change.

 

 

 

428

 

3.1.2.14.5 The system shall log a message for legacy system status change.

 

 

 

429

 

3.1.2.15 The system shall maintain a user communications log.

 

1

 

2

 

250

 

3.1.2.15.1 The system shall record the communications log entry type.

 

1

 

2

 

561

 

3.1.2.15.1.1 The choices for communications types shall include In Service.

 

1

 

2

 

562

 

3.1.2.15.1.2 The choices for communications types shall include Out of Service.

 

1

 

2

 

563

 

3.1.2.15.2 The system shall record the date/time with each communications log entry.

 

1

 

2

 

660

 

3.1.2.15.3 The system shall store the User name of initiating user with each communications log entry.

 

1

 

2

 

752

 

3.1.2.15.4 The system shall store the Workstation Identifier with each communications log entry.

 

1

 

2

 

750

 

3.1.2.15.5 The system shall store the associated Center with each communications log entry.

 

1

 

2

 

753

 

3.1.2.15.6 The system shall allow the user to enter a freeform text comment with each communications log entry.

 

1

 

2

 

754

 

3.1.2.15.7 The system shall store an identifier for the source for each communications log entry.

 

1

 

2

 

755

 

3.1.2.15.8 The system shall provide the capability for a user to select one or more communication log entries for conversion to an event.

 

1

 

2

 

789

 

3.1.2.16 The system shall support an alert capability to display alert dialogs on user workstations logged in at Centers identified to receive the specified alert type.

 

 

 

827

 

3.1.2.16.1 The system shall support alert types.

 

 

 

828

 

3.1.2.16.1.1 The system shall support an "Action from open report" alert.

 

 

 

829

 

3.1.2.16.1.2 The system shall support an "Alarm timeout" alert.

 

 

 

830

 

3.1.2.16.1.3 The system shall support a "Device failure" alert.

 

 

 

831

 

3.1.2.16.1.4 The system shall support an "Equipment request from open report" alert.

 

 

 

832

 

3.1.2.16.1.5 The system shall support a "Transfer of Resources" alert.

 

 

 

833

 

3.1.2.16.1.6 The system shall support an "Incident from Open Report" alert.

 

 

 

834

 

3.1.2.16.1.7 The system shall support an "Incident from Detector" alert.

 

 

 

835

 

3.1.2.16.1.8 The system shall support an "Incident from External Source" alert.

 

 

 

844

 

3.1.2.16.1.9 The system shall support an "Incident from AVL" alert.

 

 

 

836

 

3.1.2.16.1.10 The system shall support a "Disabled from AVL" alert.

 

 

 

837

 

3.1.2.16.1.11 The system shall support a "Mayday from AVL" alert.

 

 

 

838

 

3.1.2.16.1.12 The system shall support a "Congestion from Detector" alert.

 

 

 

839

 

3.1.2.16.1.13 The system shall support a "Response Plan Generation" alert.

 

 

 

840

 

3.1.2.16.1.14 The system shall support a "Weather Forecast" alert.

 

 

 

841

 

3.1.2.16.1.15 The system shall support a "Weather Sensor" alert.

 

 

 

842

 

3.1.2.16.1.16 The system shall support a "CHART II Infrastructure Failure" alert.

 

 

 

843

 

3.1.2.16.1.17 The system shall support a "Delinquent Equipment Status" alert.

 

 

 

845

 

3.1.2.16.2 The system shall record an alert failure in the operations log if no users with the correct functional rights to receive the alert are logged on.

 

 

 

848

 

3.1.2.16.3 The system shall escalate an alert to the next Center if indicated by the alert type and no users are logged in that may receive the alert.

 

 

 

849

 

3.1.2.16.4 The system shall support the capability to hold alert types  that do not require escalation.

 

 

 

850

 

3.1.2.16.4.1 The system shall display pending alerts to a user with the appropriate functional rights when that user logs into the Center.

 

 

 

851

 

3.1.2.16.5 The system shall escalate and alert to the next Center if indicated by the alert type and the alert is not responded to in a specified time frame.

 

 

 

852

 

3.1.2.16.6 The system shall log a message to the operations log for escalation of an alert.

 

 

 

853

 

3.1.2.16.7 The system shall take appropriate action when a user acknowledges a "Mayday from AVL" alert.

 

 

 

855

 

3.1.2.16.7.1 The system shall open an Action event for a "Mayday from AVL" alert.

 

 

 

856

 

3.1.2.16.7.2 The system shall display information on the map for a "Mayday from AVL" alert.

 

 

 

857

 

3.1.2.16.7.2.1 The system shall display an icon showing the vehicle location.

 

 

 

858

 

3.1.2.16.7.2.2 The system shall display the operator call sign.

 

 

 

859

 

3.1.2.16.7.2.3 The system shall display the vehicle ID number.

 

 

 

860

 

3.1.2.16.7.2.4 The system shall display the Mayday status.

 

 

 

861

 

3.1.2.16.7.2.5 The system shall display the time and text of the last message transmitted from the vehicle.

 

 

 

862

 

3.1.2.17 The system shall provide the capability to view the CHART phone book (CHART phone book provided by EORS).

 

 

 

899

 

3.1.2.18 The system shall support the capability to periodically download EORS information.

 

 

 

900

 

3.1.2.18.1 The system shall support the capability to download EORS lane closure permits.

 

 

 

901

 

3.1.2.18.1.1 The system shall download EORS lane closure permit attributes.

 

 

 

903

 

3.1.2.18.1.2 The system shall download EORS lane closure permit schedule dates and times.

 

 

 

904

 

3.1.2.18.1.3 The system shall download EORS lane closure permits at a system specified interval.

 

 

 

905

 

3.1.2.18.1.4 The system shall support a parameter specifying the number of days of EORS lane closure permit data to retrieve.

 

 

 

906

 

3.1.2.18.1.5 The system shall determine if a conflict exists between an EORS lane closure permit and a CHART special event item.

 

 

 

907

 

3.1.2.18.1.5.1 The system shall store lane closure permit conflict information with the construction permit attributes.

 

 

 

908

 

3.1.2.18.2 The system shall support a parameter specifying the interval to check EORS construction permits for activation.

 

 

 

909

 

3.1.2.18.2.1 The system shall create a map icon for an EORS permit that is within a specified time period of becoming active.

 

 

 

910

 

3.1.2.18.2.2 Right clicking on an EORS construction permit icon shall provide the user with the option of opening an Incident event.

 

 

 

911

 

3.1.2.18.3 The system shall notify EORS when an EORS permit has been activated.

 

 

 

912

 

3.1.2.18.4 The system shall support the capability to download EORS snow emergency information.

 

 

 

902

 

3.1.2.18.4.1 The system shall download snow emergency information at a system specified interval.

 

 

 

913

 

3.1.2.18.4.2 The system shall update a county-based snow emergency map layer when the county declares or cancels a snow emergency.

 

 

 

914

 

3.1.2.18.4.3 The system shall send notifications as specified when a snow emergency is declared.

 

 

 

915

 

3.1.2.19 The system shall support the capability to monitor National Weather Service data as provided through the WSI, Inc Weather for Windows package.

 

 

 

917

 

3.1.2.19.1 The system shall provide the capability for a user to view National Weather Service data stored on the CHART web site.

 

 

 

918

 

3.1.2.19.2 The system shall provide the capability to monitor National Weather Service severe weather alerts.

 

 

 

919

 

3.1.2.19.2.1 The system shall generate an alert to CHART users if a new or updated severe weather alert is detected.

 

 

 

920

 

3.1.2.19.3 The system shall provide the capability to periodically distribute weather reports to specified recipients by Fax.

 

 

 

921

 

3.1.2.19.3.1 The frequency to distribute weather reports shall be specified by a system parameter.

 

 

 

922

 

3.1.3 Equipment Inventory

The equipment inventory is a list of SHA equipment used in connection with CHART response to incidents.  The system provides functions to maintain the inventory, equipment status, and to generate alerts for delinquent equipment.

 

 

 

814

 

3.1.3.1 The system shall provide the capability to maintain the equipment inventory.

 

 

 

815

 

3.1.3.1.1 The system shall support the addition of new equipment entries to the inventory.

 

 

 

816

 

3.1.3.1.2 The system shall support the modification of existing equipment inventory entries.

 

 

 

817

 

3.1.3.1.3 The system shall support the deletion of equipment inventory entries.

 

 

 

818

 

3.1.3.1.4 The system shall support the allocation of equipment to events.

 

 

 

820

 

3.1.3.2 The system shall provide the capability to periodically scan the equipment inventory for delinquent equipment.

 

 

 

819

 

3.1.3.2.1 The system shall generate an alert for delinquent equipment.

 

 

 

821

 

3.1.4 Report Generation

This section lists requirements for the generation of reports from the CHART system and archive data.

 

 

 

940

 

3.1.4.1 The system shall provide the capability to generate reports from online and archived data.

 

 

 

941

 

3.1.4.2 The system shall support the generation of operational reports.

 

 

 

942

 

3.1.4.2.1 The system shall support the generation of a Center Situation report.

 

 

 

945

 

3.1.4.2.2 The system shall support the generation of a Disable Vehicle event report.

 

 

 

946

 

3.1.4.2.3 The system shall support the generation of an Incident event report.

 

 

 

947

 

3.1.4.2.4 The system shall support the generation of traffic volume reports.

 

 

 

1068

 

3.1.4.3 The system shall support the generation of administrative reports.

 

 

 

943

 

3.1.4.3.1 The system shall support the generation of a Device report.

 

 

 

948

 

3.1.4.3.2 The system shall support the generation of a Device Failure report.

 

 

 

949

 

3.1.4.3.3 The system shall support the generation of a User Activity report.

 

 

 

950

 

3.1.4.3.4 The system shall support the generation of a Center Activity report.

 

 

 

951

 

3.1.4.3.5 The system shall support the generation of a Communications log report.

 

 

 

952

 

3.1.4.3.6 The system shall support the generation of a Device Configuration report.

 

 

 

953

 

3.1.4.4 The system shall support the generation of management reports.

 

 

 

944

 

3.1.4.4.1 The system shall support the generation of a DMS Usage Classification report.

 

 

 

954

 

3.1.4.4.2 The system shall support the generation of a DMS Usage Message Type report.

 

 

 

955

 

3.1.4.4.3 The system shall support the generation of a HAR Usage Classification Type report.

 

 

 

956

 

3.1.4.4.4 The system shall support the generation of a HAR Usage Message Type report.

 

 

 

957

 

3.1.4.4.5 The system shall support the generation of an ERU/ETP Assist Type report.

 

 

 

958

 

3.1.4.4.6 The system shall support the generation of an ERU/ETP Total Assists report.

 

 

 

959

 

3.1.4.4.7 The system shall support the generation of an ERU/ETP Average Response Times report.

 

 

 

960

 

3.1.4.4.8 The system shall support the generation of an Incident Clearance Time report.

 

 

 

961

 

3.1.4.4.9 The system shall support the generation of an Incident Roadway Capacity Restoration report.

 

 

 

962

 

3.1.4.4.10 The system shall support the generation of an Incident Duration by Type report.

 

 

 

963

 

3.1.4.4.11 The system shall support the generation of an Alarm Acknowledgement report.

 

 

 

964

 

3.1.4.4.12 The system shall support the generation of a Detection Subsystem report.

 

 

 

965

 

3.1.4.4.13 The system shall support the generation of a Shop Equipment report.

 

 

 

966

 

3.1.4.5 The system shall provide an ad hoc reporting capability for archived data.

 

 

 

1088

 

3.1.4.6 The system shall provide the capability for users to customize reports.

 

 

 

1089

 

3.1.5 Schedule Management

This section lists requirements for the management and execution of scheduled system functions.

 

 

 

869

 

3.1.5.1 The system shall allow a suitably priviledged user to create a schedule.

 

 

 

870

 

3.1.5.1.1 The system shall allow a suitably priviledged user to name a schedule.

 

 

 

874

 

3.1.5.1.2 The system shall allow a suitably priviledged user to specify a begin timestamp for starting the automatic execution of a schedule.

 

 

 

875

 

3.1.5.1.3 The system shall allow a suitably priviledged user to specify an ending timestamp for stopping the execution of a schedule.

 

 

 

876

 

3.1.5.1.4 The system shall support timestamps based on an absolute time and date.

 

 

 

887

 

3.1.5.1.5 The system shall support timestamps based on time of day.

 

 

 

888

 

3.1.5.1.6 The system shall support timestamps based on day of week.

 

 

 

889

 

3.1.5.1.7 The system shall support timestamps based on day of month.

 

 

 

890

 

3.1.5.1.8 The system shall support timestamps based on a delta time.

 

 

 

892

 

3.1.5.1.9 The system shall support timestamps for each scheduled item.

 

 

 

891

 

3.1.5.1.10 The system shall delete a schedule with an absolute timestamp after the completion of the execution of the schedule.

 

 

 

898

 

3.1.5.2 The system shall allow a suitably priviledged user to modify a schedule.

 

 

 

871

 

3.1.5.3 The system shall allow a suitably priviledged user to delete a schedule.

 

 

 

872

 

3.1.5.4 The system shall support the manual initiation of a schedule.

 

 

 

885

 

3.1.5.5 The system shall support the manual termination of a schedule.

 

 

 

886

 

3.1.5.6 The system shall support the scheduling of device online and offline commands.

 

 

 

873

 

3.1.5.7 The system shall support the scheduling of DMS message commands.

 

 

 

877

 

3.1.5.8 The system shall support the scheduling of HAR message commands.

 

 

 

878

 

3.1.5.9 The system shall support the scheduling of AVCM presets.

 

 

 

879

 

3.1.5.10 The system shall support the scheduling of camera (source) to wall monitor (destination) configuration commands.

 

 

 

880

 

3.1.5.11 The system shall support the scheduling of camera tours.

 

 

 

881

 

3.1.5.12 The system shall support the scheduling of plan activations/deactivations.

 

 

 

882

 

3.1.5.13 The system shall support the scheduling of notifications.

 

 

 

883

 

3.1.5.14 The system shall support the scheduling of report generation.

 

 

 

884

 

3.1.5.15 The schedule shall include an associated event type.

 

 

 

893

 

3.1.5.15.1 The schedule event types shall include Special Event.

 

 

 

894

 

3.1.5.15.2 The schedule event types shall include Recurring Congestion.

 

 

 

895

 

3.1.5.15.3 The schedule event types shall include Safety Messages.

 

 

 

896

 

3.1.5.16 The system shall open a new event corresponding to the schedule event type when a schedule is activated.

 

 

 

897

 

3.2 Device Management

This section lists requirements for the management and control of CHART remote devices.  CHART remote devices consist of DMSs, HARs, SHAZAMS, AVL units, CCTV devices, traffic detectors, signals, and weather stations. 

 

 

 

30

 

3.2.1 General Remote Device

This section lists general requirements that apply to all remote devices.

 

 

 

31

 

3.2.1.1 The system shall maintain device attribute information for all CHART devices.

 

 

 

411

 

3.2.1.1.1 Device attribute information shall include the geographic  location of the device.

 

 

 

412

 

3.2.1.1.2 Device attribute information shall include the owning organization for the device.

 

 

 

1028

 

3.2.1.2 The system shall provide a mechanism to poll devices for status on a configurable interval basis.

 

1

 

1

 

32

 

3.2.1.2.1 The system shall support the polling of DMS devices.

 

1

 

1

 

385

 

3.2.1.2.2 The system shall support the polling of traffic detection devices.

 

 

 

386

 

3.2.1.3 The system shall allow a suitably privileged user to force a status poll of a selected pollable device.

 

1

 

1

 

33

 

3.2.1.4 The system shall allow a suitably privileged user to force a status poll of a selected group of pollable devices.

 

1

 

1

 

34

 

3.2.1.5 The system shall allow a suitably privileged user to alter the polling interval of a selected pollable device.

 

1

 

1

 

35

 

3.2.1.5.1 The minimum polling interval shall be 1 minute.

 

1

 

1

 

36

 

3.2.1.5.2 The maximum polling interval shall be 24 hours.

 

1

 

1

 

37

 

3.2.1.5.3 The minimum increment for a polling interval shall be 1 minute.

 

1

 

1

 

38

 

3.2.1.6 The system shall inform operators of a device communications failure if it is unable to communicate with a particular device during polling.

 

1

 

1

 

39

 

3.2.1.7 The system shall inform the operators of a device failure.

 

1

 

1

 

416

 

3.2.1.7.1 The system shall inform the operators of a DMS failure.

 

1

 

1

 

417

 

3.2.1.7.1.1 The system shall mark a DMS as blank after a timeout threshold is reached following a DMS communications failure.

 

1

 

1

 

669

 

3.2.1.7.1.1.1 The system shall return the current message to the device queue following a DMS communications failure.

 

 

 

1032

 

3.2.1.7.1.2 The system shall blank a DMS when successful communication with the DMS is resumed after the DMS communications failure timeout threshold has expired.

 

1

 

1

 

670

 

3.2.1.7.1.3 The system shall support a DMS communications failure timeout threshold expressed in minutes from 1 minute and 16535 minutes.

 

1

 

1

 

671

 

3.2.1.7.1.3.1 The DMS communications failure timeout default shall be 10 minutes.

 

1

 

1

 

672

 

3.2.1.7.2 The system shall inform the operators of a HAR failure.

 

1

 

2

 

418

 

3.2.1.7.3 The system shall inform the operators of a AVL failure.

 

 

 

419

 

3.2.1.7.4 The system shall inform the operators of a signals failure.

 

 

 

420

 

3.2.1.7.5 The system shall inform the operators of a detector failure.

 

 

 

627

 

3.2.1.7.6 The system shall inform the operators of a weather station failure.

 

 

 

628

 

3.2.1.7.7 The system shall generate an alert for a device failure.

 

 

 

824

 

3.2.1.7.7.1 The system shall open an Action event for the device failure when the user acknowledges the alert.

 

 

 

826

 

3.2.1.7.8 The system shall log the device failure status information to the operations log.

 

 

 

825

 

3.2.1.8 The system shall allow a suitably privileged user to place an online device offline.

 

1

 

1

 

40

 

3.2.1.9 The system shall allow a suitably privileged user to place an offline device online.

 

1

 

1

 

41

 

3.2.1.9.1 All commands to online devices shall be performed through an open event.

 

1

 

2

 

978

 

3.2.1.10 The system shall allow a suitably privileged user to place a device in maintenance mode.

 

1

 

2

 

413

 

3.2.1.10.1 Placing a device in maintenance mode shall limit access to the device to only those users with maintenance mode privileges.

 

1

 

2

 

414

 

3.2.1.10.2 Placing a device in maintenance mode shall disable polling of that device.

 

1

 

2

 

415

 

3.2.1.10.3 The system shall restrict certain commands to devices in maintenance mode only.

 

1

 

2

 

972

 

3.2.1.10.3.1 "Reset DMS" is a maintenance mode command.

 

1

 

2

 

973

 

3.2.1.10.3.2 "Reset HAR controller" is a maintenance mode command.

 

1

 

2

 

974

 

3.2.1.10.3.3 "Forced Poll" is a maintenance mode command.

 

1

 

2

 

975

 

3.2.1.10.3.4 "Setup HAR controller" is a maintenance mode command.

 

1

 

2

 

976

 

3.2.1.10.3.5 "Rebuild HAR controller" is a maintenance mode command.

 

1

 

2

 

977

 

3.2.1.10.3.6 "Set HAR transmitter on/off" is a maintenance mode command.

 

1

 

2

 

994

 

3.2.1.10.3.7 "Change device configuration" is a maintenance mode command.

 

1

 

2

 

995

 

3.2.1.10.3.8 "Store message in HAR controller slot" (except the immediate message slot) is a maintenance mode command.

 

1

 

2

 

996

 

3.2.1.10.3.9 "Delete message from HAR controller slot" is a maintenance mode command.

 

1

 

2

 

997

 

3.2.1.10.3.10 "Pixel test" is a maintenance mode command.

 

1

 

2

 

998

 

3.2.1.11 The system shall allow a suitably privileged user to add a new device which communicates via an implemented protocol.

 

1

 

1

 

42

 

3.2.1.12 The system shall allow a suitably privileged user to specify the necessary configuration information to make a device usable.

 

1

 

1

 

43

 

3.2.1.13 The system shall allow a suitably privileged user to change the name of a selected device.

 

1

 

1

 

44

 

3.2.1.14 The system shall allow a suitably privileged user to modify the configuration information for a device.

 

1

 

1

 

45

 

3.2.1.15 The system shall allow a suitably privileged user to delete a device from the system.

 

1

 

1

 

46

 

3.2.1.15.1 The system shall not allow a device to be deleted unless the device is first placed in an offline state.

 

1

 

2

 

1000

 

3.2.1.16 The system shall not exceed 3 seconds to notify a user that a shared resource they have requested is under the control of another operations center.

 

1

 

1

 

47

 

3.2.1.17 The system shall not exceed 12 seconds to complete a command to a field device (excluding POTS devices).

 

1

 

1

 

48

 

3.2.1.18 The system shall not exceed 15 seconds to notify the user of the completion status of a command to control a shared resource.

 

1

 

1

 

49

 

3.2.1.19 The system shall not exceed 15 seconds to change the status of a device from offline to online.

 

1

 

1

 

50

 

3.2.1.20 The system shall not exceed 5 seconds to change the status of a device from online to offline.

 

1

 

1

 

51

 

3.2.1.21 The system shall not exceed 5 seconds to notify the initiating user of the failure to add a new device.

 

1

 

1

 

52

 

3.2.1.22 The system shall not exceed 5 seconds to notify the initiating user of the successful addition of a new device.

 

1

 

1

 

53

 

3.2.1.23 The system shall not exceed 3 seconds to display current device configuration data to the initiating user.

 

1

 

1

 

54

 

3.2.1.24 The system shall not exceed 5 seconds to notify the initiating user of the failure to modify device configuration data.

 

1

 

1

 

55

 

3.2.1.25 The system shall not exceed 5 seconds to notify the initiating user of the successful modification of device configuration data.

 

1

 

1

 

56

 

3.2.1.26 The system shall not exceed 3 seconds to notify the initiating user of the failure to delete a device.

 

1

 

1

 

57

 

3.2.1.27 The system shall not exceed 5 seconds to notify the initiating user of the successful deletion of a device.

 

1

 

1

 

58

 

3.2.1.28 The system shall log operations messages associated with the management and control of shared resources.

 

1

 

1

 

281

 

3.2.1.28.1 The system shall log a message for Change shared resource name.

 

1

 

1

 

282

 

3.2.1.28.2 The system shall log a message for Place a shared resource online.

 

1

 

1

 

283

 

3.2.1.28.3 The system shall log a message for Take shared resource offline.

 

1

 

1

 

284

 

3.2.1.28.4 The system shall log a message for Place a shared resource in maintenance mode.

 

1

 

2

 

747

 

3.2.1.28.5 The system shall log a message for Change shared resource polling interval.

 

1

 

1

 

285

 

3.2.1.28.6 The system shall log a message for Change in shared resource hardware status.

 

1

 

1

 

286

 

3.2.1.28.7 The system shall log a message for Adding a shared resource Configuration.

 

1

 

1

 

287

 

3.2.1.28.8 The system shall log a message for Modifying a shared resource Configuration.

 

1

 

1

 

288

 

3.2.1.28.9 The system shall log a message for Deleting a shared resource Configuration.

 

1

 

1

 

289

 

3.2.1.29 Data from detection devices shall be made available to requesting systems on an equal basis.

 

 

 

1086

 

3.2.1.29.1 Servicing a request for detection data from one system shall not affect the data requested by another system.

 

 

 

1087

 

3.2.1.30 The system shall provide a capability for users to exercise specified system functions without affecting operational field devices.

 

 

 

1090

 

3.2.1.30.1 The system shall provide the capability for a user to perform DMS-related functions on a simulated DMS.

 

 

 

1091

 

3.2.2 Dynamic Message Signs

This section lists requirements for the control of Dynamic Message Signs.

 

 

 

59

 

3.2.2.1 The system shall allow a suitably privileged user to set the current message for a selected DMS.

 

1

 

1

 

60

 

3.2.2.2 The system shall allow a suitably privileged user to specify the beacon state on the selected DMS, if it has beacons.

 

1

 

1

 

61

 

3.2.2.3 The system shall allow a suitably privileged user to set the current message for a selected group of DMSs.

 

1

 

1

 

62

 

3.2.2.4 The system shall allow a suitably privileged user to blank the display of a selected DMS.

 

1

 

1

 

64

 

3.2.2.4.1 If the beacons of a DMS are on when the DMS is blanked, they shall be turned off.

 

1

 

1

 

65

 

3.2.2.4.2 Blanking the display of an online DMS shall preempt the currently displayed message, if any.

 

 

 

1029

 

3.2.2.5 The system shall allow a suitably privileged user to blank the display of a selected group of DMSs.

 

1

 

1

 

66

 

3.2.2.6 The system shall allow a suitably privileged user to reset the controller for a selected DMS.

 

1

 

1

 

68

 

3.2.2.6.1 The system shall log a message to the operations log for Reset DMS controller.

 

1

 

1

 

293

 

3.2.2.6.2 The system shall blank the display of the selected DMS when the controller is reset.

 

1

 

1

 

69

 

3.2.2.6.3 If the DMS has beacons, the system shall turn the beacons off when the controller is reset.

 

1

 

1

 

70

 

3.2.2.6.4 The Reset command for a DMS controller shall preempt any message currently displayed on the DMS.

 

 

 

793

 

3.2.2.7 The system shall allow a suitably privileged user to reset the controller for a selected group of DMSs.

 

1

 

1

 

71

 

3.2.2.8 The system shall support multiple DMS protocols.

 

1

 

1

 

74

 

3.2.2.8.1 The system shall support the Mark IV FP9500 "Maryland" DMS protocol.  (Actual protocol support is carried out by the FMS subsystem.)

 

1

 

1

 

75

 

3.2.2.8.2 The system shall support the Mark IV FP2001 DMS protocol.  (Actual protocol support is carried out by the FMS subsystem.)

 

1

 

1

 

76

 

3.2.2.8.3 The system shall support the Mark IV FP1001 DMS protocol.  (Actual protocol support is carried out by the FMS subsystem.)

 

1

 

1

 

77

 

3.2.2.8.4 The system shall support the Telespot DMS protocol.  (Actual protocol support is carried out by the FMS subsystem.)

 

1

 

1

 

78

 

3.2.2.8.5 The system shall support the ADCO DMS protocol. (Actual protocol support is carried out by the FMS subsystem.)

 

1

 

2

 

79

 

3.2.2.8.6 The system shall support the Display Solutions DMS protocol. (Actual protocol support is carried out by the FMS subsystem.)

 

1

 

2

 

80

 

3.2.2.8.7 The system shall support the Sylvia DMS protocol. (Actual protocol support is carried out by the FMS subsystem.)

 

1

 

2

 

81

 

3.2.2.9 The system shall provide an application program interface (API) to implement DMS functionality specified in the NTCIP standard  NEMA TS3.6.

 

1

 

1

 

82

 

3.2.2.10 The system shall allow a suitably privileged user to set a DMS offline.

 

1

 

1

 

83

 

3.2.2.10.1 The system shall blank the display of a DMS that is set to offline.

 

1

 

1

 

667

 

3.2.2.11 The system shall allow a suitably privileged user to set a DMS online.

 

1

 

1

 

745

 

3.2.2.11.1 The system shall immediately blank the display of a DMS that is set to online.

 

1

 

1

 

668

 

3.2.2.11.2 The system shall enable the message queue for a DMS that is set to online.

 

 

 

797

 

3.2.2.12 The system shall check known error indicators in the status packet as specified by the DMS protocol and shall inform operators of a DMS hardware failure should an error condition be discovered.

 

1

 

1

 

84

 

3.2.2.13 The system shall allow a suitably privileged user to command  a pixel test on a DMS that supports this function.

 

1

 

2

 

999

 

3.2.3 Highway Advisory Radios

This section lists requirements for the control of Highway Advisory Radios.

 

 

 

85

 

3.2.3.1 The system shall allow a suitably privileged user to set the broadcast message for a selected HAR.

 

1

 

2

 

86

 

3.2.3.2 The system shall allow a suitably privileged user to set the default message for a selected HAR.

 

1

 

2

 

459

 

3.2.3.3 The system shall allow a suitably privileged user to specify the SHAZAM state for each SHAZAM associated with a HAR, if it has a SHAZAM.

 

1

 

2

 

87

 

3.2.3.4 The system shall set the default message as the broadcast message for a HAR if the current message is inactivated.

 

1

 

2

 

88

 

3.2.3.5 The system shall allow a suitably privileged user to set the current message for a selected group of HARs.

 

1

 

2

 

89

 

3.2.3.6 The system shall support sending messages to at least four HARs simultaneously.

 

1

 

2

 

91

 

3.2.3.7 The system shall allow a suitably privileged user to designate from zero to at least eight SHAZAMs for a specified HAR.

 

1

 

2

 

458

 

3.2.3.8 The system shall allow a suitably privileged user to designate from zero to at least eight DMSs to be used as a SHAZAM for a specified HAR.

 

1

 

2

 

457

 

3.2.3.9 If a HAR has SHAZAMs associated with it and a message that  requires SHAZAMs on is sent to it then the specified SHAZAMs shall be turned on only after a message has been activated on the HAR.

 

1

 

2

 

92

 

3.2.3.10 If a HAR has active SHAZAMs then the SHAZAMs shall be turned off before the current message is deactivated.

 

1

 

2

 

93

 

3.2.3.11 The system shall allow a suitably privileged user to issue the reset command to the controller for a selected HAR.

 

1

 

2

 

94

 

3.2.3.11.1 The system shall log a message to the operations log for Reset HAR controller.

 

1

 

2

 

297

 

3.2.3.11.2 The system shall issue the setup command immediately after a reset command is sent to a HAR controller.

 

1

 

2

 

710

 

3.2.3.12 The system shall allow a suitably privileged user to issue the setup command to the controller for a selected HAR.

 

1

 

2

 

460

 

3.2.3.12.1 The system shall log a message to the operations log for Setup HAR controller.

 

1

 

2

 

465

 

3.2.3.13 The system shall allow a suitably privileged user to issue the rebuild command to the controller for a selected HAR.

 

1

 

2

 

461

 

3.2.3.13.1 The system shall log a message to the operations log for Rebuild HAR controller.

 

1

 

2

 

464

 

3.2.3.14 The system shall allow a suitably privileged user select the HAR controller slot number for a message.

 

1

 

2

 

703

 

3.2.3.14.1 The default slot number for the default message shall be slot 2.

 

1

 

2

 

708

 

3.2.3.14.2 The default slot number for the dynamic message shall be slot 7.

 

1

 

2

 

709

 

3.2.3.15 The system shall allow a suitably privileged user to delete a message from a designated slot in the HAR controller.

 

1

 

2

 

713

 

3.2.3.15.1 The system shall log a message to the operations log for deletion of a message from a HAR controller.

 

1

 

2

 

714

 

3.2.3.16 The system shall support a SHAZAM device reset command that sets a SHAZAM to its last known state.

 

1

 

2

 

711

 

3.2.3.16.1 The system shall provide the capability to periodically issue the SHAZAM reset command to a SHAZAM based on a SHAZAM specific reset interval parameter.

 

1

 

2

 

712

 

3.2.3.17 The system shall allow a suitably privileged user to play a message from a selected slot in the HAR controller.

 

1

 

2

 

715

 

3.2.3.18 The system shall provide the capability for a user at a workstation to listen to a message stored in a HAR controller.

 

1

 

2

 

726

 

3.2.3.19 The system shall allow a suitably privileged user to turn off the transmitter for a HAR.

 

1

 

2

 

716

 

3.2.3.19.1 The system shall log a message to the operations log for turning off the transmitter for a HAR.

 

1

 

2

 

717

 

3.2.3.20 The system shall support the capability to set SHAZAM devices offline without affecting the associated HAR.

 

1

 

2

 

725

 

3.2.3.20.1 The system shall set to off a SHAZAM device that is placed offline.

 

1

 

2

 

724

 

3.2.3.21 The system shall allow a suitably privileged user to set a HAR offline.

 

1

 

2

 

743

 

3.2.3.21.1 The system shall turn off the transmitter of a HAR that is set to offline.

 

1

 

2

 

738

 

3.2.3.21.2 The system shall place offline all SHAZAM devices associated with a HAR when the HAR is set to offline.

 

1

 

2

 

740

 

3.2.3.22 The system shall allow a suitably privileged user to set a HAR online.

 

 

 

847

 

3.2.3.22.1 The system shall turn on the transmitter of a HAR that is set to online

 

1

 

2

 

739

 

3.2.3.22.2 The system shall allow the user to selectively place online SHAZAM devices associated with a HAR when the HAR is set to online.

 

1

 

2

 

741

 

3.2.4 CCTV Cameras

This section lists requirements for the control and management of traffic monitoring video cameras.

 

 

 

619

 

3.2.4.1 The system shall allow a suitably privileged user to control cameras.

 

 

 

620

 

3.2.4.1.1 The system shall allow a camera user to block/unblock media and web access to the video output of a camera.

 

 

 

778

 

3.2.4.1.2 The system shall block camera video from the media and web automatically when specified users types open a control session.

 

 

 

1040

 

3.2.4.2 The system shall allow a suitably privileged user to control wall monitor assignments.

 

 

 

621

 

3.2.4.3 The system shall allow a suitably privileged user to activate tours.

 

 

 

622

 

3.2.4.4 The system shall allow a suitably privileged user to maintain the camera tour information.

 

 

 

625

 

3.2.4.5 The system shall allow a suitably privileged user to maintain CCTV presets.

 

 

 

623

 

3.2.4.5.1 The system shall support resetting a camera to its original default position at a scheduled time.

 

 

 

624

 

3.2.5 Detectors

This section lists requirements for the receipt of data from traffic detectors and the management and control of the detectors.

 

 

 

629

 

3.2.5.1 The system shall provide the capability to receive detector traffic monitoring data.

 

 

 

626

 

3.2.5.1.1 The system shall archive all detector traffic monitoring data.

 

 

 

631

 

3.2.5.2 The system shall allow a suitably privileged user to reset a detector, if supported by that detector.

 

 

 

630

 

3.2.5.2.1 The system shall log a message to the operations log for reset detector.

 

 

 

823

 

3.2.5.3 The system shall provide the capability to assess the validity of detector data.

 

 

 

1069

 

3.2.5.3.1 The system shall determine the validity of loop detector data.

 

 

 

1070

 

3.2.6 Signals

This section lists requirements for the receipt of data from traffic signal devices.

 

 

 

632

 

3.2.6.1 The system shall provide the capability to receive traffic monitoring data from traffic signals.

 

 

 

633

 

3.2.6.1.1 The system shall archive all traffic signal traffic monitoring data.

 

 

 

634

 

3.2.7 Automatic Vehicle Location

This section lists requirements for Automatic Vehicle Location (AVL) devices.

 

 

 

677

 

3.2.7.1 The system shall support the receipt of information from AVL devices.

 

 

 

678

 

3.2.7.1.1 The system shall archive AVL information.

 

 

 

1050

 

3.2.7.2 The system shall provide the capability for a user to send a message to an AVL equippped vehicle.

 

 

 

756

 

3.2.7.3 An AVL device shall be capable of providing status information to CHART.

 

 

 

686

 

3.2.7.3.1 The AVL device shall support sending a vehicle id.

 

 

 

687

 

3.2.7.3.2 The AVL device shall support sending an operator call sign.

 

 

 

688

 

3.2.7.3.3 The AVL device shall support sending vehicle status.

 

 

 

691

 

3.2.7.3.4 The AVL device shall support sending vehicle location.

 

 

 

689

 

3.2.7.3.4.1 The AVL vehicle location shall be accurate to better than 100 meters.

 

 

 

690

 

3.2.7.4 An AVL device shall be capable of providing messages to CHART.

 

 

 

679

 

3.2.7.4.1 The AVL device shall support an In/Out of Service message.

 

 

 

680

 

3.2.7.4.1.1 The system shall record an In/Out of Service message in the Communications log.

 

 

 

685

 

3.2.7.4.2 The AVL device shall support a Mayday message.

 

 

 

681

 

3.2.7.4.2.1 The system shall record a Mayday message as an Action event.

 

 

 

692

 

3.2.7.4.2.2 The system shall post a "Mayday from AVL" alert in response to an AVL Mayday message.

 

 

 

854

 

3.2.7.4.3 The AVL device shall support an Arrival On-Scene message.

 

 

 

682

 

3.2.7.4.3.1 The system shall record an Arrival On-Scene message with the event for which the vehicle was dispatched.

 

 

 

693

 

3.2.7.4.3.2 The system shall prompt the user to open a new event or associate the vehicle with an existing open event if an AVL Arrival On-Scene message is received and the vehicle is not associated with an open event.

 

 

 

760

 

3.2.7.4.4 The AVL device shall support an Assisting Disabled Vehicle message.

 

 

 

683

 

3.2.7.4.4.1 The system shall record an Assisting Disabled Vehicle message with the Disabled Vehicle event for which the vehicle was dispatched.

 

 

 

761

 

3.2.7.4.4.2 The system shall prompt the user to open a new Disabled Vehicle event or associate the vehicle with an existing open Disabled Vehicle event if an AVL Assisting Disabled Vehicle message is received and the vehicle is not associated with an open Disabled Vehicle event.

 

 

 

762

 

3.2.7.4.5 The AVL device shall support an Available message.

 

 

 

684

 

3.2.7.4.5.1 The system shall record an Available message with the event for which the vehicle was dispatched.

 

 

 

763

 

3.2.7.5 The system shall record all AVL communications to an AVL log.

 

 

 

759

 

3.3 Display Management

This section lists requirements for the management and presentation of information displayed to the users.  The main display management components are the map display and the device navigator.

 

While some functions can be invoked from the command line the CHART GUI is the primary interface between the user and the CHART system.  The GUI map display provides an updating multi-layered visual representation of the status of monitored roadways and devices.  The user can exercise control over zoom levels, panning, selecting map layers for display, and can access monitored object status and characteristics directly from the display.

 

The device navigator provides a hierarchical view of the CHART devices.  Device control functions and device status information are available through the navigator. 

 

 

 

95

 

3.3.1 Device Navigator

The device navigator provides the user with a GUI for managing and controlling devices.

 

 

 

96

 

3.3.1.1 The navigator shall provide a device group in the tree view. 

 

1

 

1

 

97

 

3.3.1.1.1 Clicking on the device group shall cause all system devices to be displayed in the list view.

 

1

 

1

 

98

 

3.3.1.2 The navigator shall show the updating attributes and status of each of the devices.

 

1

 

1

 

99

 

3.3.1.2.1 The navigator shall show the Name/description for each device.

 

1

 

1

 

100

 

3.3.1.2.2 The navigator shall show the date/time of last change in status for each device.

 

1

 

1

 

101

 

3.3.1.2.3 The navigator shall show the Object type for each device.

 

1

 

1

 

102

 

3.3.1.2.4 The navigator shall show the Operational Status for each device.

 

1

 

1

 

103

 

3.3.1.2.4.1 Operational status shall indicate if the device is Online or Offline.

 

1

 

1

 

104

 

3.3.1.2.4.2 Operational status shall indicate Hardware Failure values.

 

1

 

1

 

105

 

3.3.1.2.4.3 Operational status shall indicate Communications Failure values.

 

1

 

1

 

106

 

3.3.1.2.5 The navigator shall show the DMS geometry for each DMS device.

 

1

 

1

 

107

 

3.3.1.2.6 The navigator shall show the current message for each DMS device.

 

1

 

1

 

108

 

3.3.1.2.7 The navigator shall identify the current message for each HAR device.

 

1

 

2

 

109

 

3.3.1.2.8 The navigator shall show the phone numbers associated with a HAR.

 

1

 

2

 

727

 

3.3.1.2.8.1 The navigator shall show the phone number for the HAR controller.

 

1

 

2

 

728

 

3.3.1.2.8.2 The navigator shall show the phone number for the HAR monitor line.

 

1

 

2

 

729

 

3.3.1.2.8.3 The navigator shall show the phone number for each SHAZAM associated with the HAR.

 

1

 

2

 

730

 

3.3.1.2.9 The GUI shall provide the capability to show the id of each device.

 

1

 

1

 

795

 

3.3.1.2.10 The GUI shall provide the capability to show the network connection site for a device.

 

1

 

1

 

796

 

3.3.1.3 The navigator shall allow a user to right click on a device in the list view to display a pop-up control menu for that device.

 

1

 

1

 

110

 

3.3.1.4 The navigator shall allow an user to right click on a selected group of devices to display a pop-up control menu for the selected devices.

 

1

 

1

 

111

 

3.3.1.5 The navigator shall allow a user to sort the information in the list view by clicking on the column header.

 

1

 

1

 

112

 

3.3.1.6 The system shall provide a DMS message editor which will allow a user to format a DMS message.

 

1

 

1

 

113

 

3.3.1.6.1 The DMS message editor shall allow a user to enter message text into a text field.

 

1

 

1

 

114

 

3.3.1.6.2 The DMS message editor shall show the operator an updating view of the message text formatted for the smallest DMS being altered, with the option to view the other selected formats.

 

1

 

1

 

115

 

3.3.1.6.3 The DMS message editor shall inform the operator if the entered message text would be truncated when formatted to fit any of the selected DMS being altered.

 

1

 

1

 

116

 

3.3.1.6.4 When a group of DMSs are selected to receive the same message, the message editor shall format the message for each DMS type selected.

 

1

 

1

 

117

 

3.3.1.6.5 The system shall not allow truncated messages to be sent to a DMS.

 

1

 

1

 

118

 

3.3.1.7 The system shall provide a HAR message editor that will allow a user to format a HAR message.

 

1

 

2

 

119

 

3.3.1.7.1 For text messages the HAR message editor shall display the message header, message body, and message trailer.

 

1

 

2

 

120

 

3.3.1.7.2 The HAR message editor shall allow a user to enter message text into a text field.

 

1

 

2

 

121

 

3.3.1.7.3 The HAR message editor shall allow a user to hear the result of text to speech conversion of the message header, message body, and message trailer.

 

1

 

2

 

122

 

3.3.1.7.4 The HAR message editor shall display the run time of the spoken message in minutes and seconds.

 

1

 

2

 

123

 

3.3.1.7.4.1 The HAR message editor shall alert the user if the message run time exceeds two minutes.

 

1

 

2

 

124

 

3.3.1.7.5 The HAR message editor shall support the recording of voice messages.

 

1

 

2

 

694

 

3.3.1.7.6 The HAR message editor shall provide audio control functions for controlling the playback of audio messages.

 

1

 

2

 

695

 

3.3.1.7.6.1 The HAR message editor shall provide a PLAY button to play an audio file.

 

1

 

2

 

696

 

3.3.1.7.6.2 The HAR message editor shall provide a STOP button to stop the playback of an audio file.

 

1

 

2

 

697

 

3.3.1.7.6.3 The HAR message editor shall provide a PAUSE button to pause the playback of an audio file.

 

1

 

2

 

698

 

3.3.1.7.7 The HAR message editor shall provide the capability to construct a single continuous message from any of a message header, body and trailer.

 

1

 

2

 

699

 

3.3.1.7.7.1 The HAR message editor shall provide the capability to insert delays between message segments.

 

1

 

2

 

718

 

3.3.1.7.7.2 The HAR message editor shall provide the capability to construct a message for broadcast from messages currently residing in controller slots.

 

1

 

2

 

720

 

3.3.1.7.8 The HAR message editor shall support an optional time/date field in the message header.

 

1

 

2

 

721

 

3.3.1.7.8.1 The system shall support the automatic update of the HAR message header time/date field.

 

1

 

2

 

722

 

3.3.1.7.8.2 The HAR message header time/date field shall support customizable generalized time periods relating time of day to a period of day (e.g. 1200-1700 as afternoon).

 

1

 

2

 

723

 

3.3.1.8 The system shall provide a DMS show display window, which will show a graphical depiction of the current message for a particular DMS.

 

1

 

1

 

125

 

3.3.1.9 The navigator shall provide a DMS message library group in the tree view for each DMS message library.

 

1

 

1

 

126

 

3.3.1.9.1 Clicking on the DMS Message Library group shall cause all  DMS library messages stored in the selected library to be displayed in the list view.

 

1

 

1

 

127

 

3.3.1.10 The navigator shall show the attributes for each library message.

 

1

 

1

 

128

 

3.3.1.10.1 The navigator shall show the Message description for each library message.

 

1

 

1

 

129

 

3.3.1.10.2 The navigator shall show the Message text for each library message.

 

1

 

1

 

130

 

3.3.1.10.3 The navigator shall show the Topic/Category for each library message.

 

1

 

1

 

131

 

3.3.1.10.4 The navigator shall show the Required sign length in characters for each library message.

 

1

 

1

 

132

 

3.3.1.10.5 The navigator shall show the Beacon indicator for each library message.

 

1

 

1

 

133

 

3.3.1.11 The navigator shall allow a suitably privileged user to drag a DMS message from a message library to a DMS.

 

1

 

1

 

134

 

3.3.1.12 The navigator shall allow a suitably privileged user to drag a HAR message from a message library to a HAR.

 

1

 

2

 

135

 

3.3.1.13 The system shall allow a suitably privileged user to specify the message header and trailer for a specified HAR.

 

1

 

2

 

462

 

3.3.1.14 The navigator shall allow a suitably privileged user to drag a DMS message from a message library to a group of DMSs for display.

 

1

 

1

 

136

 

3.3.1.15 The system shall notify the initiating operator should an attempt to control a DMS fail.

 

1

 

1

 

137

 

3.3.1.16 The system shall notify the initiating operator should an attempt to control a HAR fail.

 

1

 

2

 

138

 

3.3.1.17 The navigator shall provide the capability to display the controller slots in use for a HAR.

 

1

 

2

 

719

 

3.3.1.18 The system shall notify all operators of successful DMS control activities by updating the run-time status information displayed in the navigator, and any windows that currently display the DMS message.

 

1

 

1

 

139

 

3.3.1.19 The system shall not exceed 20 seconds to update all active displays on the state of a displayed object after a state change in that object.

 

1

 

1

 

140

 

3.3.1.20 The system shall not exceed 20 seconds to update all active displays after a new display object has been added.

 

1

 

1

 

141

 

3.3.1.21 The system shall not exceed 20 seconds to update all active displays after a display object has been deleted.

 

1

 

1

 

142

 

3.3.2 Map Display

The map display provides the user with a visual representation of the status of the monitored roadways and devices. 

 

 

 

143

 

3.3.2.1 The map display shall show links.

 

 

 

388

 

3.3.2.2 The system shall provide the capability to update the CHART map from the MDOT GIS Map data.

 

 

 

403

 

3.3.2.3 The system shall provide a Map position location function.

 

 

 

440

 

3.3.2.3.1 The system shall provide the capability for the user to move the mouse over the Map and view an updating display of the cursor position in map coordinates.

 

 

 

441

 

3.3.2.3.2 The system shall provide the capability for the user to view position (distance and bearing) relative to a selected point.

 

 

 

443

 

3.3.2.3.3 The system shall provide the capability for the user to select the displayed position information for inclusion with an event entry.

 

 

 

442

 

3.3.2.3.4 The system shall provide the capability to build a database of map coordinates for selected landmarks along each highway.

 

 

 

444

 

3.3.2.3.5 The system shall provide the capability to capture a selected portion of the display for inclusion with an incident event.

 

 

 

603

 

3.3.2.3.5.1 The captured display graphic shall show the direction of travel lanes.

 

 

 

604

 

3.3.2.3.5.2 The captured display graphic shall show the number of lanes.

 

 

 

605

 

3.3.2.3.5.3 The captured display graphic shall show ramps, if any.

 

 

 

606

 

3.3.2.3.5.4 The captured display graphic shall show collection lanes, if any.

 

 

 

607

 

3.3.2.3.6 The system shall provide the capability for a user to select from a list of landmarks and have the cursor move to that position on the map display.

 

 

 

496

 

3.3.2.4 The map display shall have the capability to show the location of all CHART devices.

 

 

 

757

 

3.3.2.5 The map display shall provide the capability to show the location of all AVL equipped vehicles.

 

 

 

758

 

3.3.2.6 The map display shall support the display of independent map layers.

 

 

 

1071

 

3.3.2.6.1 The map display shall support a base map layer showing major Maryland highways.

 

 

 

1072

 

3.3.2.6.2 The map display shall support a device map layer.

 

 

 

1073

 

3.3.2.6.3 The map display shall support a weather map layer.

 

 

 

1074

 

3.3.2.6.4 The map display shall support an incident map layer.

 

 

 

1075

 

3.3.2.6.5 The map display shall support a lane closure map layer.

 

 

 

1076

 

3.3.2.6.6 The map display shall provide the capability for the user to filter a map layer in order to customize the display.

 

 

 

1077

 

3.4 Message Management

This section presents requirements for the construction and management of messages to be displayed or broadcast on CHART devices.  Message management requirements are divided into three areas.  Requirements for supported protocols and the formatting of messages are covered in Message Formats.  The system will support the grouping of messages into libraries as an aid to users in organizing messages.  Requirements for message libraries are presented the the section titled Message Libraries.  The system will support dictionaries for checking the spelling and content of messages.  Requirements for dictionary support are presented in the section titled Dictionaries.

 

 

 

144

 

3.4.1 Message Formats

This section presents requirements for the formatting of messages.

 

 

 

145

 

3.4.1.1 The system shall format DMS messages using the MULTI DMS mark-up language as specified in the NTCIP document ISO/WD 14823-2.

 

1

 

1

 

146

 

3.4.1.2 The system shall support  MULTI language tags.

 

1

 

1

 

156

 

3.4.1.2.1 The system shall support the New Page [np]  MULTI language tag. Used to specify a phase break

 

1

 

1

 

157

 

3.4.1.2.2 The system shall support the New Line [nlx]  MULTI language tag.  Used to specify a new line of text

 

1

 

1

 

158

 

3.4.1.2.3 The system shall support the Justification – line [jlx]  MULTI language tag. Used to specify the justification for the current line of text.

 

1

 

1

 

159

 

3.4.1.2.4 The system shall support the  Page timing [ptxoy] MULTI language tag. Used to specify the time-on and time-off in tenths of a second for a particular phase of a message.

 

1

 

1

 

160

 

3.4.1.3 The system shall format message text for display on a DMS.

 

1

 

1

 

147

 

3.4.1.3.1 All text lines shall be centered horizontally on the DMS.

 

1

 

1

 

148

 

3.4.1.3.2 Any phase (page on a sign display) with one line of text shall be displayed on the center line.

 

1

 

1

 

149

 

3.4.1.3.3 Any phase (page on a sign display) with two lines of text shall have that text displayed on lines one and three.

 

1

 

1

 

150

 

3.4.1.3.4 The phrase "Expect Delays" may be broken up between two lines.

 

1

 

1

 

151

 

3.4.1.3.5 The DMS message format The phrase "Stay Alert" may be broken up between two lines.

 

1

 

1

 

154

 

3.4.1.3.6 The system shall employ rules for formatting route type and route number information.

 

1

 

1

 

152

 

3.4.1.3.6.1 The system shall format onto one line the route information that contains the route type “MD”  followed by a space and another continuous string of characters.

 

1

 

1

 

390

 

3.4.1.3.6.2 The system shall format onto one line the route information that contains the route type “I”  followed by a space and another continuous string of characters.

 

1

 

1

 

391

 

3.4.1.3.6.3 The system shall format onto one line the route information that contains the route type “US”  followed by a space and another continuous string of characters.

 

1

 

1

 

392

 

3.4.1.3.6.4 The system shall format onto one line the route information that contains the route type “Ex”  followed by a space and another continuous string of characters.

 

1

 

1

 

393

 

3.4.1.3.6.5 The system shall format onto one line the route information that contains the route type “Exit”  followed by a space and another continuous string of characters.

 

1

 

1

 

394

 

3.4.1.3.6.6 The system shall keep the route direction “ N”  on the same line as the preceding route information.

 

1

 

1

 

395

 

3.4.1.3.6.7 The system shall keep the route direction “ S”  on the same line as the preceding route information.

 

1

 

1

 

396

 

3.4.1.3.6.8 The system shall keep the route direction “ E”  on the same line as the preceding route information.

 

1

 

1

 

397

 

3.4.1.3.6.9 The system shall keep the route direction “ W”  on the same line as the preceding route information.

 

1

 

1

 

398

 

3.4.1.3.6.10 The system shall place on a new line any route information that is lead by the route indicator “AT”.

 

1

 

1

 

399

 

3.4.1.3.6.11 The system shall place on a new line any route information that is lead by the route indicator “PRIOR”.

 

1

 

1

 

400

 

3.4.1.3.6.12 The system shall place on a new line any route information that is lead by the route indicator “PAST”.

 

1

 

1

 

401

 

3.4.1.3.7 Each DMS shall use only one font for displaying DMS messages.

 

1

 

1

 

155

 

3.4.1.3.8 The system shall enforce a default limit of two pages for DMS messages.

 

1

 

2

 

731

 

3.4.1.3.8.1 A suitably privileged user shall be able to create messages longer than two pages.

 

1

 

2

 

732

 

3.4.1.4 The system shall support the conversion of text to speech files compatible with standard audio formats.

 

1

 

2

 

161

 

3.4.1.5 The system shall support the recording of speech into files compatible with standard audio formats.

 

1

 

2

 

454

 

3.4.2 Message Libraries

This section presents requirements for the management of message libraries.

 

 

 

162

 

3.4.2.1 The system shall support message libraries.

 

1

 

1

 

163

 

3.4.2.1.1 The system shall support libraries containing DMS messages.

 

1

 

1

 

164

 

3.4.2.1.2 The system shall support libraries containing HAR messages.

 

1

 

2

 

165

 

3.4.2.1.2.1 The system shall support storing HAR messages in libraries in  text format.

 

1

 

2

 

455

 

3.4.2.1.2.2 The system shall support storing HAR messages in libraries in a standard audio format.

 

1

 

2

 

456

 

3.4.2.2 The system shall allow a suitably privileged user to create a new message library.

 

1

 

1

 

166

 

3.4.2.3 The system shall allow a suitably privileged user to delete a message library.

 

1

 

1

 

167

 

3.4.2.3.1 The deletion of a message library shall delete all messages stored in the library as well.

 

1

 

1

 

168

 

3.4.2.4 The system shall allow a suitably privileged user to change the name of a message library.

 

1

 

1

 

169

 

3.4.2.5 The system shall allow a suitably privileged user to create a new library message.

 

1

 

1

 

170

 

3.4.2.5.1 The system shall support setting the beacon state for a DMS library message.

 

1

 

1

 

674

 

3.4.2.5.2 The system shall support a message attribute indicating that a message is sign-specific and is only to be displayed on a specified sign.

 

 

 

1066

 

3.4.2.6 The system shall allow a suitably privileged user to delete a library message.

 

1

 

1

 

171

 

3.4.2.7 The system shall allow a suitably privileged user to modify the contents of a library message.

 

1

 

1

 

172

 

3.4.2.8 The system shall allow a suitably privileged user to change the name of a library message.

 

1

 

1

 

173

 

3.4.2.9 The system shall allow a suitably privileged user to display the contents of a library message.

 

1

 

1

 

673

 

3.4.2.9.1 The system shall allow the user to display attributes of a DMS library message.

 

1

 

1

 

798

 

3.4.2.9.1.1 The system shall display the message description for a DMS library message.

 

1

 

1

 

800

 

3.4.2.9.1.2 The system shall display the message text for a DMS library message.

 

1

 

1

 

801

 

3.4.2.9.1.3 The system shall display the message category for a DMS library message.

 

1

 

1

 

802

 

3.4.2.9.1.4 The system shall display the required message sign length for a DMS library message.

 

1

 

1

 

803

 

3.4.2.9.1.5 The system shall display the message beacon indicator for a DMS library message.

 

1

 

1

 

804

 

3.4.2.9.2 The system shall allow the user to display attributes of a HAR library message.

 

1

 

2

 

799

 

3.4.2.9.2.1 The system shall display the message description for a HAR library message.

 

1

 

2

 

805

 

3.4.2.9.2.2 The system shall display the message category for a HAR library message.

 

1

 

2

 

806

 

3.4.2.9.2.3 The system shall display the message length in minutes and seconds for a HAR library message.

 

1

 

2

 

807

 

3.4.2.10 The system shall allow a suitably privileged user to set a message on a DMS from a message stored in a DMS message library.

 

1

 

1

 

174

 

3.4.2.11 The system shall allow a suitably privileged user to set a message on a HAR from a message stored in a HAR message library.

 

1

 

2

 

175

 

3.4.2.12 The system shall not exceed 3 seconds to notify the initiating user that the library message could not be modified.

 

1

 

1

 

176

 

3.4.2.13 The system shall not exceed 3 seconds to notify the initiating user that the library message could not be deleted.

 

1

 

1

 

177

 

3.4.2.14 The system shall not exceed 3 seconds to notify the initiating user on an attempt to delete a library message that the message is being used in one or more plans.

 

1

 

1

 

178

 

3.4.2.15 The system shall not exceed 3 seconds to notify the initiating user that the message could not be added to the library.

 

1

 

1

 

179

 

3.4.2.16 The system shall not exceed 3 seconds to notify the initiating user that the library name could not be changed.

 

1

 

1

 

180

 

3.4.2.17 The system shall not exceed 3 seconds to notify the initiating user that the library could not be deleted.

 

1

 

1

 

181

 

3.4.2.18 The system shall not exceed 3 seconds to notify the initiating user that the library could not be created.

 

1

 

1

 

182

 

3.4.2.19 The system shall log operations messages associated with Message Library management.

 

1

 

1

 

298

 

3.4.2.19.1 The system shall log a message for Message Library creation.

 

1

 

1

 

299

 

3.4.2.19.2 The system shall log a message for Message Library deletion.

 

1

 

1

 

300

 

3.4.2.19.3 The system shall log a message for Change to the Message Libraries.

 

1

 

1

 

301

 

3.4.2.19.3.1 The system shall log a message for the addition of a message to a Message Library.

 

1

 

1

 

302

 

3.4.2.19.3.2 The system shall log a message for the deletion of a message from a Message Library.

 

1

 

1

 

303

 

3.4.3 Dictionaries

This section presents requirements on the use of dictionaries for checking message content.

 

 

 

183

 

3.4.3.1 The system shall support the use of dictionaries for checking words in messages.

 

1

 

1

 

184

 

3.4.3.1.1 The system shall support a banned words dictionary.

 

1

 

1

 

185

 

3.4.3.1.1.1 The system shall support a banned words dictionary for DMS devices.

 

1

 

1

 

772

 

3.4.3.1.1.2 The system shall support a banned words dictionary for HAR devices.

 

1

 

2

 

773

 

3.4.3.1.2 The system shall support a dictionary for spell checking messages.

 

1

 

2

 

186

 

3.4.3.1.2.1 The system shall support a spell check dictionary for DMS devices.

 

1

 

2

 

774

 

3.4.3.1.2.2 The system shall support a spell check dictionary for HAR devices.

 

1

 

2

 

775

 

3.4.3.1.3 The system shall support the option of enabling a dictionary on an individual user basis.

 

1

 

2

 

187

 

3.4.3.1.4 Messages checked against a banned words dictionary shall be rejected if any word in the message matches a word in the dictionary.

 

1

 

1

 

188

 

3.4.3.1.5 A word checked against a spell check dictionary shall be flagged if the word does not match a word in the dictionary.

 

1

 

2

 

189

 

3.4.3.1.5.1 A flagged word shall require user action before a message is accepted.

 

1

 

2

 

704

 

3.4.3.1.5.1.1 User action for a flagged word shall include the option of selecting a word from a pick list of suggested words to correct the flagged word.

 

1

 

2

 

705

 

3.4.3.1.5.1.2 User action for a flagged word shall include allowing a suitably privileged user to add the flagged word to the spell check dictionary.

 

1

 

2

 

706

 

3.4.3.1.5.1.3 User action for a flagged word shall include allowing the user to ignore the flagged word and continue.

 

1

 

2

 

707

 

3.4.3.2 The system shall have the capability to check all text messages on input against a dictionary before sending the message to the field.

 

1

 

1

 

190

 

3.4.3.3 The system shall have the capability to check all text messages on input against a dictionary before storing the message in a message library.

 

1

 

1

 

191

 

3.4.3.4 The system shall allow a suitably privileged user to add a new list of words to a dictionary.

 

1

 

1

 

192

 

3.4.3.5 The system shall allow a suitably privileged user to remove a word from a dictionary.

 

1

 

1

 

193

 

3.4.3.6 The system shall not exceed 3 seconds to notify the user that a message contains banned words.

 

1

 

1

 

195

 

3.4.3.7 The system shall not exceed 3 seconds to provide the suitably privileged initiating user with a list of dictionary words.

 

1

 

1

 

196

 

3.4.3.8 The system shall not exceed 5 seconds to notify the user that the word(s) were added to the dictionary.

 

1

 

1

 

197

 

3.4.3.9 The system shall not exceed 3 seconds to notify the user that a word could not be added to the dictionary.

 

1

 

1

 

198

 

3.4.3.10 The system shall require a user with privileges to access the banned words dictionary to re-enter their password prior to allowing them to view the banned words dictionary.

 

1

 

1

 

676

 

3.5 Plans

Plans are collections of actions to be executed as a group.  The CHART II system will support the creation of plan libraries and the execution of plans by users, and automatically in response to system events.

 

 

 

199

 

3.5.1 Plan Management

This section present requirements on the management of plan libraries.

 

 

 

200

 

3.5.1.1 The system shall allow a suitably privileged user to create a plan.

 

1

 

1

 

201

 

3.5.1.1.1 The plan shall include the plan description.

 

1

 

1

 

202

 

3.5.1.1.2 The plan shall include a list of actions to implement.

 

1

 

1

 

203

 

3.5.1.1.2.1 The allowable plan item actions shall include putting a library message on a DMS.

 

1

 

1

 

204

 

3.5.1.1.2.2 The allowable plan item actions shall include putting a library message on a HAR.

 

1

 

2

 

205

 

3.5.1.1.2.3 The allowable plan item actions shall include sending an email.

 

 

 

1078

 

3.5.1.1.2.4 The allowable plan item actions shall include sending a page.

 

 

 

1079

 

3.5.1.1.2.5 The allowable plan item actions shall include sending a fax.

 

 

 

1080

 

3.5.1.1.2.6 The allowable plan item actions shall include generating a report.

 

 

 

1081

 

3.5.1.2 The system shall allow a suitably privileged user to modify a plan.

 

1

 

1

 

206

 

3.5.1.3 The system shall allow a suitably privileged user to delete a plan.

 

1

 

1

 

207

 

3.5.1.4 The system shall not exceed 5 seconds to notify the initiating user that a plan was successfully added.

 

1

 

1

 

208

 

3.5.1.5 The system shall not exceed 5 seconds to notify the initiating user that a plan was successfully modified.

 

1

 

1

 

209

 

3.5.1.6 The system shall not exceed 5 seconds to notify the initiating user that a plan could not be created.

 

1

 

1

 

210

 

3.5.1.7 The system shall not exceed 3 seconds to notify the initiating user that a plan could not be modified.

 

1

 

1

 

211

 

3.5.1.8 The system shall not exceed 5 seconds in displaying a list of messages and message libraries to the initiating user when the user creates a new plan.

 

1

 

1

 

212

 

3.5.1.9 The system shall not exceed 3 seconds in displaying a list of messages and message libraries to the initiating user when the user modifies an existing plan.

 

1

 

1

 

213

 

3.5.1.10 The system shall log operations messages associated with Plan management.

 

1

 

1

 

304

 

3.5.1.10.1 The system shall log a message to the operations log for Adding a Plan.

 

1

 

1

 

305

 

3.5.1.10.2 The system shall log a message to the operations log for Modifying a Plan.

 

1

 

1

 

306

 

3.5.1.10.3 The system shall log a message to the operations log  for Deleting a Plan.

 

1

 

1

 

307

 

3.5.1.10.4 The system shall log a message to the operations log for Activation of a Plan.

 

1

 

1

 

308

 

3.5.1.10.5 The system shall log a message to the operations log for the Completion of a Plan.

 

 

 

309

 

3.5.2 Plan Activation

This section presents requirements on the execution of plans.  Plans are executed either manually by a user or automatically by the system in response to an event.

 

 

 

214

 

3.5.2.1 The system shall allow a suitably privileged user to activate a plan.

 

1

 

1

 

215

 

3.5.2.2 The system shall not exceed 3 seconds to notify the initiating user that a plan could not be activated.

 

1

 

1

 

216

 

3.5.2.3 Upon plan activation the system shall sequentially execute each plan item.

 

1

 

1

 

675

 

3.5.2.4 The system shall support the automatic initiation of an associated response plan, if any, when detector data indicate congested flow or a potential incident.

 

 

 

782

 

3.5.2.4.1 The system shall support the dynamic creation of messages for broadcast as part of a response plan.

 

 

 

784

 

3.5.2.4.2 The system shall include DMS and HAR devices in the response plan based on distance from the detector.

 

 

 

785

 

3.5.2.4.3 The system shall support a configuration parameter specifying that an operator is to be alerted that a response plan has gone into effect.

 

 

 

787

 

3.5.2.5 The system shall support a configuration parameter specifying whether a response plan requires operator confirmation before being executed by the system.

 

 

 

786

 

3.5.2.5.1 If operator confirmation is required for a response plan the system shall send an alert to the Center responsible for the detector that triggered the response.

 

 

 

788

 

3.5.2.5.2 The system shall provide the capability for the operator to modify the response plan.

 

 

 

809

 

3.5.2.5.3 The system shall display the open congestion event when the operator acknowledges a congestion response plan alert.

 

 

 

808

 

3.5.2.5.4 The system shall display the open incident event when the operator acknowledges an incident response plan alert.

 

 

 

811

 

3.5.2.5.4.1 The system shall transfer control and video of the nearest camera to the incident to the operator that acknowledges the incident event.

 

 

 

813

 

3.5.2.6 The system shall allow a suitably privileged user to deactivate a plan.

 

 

 

866

 

3.5.2.7 Upon plan deactivation the system shall remove device queue entries associated with the plan.

 

 

 

867

 

3.6 Traffic and Roadway Monitoring

Traffic and roadway monitoring includes the monitoring of traffic speeds and volumes and the monitoring of roadway weather conditions.

 

 

 

217

 

3.6.1 Detector Data Monitoring

This section lists requirements for the handling of detector data.  Detector data consists of the data received from traffic monitoring detectors as well as the traffic data received from traffic signal devices.

 

 

 

218

 

3.6.1.1 The system shall provide the capability to display a comparison of current detector data and historical detector data.

 

 

 

421

 

3.6.1.1.1 The user shall be able to select the time period for the comparison of current detector and historical detector data.

 

 

 

422

 

3.6.1.1.2 The user shall be able to select the detectors for the comparison of current detector and historical detector data.

 

 

 

423

 

3.6.1.2 The system shall have the capability to calculate queue length from detector data.

 

 

 

613

 

3.6.1.2.1 The system shall support calculating queue length in real time at the polling frequency of the detector.

 

 

 

615

 

3.6.1.3 The system shall  provide the capability to evaluate detector data for congestion and incident detection.

 

 

 

779

 

3.6.1.3.1 The system shall open a congestion event when detector data indicates congested flow.

 

 

 

780

 

3.6.1.3.2 The system shall open an incident event when detector data indicates a potential incident.

 

 

 

781

 

3.6.1.3.3 The system shall provide the capability for the operator to specify a delay period before another alert is triggered from the same detector.

 

 

 

810

 

3.6.1.3.4 The system shall close a system-generated congestion event when the evaluation of detector data indicates that traffic flow is no longer congested.

 

 

 

783

 

3.6.1.4 The system shall provide the capability to evaluate probe data.

 

 

 

1082

 

3.6.1.5 The system shall provide the capability to evaluate vehicle classification data.

 

 

 

1083

 

3.6.2 Weather Sensor Data Monitoring

This section lists requirements for the handling of weather sensor data.

 

 

 

219

 

3.6.2.1 The system shall support the capability to periodically retrieve weather sensor data from the SCAN database.

 

 

 

923

 

3.6.2.1.1 The system shall archive SCAN weather sensor data.

 

 

 

1051

 

3.6.2.1.2 The system shall provide the capability to generate alerts for poor weather or roadway conditions.

 

 

 

926

 

3.6.2.1.3 The system shall provide the capability to generate a weather sensor response plan if poor weather or roadway conditions are detected.

 

 

 

927

 

3.6.2.1.3.1 The system shall support the dynamic creation of weather condition specific messages for broadcast as part of a response plan.

 

 

 

929

 

3.6.2.1.4 The system shall support the automatic initiation of an associated weather sensor response plan, if any, when sensor data indicate poor weather or roadway conditions.

 

 

 

928

 

3.6.2.1.4.1 The system shall support including DMS and HAR messages associated with the sensor in the response plan.

 

 

 

930

 

3.6.2.1.4.2 The system shall support a configuration parameter specifying that an operator is to be alerted that a weather sensor response plan has gone into effect.

 

 

 

931

 

3.6.2.1.5 The system shall support a configuration parameter specifying whether a weather sensor response plan requires operator confirmation before being executed by the system.

 

 

 

932

 

3.6.2.1.5.1 If operator confirmation is required for a response plan the system shall send an alert to the Center responsible for the weather sensor that triggered the response.

 

 

 

933

 

3.6.2.1.5.2 The system shall display the open weather sensor event when the operator acknowledges a weather sensor response plan alert.

 

 

 

934

 

3.6.2.1.5.2.1 The system shall provide the capability for the operator to modify the weather sensor response plan.

 

 

 

935

 

3.6.2.1.5.2.2 The system shall provide the capability for the operator to specify a delay period before another weather sensor alert is triggered from the same sensor.

 

 

 

936

 

3.6.2.2 The system shall support the capability to retrieve weather sensor device status from the SCAN database.

 

 

 

924

 

3.6.2.2.1 The system shall log weather sensor device failure information to the operations log.

 

 

 

925

 

3.7 Activity Management

One of the primary responsibilities of the CHART II system is to assist the operators in traffic management activities and to maintain a record of system and operator actions associated with these activities.  The repository for this information is the event log.  An event log entry is a collection of system or user generated messages that result from managing some event (e.g. clearing a disabled vehicle).

 

 

 

220

 

3.7.1 Activity Queues

This section lists requirements for the management and control of queues for prioritizing activities.

 

 

 

221

 

3.7.1.1 The system shall support the queueing of messages to DMS devices.

 

 

 

222

 

3.7.1.2 The system shall support the queueing of messages to HAR devices.

 

 

 

223

 

3.7.1.3 Messages shall be ordered in a queue based on their priority.

 

 

 

224

 

3.7.1.4 A message entering a device queue with a higher priority than the current message on the device shall preempt the current message.

 

 

 

225

 

3.7.1.5 A message entering a device queue with the same priority as the current message shall preempt the current message if the associated event is closer to the device than the current message event.

 

 

 

771

 

3.7.1.6 A preempted message shall be returned to the device queue.

 

 

 

226

 

3.7.1.6.1 The system shall log a message to the operations log when a message is preempted.

 

 

 

794

 

3.7.1.7 The system shall maintain attributes for messages in a device queue.

 

 

 

790

 

3.7.1.7.1 Device queue message attributes shall include the event the message is associated with.

 

 

 

791

 

3.7.1.7.2 Device queue message attributes shall include the Center responsible for the message.

 

 

 

792

 

3.7.1.8 The system shall support the assignment of priorities to queued messages based on the message type/source.

 

 

 

227

 

3.7.1.8.1 The system shall support a message type/source of Incident - Operator Control.

 

 

 

228

 

3.7.1.8.2 The system shall support a message type/source of Incident - System Control.

 

 

 

229

 

3.7.1.8.3 The system shall support a message type/source of Roadwork - Operator Control.

 

 

 

230

 

3.7.1.8.4 The system shall support a message type/source of Congestion - Operator Control.

 

 

 

231

 

3.7.1.8.5 The system shall support a message type/source of Weather Alert - Operator Control.

 

 

 

232

 

3.7.1.8.6 The system shall support a message type/source of Special Event - Operator Control.

 

 

 

233

 

3.7.1.8.7 The system shall support a message type/source of Recurring Congestion - Operator Control.

 

 

 

234

 

3.7.1.8.8 The system shall support a message type/source of Congestion - System Control.

 

 

 

235

 

3.7.1.8.9 The system shall support a message type/source of Weather Alert - System Control.

 

 

 

236

 

3.7.1.8.10 The system shall support a message type/source of Special Event - System Control.

 

 

 

237

 

3.7.1.8.11 The system shall support a message type/source of Recurring Congestion - System Control.

 

 

 

238

 

3.7.1.8.12 The system shall support a message type/source of Safety Message - Operator Control.

 

 

 

239

 

3.7.1.8.13 The system shall support a message type/source of Safety Message - System Control.

 

 

 

240

 

3.7.1.8.14 The system shall support a message type/source of DMS as SHAZAM - Operator Control.

 

 

 

241

 

3.7.1.8.15 The system shall support a message type/source of DMS as SHAZAM - System Control.

 

 

 

242

 

3.7.1.9 The assignment of priorities to event types shall be a system configuration item.

 

 

 

243

 

3.7.1.10 A suitably privileged user shall be able to modify the priority of a message in a queue.

 

 

 

244

 

3.7.2 Events

The system provides logging capabilities for operators to record and share information about communications, disabled vehicles, required actions, congestion, and incidents.  Logs may be system or operator initiated.

 

 

 

245

 

3.7.2.1 Event Management

This section presents general requirements related to the management of events.

 

 

 

246

 

3.7.2.1.1 The system shall store identifying information with each event.

 

1

 

2

 

268

 

3.7.2.1.1.1 The system shall store the Date/time with each event entry.

 

1

 

2

 

269

 

3.7.2.1.1.1.1 The system shall store the system date/time of the creation of the entry.

 

1

 

2

 

735

 

3.7.2.1.1.1.2 The system shall store the operator entered date/time for an entry (defaults to system date/time).

 

1

 

2

 

736

 

3.7.2.1.1.2 The system shall store the source Workstation Identifier (if applicable) with each event entry.

 

1

 

2

 

270

 

3.7.2.1.1.3 The system shall store a searchable category type identifying the type of entry with each event entry.

 

1

 

2

 

271

 

3.7.2.1.1.4 The system shall store the User name of initiating user, or the identifier of the initiating application if system generated, with each event entry.

 

1

 

2

 

272

 

3.7.2.1.1.5 The system shall store the associated Center with each event entry.

 

1

 

2

 

433

 

3.7.2.1.1.6 The system shall store the Textual description of action taken with each event entry.

 

1

 

2

 

273

 

3.7.2.1.1.7 The system shall store location information identifying the location of the event with each event entry.

 

1

 

2

 

466

 

3.7.2.1.1.7.1 The system shall support capturing event location information in a descriptive text format.

 

1

 

2

 

467

 

3.7.2.1.1.7.2 The system shall support capturing event location information in latitude and longitude.

 

 

 

468

 

3.7.2.1.1.8 The system shall store an identifier for the source of notification of the event with each event entry.

 

1

 

2

 

485

 

3.7.2.1.2 The system shall have the capability to store events in the online system for at least 14 days.

 

1

 

2

 

248

 

3.7.2.1.2.1 Open events shall not be removed from the online system.

 

1

 

2

 

657

 

3.7.2.1.2.2 Closed events shall be removed from the online system after a system specified time has elapsed since closure.

 

1

 

2

 

658

 

3.7.2.1.3 All event information shall be retained in a searchable archival form.

 

 

 

249

 

3.7.2.1.4 The system shall allow a suitably privileged user to create a new event.

 

1

 

2

 

260

 

3.7.2.1.4.1 The system shall record the date/time of creation of an event.

 

1

 

2

 

659

 

3.7.2.1.5 The system shall allow a suitably privileged user to close an open event.

 

1

 

2

 

262

 

3.7.2.1.5.1 The system shall record the date/time of closure for an event.

 

1

 

2

 

263

 

3.7.2.1.5.2 The system shall allow a user to append additional information to a closed event.

 

1

 

2

 

264

 

3.7.2.1.5.2.1 Information appended to a closed event shall be identified as such.

 

1

 

2

 

737

 

3.7.2.1.5.3 When an event is closed the system shall remove all messages from devices and device queues associated with the event.

 

 

 

265

 

3.7.2.1.5.4 When an event is closed the system shall release all allocated camera resources.

 

 

 

463

 

3.7.2.1.5.5 An open event shall be closed only by the Center having responsibility for the event.

 

1

 

2

 

437

 

3.7.2.1.5.6 The system shall send a message to EORS on closure of an EORS-related event.

 

 

 

438

 

3.7.2.1.6 The system shall support changing an event from one event type to another type.

 

1

 

2

 

266

 

3.7.2.1.6.1 The system shall record a message associated with the event for change of event type.

 

1

 

2

 

267

 

3.7.2.1.7 The management of an open event shall be under the control of the responsible Center.

 

1

 

2

 

382

 

3.7.2.1.7.1 The system shall support the transfer of responsibility for an open event from one Center to another.

 

1

 

2

 

383

 

3.7.2.1.7.2 The system shall support the capability for more than one user to work on an open event.

 

1

 

2

 

484

 

3.7.2.1.8 The current state of an event in the online system shall be preserved through a system shutdown/crash and startup cycle.

 

1

 

2

 

525

 

3.7.2.1.9 The system shall provide the capability to view stored event information.

 

1

 

2

 

434

 

3.7.2.1.9.1 The system shall provide a search capability allowing a user to search for a specific event entry.

 

1

 

2

 

435

 

3.7.2.1.9.2 The system shall provide a filtering capability to allow a user to select a specified set of event entries.

 

1

 

2

 

436

 

3.7.2.1.9.2.1 The filtering capability shall include event state (open or closed).

 

1

 

2

 

635

 

3.7.2.1.9.2.2 The filtering capability shall include Center.

 

 

 

636

 

3.7.2.1.9.2.3 The filtering capability shall include event type.

 

 

 

637

 

3.7.2.1.10 The system shall provide the capability for the user to record freeform text comments with an event entry.

 

1

 

2

 

558

 

3.7.2.1.11 The system shall provide the capability for the user to select the Notification function from within an event management GUI.

 

 

 

569

 

3.7.2.1.11.1 The system shall record individual level notifications associated with an event in the corresponding event log.

 

 

 

452

 

3.7.2.1.12 The system shall have the capability to generate a reminder alert when an event has remained open past a system specified time limit.

 

 

 

616

 

3.7.2.1.12.1 The reminder alert for an open event shall be displayed on workstations logged into the Center that has responsibility for the event.

 

 

 

617

 

3.7.2.1.12.2 The system shall provide the user with the capability to change the reminder timing from the reminder alert dialog.

 

 

 

618

 

3.7.2.1.13 The system shall provide the capability to associate one or more events with another event.

 

1

 

2

 

777

 

3.7.2.2 Event Types

This section presents requirements for specific event types and the information to be recorded for each type of event.

 

 

 

595

 

3.7.2.2.1 The system shall maintain a record of disabled vehicle events.

 

1

 

2

 

251

 

3.7.2.2.1.1 The system shall record disabled vehicle event attributes.

 

1

 

2

 

577

 

3.7.2.2.1.1.1 The list of disabled vehicle event attributes shall include Tire Change.

 

1

 

2

 

585

 

3.7.2.2.1.1.2 The list of disabled vehicle event attributes shall include Hot Shot.

 

1

 

2

 

586

 

3.7.2.2.1.1.3 The list of disabled vehicle event attributes shall include Water.

 

1

 

2

 

587

 

3.7.2.2.1.1.4 The list of disabled vehicle event attributes shall include Gas.

 

1

 

2

 

588

 

3.7.2.2.1.1.5 The list of disabled vehicle event attributes shall include Directions.

 

1

 

2

 

589

 

3.7.2.2.1.1.6 The list of disabled vehicle event attributes shall include Own Disposition.

 

1

 

2

 

590

 

3.7.2.2.1.1.7 The list of disabled vehicle event attributes shall include Call for Service.

 

1

 

2

 

591

 

3.7.2.2.1.1.8 The list of disabled vehicle event attributes shall include Gone on Arrival.

 

1

 

2

 

592

 

3.7.2.2.1.1.9 The list of disabled vehicle event attributes shall include Relay Operator.

 

1

 

2

 

733

 

3.7.2.2.1.1.10 The list of disabled vehicle event attributes shall include Abandoned Vehicle.

 

1

 

2

 

734

 

3.7.2.2.1.1.11 The list of disabled vehicle event attributes shall include Other.

 

1

 

2

 

593

 

3.7.2.2.1.2 The system shall record the disabled vehicle event state.

 

1

 

2

 

578

 

3.7.2.2.1.2.1 The disabled vehicle event state shall include Open.

 

1

 

2

 

579

 

3.7.2.2.1.2.2 The disabled vehicle event state shall include Units Dispatched.

 

1

 

2

 

580

 

3.7.2.2.1.2.3 The disabled vehicle event state shall include Units On Scene.

 

1

 

2

 

581

 

3.7.2.2.1.2.4 The disabled vehicle event state shall include Scene Cleared.

 

1

 

2

 

582

 

3.7.2.2.1.2.5 The disabled vehicle event state shall include Closed.

 

1

 

2

 

584

 

3.7.2.2.1.3 The system shall provide the capability to record the identification of the unit(s) dispatched for the disabled vehicle event.

 

1

 

2

 

594

 

3.7.2.2.1.4 The system shall provide the capability to record the state of issue and license plate number of the disabled vehicle.

 

1

 

2

 

700

 

3.7.2.2.2 The system shall maintain a record of action events.

 

1

 

2

 

252

 

3.7.2.2.2.1 The system shall record action attributes.

 

1

 

2

 

564

 

3.7.2.2.2.1.1 The list of action attributes shall include Signal.

 

1

 

2

 

565

 

3.7.2.2.2.1.2 The list of action attributes shall include Debris.

 

1

 

2

 

566

 

3.7.2.2.2.1.3 The list of action attributes shall include Utility.

 

1

 

2

 

567

 

3.7.2.2.2.1.4 The list of action attributes shall include Other.

 

1

 

2

 

568

 

3.7.2.2.2.2 The system shall record the action state.

 

1

 

2

 

570

 

3.7.2.2.2.2.1 The action state shall include Open.

 

1

 

2

 

571

 

3.7.2.2.2.2.2 The action state shall include Units Dispatched.

 

1

 

2

 

572

 

3.7.2.2.2.2.3 The action state shall include Units On Scene.

 

1

 

2

 

573

 

3.7.2.2.2.2.4 The action state shall include Scene Cleared.

 

1

 

2

 

574

 

3.7.2.2.2.2.5 The action state shall include Delay Cleared.

 

1

 

2

 

575

 

3.7.2.2.2.2.6 The action state shall include Closed.

 

1

 

2

 

576

 

3.7.2.2.3 The system shall maintain a record of incident events.

 

1

 

2

 

253

 

3.7.2.2.3.1 The system shall record incident attributes.

 

1

 

2

 

424

 

3.7.2.2.3.1.1 The list of incident attributes shall include Disabled in Roadway.

 

1

 

2

 

533

 

3.7.2.2.3.1.2 The list of incident attributes shall include Personal Injury.

 

1

 

2

 

534

 

3.7.2.2.3.1.3 The list of incident attributes shall include Property Damage.

 

1

 

2

 

535

 

3.7.2.2.3.1.4 The list of incident attributes shall include Fatality.

 

1

 

2

 

536

 

3.7.2.2.3.1.5 The list of incident attributes shall include Debris in Roadway.

 

1

 

2

 

537

 

3.7.2.2.3.1.6 The list of incident attributes shall include Roadwork.

 

1

 

2

 

538

 

3.7.2.2.3.1.7 The list of incident attributes shall include Vehicle Fire.

 

1

 

2

 

539

 

3.7.2.2.3.1.8 The list of incident attributes shall include Maintenance.

 

1

 

2

 

540

 

3.7.2.2.3.1.9 The list of incident attributes shall include Signal Call.

 

1

 

2

 

541

 

3.7.2.2.3.1.10 The list of incident attributes shall include Police Activity.

 

1

 

2

 

542

 

3.7.2.2.3.1.11 The list of incident attributes shall include Off Road Activity.

 

1

 

2

 

543

 

3.7.2.2.3.1.12 The list of incident attributes shall include Declaration of Emergency.

 

1

 

2

 

544

 

3.7.2.2.3.1.13 The list of incident attributes shall include Weather.

 

1

 

2

 

545

 

3.7.2.2.3.1.14 The list of incident attributes shall include Other.

 

1

 

2

 

546

 

3.7.2.2.3.2 The system shall record the incident state.

 

1

 

2

 

526

 

3.7.2.2.3.2.1 The incident state shall include Open.

 

1

 

2

 

527

 

3.7.2.2.3.2.2 The incident state shall include Units Dispatched.

 

1