coordinated
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
 |
coordinated
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
|
|
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
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.
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.
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.
|
Rel |
Bld |
Object Id |
|
3.1 System Administration, Configuration, and OperationThis section lists requirements for the administration, configuration, and operation of the CHART II system.
|
|
|
5
|
3.1.1 AdministrationThe 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 OperationsThis 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 InventoryThe 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 GenerationThis 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 ManagementThis 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 ManagementThis 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 DeviceThis 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 SignsThis 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 RadiosThis 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 CamerasThis 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 DetectorsThis 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 SignalsThis 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 LocationThis 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 ManagementThis 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 NavigatorThe 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 DisplayThe 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 ManagementThis 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 FormatsThis 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 LibrariesThis 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 DictionariesThis 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 PlansPlans 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 ManagementThis 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 ActivationThis 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 MonitoringTraffic and roadway monitoring includes the monitoring of traffic speeds and volumes and the monitoring of roadway weather conditions.
|
|
|
217
|
3.6.1 Detector Data MonitoringThis 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 MonitoringThis 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 ManagementOne 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 QueuesThis 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 EventsThe 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 ManagementThis 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 TypesThis 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
|
2
|
528
|
|
3.7.2.2.3.2.3 The incident state shall include Units On Scene.
|
1
|
2
|
529
|
|
3.7.2.2.3.2.4 The incident state shall include Scene Cleared.
|
1
|
2
|
530
|
|
3.7.2.2.3.2.5 The incident state shall include Delay Cleared.
|
1
|
2
|
531
|
|
3.7.2.2.3.2.6 The incident state shall include Closed.
|
1
|
2
|
532
|
3.7.2.2.3.3 The system shall record which agencies are involved with the incident.
|
1
|
2
|
547
|
|
3.7.2.2.3.3.1 The system shall record whether an agency was notified of the incident.
|
1
|
2
|
548
|
|
3.7.2.2.3.3.2 The system shall record whether an agency responded to the incident.
|
1
|
2
|
549
|
|
3.7.2.2.3.3.3 The list of agencies involved with an incident shall include CHART Vehicle.
|
1
|
2
|
550
|
|
3.7.2.2.3.3.4 The list of agencies involved with an incident shall include Fireboard.
|
1
|
2
|
551
|
|
3.7.2.2.3.3.5 The list of agencies involved with an incident shall include Local Police.
|
1
|
2
|
552
|
|
3.7.2.2.3.3.6 The list of agencies involved with an incident shall include MDE.
|
1
|
2
|
553
|
|
3.7.2.2.3.3.7 The list of agencies involved with an incident shall include MDTA - Maintenance.
|
1
|
2
|
554
|
|
3.7.2.2.3.3.8 The list of agencies involved with an incident shall include SHA - Maintenance.
|
1
|
2
|
555
|
|
3.7.2.2.3.3.9 The list of agencies involved with an incident shall include State Police.
|
1
|
2
|
556
|
|
3.7.2.2.3.3.10 The list of agencies involved with an incident shall include MDTA Police.
|
1
|
2
|
557
|
3.7.2.2.3.4 The system shall record whether HAZMAT materials were involved in the incident.
|
1
|
2
|
489
|
3.7.2.2.3.5 The system shall record whether traffic lanes were closed for the incident.
|
1
|
2
|
490
|
|
3.7.2.2.3.5.1 The system shall record the date/time a lane is closed.
|
1
|
2
|
491
|
|
3.7.2.2.3.5.2 The system shall record the date/time a lane is opened.
|
1
|
2
|
492
|
3.7.2.2.3.6 The system shall provide the capability to display a roadway graphic for an incident event entry.
|
|
|
493
|
|
3.7.2.2.3.6.1 The roadway graphic shall support displaying the status of each lane.
|
|
|
494
|
|
3.7.2.2.3.6.2 The system shall provide the capability for the user to make annotations on the roadway graphic.
|
|
|
495
|
|
3.7.2.2.3.6.3 The system shall provide the capability for the user to click on areas of the roadway graphic in order to change the state of a lane.
|
|
|
519
|
3.7.2.2.3.7 The system shall record the types of vehicles involved.
|
1
|
2
|
497
|
|
3.7.2.2.3.7.1 The system shall record if a vehicle was jack-knifed.
|
1
|
2
|
498
|
|
3.7.2.2.3.7.2 The system shall record if a vehicle lost load.
|
1
|
2
|
499
|
|
3.7.2.2.3.7.3 The system shall record if a vehicle was overturned.
|
1
|
2
|
500
|
3.7.2.2.3.8 The system shall record the type of special needs for the incident.
|
1
|
2
|
520
|
|
3.7.2.2.3.8.1 The list of special needs for an incident shall include HAZMAT.
|
1
|
2
|
521
|
|
3.7.2.2.3.8.2 The list of special needs for an incident shall include Medivac.
|
1
|
2
|
522
|
|
3.7.2.2.3.8.3 The list of special needs for an incident shall include Investigation.
|
1
|
2
|
523
|
|
3.7.2.2.3.8.4 The list of special needs for an incident shall include Signal Operations.
|
1
|
2
|
524
|
|
3.7.2.2.3.8.5 The system shall include the special needs section from SHA Incident Report Form SHA.52.4-1 in the incident log.
|
1
|
2
|
501
|
3.7.2.2.3.9 The system shall record the weather conditions at the time of the incident.
|
1
|
2
|
502
|
3.7.2.2.3.10 The system shall record the types of resources used for the incident.
|
1
|
2
|
503
|
|
3.7.2.2.3.10.1 The system shall record the number of each type of resource used for the incident.
|
1
|
2
|
504
|
|
3.7.2.2.3.10.2 The system shall record the date/time of notification of need for each resource used for the incident.
|
1
|
2
|
505
|
|
3.7.2.2.3.10.3 The system shall record the date/time of arrival on scene for each resource used for the incident.
|
1
|
2
|
506
|
|
3.7.2.2.3.10.4 The system shall record the date/time of departure from scene for each resource used for the incident.
|
1
|
2
|
507
|
|
3.7.2.2.3.10.5 The list of resources for use for an incident shall include Arrow Board.
|
1
|
2
|
508
|
|
3.7.2.2.3.10.6 The list of resources for use for an incident shall include Dump Truck.
|
1
|
2
|
509
|
|
3.7.2.2.3.10.7 The list of resources for use for an incident shall include ERU.
|
1
|
2
|
510
|
|
3.7.2.2.3.10.8 The list of resources for use for an incident shall include ETP/VRT.
|
1
|
2
|
511
|
|
3.7.2.2.3.10.9 The list of resources for use for an incident shall include Light Plant.
|
1
|
2
|
512
|
|
3.7.2.2.3.10.10 The list of resources for use for an incident shall include Loader.
|
1
|
2
|
513
|
|
3.7.2.2.3.10.11 The list of resources for use for an incident shall include Portable DMS.
|
1
|
2
|
514
|
|
3.7.2.2.3.10.12 The list of resources for use for an incident shall include Sand Truck.
|
1
|
2
|
515
|
|
3.7.2.2.3.10.13 The list of resources for use for an incident shall include Sweeper.
|
1
|
2
|
516
|
|
3.7.2.2.3.10.14 The list of resources for use for an incident shall include FITM.
|
1
|
2
|
517
|
|
3.7.2.2.3.10.15 The list of resources for use for an incident shall include Other.
|
1
|
2
|
518
|
3.7.2.2.3.11 The system shall record the date/time that traffic flow is restored.
|
1
|
2
|
439
|
3.7.2.2.3.12 The system shall provide the capability to record traffic queue length.
|
|
|
608
|
|
3.7.2.2.3.12.1 The system shall support the manual entering of queue length data.
|
|
|
609
|
|
3.7.2.2.3.12.2 The system shall support the automatic recording of queue length data.
|
|
|
610
|
|
3.7.2.2.3.12.3 The system shall support recording of queue length data in the direction of the roadway having the incident.
|
|
|
611
|
|
3.7.2.2.3.12.4 The system shall support recording of queue length data in the opposite direction of the roadway having the incident.
|
|
|
612
|
|
3.7.2.2.3.12.5 The system shall support an updating display of queue length data for an open incident.
|
|
|
614
|
3.7.2.2.4 The system shall maintain a record of non-recurring congestion events.
|
1
|
2
|
254
|
3.7.2.2.4.1 The system shall record the non-recurring congestion event state.
|
1
|
2
|
638
|
|
3.7.2.2.4.1.1 The non-recurring congestion event state shall include Open.
|
1
|
2
|
639
|
|
3.7.2.2.4.1.2 The non-recurring congestion event state shall include Closed.
|
1
|
2
|
640
|
3.7.2.2.5 The system shall maintain a record of recurring congestion events.
|
1
|
2
|
255
|
3.7.2.2.5.1 The system shall record the recurring congestion event state.
|
1
|
2
|
641
|
|
3.7.2.2.5.1.1 The recurring congestion event state shall include Open.
|
1
|
2
|
642
|
|
3.7.2.2.5.1.2 The recurring congestion event state shall include Closed.
|
1
|
2
|
643
|
3.7.2.2.6 The system shall maintain a record of National Weather Service weather alert events.
|
1
|
2
|
256
|
3.7.2.2.6.1 The system shall record the weather alert event state.
|
1
|
2
|
644
|
|
3.7.2.2.6.1.1 The weather alert event state shall include Open.
|
1
|
2
|
645
|
|
3.7.2.2.6.1.2 The weather alert event state shall include Closed.
|
1
|
2
|
646
|
3.7.2.2.7 The system shall maintain a record of weather sensor alert events.
|
1
|
2
|
257
|
3.7.2.2.7.1 The system shall record the weather sensor alert event state.
|
1
|
2
|
647
|
|
3.7.2.2.7.1.1 The weather sensor alert event state shall include Open.
|
1
|
2
|
648
|
|
3.7.2.2.7.1.2 The weather sensor alert event state shall include Closed.
|
1
|
2
|
649
|
3.7.2.2.8 The system shall maintain a record of special events.
|
1
|
2
|
258
|
3.7.2.2.8.1 The system shall record the special event state.
|
1
|
2
|
650
|
|
3.7.2.2.8.1.1 The special event alert event state shall include Open.
|
1
|
2
|
651
|
|
3.7.2.2.8.1.2 The special event alert event state shall include Closed.
|
1
|
2
|
652
|
3.7.2.2.9 The system shall maintain a record of safety message events.
|
1
|
2
|
259
|
3.7.2.2.9.1 The system shall record the safety message event state.
|
1
|
2
|
653
|
|
3.7.2.2.9.1.1 The safety message event state shall include Open.
|
1
|
2
|
654
|
|
3.7.2.2.9.1.2 The safety message event state shall include Closed.
|
1
|
2
|
655
|
3.7.2.2.10 The system shall provide the capability for a user to send a manual alert from within an open event.
|
|
|
863
|
3.7.2.2.10.1 The system shall provide the user with a list of event types to select from.
|
|
|
864
|
3.7.2.2.10.2 The system shall provide the user with the option of entering text to accompany the alert.
|
|
|
865
|
3.7.2.3 General Event MessagesThe display of messages on DMSs, the broadcast of messages from HARs, and the activation of plans are all actions associated with the response to an event. All such actions are recorded in the appropriate event log.
|
|
|
596
|
3.7.2.3.1 The system shall log event messages associated with DMS activities.
|
1
|
2
|
290
|
3.7.2.3.1.1 The system shall log a message associated with an event for Set DMS message.
|
1
|
2
|
291
|
3.7.2.3.1.2 The system shall log a message associated with an event for Blank DMS display.
|
1
|
2
|
292
|
3.7.2.3.2 The system shall log event messages associated with HAR activities.
|
1
|
2
|
294
|
3.7.2.3.2.1 The system shall log a message associated with an event for Set HAR message.
|
1
|
2
|
295
|
3.7.2.3.2.2 The system shall log a message associated with an event for inactivate HAR message.
|
1
|
2
|
296
|
3.7.2.3.3 The system shall log event messages associated with plan activities.
|
1
|
2
|
486
|
3.7.2.3.3.1 The system shall log a message associated with an event for plan activation.
|
1
|
2
|
487
|
3.7.2.3.3.2 The system shall log a message associated with an event for plan completion.
|
1
|
2
|
488
|
3.8 WebThis section contains requirements for the distribution of SHA information through the Web.
|
|
|
971
|
3.8.1 The system shall support the display of data through a WWW server.
|
|
|
980
|
3.8.1.1 The system shall provide public WWW access.
|
|
|
1054
|
3.8.1.2 The system shall provide intranet WWW access.
|
|
|
1055
|
3.8.1.3 The system shall provide access to video through the WWW server.
|
|
|
981
|
3.8.1.4 The system shall provide the capability to view a restricted set of incident data through the WWW server.
|
|
|
985
|
3.8.1.5 The system shall provide the capability to view EORS Operations data through the WWW server.
|
|
|
1052
|
3.8.1.6 The system shall provide the capability to view maps through the WWW server.
|
|
|
1053
|
3.8.1.6.1 The system shall provide a zoom and pan capability for viewing maps.
|
|
|
1060
|
3.8.1.6.2 The web map interface shall display a highway base map.
|
|
|
1058
|
3.8.1.6.3 The web map interface shall display road segment speed data.
|
|
|
984
|
3.8.1.6.4 The web map interface shall display EORS road closure data.
|
|
|
987
|
3.8.1.6.5 The web map interface shall display snow emergency plan status.
|
|
|
1061
|
3.8.1.6.6 The web map display shall show device locations using map icons.
|
|
|
1056
|
3.8.1.6.6.1 Clicking on a device icon shall display device detail information.
|
|
|
1059
|
3.8.1.6.6.2 Clicking on a DMS icon shall display the current DMS message.
|
|
|
983
|
3.8.1.6.6.3 Clicking on a HAR icon shall provide the capability to listen to current HAR message.
|
|
|
982
|
3.8.1.6.6.4 Clicking on a pavement sensor shall provide the capability to view the current pavement sensor data.
|
|
|
986
|
3.8.1.6.7 The map view shall be printable.
|
|
|
1057
|
3.8.1.7 Content provided through the WWW server shall be viewable using Microsoft Internet Explorer.
|
|
|
990
|
3.8.1.8 Content provided through the WWW server shall be viewable using Netscape.
|
|
|
991
|
3.8.2 The system administrator shall have control over which data are available through the WWW server.
|
|
|
988
|
3.8.3 Dynamic information available through the WWW server shall be updated at least once every two minutes.
|
|
|
989
|
3.9 System Maintainability and AvailabilityThe overall CHART II system must provide 24 hours/day 7 days/week operations with no single point of failure. This section presents requirements for the reliability, maintainability, and availability of the system.
|
|
|
764
|
3.9.1 MaintainabilityThis section lists system maintainability requirements.
|
|
|
766
|
3.9.1.1 The system administrator shall be able to perform remote software installations.
|
|
|
769
|
3.9.1.2 The system administrator shall be able to start and stop remote CHART system processes.
|
|
|
970
|
3.9.1.3 The system shall support the capability to backup operational data files while the system is running.
|
|
|
992
|
3.9.1.3.1 The system shall support the remote backup of operational data files.
|
|
|
993
|
3.9.1.4 An system operations and maintenance guide shall be provided.
|
|
|
1063
|
3.9.1.5 A system user's guide shall be provided.
|
|
|
1064
|
3.9.2 AvailabilityThis section lists system availability requirements.
|
|
|
767
|
3.9.2.1 The CHART II system at the SOC shall support operations 24 hours/day 7 days/week.
|
|
|
768
|
3.9.2.2 The CHART II system shall support a failover capability whereby operations at one location can be transferred to a second location.
|
|
|
770
|
3.9.2.3 The CHART II system shall support distributed operations.
|
|
|
1084
|
3.9.2.3.1 The CHART II system shall include multiple locations capable of performing all CHART functions (excluding archiving).
|
|
|
1085
|
3.10 SimulationThis section presents system requirements for the support of simulation tools. The University of Maryland has responsibility for the development of simulation tools for use in the CHART II system. The CHART II system will provide the input to the simulation tools and receive the simulation results for display to CHART users.
|
|
|
1041
|
3.10.1 The system shall provide monitoring data to the simulation tools.
|
|
|
1044
|
3.10.1.1 The data provided to the simulation tools shall include detector data.
|
|
|
1046
|
3.10.1.2 The data provided to the simulation tools shall include traffic signal data.
|
|
|
1047
|
3.10.1.3 The data provided to the simulation tools shall include event data.
|
|
|
1048
|
3.10.2 The system shall provide real-time monitoring data to the simulation tools.
|
|
|
1045
|
3.10.3 The system shall provide archived monitoring data to the simulation tools.
|
|
|
1043
|
3.10.4 The system shall provide the capability to display the simulation results to the CHART user.
|
|
|
1049
|
This appendix contains a table showing the initial R1B1 requirements and a mapping to the corresponding CHART II System Requirement(s). Shaded requirements indicate those R1B1 requirements that have not been superceded by an allocated CHART System requirement and remain in effect for this release.
|
R1B1 ID
|
Release 1 Build 1 Requirement
|
Chart II Requirement |
|
237
|
3 Requirements
|
|
|
240
|
3.1 Users/SecurityThe system will rely on underlying network, operating system and physical access controls for basic security. Release 1 Build 1 applications will provide only application level security aimed at controlling which functions an operator may perform based on his/her login id and access level assignments.
|
|
|
242
|
3.1.1 The system shall provide a mechanism to define and enforce two user access levels.
|
CHART-7 The system shall provide a mechanism to define and enforce user functional rights.
|
|
463
|
3.1.1.1 The administrator shall be the highest access level.
|
CHART-8 There shall be at least one user of the system, with the role of administrator, who shall have full system functional rights.
|
|
243
|
3.1.1.2 The administrator shall have full system capabilities. An administrator has a greater privilege level than an operator and as such is allowed to perform all actions an operator may perform plus all actions that explicitly require administrator access.
|
CHART-8 There shall be at least one user of the system, with the role of administrator, who shall have full system functional rights.
|
|
464
|
3.1.1.3 The operator shall be the lowest access level.
|
CHART-9 The system shall support the assignment of roles to users.
|
|
245
|
3.1.2 The system shall require a user to provide a userid and password in order to login.
|
CHART-10 The system shall require a user to provide a userid and password in order to login.
|
|
246
|
3.1.3 The system shall allow a user to logoff.
|
CHART-11 The system shall allow a user to logoff.
|
|
247
|
3.1.4 The system shall allow an administrator to create a new user account.
|
CHART-12 The system shall allow an administrator to create a new user account.
|
|
248
|
3.1.5 The system shall allow an administrator to delete a user account.
|
CHART-13 The system shall allow an administrator to delete a user account.
|
|
249
|
3.1.6 The system shall allow an administrator to modify the access of a user account.
|
CHART-9 The system shall support the assignment of roles to users.
CHART-14 The system shall allow an administrator to modify the functional rights of a role.
|
|
465
|
3.1.7 The system shall assign an operations center to a user upon login.
|
CHART-15 The system shall assign an operations center to a user upon login.
|
|
466
|
3.1.7.1 The assigned operations center shall be the logical site of the workstation where the user logged into the GUI.
|
CHART-16 The assigned operations center shall be the logical site of the workstation where the user logged into the GUI.
|
|
662
|
3.1.8 The system shall not allow the last user at an operations center to logoff while that operations center is responsible for DMS messages.
|
CHART-402 The system shall not allow the last user logged in to a Center to logoff while that Center has control of resources.
|
|
773
|
3.1.8.1 The system shall detect if no users are logged in at the control center that is listed as the responsible control center for a DMS and shall generate an alert to a logged-in administrator or operator at the SOC if the condition is detected.
|
CHART-17 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.
|
|
663
|
3.1.9 The system shall provide a change user dialog that allows a new user to logon and an old user to logoff. This will alleviate the need for the last user at an op center to temporarily transfer responsibility for DMS messages so the operator may log off at shift change.
|
CHART-18 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.
|
|
250
|
3.2 DMS Control
|
|
|
252
|
3.2.1 The system shall allow an operator to set the current message for a selected DMS that is the responsibility of the operator's operations center or does not have a responsible operations center.
|
CHART-60 The system shall allow a suitably privileged user to set the current message for a selected DMS.
|
|
467
|
3.2.1.1 The system shall allow an operator to specify the beacons on the selected DMS, if it has beacons, should be turned on when the message is set.
|
CHART-61 The system shall allow a suitably privileged user to specify the beacon state on the selected DMS, if it has beacons.
|
|
468
|
3.2.2 The system shall allow an operator to set the current message for a selected group of DMSs that are the responsibility of the operator's operations center or do not have a responsible operations center.
|
CHART-62 The system shall allow a suitably privileged user to set the current message for a selected group of DMSs.
|
|
469
|
3.2.2.1 The system shall allow the operator to specify the beacons, for all signs in the selected group of DMSs that have beacons, should be turned on when the message is set.
|
CHART-61 The system shall allow a suitably privileged user to specify the beacon state on the selected DMS, if it has beacons.
|
|
253
|
3.2.3 The system shall allow an operator to blank the display of a selected DMS that is the responsibility of the operator's operations center.
|
CHART-64 The system shall allow a suitably privileged user to blank the display of a selected DMS.
|
|
470
|
3.2.3.1 If the beacons of a DMS are on when the DMS is blanked, they shall be turned off.
|
CHART-65 If the beacons of a DMS are on when the DMS is blanked, they shall be turned off.
|
|
471
|
3.2.4 The system shall allow an operator to blank the display of a selected group of DMSs that are the responsibility of the operator's operations center.
|
CHART-66 The system shall allow a suitably privileged user to blank the display of a selected group of DMSs.
|
|
472
|
3.2.4.1 If the beacons of a DMS in the selected group are on when the DMS is blanked, they shall be turned off.
|
CHART-65 If the beacons of a DMS are on when the DMS is blanked, they shall be turned off.
|
|
254
|
3.2.5 The system shall allow an operator to reset the controller for a selected DMS that is the responsibility of the operator's operations center or does not have a responsible operations center.
|
CHART-68 The system shall allow a suitably privileged user to reset the controller for a selected DMS.
|
|
473
|
3.2.5.1 The system shall blank the display of the selected DMS when the controller is reset.
|
CHART-69 The system shall blank the display of the selected DMS when the controller is reset.
|
|
474
|
3.2.5.2 If the DMS has beacons, the system shall turn the beacons off when the controller is reset.
|
CHART-70 If the DMS has beacons, the system shall turn the beacons off when the controller is reset.
|
|
475
|
3.2.6 The system shall allow an administrator to reset the controller for a selected group of DMSs.
|
CHART-71 The system shall allow a suitably privileged user to reset the controller for a selected group of DMSs.
|
|
476
|
3.2.6.1 The system shall blank the display of all selected DMSs when the controller is reset.
|
CHART-69 The system shall blank the display of the selected DMS when the controller is reset.
|
|
477
|
3.2.6.2 If a selected DMS has beacons, the system shall turn the beacons off when the controller is reset.
|
CHART-70 If the DMS has beacons, the system shall turn the beacons off when the controller is reset.
|
|
256
|
3.2.7 The system shall allow an operator to force a status poll of a selected DMS.
|
CHART-33 The system shall allow a suitably privileged user to force a status poll of a selected pollable device.
|
|
481
|
3.2.8 The system shall allow an operator to force a status poll of a selected group of DMSs.
|
CHART-34 The system shall allow a suitably privileged user to force a status poll of a selected group of pollable devices.
|
|
257
|
3.2.9 The system shall allow an administrator to change the name of a selected DMS.
|
CHART-44 The system shall allow a suitably privileged user to change the name of a selected device.
|
|
258
|
3.2.10 The system shall allow an administrator to alter the polling interval of a selected DMS.
|
CHART-35 The system shall allow a suitably privileged user to alter the polling interval of a selected pollable device.
|
|
482
|
3.2.10.1 The minimum polling interval shall be 1 minute.
|
CHART-36 The minimum polling interval shall be 1 minute.
|
|
483
|
3.2.10.2 The maximum polling interval shall be 24 hours.
|
CHART-37 The maximum polling interval shall be 24 hours.
|
|
484
|
3.2.10.3 The minimum increment for a polling interval shall be 1 minute.
|
CHART-38 The minimum increment for a polling interval shall be 1 minute.
|
|
485
|
3.2.11 The system shall provide an application program interface (API) to implement DMS functionality specified in the NTCIP standard NEMA TS3.6.
|
CHART-82 The system shall provide an application program interface (API) to implement DMS functionality specified in the NTCIP standard NEMA TS3.6.
|
|
259
|
3.2.12 The system shall support the Mark IV FP9500 "Maryland" DMS protocol. (Actual protocol support is carried out by the FMS subsystem.)
|
CHART-75 The system shall support the Mark IV FP9500 "Maryland" DMS protocol. (Actual protocol support is carried out by the FMS subsystem.)
|
|
486
|
3.2.13 The system shall support the Mark IV FP2001 DMS protocol. (Actual protocol support is carried out by the FMS subsystem.)
|
CHART-76 The system shall support the Mark IV FP2001 DMS protocol. (Actual protocol support is carried out by the FMS subsystem.)
|
|
487
|
3.2.14 The system shall support the Mark IV FP1001 DMS protocol. (Actual protocol support is carried out by the FMS subsystem.)
|
CHART-77 The system shall support the Mark IV FP1001 DMS protocol. (Actual protocol support is carried out by the FMS subsystem.)
|
|
488
|
3.2.15 The system shall support the Telespot DMS protocol. (Actual protocol support is carried out by the FMS subsystem.)
|
CHART-78 The system shall support the Telespot DMS protocol. (Actual protocol support is carried out by the FMS subsystem.)
|
|
264
|
3.2.16 The system shall provide a mechanism to establish and maintain a responsible operations center of a DMS.
|
CHART-792 Device queue message attributes shall include the Center responsible for the message.
|
|
265
|
3.2.16.1 The system shall designate the operations center where the operator is logged in as the responsible operations center of the DMS when the operator sets a message or enables the beacons on that DMS.
|
CHART-382 The management of an open event shall be under the control of the responsible Center.
|
|
266
|
3.2.16.2 The system shall clear the responsible operations center of a DMS when its display is blanked.
|
CHART-265 When an event is closed the system shall remove all messages from devices and device queues associated with the event.
|
|
489
|
3.2.16.3 The system shall provide a mechanism to transfer a DMS to another responsible operations center.
|
CHART-383 The system shall support the transfer of responsibility for an open event from one Center to another.
|
|
490
|
3.2.16.4 The system shall clear the responsible operations center of a DMS when it is reset.
|
CHART-225 A message entering a device queue with a higher priority than the current message on the device shall preempt the current message.
|
|
664
|
3.2.16.5 The system shall not allow a DMS to display a message without a responsible operations center.
|
CHART-792 Device queue message attributes shall include the Center responsible for the message.
|
|
665
|
3.2.16.6 The system shall not hold an op center responsible for a blank DMS.
|
CHART-226 A preempted message shall be returned to the device queue.
|
|
268
|
3.2.17 The system shall allow an administrator to override the current message on a DMS assigned to any responsible operations center.
|
CHART-244 A suitably privileged user shall be able to modify the priority of a message in a queue.
|
|
768
|
3.2.17.1 The system shall set the controlling operations center for the DMS to the operations center where the administrator is logged in.
|
CHART-244 A suitably privileged user shall be able to modify the priority of a message in a queue.
|
|
269
|
3.2.18 The system shall not allow an operator to override the current message on a DMS assigned to a different operations center than the operations center the operator is logged in to.
|
CHART-225 A message entering a device queue with a higher priority than the current message on the device shall preempt the current message.
|
|
491
|
3.2.19 The system shall not allow an operator logged in at an operations center to blank the display of a DMS that is the responsibility of a different operations center.
|
CHART-225 A message entering a device queue with a higher priority than the current message on the device shall preempt the current message.
|
|
492
|
3.2.20 The system shall allow an administrator logged in at any operations center to blank the display of a DMS that is the responsibility of a different operations center.
|
CHART-244 A suitably privileged user shall be able to modify the priority of a message in a queue.
|
|
460
|
3.3 DMS Navigator
|
|
|
273
|
3.3.1 The navigator shall provide a DMS group in the tree view.
|
CHART-97 The navigator shall provide a device group in the tree view.
|
|
496
|
3.3.1.1 Clicking on this group shall cause all system DMS devices to be displayed in the list view.
|
CHART-98 Clicking on the device group shall cause all system devices to be displayed in the list view.
|
|
274
|
3.3.2 The navigator shall show the updating status of each of the following attributes for each DMS device at the maximum rate of the currently defined status polling rate for the device:
|
CHART-99 The navigator shall show the updating attributes and status of each of the devices.
|
|
275
|
3.3.2.1 Name/description
|
CHART-100 The navigator shall show the Name/description for each device.
|
|
276
|
3.3.2.2 Object type (DMS)
|
CHART-102 The navigator shall show the Object type for each device.
|
|
277
|
3.3.2.3 Operational Status
|
CHART-103 The navigator shall show the Operational Status for each device.
|
|
497
|
3.3.2.3.1 Operational status shall have one of the following values:
|
CHART-106 Operational status shall indicate Communications Failure values.
CHART-105 Operational status shall indicate Hardware Failure values.
CHART-104 Operational status shall indicate if the device is Online or Offline.
|
|
500
|
Online
|
CHART-104 Operational status shall indicate if the device is Online or Offline.
|
|
502
|
Offline
|
CHART-104 Operational status shall indicate if the device is Online or Offline.
|
|
504
|
Hardware failure
|
CHART-105 Operational status shall indicate Hardware Failure values.
|
|
506
|
Software Communications failure
|
CHART-106 Operational status shall indicate Communications Failure values.
|
|
508
|
Communications failure
|
CHART-106 Operational status shall indicate Communications Failure values.
|
|
510
|
3.3.2.3.2 The ascending sort order of operational status shall be:
|
CHART-112 The navigator shall allow a user to sort the information in the list view by clicking on the column header.
|
|
513
|
Hardware Failure
|
|
|
515
|
Software Communications Failure
|
|
|
517
|
Communications Failure
|
|
|
519
|
Online
|
|
|
521
|
Offline
|
|
|
283
|
3.3.2.4 DMS geometry
|
CHART-107 The navigator shall show the DMS geometry for each DMS device.
|
|
285
|
3.3.2.5 DMS Message responsible operations center
|
CHART-792 Device queue message attributes shall include the Center responsible for the message.
|
|
286
|
3.3.2.6 Current message
|
CHART-108 The navigator shall show the current message for each DMS device.
|
|
287
|
3.3.2.7 Date/time of last status change (message change, operational status change, responsible operations center change, etc.)
|
CHART-101 The navigator shall show the date/time of last change in status for each device.
|
|
776
|
3.3.2.8 DMS ID
|
CHART-795 The GUI shall provide the capability to show the id of each device.
|
|
288
|
3.3.3 The navigator shall allow an operator to right click on a DMS in the list view to display a pop-up control menu for that DMS.
|
CHART-110 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.
|
|
289
|
3.3.4 The navigator shall allow an operator to right click on a selected group of DMSs to display a pop-up control menu for the selected DMSs.
|
CHART-111 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.
|
|
523
|
3.3.5 The navigator shall allow an operator to sort the information in the list view by clicking on the column header.
|
CHART-112 The navigator shall allow a user to sort the information in the list view by clicking on the column header.
|
|
290
|
3.3.6 The system shall provide a DMS message editor which will allow an operator to format a DMS message as follows:
|
CHART-113 The system shall provide a DMS message editor which will allow a user to format a DMS message.
|
|
291
|
3.3.6.1 The message editor shall allow an operator to enter message text into a text field.
|
CHART-114 The DMS message editor shall allow a user to enter message text into a text field.
|
|
292
|
3.3.6.2 The 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.
|
CHART-115 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.
|
|
293
|
3.3.6.3 The 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.
|
CHART-116 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.
|
|
771
|
3.3.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.
|
CHART-117 When a group of DMSs are selected to receive the same message, the message editor shall format the message for each DMS type selected.
|
|
770
|
3.3.6.5 The system shall not allow truncated messages to be sent to a DMS.
|
CHART-118 The system shall not allow truncated messages to be sent to a DMS.
|
|
294
|
3.3.7 The system shall provide a DMS show display window, which will show a graphical depiction of the current message for a particular DMS.
|
CHART-125 The system shall provide a DMS show display window, which will show a graphical depiction of the current message for a particular DMS.
|
|
295
|
3.3.8 The system shall notify the initiating operator should an attempt to control a DMS fail.
|
CHART-137 The system shall notify the initiating operator should an attempt to control a DMS fail.
CHART-417 The system shall inform the operators of a DMS failure.
|
|
251
|
3.3.9 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.
|
CHART-290 The system shall log event messages associated with DMS activities.
CHART-99 The navigator shall show the updating attributes and status of each of the devices.
|
|
778
|
3.3.10 The Graphical User Interface shall display the following information upon operator request:
|
CHART-792 Device queue message attributes shall include the Center responsible for the message.
CHART-796 The GUI shall provide the capability to show the network connection site for a device.
|
|
780
|
3.3.10.1 The Graphical User Interface shall display the DMS network connection site of a DMS upon operator request.
|
CHART-796 The GUI shall provide the capability to show the network connection site for a device.
|
|
779
|
3.3.10.2 The Graphical User Interface shall display the owning organization of a DMS upon operator request
|
CHART-792 Device queue message attributes shall include the Center responsible for the message.
CHART-1028 Device attribute information shall include the owning organization for the device.
|
|
296
|
3.4 DMS Polling
|
|
|
298
|
3.4.1 The system shall provide a mechanism to poll each DMS for status on a configurable interval basis. (Actual polling is carried out by the FMS subsystem.)
|
CHART-32 The system shall provide a mechanism to poll devices for status on a configurable interval basis.
|
|
524
|
3.4.1.1 The minimum polling interval shall be 1 minute.
|
CHART-36 The minimum polling interval shall be 1 minute.
|
|
525
|
3.4.1.2 The maximum polling interval shall be 24 hours.
|
CHART-37 The maximum polling interval shall be 24 hours.
|
|
526
|
3.4.1.3 The minimum increment for a polling interval shall be 1 minute.
|
CHART-38 The minimum increment for a polling interval shall be 1 minute.
|
|
297
|
3.4.2 The system shall allow an operator to place an online DMS offline that currently has no responsible operations center or the responsible operations center is the operations center currently assigned to the operator.
|
CHART-83 The system shall allow a suitably privileged user to set a DMS offline.
CHART-40 The system shall allow a suitably privileged user to place an online device offline.
|
|
527
|
3.4.2.1 Placing a DMS offline shall blank the displayed message.
|
CHART-667 The system shall blank the display of a DMS that is set to offline.
|
|
528
|
3.4.2.2 Placing a DMS offline shall clear the responsible operations center.
|
CHART-667 The system shall blank the display of a DMS that is set to offline.
CHART-225 A message entering a device queue with a higher priority than the current message on the device shall preempt the current message.
|
|
529
|
3.4.2.3 If the DMS has beacons, placing the DMS offline shall turn the beacons off.
|
CHART-65 If the beacons of a DMS are on when the DMS is blanked, they shall be turned off.
|
|
530
|
3.4.3 The system shall allow an operator to place an offline DMS online.
|
CHART-745 The system shall allow a suitably privileged user to set a DMS online.
|
|
531
|
3.4.3.1 Placing a DMS online shall blank the displayed message.
|
CHART-668 The system shall immediately blank the display of a DMS that is set to online.
|
|
532
|
3.4.3.2 Placing a DMS online shall clear the responsible operations center.
|
CHART-797 The system shall enable the message queue for a DMS that is set to online.
|
|
533
|
3.4.3.3 If the DMS has beacons, placing the DMS online shall turn the beacons off.
|
CHART-65 If the beacons of a DMS are on when the DMS is blanked, they shall be turned off.
|
|
534
|
3.4.4 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.
|
CHART-84 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.
|
|
535
|
3.4.5 The system shall inform operators of a DMS communications failure if it is unable to communicate with a particular DMS during polling.
|
CHART-39 The system shall inform operators of a device communications failure if it is unable to communicate with a particular device during polling.
|
|
785
|
3.4.6 When a DMS communications failure has occurred, the system shall mark the DMS as blank after a timeout threshold is reached.
|
CHART-669 The system shall mark a DMS as blank after a timeout threshold is reached following a DMS communications failure.
|
|
784
|
3.4.7 The system shall execute a blank message command for the DMS when successful communications with the DMS is resumed after the DMS communications failure timeout threshold has expired.
|
CHART-670 The system shall blank a DMS when successful communication with the DMS is resumed after the DMS communications failure timeout threshold has expired.
|
|
783
|
3.4.8 The system shall allow setting of a configuration parameter to set the DMS communications failure timeout threshold using a value expressed in minutes using any integer value between 1 minute and 16535 minutes.
|
CHART-671 The system shall support a DMS communications failure timeout threshold expressed in minutes from 1 minute and 16535 minutes.
|
|
782
|
3.4.9 The DMS communications failure timeout threshold shall default to 10 minutes.
|
CHART-672 The DMS communications failure timeout default shall be 10 minutes.
|
|
781
|
3.4.10 When a DMS communications failure has occurred, the system shall clear the controlling operations center for that DMS after a timeout threshold is reached.
|
CHART-1032 The system shall return the current message to the device queue following a DMS communications failure.
CHART-670 The system shall blank a DMS when successful communication with the DMS is resumed after the DMS communications failure timeout threshold has expired.
|
|
299
|
3.5 DMS Messages Formats
|
|
|
301
|
3.5.1 The system shall format DMS messages using the MULTI DMS mark-up language as specified in the NTCIP document ISO/WD 14823-2.
|
CHART-146 The system shall format DMS messages using the MULTI DMS mark-up language as specified in the NTCIP document ISO/WD 14823-2.
|
|
302
|
3.5.2 The system shall format all DMS messages for display according to the algorithm provided on page 20 of the initial RFP and as demonstrated in the requirements prototype.
|
CHART-147 The system shall format message text for display on a DMS.
|
|
303
|
3.5.2.1 All lines shall be centered horizontally.
|
CHART-148 All text lines shall be centered horizontally on the DMS.
|
|
304
|
3.5.2.2 Any phase (page on a sign display) with one line of text shall be displayed on the center line.
|
CHART-149 Any phase (page on a sign display) with one line of text shall be displayed on the center line.
|
|
305
|
3.5.2.3 Any phase with two lines of text shall have that text displayed on lines one and three.
|
CHART-150 Any phase (page on a sign display) with two lines of text shall have that text displayed on lines one and three.
|
|
306
|
3.5.2.4 The phrase "Expect Delays" may be broken up between two lines.
|
CHART-151 The phrase "Expect Delays" may be broken up between two lines.
|
|
307
|
3.5.2.5 Route types and Route numbers shall not be broken up.
|
CHART-152 The system shall employ rules for formatting route type and route number information.
CHART-390 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.
CHART-391 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.
CHART-392 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.
CHART-393 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.
CHART-394 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.
CHART-395 The system shall keep the route direction “ N” on the same line as the preceding route information.
CHART-396 The system shall keep the route direction “ S” on the same line as the preceding route information.
CHART-397 The system shall keep the route direction “ E” on the same line as the preceding route information.
CHART-398 The system shall keep the route direction “ W” on the same line as the preceding route information.
|
|
308
|
3.5.2.6 Directions containing the route and direction of the incident may be broken up as shown in the examples provided in the RFP.
|
CHART-152 The system shall employ rules for formatting route type and route number information.
CHART-399 The system shall place on a new line any route information that is lead by the route indicator “AT”.
CHART-400 The system shall place on a new line any route information that is lead by the route indicator “PRIOR”.
CHART-401 The system shall place on a new line any route information that is lead by the route indicator “PAST”.
|
|
309
|
3.5.2.7 The phrase "Stay Alert" may be broken up between two lines.
|
CHART-154 The DMS message format The phrase "Stay Alert" may be broken up between two lines.
|
|
310
|
3.5.2.8 Each DMS shall use only one font for displaying DMS messages.
|
CHART-155 Each DMS shall use only one font for displaying DMS messages.
|
|
311
|
3.5.2.9 The system shall support the following MULTI language tags:
|
CHART-156 The system shall support MULTI language tags.
|
|
538
|
New Page [np]
|
CHART-157 The system shall support the New Page [np] MULTI language tag. Used to specify a phase break
|
|
541
|
New Line [nlx]
|
CHART-158 The system shall support the New Line [nlx] MULTI language tag. Used to specify a new line of text
|
|
544
|
Justification – line [jlx]
|
CHART-159 The system shall support the Justification – line [jlx] MULTI language tag. Used to specify the justification for the current line of text.
|
|
547
|
Page timing [ptxoy]
|
CHART-160 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.
|
|
316
|
3.6 DMS Message Libraries
|
|
|
318
|
3.6.1 The system shall allow an operator to set a message on a DMS from a message stored in a DMS message library.
|
CHART-174 The system shall allow a suitably privileged user to set a message on a DMS from a message stored in a DMS message library.
|
|
319
|
3.6.2 The system shall allow an operator to create a new DMS message library.
|
CHART-166 The system shall allow a suitably privileged user to create a new message library.
|
|
320
|
3.6.3 The system shall allow an operator to delete a DMS message library.
|
CHART-167 The system shall allow a suitably privileged user to delete a message library.
|
|
450
|
3.6.3.1 This action shall delete all messages stored in the library as well.
|
CHART-168 The deletion of a message library shall delete all messages stored in the library as well.
|
|
322
|
3.6.4 The system shall allow an operator to change the name of a DMS message library.
|
CHART-169 The system shall allow a suitably privileged user to change the name of a message library.
|
|
323
|
3.6.5 The system shall allow an operator to create a new DMS library message.
|
CHART-170 The system shall allow a suitably privileged user to create a new library message.
|
|
324
|
3.6.6 The system shall allow an operator to delete a DMS library message.
|
CHART-171 The system shall allow a suitably privileged user to delete a library message.
|
|
325
|
3.6.7 The system shall allow an operator to modify the contents of a DMS library message.
|
CHART-172 The system shall allow a suitably privileged user to modify the contents of a library message.
|
|
326
|
3.6.8 The system shall allow an operator to change the name of a DMS library message.
|
CHART-173 The system shall allow a suitably privileged user to change the name of a library message.
|
|
456
|
3.6.9 The navigator shall provide a DMS message library group in the tree view for each DMS message library.
|
CHART-164 The system shall support libraries containing DMS messages.
CHART-126 The navigator shall provide a DMS message library group in the tree view for each DMS message library.
|
|
457
|
3.6.9.1 Clicking on this group shall cause all DMS library messages stored in the selected library to be displayed in the list view.
|
CHART-673 The system shall allow a suitably privileged user to display the contents of a library message.
CHART-127 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.
|
|
328
|
3.6.10 The navigator shall show the following attributes for each library message:
|
CHART-798 The system shall allow the user to display attributes of a DMS library message.
|
|
329
|
3.6.10.1 Message description
|
CHART-800 The system shall display the message description for a DMS library message.
|
|
330
|
3.6.10.2 Message text
|
CHART-801 The system shall display the message text for a DMS library message.
|
|
331
|
3.6.10.3 Topic/Category
|
CHART-802 The system shall display the message category for a DMS library message.
|
|
332
|
3.6.10.4 Required sign length in characters
|
CHART-803 The system shall display the required message sign length for a DMS library message.
|
|
333
|
3.6.10.5 Beacon indicator
|
CHART-804 The system shall display the message beacon indicator for a DMS library message.
|
|
334
|
3.6.11 The navigator shall allow an operator to drag a DMS message from a library to a DMS.
|
CHART-134 The navigator shall allow a suitably privileged user to drag a DMS message from a message library to a DMS.
CHART-174 The system shall allow a suitably privileged user to set a message on a DMS from a message stored in a DMS message library.
|
|
549
|
3.6.11.1 If the DMS has beacons and the beacon indicator in the library message is true then the system shall turn the beacons on when setting the message.
|
CHART-674 The system shall support setting the beacon state for a DMS library message.
|
|
317
|
3.6.12 The navigator shall allow an operator to drag a DMS message from a library to a group of DMSs for display.
|
CHART-62 The system shall allow a suitably privileged user to set the current message for a selected group of DMSs.
|
|
550
|
3.6.12.1 If any DMS in the group has beacons and the beacon indicator in the library message is true then the system shall turn the beacons on when setting the message.
|
CHART-674 The system shall support setting the beacon state for a DMS library message.
|
|
335
|
3.7 Operations log
|
|
|
337
|
3.7.1 The system shall generate a message in the operations log for each of the following system operations:
|
CHART-274 The system shall log messages generated from operations activities.
CHART-247 The system shall maintain a system operations log.
|
|
338
|
3.7.1.1 User login
|
CHART-275 The system shall log a message for User login.
|
|
551
|
3.7.1.2 Failed user login attempts
|
CHART-276 The system shall log a message for Failed user login attempts.
|
|
339
|
3.7.1.3 User logout
|
CHART-277 The system shall log a message for User logout.
|
|
340
|
3.7.1.4 Set DMS message
|
CHART-291 The system shall log a message associated with an event for Set DMS message.
|
|
341
|
3.7.1.5 Blank DMS display
|
CHART-292 The system shall log a message associated with an event for Blank DMS display.
|
|
342
|
3.7.1.6 Reset DMS controller
|
CHART-293 The system shall log a message to the operations log for Reset DMS controller.
|
|
343
|
3.7.1.7 Change DMS name
|
CHART-282 The system shall log a message for Change shared resource name.
|
|
344
|
3.7.1.8 Change DMS polling interval
|
CHART-285 The system shall log a message for Change shared resource polling interval.
|
|
552
|
3.7.1.9 Take DMS offline
|
CHART-284 The system shall log a message for Take shared resource offline.
|
|
553
|
3.7.1.10 Place a DMS online
|
CHART-283 The system shall log a message for Place a shared resource online.
|
|
554
|
3.7.1.11 Adding users
|
CHART-278 The system shall log a message for Adding users.
|
|
555
|
3.7.1.12 Modifying users
|
CHART-279 The system shall log a message for Modifying users.
|
|
556
|
3.7.1.13 Deleting users
|
CHART-280 The system shall log a message for Deleting users.
|
|
557
|
3.7.1.14 Change in DMS hardware status
|
CHART-286 The system shall log a message for Change in shared resource hardware status.
|
|
558
|
3.7.1.15 Change to the DMS Message Libraries
|
CHART-298 The system shall log operations messages associated with Message Library management.
|
|
559
|
3.7.1.16 Change in responsible operations center for a DMS
|
CHART-794 The system shall log a message to the operations log when a message is preempted.
|
|
560
|
3.7.1.17 Adding a DMS Configuration
|
CHART-287 The system shall log a message for Adding a shared resource Configuration.
|
|
561
|
3.7.1.18 Modifying a DMS Configuration
|
CHART-288 The system shall log a message for Modifying a shared resource Configuration.
|
|
562
|
3.7.1.19 Deleting a DMS Configuration
|
CHART-289 The system shall log a message for Deleting a shared resource Configuration.
|
|
563
|
3.7.1.20 Adding a DMS Plan
|
CHART-305 The system shall log a message to the operations log for Adding a Plan.
|
|
564
|
3.7.1.21 Modifying a DMS Plan
|
CHART-306 The system shall log a message to the operations log for Modifying a Plan.
|
|
565
|
3.7.1.22 Deleting a DMS Plan
|
CHART-307 The system shall log a message to the operations log for Deleting a Plan.
|
|
566
|
3.7.1.23 Activation of a DMS Plan
|
CHART-308 The system shall log a message to the operations log for Activation of a Plan.
|
|
345
|
3.7.2 The system shall store the following information with each operations log entry:
|
CHART-469 The system shall store identifying information with each operations log entry.
|
|
775
|
Workstation Identifier
|
CHART-471 The system shall store the Workstation Identifier (if applicable) with each operations log message.
|
|
569
|
Date/time the operation was performed
|
CHART-470 The system shall store the Date/time the operation was performed with each operations log message.
|
|
571
|
User name of initiating operator
|
CHART-473 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.
|
|
573
|
Textual description of action taken which will include identification information for any affected field device and the text of a DMS message if appropriate
|
CHART-475 The system shall store the Textual description of action taken with each operations log message.
|
|
349
|
3.7.3 The system shall store operations log entries in the database utilized by the service application (DMS service, etc.) performing the action.
|
CHART-479 The system shall have the capability to store at least 14 days of operations log entries in the online system.
|
|
445
|
3.8 Banned Word List
|
|
|
447
|
3.8.1 The system shall check all DMS messages against a dictionary of banned words before sending the message to the field.
|
CHART-187 The system shall support the option of enabling a dictionary on an individual user basis.
CHART-190 The system shall have the capability to check all text messages on input against a dictionary before sending the message to the field.
CHART-185 The system shall support a banned words dictionary.
|
|
574
|
3.8.2 The system shall check all DMS messages against a dictionary of banned words before storing the message in a message library.
|
CHART-191 The system shall have the capability to check all text messages on input against a dictionary before storing the message in a message library.
CHART-185 The system shall support a banned words dictionary.
|
|
575
|
3.8.3 The system shall allow an administrator to add a new word to the list of banned words.
|
CHART-192 The system shall allow a suitably privileged user to add a new list of words to a dictionary.
|
|
448
|
3.8.4 The system shall allow an administrator to add a new list of words to the list of banned words.
|
CHART-192 The system shall allow a suitably privileged user to add a new list of words to a dictionary.
|
|
449
|
3.8.5 The system shall allow an administrator to remove a word from the list of banned words.
|
CHART-193 The system shall allow a suitably privileged user to remove a word from a dictionary.
|
|
458
|
3.9 DMS Message Plans
|
|
|
576
|
3.9.1 The system shall allow an operator to create a DMS message plan which includes the following:
|
CHART-201 The system shall allow a suitably privileged user to create a plan.
|
|
577
|
3.9.1.1 Plan Description
|
CHART-202 The plan shall include the plan description.
|
|
578
|
3.9.1.2 One or more of the following:
|
CHART-203 The plan shall include a list of actions to implement.
|
|
586
|
DMS to display a message on
|
CHART-204 The allowable plan item actions shall include putting a library message on a DMS.
|
|
588
|
DMS library message to display
|
CHART-204 The allowable plan item actions shall include putting a library message on a DMS.
|
|
589
|
3.9.2 The system shall allow an operator to modify a DMS message plan.
|
CHART-206 The system shall allow a suitably privileged user to modify a plan.
|
|
590
|
3.9.3 The system shall allow an operator to delete a DMS message plan.
|
CHART-207 The system shall allow a suitably privileged user to delete a plan.
|
|
591
|
3.9.4 The system shall allow an operator to activate a message plan.
|
CHART-215 The system shall allow a suitably privileged user to activate a plan.
|
|
592
|
3.9.4.1 Activation of a message plan shall involve activating the specified library message on the specified device for each DMS/Message pair in the plan.
|
CHART-675 Upon plan activation the system shall sequentially execute each plan item.
|
|
459
|
3.10 DMS Configuration and Administration
|
|
|
593
|
3.10.1 The system shall allow an administrator to add a new DMS which communicates via an implemented protocol.
|
CHART-42 The system shall allow a suitably privileged user to add a new device which communicates via an implemented protocol.
|
|
594
|
3.10.2 The system shall allow an administrator to specify the necessary configuration information to make a DMS usable.
|
CHART-43 The system shall allow a suitably privileged user to specify the necessary configuration information to make a device usable.
|
|
595
|
3.10.3 The system shall allow an administrator to modify the configuration information for a DMS.
|
CHART-45 The system shall allow a suitably privileged user to modify the configuration information for a device.
|
|
596
|
3.10.4 The system shall allow an administrator to delete a DMS from the system.
|
CHART-46 The system shall allow a suitably privileged user to delete a device from the system.
|
|
777
|
3.10.5 The system shall require the administrator to re-enter their password prior to allowing them to view the banned word dictionary.
|
CHART-676 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.
|
This appendix contains a history of updates to requirements in this document.
The following tables detail the changes made in response to
comments received on the CHART II System Requirements Specification Release 1
Build 2. These include changes made in response to comments on R1B1 and R1B2
requirements only.
|
Changes to R1B1 Requirements |
||
3.2.2.11.1 The system shall immediately blank the display of a DMS that is set to online. |
668 |
Added “immediately” |
3.3.1.2.9 The GUI shall provide the capability to show the id of each device. |
795 |
Changed “navigator” to “GUI”. |
3.3.1.2.10 The GUI shall provide the capability to show the network connection site for a device. |
796 |
Changed “navigator” to “GUI”. |
|
Changes to R1B2 Requirements |
||
|
Section 2 14) MDSHA CHART Software Functional Requirements Document. |
|
Added to list of references. |
3.1.2.15.1.1 The choices for communications types shall include In Service.
|
562
|
Changed “list” to “choices”. |
3.1.2.15.1.2 The choices for communications types shall include Out of Service.
|
563
|
Changed “list” to “choices”. |
3.2.1.9.1 All commands to online devices shall be performed through an open event. |
978
|
New requirement |
3.2.1.10.3 The system shall restrict certain commands to devices in maintenance mode only. |
972
|
New requirement |
3.2.1.10.3.1 "Reset DMS" is a maintenance mode command.
|
973
|
New requirement |
3.2.1.10.3.2 "Reset HAR controller" is a maintenance mode command.
|
974
|
New requirement |
3.2.1.10.3.3 "Forced Poll" is a maintenance mode command.
|
975
|
New requirement |
3.2.1.10.3.4 "Setup HAR controller" is a maintenance mode command.
|
976
|
New requirement |
3.2.1.10.3.5 "Rebuild HAR controller" is a maintenance mode command.
|
977
|
New requirement |
3.2.1.10.3.6 "Set HAR transmitter on/off" is a maintenance mode command.
|
994
|
New requirement |
3.2.1.10.3.7 "Change device configuration" is a maintenance mode command.
|
995
|
New requirement |
3.2.1.10.3.8 "Store message in HAR controller slot" (except the immediate message slot) is a maintenance mode command.
|
996
|
New requirement |
3.2.1.10.3.9 "Delete message from HAR controller slot" is a maintenance mode command.
|
997
|
New requirement |
3.2.1.10.3.10 "Pixel test" is a maintenance mode command.
|
998
|
New requirement |
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. |
1000
|
New requirement |
3.2.2.13 The system shall allow a suitably privileged user to command a pixel test on a DMS that supports this function.
|
999
|
New requirement |
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. |
741
|
Modified to state that the user can “selectively” mark SHAZAM devices online. |
The following items were added to the glossary:
|
Event
|
An occurrence or activity of concern to the CHART system and the recording of information about that occurrence or activity.
|
|
Functional Right
|
The right to perform a specified function.
|
|
Open Event
|
An event which the CHART system is currently engaged in monitoring or managing.
|
|
Pollable Device
|
A device that supports returning its status on request.
|
|
Resources
|
Any of the SHA devices, detectors, and equipment available to the CHART system.
|
|
Role
|
A collection of zero or more function rights. Users are assigned roles and thereby obtain functional rights for performing system functions.
|
|
Suitably Privileged User
|
A user with the appropriate functional rights to perform an action.
|
The following tables detail the
changes made in response to comments received on the CHART II System
Requirements Specification.
|
Changes to Requirements |
||
3.1.2.6.6 The system shall provide the capability to automatically restart selected processes when they go down.
|
1067
|
New requirement. |
3.1.2.18.1 The system shall support the capability to download EORS lane closure permits.
|
901
|
Changed “construction permit” to “lane closure permit”. |
3.1.2.18.1.1 The system shall download EORS lane closure permit attributes.
|
903
|
Changed “construction permit” to “lane closure permit”. |
3.1.2.18.1.2 The system shall download EORS lane closure permit schedule dates and times.
|
904
|
Changed “construction permit” to “lane closure permit”. |
3.1.2.18.1.3 The system shall download EORS lane closure permits at a system specified interval.
|
905
|
Changed “construction permit” to “lane closure permit”. |
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
|
Changed “construction permit” to “lane closure permit”. |
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
|
Changed “construction permit” to “lane closure permit”. |
|
3.1.2.18.1.5.1 The system shall store lane closure permit conflict information with the construction permit attributes. |
908
|
Changed “construction permit” to “lane closure permit”. |
3.1.4.2.4 The system shall support the generation of traffic volume reports.
|
1068
|
New requirement. |
3.1.4.5 The system shall provide an ad hoc reporting capability for archived data.
|
1088
|
New requirement. |
3.1.4.6 The system shall provide the capability for users to customize reports.
|
1089
|
New requirement. |
3.2 Device ManagementThis 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
|
Added CCTV devices to text. |
3.2.1.29 Data from detection devices shall be made available to requesting systems on an equal basis.
|
1086
|
New requirement. |
3.2.1.29.1 Servicing a request for detection data from one system shall not affect the data requested by another system.
|
1087
|
New requirement. |
3.2.1.30 The system shall provide a capability for users to exercise specified system functions without affecting operational field devices.
|
1090
|
New requirement. |
3.2.1.30.1 The system shall provide the capability for a user to perform DMS-related functions on a simulated DMS.
|
1091
|
New requirement. |
3.2.5.3 The system shall provide the capability to assess the validity of detector data. |
1069
|
New requirement. |
3.2.5.3.1 The system shall determine the validity of loop detector data.
|
1070
|
New requirement. |
3.3.2.6 The map display shall support the display of independent map layers.
|
1071
|
New requirement. |
3.3.2.6.1 The map display shall support a base map layer showing major Maryland highways.
|
1072
|
New requirement. |
3.3.2.6.2 The map display shall support a device map layer.
|
1073
|
New requirement. |
3.3.2.6.3 The map display shall support a weather map layer.
|
1074
|
New requirement. |
3.3.2.6.4 The map display shall support an incident map layer.
|
1075
|
New requirement. |
3.3.2.6.5 The map display shall support a lane closure map layer.
|
1076
|
New requirement. |
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
|
New requirement. |
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
|
New requirement. |
3.5.1.1.2.3 The allowable plan item actions shall include sending an email.
|
1078
|
New requirement. |
3.5.1.1.2.4 The allowable plan item actions shall include sending a page.
|
1079
|
New requirement. |
3.5.1.1.2.5 The allowable plan item actions shall include sending a fax.
|
1080
|
New requirement. |
3.5.1.1.2.6 The allowable plan item actions shall include generating a report.
|
1081
|
New requirement. |
3.6.1.4 The system shall provide the capability to evaluate probe data.
|
1082
|
New requirement. |
3.6.1.5 The system shall provide the capability to evaluate vehicle classification data.
|
1083
|
New requirement. |
3.9.2.2 The CHART II system shall support a failover capability whereby operations at one location can be transferred to a second location.
|
770
|
Modified to remove “without loss of functionality”. |
3.9.2.3 The CHART II system shall support distributed operations.
|
1084
|
New requirement. |
3.9.2.3.1 The CHART II system shall include multiple locations capable of performing all CHART functions (excluding archiving). |
1085
|
New requirement. |
CHART Coordinated Highways Action Response Team
COTS Commercial-Off-The-Shelf
CSC Computer Sciences Corporation
DMS Dynamic Message Sign
EORS Emergency Operations Reporting System
ERU/ETP Emergency Response Unit/ Emergency Traffic Patrol
FITM Freeway Incident Traffic Management
FMS Field Management Station
GUI Graphical User Interface
HAR Highway Advisory Radio
ITS Intelligent Transportation System
NTCIP National Transportation Communications for ITS Protocol
RFP Request for Proposal
TSR Telecommunications Service Request
VRT Vehicle Recovery Tech
|
Logical Site |
A conceptual division of a physical site. A physical site may contain 0 or more logical sites. |
|
|
|
|
|
An occurrence or activity of concern to the CHART system and the recording of information about that occurrence or activity.
|
|
|
|
|
Functional Right |
The right to perform a specified function. |
|
|
|
|
Open Event |
An event which the CHART system is currently engaged in monitoring or managing. |
|
|
|
|
Owner |
A static property that defines the organization who owns the hardware. |
|
|
|
|
Physical Site |
The actual geographic location where a resource is located. |
|
|
|
|
Pollable Device |
A device that supports returning its status on request. |
|
|
|
|
Resources |
Any of the SHA devices, detectors, and equipment available to the CHART system. |
|
|
|
|
Responsible Operations Center |
The operations center that is currently responsible for the management of a device. |
|
|
|
|
Role |
A collection of zero or more function rights. Users are assigned roles and thereby obtain functional rights for performing system functions. |
|
|
|
|
Suitably Privileged User |
A user with the appropriate functional rights to perform an action. |