CHART II Business Area Architecture Report
COORDINATED HIGHWAYS ACTION RESPONSE TEAM
STATE HIGHWAY ADMINISTRATION
CHART II Business Area Architecture Report
January 8, 2006
CHART II Business Area Architecture Report
Revision
0
1
Description
Pages Affected
Initial Release
Update
CHART II Business Area Architecture Report
All
All
i
Date
August 23, 2000
January 8, 2006
January 8, 2006
CHART II Business Area Architecture Report
Table of Contents
1 Executive Summary ............................................................................. 1
1.1
Overview .............................................................................................................................1
1.2
Background ........................................................................................................................1
1.3
Case for Action ...................................................................................................................2
1.3.1 System Problems ............................................................................................................2
1.3.2 Business Problems .........................................................................................................2
1.4
Vision of the Future CHART II System ..........................................................................2
1.5
Overview of the Future CHART II System ...................................................................13
1.5.1 Business Processes .......................................................................................................13
1.5.1.1 Traffic Monitoring, Detection and Verification................................................................ 15
1.5.1.2 Incident, Traffic, Operations Management ....................................................................... 16
1.5.1.3 Traveler Information ......................................................................................................... 18
1.5.1.4 Performance Measurement and Traffic Flow Analysis .................................................... 19
1.5.1.5 External Transportation Management System Interface ................................................... 20
1.5.2 Organization .................................................................................................................21
1.5.2.1 Training Requirements ..................................................................................................... 23
1.5.3 Location .......................................................................................................................23
1.5.4 Application ...................................................................................................................24
1.5.5 Data ..............................................................................................................................25
1.5.6 Technology ..................................................................................................................26
1.6
Performance Objectives of the Future CHART II System ..........................................30
1.6.1 Process Thread Model..................................................................................................30
1.6.2 CHART II Activities Performance Model ...................................................................32
1.6.3 Public Perception .........................................................................................................33
1.7
CHART II Release Strategy ............................................................................................34
2 Business Process Model View .......................................................... 41
2.1
Business Process Direction Model ..................................................................................41
2.1.1 Business Process Principles, Constraints, and Assumptions .......................................41
2.2
Conceptual Business Process Model...............................................................................42
CHART II Business Area Architecture Report
ii
January 8, 2006
CHART II Business Area Architecture Report
2.2.1 Implementation Constraints and Assumptions ............................................................42
2.2.2 Business Process Hierarchy .........................................................................................42
2.2.3 Business Processes by Type.........................................................................................46
2.2.4 Business Process Flows / Data Flow Diagrams ...........................................................51
2.2.4.1 Security and Operational Control ..................................................................................... 51
2.2.4.1.1 System Administration ........................................................................................... 52
2.2.4.1.1.1 Maintain Users ............................................................................................................... 54
2.2.4.1.1.2 Maintain Roles ............................................................................................................... 55
2.2.4.1.1.3 Maintain Functional Rights............................................................................................ 57
2.2.4.1.1.4 Maintain Functional Responsibilities and Alert Types .................................................. 59
2.2.4.1.1.5 Maintain Geographic Responsibility ............................................................................. 61
2.2.4.1.1.6 Maintain Center and AOR ............................................................................................. 62
2.2.4.1.2 Operational Control ................................................................................................ 64
2.2.4.1.2.1 Maintain Center Notepad ............................................................................................... 64
2.2.4.1.2.2 User Logon .................................................................................................................... 66
2.2.4.1.2.3 View Center Situation .................................................................................................... 68
2.2.4.1.2.4 Maintain User Preferences ............................................................................................. 70
2.2.4.1.2.5 Maintain Operator’s Notepad......................................................................................... 71
2.2.4.1.2.6 Perform Chart Chat ........................................................................................................ 73
2.2.4.1.2.7 Logout ............................................................................................................................ 75
2.2.4.1.2.8 Change User ................................................................................................................... 76
2.2.4.1.2.9 Transfer Resources ........................................................................................................ 77
2.2.4.1.2.10 Respond to Request to Transfer Resources .................................................................... 79
2.2.4.1.3 Configuration Processes ......................................................................................... 80
2.2.4.1.3.1 Maintain System Parameters .......................................................................................... 80
2.2.4.1.3.2 Maintain Links ............................................................................................................... 82
2.2.4.1.4 Maintain FITM Plans ............................................................................................. 84
2.2.4.1.5 Map Configuration ................................................................................................. 86
2.2.4.1.5.1 Update MDOT GIS Map Data ....................................................................................... 86
2.2.4.2 System Configuration and Status ...................................................................................... 88
2.2.4.2.1 Components ............................................................................................................ 89
2.2.4.2.1.1 Maintain Component Configuration .............................................................................. 89
2.2.4.2.1.2 Log System Failures ...................................................................................................... 90
2.2.4.2.2 Devices ................................................................................................................... 92
2.2.4.2.2.1 Maintain Device Configuration ..................................................................................... 92
2.2.4.2.2.2 Set Device On-Line........................................................................................................ 93
2.2.4.2.2.3 Set Device Off-Line ....................................................................................................... 94
2.2.4.2.2.4 Set Device to Maintenance Mode .................................................................................. 95
CHART II Business Area Architecture Report
iii
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.2.2.5 Handle DMS and HAR Polling Results ......................................................................... 96
2.2.4.2.2.6 Respond to Device Failure Alerts .................................................................................. 98
2.2.4.3 Incident/Event Management ............................................................................................. 99
2.2.4.3.1 Logs ...................................................................................................................... 101
2.2.4.3.1.1 Log Communications Log ........................................................................................... 101
2.2.4.3.1.2 Log Action Log ............................................................................................................ 104
2.2.4.3.1.3 Log Disabled Vehicle Log ........................................................................................... 106
2.2.4.3.1.4 Log Incident Log ......................................................................................................... 108
2.2.4.3.1.4.1 View Historical vs. Current...................................................................................................... 113
2.2.4.3.1.5 Log Congestion Log .................................................................................................... 114
2.2.4.3.1.6 Log Recurring Congestion Log.................................................................................... 115
2.2.4.3.1.7 Log Special Event Log................................................................................................. 116
2.2.4.3.1.8 Log Weather Advisory Log ......................................................................................... 117
2.2.4.3.1.9 Log Weather Sensor Log ............................................................................................. 118
2.2.4.3.1.10 Log Safety Message Log ............................................................................................. 120
2.2.4.3.1.11 View Log ..................................................................................................................... 121
2.2.4.3.1.12 Close Log ..................................................................................................................... 122
2.2.4.3.2 Location Navigation ............................................................................................. 124
2.2.4.3.2.1 Maintain Location Navigation Data ............................................................................. 124
2.2.4.3.2.2 Activate Location Navigator ........................................................................................ 126
2.2.4.3.3 Queues .................................................................................................................. 128
2.2.4.3.3.1 Calculate Queue Length ............................................................................................... 128
2.2.4.3.4 Notification........................................................................................................... 130
2.2.4.3.4.1 Maintain Notification List ............................................................................................ 130
2.2.4.3.4.2 Perform Notification .................................................................................................... 132
2.2.4.4 Shared Resource Management........................................................................................ 134
2.2.4.4.1 DMS/HAR Common Processes ........................................................................... 137
2.2.4.4.1.1 Maintain Acceptable Word Dictionary ........................................................................ 137
2.2.4.4.1.2 Maintain Unacceptable Word Dictionary .................................................................... 138
2.2.4.4.1.3 Perform Responsibility Reminder ................................................................................ 139
2.2.4.4.1.4 Respond to Responsibility Reminder Alert .................................................................. 140
2.2.4.4.2 DMS Processes ..................................................................................................... 141
2.2.4.4.2.1 Maintain DMS Message Library.................................................................................. 141
2.2.4.4.2.2 DMS – Add a Message ................................................................................................ 143
2.2.4.4.2.3 DMS – Remove a Message .......................................................................................... 145
2.2.4.4.2.4 DMS – Arbitrate Message Queue ................................................................................ 146
2.2.4.4.2.5 DMS – Evaluate Queue ............................................................................................... 148
2.2.4.4.2.6 DMS – Send A Message .............................................................................................. 150
2.2.4.4.2.7 DMS – Blank A Sign ................................................................................................... 151
2.2.4.4.2.8 DMS Reset ................................................................................................................... 151
CHART II Business Area Architecture Report
iv
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.2.9 DMS – Restore Message .............................................................................................. 154
2.2.4.4.2.10 DMS – Override Queue ............................................................................................... 155
2.2.4.4.3 HAR Processes ..................................................................................................... 156
2.2.4.4.3.1 Maintain HAR Message Library .................................................................................. 156
2.2.4.4.3.2 HAR – Add A Message ............................................................................................... 158
2.2.4.4.3.3 HAR – Remove A Message ......................................................................................... 159
2.2.4.4.3.4 HAR – Arbitrate Message Queue ................................................................................ 160
2.2.4.4.3.5 HAR – Evaluate Queue ................................................................................................ 162
2.2.4.4.3.6 HAR – Broadcast A Message ...................................................................................... 164
2.2.4.4.3.7 HAR – Broadcast Default Message ............................................................................. 166
2.2.4.4.3.8 HAR – Set SHAZAM On/Off ...................................................................................... 167
2.2.4.4.3.9 HAR – Update Default Message .................................................................................. 169
2.2.4.4.3.10 HAR – Send Maintenance Command .......................................................................... 170
2.2.4.4.3.11 HAR - Restore Message ............................................................................................... 172
2.2.4.4.3.12 HAR – Override Queue ............................................................................................... 173
2.2.4.4.4 AVCM .................................................................................................................. 175
2.2.4.4.4.1 Maintain Wall Monitor Configuration ......................................................................... 175
2.2.4.4.4.2 Control Wall Monitor Assignment .............................................................................. 177
2.2.4.4.4.3 Maintain CCTV Presets ............................................................................................... 178
2.2.4.4.4.4 Refresh Default AVCM Presets ................................................................................... 179
2.2.4.4.4.5 Maintain Tours ............................................................................................................. 180
2.2.4.4.4.6 Activate Tour ............................................................................................................... 181
2.2.4.4.4.7 Control Camera ............................................................................................................ 182
2.2.4.4.5 Detectors............................................................................................................... 183
2.2.4.4.5.1 Handle Polled Detector Data........................................................................................ 183
2.2.4.4.5.2 Handle Detector Rules ................................................................................................. 185
2.2.4.4.5.2.1
2.2.4.4.5.2.2
2.2.4.4.5.2.3
2.2.4.4.5.2.4
2.2.4.4.5.2.5
Generate Congestion Response ................................................................................................ 187
Respond to Congestion Alert ................................................................................................... 189
Generate Incident Response ..................................................................................................... 191
Respond to Incident Alert ........................................................................................................ 192
Activate Response Plan ............................................................................................................ 193
2.2.4.4.6 Equipment ............................................................................................................ 194
2.2.4.4.6.1 Maintain Equipment Inventory .................................................................................... 194
2.2.4.4.6.2 Maintain Equipment Status .......................................................................................... 195
2.2.4.4.6.3 Alert for Delinquent Equipment Status ........................................................................ 196
2.2.4.4.6.4 Respond to Delinquent Equipment Status Alert .......................................................... 197
2.2.4.4.7 Signals .................................................................................................................. 198
2.2.4.4.7.1 Handle Signal Polling Data .......................................................................................... 198
2.2.4.4.7.2 Respond to Exceeded Signal Threshold Alert ............................................................. 200
2.2.4.4.7.3 Download Signal Data ................................................................................................. 201
2.2.4.4.8 AVL ...................................................................................................................... 203
2.2.4.4.8.1 Handle AVL Polling Results ....................................................................................... 203
CHART II Business Area Architecture Report
v
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.8.2 Perform AVL Function Processing .............................................................................. 204
2.2.4.4.8.2.1
2.2.4.4.8.2.2
2.2.4.4.8.2.3
2.2.4.4.8.2.4
2.2.4.4.8.2.5
2.2.4.4.8.2.6
Process AVL In/Out of Service Message ................................................................................. 206
Process AVL Mayday Message ............................................................................................... 207
Process AVL Arrival On-Scene Message ................................................................................ 208
Process AVL Assist Disabled Vehicle Message ...................................................................... 209
Process AVL Assist Disabled CHART Vehicle Message ........................................................ 210
Process AVL Available Message ............................................................................................. 211
2.2.4.4.8.3 Respond to AVL Alerts ............................................................................................... 212
2.2.4.4.8.3.1 Respond to AVL Mayday Alert ............................................................................................... 212
2.2.4.4.8.3.2 Respond to AVL Arrival On-Scene Alert ................................................................................ 214
2.2.4.4.8.3.3 Respond to AVL Disabled Vehicle Alert ................................................................................. 215
2.2.4.5 Alerts............................................................................................................................... 216
2.2.4.5.1 Send Manual Alert................................................................................................ 217
2.2.4.5.2 Send Alert ............................................................................................................. 218
2.2.4.5.3 Escalate Alert ....................................................................................................... 220
2.2.4.6 Plans ................................................................................................................................ 221
2.2.4.6.1 Maintain Plans ...................................................................................................... 222
2.2.4.6.2 Activate Plan ........................................................................................................ 223
2.2.4.6.3 Deactivate Plan ..................................................................................................... 224
2.2.4.7 Scheduled Events ............................................................................................................ 225
2.2.4.7.1 Maintain Scheduled Events .................................................................................. 226
2.2.4.7.2 Process Scheduled Events Start ............................................................................ 228
2.2.4.7.3 Process Scheduled Events End ............................................................................. 230
2.2.4.8 EORS Interface ............................................................................................................... 231
2.2.4.8.1 Construction ......................................................................................................... 232
2.2.4.8.1.1 Download EORS Permits ............................................................................................ 232
2.2.4.8.1.2 Activate EORS Icons on Map ...................................................................................... 233
2.2.4.8.1.3 Activate EORS Permit ................................................................................................. 234
2.2.4.8.2 Snow Emergency .................................................................................................. 236
2.2.4.8.2.1 Maintain Snow Emergency Declaration ...................................................................... 236
2.2.4.8.3 Phone Book .......................................................................................................... 238
2.2.4.8.3.1 Access Phone Book ..................................................................................................... 238
2.2.4.9 Weather Support ............................................................................................................. 239
2.2.4.9.1 National Weather Service ..................................................................................... 240
2.2.4.9.1.1 View National Weather Service Data .......................................................................... 240
2.2.4.9.1.2 Process Weather Alerts from the National Weather Service ....................................... 241
2.2.4.9.1.3 Respond to National Weather Service Alert ................................................................ 242
2.2.4.9.1.4 Fax Weather Report ..................................................................................................... 243
2.2.4.9.2 SCAN ................................................................................................................... 244
2.2.4.9.2.1 Handle Weather Sensor Data ....................................................................................... 244
CHART II Business Area Architecture Report
vi
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.9.2.2 Generate Weather Sensor Response............................................................................. 246
2.2.4.9.2.3 Respond to Weather Sensor Alert ................................................................................ 248
2.2.4.10Archiving and Reports .................................................................................................... 250
2.2.4.10.1 Archiving .............................................................................................................. 250
2.2.4.10.1.1 Archive Update – Add ................................................................................................. 254
2.2.4.10.1.2 Archive Update – Update Log Data ............................................................................. 255
2.2.4.10.1.3 Real Time System Update – Delete ............................................................................. 257
2.2.4.10.2 Reports.................................................................................................................. 258
2.2.4.10.2.1 Operational Reports ..................................................................................................... 258
2.2.4.10.2.2 Reports from Archive .................................................................................................. 260
2.2.4.11Simulation ....................................................................................................................... 261
2.2.4.11.1 Real-Time Mode................................................................................................... 262
2.2.4.11.2 Off-Line Mode ..................................................................................................... 263
2.2.4.11.3 Training Mode ...................................................................................................... 263
2.2.4.12Other Agencies ............................................................................................................... 264
3 Organization Model View ................................................................. 266
3.1
Organization Direction Model ......................................................................................266
3.1.1 Organization Principles, Constraints, and Assumptions ............................................266
3.2
Organization Model .......................................................................................................267
3.3
Training Requirements .................................................................................................269
3.3.1 Technical training ......................................................................................................269
3.3.1.1 Windows NT 4.0: ............................................................................................................ 269
3.3.1.2 Other technical training .................................................................................................. 269
3.3.2 Functional Training ....................................................................................................269
3.3.2.1 CHART Application Administration: ............................................................................. 269
3.3.2.2 CHART User Functions: ................................................................................................ 269
3.3.2.3 CHART Archive Data: ................................................................................................... 270
3.3.3 User Application Training .........................................................................................270
3.3.3.1 CHART Application User Training: ............................................................................... 270
3.3.3.2 CHART Archive Training .............................................................................................. 270
4 Location Model View ........................................................................ 271
4.1
Location Direction Model..............................................................................................271
4.1.1 Location Principles, Constraints, and Assumptions ..................................................271
4.2
Conceptual Location Model ..........................................................................................271
CHART II Business Area Architecture Report
vii
January 8, 2006
CHART II Business Area Architecture Report
4.2.1 Location Types...........................................................................................................272
4.2.2 Location-Process Matrix ............................................................................................272
4.2.3 Location Hierarchy ....................................................................................................277
5 Application Model View ................................................................... 279
5.1
Application Direction Model .........................................................................................279
5.1.1 Application Principles, Constraints, and Assumptions ..............................................279
5.2
Conceptual Application Model .....................................................................................281
5.2.1 Application Architecture ............................................................................................281
5.2.1.1 Conceptual Application Architecture Diagram............................................................... 281
5.2.1.2 Conceptual Application Areas ........................................................................................ 283
5.2.1.3 Conceptual Application Area Definitions ....................................................................... 284
5.2.1.3.1 Traffic and Roadway Monitoring ......................................................................... 285
5.2.1.3.2 Incident Management ........................................................................................... 288
5.2.1.3.3 Shared Resource Management ............................................................................. 291
5.2.1.3.4 Status Display Management ................................................................................. 294
5.2.1.3.5 System Configuration and Administration ........................................................... 296
5.2.1.3.6 Operations Support ............................................................................................... 299
5.2.1.3.7 Report Generation ................................................................................................ 302
5.2.1.4 COTS Packages .............................................................................................................. 303
5.2.2 Process / Application Matrix .....................................................................................304
6 Data Model Views ............................................................................. 309
6.1
Data Direction Model ....................................................................................................309
6.1.1 Data Principles, Constraints, and Assumptions .........................................................309
6.2
Conceptual Data Model .................................................................................................310
6.2.1 Entity Relationship Diagram......................................................................................310
6.2.2 Entity Definitions .......................................................................................................314
6.2.3 Process/Entity Matrix.................................................................................................320
7 Technology Model View ................................................................... 341
7.1
Technology Direction Model .........................................................................................341
7.1.1 Technology Principles, Constraints, and Assumptions..............................................341
7.1.2 Key Technical Performance Factors ..........................................................................342
7.1.3 Technology Requirements Model ..............................................................................342
CHART II Business Area Architecture Report
viii
January 8, 2006
CHART II Business Area Architecture Report
7.2
Technology Diagnostic Model .......................................................................................345
7.2.1
7.3
Technology Profile.....................................................................................................345
Conceptual Technology Model .....................................................................................346
7.3.1 Technology Concept Diagram ...................................................................................346
7.3.2 Network Concept Diagram ........................................................................................347
7.4
Performance Engineering Model..................................................................................348
7.4.1 System Availability....................................................................................................349
Appendix A – List of Acronyms ........................................................... 350
CHART II Business Area Architecture Report
ix
January 8, 2006
CHART II Business Area Architecture Report
Table of Exhibits
Figure 1-1. Vision Statements by Domain of Change ...................................................................10
Figure 1-2. Vision Statements by CHART Business Objective ....................................................12
Figure 1-3. NIA User Services Provided by CHART....................................................................13
Figure 1-4. CHART Business Process Groupings .........................................................................14
Figure 1-5. Traffic Monitoring, Detection and Verification ..........................................................15
Figure 1-6. Incident, Traffic, Operations Management .................................................................16
Figure 1-7. CHART II Log Types and Descriptions .....................................................................17
Figure 1-8. Traveler Information ...................................................................................................18
Figure 1-9. Performance Measurement and Traffic Flow Analysis ..............................................19
Figure 1-10. External Transportation Management System Interface ...........................................20
Figure 1-11. CHART Organization Chart .....................................................................................21
Figure 1-12. CHART Organizational Responsibilities ..................................................................22
Figure 1-13. CHART II Application Areas ...................................................................................24
Figure 1-14. CHART Application Architecture Interfaces............................................................25
Figure 1-15. CHART Components ................................................................................................27
Figure 1-16. CHART Conceptual Architecture .............................................................................28
Figure 1-17. Network Diagram ......................................................................................................29
Figure 1-18. CHART Threads Performance Objectives ................................................................32
Figure 1-19. Processes by Release Matrix – Page 1/4 ...................................................................38
Figure 1-20. Processes by Release Matrix – Page 2/4 ...................................................................38
Figure 1-21. Processes by Release Matrix – Page 3/4 ...................................................................39
Figure 1-22. Processes by Release Matrix – Page 4/4 ...................................................................40
Figure 2-1. CHART II, Business Process Hierarchy – Part 1 of 2 ................................................44
Figure 2-2. CHART II, Business Process Hierarchy - Part 2 of 2 .................................................45
Figure 2-3. Process by Process Type Matrix, Part 1/4 ...................................................................47
Figure 2-4. Process by Process Type Matrix, Part 2/4 ...................................................................48
Figure 2-5. Process by Process Type Matrix, Part 3/4 ...................................................................49
Figure 2-6. Process by Process Type Matrix, Part 4/4 ...................................................................50
Figure 2-7. Security and Operational Control................................................................................51
Figure 2-8. Maintain User ..............................................................................................................54
Figure 2-9. Maintain Roles ............................................................................................................56
CHART II Business Area Architecture Report
x
January 8, 2006
CHART II Business Area Architecture Report
Figure 2-10. Maintain Functional Rights .......................................................................................58
Figure 2-11. Maintain Functional Responsibilities........................................................................60
Figure 2-12. Maintain Geographic Responsibility.........................................................................61
Figure 2-13. Maintain Center and AOR ........................................................................................63
Figure 2-14. Maintain Center Notepad ..........................................................................................65
Figure 2-15. User Logon ................................................................................................................67
Figure 2-16. View Center Situation ...............................................................................................69
Figure 2-17. Maintain User Preferences ........................................................................................70
Figure 2-18. Maintain Operator's Notepad ....................................................................................72
Figure 2-19. Perform Chart Chat ...................................................................................................74
Figure 2-20. Logout .......................................................................................................................75
Figure 2-21. Change User ..............................................................................................................76
Figure 2-22. Transfer Resources ....................................................................................................78
Figure 2-23. Respond to Request to Transfer Resources ...............................................................79
Figure 2-24. Maintain System Parameters .....................................................................................81
Figure 2-25. Maintain Links ..........................................................................................................83
Figure 2-26. Maintain FITM Plans ................................................................................................85
Figure 2-27. Update MDOT GIS Map Data ..................................................................................86
Figure 2-28. System Configuration and Status ..............................................................................88
Figure 2-29. Maintain Component Configuration .........................................................................89
Figure 2-30. Log System Failures ..................................................................................................91
Figure 2-31. Maintain Device Configuration.................................................................................92
Figure 2-32. Set Device Online .....................................................................................................93
Figure 2-33. Set Device Offline .....................................................................................................94
Figure 2-34. Set Device to Maintenance Mode .............................................................................95
Figure 2-35. Handle DMS and HAR Polling Results ....................................................................97
Figure 2-36. Respond to Device Failure Alerts .............................................................................98
Figure 2-37. Incident Management ..............................................................................................100
Figure 2-38. Communications Log ..............................................................................................102
Figure 2-39. Prototype Communications Log Screen..................................................................103
Figure 2-40. Log Action Log .......................................................................................................104
Figure 2-41. Prototype Actions Log Screen ................................................................................105
CHART II Business Area Architecture Report
xi
January 8, 2006
CHART II Business Area Architecture Report
Figure 2-42. Log Disable Vehicle Log ........................................................................................106
Figure 2-43. Prototype Disabled Vehicle Log .............................................................................107
Figure 2-44. Log Incident Log .....................................................................................................109
Figure 2-45. Prototype Incident Management Log Screen ..........................................................112
Figure 2-46. View Historical Vs. Current ....................................................................................113
Figure 2-47. Log Activity Log .....................................................................................................114
Figure 2-48. Log Recurring Congestion Log ...............................................................................115
Figure 2-49. Log Special Event Log ............................................................................................116
Figure 2-50. Log Weather Advisory Log ....................................................................................117
Figure 2-51. Log Weather Sensor Log ........................................................................................119
Figure 2-52. Log Safety Message Log .........................................................................................120
Figure 2-53. View Log .................................................................................................................121
Figure 2-54. Close Log ................................................................................................................123
Figure 2-55. Maintain Location Navigation Data ........................................................................125
Figure 2-56. Activate Location Navigator ...................................................................................127
Figure 2-57. Calculate Queue Length ..........................................................................................129
Figure 2-58. Maintain Notification List .......................................................................................131
Figure 2-59. Perform Notification ...............................................................................................133
Figure 2-60. Shared Resource Management ................................................................................135
Figure 2-61. Maintain Acceptable Words ....................................................................................137
Figure 2-62. Maintain Unacceptable Words ................................................................................138
Figure 2-63. Perform Responsibility Reminder ...........................................................................139
Figure 2-64. Respond to Responsibility Reminder Alert.............................................................140
Figure 2-65. Maintain DMS Message Library.............................................................................142
Figure 2-66. DMS – Add a Message ...........................................................................................144
Figure 2-67. DMS – Remove a Message .....................................................................................145
Figure 2-68. DMS – Arbitrate Message Queue ...........................................................................147
Figure 2-69. DMS – Evaluate Queue ...........................................................................................149
Figure 2-70. DMS – Send A Message .........................................................................................150
Figure 2-71. DMS - Reset ............................................................................................................153
Figure 2-72. DMS – Restore Message .........................................................................................154
Figure 2-73. DMS – Override Queue ..........................................................................................155
CHART II Business Area Architecture Report
xii
January 8, 2006
CHART II Business Area Architecture Report
Figure 2-74. Maintain HAR Message Library .............................................................................157
Figure 2-75. HAR – Add A Message...........................................................................................158
Figure 2-76. HAR – Remove A Message ....................................................................................159
Figure 2-77. HAR – Arbitrate Message Queue ...........................................................................161
Figure 2-78. HAR – Evaluate Queue ...........................................................................................163
Figure 2-79. HAR – Broadcast A Message .................................................................................165
Figure 2-80. HAR – Broadcast Default Message ........................................................................166
Figure 2-81. HAR – Set SHAZAM On/Off .................................................................................168
Figure 2-82. HAR – Update Default Message .............................................................................169
Figure 2-83. HAR – Send Maintenance Command .....................................................................171
Figure 2-84. HAR - Restore Message ..........................................................................................172
Figure 2-85. HAR – Override Queue ...........................................................................................174
Figure 2-86. Maintain Wall Monitor Configuration ....................................................................176
Figure 2-87. Control Wall Monitor Assignment..........................................................................177
Figure 2-88. Maintain CCTV Presets ..........................................................................................178
Figure 2-89. Refresh Default AVCM Presets ..............................................................................179
Figure 2-90. Maintain Tours ........................................................................................................180
Figure 2-91. Activate Tour ..........................................................................................................181
Figure 2-92. Control Camera .......................................................................................................182
Figure 2-93. Handle Polled Detector Data ...................................................................................184
Figure 2-94. Handle Detector Rules ............................................................................................186
Figure 2-95. Generate Congestion Response ...............................................................................188
Figure 2-96. Respond to Congestion Alert ..................................................................................190
Figure 2-97. Generate Incident Response ....................................................................................191
Figure 2-98. Respond to Incident Alert .......................................................................................192
Figure 2-99. Activate Response Plan ...........................................................................................193
Figure 2-100. Maintain Equipment Inventory .............................................................................194
Figure 2-101. Maintain Equipment Status ...................................................................................195
Figure 2-102. Alert for Delinquent Equipment Status .................................................................196
Figure 2-103. Respond to Delinquent Equipment Status Alert ...................................................197
Figure 2-104. Handle Signal Polling Data ...................................................................................199
Figure 2-105. Respond to Exceeded Signal Threshold Alert ......................................................200
CHART II Business Area Architecture Report
xiii
January 8, 2006
CHART II Business Area Architecture Report
Figure 2-106. Download Signal Data ..........................................................................................202
Figure 2-107. Handle AVL Polling Results .................................................................................203
Figure 2-108. Perform AVL Function Processing .......................................................................205
Figure 2-109. Process AVL In/Out Service Message ..................................................................206
Figure 2-110. Process AVL Mayday Message ............................................................................207
Figure 2-111. Process AVL Arrival On-Scene Message .............................................................208
Figure 2-112. Process AVL Assist Disabled Vehicle Message ...................................................209
Figure 2-113. Process AVL Assist Disabled CHART Vehicle Message ....................................210
Figure 2-114. Process AVL Available Message ..........................................................................211
Figure 2-115. Respond to Mayday Alert from AVL ...................................................................213
Figure 2-116. Respond to Arrival On-Scene Alert from AVL ....................................................214
Figure 2-117. Respond to Disabled Vehicle Alert from AVL .....................................................215
Figure 2-118. Alerts .....................................................................................................................216
Figure 2-119. Send Manual Alert ................................................................................................217
Figure 2-120. Send Alert..............................................................................................................219
Figure 2-121. Escalate Alert ........................................................................................................220
Figure 2-122. Plans ......................................................................................................................221
Figure 2-123. Maintain Plans .......................................................................................................222
Figure 2-124. Activate Plan .........................................................................................................223
Figure 2-125. Deactivate Plan......................................................................................................224
Figure 2-126. Scheduled Events ..................................................................................................225
Figure 2-127. Maintain Scheduled Events ...................................................................................227
Figure 2-128. Process Scheduled Events Start ............................................................................229
Figure 2-129. Process Scheduled Events End..............................................................................230
Figure 2-130. EORS Interface .....................................................................................................231
Figure 2-131. Download EORS Permits ......................................................................................232
Figure 2-132. Activate EORS Icons on Map ...............................................................................233
Figure 2-133. Activate EOR Permit.............................................................................................235
Figure 2-134. Maintain Snow Emergency Declaration ...............................................................237
Figure 2-135. Weather Support....................................................................................................239
Figure 2-136. View National Weather Service Data ...................................................................240
Figure 2-137. Process Weather Alerts from National Weather Service ......................................241
CHART II Business Area Architecture Report
xiv
January 8, 2006
CHART II Business Area Architecture Report
Figure 2-138. Respond to National Weather Service Alert .........................................................242
Figure 2-139. Fax Weather Report ..............................................................................................243
Figure 2-140. Handle Weather Sensor Data ................................................................................245
Figure 2-141. Respond to Weather Sensor Alert .........................................................................249
Figure 2-142. Archiving and Reports ..........................................................................................250
Figure 2-143. Archive Update - Add ...........................................................................................254
Figure 2-144. Archive Update – Update Log Data .....................................................................256
Figure 2-145. Real Time System Update - Delete .......................................................................257
Figure 2-146. Reports ..................................................................................................................259
Figure 4-1. Location-Process Matrix, Part 1/4.............................................................................273
Figure 4-2. Location-Process Matrix, Part 2/4.............................................................................274
Figure 4-3. Location-Process Matrix, Part 3/4.............................................................................275
Figure 4-4. Location-Process Matrix, Part 4/4.............................................................................276
Figure 4-5. CHART II, Location Hierarchy ................................................................................278
Figure 5-1. Application-level Diagram ........................................................................................282
Figure 5-2. Future State Application Names ...............................................................................283
Figure 5-3. Process by Application Matrix - Part 1/4 ..................................................................305
Figure 5-4. Process by Application Matrix - Part 2/4 ..................................................................306
Figure 5-5. Process by Application Matrix - Part 3/4 ..................................................................307
Figure 5-6. Process by Application Matrix - Part 4/4 ..................................................................308
Figure 6-1. Conceptual Entity Relationship Diagram, Part 1/3 ...................................................311
Figure 6-2. Conceptual Entity Relationship Diagram, Part 2/3 ...................................................312
Figure 6-3. Conceptual Entity Relationship Diagram, Part 3/3 ...................................................313
Figure 6-4. Process/Entity Matrix, Part 1/20 ...............................................................................321
Figure 6-5. Process/Entity Matrix, Part 2/20 ...............................................................................322
Figure 6-6. Process/Entity Matrix, Part 3/20 ...............................................................................323
Figure 6-7. Process/Entity Matrix, Part 4/20 ...............................................................................324
Figure 6-8. Process/Entity Matrix, Part 5/20 ...............................................................................325
Figure 6-9. Process/Entity Matrix, Part 6/20 ...............................................................................326
Figure 6-10. Process/Entity Matrix, Part 7/20 .............................................................................327
Figure 6-11. Process/Entity Matrix, Part 8/20 .............................................................................328
Figure 6-12. Process/Entity Matrix, Part 9/20 .............................................................................329
CHART II Business Area Architecture Report
xv
January 8, 2006
CHART II Business Area Architecture Report
Figure 6-13. Process/Entity Matrix, Part 10/20 ...........................................................................330
Figure 6-14. Process/Entity Matrix, Part 11/20 ...........................................................................331
Figure 6-15. Process/Entity Matrix, Part 12/20 ...........................................................................332
Figure 6-16. Process/Entity Matrix, Part 13/20 ...........................................................................333
Figure 6-17. Process/Entity Matrix, Part 14/20 ...........................................................................334
Figure 6-18. Process/Entity Matrix, Part 15/20 ...........................................................................335
Figure 6-19. Process/Entity Matrix, Part 16/20 ...........................................................................336
Figure 6-20. Process/Entity Matrix, Part 17/20 ...........................................................................337
Figure 6-21. Process/Entity Matrix, Part 18/20 ...........................................................................338
Figure 6-22. Process/Entity Matrix, Part 19/20 ...........................................................................339
Figure 6-23. Process/Entity Matrix, Part 20/20 ...........................................................................340
Figure 7-1. CHART II Conceptual Architecture .........................................................................346
Figure 7-2. CHART II Network Concept Diagram .....................................................................347
CHART II Business Area Architecture Report
xvi
January 8, 2006
CHART II Business Area Architecture Report
1 Executive Summary
1.1 Overview
This document was originally released in August, 2000 and has been updated to reflect the work
and progress made to date (January, 2006). Much of the original document remains unchanged
to reflect the original thoughts recorded from the methodology employed to create the BAA
(Business Area Architecture) which is an important point of view to be maintained for CHART
Projects. Diagrams and tables that have been left un-updated for this reason shall be labeled as
(August 2000).
The CHART II project began in Hanover, Maryland on November 30, 1998, after a successful
design competition. In the design competition, CSC/PBFI was provided with application
requirements and responded with a proposed system design and prototype software by which a
determination was made and the contract awarded to CSC/PBFI. As part of the design
competition, the use of CSC’s Catalyst methodology was proposed. The first phase of utilizing
this methodology is the analysis and preparation of this Business Area Architecture Report.
As a result of Catalyst training and the Initiation and Visioning Workshops, it became apparent
that the requirements on which the design competition was based inadequately reflected the
future business objectives of the CHART II system as a system to support State-wide operations,
other SHA agencies, and CHART/SHA partners well into the future. Once this was understood
and the project’s Principles, Constraints and Assumptions were developed to address these
business needs, work proceeded into business process design and development of the business
and system architecture.
This BAA Report focuses primarily on the needs of SHA and the Traffic Operations Centers for
an operational system to manage traffic on state highways, and is not intended to address the
entire vision of CHART as a multi-modal Integrated Transportation System. The approach to
initially concentrate on the operational traffic management aspects of CHART was taken to
address the immediate concerns for a traffic management system to replace the existing system.
This approach was also taken to establish a business and technical baseline on which to conduct
further visioning and business analysis. From here, it would expand into the full statewide multimodal Integrated Transportation System in the future.
The first section of this report is the Executive Summary. Within the Executive Summary, the
project background is reviewed; the case for action is clarified; the vision is reviewed, and the
future Chart II System (broken down by the Six Domains of Change) is summarized.
1.2 Background
CHART (Coordinated Highways Action Response Team) is a joint effort of the Maryland
Department of Transportation and the Maryland State Police, in cooperation with other federal,
state and local agencies. CHART's mission is to improve “real-time” operations of Maryland’s
highway system through teamwork and technology. The CHART program relies on
communication, coordination, and cooperation among agencies and disciplines, both within
Maryland and with neighboring states, to foster the teamwork necessary to achieve our goal. This
is consistent with Maryland’s State Highway Administration’s overall mission, which is to
provide Maryland with an effective and efficient highway system.
CHART II Business Area Architecture Report
1
January 8, 2006
CHART II Business Area Architecture Report
The CHART program is Maryland’s entry into the ITS (Intelligent Transportation System) arena,
and started in the mid-1980s as the “Reach the Beach” initiative, focused on improving travel to
and from Maryland’s eastern shore. It has become so successful that it is now a multijurisdictional and multi-disciplinary program, and its activities have extended not just to the busy
Baltimore-Washington-Annapolis-Frederick Corridors, but into a statewide program. The
program is directed by the CHART Board, consisting of senior technical and operational
personnel from SHA, Maryland Transportation Authority, (MdTA), Maryland State Police
(MSP), Federal Highway Administration, the University Of Maryland Center for Advanced
Transportation Technology (UMd CATT Lab), and various local governments. The board is
chaired by the Chief Engineer of the SHA. This comprehensive, advanced traffic management
system is enhanced by a state-of-the-art command and control center called the Statewide
Operations Center (SOC). The SOC is the “hub” of the CHART system, functioning 24-hours-aday, seven days a week, with satellite Traffic Operations Centers (TOCs) spread across the state
to handle peak-period traffic.
1.3 Case for Action
The current CHART System represents the culmination of work spanning across multiple
contracts and vendors using the original version of this document for direction. Phased releases
of CHART Software containing; Incident Management, Device Control (DMS Dynamic
Message Signs, HAR Highway Advisory Radio, Closed Circuit Televison CCTV) Field
Management Stations (FMS) infrastructure, and System Administration are some of the major
modules that have been released Based on operating experience to date, the MD State Highway
Administration has determined that a complete life-cycle based review and system design is
needed to continue the development of an integrated CHART Automated Transportation
Management System (ATMS) that is more responsive to the State’s needs.

The scope and operational priorities of the CHART System have shifted since the publication
of the original BAA document. The update of this document shall capture the work-to-date
in the CHART Systems Development to complete the original goals and give CHART
Operators the work tools necessary to meet these new requirements especially in the areas of
partnering and information exchange with other agencies
1.3.1 Business Problems

(Travelers) distrust trust the message displayed on a variable message sign

Many informal agreements with partners/agencies

Changing political priorities

Too many subjective operator decisions

No single point of control over participating agencies
1.4 Vision of the Future CHART II System
The justification for Intelligent Transportation Systems is one of managing a national resource,
that resource being our highways and interstates. Concurrent with this justification is the concept
CHART II Business Area Architecture Report
2
January 8, 2006
CHART II Business Area Architecture Report
that better management of our highways (i.e., the flow of traffic on those highways) leads to
traveler cost and time savings through less travel time, fewer accidents, and reduced impact to
the environment caused by emissions from slow or standing vehicles.
The long range vision for ITS is to eventually have technology-equipped vehicles that can select
the most efficient path from trip origin to destination based on computer supplied information
identifying highways with the least congestion or best traffic flow — on a nation-wide basis.
Unfortunately, this is a long-range vision not yet viable with cost effective technology and the
architecture to support it.
It needs to be recognized that the science of ITS is still in its infancy. The National ITS
Architecture was only initially released in 1997, establishing a framework for technology
implementation over the next twenty years driving towards this long range vision for ITS. It also
needs to be recognized that federal, state, regional, and local government agencies have to work
closely with private sector industries to achieve the advances in technology and to share what
traffic management data is available to plan further improvements and progress in the ITS and
transportation management business.
The CHART program fits into the early phases of the National ITS Architecture vision like many
other state and local government organizations — by concentrating on the management of traffic
flow, the coordination of responses to incidents, the providing of traveler advisories, and the
gathering and providing of the data necessary for further analysis and planning. The CHART
vision is comprised of four major categories of business objectives:
1. CHART has been developed to be a statewide traffic management system, not limited to
one or two specific corridors of high traffic volumes, but expandable to cover the entire
state as funds, resources, and roadside equipment become available to support traffic
management.
2. CHART has evolved into a coordination focal point, able to identify incidents,
congestion, construction, road closures and other emergency conditions; and then able to
share data and coordinate response with various agencies, as necessary, to respond to
recurring and non-recurring congestion and emergencies. It should also manage traffic
flow with traveler advisories and signal controls, and coordinate or aid in the cleanup and
clearance of obstructions.
3. CHART is an information provider, providing real-time traffic flow and road condition
information to travelers and the media broadcasters, as well as providing real-time and
archived data to other state agencies and local, regional, inter-state, and private sector
partners.
4. CHART is a 7 day per week, 24 hours per day operation with the system performing
internal processing and status checks to detect failed system components and resetting or
reconfiguring itself where appropriate, or notifying operators and/or maintenance staff
where necessary for service.
During the CHART Visioning sessions, CHART management and operations staff expressed
many aspects of their vision for CHART from both a business and system perspective. These
vision statements were previously published in vision meeting minute’s documents. As this BAA
Report is limited to the operations aspects of Traffic Management, not all the expressed vision
statements for CHART have been addressed. The following three tables summarize which
aspects of the vision statements are addressed in this BAA Report and provide a scorecard to
CHART II Business Area Architecture Report
3
January 8, 2006
CHART II Business Area Architecture Report
determine those aspects of the vision requiring further analysis to achieve the overall vision for
CHART.
In the first and second tables, the statuses of “Full”, “Part”, and “None” are used to identify the
extent to which these vision statements have been addressed within the scope of this BAA
Report. The third table uses “Yes” and “No” to identify the National ITS architecture (NIA)
User Services covered by this BAA Report.
The first vision statements table summarizes the status of vision statements addressed as related
to the Systems Delevlopment Domains of Change.
CHART II Business Area Architecture Report
4
January 8, 2006
CHART II Business Area Architecture Report
Vision Statement
Full
Part
None
Business Process:
CHART II is an appropriately automated,
fully integrated system that operates
seamlessly across jurisdictional
boundaries and permits effective multimodal monitoring, control, and
performance evaluation by the
appropriate entities.
Faster response = faster recovery = lives
saved
Integrated Response
“Libraries” and Dispersed
“Field Management
Stations” have greatly
increased the system
speed.
Increased partnerships
(now over 50 ops centers
use CHART) have greatly
increased speed of
incident verification
CHART Map introduced
in R1B4
Assigned to one Center in
R1B2
Better verification of incidents
Incident location identification (ramp
IDs?)
Incident assigned to one person
Full
Part
Prediction of the magnitude of an incident
All responses to incidents are pre-planned
Part
Automate the response to incidents
Part
Integration of agency response
Incident queue monitoring
None
Full
Full
Arterials considered in incident response
Pre-planned incident response plans
CHART II Business Area Architecture Report
Comments
Part
Part
5
Libraries intrduced in
R1B2
For detector based and
operator initiated incident
responses
Assuming detector
availability for specific
applications
For FITM scenarios
Libraries intrduced in
R1B2
January 8, 2006
CHART II Business Area Architecture Report
Vision Statement
Full
Organization:
The CHART II system is an appropriately
automated, user friendly system that
requires minimal training and fosters
inter-organizational coordination among
all groups involved in surface
transportation for the sharing of
information and management of
resources.
Planning and CHART share devices — no
system should disable devices
Part
Not just SHA -> Statewide and all
operating agencies
Shared application capabilities “like an
internet”
Shared coordination of agencies through
system capabilities
Manage all traffic incidents
Part
Full
Part
Full
Location:
CHART II is a statewide system that
includes all major transportation facilities
for highway and transit in all counties and
Baltimore City. CHART II includes an
interconnected system of transportation
operation centers located in all agencies
(state, local, regional, and federal)
involved in transportation management.
CHART II contains both fixed and mobile
subsystems.
Virtual SOC
Full
CHART II Business Area Architecture Report
Part
6
None
Comments
Device data is available
to Planning through the
Archive, as well as CCTV
when available
Current MDOT network
extended to non-MDOT
agencies. Internet-based
CHART planned for
future Release
CHART Lite introduced
R1B3
As related to responses to
Incidents and Actions
Related to state highways
and arterials
Operations Center
Concept introduced in
R1B2
January 8, 2006
CHART II Business Area Architecture Report
Vision Statement
Application
CHART II is a truly integrated and
interoperable statewide system of
transportation applications in partnership
with organizations that provide
transportation management, information,
and emergency services. This will
enhance mobility while minimizing the
economic and environmental impacts.
Click on device on map and get
speed/volume information
Full
Part
Full
Easy way to retrieve data without Oracle
expertise
Part
Include weather system data/conditions
Full
To expand coverage – FITM routes and
major arterials
Identify failures
Full
Support #77 data capture
Exploit CCTV to the greatest extent
possible (Verification, Critique tool,
Training)
Real-time collection of incident data
Full
Landmarks tied into map
Full
Real-time incident status
Full
System determined sharing of resources
Full
Full
Part
Full
Status of construction
Part
Automated information exchange
Part
CHART II Business Area Architecture Report
7
None
Comments
Speed Sensors introduced
in R1B2 CHART Map
introduced in R1B4
Initial Reporting Tool in
R1B2. COTS reporting
package introduced in
R1B4
Included in CHART Map
introduced in R1B4
Included in CHART Map
introduced in R1B4
Graphical change in
device state with logging
introduced in R1B2
No specific processes for
critique and training
Initial Reporting Tool in
R1B2. COTS reporting
package introduced in
R1B4
Included in CHART Map
introduced in R1B4
Event-based control
introduced in R1B2
Event-based control with
CORBA Brokers
introduced in R1B2
Planned Roadwork Events
introduced in R1B2,
EORS download added in
R1B3
CORBA Brokers
introduced in R1B2
January 8, 2006
CHART II Business Area Architecture Report
Vision Statement
“CHART- Lite” for other (nonoperational) agencies
Data
CHART II provides a framework to
collect, analyze, disseminate, and utilize
accurate real-time and archived
transportation data from all current and
future sources in an open and accessible
format.
Download data to manipulate it for
performance measures
Full
Full
Download data to manipulate it for
planning (Construction, Maintenance,
Traffic Management)
Full
Speed, occupancy, flow rate (individual,
average, and variance)
Full
None
Part
Comments
CHART Lite introduced
R1B3
Oracle Database set up in
R1B2. Initial Reporting
Tool in R1B2. COTS
reporting package
introduced in R1B4
Oracle Database set up in
R1B2. Initial Reporting
Tool in R1B2. COTS
reporting package
introduced in R1B4
Oracle Database set up in
R1B2. Initial Reporting
Tool in R1B2. COTS
reporting package
introduced in R1B4
Current Detector data
available in reporting tool.
Data interchange
standards to be developed
in Design Phase
Full
Full
Detector-based congestion
and incident response
Oracle Database set up in
R1B2. Initial Reporting
Tool in R1B2. COTS
reporting package
introduced in R1B4. Live
feed to UMD introduced
in R1B4
Part
Calculate travel time and
origin/destination
CHART II Business Area Architecture Report
None
Full
Monitoring data for travelers — Travel
rate index (vs. benchmark), Predictive
measurements, Emphasis on customer
useable data, Disclaimer
Acquire and share data from other
agencies
No jurisdictional boundaries for
dissemination
Correlate Monitoring with Incident
Management
Cost/Benefit analysis
Part
None
8
January 8, 2006
CHART II Business Area Architecture Report
Vision Statement
Correlate monitoring w/ VMS & TAR
Transit data
Data interface with simulation package
Ability to have duration data (duration of
incidents)
Full
Full
Full
Full
Full
Data should be lane specific
Data must be referenced geographically
Full
Full
Comments
Oracle Database set up in
R1B2. Initial Reporting
Tool in R1B2. COTS
reporting package
introduced in R1B4. Live
feed to UMD introduced
in R1B4
Oracle Database set up in
R1B2. Initial Reporting
Tool in R1B2. COTS
reporting package
introduced in R1B4. Live
feed to UMD introduced
in R1B4
Full
Availability of database of historical video
clips
Device status and history
Full
CHART II Business Area Architecture Report
None
None
Ability to evaluate data for changing
sensor locations, density, etc.
Categorize data for recurring/nonrecurring special events
The ability to critique incident response
Part
Full
9
Oracle Database set up in
R1B2. Initial Reporting
Tool in R1B2. COTS
reporting package
introduced in R1B4. Live
feed to UMD introduced
in R1B4
Oracle Database set up in
R1B2. Initial Reporting
Tool in R1B2. COTS
reporting package
introduced in R1B4. Live
feed to UMD introduced
in R1B4. CHART Map
introduced in R1B4
None
Oracle Database set up in
R1B2. Initial Reporting
Tool in R1B2. COTS
reporting package
introduced in R1B4. Live
feed to UMD introduced
in R1B4
Part of Simulation
January 8, 2006
CHART II Business Area Architecture Report
Vision Statement
Automatically compute cost benefit
Import/export information from other
agencies/systems
Full
Technology:
The CHART II system is based upon
requirements driven technology that
allows for an open architecture and
modular applications and is capable of
evolving as functional, performance, and
technological needs change.
Parking monitoring and ramp metering
Data should be available in the field
Part
Part
Part
None
Comments
Archive report
Data interchange
standards to be developed
in Design Phase
None
Part
In-vehicle systems
Integrate CAD’s (Computer Aided
Dispatch)
Part
Multi-modal multi-jurisdiction status
notification system
Part
None
CHART Lite introduced
R1B3. Vehicle MDT
introduced with CAPWIN
in R1B3. AVL
Introduced in R2B1
AVL Introduced in R2B1
Capabilities needed for
this will be determined
through a separate effort
and possibly incorporated
into future releases of
CHART
Notification is via Pager,
Fax, and/or E-Mail.
Additional capabilities to
be identified through the
functional visioning effort
and incorporated into
future releases of CHART
Figure 1-1. Vision Statements by Domain of Change (August 2000)
The second vision statements table summarizes the status of vision statements addressed as
related to the CHART Business Objectives.
Vision Statement
Business Objectives
Managing Non-Recurring Transportation
Conditions
Managing Recurring Transportation
Conditions
CHART II Business Area Architecture Report
Full
Part
None
Comments
Full
Full
10
January 8, 2006
CHART II Business Area Architecture Report
Vision Statement
Managing Transportation Data and
Information
Develop a cost effective operating
capability that is efficient to maintain
Specific Strategies
Managing Non-Recurring
Transportation Conditions
Benchmark
Apply technology aggressively
Conservative integration of signals
Managing Recurring Transportation
Conditions
Benchmark
Apply technology aggressively
Execute inter-jurisdictional agreements
for inter-operable deployment of
technology and operations
Use technology to share resource
availability between jurisdictions
Deploy incident detection and validation
devices, software, and algorithms
Evaluate alternative response plans for
incidents
Managing Transportation Data and
Information
Make access to near-real-time and
archived data/information easily available
to authorized customers
Develop a cost effective operating
capability that is efficient to maintain
Benchmark
Application of aggressive technology
Identify commonly used Operations and
Management data types specific to
specific devices
Proceduralize
Automate
Allocate to appropriate staff level
Train
Critical Success Factors
Architecture accommodates scalability to
add new device types
Provide valuable information
CHART II Business Area Architecture Report
Full
Full
Part
None
Comments
Full
Full
Full
Full
Full
Full
None
Part
Full
Full
Full
Full
Full
Full
Full
Full
Full
Full
Full
Full
11
January 8, 2006
CHART II Business Area Architecture Report
Vision Statement
Demonstrate improvement using
performance objectives
Ensure courteous, personalized, and
responsive public service
Critical Business Issues
Scope creep (both within the business and
the system)
Resource sharing
Y2K issues that could possibly cause
CHART to shut down
Coordination between different
development projects
Customer Needs Summary
Emergency
En Route Driver Information
Route Guidance
Traffic Control
Incident Management
Highway-Rail Intersection
Demand Management Operations
Pre-Trip Travel Information
Public Transportation Management
En Route Transit Information
Electronic Payment Services
Commercial Vehicle Administration
Process
Hazardous Material Incident Response
Emergency Notification & Personal
Security
Emergency Vehicle Management
Full
Full
Part
None
Comments
Part
Covers responsiveness
Part
Limited to SOC/TOC area
of responsibility
Part
Principal to be applied in
Development Phase
Full
None
Full
Full
None
Part
Traffic surveillance
Full
None
None
Part
CHART web site
None
Full
None
None
None
None
Part
AVL
Figure 1-2. Vision Statements by CHART Business Objective (August 2000)
The third table summarizes the status of the User Services of the National ITS architecture as
they relate to what will be provided by CHART. Some of the User Services shown below are not
part of CHART because the initial implementation of the CHART system is viewed as an
operational application for SHA and the management of traffic on the state highways and the
arterial roadways. Closer Coordination with the National ITS Architecture is a high priority for
the next round of CHART development.
National ITS Architecture User Service
1.0 Travel and Traffic Management
1.1 Pre-Trip Travel Information
CHART II Business Area Architecture Report
12
Provided by CHART
Yes
January 8, 2006
CHART II Business Area Architecture Report
National ITS Architecture User Service
1.1.2 Current Situation Information
1.1.4 User Access Information
1.2 En-Route Driver Information
1.2.1 Driver Advisory
1.3 Route Guidance
1.6 Traffic Control
1.6.2 Traffic Surveillance
1.7 Incident Management
1.7.1 Scheduled Planned Incidents
1.7.2 Identify Incidents
1.7.3 Formulate Response Actions
1.7.4 Support Coordinated Implementation of Response
1.7.5 Support Initialization of Response Actions
1.7.6 Predict Hazardous Conditions
1.8 Travel Demand Mgmt.
1.8.1 Communications Function
1.8.2 Processing Function
1.10 Highway-Rail Intersection
2.0 Public Transportation Management
2.1 Public Transportation Management
2.2 En-Route Transit Info.
3.0 Electronic Payment
3.1 Electronic Payment Services
4.0 Commercial Vehicle Operations
4.4 Commercial Vehicle Administrative Processes
4.5 HazMat Incident Response
5.0 Emergency Management
5.1 Emergency Notification & Personal Security
5.2 Emergency Vehicle Management
7.0 Information Management
7.1 Archived Data
7.1.1 Historical Data Archive
7.1.2 Operational Data Control
7.1.3 Data Import & Verification
7.1.4 Automatic Data Historical Archive
Provided by CHART
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Figure 1-3. NIA User Services Provided by CHART (August 2000)
1.5 Overview of the Future CHART II System
1.5.1 Business Processes
CHART II Business Area Architecture Report
13
January 8, 2006
CHART II Business Area Architecture Report
The CHART program provides statewide traffic management services for the state highways of
Maryland. Traffic management as performed by CHART is comprised of five major groups of
processes. The following groups of future processes are illustrated in the following diagram and
defined in the following paragraphs for the CHART II system.
TRAFFIC
MONITORING,
DETECTION,
VERIFICATION
INCIDENT,
TRAFFIC,
OPERATIONS
MANAGEMENT
TRAVELER
INFORMATION
PERFORMANCE
MEASUREMENT
AND
TRAFFIC FLOW
ANALYSIS
EXTERNAL
TRANSPORTATION
MANAGEMENT
SYSTEM
INTERFACE
Figure 1-4. CHART Business Process Groupings (August 2000)
1. Traffic monitoring, detection and verification — CHART utilizes various technologies for
monitoring traffic flows and roadway conditions to detect problem spots requiring attention.
Some of the technologies include CCTV, telephone, radio, roadside detectors, roadside
weather stations.
2. Incident, traffic, operations management — CHART manages seven specific types of
activities as related to the management of incidents, traffic flow, and operational
management of the program. These ten activities have been related to events that will be
utilized to identify each event and record the actions taken to manage the particular event.
These events then form the basis for performance measurement data and are the basis for
analysis and simulation of CHART responses to study and formulate better response
capabilities in the future.
3. Traveler information — CHART provides traveler information to the media, the traveling
public and to other traffic management organizations for pre-trip planning, en-route planning,
public travel safety, and scheduled planned closures. Traveler information is dispersed
through roadside devices (DMS and HAR), over the Internet, through sharing of CCTV
video streams, and through sharing of stored data.
4. Performance measurement and traffic flow analysis — CHART archives data related to
traffic flow, weather, and the activities managed by the program to establish and maintain a
CHART II Business Area Architecture Report
14
January 8, 2006
CHART II Business Area Architecture Report
data set by which statistical and operational performance measurements can be calculated
and evaluated, and reenactments of activities may be simulated and evaluated for best
practices.
5. External transportation management system interface — CHART provides manual and
automated interfaces to other jurisdictional traffic management systems so as to be aware of
traffic situations in those jurisdictions and to provide appropriate traveler information to
travelers approaching those jurisdictions or those travelers approaching CHART managed
roadways.
1.5.1.1 Traffic Monitoring, Detection and Verification
TRAFFIC MONITORING, DETECTION, VERIFICATION
PHONE
RADIO
DETECTOR
SENSOR
SIGNAL
CCTV
Figure 1-5. Traffic Monitoring, Detection and Verification (August 2000)
CHART utilizes both manual and automated capabilities to monitor, detect and verify traffic
conditions.
CHART operators manually receive reports of incidents, traffic congestion and maintenance
needs (signal outages, broken signs, debris in roadway, etc.) via telephone and radio. Most of the
telephone calls come through the 911 System and #77 telephone system from the Maryland
State Police, others are direct calls to the SOC and TOC’s. Radio calls are received from the
MSP, CHART Emergency Traffic Patrol (ETP), and CHART Emergency Response Unit (ERU)
vehicles. Manual operator initiation of a CHART event is required to record the activity and the
responses made to the reported situation.
To date CHART receives traffic flow data from detectors roadside mounted radar detectors and
does very minimal processing with the data. As stated in the original BAA it is still CHARTs
goal to receive traffic flow data from Signal traffic counters. CHART plans to analize this data,
comparing it to calculated “normal” traffic flows and determines abnormal traffic flows. Results
of the CHART analysis may result in the automated alerting of CHART operators to abnormal
traffic conditions, and the automated initiation of a CHART event and an automated response to
the condition. CHART also receives data from Weather stations and road surface sensors.
CHART plans to analyses this data and determine when hazardous driving conditions exist.
When hazardous driving conditions are detected, CHART will alerts operators and initiates a
CHART event and an automated response.
CCTV are primarily used to verify reported traffic incidents, congestion and maintenance
activities, but occasionally may be a manual method of detecting traffic problems. As the
location of a traffic problem is identified to CHART, the system should in the future attempt to
select a CCTV within a specified range of the location and give control of that CCTV to the
operator to verify the traffic situation.
CHART II Business Area Architecture Report
15
January 8, 2006
CHART II Business Area Architecture Report
1.5.1.2 Incident, Traffic, Operations Management
INCIDENT, TRAFFIC, OPERATIONS MANAGEMENT
INCIDENT MGMT
TRAFFIC MGMT
INCIDENT
CONGESTION
COMMUNICATIONS
MGMT
HIGHWAY MAINT
MGMT
RECURRING
CONGESTION
COMMUNICATIONS
ACTION
OPERATIONS MANAGEMENT
WEATHER SENSOR
SPECIAL EVENT
TRAVELER SPT MGMT
DISABLED VEHICLE
WEATHER
ADVISORY
SAFETY MESSAGE
Figure 1-6. Incident, Traffic, Operations Management (August 2000)
The CHART system supports the management of CHART activities through the use of events.
Events are used to identify each occurrence of each type of activity performed by the CHART
program, and to track each action taken in response to the activity until the occurrence is
completed and the event is closed. Responsibility for managing an activity or event is controlled
by assigning an event to one of the operating centers defined in the system. Responsibility may
be transferred between operating centers by assigning a event to another operating center.
Events may be managed by multiple operating centers at one time.
In addition to using Events to manage CHART program activities in-process, archived event data
form the basis for performance measurements and provide data for simulation exercises.
The activities and event types are identified and defined in the following table.
Event Type
Action Event
Communications Log
Congestion Event
Description
Action events are for managing a maintenance type activities
requiring coordination with SHA or other organizations to make
repairs or cleanup to highways or traffic control devices. Operator
initiated Action Events are usually related to signal outages, debris
on the shoulder of the roadway or utility repairs. System initiated
Communications log is for recording all non-action required
communications. Primarily used to record in-service/out-of-service
calls. As most activities are started via phone or radio calls, most
operator-initiated events begin as Communication logs and then
change to their specific activity type.
Congestion Events are currently operator initiated. Analysis of Congestion
logs may be used to aid in the identification of recurring congestion spots.
It is still a goal of CHART to automate the detection and response to
recurring congestion events. Congestion Events are automatically ported to
the CHART Web site.
CHART II Business Area Architecture Report
16
January 8, 2006
CHART II Business Area Architecture Report
Event Type
Disabled Vehicle Event
Incident Event
Special Event
Safety Message Event
Weather Event
Description
Disabled Vehicle Events records identification and location of
disabled vehicles and actions taken to remove the vehicle or in
obtaining assistance for the motorist. These logs are operator
initiated; however it is desired to allow for automation (via the AVL
processes) in the future.
Incident Event identifies non-planned roadway closures. Includes all
activities that impact travel lanes (Debris, Police Activity, Incidents)
Identifies actions taken, people/organizations notified, vehicles
dispatched/on-scene, queue length, duration, etc. These Events are
operator-initiated; however it is desired to allow for automation (by
the analysis of detector data). Incident Events are automatically
ported to the CHART Web site.
Special Event, identifies and records actions taken to manage traffic
related to sporting events, parades, etc. Special Events are
automatically ported to the CHART Web site.
Safety Message Event identifies the use of devices to
display/broadcast safety or public service information.
Weather Events identifies the use of devices to display/broadcast
weather advisory information. This event type is operator-initiated
and identifies any actions taken to advise the public via CHART
devices of weather related information.
Figure 1-7. CHART II Log Types and Descriptions
CHART II Business Area Architecture Report
17
January 8, 2006
CHART II Business Area Architecture Report
1.5.1.3 Traveler Information
TRAVELER INFORMATION
MEDIA / INFORMATION PROVIDER SUPPORT
DMS
HAR
SHA WEB PAGE
SUPPORT
CCTV
INCIDENT
INTERCHANGE
DATABASE
Figure 1-8. Traveler Information (August 2000)
The CHART system supports and controls the disbursement of traveler information to various
devices, systems, and organizations.
The primary means of providing en-route traveler information to Maryland’s motorists is through
Dynamic Message Signs (DMS) and Highway Advisory Radio (HAR). The CHART system
supports the use of these devices through the use of message libraries to provide operator access
to pre-recorded messages organized by topic and simplified user interfaces to select messages
and related devices. The system is designed to aid users in resolving contention for use of the
devices by providing arbitration capabilities. These capabilities allow operators to assign
messages to devices, and let the system determine which of multiple messages designated for a
single device actually gets displayed or broadcast.
These capabilities include: a) maintenance of a message queue for each device, b) an arbitration
algorithm to determine message priorities, and c) appropriate processes to display/broadcast
messages on designated devices, remove messages from devices, and interface with event
processes to record actions of when messages are queued and when they are actually sent to or
removed from the devices. Capabilities are also provided for authorized operators to force nonstandard priority levels on messages when the situation may require some variation to the
standard process.
The SHA maintains a Web page for pre-trip planning, providing the public with real-time traffic
event data, traffic flow information, video feeds, and weather sensor data and pictures. CHART
provides capabilities to make data available and to control the access to the video feeds presented
on the Web page. One specific capability of CHART is the ability to stop video feeds from going
outside of CHART in the event that an operator takes control of a camera for any reason.
In order to provide information to other organizations and to the media, there is a closed-circuit
television (CCTV) system. The CCTV system is used for traffic monitoring and various feeds
from the system are made available to other organizations (i.e., Montgomery County).
Maryland is a member of the I-95 Corridor Coalition, which is comprised of multiple
agencies/organizations responsible for transportation along the northeast section of the corridor
from Florida to Maine. The Coalition’s mission is to “work cooperatively to improve mobility,
safety, environmental quality and efficiency of inter-regional travel in the northeast through realtime communication and operational management of the transportation system. In doing so, the
CHART II Business Area Architecture Report
18
January 8, 2006
CHART II Business Area Architecture Report
Coalition seeks to establish an economically beneficial multi-modal framework for early
implementation of appropriate ITS technology.”
1.5.1.4 Performance Measurement and Traffic Flow Analysis
PERFORMANCE MEASUREMENT AND TRAFFIC FLOW ANALYSIS
Incident,
Traffic,Operations
Management
Archive
Detectors
Weather
Sensors
Signals
Figure 1-9. Performance Measurement and Traffic Flow Analysis (August 2000)
CHART organizes and stores data for the purposes of calculating performance measurements
and performing traffic flow analysis.
CHART stores data related to operational events/logs (described in the Incident, Traffic,
Operations Management section above) in an online, operational database for a period of 24
hours after each event is closed. Each day, the current day’s data is copied to the Archive
database for offline access. Traffic flow analysis data is downloaded to the Archive database on a
daily basis. In this manner, the Archive database is never more than 24 hours out of date with
the operational activities. Data for performance measurements is contained in both the
operational database and the Archive database. Data for traffic flow analysis is stored in the
Archive database.
PERFORMANCE MEASUREMENT DATA
CHART utilizes events to identify and organize data related to each activity performed by the
operations staff. Each event identifies a single traffic or operational event, providing a means to
manage the event and to record all activities related to the specific event. Each event includes
data identifying the operational center managing the event and event-level data to capture the
start/end times and the status of the event. Open events indicate the current events in progress
and are used to identify the current work in process. Any activity related to a event is recorded
as part of the event (DMS, HAR, Alerts, Notifications, actions taken by other organizations,
etc.).
The CHART events form a basis for calculating operational performance measurements. From
these event logs SHA/CHART management can calculate numbers of events, average duration of
events, frequencies of types of events, numbers of events per specific roadway or operational
center, etc. Data contained within these logs can be analyzed to determine the numbers of times
messages were displayed on DMS’s or broadcast on HAR’s, which signs or radios were used,
and the numbers of messages related to event types.
Because CHART utilizes a queuing approach to control contention for use of individual signs
and radios, the logs identify when messages are initially queued, when they are actually
CHART II Business Area Architecture Report
19
January 8, 2006
CHART II Business Area Architecture Report
displayed or broadcast, when they are removed from the sign or radio, etc. Analysis of these
timings may disclose specific signs and radios having high usage and contention, and thereby
identify locations for additional devices. In early 2006 a Commercial-of-the-Shelf web based
reporting tool will be completed. This tool will allow CHART Manager to run pre-defined
reports to view the data from both the operational and archive databases.
TRAFFIC FLOW ANALYSIS
Detector data, weather sensor data, and signal data (signal data is not currently integrated into
CHART and detailed weather data is viewed from a stand alone system) is downloaded from
respective devices on a daily basis to the Archive database. This data is maintained in raw data
format. Traffic engineers having access to the Archive database may analyze the data in the
Archive, or download the data to their respective analysis tools.
SIMULATION
The Archive database contains both operational event data and detector/sensor data, thereby
providing highway conditions for traffic flow and identification of any actions taken by the
CHART operations staff. Through use of Simulation tools capabilities, this data can be
combined and analyzed to review/display actions taken by the operations staff (display of signs,
etc.) and the resultant change in traffic flows. This analysis can then be utilized in various ways
to analyze successful and unsuccessful traffic management methods and form a basis to
demonstrate and train the operations staff in better methods. Currently the University of
Maryland CATT Lab is using CHART Archive Data to create traffic simulation tools.
1.5.1.5 External Transportation Management System Interface
EXTERNAL TRANSPORTATION MANAGEMENT SYSTEM INTERFACE
PROVIDE / RECEIVE INFORMATION
Partners In
Motion
Transcom
Media
EXCHANGE & CONTROL
Other
Maryland
Agencies
Montgomery
County
VDOT
Figure 1-10. External Transportation Management System Interface (August 2000)
CHART provides incident information to traffic management partners through our public web
page. These partners include the media, public traveler information providers, and traffic
management organizations of other states and other Maryland jurisdictions. As basic Incident
information is collected and updated in CHART, the Incident data feed is updated. The next step
for this data feed is in future software releases is to follow the national standard for Center to
Center communications. Implementation of Center to Center will realize the orginal BAA’s
defined vision for external data sharing.
CHART II Business Area Architecture Report
20
January 8, 2006
CHART II Business Area Architecture Report
In addition to exchanging Incident information with nearby state and regional traffic
management organizations, CHART would like to have a more direct system interface in which
CHART operators could view selected cameras and control selected signs. Camera viewing
would be useful to monitor traffic flows near the Maryland borders so that travelers could be
warned of congestion or incidents ahead. Conversely, use of signs in these other systems could
be used to advise travelers of conditions as they enter Maryland. The goal of establishing system
interfaces with these organizations is in keeping with the vision of the National ITS Architecture,
but it should be expected that these CHART goals may be politically and technically
challenging.
1.5.2 Organization
This section presents the organizational structure for CHART, and specifies the expected duties
of the organizational entities, as related to the deployment of a new CHART system. There was
no intent in the BAA exercise to analyze and recommend a re-organization of the CHART
organization, but merely to understand the organization and to make suggestions for training
needs for the CHART II system.
The following diagram shows the current CHART Organization:
CHART Organization Chart
SHA
Chief Engineer
CHART
Board
CHART
Program
Manager
Operations Team
ITS Development
Team Manager
Integration Team
CHART ITS Systems
Admin
Figure 1-11. CHART Organization Chart
CHART II Business Area Architecture Report
21
January 8, 2006
CHART II Business Area Architecture Report
The following table identifies the major responsibilities of the organizational entities as related to
the deployment, management, and operation of the CHART system described in the other
sections of this document. The responsibilities identified in this table also reflect many of those
responsibilities necessary to continue the growth of CHART, as well as support the continuing
efforts to further integrate other systems and transportation models into a state-wide ITS.
Organizational Entity
SHA Chief Engineer



Major Responsibilities
Strategy and Planning
Manage budget and funding
Define business objectives
CHART Program Manager




Strategy and Planning
Manage budget and funding
Define, measure, and manage business objectives
Define and monitor operational objectives
Operations Team



Traffic management of state highways and arterials
Manage ETP, ERU and HOT operations
Monitor, measure, and manage operational
accomplishments
Plan, prepare, and conduct ER training
Investigate new technologies
Develop ITS strategy
Define ITS objectives
Manage ITS development and deployment
ITS Development Team
Manager
Integration Team —
CHART ITS Systems
Admin














ITS Systems planning and strategy
Maintain infrastructure equipment and configuration
CHART application administration and configuration
Network administration and maintenance
Legacy systems administration
Applications change control and configuration
management
CHART application maintenance
Database administration
CHART functional and user training
Figure 1-12. CHART Organizational Responsibilities (August 2000)
Many of the major responsibilities for the Integration Team — CHART ITS System Admin
organization are supported by contract personnel during the development of CHART II and,
afterwards, as part of application maintenance and hardware maintenance contracts.
CHART II Business Area Architecture Report
22
January 8, 2006
CHART II Business Area Architecture Report
1.5.2.1 Training Requirements
Deployment of a new system can have an adverse affect on an organization, unless appropriate
training is provided. With so many of the aspects of the new system being different from the old
system and the system environment, several types of training will be required to prepare the
organization to effectively utilize, administer, and maintain the system. The three types of
training, which have been identified as necessary, are: Technical, Functional, and User
Application training.
Technical Training
 Windows Operating System – To assist system administrators and users with understanding
the complexities of Windows Servers.
 System support training in Oracle, ATM Switch, Mux, Routers, etc.
Functional Training
 CHART Application Administration – To provide a functional overview of the system
parameters and configuration data used in the CHART applications to control the processing
options and flexibility of the applications.
 CHART User Functions – To provide the users with a conceptual view of the processes
supported by the CHART applications. Introducing users to any new terminology, situations
to utilize each function, and the business objectives and reasons for performing each
function.
 CHART Archive Data – To provide users with an overview of the data being retained in the
Archive Database and its logical structure and relationships
User Application Training
 CHART Application User Training – To provide CHART users with application-level
training, and to be directed to training individuals in the use of the CHART II application at a
screen level.
 CHART Archive Training – To provide Archive users with instructions on use of standard
and alternative tools to select, extract, and report on data in the Archive.
1.5.3 Location
The BAA for CHART II focused mainly on the traffic operations of the State of Maryland’s state
highways and arterial roadways. As a result, the locations identified for the CHART II system
were SHA- and state-centric. As identified in the BAA workshops, the following locations were
identified as having varying degrees of functionality available to them when using the CHART II
system:

SOC/TOC/AOC – SHA Traffic Operations Center operations and traffic management
personnel will be responsible for monitoring traffic and roadway conditions and evaluating
actions that need to be taken. Personnel will be communicating with Maryland State Police,
ERU and ETP operators, and the various maintenance shops. These locations will have the
most capabilities and control when compared to the other CHART II locations, since they
will be handling most of the coordination efforts to manage the traffic flow of the roadways.
CHART II Business Area Architecture Report
23
January 8, 2006
CHART II Business Area Architecture Report

Districts – District Offices personnel will be primarily monitoring select information, and
also perform some highway maintenance supervision. These locations will mostly be viewing
the information and will not be active participants in the system.

SHA Highway Maintenance – Highway maintenance shop personnel will be responsible for
structural repairs, road signs and posts, potholes, guard rails, etc., which may be contributing
to degrading traffic conditions. In many cases the maintenance shops will need to assist by
providing the following equipment or materials: Arrow boards, dump trucks, light plants,
loaders, sand, sweepers, etc. Main responsibilities in the CHART II system will be to respond
to Action and Incident events as dispatched by a TOC.

Device Maintenance: Signal Crew – Signal control and repair personnel will be mainly
responsible for responding to signal failure alerts/Action Events in the CHART II system.
To date Signal systems have not been integrated into CHART Software.

Device Maintenance: – maintenance personnel will be mainly responsible for responding to
DMS, Shazam, HAR, Radar, CCTV Action Events in the CHART II system. Currently
notification is a manual operations.

Maryland State Police – This will included all MSP locations participating in CHART. The
MSP will be assisting with traffic management and incident response.

Media – Outside information re-processors (i.e., television, radio, traffic reporters). These
locations will receive filtered incident and traffic flow information, and CCTV video feeds
from the CHART II system.
1.5.4 Application
A conceptual description of the seven future CHART II application areas required to satisfy the
CHART II business needs is shown in the table below. Each of these application areas have been
addressed at least in a basic manner during development efforts since the BAA.
Application Area
Traffic and Roadway Monitoring
Incident Management
Shared Resource Management
Status Display Management
System Configuration and
Administration
Operations Support
Report Generation
Description
Monitor traffic and roadway conditions and
evaluate roadway detector data.
Provides the operator with tools to assist in
incident management and documentation.
Handle allocation and control of shared devices
(DMS, HAR) and receive and log roadway
detector data.
Maintain the state of the display map.
Provides tools for managing and administering
the system
Provides user access control and support utilities.
Provide tools for generating reports from system
log files.
Figure 1-13. CHART II Application Areas (August 2000)
CHART II Business Area Architecture Report
24
January 8, 2006
CHART II Business Area Architecture Report
The CHART II system gives and receives information to and from other sources linked to the
system. The diagram below illustrates how the CHART II system will interface with legacy
systems, as well as with other external interfaces and COTS software. These applications assist
the users of the CHART II system to monitor the roadways, notify individuals and groups that
may need to assist with situations or be aware of what’s happening, and receive additional
information to assist with current or future situations.
FAX,page,email
Recipient
FMS
AVCM
message
device commands
device status
camera commands
video
SCAN / Web
weather sensor
data
CHART II
weather
alerts
incident
reports
External
Incident Report
Source
road closure status
EORS
Figure 1-14. CHART Application Architecture Interfaces (August 2000)
Since the orgianl BAA CHART software has been developed as a installable GUI. The direction
of CHART II user interface has shifted to a CHART-Lite (web based) version of the application:
Starting with Release 2 Build 1 (early 2006 – CHART GUI will no longer be available to users).

The University of Maryland currently has responsibility for the development of simulation
tools for the CHART II system (all simulation tools are currently stand alone and not an
integrated part of the CHART System).
1.5.5 Data
One of the most common pitfalls in designing systems is that the data is either not captured and
stored, redundant, not traceable, and/or not distributed. As a result, the design of the Oracle
database for the CHART II system has been developed with all these pitfalls in mind. The data of
the CHART II system is viewed as a valuable asset for not only informational reasons, but also
CHART II Business Area Architecture Report
25
January 8, 2006
CHART II Business Area Architecture Report
for managerial, process improvement, and legal reasons. All of the operations being carried out
by either the system or operators will be captured and stored in a centralized database which can
be accessed from any of the CHART II workstations. Wherever possible, the database will be
highly normalized to ensure that not only will the data not span across multiple tables, but will
also be captured only once. As the system matures, the data captured from the system can be
used to analyze system performance, incident response, operator efficiency, and assist with
training and simulation activities.
To assist with this, there are two types of database repositories:
 Operational database – Real time capture of information. As activities take place in the
system, the data will be captured in real-time fashion, not in batch mode. This will allow the
data being captured and displayed by the system to be the most current and useful to all the
users of the system. This is all the data of the system which is up to 14 days old, and any
open logs even if they are open for more than 14 days. The data from this database can also
be used for Operational, Administrative, and Management/Statistical reports, as well as realtime simulation activities.
 Archive database – Repository of information of more than 14 days old. The primary uses of
information in the archive database are :
 Making information available for other Maryland state agencies,
 Enablement of CHART II simulation,
 Storage of information for legal purposes, and
 Providing data for generating various reports – In additional to the Operational report types
generated from the operational database, other type of reports to be made available by the archive
database would be Operations (i.e., weather detectors/road conditions, down time of
devices/components), Management (i.e., workload reports, resource utilization, cost of incident
clearance), and Performance Management reports.
1.5.6 Technology
CHART II is to be a statewide system operating 24 hours per day, 7 day per week schedule. The
system must be highly available through redundancy and geographic distribution, and the state of
the system (device status, current messages, etc.) shall be maintained and shall persist through a
system shutdown and startup cycle.
To satisfy these high level technological requirements, the system requires a mix of
communications, hardware infrastructure, and operating system components that support these
requirements. The components selected for CHART II to meet these requirements are itemized in
the following table:
Category
Hardware
Components

Standard workstation hardware is Hewlett Packard XW6000
2.80Mz (or better) processor, 1 GB memory, 30 GB storage.

Standard server hardware is Compaq Proliant ML570 900Mz (or
CHART II Business Area Architecture Report
26
January 8, 2006
CHART II Business Area Architecture Report
Category
Software
Components
better) quad processor, 4 GB memory, 109 GB RAID 5.

CHART-Lite hardware is Compaq DL380 1.2 Gz (or better)
single processor, 2 GB memory, 140 GB storage.

Operating system software is Windows XP for Workstations and
Windows 2000 Server for Servers

Standard workstation software suite includes:
- Microsoft Office
- Web browser (Internet Explorer)

Standard server software suite includes:
- Oracle 10G
Communications

Communications between servers and from servers to the field
devices must be available 24 hours/day.

Failure of communications to a server or failure of a server will
not affect the ability of other servers from communicating with
field devices.
Figure 1-15. CHART Components
CHART II Business Area Architecture Report
27
January 8, 2006
CHART II Business Area Architecture Report
The diagram below shows the conceptual architecture of the system illustrating the use of the
CORBA ORB for process communication.
Information Exchange Network
Partners-In-Motion
VDOT Traffic Management System
SCAN for Windows
EIS EORS
SSI Weather Source
Detectors
DMS
HAR
Shazam
External Systems Server
Legacy Systems Server
Security Server
Zone Management Server
SNMP
Agent
TCP/IP
Communication
SNMP
Manager
FMS Server
Legacy
Database
DLL
CHART FMS Server
CORBA ORB
Web Server
Web Export Server
GUI Client
CHART II Database Server (TMDD schema)
CORBA ORB
AVCM Server
Fax Server
Pager Server
Page Recipients
Fax Recipients
Cameras
Figure 1-16. CHART Conceptual Architecture (August 2000)
NOTE: Figure 1-16 Zone Management Server, Security Server and Fax Server have not been
implemented.
CHART II Business Area Architecture Report
28
January 8, 2006
CHART II Business Area Architecture Report
Below is a network concept diagram showing the system network connectivity.
DMS
ROA DWORK
EX I T 1 0 - 1 2
1 0 P M- 3 A M
Windows 2000 Svr SP4
CHART II Client
AVCM Client
Windows XP Prof.
CHART II Client
AVCM Client
Cisco 2516
SHAZAM
TOC
s
Modem
CHART Workstation
Travelers
InformationTune Radio to
1650 AM
Windows XP Prof.
CHART II Client
AVCM Client
CHART Workstation
Multiplexer
CHART Workstation
Switches
Cisco 7206
Greenbelt
ATM
Switch
BA
Frame Relay
HAR
Switches
Brooklandvill
ATM
e
Switch
n x T-1
CSU/DSU
Cisco 2524
CHART Backbone
BA
Frame Relay
CHART Backbone
Cisco 2524
HAR
Remote
FMS
SERVER
Travelers
InformationTune Radio
to 1650 AM
Cisco 7206
Remote
FMS
SHAZAM
Server
Windows 2000 Svr
SP4
ISDN/POTS interface (COTS)
Telephony Board
Comunications Service
ISDN/POTS
Windows 2000 Svr SP4
ISDN/POTS interface (COTS)
Telephony Board
Comunications Service
MDOT WAN
Hanover
ATM
Switch
CSU/DSU
CHART
Backbone
Multiplexer
ISDN/
POTS
Detector
CHART
Serve II
r
NT Server 4.0 SP5
Cisco 2516
AOC
Oracle 8i RDBMS
CHART II Server AppsMDTA
Modem
Modem
DMS
R O A D WO R K
EX I T 1 0 - 1 2
1 0 P M- 3 A M
Trader Service
Event Service
User Manager Service
Traffic Event Service
DMS Service
Message Utility Service
TSS Service
EORS Permit Service
HARS Service
TTSService
Modem
Cisco 7206
Windows 2000 Svr SP4
Oracle 10g RDBMS
CHART II Server Apps
Trader Service
Event Service
User Manager Service
Traffic Event Service
DMS Service
Message Utility Service CHAR
TSS Service
T
II
Serve
EORS Permit Service
HARS Service
r
TTSService
CHART
Workstation
Windows XP Prof.
CHART II Client
AVCM Client
EORS DB
Server
Switches
Detector
Windows XP Prof.
CHART II Client
AVCM Client
CHART Workstation
Switches
CHART II Web
Server
0
Figure 1-17. Network Diagram
CHART II Business Area Architecture Report
29
January 8, 2006
CHART II Business Area Architecture Report
1.6 Performance Objectives of the CHART II System
1.6.1 Process Thread Model
The Catalyst Business Process Performance Model identifies the critical business process threads
and defines the performance objectives for them. These performance objectives become useful
input in designing applications and defining the technical architecture for a system, as well as
identifying those business processes that need to be highly reengineered.
The CHART business of Traffic Management is a young business and lacks historical data and
best practices related to process performance models. There are many factors to be considered in
determining a performance model for traffic management. For example, the performance of a
process thread of incident detection through restoration of normal traffic flow is affected by 1)
the severity of the incident, 2) the numbers of vehicles involved, 3) the traffic volume at the time
(the size of the backup), and 4) the availability of alternate routes, etc. To specify a performance
objective on this high a level of thread would be unrealistic. For CHART II, it makes more sense
to define and assign performance objectives for lower level threads and attempt to minimize the
variables affecting the measurement of those threads.
It has been determined through BAA workshops that CHART operators perform 7 basic
activities in their day-to-day roles to manage traffic on Maryland’s state highways. The event
types being recorded in the CHART II system identify these 7 activities and, therefore, identify
the major process threads and subsequent lower level threads for determining performance
measurements. The following table identifies the major- and lower-level process threads
identified in CHART II, and assigns performance objectives for each. Future time objectives are
noted for controllable threads, and the level of required quality is indicated where this is a factor
in accomplishing the thread. Examples of variables that might affect the accomplishment of the
objectives are identified in the table
Event
Result
Time
Quality
Comm Log
2 minutes
High level of
accuracy
Alert sent to
responsible Center
Action Log – initiated by
system detection of device
failure
15
seconds
Accuracy of
identification
of failure
Action Log
initiation
Alert sent to
responsible center
Action Log – operator
initiated
1-5
minutes
Alert received at
responsible center
Alert
acknowledged at
responsible center
Action Log – alert
acknowledgement
Accuracy of
identification
of failure
N/A
Alert received at
the responsible
center
Alert escalated
and sent to next
responsible center
Action Log – alert escalation
COMMUNICATION LOG
Communications
Communications
Log Initiation
Log Closure
ACTION LOG
Detection of
failure from data
received from
FMS
Process Thread
CHART II Business Area Architecture Report
Variable:
30
seconds to
3 days
30
Parameter
controlled
Accuracy of
escalation
protocol
Variables
Length of phone call, ease
of data entry
FMS determination of type
of failure may affect
quality
Accuracy of information
received by operator, ease
of data entry
Duty hours and staff
availability at the
responsible center,
assumes non-escalated
alert
Value of system parameter
for escalation wait period,
priority of alert
January 8, 2006
CHART II Business Area Architecture Report
Event
Action alert
acknowledged
Result
Action completed
DISABLED VEHICLE EVENT
Disabled Vehicle
Dispatch of
Log initiation,
CHART vehicle
receipt of call from
traveler or other
agency
Disabled Vehicle
Disabled Vehicle
Log initiation,
Log created
radio call from
CHART vehicle
INCIDENT EVENT (Operator Initiated)
Incident Log
Incident Verified
Initiation
or Cancelled
Process Thread
Time
Quality
Action Log – action
completed, log closed
Variable
Accuracy of
information
received
Type of action required,
maintenance staff
availability, priority of
action
Disabled Vehicle Log –
initiated via phone call
5 minutes
Accuracy of
location of
disabled
vehicle
Ease of data entry,
availability and location of
CHART vehicles/drivers
Disabled Vehicle Log –
initiated via vehicle on scene
3 minutes
Accuracy of
location and
vehicle
description
Ease of data entry
0–2
minutes
Availability of camera in
near location, source of
information
Process initial response
5-10
minutes
Initial response
complete
Completion of
Initial Dispatch
and DMS/HAR
Response
Incident cleared
from roadway
Accuracy of
location and
incident
description
High level of
accuracy
Incident cleared
Variable
N/A
Incident cleared
Delay cleared
Normal flow restored
Variable
N/A
Process Initial Response
3-5
minutes
Accuracy of
location
Response to alert
30
seconds to
5 minutes
Accuracy of
information
communicated
Response to additional
congestion
3-5
minutes
Normal flow restored
Variable
High level of
accuracy of
input
Accuracy of
detector
information
Incident Verified
CONGESTION EVENT
Congestion
Congestion Log
Detected
Initiated, Alert
Sent
Alert received at
Alert
responsible center
acknowledged
Additional
congestion
reported
Congestion clear
Congestion log
modified
Delay cleared
Operator initiated Incident
Log – Incident Verification
RECURRING CONGESTION LOG – Implemented as subset of Congestion Event
Recurring
Recurring
Initial Response to
3-5
Congestion
Congestion Plan
Congestion
minutes
Activated
Recurring
Delay Cleared
Normal Traffic Flow
Variable
Congestion Clear
SPECIAL EVENT
Special Event
Scheduled to
Begin
Special Event
Expires
Accuracy of
detector
information
Accuracy of information
from detectors, response
time of FMS
Accuracy of plan, # of
DMS/HAR involved,
response time of FMS
# of DMS/HAR involved,
response time of FMS
3-5
minutes
Accuracy of
information
Clear messages
from DMS/HAR
Terminate Special Event Plan
2 minutes
Message
arbitration
handled
correctly
Weather Advisory
Notification
3-5
minutes
Accuracy of
information
31
Length of roadway
congestion, time of day, #
of DMS/HAR involved
Accuracy of information
from detectors, duty hours
and staff availability of
staff of responsible center
Length of roadway
congestion, time of day, #
of DMS/HAR involved
Accuracy of information
from detectors, response
time of FMS
# of DMS/HAR involved
Special Event Notification
CHART II Business Area Architecture Report
#’s of Dispatches and
DMS/HAR involved, Plan
versus operator initiation,
ease of GUI use
Number of vehicles, type
of vehicles, HAZMAT,
load spill, severity of
injuries
Duration of roadway
clearance, traffic volume,
availability of alternate
routes
Accuracy of
plan
Special Event Log
Initiated
WEATHER EVENT
Weather Advisory
Weather Advisory
Received
Log Initiated
Variables
January 8, 2006
CHART II Business Area Architecture Report
Event
Result
Process Thread
Time
Weather Advisory
Changes
Weather Advisory
Log Updated
Update Weather Advisory
2-4
minutes
Accuracy of
information
Accuracy of information
Select messages
and DMS/HAR
devices
Display/broadcast
messages
Provide Traveler Information
3-5
minutes
# of DMS/HAR involved,
response time of FMS
Weather Advisory
Expires
Close Log and
clear messages
from DMS/HAR
Terminate Weather Advisory
Plan
2 minutes
Message
arbitration
handled
correctly
Message
arbitration
handled
correctly
Accuracy of
information
Accuracy of information, #
of DMS/HAR involved,
response time of FMS
# of DMS/HAR involved,
response time of FMS
WEATHER SENSOR LOG – To be part of Weather Event when Implemented
Weather Sensors
Weather Sensor
Activate Weather Sensor Plan 3-5
Detect Hazardous
Log Initiated
minutes
Conditions
Weather Sensor
Clear messages
Weather Sensor Signs
2 minutes
Detect Conditions
from DMS/HAR
Terminated
Return to Normal
State
SAFETY EVENT
Safety Message
Safety Messages
Post Safety Message
3-5
Log Initiation
Prepared
minutes
Restore Messages
to Queue
Safety Messages
Cleared
Clear Safety Message
2 minutes
Quality
Message
arbitration
handled
correctly
Accuracy of
information
input
Message
arbitration
handled
correctly
Variables
# of DMS/HAR involved,
response time of FMS
Accuracy of information, #
of DMS/HAR involved,
response time of FMS
# of DMS/HAR involved,
response time of FMS
Figure 1-18. CHART Threads Performance Objectives
CHART will concentrate on process designs that 1) automate as much as possible, 2) application
designs that are intelligent and minimize user interaction, and 3) technology architectures that
provide the most throughputs for the money being invested.
Application performance goals will be defined in the Application Design phase based on best
practices for computer systems, thereby giving application designers and acceptors the necessary
baseline to evaluate the performance of the system from a technical perspective.
Guiding principles, constraints and assumptions support best efforts to design an efficient system
from a process and application design perspective, and will be the performance objectives for
this system.
1.6.2 CHART II Activities Performance Model
The BAA process identifies the various business activities performed by the CHART
organization and business processes designed to capture information about each of these
activities. It is desirable in business to measure and understand the volume of activities
conducted by a business area. This volumetric measurement of activities provides information by
which to determine workloads and resource requirements. Various views of these volumetric
measurements can be used to determine peak periods of workloads, variances over time, etc. The
following table identifies the types of volumetric measurements that would be useful in
managing the business area and are to be obtainable from the CHART II Archive data.
CHART II Business Area Architecture Report
32
January 8, 2006
CHART II Business Area Architecture Report
TYPE OF VOLUMETRIC
MEASUREMENT
Count of activity logs
Count of activity logs by operation center
Count by activity type over time
Count of activity type by roadway
Count of activity type by roadway over
time
Count of activity type by link
Count of activity type by link over time
PURPOSE OF MEASUREMENT
Rough measurement of workload
Measurement of workload by operation
center
Measurement of increase/decrease in
particular activities
Trends by roadway
Time-phased trends by roadway
Trends by link
Time-phased trends by link
1.6.3 Public Perception
It is important in business to obtain feedback from customers relative to the products and
services being offered. This feedback provides information to the business for purposes of
improving those products and services, and provides a basis for reorienting the business for the
future to meet expected customer demands.
CHART is a service-oriented business, providing on-the-road assistance for accidents, disabled
vehicles, traveler information on signs and radios. It also provides public access to camera feeds
through the CHART web site, provides current incident information through its Incident
Exchange Database, and provides statistic traffic flow and CHART operations information
through its Archive database. In order to increase CHART’s effectiveness as a business, it should
be determined how the public and users perceive the usefulness of these services, if they are
aware of the availability of these services, and their reactions to the quality of these services.
These measurements are typically gathered through surveys. Three categories of individuals (or
locations) to be surveyed have been identified which may provide useful feedback to CHART
management.
Disabled Motorists — When providing roadside assistance, CHART vehicle drivers give out
card surveys for travelers to rate the service. These surveys usually have a very positive feedback
because these individuals were the direct recipients of needed assistance. Though the responses
are predictable, these surveys should continue to identify any exceptions.
Web Site Surveys — Surveys could be made available on the CHART web site, which would be
a different sampling of the public though slanted to individuals aware of some of the CHART
services. Responses as to quality, timeliness, adequacy, and speed of information could be
informative in determining where to dedicate resources for Web Page designs or more robust
services.
Motor Vehicle Administration — Requesting customers at Motor Vehicle Administration to fill
out a survey should provide a larger cross section sampling of the public, at least representing
CHART II Business Area Architecture Report
33
January 8, 2006
CHART II Business Area Architecture Report
possible individuals with no knowledge of CHART. These surveys should attempt to measure
public awareness of CHART and CHART services, and obtain geographic feedback as to areas
more or less aware of CHART services and, therefore, more or less inclined to utilize those
services. Obtaining public input as to frequency or future intention of use of types of services
may be used to plan future upgrades in services and systems for specific geographical areas.
1.7 CHART II Release Strategy
Consistent with the Catalyst methodology, it is proposed to build and deploy the CHART II
system in a series of releases and builds. As opposed to the “big-bang” approach, the multiple
release strategy is done to divide the system into manageable sized pieces that will:
1. provide functionality to SHA in a sequence consistent with their operational needs
2. lessen the impact on the client organization to absorb training and utilize the new
applications
3. provide reasonably sized sets of code for development, testing, and documentation
4. allow for iterative repairs and design improvements over multiple releases
A release strategy was developed early in the BAA process to sequence the process design
efforts and allow an early start on the development of the first release. This strategy consisted of
four releases and was defined per the following table. The following Table has been updated
from the original version to reflect work done.
RELEASE
Release 1 (completed – 4
builds)
SUBJECT AREA
Administration
FUNCTIONALITY
Login
Application Access Control
Navigator
Status of Devices
Message Library
Device Control
Operator Communications
Log
Manual incident data entry
Operator selection of incident
response actions
Incident Management (Basic)
DMS
HAR
SHAZAM
Logging System Failures and
Actions
CHART II Business Area Architecture Report
34
January 8, 2006
CHART II Business Area Architecture Report
RELEASE
Release 2 (Not fully
impletmented)
SUBJECT AREA
GUI (Map) Map has been
developed independently – not
fully integrated
FUNCTIONALITY
Device Control
Device Status
Incident
Detection (indicate
congestion)
Incident Management
(Advanced – Lane Level)
Reports (COTS package with
custom reports to be
completed early 2006)
FAX
Paging
Legacy Systems Interface
Weather
EORS
IEN (No longer a business
objective – more generic
NTCIP Center to Center is
anticipated to fill requirement)
PIM (No longer a business
objective – more generic
NTCIP Center to Center is
anticipated to fill requirement)
AVCM (Integrated into
CHART early 2006 R2B1)
WWW (Web site currently
developed and maintained
under separate work orders –
CORBA feed for CHART data
completed)
Release 3 (Not implemented
Incident Response
Archive (University of
Maryland CATT Lab is
currently performing most of
the planned archive functions
via a CORBA feed provided
from CHART )
CHART II Business Area Architecture Report
35
Rules Based (automated)
FITM Plans
Signal Controls
(moved to Release 4)
January 8, 2006
CHART II Business Area Architecture Report
RELEASE
Release 4
SUBJECT AREA
AVL (Currently deploying
stand alone product, early
2006)
Maintenance
Legacy Systems Interface
(remaining)
Other Agencies Requirements
FUNCTIONALITY
Interfaces to Montgomery
County and VDOT
Archive Reports
Simulation (University of
Maryland CATT Lab is
currently performing most of
the planned simulation
functions via a data feed
provided from the CHART
Database)
Upon completion of the BAA process re-engineering activities, the release strategy was reviewed
in light of the defined processes and each process was assigned to one or more releases to further
define the release strategy. The following table shows the relationship between BAA defined
processes and work to date The following figures 1-19 through 1-22 have been updated to
reflect actual work completed. The original BAA Document anticipated four major releases with
multiple builds per release. In relation to this four release strategy CHART is up to Release 2.
Having completed Release 1 with four separate builds and several minor build updates having
been accomplished. This table also shows the progress of CHART Lite, CHART Map and
CHART Reporting Tool which has been completed under separate work orders than the CHART
II Development.
CHART II Business Area Architecture Report
36
January 8, 2006
CHART II Business Area Architecture Report
CHART Reporting Tool (4)
CHART Map (3)
CHART Lite (2)
CHART II (1)
1
2
3
4
SECURITY AND OPERATIONAL CONTROL
System Administration
a
Maintain Users
X
X
b
Maintain Roles
X
X
c
Maintain Functional Rights
X
X
d
Maintain Functional Responsibilities
X
X
e
Maintain Geographic Responsibility
f
Maintain Operations Center and AOR
Operational Control
a
Maintain Center Notepad
b
User Logon
X
c
View Center Situation
X
d
Maintain User Preferences
X
e
Maintain Operator's Notepad
f
Perform CHART Chat
X
X
g
Logout
X
X
h
Change User
X
X
i
Transfer Resources
X
j
Respond to Request to Transfer Resources
X
X
X
X
X
X
X
X
X
Configuration Processes
a
Maintain System Parameters
b
Maintain Links
X
FITM Plans
a
Maintain FITM Plans
X
Map Configuration
a
Update MDOT GIS Map Data
X
SYSTEM CONFIGURATION AND STATUS
Components
a
Maintain Component Configuration
X
X
b
Log System Failures
X
X
a
Maintain Device Configuration
X
X
b
Set Device Online
X
X
c
Set Device Offline
X
X
d
Set Device to Maintenance Mode
X
X
e
Handle DMS and HAR Polling Results
X
X
f
Respond to Device Failure Alerts
Devices
INCIDENT/EVENT MANAGEMENT
Logs
a
Log Communications Log
X
X
b
Log Action Event
X
X
c
Log Disabled Vehicle Event
X
X
d
Log Incident Event
X
X
CHART II Business Area Architecture Report
37
January 8, 2006
CHART II Business Area Architecture Report
Figure 1-19. Processes by Release Matrix – Page 1/4
CHART Reporting Tool (4)
CHART Map (3)
CHART Lite (2)
CHART II (1)
1
e
2
3
4
View Historical vs. Current
f
Log Congestion Event
g
Log Recurring Congestion Log
X
X
h
i
Log Special Event
X
X
Log Weather Event
X
j
Log Weather Sensor Log
X
k
l
Log Safety Message Event
X
X
View Log
X
m
X
Close Log
X
X
Location Navigation
a
Maintain Location Navigation Data
X
b
Activate Location Navigator
X
Queues
a
Calculate Queue Length
Notification
a
Maintain Notification List
b
Perform Notificaiton
SHARED RESOURCE MANAGEMENT
DMS/HAR Common Processes
a
Maintain Acceptable Word Dictionary (Spell Check)
X
X
b
Maintain Unacceptable Word Dictionary
X
X
c
Perform Responsibility Reminder
X
X
d
Respond to Responsibility Reminder Alert
DMS Processes
a
Maintain DMS Message Library
X
X
b
DMS – Add a Message
X
X
c
DMS – Remove a Message
X
X
d
DMS – Arbitrate Message Queue
X
X
e
DMS – Evaluate Queue
X
X
f
DMS – Send a Message
X
X
g
DMS – Blank a Sign
X
X
h
DMS - Reset
X
X
i
DMS – Restore Message
X
X
j
DMS- Override Queue
X
X
HAR Processes
a
Maintain HAR Message Library
X
b
HAR – Add a Message
X
X
c
HAR – Remove a Message
X
X
d
HAR – Arbitrate Message Queue
X
X
e
HAR – Evaluate Queue
X
X
f
HAR – Broadcast a Message
X
X
g
HAR – Broadcast Default Message
X
X
h
HAR – Set Shazam On/Off
X
X
Figure 1-20. Processes by Release Matrix – Page 2/4
CHART II Business Area Architecture Report
38
January 8, 2006
CHART II Business Area Architecture Report
CHART Reporting Tool (4)
CHART Map (3)
CHART Lite (2)
CHART II (1)
1
2
i
HAR – Update Default Message
X
X
j
HAR – Send Maintenance Command
X
X
k
HAR – Restore Message
X
X
l
HAR - Override Queue
X
X
3
4
AVCM
a
Maintain Wall Monitor Configuration
b
Control Wall Monitor Assignment
c
Maintain CCTV Presets
d
Refresh Default AVCM Presets
e
Maintain Tours
X
f
Activate Tour
X
g
Control Camera
X
X
Detectors
a
Handle Polled Detector Data
b
Handle Detector Rules
c
Generate Congestion Response
d
Respond to Congestion Alert
e
Generate Incident Response
f
Respond to Incident Alert
g
Activate Response Plan
X
X
Equipment
a
Maintain Equipment Inventory
b
Maintain Equipment Status
c
Alert For Delinquent Equipment Status
d
Respond to Delinquent Equipment Status Alert
Signals
a
Handle Signal Polling Data
b
Respond to Exceeded Signal Threshold Alert
c
Download Signal Data
a
Handle AVL Polling Results
b
Perform AVL Function Processing
AVL
c
Process AVL In/Out of Service Message
d
Process AVL Mayday Message
e
Process AVL Arrival On-Scene Message
f
Process AVL Assist Disabled Vehicle Message
g
Process AVL Assist Disabled CHART Vehicle Message
h
i
Process AVL Available Message
Respond to AVL Alerts
j
Respond to Mayday Alert from AVL
k
Respond to Arrival On-Scene Alert from AVL
l
Respond to Disabled Vehicle Alert from AVL
ALERTS
Figure 1-21. Processes by Release Matrix – Page 3/4
CHART II Business Area Architecture Report
39
January 8, 2006
CHART II Business Area Architecture Report
CHART Reporting Tool 4)
CHART Map (3)
CHART Lite (2)
CHART II (1)
1
2
a
Send Manual Alert
b
Send Alert
c
Escalate Alert
a
Maintain Plans
X
X
b
Activate Plan
X
X
c
Deactivate Plan
X
X
X
X
3
4
PLANS
SCHEDULED EVENTS
a
Maintain Scheduled Events
b
Process Scheduled Events Start
c
Process Scheduled Events End
EORS INTERFACE
Construction
a
Download EORS Permits
b
Activate EORS Icon On Map
X
c
Activate EOR Permit
X
Snow Emergency
a
Maintain Snow Emergency Declaration
Phone Book
a
Access Phone Book
WEATHER SUPPORT
National Weather Service
a
View National Weather Service Data
b
Process Weather Alerts From The NWS
c
Respond to National Weather Service Alert
d
Fax Weather Report
SCAN
a
Handle Weather Sensor Data
b
Generate Weather Sensor Response
c
Respond to Weather Sensor Alert
ARCHIVING AND REPORTS
Archiving
a
Archive Update - Add
b
Archive Update - Update Log Data
c
Real Time System Update - Delete
Reports
a
Operational Reports
X
b
Reports from Archive
X
Other Agencies
a
Montgomery County
b
VDOT
c
PIM
d
TRANSCOM
e
911 Centers
Figure 1-22. Processes by Release Matrix – Page 4/4
CHART II Business Area Architecture Report
40
January 8, 2006
CHART II Business Area Architecture Report
2 Business Process Model View
This section presents various model views of the Business Processes derived from CHART II
visioning and process design workshops. The Direction Model provides the principles,
constraints and assumptions that guide the design of business processes, while the Conceptual
Model provides the specifics of business processes defined and derived as a result of the
workshops.
This section has not been updated so as to convey the original thoughts recorded from the
methodology employed to create the BAA which is an important viewpoint to maintain for
the CHART Project. Minor notations to bring major themes up to date will be listed as
Notes: below the applicable section. Figures 1-19 through 1-22 can be referenced to
determine what processes have actually been implemented.
2.1 Business Process Direction Model
This model shows what business process principles, constraints, and assumptions impact the
project.
2.1.1 Business Process Principles, Constraints, and Assumptions
Numerous principles, constraints, and assumptions (PCAs) were derived for this particular model
view. The following table shows how the BAA process scored in applying the identified PCAs.
The scoring is defined as follows:

Applied = The PCAs were observed and applied to one or more of the Domains of
Change

To Be Applied = The PCAs were not viewed as relevant to this phase of the project, but
may be applied in later phases (i.e., Design, Development, and Deployment)

Not Applicable = The PCAs identified were replaced by different approaches used in
process design
Principles

Attempt to improve processes through automation whenever possible

Minimize operator options
Constraints
None
Assumptions
None
CHART II Business Area Architecture Report
41
January 8, 2006
CHART II Business Area Architecture Report
2.2 Conceptual Business Process Model
The Conceptual Business Process Model provides process decomposition of the business
processes within the scope of the business area under investigation. It also presents process
dynamics, that is, how lower-level business processes interrelate, or flow, to implement a higherlevel process.
2.2.1 Implementation Constraints and Assumptions
Usually a conceptual Business Process Model reflects business activities and tries to avoid any
extensive discussion of the implementation of any automated processes. Due to the background
of the CHART II project, an implementation approach has already been selected based on the
prototype applications submitted during the contract award phase. Having an implementation
approach already specified forces certain constraints in the design of business processes. To
minimize these constraints, the business processes recognize and make reference to only two
high level aspects of the implementation approach – the Navigator and the Map. The following
identifies the assumptions about the implementation approach as affected by the business
processes.
 Navigator – the Navigator is a directory-type text display to the operator. This
display identifies selectable components that the operator may select as required to
utilize a component, device, event, etc.; or to obtain current status information about
the item selected.
 Map – the Map is a geographical display of roadways, devices, incidents, etc. to the
operator. This display is comprised of map layers, each layer related to a different
type of device or event. Layers display icons or area shadings to represent locations
of the topic of the layer (DMS devices, snow emergency areas, incident locations,
EORS permit locations, etc.). Operators select which layers are displayed over the
Map based on the job they are performing.
Some CHART II business processes identify relationships with the Navigator and/or the Map
(usually to provide data to them) to indicate that the displays are to be updated and refreshed for
user viewing, or that status information is updated and available if the user should select that
item. In and of themselves, the Navigator and the Map are not business processes and as such no
process flows will be found in this section for them.
NOTE: CHART II Navigator (Client GUI has been abandoned in favor of a web based interface
called CHART Lite).
2.2.2 Business Process Hierarchy
The Business Process Hierarchy is a schematic representation of the results of process
decomposition. In the Construction and Deployment Phase, the decomposition will be taken to
the elementary business process (EBP) level.
The Business Process Hierarchy shown below indicates the division of processes by major
process groups, and the processes identified in the process design workshops (or derived as the
result of analysis). These process groups and processes are organized in a process orientation.
CHART II Business Area Architecture Report
42
January 8, 2006
CHART II Business Area Architecture Report
This orientation disregards the roles that perform the processes in order to represent the business
process flow of traffic management as performed by CHART.
CHART II Business Area Architecture Report
43
January 8, 2006
CHART II Business Area Architecture Report
CHART II
SECURITY AND
OPERATIONAL CONTROL
SYSTEM CONFIGURATION
AND STATUS
System
Administration
Components
MAINT USERS
MAINT COMPONENT
CONFIGURATION
MAINT ROLES
LOG SYSTEM
FAILURES
MAINT FUNCTIONAL
RIGHTS
MAINT FUNCTIONAL
RESPONSIBILITIES
MAINT
GEOGRAPHIC
RESPONSIBILITY
MAINT CENTER
AND AOR
Operational
Control
MAINT CENTER
NOTEPAD
USER LOGON
VIEW CENTER
SITUATION DATA
SHARED RESOURCE
MANAGEMENT
DMS/HAR
Common
Processes
MAINT ACCEPTABLE
W ORD DICTIONARY
MAINT
Devices
UNACCEPTABLE
W ORD DICTIONARY
PERFORM
RESPONSIBILITY
REMINDER
RESPOND TO
RESPONSIBILITY
REMINDER ALERT
MAINT DEVICE
CONFIGURATION
SET DEVICE
ONLINE
SET DEVICE
OFFLINE
SET DEVICE TO
MAINT MODE
DMS Processes
HANDLE DMS AND
HAR POLLING
RESULTS
RESPOND TO
DEVICE FAILURE
ALERTS
MAINT DMS
MESSAGE LIBRARY
MAINT USER
PREFERENCES
DMS - RESET
TRANSFER
RESOURCES
RESPOND TO
REQUEST TO
TRANSFER
RESOURCES
HAR - REMOVE A
MESSAGE
HAR - ARBITRATE
MESSAGE QUEUE
HAR - EVALUATE
QUEUE
HAR -
DMS - RESTORE
MESSAGE
DMS - OVERRIDE
QUEUE
MAINT CCTV
PRESETS
REFRESH DEFAULT
AVCM PRESETS
BROADCAST A
MESSAGE
HAR-BROADCAST
DEFAULT MSG.
CONTROL CAMERA
HAR-SEND
MAINT. COMMAND
HAR - RESTORE
MESSAGE
HAR - OVERRIDE
QUEUE
Equipment
MAINT EQUIPMENT
INVENTORY
MAINT EQUIPMENT
STATUS
ALERT FOR
DELINQUENT
EQUIPMENT
STATUS
RESPOND TO
DELINQUENT EQUIP
STATUS ALERT
MAINT TOURS
ACTIVATE TOUR
HAR-UPDATE
DEFAULT MSG.
DMS - BLANK A
SIGN
CHANGE USER
HAR - ADD A
MESSAGE
CONFIGURATION
CONTROL W ALL
MONITOR
ASSIGNMENT
DMS - REMOVE A
MESSAGE
DMS - SEND A
MESSAGE
LOGOUT
MAINT W ALL
MONITOR
HAR - SET
SHAZAM ON/OFF
DMS - EVALUATE
QUEUE
PERFORM CHART
CHAT
AVCM
MAINT HAR
MESSAGE LIBRARY
DMS - ADD A
MESSAGE
DMS - ARBITRATE
MESSAGE QUEUE
MAINT OPERATOR'S
NOTEPAD
HAR Processes
Detectors
HANDLE POLLED
DETECTOR DATA
HANDLE DETECTOR
RULES
GENERATE
CONGESTION
RESPONSE
RESPOND TO
CONGESTION
ALERT
GENERATE
INCIDENT
RESPONSE
RESPOND TO
INCIDENT ALERT
ACTIVATE
RESPONSE PLAN
Configuration
Processes
MAINT SYSTEM
PARAMETERS
MAINT LINKS
Signals
HANDLE SIGNAL
POLLING DATA
RESPOND TO
EXCEEDED SIGNAL
THRESHOLD ALERT
DOWNLOAD SIGNAL
DATA
AVL
HANDLE AVL
POLLING RESULTS
PERFORM AVL
FUNCTION
PROCESSING
PROCESS AVL IN/
OUT SERVICE MSG
PROCESS AVL
MAYDAY MSG
PROCESS AVL
ARRIVAL ON-SCENE
MSG
PROCESS AVL
ASSIST DISABLED
VEHICLE MSG
PROCESS AVL
DISABLED CHART
VEHICLE MSG
PROCESS AVL
AVAILABLE MSG
FITM Plans
MAINTAIN FITM
PLANS
RESPOND TO AVL
ALERTS
Map
Configuration
RESPOND TO AVL
MAYDAY ALERT
UPDATE MDOT
GIS MAP DATA
RESPOND TO AVL
ARRIVAL ONSCENE ALERT
RESPOND TO AVL
DISABLED VEHICLE
ALERT
Figure 2-1. CHART II Business Process Hierarchy – Part 1 of 2 (August 2000)
CHART II Business Area Architecture Report
44
January 8, 2006
CHART II Business Area Architecture Report
CHART II
INCIDENT / E VENT
MANAGEMENT
ALERTS
Logs
Send Manual Alert
LOG
PLANS
SCHEDULED E VENTS
EORS I NTERFACE
Maintain Plans
Maint Scheduled
Events
Construction
COMMUNICATIONS
LOG
Send Alert
Activate Plan
LOG A CTION L OG
Escalate Alert
Deactivate Plan
LOG D ISABLED
VEHICLE L OG
LOG INCIDENT L OG
Process
Scheduled Events
Start
Process
Scheduled Events
End
DOWNLOAD EORS
PERMITS
ACTIVATE EORS
ICONS ON M AP
ACTIVATE EOR
PERMIT
Snow Emergency
VIEW H ISTORICAL
VS . C URRENT
MAINT S NOW
EMERGENCY
DECLARATION
LOG C ONGESTION
LOG
Phone Book
LOG R ECURRING
CONGESTION L OG
ACCESS P HONE
BOOK
LOG S PECIAL
EVENT L OG
LOG W EATHER
ADVISORY L OG
LOG W EATHER
SENSOR L OG
WEATHER S UPPORT
National W eather
Service
VIEW N ATIONAL
W EATHER S ERVICE
DATA
PROCESS
W EATHER A LERTS
FROM THE NWS
RESPOND TO NWS
ALERT
FAX W EATHER
REPORT
SCAN
HANDLE W EATHER
SENSOR D ATA
GENERATE
W EATHER S ENSOR
RESPONSE
RESPOND TO
W EATHER S ENSOR
ALERT
LOG S AFETY
MESSAGE L OG
VIEW L OG
CLOSE L OG
Location
Navigation
MAINT L OCATION
NAVIGATION D ATA
ACTIVATE
LOCATION
NAVIGATOR
Queues
CALCULATE QUEUE
LENGTH
Notification
MAINT
NOTIFICATION L IST
PERFORM
NOTIFICATION
Figure 2-2. CHART II Business Process Hierarchy - Part 2 of 2 (August 2000)
CHART II Business Area Architecture Report
45
January 8, 2006
ARCHIVING
AND R EPORTS
Archiving
Archive Update Add
Archive Update Update Log Data
Real Time
System Update Delete
Reports
Operational
Reports
Reports from
Archive
CHART II Business Area Architecture Report
2.2.3 Business Processes by Type
CHART processes have been grouped into four types of processes: System Administration,
Center Administration, Operational, and Custodial.
Administrative processes are those processes that configure and control the system functionality.
Administrative processes are divided into System Administration and Center Administration to
identify the respective level of configuration and control, and the roles that are responsible for
executing these processes.
Operational processes are those processes that require operator interaction to initiate or perform
the process.
Custodial processes are repetitive, scheduled system processes that do not require operator
control or presence for these processes to be executed.
The following matrix identifies each process and the process type assigned to each process.
CHART II Business Area Architecture Report
46
January 8, 2006
CHART II Business Area Architecture Report
Custodial
Operational
Center Administration
System Administration
1
2
3
4
SECURITY AND OPERATIONAL CONTROL
System Administration
a
Maintain Users
X
b
Maintain Roles
X
c
Maintain Functional Rights
X
d
Maintain Functional Responsibilities
X
e
Maintain Geographic Responsibility
X
f
Maintain Operations Center and AOR
X
Operational Control
a
Maintain Center Notepad
b
User Logon
X
X
c
View Center Situation
X
d
Maintain User Preferences
X
e
Maintain Operator's Notepad
X
f
Perform CHART Chat
X
g
Logout
X
h
Change User
X
i
Transfer Resources
X
j
Respond to Request to Transfer Resources
X
Configuration Processes
a
Maintain System Parameters
X
b
Maintain Links
X
Maintain FITM Plans
X
FITM Plans
a
Map Configuration
a
Update MDOT GIS Map Data
X
SYSTEM CONFIGURATION AND STATUS
Components
a
Maintain Component Configuration
b
Log System Failures
X
X
Devices
a
Maintain Device Configuration
b
Set Device Online
X
X
c
Set Device Offline
X
d
Set Device to Maintenance Mode
X
e
Handle DMS and HAR Polling Results
f
Respond to Device Failure Alerts
X
X
INCIDENT/EVENT MANAGEMENT
Logs
a
Log Communications Log
X
b
Log Action Log
X
c
Log Disabled Vehicle Log
X
Figure 2-3. Process by Process Type Matrix, Part 1/4 (August 2000)
CHART II Business Area Architecture Report
47
January 8, 2006
CHART II Business Area Architecture Report
Custodial
Operational
Center Administration
System Administration
1
d
Log Incident Log
e
2
3
X
View Historical vs. Current
4
X
X
f
Log Congestion Event
X
X
g
Log Recurring Congestion Log
X
X
h
Log Special Event
X
X
i
Log Weather Event
X
X
j
Log Weather Sensor Log
X
X
k
Log Safety Message Event
X
X
l
View Log
X
m
Close Log
X
X
Location Navigation
a
Maintain Location Navigation Data
b
Activate Location Navigator
X
X
Calculate Queue Length
X
X
X
X
Queues
a
Notification
a
Maintain Notification List
b
Perform Notificaiton
X
SHARED RESOURCE MANAGEMENT
DMS/HAR Common Processes
a
Maintain Acceptable Word Dictionary
X
b
Maintain Unacceptable Word Dictionary
X
c
Perform Responsibility Reminder
d
Respond to Responsibility Reminder Alert
X
X
DMS Processes
a
Maintain DMS Message Library
b
DMS – Add a Message
X
X
X
c
DMS – Remove a Message
X
X
d
DMS – Arbitrate Message Queue
X
e
DMS – Evaluate Queue
X
f
DMS – Send a Message
X
g
DMS – Blank a Sign
h
DMS - Reset
i
DMS – Restore Message
j
DMS- Override Queue
X
X
X
X
X
HAR Processes
a
Maintain HAR Message Library
b
HAR – Add a Message
X
X
X
c
HAR – Remove a Message
X
X
d
HAR – Arbitrate Message Queue
X
e
HAR – Evaluate Queue
X
f
HAR – Broadcast a Message
X
Figure 2-4. Process by Process Type Matrix, Part 2/4 (August 2000)
CHART II Business Area Architecture Report
48
January 8, 2006
CHART II Business Area Architecture Report
Custodial
Operational
Center Administration
System Administration
1
2
3
g
HAR – Broadcast Default Message
h
HAR – Set Shazam On/Off
i
HAR – Update Default Message
X
j
HAR – Send Maintenance Command
X
k
HAR – Restore Message
l
HAR - Override Queue
4
X
X
X
X
AVCM
a
Maintain Wall Monitor Configuration
X
b
Control Wall Monitor Assignment
c
Maintain CCTV Presets
d
Refresh Default AVCM Presets
e
Maintain Tours
f
Activate Tour
X
g
Control Camera
X
X
X
X
X
X
Detectors
a
Handle Polled Detector Data
X
b
Handle Detector Rules
X
c
Generate Congestion Response
d
Respond to Congestion Alert
e
Generate Incident Response
f
Respond to Incident Alert
g
Activate Response Plan
X
X
X
X
X
Equipment
a
Maintain Equipment Inventory
b
Maintain Equipment Status
X
c
Alert For Delinquent Equipment Status
d
Respond to Delinquent Equipment Status Alert
X
X
x
Signals
a
Handle Signal Polling Data
b
Respond to Exceeded Signal Threshold Alert
x
c
Download Signal Data
x
a
Handle AVL Polling Results
x
b
Perform AVL Function Processing
x
x
AVL
c
Process AVL In/Out of Service Message
x
d
Process AVL Mayday Message
x
e
Process AVL Arrival On-Scene Message
x
f
Process AVL Assist Disabled Vehicle Message
x
g
Process AVL Assist Disabled CHART Vehicle Message
x
h
Process AVL Available Message
x
i
Respond to AVL Alerts
j
Respond to Mayday Alert from AVL
x
k
Respond to Arrival On-Scene Alert from AVL
x
Figure 2-5. Process by Process Type Matrix, Part 3/4 (August 2000)
CHART II Business Area Architecture Report
49
January 8, 2006
CHART II Business Area Architecture Report
Custodial
Operational
Center Administration
System Administration
1
l
Respond to Disabled Vehicle Alert from AVL
2
3
4
x
ALERTS
a
Send Manual Alert
b
Send Alert
X
X
c
Escalate Alert
X
a
Maintain Plans
b
Activate Plan
X
X
c
Deactivate Plan
X
X
PLANS
X
SCHEDULED EVENTS
a
Maintain Scheduled Events
b
Process Scheduled Events Start
X
X
c
Process Scheduled Events End
X
EORS INTERFACE
Construction
a
Download EORS Permits
b
Activate EORS Icon On Map
c
Activate EOR Permit
X
X
X
Snow Emergency
a
Maintain Snow Emergency Declaration
X
Phone Book
a
Access Phone Book
X
WEATHER SUPPORT
National Weather Service
a
View National Weather Service Data
b
Process Weather Alerts From The NWS
X
c
Respond to National Weather Service Alert
d
Fax Weather Report
x
a
Handle Weather Sensor Data
X
b
Generate Weather Sensor Response
c
Respond to Weather Sensor Alert
X
X
SCAN
X
X
ARCHIVING AND REPORTS
Archiving
a
Archive Update - Add
X
b
Archive Update - Update Log Data
X
c
Real Time System Update - Delete
X
Reports
a
Operational Reports
X
X
b
Reports from Archive
X
X
Figure 2-6. Process by Process Type Matrix, Part 4/4 (August 2000)
CHART II Business Area Architecture Report
50
January 8, 2006
CHART II Business Area Architecture Report
2.2.4 Business Process Flows / Data Flow Diagrams
This section of the report presents the data flow diagrams from the Business Team analysis tool.
The following data flow diagrams are organized as illustrated in Figure 2-1. CHART II Business
Process Hierarchy.
The CHART II processes presented in this section identify several processes and data stores that
might logically belong to other applications, either in part or in whole. Some configuration data
and system parameter data might belong to the FMS application or to the AVCM application.
For the purposes of these process flows, and to provide completeness of the process analysis, it
has been assumed that FMS and AVCM will share these data stores – or the interfaces between
these separately developed applications will be coordinated during the application design phase
of this project.
2.2.4.1 Security and Operational Control
The Security and Operational Control processes include all those processes necessary to define,
setup and control the security aspects and architectural parameters for the CHART II system.
These processes are divided into groups related to System Administration, Operational Control,
Configuration Processes, FITM plan maintenance, and Map Configuration. Figure 2-7. Security
and Operational Control identifies the individual processes within each group.
Security and Operational Control - 10/28/99
1
Sec urity and Operational Control
1.1
Sy s tem Adminis tration
1.2
Operational Control
1.3
Configuration Proc es s es
1.1.1
1.2.1
1.2.7
1.3.1
Maintain Us ers
Maintain Center
Notepad
Logout Us er
Maintain Sy s tem
Parameters
1.1.2
1.2.2
1.2.8
1.3.2
Maintain Roles
Logon Us er
Change Us er
Maintain Link s
1.1.3
1.2.3
1.2.9
Maintain Functional
Rights
View Center
Situation Data
Trans fer
Resourc es
1.4
Maintain FITM
Plans
1.1.4
1.2.4
Maintain Functional
Respons ibilitie s
1.2.10
Res pond to
Resourc e Trans fer
Alert
Maintain Us er
Preferenc es
1.5
Map Configuration
1.5.1
Update MDot GIS
Map Data
1.1.5
Maintain
Geographic
Respons ibilitie s
1.2.5
Maintain
Operators
Notepad
1.1.6
Maintain Operations
Center and AOR
1.2.6
Perform Chart
Chat
Figure 2-7. Security and Operational Control (August 2000)
CHART II Business Area Architecture Report
51
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.1
System Administration
The System Administration process group identifies the required processes to establish the users
and the centers (locations) of the system.
Users are defined to the system by both their identity and the functional capabilities that are
granted to them. Access to the functional capabilities of the system is controlled through the
definition of the system’s functional capabilities, the grouping of functional capabilities into
Roles, and then the assignment of Role(s) to users.
Centers are the physical or logical organizational entities supported by the system. Centers are
defined to the system by their identity and hierarchical relationship to other centers, their
functional responsibilities, and their geographical area of responsibility. Functional
Responsibilities define the system capabilities that centers may perform, and they define the
types of Alerts that are generated by the system (similar to the relationship between users and
Functional Rights). Geographical Area of Responsibility is the geographical area definitions that
are assigned to centers to define the area from which they are to receive Alerts. Establishment of
a center includes defining the center by its name and location, its relationship to other centers in
the hierarchy of responsibilities, the assignment of Functional Responsibilities (or groups of
Functional Responsibilities), and the assignment of any Geographical Area of Responsibility.
The conceptual objective of CHART is to allow the maximum amount of flexibility in
establishing relationships between users and centers, while still maintaining the specific mission
support capabilities of the individual centers. CHART is intended to support these three User-toCenter scenarios:

Users may be trained to support more than one type of center (for example; TOC and
Maintenance Shop) and should be expected to be able to work at either as required.

Users may be temporarily assigned to any one of several similar centers (for example,
from TOC3 to the SOC).

Users may need to logon from a different center to perform work for their assigned center
(for example, while at the SOC, the Maintenance Shop user may wish to logon and check
the current alerts for his/her shop).
To achieve the objective flexibility, the processes and architecture need to support the following
relationships between users, centers, and the CHART workstations:
 Users are defined as being granted specific Functional Rights and related to specific
centers for which they might be assigned. As in the first scenario above, a user may be
granted the necessary functional rights to perform the duties of an operator at both a
TOC and a Maintenance Shop, and then the user is related to TOC3 and the Hanover
Maintenance Shop.
 Centers are defined as being responsible for performing specific system functional
responsibilities as necessary to support their mission requirements. It is expected that a
TOC center would have a more extensive set of functional responsibilities than a
Maintenance Shop center. Should the user with functional rights granted to perform the
duties of an operator at both a TOC and a Maintenance Shop log onto the system and
identify himself/herself as relating the session with the Maintenance Shop, he/she will
CHART II Business Area Architecture Report
52
January 8, 2006
CHART II Business Area Architecture Report
only be allowed to perform those assigned functional rights that match with the
functional responsibilities specified for the Maintenance Shop center.
 Workstations were defined initially as being physically related to the location (center)
where they are installed, however current thinking now is that workstations will need to
be dynamically related to centers as designated for the user of the workstation. To
support the three scenarios described above, the system will need to determine which
centers have been related to the user. If more than one have been designated, the system
must have the user indicate to which center this session is to be related. If it’s assumed in
the third scenario above that this Maintenance Shop user is only related to one center
(his/her Maintenance Shop), the user should not have to indicate the center to be related
in this session. For the duration of the session, the workstation needs to function as a part
of the center indicated, interfacing with appropriate distributed databases, receiving
Alerts for the center as appropriate, and adhering to the conditions of the Logout
process.
Implementation Considerations: the hierarchical relationship between centers defines the
routing of responsibility for escalation of Alerts when lower level organizations in the hierarchy
do not respond to the Alerts. For purposes of this BAA, it is assumed that this hierarchical
relationship between centers is an attribute of the definition of a center, and no specific process
or data store is defined for this relationship. Since a multitude of implementation options is
possible, this needs to be reviewed during the Application Design phase. An initial schematic of
the center hierarchy is available in section 4.2.3, Locations to assist in this analysis.
CHART II Business Area Architecture Report
53
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.1.1 Maintain Users
The Maintain Users process maintains a table of values identifying recognized CHART II users,
and provides the capabilities to maintain the set of Roles and centers assigned to these users.
Maintain Users - 9/17/99
1
Need to Maintain Users
9
Determine New User
Name
Add User Selected
Update User Selected
5
Selected User Information
List Users
New User Name
D4
D3
Center
Role
User to Update
D1
Users
Role Info
4
While Maintaining a User
Allowed Centers
4.2
6
Maintain User Data
Modify User Selected
Select User
Updated User/Role
User Selected for Deletion
8
Updated User Information
7
Store User Data
Deleted User
Delete User from
Database
Log User Update
D2
Operations
Log
Log Data
10
Log System
Operation
*** User Data can be:
Role/Functional Rig hts Data
Allowed Centers Data
Figure 2-8. Maintain User (August 2000)
CHART II Business Area Architecture Report
54
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.1.2 Maintain Roles
The Maintain Roles process maintains the table of values designating the various security roles
defined for the system. This process also provides the capabilities for maintaining the relation to
the set of Functional Rights identifying the system capabilities associated with each Role.
In the process design workshops, types of roles needed in the system were defined as:

Full – Create/Edit Message content (DMS, HAR stored messages)

Partial – Send message from library

Area of Responsibility – Subset of Full/Partial

View Only

Admin – System administration privileges
Each role may have several levels of privileges. The discussion by the group led to the
determination of three administration levels. View and Partial roles will also be broken down
further as shown in the list of privileges associated with the various users of the system. It was
determined that the Media would not have the privilege of viewing full incident reports. Partial
will be broken down further by the type of device to be accessed, as shown in the Signal Ops
category.
Admin levels:

Parameters (colors, etc.)

User/device admin

Functional (backup/restore)
Examples of Organizational roles and the type of security role expected to be related:

Highway Operations Technician (HOT) – Full

Police – Partial

System Administrator – Admin

Signal Ops – Partial for selected devices only

Shop Maintenance – Partial

Device Maintenance – Partial

Media – Limited View only with filtered incident reports

Government – Partial

SHA Management – View only
CHART II Business Area Architecture Report
55
January 8, 2006
CHART II Business Area Architecture Report
Maintain Roles - 9/27/99
1
Determine New
Role Name
2
Add Role Selected
Need to Maintain Roles
Delete/Modify Role Selected
3
List Roles
List of Roles
Role List
New Role Name
4
While Deleting Roles
5
Selected Role Information
Select Role
4.1
Check if Role is
Used
Delete Selected
Role to Update
D1
6
While Maintaining a Role
Role
If Not Used by User
6.1
Maintain Assigned Functional Rights
Groups
7
Delete Role from Database
Updated Role/Functional Rights
8
Updated Role Information
Updated Info
Store Updated Role
Updated Role Info
9
Log System
Operation
D2
Log Data
Operations
Log
Figure 2-9. Maintain Roles (August 2000)
CHART II Business Area Architecture Report
56
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.1.3 Maintain Functional Rights
The Maintain Functional Rights process maintains the table of values that designates the
functional capabilities of the system that may be assigned to specific Roles and subsequently
assigned to users.
Implementation Considerations: These Functional Rights need to be defined during the
Application Design phase to ensure the appropriate level of functional capability is designated.
For example, the ability to View an Incident Log needs to be divided into two Functional Rights
– one for Operators to have the capability to view the raw data, and one for external users who
will have the capability to view a filtered set of data. However implemented, it must be
recognized that these are two distinct Functional Rights.
CHART II Business Area Architecture Report
57
January 8, 2006
CHART II Business Area Architecture Report
Maintain Functional Rights - 10/5/99
1
2
Add Group Selected
Determine New Group
Name
Need to Maintain
Functional Rights
Modify/Delete Selected
D6
3
Role
List Functional Rights
Groups
Group List
Role Data
Groups List
4
Add Functional Rights to Group
5
Select Functional Rights
Group
Determine If Functional
Rights Group Is Assigned to
Role
Delete Rights Group
Modify Group
Assigned to Role
7
While Adding/Modifying Functional Rights Groups
D4
Functional
Rights Group
6
Confirm Delete
D3
7.1
Functional
Right
Functional Rights Data
Maintain Functional
Rights
If Confirmed
Not Assigned to Role
8
9
Delete Group from
Database
Update Database
10
Functional Rights Group Data
Deleted from Roles OK
Delete from Database
Update Functional
Rights Data
Log Rights Group Update
11
Log System
Operation
Log Data
D5
Operations
Log
Figure 2-10. Maintain Functional Right (August 2000)
CHART II Business Area Architecture Report
58
January 8, 2006
Delete Functional
Rights Group from
Roles
CHART II Business Area Architecture Report
2.2.4.1.1.4 Maintain Functional Responsibilities and Alert Types
The Maintain Functional Responsibilities and Alert Types process maintains the table of values
that designates the functional capabilities of the system that may be assigned to specific centers.
Implementation Considerations: These Functional Responsibilities and Alert Types define the
system capabilities for centers and logically may be at a different level of specificity than the
Functional Rights assigned to users. For example, specifying a Functional Responsibility for
Action Logs may be sufficient to indicate the related Maintenance Shop center will have access
to Action Logs; whereas Functional Rights assigned to users at the Maintenance Shop will limit
their Functional Rights to Viewing and Closing of the Action Logs, but not the creation of
Action Logs.
CHART II Business Area Architecture Report
59
January 8, 2006
CHART II Business Area Architecture Report
1
Need to Maintain Functional
Responsibility Groups
Maintain Functional Responsibilities -10/5/99
Modify/Delete Selected
D4
9
Center
List Groups
Group LIst
Center Data
Add a New Group
Func Resp Group List
14
10
Select Group
Check if Functional
Responsibility is Assigned
to Center
Group to Delete
Group to Modify
If Assigned to Center
If Not Assigned
D1
Functional
Responsibility
Groups
Added Group
4
6
Add Functional
Resp Group
Modify Functional
Resp Group
15
Confirm Delete
New Group for Functional Responsibilies
Group for Modification
Functional
Responsibility & Alert
Type
D3
Functional Responsibility
11
While Modifying Group
5
11.1
Delete Functional
Resp Group
If Confirmed
Maintain Functional
Responsibilities
Update Group Info
8
Deleted Group
Update Functional
Resp Group
Updated Group Info
Log Update
D2
Operations
Log
7
Log Data
Log System
Operation
Figure 2-11. Maintain Functional Responsibilities (August 2000)
CHART II Business Area Architecture Report
60
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.1.5 Maintain Geographic Responsibility
The Maintain Geographic Responsibility process maintains the table of geographic boundaries
used to designate the geographic areas of responsibility for the centers.
Geographic areas of responsibility are expected to be as large as the entire state and as small as
part of a county. Different geographic areas may overlap other geographic areas within the table
of defined geographic areas, with the expectation that they will be related to different types of
centers. For example, Maintenance Shops have relatively small areas of responsibilities as
compared to TOCs, and an area of responsibility for a specific Maintenance Shop may cross the
boundaries of the areas of responsibility for two TOCs.
Once related to a center, these geographic areas of responsibilities (along with assigned
Functional Responsibilities) are used to identify the center to receive specific types of Alerts for
specific types of devices within the area. For example, a specific Weather Station will fall within
the geographic area of responsibility of a TOC for purposes of weather related Alerts, and will
fall within the geographic area of responsibility of a Radio Maintenance Shop for purposes of
device failure Alerts.
1
Maintain Geographic Responsibility - 10/5/99
Add Selected
Need to Maintain Geographic
Responsibility
D3
List Resp
Center
2
Geo List
List Geographic
Responsibilities
Center Data
List
6
Add Geographic
Responsibility
7
3
Select Geographic
Responsibility
Check if Geographic
Responsibility is Assigned
to a Center
Delete Selected
Modif y geo area
D1
Not Used
Geographic
Responsibility
4
While Modif ying Geographic
Responsibility
Add Area
4.1
Used
9
8
Delete Geographic
Responsibility
Notif y User- Fail
Delete
Maintain
Geographic Data
Geographic Data
Update Geo Inf o
11
Updated Data
Update Geographic
Responsibility
Delete Geo Resp
Update Inf o
10
Log Sy stem Operation
Log Data
D2
Operations Log
Figure 2-12. Maintain Geographic Responsibility (August 2000)
CHART II Business Area Architecture Report
61
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.1.6 Maintain Center and AOR
The Maintain Center and AOR process maintains the table of centers defined to the system.
Basic center information includes the identity of the center and its hierarchical responsibility
relationship to other centers. This process also maintains the relationships to respective
Functional Responsibilities and Geographic Area of Responsibility for each center.
The hierarchical responsibility relationship identifies where to forward Alerts that are not
deliverable to or responded by the center. Functional Responsibilities identify the system
functions the center is permitted to perform and the types of Alerts this center may receive. The
Geographic Area of Responsibility identifies the physical area of coverage for the center, further
defining those devices and related Alerts that may be sent to the center.
CHART II Business Area Architecture Report
62
January 8, 2006
CHART II Business Area Architecture Report
Maintain Center and AOR -10/5/99
8
1
Add Operations Center Selected
Need to Maintain Centers
Select Center for
Deletion
Delete Selected
Modify Center Selected
2
While Adding Centers
Center Info
10
2.1
List Centers
Determine New Center Name
New Center Name
Center Information
14
Modify Selected
Check for Subordinate
Center
2.2
Select Associated Geographic
Responsibility
D3
Geographic Responsibility List
Geographic
Responsibility
7
Select Center to Update
Selected Center Detailed Data
Subordinate Center Found
Center/Area of Resp
Geo Resp
2.4
Select Associated Functional
Responsibilities
16
Notify User Fail Delete
Center to Update
4
While Updating a Center
Functional Responsibility List
4.2
Center/Geo and Func Resp
2.6
D4
Functional
Responsibility &
Alert Type
D1
Modify Geo/Func Resp/Heirarchy
Center
Func Resp
Alert Types
No Subordinate Center Found
Select Associated Alert Types
Center/Geo/Func/Alert Responsibility
Updated Op Center/ Geo/Func Resp
2.5
Add Center Heirarchy
6
Store Center with Geo/Func/Heir
Updated Center Information
9
Store Updated Center
Deleted Center
Updated Center Data
D2
Ooperations
Log
Log Data
12
Log System
Operations
Figure 2-13. Maintain Center and AOR (August 2000)
CHART II Business Area Architecture Report
63
January 8, 2006
Delete/Inactivate Center
from Database
CHART II Business Area Architecture Report
2.2.4.1.2
Operational Control
The Operational Control group of processes identifies the required processes to allow users to
log onto or out of the system, to pass operations related information between users, and to
manage responsibility for ongoing Incidents and use of the system’s shared resources between
Traffic Operations centers.
2.2.4.1.2.1 Maintain Center Notepad
The Maintain Center Notepad process provides the capability by which shift supervisors may
record and inform users at the center of pertinent information. Each center will have a free text
notepad maintained by Shift Supervisor(s), where the Shift Supervisor(s) may enter any
information to be passed onto users (for the same center) when the users Logon to the system.
The View Center Situation Data process displays the contents of the notepad to the user as a step
in the Logon process.
CHART II Business Area Architecture Report
64
January 8, 2006
CHART II Business Area Architecture Report
Maintain Center Notepad - 8/18/99
1
Create Notepad
If Not Created
Notepad Exis ts
Notepad
D1
Center
Notepad
Need to Maintain
Center Notepad
Exis ting Text
7
Maintain Notepad
Text
Notepad Data
Updated Notepad Inform ation
5
Save Center
Notepad
Update Information
D2
Operations
Log
Log Data
6
Log Sys tem
Operation
Figure 2-14. Maintain Center Notepad (August 2000)
CHART II Business Area Architecture Report
65
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.2.2 User Logon
The User Logon process verifies the user as a CHART II user and initializes the controls for
whatever role has been assigned to that user.
In the process design workshops, it was determined that the system steps to completing a User
Logon should include the following:

Machine

Network

Database

Functional Rights

Area of Responsibility
During logon, the CHART II system first logs into the user’s machine and, if necessary, it logs
into the network. If there are three unsuccessful attempts to login with an ID, the ID is locked
and the information is logged. Once the machine/network logon is successful, the system logs
into the database, which allows the retrieval of the user’s authorized centers. If the user is
authorized Logon to multiple centers, he/she will be requested to identify the center to be related
for this session; if only authorized Logon to a single center, the system will relate the user to that
center. Upon determination of the center for the session, the system will match users Functional
Rights with the center’s Functional Responsibilities and determine the user’s Functional Rights
for this session. The user’s GUI Preferences are retrieved and the CHART application is
initiated. All steps are logged.
The View Center Situation Data process is performed after the application is initiated.
Functional Rights are indirectly related to the user through the Role(s) assigned to the user. Area
of Responsibility is determined based on the center selected for the session and the Geographic
Area of Responsibility related to the center at the time of the Logon.
Area of Responsibility refers to the types of alarms a center may receive from the system, as well
as the geographical area from which these alarms may be generated.
CHART II Business Area Architecture Report
66
January 8, 2006
CHART II Business Area Architecture Report
Logon User - 9/27/99
1
Logon
Machine & Network
Verification
Logon Information
D9
Not Verified
Operations
Log
User & Network Information
2
3
Lock Account
Log Data
Not Verified - 3rd Attempt
Log Logon Attempt
Logon Attempt
Verified
Lock Data
11
List Allowed
Centers
9
If more than 1 Center Allowed
RetrieveUser Allowed
Center List
Center List
User/Center Xref Data
D7
Successful Logon
If 1 Center
10
12
Select Center
Center
13
Log System
Operation
Set Center
Responsibilities
Selected Center
Center Responsibilities
D8
D6
Center Geographical Area & Functional Rights
Functional
Responsibility &
Alert Type
User
User/Role Data
4
Set Role
Role
D5
Role
D1
Functional Right
D4
User Preference
Verified Role
5
Enable Functional
Rights Based on
Center Rights
Functional Rights
Verified Func Rights
8
Initialize GUI
User Preferences
If Operator-Display Status Report
View Center Situation
Figure 2-15. User Logon (August 2000)
CHART II Business Area Architecture Report
67
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.2.3 View Center Situation
The View Center Situation Data process provides CHART users at SHA centers with a view of
the recent and current center activities as related to Incident Logs, Action Logs, Device Failures,
and Alerts. It is not expected to display this information to non-SHA users, such as the media or
those accessing the system only to retrieve Archived data.
The term ‘recent’ refers to center activities over the last number of hours as specified in the
System Parameters. The center notepad is displayed to inform the user of information from the
Shift Supervisor.
The View Center Situation Data will be somewhat different for each type of center. For example,
the full set of situation data described above is for the SOC and TOCs. A Maintenance Shop
would not receive a view of Incident Logs or Action Logs, but would receive a view of Device
Failures and Alerts related to that center’s area of responsibility.
CHART II Business Area Architecture Report
68
January 8, 2006
CHART II Business Area Architecture Report
View Center Situation - 10/5/99
1
Retrieve
Configuration
Data
Config Data
D6
System
Parameters
D1
Incident
Log
D2
Action Log
D3
Failure
Log
D4
Alert Data
# of hours
2
For Past ## Hours and AOR
2.1
Retrieve
Incident Logs
Current and closed over ## hours
Incidents
2.2
Retrieve Action
Logs
Action Log Data
Actions
2.3
Retrieve
Device Failures
Failure Data
Failures
2.4
Retrieve Alerts
Alert Data
Alerts
2.5
Retrieve
Center
Notepad
Notepad data
D5
Center
Notepad
All Data
3
Display Report to User
Figure 2-16. View Center Situation (August 2000)
CHART II Business Area Architecture Report
69
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.2.4 Maintain User Preferences
The Maintain User Preferences process maintains the data values that control user-selectable
GUI and system capabilities so that the User Preferences are initiated each time the user starts
the application.
Implementation Consideration: application design will have to address any variances in user
preferences affected by a user having multiple authorized centers with different sets of
Functional Responsibilities.
Maintain User Preferences - 9/9/99
Stored User Preferences
1
Get User Preferences
for Current User
Current User Preferences
D1
User
Preferences
2
Add/Delete/Modify User
Preferences
Modified User Preferences
User Preferences
3
Store User Preferences
Figure 2-17. Maintain User Preferences (August 2000)
CHART II Business Area Architecture Report
70
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.2.5 Maintain Operator’s Notepad
The Maintain Operator’s Notepad process views and maintains a free text area for each user in
which the user may store pertinent/personalized information. Examples of data expected to be
stored in this free text area include key phone numbers, operator’s procedural notes, etc. All
operators are expected to maintain their own notepads with the information they determine to be
important.
As operators may be assigned at various centers at various times, the system must ensure that the
operator’s notepad is available wherever the operator is located across the system.
It is not anticipated that all CHART users will need this capability and Functional Rights need to
be granted to users to provide the capability to the user. Only the creating user may have access
to his/her notepad.
CHART II Business Area Architecture Report
71
January 8, 2006
CHART II Business Area Architecture Report
Maintain Operators Notepad - 9/17/99
2
Create Notepad
If Notepad does not Exist
1
Need to Maintain
Operators
Notepad
New Notepad
D1
Operators
Notepad
Notepad Exists
3
Current Text
Maintain Notepad Text
Updated Notepad
Notepad Text
4
Save Operators
Notepad
Notepad Update
D2
Operations
Log
5
Log Data
Log System Operation
Figure 2-18. Maintain Operator's Notepad (August 2000)
CHART II Business Area Architecture Report
72
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.2.6 Perform Chart Chat
The Perform CHART Chat process provides CHART operators with the capability to
communicate between workstations over the network. The CHART Chat process provides the
Chat user with a list of other online users from which the Chat user selects those other online
users to which he/she wishes to send a message. The Chat user then enters a free text message
that is transmitted to the selected recipients.
The workshop participants determined that there was no need to record/retain information about
the use of Chat or of the contents of the messages sent.
Implementation Consideration: a version of CHART Chat was recently completed under the
Web development effort. This application is available to CHART II to integrate into the CHART
II application.
CHART II Business Area Architecture Report
73
January 8, 2006
CHART II Business Area Architecture Report
Perform Chart Chat - 9/17/99
1
D1
User
Users Online
Retrieve List of
Online Chart Users
Online User List
2
Select Users for
Chat
Selected Recipients
3
Type Text
Message for Users
4
Send Text to Users
Figure 2-19. Perform Chart Chat (August 2000)
CHART II Business Area Architecture Report
74
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.2.7 Logout
The Logout process validates that the last user to request logout at a center has released control
or transferred all responsibilities. If not, the logout is failed and the user is put into the Transfer
Shared Resources processes to perform the transfer of these resource and responsibilities. A
successful Logout will disconnect a user from the application system and the network.
1
Request
Logout
Logout User - 10/11/99
User Information
3
2
Get Number
Logged In
Number of Operators Logged In Count - Greater than 1
Number of Operators Logged In Count - equals 1
Logout User
4
Get Assigned
Resources
Assigned Resource Count - equals 0
Assigned Resource Count - greater than 0
5
User Logout Information
Fail Logout
Assigned Resources
Transfer Shared
Resources
Resources Transfered
6
Log System
Operation
D1
Logout Info
Operations Log
Figure 2-20. Logout (August 2000)
CHART II Business Area Architecture Report
75
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.2.8 Change User
The Change User process provides the capability for a user to logon to a Workstation to replace
the current user. The intent of this feature is for use during a shift change to overcome the check
in the Logout process for the last user logging out for a center. The new user logging onto the
system must be granted the same center access as the current user in order to take over
responsibility for the shared resources currently assigned to the center.
Change Us er - 10/6/99
1
Change Us er
Selected
Shift Change
Send Us erID/Pass word/Current Center
2
Logon New
Us er
Logon
Return Status
If Succes sful
3
Logout
Previous Us er
Logout
Logout
Figure 2-21. Change User (August 2000)
CHART II Business Area Architecture Report
76
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.2.9 Transfer Resources
The Transfer Resources process allows for a user at a given center to transfer responsibility for
ongoing activities and controlled resources to another center.
This process may be used at any time to transfer responsibility between centers, and is to be
performed as part of the closing of a center at the end of a workday. The last user at a center will
not be permitted to logout of the system until these transfers are performed and the system does
not detect any open logs or resources assigned to that center.
When resources are transferred and alert is sent to the receiving center notifying them of the
transfer. Acknowledgment is not required for completion of the transfer.
This process applies to the TOCs only.
Notes from the process design workshops included the following:
1. At the end of the day, all devices and open incident logs must be transferred to the SOC
before the last operator logs out.
2. The transfer of devices and incident logs will be displayed on the recipients’ ticker and an
acknowledgment will be recorded when the devices/logs are accepted.
3. The transfer will show up on the ticker of all logged in users at the recipient center.
4. At the end of a shift at the TOC (not the end of the day), the Change User process will be
used to avoid having the last user attempt to Logout of the center.
CHART II Business Area Architecture Report
77
January 8, 2006
CHART II Business Area Architecture Report
1
Select
Res ources
Transfer Shared Res ources - 11/15/99
Shared Res ource Inform ation
2
For each res ource s elected
D2
Alert Data
Store Alert Data
2.1
Set Controlling
Operations
Center
Send Alert
Shared Res ource Alert Info
Transfer Log Inform ation
D1
5
Log Sys tem
Operation
Operations Log
Log Data
Figure 2-22. Transfer Resources (August 2000)
CHART II Business Area Architecture Report
78
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.2.10 Respond to Request to Transfer Resources
The Respond to Request to Transfer Resources Alert process is used to allow the individual to
receive the alert, capture when the alert was acknowledged, and display the resources that have
been transferred.
Respond to Request to Transfer Resources Alert - 11/15/99
1
Date/Time and User
Acknowledge
Alert
Alert Data
D1
Alert Data
Alert Ackd
3
Display
Transferred
Resources
Figure 2-23. Respond to Request to Transfer Resources (August 2000)
CHART II Business Area Architecture Report
79
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.3
Configuration Processes
The Configuration Processes group of processes maintains those data items that configure and
control the actions of the system processes. These include the System Parameters and Links.
System Parameters are those data items that supply control information to the processes.
Links define segments of the highways as units to be measured and monitored for traffic
management. These defined segments determine the units of information to be displayed on the
visual Map to provide traveler information related to current traffic conditions.
2.2.4.1.3.1 Maintain System Parameters
The Maintain System Parameters process maintains the data values for the System Parameters
that control the other processes in the system. The process provides the authorized user with the
capabilities to add and modify System Parameters.
The specification of System Parameters and their values must be closely coordinated with the
design of the Applications for CHART II. Since these values are “plugged in” to the
applications, accuracy in maintaining these parameters is critical to the continued operation of
the system.
Examples of System Parameters include:

Time in advance of EORS Permit start time to activate EORS icon

Interval to wait to send Alert for Delinquent Equipment Status

Determining which response plans need to be executed based on which Counties are
declaring a snow emergency.

Frequency, time of day, and permit time range for downloading EORS permit data

Frequency for checking System Components

Frequency for checking for National Weather Service weather alert

Frequency for refreshing default AVCM Presets
CHART II Business Area Architecture Report
80
January 8, 2006
CHART II Business Area Architecture Report
Maintain System Parameters -10/5/99
9
Need to Maintain
System Parameters
Add Selected
Modify Parameter Selected
2
1
Add System
Parameter
Display List of
System Parameters
Parameter List
Modify
3
Modify System
Parameter
D1
Modify Parameter
System
Parameter
6
Modify Parameter Value
Modify Parameter
Information
Updated Parameter Information
7
Update System
Parameters
Updated Parameters
Updated Parameter List
8
Log System
Operation
Log Data
D2
Operations
Log
Figure 2-24. Maintain System Parameters (August 2000)
CHART II Business Area Architecture Report
81
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.3.2 Maintain Links
The Maintain Links process provides the capabilities to maintain the data values that define
Links to the system, and therefore configure and control the units of traffic information
maintained and monitored in the system. Maintenance of Link data includes relating Links to
specific Detectors and to the CHART map data. The relation to specific Detectors is necessary to
relate gathered volume, occupancy, and speed data to specific Links. The relation to CHART
map data is necessary to specify where each Link is to be displayed on the map.
Conceptually, Links may be defined as detector-to-detector segments, exit-to-exit segments,
fixed length segments of a highway, or any other unit deemed appropriate. Links for CHART II
have not been specifically defined as of the writing of this report, and may not be defined until
XAD.
CHART II Business Area Architecture Report
82
January 8, 2006
CHART II Business Area Architecture Report
1
Need to
Maintain Links
Modify/Delete Selected
Maintain Links -9/17/99
2
List Links
Links
Links List
3
Add Selected
Delete Selected
Select Link
Modify Selected
6
5
Add Link
Modify Link
Link to Add
4
Delete Link
Data
Link to Modify
7
While Not Done Adding or Modifying Links
D1
7.1
Link
Delete Data
Add/Modify/Delete
Associated Link Data
Devices
11
Modified Data
Store Link Data
D3
Updated Link Data
Device
Configuration
Change in Link
D2
Operations Log
Log Data
12
Log System
Operations
Figure 2-25. Maintain Links (August 2000)
CHART II Business Area Architecture Report
83
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.4
Maintain FITM Plans
The Maintain FITM Plans process provides the capabilities to maintain electronic versions of the
FITM currently maintained in paper format. FITM plans consist of diagrams of detour routes,
text descriptions of the detour routes, and text lists of required equipment and actions to be taken
to implement the plan. A FITM plan covers a highway between two exits, and includes
information for establishing detours in either direction of travel on the highway.
The Maintain FITM Plans process defines a plan by the exits covered and the travel direction,
implying that today’s paper plans may result in two or more electronic plans. The process
provides for the creation, modification and deletion of plans. Each plan is composed of a
graphics part, textual description, and textual directions. The graphics part of a plan may be
scans of annotated maps, may be electronic maps, or may be layers on the GUI display map (this
is to be determined at XAD). The textual description part is joined with the graphic part. This is
used to form a transmission to the public about the detour when it is implemented. The textual
directions are instructions to CHART and other agencies staff managing the incident, identifying
the need and placement of traffic control devices (arrow boards, cones, etc.) and the location and
messages to be displayed on DMS or HAR devices.
This maintenance of FITM plans in electronic format is expected to be useful in maintaining
hard copies of FITM plans carried in the CHART vehicles and FITM trailers. A manual process
will need to be established to print and distribute change pages to hard copy folders, and have the
folders updated by page replacements.
Operators have two alternative methods for initiating a FITM plan. The first method is to follow
the FITM plan documentation and perform the actions described in the documentation. The
second method is to setup Plans using the Maintain Plans process, and then allowing the
implementation of a FITM plan using the Activate Plan process. It is not expected at this time
that the system will automatically activate a designated Plan when an Incident Log is identified
as a FITM condition, as it will take a significant amount of time to develop Plans for all of the
FITM plans. At such time as all the Plans have been developed, the activation of a FITM related
Plan could be implemented based on the location and direction of an Incident.
CHART II Business Area Architecture Report
84
January 8, 2006
CHART II Business Area Architecture Report
Maintain FITM Plans - 11/10/99
1
Need to Maintain
FITM Plans
FITM Plan Data may consist these types of data:
1. Scanned FITM Plan Image for each direction including:
Detour Text
Image
Equipment Deployment Instructions
2. Vector Detour Data
3. Text
Modify/Delete FITM Plan
2
List FITM Plans
Plan List
FITM Plan List
4
Add FITM Plan
3
Add New FITM Plan
Select FITM Plan
Delete Selected Plan
7
Delete FITM
Plan
Delete FITM Plan
Modify Selected Plan
6
Modify FITM Plan
Add FITM Plan Data
D1
FITM Plan
Modify FITM Plan Data
8
While Not Done Adding or Modifying FITM Plans
8.1
Add/Modify/Delete Associated FITM Data
Updated Data
5
Store FITM
Data
Updated FITM Plan Data
Log FITM Plan Update
D2
Operations
Log
Log Data
9
Log System
Operation
Figure 2-26. Maintain FITM Plans (August 2000)
CHART II Business Area Architecture Report
85
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.1.5
Map Configuration
The Map Configuration process group contains a single process to maintain Map Data for the
CHART II system.
NOTE: CHART Map has been developed as a stand along product that has a data feed from
CHART for live data. Currently no integration effort has tied CHART Map and CHART Lite to
satisfy the final vision of the BAA.
2.2.4.1.5.1 Update MDOT GIS Map Data
The Update MDOT GIS Map Data process provides the capabilities to download map data from
the MDOT GIS system. This process allows the CHART II Map information to be periodically
synchronized with the MDOT map information and eliminates the need for frequent CHART II
system maintenance to maintain the Map information. This process retrieves new data from the
MDOT system on an as-required basis, performs any necessary data conversion, and stores the
converted data in CHART II. Details of this process will be determined at detail design.
Update MDot GIS Map Data - 8/23/99
1
At Time Determined by Admin
1.1
Retrieve Updated
MDot Map Data
Updated data
D2
MDOT Map
Data
Updated Map Data
1.2
Store Map
Data
Map Data
D1
Chart Map
Data
Figure 2-27. Update MDOT GIS Map Data (August 2000)
CHART II Business Area Architecture Report
86
January 8, 2006
CHART II Business Area Architecture Report
CHART II Business Area Architecture Report
87
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.2 System Configuration and Status
The System Configuration and Status processes include processes necessary to define, setup, and
monitor the hardware, software, and devices of the CHART II system. These processes are
divided into groups related to components and devices. The following figure identifies the
individual processes within each group
System Configuration and Status - 10/28/99
1
System Configuration and Status
1.1
Components
1.2
Devices
1.1.1
Maintain
Component
Configuration
1.2.1
Maintain Device
Configuration
1.1.2
1.2.2
Log System
Failures
Set Device
Online
1.2.3
Set Device
Offline
1.2.4
Handle DMS and
HAR Polling
Results
1.2.5
Respond to
Device Failure
Alerts
Figure 2-28. System Configuration and Status (August 2000)
CHART II Business Area Architecture Report
88
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.2.1
Components
The Components group allows for the System Administrator to maintain the overall
configuration of the CHART II system and for the Operators to monitor the health of each of the
components.
2.2.4.2.1.1 Maintain Component Configuration
The Maintain Component Configuration process maintains tables of data to identify computer
system components (i.e., servers, clients, software, communications, legacy systems).
Component configuration data will include data to control the frequency and type of status
checks to be performed on the components.
3
A dd Co mpon ent
In fo rmati on
1
Need to Ma in ta in
Co mp one nts
A dd Co mpon ent
Modi fy Compo nent
Mai nta in Comp onen t Config uratio n - 9/17/99
Del ete Comp onen t
2
Compon ent Li st for Del eti on
Dis pla y Comp onen t Li st
Compon ent Li st for Upd ate
4
5
Compon ent Li st
S el ect Comp onen t for
Mo difi cati on
Compon ent In fo
S el ect Comp onen t for
De leti on
Compon ent In fo for Upd ate
D1
Compon ent
Co nfi gu ra ti on
6
Modi fy Compo nent
In fo rmati on
Compon ent In formati on
Modi fi ed Comp onen t Informa ti on
7
A dded Comp onen t Informati on
Del ete d Co mpone nt Informatio n
Update Compo nent Co nfigu ra ti on
Da tab ase
Lo g Comp one nt Chan ge
8
Lo g System Operatio n
Updated Comp onen t Informa ti on
D2
Operatio ns Lo g
Figure 2-29. Maintain Component Configuration (August 2000)
CHART II Business Area Architecture Report
89
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.2.1.2 Log System Failures
The Log System Failures process performs the writing to a database table of system failures
when the status of a system component changes to an unhealthy state.
As part of the reliability of the new system, it is expected to poll each system component at a
component-specific frequency and identify any failure. Each detected failures is logged and the
date/time stamp of the last poll and the status is maintained for each component. Specific system
action is taken for certain components to attempt correction of the failed component. Specific
components mentioned in the workshop were:

Servers

Clients

Software

Communications

Legacy Systems
Representative data to be logged for system failures includes:

Device identifier

Last Polled Date/Time Stamp

Failure type

Location / variable
From information reported and retained, the system administrators will be able to identify the
frequency of failures of specific components, as well as to initiate corrective actions at the time
of failure.
CHART II Business Area Architecture Report
90
January 8, 2006
CHART II Business Area Architecture Report
1
Determine Component to Poll
Component Polling Frequency
D1
Component
Conf iguration
Poll Component
Log Sy stem Failures - 10/26/99
2
Poll Component
Return Status
3
Validate Health
4
Component Failure Info
Log Failure
Failure Inf o
D3
System
Parameter
D2
Status/Time
Failure Log
# of Failures ov er Time Period
6
Check- # of Component Failures/Specif ied
Time Meets Notification Criteria
5
Restart Inf o
Correction Succeeded
System Correction Process
Update Component Status
Correction Status
Requires Notif ication
Correction Failed
Perf orm Notif ication
Send Alert
Store Alert Data
D4
Alert Data
Figure 2-30. Log System Failures (August 2000)
CHART II Business Area Architecture Report
91
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.2.2
Devices
The Devices group allows for the Operators to maintain the overall configuration of the CHART
II devices and monitor the health of each of the devices.
2.2.4.2.2.1 Maintain Device Configuration
The Maintain Device Configuration process maintains tables of data to identify and control
CHART devices such as DMS, HAR, detectors, sensors, cameras, etc.
HAR devices may have related SHAZAM devices and/or DMS devices (with assigned message)
that can be activated when a HAR message is broadcast.
Devices include location information so the device may be dynamically assigned to a center
based on the current Area of Responsibility for a given center.
Maintain Device Configuration - 10/5/99
1
Add Device
Need to Maintain Devices
Modify/Delete Device
2
Display Device List
Device List
Configured Devices
3
4
Add New Device and
Configuration Data
Select Device for
Modification/Deletion
Device Info
Delete Device
Modify Device Data
6
D3
9
Plan
Plan Info
Determine if Device is
Used in a
Plan/Schedule
Modify Device
Information
If Not Used - Delete
Added Device Information
D1
Device
Configuration
If Used
Schedule Info
Delete from Plan
Modified Device Information
D4
10
Schedule
Data
Delete from Schedule
If ConfirmedDelete from
Plan/Schedule
If confirmed - delete
7
Update Device
Configuration Database
Device Information
Log Deletion
Changed Device Info
8
Log System Operation
Log Data
D2
Operations Log
Figure 2-31. Maintain Device Configuration (August 2000)
CHART II Business Area Architecture Report
92
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.2.2.2 Set Device On-Line
The Set Device On-Line process allows an operator to change one or more devices currently offline (out of service) to an on-line (in service) state and display revised statuses for the selected
devices. Setting a device on-line is a logical status change in that other system processes will
begin to interact with the device. This process assumes the FMS or AVCM application needs to
be notified of the status change. Device status information is displayed at the next polling cycle.
1
List of Of f line Dev ices
Display Device List
D2
Dev ice
Conf iguration
Dev ice List
2
Set Device Online - 12/16/99
Select Dev ices
Selected Devices
3
For Each Dev ice Selected
3.1
Format Online Command
Formatted Command
If HAR Dev ice
3.2
3.3
HAR - Restore Message
DMS - Restore Message
Formatted Command & Device
Send Online
Command to
FMS/AVCM
Success
Update Dev ice
Status
FMS/AVCM
Status Inf ormation
If DMS Dev ice
Failure
Command Successf ul
3.5
3.4
Log Sy stem
Operation
Success Inf o
D1
Operations
Log
Log Failure
Failure Inf o
Command Failure
3.6
Notif y Operator
Figure 2-32. Set Device Online (August 2000)
CHART II Business Area Architecture Report
93
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.2.2.3 Set Device Off-Line
The Set Device Off-Line process allows an operator to change one or more devices currently online (in service) to an off-line (out of service) state and display revised statuses for the selected
devices. Setting a device off-line is a logical status change in that other system processes will no
longer interact with the device. This process assumes the FMS or AVCM application needs to be
notified of the status change.
1
Display Device
List
Set Device Offline -10/5/99
D2
List of Online Devices
Dev ice
Conf iguration
Dev ice List
2
Select Dev ices
Selected Devices
3
For Each Dev ice Selected
3.1
Format Of f line Command f or
FMS/AVCM
Formatted Command
3.2
3.3
Update Dev ice
Status
Success
Formatted Command & Device
Send Command to
FMS/AVCM to put
dev ice of f line
FMS/AVCM
Status Inf ormation
Updated Status
Command Failure
3.4
3.5
Log Failure
Log Sy stem
Operation
Success Inf o
D1
Operations
Log
Failure Data
Failure
3.6
Notif y User
Figure 2-33. Set Device Offline (August 2000)
CHART II Business Area Architecture Report
94
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.2.2.4 Set Device to Maintenance Mode
The Set Device to Maintenance Mode process is used to take one or more devices out of the online mode, but still have communications with FMS/AVCM to continue in order to send
commands. The polling of the device(s) will not, however, be active until the device is returned
to an on-line state. This mode will be limited for usage by the maintenance organizations (i.e.,
signal shop, DMS shop) in order to test devices.
Set Device to Maintenance Mode-11/10/99
1
Display Device
List
List of Devices
D1
Device
Configuration
Device List
2
Select D evices
Selected Devices
3
For Each Device Selected
3.1
Format Maintenance Mode Command to
FMS/AVCM
Formatted C ommand
3.3
3.4
Update Device
Status
Send Command to F MS/AVCM to put
device into Maintenance
Success
Formatted C ommand & Device
FMS/AVCM
Status Information
Updated Status
Command F ailure
3.5
Log System
Operation
Log Success Data
3.6
Log Failure
D2
Operations
Log
Failure
Log Failure Data
3.7
Notify User
Figure 2-34. Set Device to Maintenance Mode (August 2000)
CHART II Business Area Architecture Report
95
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.2.2.5 Handle DMS and HAR Polling Results
The Handle DMS and HAR Polling Results process updates the result of periodic health checks
of HAR and DMS devices. The frequency of polling these devices is controlled by configuration
data for the individual devices. FMS will perform the communication with the devices at the
specified polling frequency and pass the resulting health check information to CHART II. If the
device is within acceptable diagnostic parameters, the status of the device is updated to indicate a
healthy status and the date/time stamp of that status. If the device is outside acceptable diagnostic
parameters, the failure information is written to the Failure Log. Each device may be configured
so that a certain number of failures must be received before an alert is sent. Once the minimum
number of failures is reached, an alert is sent to the responsible center, and the status of the
device is updated to reflect a failure status and the date/time stamp of the failure.
Implementation consideration: DMS and HAR failures may be indicated as a result of a
system component failure. To ensure that the proper maintenance response is initiated, the
system must be able to determine the difference between component and device failures and
report them accordingly. In other words, the inability to communicate with a DMS may be due to
a device failure, a communication failure, or even an FMS failure. CHART II needs to be able to
tell the difference and log the proper type of failure so that the appropriate maintenance shop or
contractor can be dispatched to make a repair. The system also needs to be able to control the
frequency of logging failures for devices already in a failure status, or devices that have failed
several times in a short period of time.
CHART II Business Area Architecture Report
96
January 8, 2006
CHART II Business Area Architecture Report
Handle DMS and HAR Polling Results - 12/1/99
If OK
If Failure
FMS
2
Update Dev ice
Status
1
Status Inf ormation
Good Status Receiv ed - Clear Failures
Failure Log
4
HAR
Failure Conf ig Data
Retriev e # of Failures Bef ore Alert and
Current # of Failures
Clear Data
If # of Failures is greater than 0
- Reset to zero
D2
Failure State
D7
6
Failure Inf o
Log Failure
D6
DMS
Failure Conf ig Info
Clear Inf o
If less than # of failures f or alert
# of Failures
If # of failures f or alert receiv ed
7
5
# of Failures Reciev ed
Increment # of Failures
Received
Alert Information
Store Alert Data
Failure Alert
Send Alert
Figure 2-35. Handle DMS and HAR Polling Results (August 2000)
CHART II Business Area Architecture Report
97
January 8, 2006
D5 Alert Data
CHART II Business Area Architecture Report
2.2.4.2.2.6 Respond to Device Failure Alerts
The Respond to Device Failure Alert process allows personnel to acknowledge receipt of a
device failure alert for the following devices:

DMS

HAR

Signals

AVL
Respond to Device Failure Alert - 11/15/99
Once the alert is acknowledged, any information related to the failure will be input into the
associated log.
1
Acknowledge
Alert
Alert Data
Date/Time and User
Alert Ackd
Device ID Failure
D3 Action Log
Log ID
D1
2
Create Action
Log
Alert Data
Action Log ID
Log Opened
Log Action Log
Figure 2-36. Respond to Device Failure Alerts (August 2000)
CHART II Business Area Architecture Report
98
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3 Incident/Event Management
The Incident/Event Management processes provide the capabilities to identify each operational
incident or event to be managed by the operations staff, to record various types of operational
actions taken, and to monitor results of actions taken to complete the handling of the incident or
event. Basically, each operational event is identified as one of several log types with a unique
identifier. All actions taken and the status of the incident or event are initiated and tracked from
within the log. This log approach allows each unique incident or event to be managed from a
single controlling source, allows all data related to a single incident or event to be captured as a
single entity, and provides a structured source of information for reviewing actions and
calculating performance measurements.
Events are recorded on various Log screens related to the type of event being handled. The intent
is to have the Communications Log screen displayed most of the time, as this is the most
frequently used log type. By selecting a different type of log, the screen will change to display
the format of the selected log type. Date/Time stamps are to be populated at the time the log
screen is saved – not when the screen is opened as the screen may sit idle for long periods of
time.
Comments noted from the process design workshops relative to all the log types are as follows:
1. The Date/Time Stamp associated with each text field on the logs is automatically placed
there when the text field is typed in.
2. Checking a check box (i.e., In Service or Out of Service) will automatically place a
date/time stamp and text in the text field. The operator may then add specifics, such as
which unit or shop is in service.
3. The User ID of the operator and area of responsibility will be captured in the background
for all actions.
4. The system will use the location of the logon to determine the center and area of
responsibility.
5. The system will have the ability to filter logs based on center, date/time range, and type.
6. Logs will be maintained active within the CHART II system for 2 weeks, as long as the
logs are displayed within several seconds of the request. If performance slips, the amount
of time a log remains active will be reduced.
7. The automatic log list will include all logs created during the previous 12 hours. If a
longer period is needed, the search function is used.
8. The search function must use type (i.e., incident, construction, etc.) as a search criterion.
9. There is a need for a way to trace an incident/disabled log to the original communications
log.
10. Save will save and close the window.
11. Some fields must be required fields. These are to be determined at a later date.
12. Whenever On Scene or Dispatched are checked, that is assumed to mean a unit belonging
to the agency filling out the log.
CHART II Business Area Architecture Report
99
January 8, 2006
CHART II Business Area Architecture Report
Incident Management - 12/16/99
1
Incident Management
1.1
Logs
1.2
Location Navigation
1.1.2
1.2.1
Log
Communications
Log
1.1.8
Maintain Location
Navigation Data
Log Recurring
Congestion Log
1.1.3
1.2.2
Log Action Log
1.1.9
Activate Location
Navigator
Log Special
Event Log
1.1.4
Log Disabled Log
1.1.10
Log Weather
Advisory Log
1.3
Queues
1.3.1
Calculate Queue
Length
1.1.1
Log Incident Log
1.1.1.2
View Historical vs
Current
1.1.11
Log Weather
Sensor Log
1.5
Notification
1.5.1
Maintain
Notification List
1.1.7
1.1.12
Log Congestion
Log
Log Safety
Message Log
1.5.2
Perform
Notification
1.1.5
View Log
1.1.6
Close Log
Figure 2-37. Incident Management (August 2000)
CHART II Business Area Architecture Report
100
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1
Logs
The Logs process group provides capabilities for operators to record and share information about
communications, disabled vehicles, required actions, congestion, and incidents. Logs may be
system or operator initiated.
2.2.4.3.1.1 Log Communications Log
The Communications Log process provides the user with the capability to record appropriate
information about communications received, but not necessarily requiring any follow up action.
From the communications log, the log type can be changed to any other log type.
CHART II Business Area Architecture Report
101
January 8, 2006
CHART II Business Area Architecture Report
1
Display Blank Comm
Log
Log Communications Log - 12/6/99
Comm Log Inf o
Create Header
D2
Communications
Log
2
Retriev e ID
Comm Log Close Timestamp
Assigned Log ID
User ID
4
While Not Closed
5
3
Log Action Log
Log Ty pe - Action
4.1
Close Comm Log
Close Log Inf o
Append New Line with
Date/Time stamp
Log Ty pe - Communications
Log Ty pe Disabled
Log Disabled Log
Log Incident Log
Log Ty pe - Incident
Comm Log Closure Info
D1
Communications
Log Text
Log Ty pe -Congestion
Comm Log Inf ormation
Determine Log Type
Log Ty pe-Special ev ent
Log Special Ev ent Log
Log Ty pe-Saf ety Message
Log Ty pe-Weather Advisory
Figure 2-38. Communications Log(August 2000)
CHART II Business Area Architecture Report
Log Congestion Log
102
January 8, 2006
Log Weather Adv isory Log
Log Safety Message
Log
CHART II Business Area Architecture Report
A prototype Communications Log screen as discussed in the workshops is illustrated in Figure 239. The operator Communications Log is used for each communication between the operator and
those outside the center. Simplifying this log will allow the operator to enter the information
directly into the system, rather than writing it on paper first. Suggestions were made for
simplifying the information including check boxes for the most common communication (i.e.,
10-7, 10-8, 10-46, 10-50). It was suggested that a fold/unfold feature would allow the comm log
to expand to an incident report. Discussion included the ability to search the comm log database
based on a keyword, and the ability to display only the comm logs associated with the operator’s
area of responsibility. Although 10-codes are used in everyday activities at the SOC/TOCs, it
was decided not to use them in the system in order to make the screens more user friendly to
other agencies utilizing the system.
Communications Log
Source
In Service
Out of Service
ID
County
Communications Log
05/14/99 12:32:00
Out of Service
Time Stamp
Text
Save
Append
Search Log
Figure 2-39. Prototype Communications Log Screen (August 2000)
CHART II Business Area Architecture Report
103
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1.2 Log Action Log
The Log Action Log process allows the user with the correct functional rights to record
appropriate information about device failures and non-blockage events (signals, debris, utility,
signs, etc.). The operator can notify the responsible shop/agency of a failure by sending a manual
alert or transferring responsibility of the open log. Others can also be notified of the failure
through e-mail, fax, or page. This process may be system or operator initiated.
Log Comm Log
Log Action Log - 12/6/99
Log Ty pe - Action
1
Header Data
Create Action Log Header
D3
Action Log
Action Log ID
Log Inf o
2
While Action Required and NOT Closed
2.1
Alert Sent
Send Alert
Notif y Appropriate Contact of
Required Action
Notif y
Perf orm Notif ication
Notif y Ack
Ack
Dispatch Status
Store Alert Data
2.2
D2
Alert Data
Update Log Text
Log Inf ormation
D1
Action Log
Text
Action Log Inf o
2.3
Determine if Alert/Notification
Ack Receiv ed/Required
If Not Ack Not Required or Ack Receiv ed
Close Log
Figure 2-40. Log Action Log (August 2000)
CHART II Business Area Architecture Report
104
January 8, 2006
CHART II Business Area Architecture Report
A prototype Actions Log screen as discussed in the workshops is illustrated below. Process
design workshop notes related to the action form are as follows:
1. The action log will be similar to the disabled log, except it will have check boxes for
signal, debris (not in travel lanes), and utility.
2. The action log will have a button for Notify that will bring up the fax/e-mail list. The
persons and agencies selected on the fax/e-mail list will be sent a copy of the action log
via the appropriate media.
Action Log
Source
Dispatched
ID
On Scene
Unit Dispatched
County
Clear Scene
Delay Cleared
Disabled Vehicle
05/14/99 12:55:45
CHART Unit On Dispatched
05/14/99 13:12:03
CHART Unit On Scene
05/14/99 13:12:45
Debris: Animal carcass on right shoulder
Save
Append
Search Log
Notify
Signal
Debris
Utility
Other
Figure 2-41. Prototype Actions Log Screen (August 2000)
CHART II Business Area Architecture Report
105
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1.3 Log Disabled Vehicle Log
The Disabled Vehicles Log process provides the user with the capability to record appropriate
information for communications received about disabled vehicles requiring assistance and the
actions taken to assist the affected motorist(s). Information relating to the make and model of the
disabled vehicle and the license plate number are radioed from the field and recorded in the log
as a safety measure for the driver. Information from the responding unit, if equipped with AVL,
may be inserted into the log by the system. This log may be operator or system initiated.
Log Disabled Vehicle Log -12/6/99
Log Comm Log
Log Ty pe - Disabled
Create Log
1
Create Disabled Log and Retrieve Log ID
Log ID
Disabled Log ID
2
Header
Store Disabled Log Header Data
Log Inf o
3
Capture Vehicle ID Inf o and Date/Time
D2
Vehicle Inf ormation
Disabled
Log
Dispatch Status
4
While Trav eller Needs Assistance
4.1
D1
Identif y Assistance Required/Prov ided and
Date/Time
Disabled Log Text
Updated Assistance Inf ormation
Disabled Dispatch Log Inf o
5
Store Log Close Timestamp
Disabled Log Inf ormation f or Storage
Close Disabled Log
Figure 2-42. Log Disable Vehicle Log (August 2000)
CHART II Business Area Architecture Report
106
January 8, 2006
CHART II Business Area Architecture Report
A prototype Disabled Vehicle Log screen as discussed in the workshops is illustrated below.
Early in the process, identification information about the Disabled Vehicle and specific location
information should be captured – this is to ensure the safety of the SHA vehicle driver. This is
radioed in when an SHA vehicle arrives on the scene and includes vehicle license plate number
and specific location such as route, direction, mile marker, lane or shoulder, etc.
Check boxes indicate the types of services performed and need to be captured to calculate
metrics. This should be designed so that input can come directly from field units via AVL or
manual entry.
Disabled Vehicle Log
Dispatched
Source
On Scene
Unit Dispatched
ID
Clear Scene
Delay Cleared
County
Disabled Vehicle
05/14/99 12:55:45
CHART Unit Dispatched
Time Stamp
Text
Save
Append
Tire Change
Directions
Hot Shot
Own Disposition
Water
Call for Service
Gas
Gone On Arrival
Search Log
Other
Figure 2-43. Prototype Disabled Vehicle Log (August 2000)
CHART II Business Area Architecture Report
107
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1.4 Log Incident Log
The Incident Log process provides the user with the capability to record appropriate information
for communications received about traffic incidents. This includes:

Time and Lane-Level Location of Incident

Type of Incident

Weather Conditions

Agencies notified

Agencies Responded

Traffic Flow and Queue Data

FITM Response
The incident log may have a sub-type of Roadwork if it was created as a response to the
activation of an EORS permit. As information pertaining to the incident is gathered, it may be
necessary to elevate the incident to a FITM incident. Once this occurs, the system allows for the
display of pertinent FITM detour information. Information from the responding unit, if equipped
with AVL, may be inserted into the log by the system. This log may be system or operator
initiated and may contain information recorded from other system devices.
CHART II Business Area Architecture Report
108
January 8, 2006
CHART II Business Area Architecture Report
L o g Com m L o g
L o g In ci d e n t L o g -1 2/6 /9 9
L o g Typ e - In c i d e n t
1
Cre a te In c i d e n t L o g & ID
In c i d e nt L o g ID
L o g ID
2
He a d e rDa ta
Sto re He a d e r Da ta
L o c a ti on Da ta
De te rmi n e L o c a ti o n
3
Ge t L o ca ti o n
Ac ti v a te L o c a ti o n Nav i g a to r
L o c a ti on
In c i d e nt Id /L o c a ti o n
4
We a th er Co n d i ti o n s
Re tri e ve We a th e r Con d i ti o n s
D3
Cl o s e st Se n s o r Da ta
Sc a n
If EOR Pe rm i t Ac ti v a ti o n
5
Re tu rn As s o c i a te d Inc i d e n t
ID
EORS
Ro a d work L o g Id
He a d e rCo m p l e te - Be g i n M a n a g em e n t
6
Wh i l e No t No rm a l Traffi c Fl o w
6 .1
L a n e Le v e l In fo rm a ti o n In p u t
He a d e ra n d L a n e L ev e l In fo
D2
Sto re Up d a te d L a n e L e v e l In fo
In c i d e nt
In te rc ha n g e
Da ta b as e
Up d a ted L a n e In fo
No ti fy with Up d a te d La n e L e v e l Info
6 .2
Id e n ti fy Re s p o n s e Re q u i re d
D1
Re s p o ns e In fo
In c i d e nt L o g
Pe rfo rm No ti fi c a ti o n
In c i d e nt Re s p o n s e
6 .3
Se t Trav e l e r In fo rm ati o n
De v i c es
No ti fy
Sh a re d Re s o u rc e s Se t
6 .4
D6
In c i d e nt L o g
Te x t
No ti fi c ati o n In fo
No ti fy an d In d i c a te
Ap p ro pri a te Re s p o nd e rs
D4
Sto re Ale rt Da ta
Al e rt Data
Al e rt Data
Re s p o nd e r In fo
Se n d Ale rt
6 .5
Awa i t Arri v a l o f No ti fie d
Re s p on d e rs
6 .6
On Sc en e In fo
Arri v a l In fo rm a ti o n
In d i c a te wh e n Re s p on s e i s
m adeon s c ene
Pro g re ss Re p o rts
Ru b b e rNe c k i n g Qu e ue L e n g th
6 .7
6 .8
Re s o u rc e In fo
Id e n ti fy Nu m b e r o f
Re s o urc e s Uti l i z e d
Cl e a ra nc e a n d Re s ou rc e
M o n i tor Ro a d a n d
Cl e a ran c e Pro g re s s
Ca l c u l ate Qu e u e L e ng th
In c i d e nt Qu e u e L e n gth
If In c i de n t d e c l a re d a FITM
6 .9
FITM De to u r Da ta
Sh o w FITM Pl a n a n d Fa x
De to u r
FITM Da ta
D5
FITM Pla n
L o g In fo
6 .1 0
No rm a l Fl o w - Sta rt Clo s e Ti m e s tam p
Re c o rd No rm a l Tra ffic Fl o w
Re tu rne d
De te c ts No rm a l Fl o w
Ha n d l e De te c to r
Ru l e s
L o g a nd Di s p o s i ti o n In fo
Cl o s e Lo g
Figure 2-44. Log Incident Log (August 2000)
CHART II Business Area Architecture Report
109
January 8, 2006
CHART II Business Area Architecture Report
A prototype Incident Log screen as discussed in the workshops is illustrated below. Other
clarifications derived at the workshops include:
1. Incident Types (in order of preferred list sequence) are:

Disabled in Roadway

PI – Personal Injury

PD – Property Damage

F – Fatality

Debris in Roadway

Roadwork

Vehicle Fire

Maintenance

Signal Call

Police Activity

Off Road Activity

Declaration of Emergency

Weather

Other
2. Hazmat is an attribute of an incident, not an incident type
3. Road opened time stamp needs to be captured
4. Roadway location graphic needs to show on/off ramps or collection lanes
5. ‘Vehicles Involved’ needs to capture number of vehicles and types
6. Form needs a section to flag ‘Special Needs’ – such as Hazmat, Medevac, signals, etc.
7. Weather will be a drop box for R1B1, expect to be auto-populated in future releases
8. ‘Resources’ section needs to show type and number of units used on site for the incident
9. List of ‘Resources’ needs to have FITM added, and change ‘ETP’ to ‘ETP/VRT’ (VRT is
MdTA Vehicle Recovery Tech)
10. Text area is for recording of which devices were activated and what was changed.
Manual entry in R1B1, expect to auto populate based on incident plans as well as manual
entry in future releases.
11. Only Entry Tab expected for Release 1, other tabs to be defined in future releases.
12. Data/Time Stamp at top is to reflect when the related Incident record is created, not when
the form is opened.
CHART II Business Area Architecture Report
110
January 8, 2006
CHART II Business Area Architecture Report
13. Special Needs section from SHA Incident Report Form (designated SHA.52.4-1) to be
included on the Incident Log
14. Dispatched, On Scene, Clear Scene, and Delay Cleared are added to the incident log.
15. There needs to be a way to determine when the normal traffic flow has resumed. One
suggestion is when the last device is returned to normal time of day operation.
16. Clicking to open/close a lane will also place text in the log with a date/time stamp.
17. In the Vehicles Involved section, there must be a way to have sub-categories, such as,

Tractor-Trailer

Jack-knifed

Overturned

Lost Load
18. When a camera is selected to verify or monitor an incident, the camera used should be
noted in the log. User should be able to identify when camera coverage of the incident
location was unavailable.
CHART II Business Area Architecture Report
111
January 8, 2006
CHART II Business Area Architecture Report
Incident Log
Dispatched
Source
On Scene
ID
Clear Scene
County
Delay Cleared
Incident Log
Entry
Response
Log
Search Location
Location
05/14/99 13:15:45
CHART unit dispatched
05/14/99 13:19:56
CHART unit on scene
05/14/99 13:22:17
Local Police on scene - Baltimore County
05/14/99 13:25:36
ETP on scene
05/14/99 13:27:51
Sand Truck on scene
Incident Type
Vehicles Involved
Weather Condition (auto)
S
N
Agencies Responded / Notified
CHART Vehicle
MDTA - Maint.
Fireboard
SHA - Maint.
Resources Notified/On Scene
Arrow Board
1
Loader
#
Dump Truck
#
P. DMS
#
Local Police
State Police
ERU
#
Sand Truck
1
MDE
MdTA Police
ETP / VRT
2
Sweeper
#
#
FITM
#
Other
#
Light Plant
Special Needs Notified/On Scene
HazMat
Investigation
Medivac
Signal Ops
Figure 2-45. Prototype Incident Management Log Screen (August 2000)
CHART II Business Area Architecture Report
112
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1.4.1 View Historical vs. Current
The View Historical vs. Current process provides the operator the capability of viewing a display
of detector data for the area of an incident. The operator may select one or more detectors in the
area and a time frame. The system will plot and display a comparison of historical data and
current data for these detectors over the selected time period. From this data display, the operator
will be able to discern information as to the severity of the blockage compared to ‘normal’ traffic
flow for the time period, and determine when traffic flow is restored to ‘normal’ conditions.
View Historical Vs Current Data (Detectors) - 9/9/99
1
List Detectors
Detector List
D3
Device
Configuration
D1
Historical Data
D2
Smoothed Data
List of Detectors
2
Select Detectors
Selected Detectors
3
Enter T ime Range
Specified T ime Range
4
Retrieve Historical
Data for Specified
T ime
Historical Data
Historical
5
Retrieve Current
Data for Specified
T ime
Detector Data
Historical vs Current
6
Plot Data
Figure 2-46. View Historical Vs. Current (August 2000)
CHART II Business Area Architecture Report
113
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1.5 Log Congestion Log
The Congestion Log provides the user with the capability to record appropriate information
relating to non-recurring congestion. When the system determines that there is congestion and
creates a congestion response plan, all information pertaining to that response is stored in a
congestion log. A system generated congestion log can be closed when the system determines
that the roadway is no longer congested. This process is operator or system initiated.
Log Comm Log
LogCongestion Log -12/10/99
Log Type - Congestion
1
Open Congestion Log
Congestion Log ID
Respond to Congestion
Alert
Congestion Response
Log Header Info
2
Retrie ve Detector
Location
D6
Detector Location
Detector
Location of Detector
3
Activate Location
Navigator
Get Location
Allow User Modification
of Location
Location Data
Location
Congestion Id/Location
4
While Not Done
4.1
Response Info
Identify Response
Required
Identified Congestion Response
D1
Congestion
Log
Actrivate Plan
4.2
Traveler Information Device Set
Plan Required
Set Traveler Information
Devices
HAR Message Needed
DMSMessage Needed
D7
Congestion
Log Text
HAR - Add a Message
DMS- Add a Message
Shared Resources Set
4.3
Notific ation Info
Perform Notification
Notify
Determine Notification
Notific ation Done
Send Alert
4.4
AlertSent
AlertInfo
Send Alert If Alert is
Required
Store Alert Data
D4
AlertData
Response Complete
5
Congestion Cleared Timestamp
Congestion Cleared
Detector Shows Congestion Cleared
Handle Detector Rules
Congestion Log for Closure
Close Log
Figure 2-47. Log Activity Log (August 2000)
CHART II Business Area Architecture Report
114
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1.6 Log Recurring Congestion Log
The Recurring Congestion Log provides capabilities for operators or the system to record actions
taken in the management of recurring congestion. It is expected that recurring congestion
conditions will be managed by activating a scheduled event at predetermined time periods. The
system will initiate a recurring congestion log at the start of a scheduled event identified for
recurring congestion. If initiated by the system, an operator may insert actions taken as
appropriate, or may revise the scheduled messages and have those actions recorded in the log by
the system. An operator may initiate and manage a recurring congestion condition by initiating a
log and taking appropriate actions.
Process Scheduled Event
Start
Log Recurring Congestion Log -12/10/99
Start Recurring Event
1
Recurring Congestion Log ID
Open Recurring
Congestion Log
Log Header Inf o
2
Start Timestamp
Store Header Data
Header/Log ID
3
While During Scheduled Ev ent
Actriv ate Plan
3.1
D1
Recurring
Congestion
Log
Trav eler Inf ormation Dev ice Set
Plan Required
Set Traveler Inf ormation
Dev ices
HAR Message Needed
DMS Message Needed
D6
HAR - Add a Message
DMS- Add a Message
Recurring
Congestion Log Text
Shared Resources Set
3.2
Notif ication Inf o
Perf orm Notif ication
Notif y
Determine Notif ication
Operator Closes Ev ent
4
Start Close Timestamp
Close Log
Recurring Congestion Log f or Closure
Close Log
Figure 2-48. Log Recurring Congestion Log (August 2000)
NOTE: Congestion Log and Recurring Congestion Logs have been implemented as one Event
type called Congestion Event in the deployed system.
CHART II Business Area Architecture Report
115
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1.7 Log Special Event Log
The Special Event Log process provides capabilities for operators or the system to record actions
taken in the management of special events. It is expected that recurring special events will be
managed by activating a scheduled event at predetermined time. A special event log may also be
initiated by an operator and manually managed. Manual alerts may be sent regarding the special
event. All shared resources used and notifications performed are logged. If initiated by the
system, a special event log will be closed at the end of the scheduled event, or it may be closed
by the operator, which will force the end of the scheduled event. If initiated by an operator, the
special event log will have to be closed by an operator.
Log Special Event Log -12/10/99
Log Comm Log
Log Type - Special Event
Special Event Log ID
1
Process Scheduled Event
Start
Start Time
Open Special Event Log
Log Header Data
Log ID
2
Get Location
Log Location
Activate Location
Navigator
Determine Location
Location
Special Event Id/Location
3
While Not Done
3.1
Response Info
Identify Response
Required
Activity Response
Actrivate Plan
3.9
D1
Log Shared Resource Usage
Special
Event Log
Plan Required
HAR- Add a Message
HAR Message Needed
Set Traveler Information
Devices
DMS Message Needed
DMS - Add a Message
Shared Resources Set
D6
Special
Event Log
Text
3.11
Log Equipment Needs
Determine Equipment
Utilization
Equip For Special Event
Perform Notification
3.2
Notification Info
Notify
Determine Notification
Notification Done
3.10
Log Alert Sent
Send Alert If Alert is
Required
Send Manual Alert
Alert Info
D4
Alert Data
Store Alert Data
Response Complete
4
Start Close Timestamp
Manual Close Log
Special Event Log for Closure
Close Log
Figure 2-49. Log Special Event Log (August 2000)
CHART II Business Area Architecture Report
116
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1.8 Log Weather Advisory Log
The Weather Advisory Log process provides the user with the capabilities to manage and record
appropriate information and actions taken pertaining to National Weather Service alerts. All
traveler information devices used are logged. Manual alerts sent and notifications performed are
also logged. This process is operator initiated and closed.
Log Comm Log
Log Weather Advisory Log -12/10/99
Log Type - Weather Advisory
1
Weather Advisory Log ID
Open Weather Advisory
Log
Log Header Data
Log ID
2
Location
Log Location Data
Activate Location
Navigator
Determine Location
Get Location
Weather Advisory Id/Location
3
While Not Done
3.1
Response Info
Identify Response
Required
Weather Advisory Response
Actrivate Plan
3.9
D1
Plan Required
Weather
Advisory
Log
Log Shared Resource Usage
D6
Set Traveler Information
Devices
HAR - Add a Message
HAR Message Needed
DMS Message Needed
Weather
Advisory
Log Text
DMS Display a Message
Shared Resources Set
3.2
Perform Notification
Notify
Notification Info
Determine Notification
Notification Done
Send Manual Alert
3.10
Log Alerts
Alert Info
Send Alert If Alert is
Required
D4
Store Alert Data
Alert Data
Response Complete
4
Weather Advisory Log Info for Storage
Close Log
Close Log
Weather Advisory Log ID for Closure
Figure 2-50. Log Weather Advisory Log (August 2000)
CHART II Business Area Architecture Report
117
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1.9 Log Weather Sensor Log
The Weather Sensor Alert Log process provides capabilities to record information pertaining to
inclement weather detected by the weather sensor devices and the response actions taken to
manage the situation. This log is initiated when data from the weather sensor devices are
evaluated against thresholds and found to be non-normal, and a weather sensor alert is generated.
A response plan for the weather sensor alert is created and, if operator approval is requested and
received, the response plan is executed. All traveler information devices used to notify the public
of the current weather conditions is logged. Notification performed and manual alerts sent are
also recorded. This process is system initiated and will be closed by the system when data from
the sensors reflect normal conditions. This log may also be closed by an operator, which will
force the deactivation of the response plan and should disable sensor detection for some
operator-specified period of time.
CHART II Business Area Architecture Report
118
January 8, 2006
CHART II Business Area Architecture Report
Log Weather Sensor Alert Log -12/10/99
Respond to Weather
Sensor Alert
Response Plan
Weather Sensor Log ID
1
Open Weather Sensor
Log
Log Header Data
Log ID
3
While Not Done
3.1
Response Info
Identify Response
Required
Weather Sensor Response
Actrivate Plan
3.9
Log Shared Resource Usage
D1
Weather
Sensor
Log
D6
Plan Required
Set Traveler Information
Devices
HAR Message Needed
DMS Message Needed
Weather
Sensor
Log Text
HAR - Add a Message
DMS - Add a
Message
Shared Resources Set
3.2
Notification Info
Perform Notification
Notify
Determine Notification
Notification Done
Send Manual Alert
3.10
Log Alerts
Alert Info
Send Alert If Alert is
Required
Store Alert Data
D4
Alert Data
Response Complete
Log Closure Data - Timestamp
4
Weather Within Normal
Parameters
Weather Normal - Alert Ended
Handle Weather Sensor
Data
Weather Sensor Log for Closure
Close Log
Figure 2-51. Log Weather Sensor Log (August 2000)
CHART II Business Area Architecture Report
119
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1.10
Log Safety Message Log
The Safety Message Log process provides the capabilities of recording appropriate information
pertaining to the display and/or broadcasting of safety messages. Safety messages can be set for
display using the scheduler, in which case the system will initiate the safety message log. This
log can be operator initiated and messages may be displayed or broadcast by activating a safety
plan or manual selection of devices. All traveler information devices used are logged. If system
initiated, this log will be closed at the end of the scheduled event. An operator may also close
this log before the end of the scheduled event, which will force the early closure of the scheduled
event. If operator initiated, an operator must close the log.
Log Safety Message Log -12/10/99
Log Comm Log
Log Ty pe - Saf ety
1
Saf ety Log ID
Open Saf ety Log
Start Saf ety Schedule
Process Scheduled Event
Start
Open Log ID
2
Start Timestamp
Store Header Data
D1 Saf ety Log
Header Data/Log ID
3
While Not Done
Activ ate Plan
3.1
D6 Saf ety Log
Text
Log Shared Resource Use
Plan Required
HAR Message Needed
Set Traveler Inf ormation
Dev ices
DMS Message Needed
HAR - Add a Message
DMS - Add a Message
Shared Resources Set
4
Saf ety Log Inf o for Storage
Close Log
Saf ety Log for Closure
Manual Close Log
Figure 2-52. Log Safety Message Log (August 2000)
CHART II Business Area Architecture Report
120
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1.11 View Log
The View Log process allows an operator to select and view all information relating to the
selected log including start/end timestamp, operator and system generated actions, and response
data. This view of a log must be capable of displaying all log data and to include data captured
under various log types during the progression of the life of the log.
View Log - 12/6/99
1
List Logs
Logs
Selected Log Id
2
D1
Log
Log Data
Select Log
Formatted Log Data
3
Display Log
Figure 2-53. View Log (August 2000)
CHART II Business Area Architecture Report
121
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.1.12 Close Log
The Close Log process stores appropriate information about the closure of the incident and
activity logs, releases shared resources (DMS and HAR) related to the log, and initiates the
sending of notifications to appropriate personnel and organizations. If an incident log was related
to road construction (an EORS permit), closure information is sent to the EORS system. Two
closure date/time stamps are maintained for logs. One is the time the operator or system indicates
that the situation is restored to normal; the second is when the system completes all of its closure
activities.
Closure may be operator or system initiated. Detector or sensor data may indicate the end of a
traffic or roadway situation and initiate closure of a related log. Operators may close a log when
the roadway is restored to normal traffic flow or the situation being managed is over.
Detector and sensor processing may not close a log that was initiated by an operator.
CHART II Business Area Architecture Report
122
January 8, 2006
CHART II Business Area Architecture Report
1
Add Text Line - Start Close
Log
Close Log -12/10/99
Log Start Close
Close Log Selected
2
Generate Log Close
Timestamp
Log Close Timestamp
Close Timestamp
3
Close Log Form on Screen
DMS - Remove a
Message
Remove DMS Message
Shared Resources in Use
4
Release Associated Resources
HAR - Remove a
Message
4.1
Remove HAR Message
Release Resources
Log Release of Resources
D1
Devices Off
4.2
D3 Detectors
Log ID
Release Associated
Detectors and Sensors
Sensor
D4
Log
Pavement
Sensors
Log Release of Devices
Devices Released
4.3
Update Shared Resource
Status
Log Resource Status
Send Notification
Perform Notification
Close Log Notification
5
Send Incident Close
Notification
Log Notification
Notification has been sent
If Construction Type Incident
7
6
Send Close to EOR
Generate Log Completed
Timestamp
Log Completed Timestamp
Close Permit Data
Incident Closed
8
EOR
If Incident -Remove Incident
Icon from Map
Figure 2-54. Close Log (August 2000)
CHART II Business Area Architecture Report
123
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.2
Location Navigation
The Location Navigation processes are intended to provide operators with a tool to aid in
pinpointing the location of an incident for entry on the Incident Log. This is accomplished by
building a database of map coordinates for landmarks, exits, intersections, etc. for each highway.
This provides a user interface allowing the user to search and select appropriate information in
the database and position a cursor on a map display based on the stored map coordinates. The
operator should be able to move the initial cursor position to better match the received
information (ex: 1000 yards north of Exit 12, second lane) and then indicate that this is the
position recorded in the Incident Log.
2.2.4.3.2.1 Maintain Location Navigation Data
The Maintain Location Navigation Data process provides the capabilities to build and maintain
the database of map coordinates for landmarks, exits, intersections, etc. for each highway. Map
coordinates need to be easily recorded for each item to match the CHART map system.
CHART II Business Area Architecture Report
124
January 8, 2006
CHART II Business Area Architecture Report
Maintain Location Navigation Data - 7/28/99
19
Need to Maintain
Navigation Data
Modify or Delete Chos en
12
Lis t Major
Highway s
Highway Lis t
Add a New Highway
Lis t of Highway s
13
Select Highway
Highway to Delete
Highway to Modify
22
21
20
Modify a Highway
Add a Highway
D1
Loc ation
Navigation
Info
Delete a Highway
Highway for deletion
Need to maintain as s ociated data
Need to maintain As s ociated Info
11
Delete As s ociated
Loc ation Data
23
While not Done Adding/Modify ing a Highway
23.2
As s oc iated Data
Modify As s oc ia ted Data
23.1
Add New
As s oc iated Data
23.3
Delete As s oc ia ted
Data
High and as s oc iated data for dele tion
Highway and As s oc iated data for s torage
10
Loc ation Nav ig ation Info
Store Loc ation Data
Loc ation Data for log
29
Log Sy s tem Operation
***Ass oc iated Data c an be Landmark s , Exit Numbers ,
Cross Streets, or Mile Mark ers
Log Data
D2
Operation Log
Figure 2-55. Maintain Location Navigation Data (August 2000)
CHART II Business Area Architecture Report
125
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.2.2 Activate Location Navigator
The Activate Location Navigator process is activated from the Incident Log. This process allows
the operator to select the highway where the incident is located and then displays a list of
associated data (landmarks, exits, intersections, etc.) for that highway. Additionally, the location
of CHART vehicles as identified by the AVL devices should be available for the operator to
select to identify the location. The operator selects a landmark, exit, intersection, or AVL from
the list and the system displays a movable cursor on the map indicating the location of this item.
The operator manipulates the map zoom levels and the cursor to pinpoint the appropriate road
segment. When satisfied with the position, the road segment is captured and displayed on the
Incident Log, Disabled Vehicle Log, Congestion Log, or Action Log.
Implementation Considerations: this process is critical to saving operator data entry time and
there is much interest in its implementation. Prototyping this process with the SOC operators
should be planned for.
CHART II Business Area Architecture Report
126
January 8, 2006
CHART II Business Area Architecture Report
Activa te Locatio n Navigato r - 8/10/99
1
List M ajor
Hig hways
Hig hwayL ist
Hig hways
2
Select Hig hway
Selected H ighway
Associated Data List
3
List Assoc iated
Data
Associated data
D1
4
Select
Associate d
Data
Locat ion
Navig ation
Info
Selected Assoc iated Data
5
Retr ieve
Coor dinat es
Coor dinate s
Locat ion
6
Displ ay
Loca tion on
M ap
Retur n dat a
7
Retur n
Loca tion Data
and
Lane -Level Info
Figure 2-56. Activate Location Navigator (August 2000)
CHART II Business Area Architecture Report
127
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.3
Queues
The Queues process group contains a single process that calculates or records queue lengths
related to a specific Incident Log. This process aids the operator in providing queue length
information required on the Incident Log.
2.2.4.3.3.1 Calculate Queue Length
The Calculate Queue Length process either calculates queue lengths based on detector data or
provides operators with a means to manually enter queue length data. Two types of queue lengths
are calculated for each Incident Log: in the direction of the roadway having an incident, and in
the opposite direction due to ‘rubber-necking’. Where multiple detectors are installed along the
roadway, detector data will be evaluated to determine the length of the queue in each direction
and displayed on the Incident Log. Where only one detector is available downstream from the
incident (either direction), the queue length will be calculated to that detector and captured and
displayed on the Incident Log. This process will have the capability for the operator to enter data
and override the calculated queue length, or to record a queue length when no detectors are
available.
Once activated by the operator – and until overridden – the queue length will be periodically
updated based on the frequency of polling of detector data.
CHART II Business Area Architecture Report
128
January 8, 2006
CHART II Business Area Architecture Report
Log Incident
Log
Calculate Queue Length - 8/30/99
RubberNecking Direction
Need Queue Length - Incident Direction
1
Manual Entry
No Detector Data Available
Retrieve Detector Data
Within Predefined Distance
Detector Data Closest to Incident
3
While Detectors Available Show Queue
Detector Data Returned
3.1
D1
Smoothed
Detector Data
Detector Data
Retrieve Detector Information from
Next Closest Detector
Only 1 Detectors Within Distance
Queue Length data
4
8
Calculate Distance from First
Detector To Last in Queue
Calculate Queue
Based on Single
Detector Data
Queue Length
6
Update Queue Length Display in
Log
Log Queue
Queue Length For Storage
Store RubberNecking Direction
D2
5
Queue Data
Store Queue Length
Queue Data
Operations Log Info
7
Log Operations Log
Log Info
D3
Operations Log
Figure 2-57. Calculate Queue Length (August 2000)
CHART II Business Area Architecture Report
129
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.4
Notification
The Notification process group includes those processes necessary to maintain a list of
individuals to be notified when specific actions/activities are processed in the system. It also
contains the capabilities to determine which individuals are notified for which system actions
and by which method. Methods of notification include Fax, E-Mail and Paging.
2.2.4.3.4.1 Maintain Notification List
The Maintain Notification List process maintains a database of groups of individuals or
organizations to be notified, their method of notification (and the details for accomplishing that
method), and those system processes/functions for which they are to be notified. The database
and maintenance capabilities will be designed to support the following:

Maintenance of groups

Maintenance of individuals or organizations and the necessary data for performing the
Fax, E-Mail or Paging notification for each individual or organization

The capability to assign individuals or organizations to one or more groups

The capability to assign one or more groups to specific system processes or functions
which require a notification capability
CHART II Business Area Architecture Report
130
January 8, 2006
CHART II Business Area Architecture Report
Maintain Notification List -9/23/99
1
Need to
Maintain List
Modify/Delete Data
2
List Notification
Groups
Notification Group List
List Groups
Add a New Group
12
3
Select Group
Group to delete
Is Group/Person in
a Plan/Schedule
It IS Used in Plan/Schedule
13
Group to Modify
Notification
Data
D1
4
5
Add a Group
Modify a Group
Add Associated Data
Delete Reference
from Plan/Schedule
Maintain Associated data
NOT Used in Plan/Schedule
8
While Not Done Adding/Modifying a Notification
Group
8.1
Maintain Associated Data
6
Delete a Group
Notification Group
Store Update
Delete Associated Data
7
Store Updated Notification Data
10
Store Notification
Data
Store Change
Delete Associated
Notification Data
Notification Data for Log
D2
Operations
Log
Log Data
11
Log System
Operation
Associated Data can be one or more methods of
notifying a center, an organization, or a person and the
required data, such as fax number or e-mail address.

Figure 2-58. Maintain Notification List (August 2000)
CHART II Business Area Architecture Report
131
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.3.4.2 Perform Notification
The Perform Notification process is activated from other system processes. The process receives
type of notification and notification-specific information from these other processes. Based on
the type of notification, the specific group(s) is selected. A notification is formatted for the
method to be used for that individual or organization in the group(s). Based on the method of
notification, notification-specific information and method-specific information is passed to the
appropriate supporting COTS application that performs the actual transmission and return a
success or failure result. If the notification is related to a Log, individual level notification
successes and failures are recorded in the related Log. Individual level notification successes and
failures are recorded in the Operations Log.
For the Incident Log, media and private-sector traffic information services are advised of current
incidents through their querying of the Incident Interchange Database. This Perform Notification
process could also provide additional notification.
CHART II Business Area Architecture Report
132
January 8, 2006
CHART II Business Area Architecture Report
Incoming Info
Notification Needed-Name & Msg Type
Pe rfo rm No ti fi c a ti o n - 8 /2 3 /9 9
1
Receive Notification Nameand
Message Type fromExternal Agent
Name
3
D1
Notification List
Determine
Notification
Methods
Notification Data
Type -E-Mail/Page/Fax and Number or Address
7
For Each Recipientin Notification List
7.2
Retrieve Notification Methods and Address or Number
Send Page
Send Fax
Send E-Mail
7.4
Page
7.6
Fax
Page COTS
FormatPage
7.5
Fax COTS
FormatFAX
FormatE-Mail
ReturnPage Status
ReturnFax Status
Page OK
Fax Failed
Fax OK
E-MailOK
E-MailFailed
Page Failed
ReturnE-Mail Status
E-Mail
E-MailCOTS
13
6
Add Notify Failure
Text toany
Associated Log
Add Notify Successful
Text inAny Associated
OpenLogs
Failure
Success
5
Log System
Operation
Log Info
D2
Operations Log
Figure 2-59. Perform Notification (August 2000)
CHART II Business Area Architecture Report
133
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4 Shared Resource Management
The Shared Resource Management processes include all those processes necessary to define,
setup, and control the monitoring, verification, and traveler notification aspects of the CHART II
system. These processes are divided into groups related to DMS, HAR, AVCM, Detectors,
Equipment, Signals, and AVL. The following figure identifies the individual processes within
each group.
CHART II Business Area Architecture Report
134
January 8, 2006
CHART II Business Area Architecture Report
Shared Resource Management-12/16/99
1
SharedResource Management
1.1
DMS/HAR Common Processes
1.2
DMS Processes
1.3
HAR Processes
1.4
AVCM
1.6
Detectors
1.7
Signals
1.8
AVL
1.1.1
Maintain
Acceptable Word
Dictionary
1.2.1
Maintain DMS
Message Library
1.3.1
Maintain HAR
Message Librsry
1.4.1
Maintain Wall
Monitor
Configuration
1.6.1
HandleDetector
Data
1.5.1
Maintain
Equipment
Inventory
1.7.2
HandleSignal
Polling Data
1.8.3
HandleAVL
Polling Results
1.1.2
Maintain
Unacceptable
WordDictionary
1.2.2
DMS-Add a
Message
1.3.2
HAR -Add a
Message
1.4.2
Control Wall
Monitor
Assignment
1.6.2
HandleDetector Rules
1.5.2
Maintain
Equipment Status
1.7.3
Respond to
Exceeded
Volume
Threshold Alert
1.1.4
Perform
Responsibility
Reminder
1.2.3
1.3.4
1.4.3
DMS -Remove a
Message
HAR -Remove a
Message
Maintain CCTV
Presets
1.5
Equipment
1.6.2.1
Generate
Congestion
Response
1.6.2.3
1.5.3
Alert for
Delinquent
Equipment Status
1.7.1
Download Traffic
Counts
Respond to
Congestion Alert
1.4.4
1.1.5
Respond to
Responsibility
Reminder Alert
1.2.14
1.3.5
DMS -Arbitrate
Message Queue
HAR -Arbitrate
Message Queue
Refresh Default
AVCMPresets
1.6.2.2
1.8.1
PerformAVL Function Processing
1.8.1.1
Process AVL
In/OutService
Message
1.8.1.2
Process AVL
Mayday Message
1.5.4
Respond to
Delinquent
Equipment Status
Alert
1.8.1.3
Generate Incident
Response
Process AVL On
SceneMessage
1.6.2.4
Respond to
Incident Alert
1.8.1.4
Process AVL
Assist Disabled
Message
1.6.2.5
Activate
Response Plan
1.8.1.5
Process AVL
Available
Message
1.4.5
1.2.15
1.3.13
DMS -Evaluate
Queue
HAR -Evaluate
Queue
1.2.16
DMS -Send a
Message
1.3.12
HAR -Broadcast
a Message
Activate Tour
1.2.17
DMS -Blank a
Sign
1.3.11
HAR -Broadcast
Default Message
Control Camera
1.2.4
1.3.10
DMS -Reset
HAR -Set
SHAZAM On/Off
Maintain Tours
1.4.6
1.4.7
1.8.2
Respond to AVL Alerts
1.2.18
1.3.9
DMS -Restore
Message
HAR -Update
Default Message
1.2.19
1.3.8
HAR -Send
Maintenance
Command
DMS -Override
1.8.2.1
Respond to
Arrival On Scene
Alert From AVL
1.8.2.2
Respond to
Disabled Vehicle
Alert From AVL
1.8.2.3
Respond to
Mayday Alert
From AVL
1.3.7
HAR -Restore
Message
1.3.6
HAR -Override
Queue
Figure 2-60. Shared Resource Management(August 2000)
CHART II Business Area Architecture Report
135
January 8, 2006
CHART II Business Area Architecture Report
DMS and HAR device processes include message arbitration processes which maintain a
message priority queue for each DMS and HAR device and determines which message is to be
displayed or broadcast at any point in time. In the default state, each device will be blank or
broadcasting a default message and its queue will be empty.
As messages are requested for display or broadcast on a specific device, they are added to that
device’s queue. Based on priorities, the highest priority message that exists for a device is
displayed or broadcast at all times. Any lesser priority messages remain in the queue for display
or broadcast when the higher priority message(s) is de-activated.
Messages in the queue are related to specific logs. Any one log will have only one message in a
device queue at any one time.
Messages are de-activated in the queue when a blank command is sent to the device from the
related log. If the highest priority message in the queue is blanked, the next highest is displayed
or broadcast. The blanking of all messages in a queue makes the queue empty and the last
message blanked causes the device to be set to its default state.
A scheduled message is placed in its appropriate level in the queue upon scheduler event
activation start-time and removed upon scheduler event end-time and displayed or broadcast
whenever it is the highest priority in the queue.
Message priorities are to be based on system parameters so that changes in the priorities may be
effected without re-coding. Per workshop discussions, the following sequence of message
priorities were agreed to as a starting configuration for DMS devices:
Sequence
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Message Type
Incident
Incident
Roadwork
Congestion
Weather Alert
Special Event (High Priority)
Recurring Congestion
Congestion
Weather Alert
Special Event (Low Priority)
Recurring Congestion
Safety Message
Safety Message
SHAZAM (DMS only)
SHAZAM (DMS only)
Operator/System Control
Operator
System
Operator
Operator
Operator
Operator
Operator
System
System
System
System
Operator
System
Operator
System
A discussion topic of the process design workshops involved allowing the display of two
separate one-page messages. This would allow the alternating display of the two highest priority
one-page messages. It was decided that devices will be configurable to allow: no multi-page
messages, two incident related messages, or one incident and one roadwork two-page message.
CHART II Business Area Architecture Report
136
January 8, 2006
CHART II Business Area Architecture Report
Message priorities for HAR are handled differently in that, as the broadcast time limit allows,
high priority messages will be concatenated and broadcast. The queues for the HAR devices
therefore act as sorters to indicate the sequence of messages to be considered for concatenation.
The priorities for HAR messages should be very similar to the table shown above (excluding the
SHAZAM messages) but should have their own set of system parameters to allow for variances.
2.2.4.4.1
DMS/HAR Common Processes
The following set of processes is common to both DMS and HAR devices.
2.2.4.4.1.1 Maintain Acceptable Word Dictionary
The Maintain Acceptable Words process maintains a central dictionary of words or phrases
allowable in DMS (Dynamic Message Signs) and HAR (Highway Advisory Radio) messages.
This dictionary is used in the validation of library or ad hoc messages for both DMS and HAR
devices.
Maintain Acceptable Word Dictionary -10/6/99
1
Open Acceptable Word
Dictionary for Editing
Dictionary Word List
2
Dictionary
Add/Update/Delete a Word
Updated Acceptable Word List
3
Save Acceptable Word
Dictionary
Updated Dictionary
D1
Acceptable
Word Dictionary
Log Change
4
Log System Operations
Log Data
D2
Operations Log
Figure 2-61. Maintain Acceptable Words (August 2000)
CHART II Business Area Architecture Report
137
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.1.2 Maintain Unacceptable Word Dictionary
The Maintain Unacceptable Words Dictionary process maintains a central dictionary of words or
phrases not allowed for use in DMS and HAR messages. This dictionary is used in the validation
of library or ad hoc messages for both DMS and HAR devices.
Maintain Unacceptable Word Dictionary -10/6/99
1
Open Unacceptable Word
Dictionary for Editing
Dictionary Word List
2
Dictionary
Add/Update/Delete a Word
Updated Banned Word List
3
Save Unacceptable Word
Dictionary
Updated Dictionary
D1
Unacceptable
Word Dictionary
Log Operations
4
Log System Operations
Log Data
D2
Operations Log
Figure 2-62. Maintain Unacceptable Words (August 2000)
CHART II Business Area Architecture Report
138
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.1.3
Perform Responsibility Reminder
The Perform Responsibility Reminder process is used to notify operators at the responsible
center if a log is opened past the timeframe that has been set in the system parameters. In
responding to a responsibility alert, the operator may specify a different reminder timeframe for
determining when to send the next alert. If the reminder alert remains unacknowledged, the alert
will be escalated.
Perform Responsibility Reminder-12/6/99
1
For Each Log That Needs a
Reminder
1.1
D7
Log
Updated Time to Remind
Determine if Time
to Remind
Default Time to Remind
D1
System
Parameters
Log Alert Data
D6
Alert Data
Reminder Data for Alert
Send Alert
Figure 2-63. Perform Responsibility Reminder (August 2000)
CHART II Business Area Architecture Report
139
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.1.4 Respond to Responsibility Reminder Alert
The Respond to Responsibility Reminder Alert process allows the person receiving the alert to
either cancel the reminder and thus close the associated log, or update the reminder timing. If the
user wants to update the reminder timing, there will be a place in the log to lengthen the timing
so the reminder will not come up as often. Once the reminder information is updated, the
information is saved and the change to the reminder timing is recorded in the Operations Log.
Respond to Responsibility Reminder Alert-12/6/99
1
Acknowledge
Alert
Alert Data
D1
Alert Data
D2
Log
Date/Time & User
Alert Ackd
2
Read Log Data
Open Log
Update Log
Log Opened
3
User Closes or
Updates Log
Update Reminder Time
4
Update Time to
Be Reminded
Again
Cancel Reminder
Reminder Updated
5
Cancel
Responsibility
Reminder
6
Log System
Operation
Reminder Cancelled
Close Log
Log Data
D6
Operations
Log
Figure 2-64. Respond to Responsibility Reminder Alert (August 2000)
CHART II Business Area Architecture Report
140
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.2
DMS Processes
The DMS Processes group allows for the System Administrator to maintain the acceptable and
unacceptable words dictionary for the DMS displays, as well as maintain a central message
library. The CHART operators are able to display and blank messages on the DMS devices and
also reset the devices as needed.
2.2.4.4.2.1 Maintain DMS Message Library
The Maintain DMS Message Library process provides for the centralized creation and
maintenance of message text and beacon control for pre-defined DMS messages. The system
may provide multiple physical libraries to allow organization of messages into logical topic
groupings (construction, incident, events, weather, special, safety, etc), and to reduce the effort
for disbursing changes to message libraries across the system.
The following information is needed for each DMS stored message:

Message ID – The message ID uniquely identifies each stored message.

Message Name – Each message has a name, the text for display on the DMS, and the sign
length capable of displaying the message.

Message Text

Topic/Category – Each message is associated with a category within the library. For
example, under the Weather library, messages may be categorized as Snow, Ice, Freezing
Bridges, etc. The combination of library topic and message category provides the means
to organize messages when displayed in the navigator.

Sign Length – Each message has a maximum sign length allowed based on the size of the
sign to be used.

Beacon Indicator – Each stored message has a flag indicating whether beacons are set
on/off.
Some messages may be designated as ‘sign specific,’ meaning that the message is only to be
displayed on the indicated DMS. Displaying this message on any other sign will not make sense
to travelers.
The algorithm to determine if the message will fit on a sign should be run when storing a
message If the message will not fit on a certain sign, the system should alert the administrator so
another message can be stored for the smaller signs.
At some point, the system will be required to take advantage of all functionality of the signs,
including graphics. The system should be designed with this expansion in mind.
CHART II Business Area Architecture Report
141
January 8, 2006
CHART II Business Area Architecture Report
Maintain DMSStored Mes s age Library - 12/9/99
13
1
Delete Mes s age from Databas e
Delete Mes s age Selec te d
Need to Maintain Mes s ages
D5
7
Update Mes s age Selected
Determine Mes s age Name
Plan
DMSMes s age
Add Mes s age Selec ted
8
15
Determine if Sto red Mess age is
Us ed in a Plan or Sc hedule
Lis t Stored
Mess ages
Plan Information
Sc heduler Information
D6
Sc heduler
Data
Mes sage Lis t
Stored Mes s age Lis t
If NOT in Plan/Sc hedule
Plan for Deletion
9
Select Mes s age
Selected Mes sage
Item fo r Deletion
If it ISin Plan or Sc hedule
Add Mes s age
Mes sage for Update
16
12
While All Sign Dimens ions Not Handled-if needed
DMSMes s age to Delete
Confirm Delete Referenc e to
Mess age fromPlan or
Sc hedule
12.1
While Adding/Modify ing Mes s age
12.1.2
Modify or Ty pe Tex t of
Mess age
Updated Mes sage
12.1.5
Select Beac on Status
Beacon Status/Mes s age
D2
12.1.4
Validate Mes sage
Ac c eptable/
Unac c eptable
Word Dic tionary
D1
DMS
Mess age
Library
Ac c eptable-Unac c eptable Words
Verifie d Ms g
12.1.6
Determine Poss ible
Dimens ions
All Pos s ible Dimens ions
D3
DMS
Mes sage & Beac on for Storage
12.1.3
Store Updated Mes s age
Updated DMSMes s age
Log Stored Mes s age Lib rary Change
14
Log Sy s tem
Operation
Log data
D4
Operations Log
Figure 2-65. Maintain DMS Message Library (August 2000)
CHART II Business Area Architecture Report
142
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.2.2 DMS – Add a Message
The DMS – Add a Message process provides the capabilities for operators to select one or more
DMS devices, select or enter a message to be displayed, and add the message to the DMS
message arbitration queues of the selected devices. Beacon status is related to a message and is
also reflected in the queues. The associated log is updated to record the addition of a message to
a device message queue. After adding a message to the queue, message arbitration is performed
to determine if the change has affected which message(s) should be displayed on the sign.
The following comments were recorded in the process design workshops:
1. Error checking regarding what is on the sign versus what the system last sent to the sign
should be done at a very low level. If polling results are only returned to the Chart II
system on an exception basis from the FMS system, FMS may provide the error checking
capability.
2. At some point, the system will be required to take advantage of all functionality of the
signs, including graphics and complete diagnostics. The system should be designed with
expansion in mind.
3. The system must be able to allow selected users to override/ignore the Acceptable Word
Dictionary.
CHART II Business Area Architecture Report
143
January 8, 2006
CHART II Business Area Architecture Report
1
List DMS Devices
D3
DMSs
DMS
DMS List
2
DMS: Add Message - 12/9/99
Select DMS
Devices
Selected Devices
Manual Message Selected
12
Stored Message Selected
Determine if Stored
Message or Manual
Message
D1
Unacceptable
Word
Dictionary
4
List Stored
Messages
Manual Message
Unacceptable Words
Acceptable Words
D2
3
Enter Text
Message
Not Validated
D4
DMS Stored
Message
Library
Stored Message List
6
5
Spell Check and
Validate Text
Message
Select Stored
Message
Validated Message
Acceptable
Word
Dictionary
Stored Messages
Message
7
8
Determine
Beacon Status
Verify Message
Format
Prepared Message and Beacon
10Status
Verified Message
For Each DMS Selected
10.1
Send Message
to Queue
Message/DMS ID/Priority
Perform DMS
Message Arbitration
Figure 2-66. DMS – Add a Message (August 2000)
CHART II Business Area Architecture Report
144
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.2.3 DMS – Remove a Message
The DMS – Remove a Message process provides the capabilities for operators to select a DMS
devices (as related to a log or from a list of all devices), display the DMS message arbitration
queue for the selected device, and remove a message from that queue. The log associated with
the removed message is updated to record the removal of the message. After removal of a
message from the queue, message arbitration is performed to determine if the change has
affected which message(s) should be displayed on the sign.
DMS - Remove a Message - 12/9/99
1
List DMS Devices
DMS List
D1
DMS
Device List
2
Select DMS
Device
Sekected DMS
3
List Current
Messages
Messages in Queue
D3
DMS Message
Arbitration Queue
Message List
4
Select Messages
Selected Messages
5
For Each Message Selected
5.1
DMS ID/Priority/Slot #
Perform DMS Message
Arbitration
Flag Message for
Removal
Figure 2-67. DMS – Remove a Message (August 2000)
CHART II Business Area Architecture Report
145
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.2.4 DMS – Arbitrate Message Queue
The DMS – Arbitrate Message Queue process maintains a message priority queue for each DMS
device. When messages are added to the queue, this process adds or updates the correct priority
level with the message information. Once the queue has been manipulated it is evaluated.
Each message in the queue is related to a specific log. Any one log will have only one message
in a device queue at any one time.
The operator can remove messages from the queue manually or the system will remove all
messages associated with a log when the log closes. The log is updated whenever an item is
added or removed from the queue.
A scheduled message is placed in the appropriate priority level in the queue upon scheduler
event-activation and removed upon scheduler event end-time.
CHART II Business Area Architecture Report
146
January 8, 2006
CHART II Business Area Architecture Report
DMS - Add a
Message to the
Queue
Process Scheduled
Event Start
Activate Plan
DMS - Arbitrate Message Queue - 12/9/99
DMS ID/Log ID/Message/Sched Priority/Beacon
DMS ID/Log Id/Message/Priority/Beacon
DMS Id/Log Id/Message/Log Priority/Beacon
1
Log ID In Use-Update Message
Process Scheduled
Event End
Close Log
Evaluate Message Log ID and
Queue
Queue Data
DMS - Remove a
Message From Queue
DMS ID/Log ID/Priority
New Message- Add to Queue
DMS ID/Priority/Log ID #
Log ID/DMS ID/Priority
2
3
Update Message in Queue
Add New Message to Queue
D1
DMS Id #/Priority/Log Id
DMS
Message
Arbitration
Queue
Added Message
Updated Message
5
9
Store Queue Change
DMS ID/Priority/Log ID
Remove Message from the Queue
Update Queue
D5
Log
Log Deletion
Log Change in Queue
Record Queue Modification
11
Log Message
Modification In Queue
Queue Modification
D2
4
Operations Log
Log Data
Log System Operation
Update of Queue
DMS - Evaluate Queue
Figure 2-68. DMS – Arbitrate Message Queue (August 2000)
CHART II Business Area Architecture Report
147
De-Activate Plan
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.2.5 DMS – Evaluate Queue
The DMS – Evaluate Queue process determines which message(s) should be displayed on the
device. Each time the queue is manipulated, the messages are re-evaluated. If the result of the
evaluation is different from what is currently displayed, the message(s) for display is marked as
pending and it is sent to the device. If the queue is empty the sign is blanked. There may be
multiple messages at each priority level related to different logs. The highest priority message(s)
is always displayed.
CHART II Business Area Architecture Report
148
January 8, 2006
CHART II Business Area Architecture Report
PerformDMS Message Arbitration
Queuehas been Modified/Device ID
DMS:Evaluate Queue - 12/15/99
1
Retrieve Current Device State
DeviceState Online/Offline
D3
DMS
DeviceState
2
Retrieve Queue andCurrent
Display
Queueand CurrentDisplay
Queue
3
Determine if Queueis Empty
DMS -Blank a Sign
If Empty and Device State Online
QueueNot Empty
4
Determine HighestPriority
If MoreMessage inQueue
5
Determine Next Highest Priority
D1
DMS
Message
Arbitration
Queue
If NextHighest is Incident-Special Event or Roadwork
If No More Messages in Queue
6
Mark as Page 2
2 PageMessage
7
Compare to Previous Display
If Different from Previous Display
8
Mark as Pending
Pending Display
If Device State Online - CurrentDisplay LogIDs/PendingDisplay LogIds
DMS-Send a Message
Figure 2-69. DMS – Evaluate Queue (August 2000)
CHART II Business Area Architecture Report
149
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.2.6 DMS – Send A Message
The DMS – Send a Message process provides the capability to initiate the interface with FMS to
allow the message to be displayed on the selected device. Beacon status is related to a message.
If the process indicates turning on or turning off the beacons when the selected message is
displayed, this process also initiates the beacon controls through FMS to ensure the message is
displayed before the beacons are turned on. Message arbitration is performed before any message
is sent to the DMS. Once the message is displayed on the sign and the return status received from
FMS that the command has been successful, the log associated with the message will be updated
to reflect the new display status. The queue will be marked to show the message is currently
displayed and no longer pending.
DMS - Restore Message
DMs - Evaluate Queue
DMS - Send a Message - 12/9/99
DMS ID/Log IDs/Message/Beacon
DMS ID/Log IDs/Message/Beacon State
1
Format DMS Message
Command for FMS
4
Formatted Command
Command/Log Id
FMS
Beacon Data
Send Command to FMS
Return Status/Log ID
2
If Needed Change Beacon
State
Beacon Command
Command Successful
Command Failure
3
6
Log System Operation
Log Data
D1
Operations Log
Failure Data
Log Failure
Update Navigator/Map
Notify User of Failure
5
7
Update Device Status
Notify User
For Successful Display
8
For Each Log ID
8.1
Update Display Status in
Log
Log ID/Message/Display Status
D2
Log
Update Queue
8.2
Update Pending Mark to
Display in Queue
DMS ID/Log ID/Display State
D3
DMS Message
Arbitration
Queue
Figure 2-70. DMS – Send A Message (August 2000)
CHART II Business Area Architecture Report
150
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.2.7 DMS – Blank A Sign
The DMS – Blank a Sign process provides the capability to initiate the interface with FMS to
blank the selected device. If the beacon is currently on, this process initiates the beacon controls
through FMS to ensure the beacons are turned off before the message is blanked. Once the
message is blanked and the return status received from FMS indicates that the command has
been successful, the operations log is updated to record a successful operation. Should the
command fail, the fact is written to the failure log. The device status is updated as appropriate.
(The log associated with the message is updated to reflect the actual time stamp of when the
message was removed from the sign.)
DMS - Evaluate
Queue
DMS - Blank a Sign - 12/9/99
DMS ID
1
Format Blank DMS
and Beacon Off
Commands for FMS
Formatted Command
2
Command
Send Command to
FMS
FMS
Return Status
Command Success
Command Failure
3
5
Log System Operation
Log Data
D1
Operations
Log
Update for Navigator/Map
Log Failure
Failure Data
Failure Notification
4
6
Update Device Status
Notify User
2.2.4.4.2.8 DMS Reset (August 2000)
The DMS Reset process allows an operator to force a reset of one or more DMS devices, which
is sometimes necessary to overcome erratic device behavior. If the beacons are on, they are
turned off before performing the reset. The log associated with the message(s) that is marked for
current display in the DMS message arbitration queue is updated to reflect that it is not being
displayed during the period required to perform the reset and restore the message. Upon
CHART II Business Area Architecture Report
151
January 8, 2006
CHART II Business Area Architecture Report
completion of the reset, the system will determine the correct message to be displayed through
message arbitration and initiate the display of the message on the sign.
It may be necessary to blank the sign prior to performing a reset to avoid confusing motorists. If
the workings of a sign are such that it is left in a diagnostic mode upon completion of a reset, the
sign should be blanked after reset. If either of these actions is appropriate for a given sign, it is
expected that the blanking of the sign would be accomplished within the FMS application.
CHART II Business Area Architecture Report
152
January 8, 2006
CHART II Business Area Architecture Report
1
Lis t DMS Dev ic es
DMS- Res et - 12/10/99
D1
Lis t
DMS
DMSLis t
2
Select DMS
Devic es
Selected DMS
3
Retrie v e Log Id s of
Current Dis pla y
DMSIDs /Log ID s Dis play ed
D3
DMSMes s age
Arbitr ation
Queue
D4
Log
Rec ord Blanking
4
For Eac h Mess age Mark ed
as Dis play ed
4.1
Rec ord
Mess age Not
Dis play ed
Log ID / DMS Id/ Not Dis play ed
StartRes et
5
For Eac h DMS
5.1
Format Res et
Command for FMS
Formatted Command
Command
5.2
FMS
Send Command to
FMS
Return Status
Suc ces s
Failure
5.3
Log Sy s tem
Operation
5.4
Log Data
D2
Operations
Log
Failure Data
Update Nav igator/Map
Log Failure
Failure Notific ation
5.5
5.6
Update Dev ice
Status
Notify Us er
When Res et Complete
5.7
Res to re DMS
Mess age
DMSID
DMS- Res tore Mes s age
Figure 2-71. DMS – Reset (August 2000)
CHART II Business Area Architecture Report
153
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.2.9 DMS – Restore Message
The DMS – Restore Message process determines which message(s) need to be displayed on a
sign after a DMS – Reset. The DMS–Restore Message process determines which message(s) is
marked for display and sends it to the device.
DMS - Restore Mes s age - 12/15/99
DMS - Reset
DMS to Res tore
1
DMS - Blank a
Sign
Queue Empty
Retrieve Mes sages
Marked for Current Dis play
Mes s ages/Log IDs /Beacon State
D1
DMS Mes sage
Arbitration Queue
If Queue not Em pty - Mes sage/Beacon State/Log Ids
DMS - Send a Mess age
Figure 2-72. DMS – Restore Message (August 2000)
CHART II Business Area Architecture Report
154
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.2.10 DMS – Override Queue
The DMS – Override Queue process provides operators with the capability to adjust the priority
settings of messages within a device arbitration queue in order to force a message to be displayed
or not. The change to the priority will be in affect until the message is removed from the queue
or again adjusted by an operator. The priority adjustment is recorded in the associated log.
DMS - Override Queue - 12/10/99
1
List DMS Devices
DMS List
D3
DMS
D1
DMS Message
Arbitration
Queue
Device List
2
Select DMS
DMS Id
3
Retrieve Queue Data
Queue Data for DMS Id
Queue Data
4
Select Message for
Modification
DMS Id/Log ID/Message/New Priority
Message/Log ID/Priority
5
Select New Priority
Message/ Log ID/New Priority
6
Store Message at
New Priority Level
Log ID/Message/New Priority
7
Log Priority Change to
Associated Log
Log ID/Message/Priority Change
D4
Log
D2
Operations
Log
Operator Queue Override
8
Log Data
Log System Operation
Re-evaluate Queue for Message Display
DMS - Evaluate Queue
Figure 2-73. DMS – Override Queue (August 2000)
CHART II Business Area Architecture Report
155
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.3
HAR Processes
The HAR Processes group allows for the System Administrator to maintain the HAR Message
Library and for CHART operators to select messages and devices for the broadcast and blanking
of messages. Actual broadcasting of messages is handled through a message arbitration process
that determines the priority of messages and directs qualified messages for broadcasting on the
HAR devices.
2.2.4.4.3.1 Maintain HAR Message Library
The Maintain HAR Message Library process provides for the creation and maintenance of
message text and voice files for pre-defined HAR messages.
Radio messages are comprised of three components:
1. Header – The header identifies the agency broadcasting the message. Although usually
the SHA broadcasts the messages, it is sometimes necessary to identify a different agency
(i.e., the State Police)
2. Body – The body of the message contains the advisory information to be broadcast
3. Footer – The footer of the message is device specific since it contains the radio call letters
and frequency of the specific HAR device.
The system is expected to be able to store and maintain HAR messages in both voice and text
formats. The system should also provide the operator with the ability to enter both voice and text,
or to allow entry of text and translate that text into voice (given a solution with an adequate voice
quality – yet to be determined).
HAR controllers can store messages in designated slots with a total combined message time
(including header and footer) of 6 minutes stored at the controller. Interface to the controller
provides capabilities to recall and save messages. When no advisory message is active and the
HAR is to be blanked, the default message in slot 2 is designated to be played. Active advisory
messages are stored in slot 7. When sending messages to the controller, it is necessary to validate
that the message was successfully updated.
CHART II Business Area Architecture Report
156
January 8, 2006
CHART II Business Area Architecture Report
1
Need to Maintain Messages
Maintain HAR Message Library - 12/9/99
Update Message Selected
2
List Messages
Selected Message
3
While Adding Messages
Message List
3.1
4
While Deleting Messages
Add Message Selected
Type or Record
Message for
Addition
5
Select Message
4.2
Message Selected for Deletion
D4
Plan
Plan Data
Determine if
Message is Used
in Plan/Schedule
Planned Message
New Message
Message for Modification
3.2
Msg IS Used
Validate Message
Acceptable/Unacceptable Word List
D2
6
While Updating Messages
Acceptable/
Unacceptable
Word Dictionary
Schedule Data
4.3
6.1
Modify Text or
Voice
Message/SHAZAM
Status
Validated Message
3.3
Delete From
Plans/Schedules
If NOT Used
Acceptable-Unacceptable Word List
Select
SHAZAMS/DMS if
needed
SHAZAM List
D6
SCheduled Message
Schedule
Data
Deleted Har Message
SHAZAMS
D1
Updated Message
4.1
Delete Message
from Database
6.2
Message and SHAZAM Status
Validate Updated
Message
3.4
Save New Message
- Voice and/or Text
Validated Msg
6.3
Store Updated
Message - Text
and/or Voice
HAR Message for Deletion
Updated HAR Message
7
New HAR Message
Update Database
Updated Message Info
Update for Log
8
Log System
Operation
Log Data
D3
Operations
Log
Figure 2-74. Maintain HAR Message Library(August 2000)
CHART II Business Area Architecture Report
D5
157
January 8, 2006
HAR
Message
Library
CHART II Business Area Architecture Report
2.2.4.4.3.2 HAR – Add A Message
The HAR – Add a Message process provides the capabilities for operators to select one or more
HAR devices and select or enter an audio or text message to be added to the HAR message
arbitration queue. Any message that exists as a stored message in text format or is typed by the
operator may be translated by software to an audio file if a COTS package of sufficient quality is
available. SHAZAM status is also selected. After addition of a message to the queue, message
arbitration is performed to determine if the change has effected which message(s) should be
broadcast. The related log is updated to record the action taken.
1
List HAR Devices
HAR List
D9
HAR
D8
HAR Stored
Message Library
List
HAR -Add a Message - 12/9/99
2
Select HAR Devices
Record Message
Manual Text Message
D6
Unacceptable
Word Dictionary
Stored Message List
Stored Message
3
4
5
Enter Manual
Message
Record Voice
Message
List Stored
Messages
Unacceptable Words
Text Message
6
Spell Check and
Validate Message
Message List
Recorded Message Complete
Validated Message
Acceptable Words
D7
Acceptable
Word Dictionary
7
8
Convert Text to
Voice
Select Stored
Message
Selected Stored Message
Computer Generated Voice
9
List SHAZAM Devices
SHAZAM List
10
Select SHAZAMS
Selected SHAZAMS
11
For Each HAR Selected
11.1
Update Queue
HAR ID/Message/Log ID/Priority
HAR - Arbitrate Message
Figure 2-75. HAR – Add A Message (August 2000)
CHART II Business Area Architecture Report
158
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.3.3 HAR – Remove A Message
The HAR – Remove a Message process provides the capabilities for operators to select one or
more HAR devices, display the HAR message arbitration queue for the selected device, and
remove a message from that queue. After removal of a message from the queue, message
arbitration is performed to determine if the change has effected which message(s) should be
broadcast. The related log is updated to record the action taken.
1
HAR - Remov e a Message 12/9/99
List HAR Dev ices
HAR List
D1
HAR
D2
HAR Message
Arbitration Queue
List
2
Select HAR Dev ice
HAR ID
3
List Current
Messages
Current Messages
Message List
4
Select Messages
Selected Messages
5
For Each Message Selected
5.1
Remov e the Message f rom
the Queue
HAR ID/Message/Priority
HAR - Arbitrate Message Queue
Figure 2-76. HAR – Remove A Message (August 2000)
CHART II Business Area Architecture Report
159
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.3.4 HAR – Arbitrate Message Queue
The HAR – Arbitrate Message Queue process maintains a message priority queue for each HAR
device configured in the system. When messages are added to the queue, this process adds or
updates the correct priority level with the message information. Once the queue has been
manipulated it is evaluated.
Each message in the queue is related to a specific log. Any one log will have only one message
in a device queue at any one time.
The operator can remove messages from the queue manually or the system will remove all
messages associated with a log when the log closes. The log is updated whenever an item is
added or removed from the queue.
A scheduled message is placed in the appropriate priority level in the queue upon scheduler
event-activation and removed upon scheduler event end-time.
CHART II Business Area Architecture Report
160
January 8, 2006
CHART II Business Area Architecture Report
HAR - Add a Message
HAR - Arbitrate Message Queue - 12/10/99
Process Scheduled Event
Start
Activate Plan
HAR Id/Log #/Message/Priority
HAR ID/Log Id #/Message/Priority
HAR ID/Log ID/Message/Priority
1
Evaluate Message Log ID and Queue
Queue Data
Process Scheduled
Event End
HAR - Remove a
Message
Close Log
De-Activate Plan
Log Id Not In Queue
Log ID Is In Queue
Priority/Log Id/Har ID
2
3
Update Message in
Queue
Add Message to
Queue
Updated Message
D2
HAR Id/Log ID/Priorit y
Log ID/Priorit y/HAR Id
HAR
Message
Arbitration
Queue
New Message
4
5
Update the Queue
Store Queue Change
HAR ID/Priority/Log ID
Log Change in Queue
Remove Message from Queue
Log Message Removal
6
Log Message
Modification in Queue
Log ID
D1
Log
Log Update
7
Log System Operation
Log Data
D4
Operations Log
Evaluate Queue for Broadcast
HAR - Evaluate Queue
Figure 2-77. HAR – Arbitrate Message Queue(August 2000)
CHART II Business Area Architecture Report
161
January 8, 2006
Log Id /Har Id/Priority
CHART II Business Area Architecture Report
2.2.4.4.3.5 HAR – Evaluate Queue
The HAR – Evaluate Queue process determines which message(s) should be broadcast on the
device. The header, footer, and their broadcast time are determined. Starting at the highest
priority, the messages are concatenated until all the messages are included for broadcast or
another message would put the broadcast time over the maximum broadcast time. All messages
used in the broadcast are marked in the HAR message arbitration queue as pending and the
message is sent to the device. Each time the queue is manipulated, the messages are re-evaluated.
If the result of the evaluation is different than what is currently displayed, the message(s) for
broadcast is marked as pending and it is sent to the device. If the queue is empty the default
message is broadcast. There may be multiple messages at each priority level related to different
logs. The highest priority message(s) is always broadcast.
CHART II Business Area Architecture Report
162
January 8, 2006
CHART II Business Area Architecture Report
HAR -Arbitrate Message
HAR -Evaluate Queue - 12/15/99
HAR Id #
1
DeviceState - Online/Offline
Retrieve Current Device State
DeviceState
2
Retrieve Queue andCurrent
Broadcast
D7
Queueand CurrentBroadcast
HAR
Queueand Messages Marked Current
3
HAR -Broadcast Default
Message
If Device Online and Queue is Empty
Determine if Queueis Empty
QueueNot Empty
4
Maximum Broadcast Time for HAR Id
Retrieve MaximumBroadcast
Time
Maximum Time
5
Determine HighestPriority
Message /Header/Footer - Mark
as Pending
Pending Broadcast
D2
HAR
Message
Arbitration
Queue
Log ID/Priority
6
Until Maximum Time is Reached or No More
Messages
6.1
Evaluate Length ofNext Priority
Message
If Within Time Period
6.2
Concatenate WAV File to
Previous
Concatenated Message
6.3
Mark Message for Pending
Broadcast
Mark Pending Broadcast
All Messages Usedor MaximumTime Reached
7
Compare Current Broadcast to
Pending Broadcast
If Different
8
Evaluate SHAZAMStates
If Device Online - HAR ID/Message/SHAZAM States
HAR -Broadcast aMessage
Figure 2-78. HAR – Evaluate Queue(August 2000)
CHART II Business Area Architecture Report
163
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.3.6 HAR – Broadcast A Message
The HAR – Broadcast a Message process provides the capability to initiate the interface with
FMS to allow the message to be broadcast on the selected device. SHAZAM devices may also be
initiated. Message arbitration and queue evaluation is performed before any message is sent to
the HAR. Once the message is broadcast and the return status received from FMS that the
command has been successful, the log associated with each broadcast message will be updated to
reflect the new broadcast status. The queue will be marked to show the message is currently
broadcast and no longer pending.
CHART II Business Area Architecture Report
164
January 8, 2006
CHART II Business Area Architecture Report
HAR - Evaluate Queue
HAR ID/Message/Log IDs/Each SHAZAM State
1
HAR - Broadcast a Message - 12/9/99
Format Command for
FMS
Formatted Command
Command/Log ID
2
FMS
Send Command to
FMS
Return Status/Log Id
Log Success
Log Failure
3
4
Log System
Operation
Log Data
D1
Operations
Log
Failure Data
Log Failure
Update Status in Navigator/Map
Notify User of Failure
5
Update Device
Status
6
Notify User
Update Queue
7
For Each Log ID
7.2
Mark Messages As
Broadcast - Clear
Pending
HAR ID/Log ID/Broadcast State
D3
HAR Message
Arbitration Queue
Update Logs
7.1
Record Successful
Broadcast Command
Record Msg Broadcast
D2
Log
If Needed - Change State of SHAZAMs
HAR - Set
SHAZAM On/Off
Figure 2-79. HAR – Broadcast A Message(August 2000)
CHART II Business Area Architecture Report
165
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.3.7 HAR – Broadcast Default Message
The HAR – Broadcast Default Message process provides the capabilities to begin broadcasting
the default message for any HAR device when that device’s arbitration queue no longer contains
any priority messages. When evaluation of the HAR message arbitration queue determines that
the queue is empty, any SHAZAMs that are set on are turned off. Once FMS returns a successful
status and the devices are off, a command is sent for the HAR device to broadcast from the
default slot.
HAR - Ev aluate Queue
HAR ID #
1
HAR - Broadcast Def ault Message 12/9/99
If ANy SHAZAMS Are ActiveTurn them OFF
HAR - Set SHAZAM
On/Of f
Activ e SHAZAM ID
HAR ID
2
Format Play Def ault Slot
Command for FMS
Formatted Command
Command
3
FMS
Send Command to FMS
Return Status
Log Success
Log Failure
4
Log Sy stem
Operation
5
Log Data
D1
Operations
Log
Failure Data
Log Failure
Update Status in Nav igator/Map
Notif y User of Failure
6
7
Update Dev ice
Status
Notif y User
Figure 2-80. HAR – Broadcast Default Message(August 2000)
CHART II Business Area Architecture Report
166
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.3.8 HAR – Set SHAZAM On/Off
The HAR – Set SHAZAM On/Off process provides a means for the system to turn SHAZAMs
on or off when broadcasting a message, or turn them off before broadcasting the default
message. SHAZAMs are always turned on after the associated message reaches the HAR or
turned off before it is sent to the HAR. DMS devices being utilized as SHAZAMs related to the
specific HAR are also turned off by removing the SHAZAM message from the DMS arbitration
queue and evaluating the queue for that DMS device.
CHART II Business Area Architecture Report
167
January 8, 2006
CHART II Business Area Architecture Report
HAR - Set SHAZAM On/Off - 12/9/99
HAR - Broadcast
Default Message
HAR - Broadcast
Message
Shazams to Turn OFF
Shazams to Turn On/Off
1
For Each SHAZAM/State Pair in List
1.9
DMS ID/Message/Priority/Log ID - REMOVE
DMS - Arbitrate
Message Queue
D1
1.1
Remove Message from DMS
Queue
DMS Stored
Message Library
Shazam NOT DMS
If DMS And Turn On
DMS Message for Shazam
DMS ID/Message/Priority/Log ID - ADD
Determine if SHAZAM is
DMS
If DMS and Turn OFF
1.2
1.3
Retrieve DMS Message and
Update Queue
Format On or OFF Command
for FMS
Formatted Command
Command
1.4
FMS
Send Command to FMS
Return Status
Command Success
Command Failure
1.6
Log System Operation
1.5
Log Data
D2
Operations
Log
Log Failure
Log Failure
Update Navigator/Map
Failure Notification
1.7
1.8
Update Device Status
Notify User
Figure 2-81. HAR – Set SHAZAM On/Off(August 2000)
CHART II Business Area Architecture Report
168
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.3.9 HAR – Update Default Message
The Update Default Message process allows the user to update the message stored in the default
slot of the HAR controller. Whenever the HAR message arbitration queue is empty the default
message is broadcast. The default HAR message is created by typing freeform text, recording a
.WAV file, or selecting a stored library message. The message is then sent to FMS for storage in
the default slot of the controller.
1
HAR - Update Default Message - 12/9/99
D1
Device List
List HAR Devices
HAR
HAR List
2
Select HAR Devices
Manual Msg for Selected HARs
3
Stored MSG for Selected HARs
Enter Manual
Default Message
D2
Record Msg for Selected HARs
Unacceptable
Word
Dictionary
Manual Default Message
Unacceptable Words
4
6
5
Spell Check and
Validate
Record Voice Default
Message
Select Stored
Default Message
Validated Message
Acceptable Words
D3
Acceptable
Word
Dictionary
7
Recorded Default Message
Convert Text to
Voice
Stored Message Data
Stored Default Message Data
Default Message from Manual
D4
8
For Each HAR Selected
HAR Message
Library
8.1
Format Command for
FMS To Place Data in
Default Slot
Formatted Command
8.2
Command
Send Command to FMS
FMS
Return Status
Command Success
D5
Operations
Log
Log Data
8.3
Log System
Operation
Command Failure
8.4
Log Failure
Failure Notification
8.5
Notify User
Figure 2-82. HAR – Update Default Message (August 2000)
CHART II Business Area Architecture Report
169
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.3.10 HAR – Send Maintenance Command
The HAR – Send Maintenance Command process allows the user to perform HAR controller
functions including, but not limited to, setup, reset, and rebuild. The command is sent to the
controller through FMS and, when a successful status is received from FMS, the message(s)
marked for broadcast is sent to the controller. If the queue is empty, the default message is
broadcast.
CHART II Business Area Architecture Report
170
January 8, 2006
CHART II Business Area Architecture Report
HAR -Send Maintenance Command - 12/10/99
1
List HAR Devices
D1
List
HAR
HAR List
2
SelectHAR
Devices
Selected DMS
3
Retrieve Log Ids of
Current Broadcast
HAR IDs/Log IDs of Messagesbroadcast
D3
DMS Message
Arbitration
Queue
D4
Log
RecordRemoval from Broadcast
4
For Each MessageMarked
as Broadcast
4.1
Record
Message Not
Broadcast
Log ID/ HAR Id/ Not Broadcast
SelectCommand
6
SelectCommand Setup- Reset - Rebuild
Send Command
5
For Each DMS
5.1
FormatCommand
for FMS
Formatted Command
Command
5.2
FMS
Send Command to
FMS
Success
ReturnStatus
Failure
5.3
5.4
Log System
Operation
Log Data
D2
Operations
Log
FailureData
Log Failure
UpdateNavigator/Map
FailureNotification
5.5
5.6
UpdateDevice
Status
NotifyUser
WhenCommand Complete
5.7
Restore HAR
Message Broadcast
HAR ID
HAR-Restore Message
Figure 2-83. HAR – Send Maintenance Command(August 2000)
CHART II Business Area Architecture Report
171
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.3.11 HAR - Restore Message
After a maintenance command has been sent to a HAR controller, the message(s) evaluated for
broadcast must be restored to the device. The HAR – Restore Message process determines which
message(s) is marked for broadcast and uses the HAR – Broadcast Message process to send it to
the device. If the HAR message arbitration queue is empty, the command is sent to broadcast the
default message.
HAR - Restore Message - 12/15/99
HAR - Send Maintenance Command
HAR ID
1
HAR - Broadcast Default
Message
Queue is Empty
Retrieve Messages Flagged for
Current Broadcast
Log ID/Message
D1
HAR Message
Arbitration Queue
D2
HAR Stored
Message Library
If Queue Contains At Least One Message
2
Retrieve Header/Footer
Header/Footer
Header/Body/Footer - Log IDs - HAR ID
3
If more than one message Concatenate Messages
HAR ID/Message/Log Ids
HAR - Broadcast Message
Figure 2-84. HAR - Restore Message(August 2000)
CHART II Business Area Architecture Report
172
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.3.12 HAR – Override Queue
The HAR – Override Queue process provides operators with the capability to adjust the priority
settings of messages within a device arbitration queue in order to force a message to be broadcast
or not. The change to the priority will be in effect until the message is removed from the queue
or again adjusted by an operator. The priority adjustment is recorded in the associated log.
CHART II Business Area Architecture Report
173
January 8, 2006
CHART II Business Area Architecture Report
HAR - Override Queue - 12/10/99
1
List HAR Devices
HAR List
D3
HAR
D1
HAR Message
Arbitration
Queue
Device List
2
Select HAR
HAR Id
3
Retrieve Queue Data
Queue Data for HAR Id
Queue Data
4
Select Message for
Modification
HAR Id/Log ID/Message/New Priority
Message/Log ID/Priority
5
Select New Priority
Message/ Log ID/New Priority
6
Store Message at
New Priority Level
Log ID/Message/New Priority
7
Log Priority Change to
Associated Log
Log ID/Message/Priority Change
D4
Log
D2
Operations
Log
Operator Queue Override
8
Log Data
Log System Operation
Re-evaluate Queue for Message Broadcast
HAR - Evaluate Queue
Figure 2-85. HAR – Override Queue(August 2000)
CHART II Business Area Architecture Report
174
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.4
AVCM
The AVCM Processes group allows for users with appropriate rights to maintain the Wall
Monitor Configurations, CCTV Presets, and Tours. The CHART operators are able to Control
Wall Monitor Assignments, Activate Tours, and Control Cameras.
2.2.4.4.4.1 Maintain Wall Monitor Configuration
The Maintain Wall Monitor Configuration process is a System Administration function, which is
used to establish/define the monitors to be displayed on the walls at the centers, media video feed
channels, VCR devices, and Web Page feeds. For actual wall mounted configurations, it is
expected that a GUI interface will be provided to ease the operator’s capabilities to assign a
camera to a monitor or projector.
CHART II Business Area Architecture Report
175
January 8, 2006
CHART II Business Area Architecture Report
Maintain Wall Monitor Configuration -8/6/99
1
While Not Done
1.1
List Monitors
Monitors
1.2
Add or Delete
Monitor
Monitor Device List for Location
Updated Info
1.3
Store Wall
Monitor Data
D2
Device
Configuration
Available Monitor List
D1
Wall Monitor
Configuration
D3
Operations
Log
Wall Monitor Data
Updated Information
2
Log System
Operation
Log Info
Figure 2-86. Maintain Wall Monitor Configuration(August 2000)
CHART II Business Area Architecture Report
176
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.4.2 Control Wall Monitor Assignment
The Control Wall Monitor Assignment process is an operational function, which enables the
CHART Operators at each center to direct output from a tour or a camera to a specific wall
monitor or projector, media video feed channel, VCR device, and Web Page feed.
Contr ol Wall Monitor Assignment- 12/7/99
1
Retrieve Wall Monitor
Configuration
Monitor Configuration
D1
Wall Monitor
Configuration
D3
Wall Monitor
Assignment
D2
AVCM
Wall Monitor Configuration
2
Display Configuration
and Assignments
Assignments
Graphical Display of Wall Monitors
3
List Cameras
Cameras
Camera List
4
Select Camera for
Monitor
Selected Camera
5
Assign Camera to
Monitor
Camera & Monitor
6
Display Video on
Monitor
Camera Assignment Logged
7
Log System Operation
Log Data
D4
Operations Log
Figure 2-87. Control Wall Monitor Assignment(August 2000)
CHART II Business Area Architecture Report
177
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.4.3 Maintain CCTV Presets
The Maintain CCTV Presets process is a System Administration function used to maintain the
stored presets for the AVCMs.
1
Need to Maintain
Presets
Maintain CCTV Presets -12/20/99
Add a Preset
D2
6
AVCM
Camera List
List Cameras
List of Cameras
7
Select Camera
13
Preset List
Delete/Modify selected
2
Selected Camera
Add Preset
List Presets
Display List
4
14
Allow Operator to Name Preset
Modify Preset
Preset to Modify
Select Preset for
Deletion/Modification
5
Selected Preset
Name Preset
15
D1
Modify Settings
Delete Preset
from Database
Delete Preset
Preset to Add
Preset
Log Deletion
12
20
10
Log Operations
Log
Camera Ready for Control
Log Operation
Get Camera
Pan/Titlt/Zoom
Save Preset
Preset for Save
Log Text
Control Camera
Resulting Pan/Tilt/Zoom
D3
Operations
Log
Control Camera
Figure 2-88. Maintain CCTV Presets(August 2000)
CHART II Business Area Architecture Report
178
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.4.4 Refresh Default AVCM Presets
The Refresh Default AVCM Preset process is a custodial function, which is used to return a
camera to its original default position at a scheduled time.
Refresh Default AVCM Presets - 9/17/99
1
D1
System
Parameter
Scheduled Time
At Scheduled
Time
Time to Update Presets
2
For Each Camera
D2
Preset
Presets
2.1
Retrieve Default
Presets
Presets for Camera
2.2
Send
Presets/Slots to
Camera
AVCM Preset Command
AVCM
Presets Updated
D3
Operations
Log
Log Data
3
Log System
Operation
Figure 2-89. Refresh Default AVCM Presets(August 2000)
CHART II Business Area Architecture Report
179
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.4.5 Maintain Tours
The Maintain Tours process is used to change the configurations of cameras being displayed on a
monitor. There could be different tours to maintain, whether they are for wall monitors or for
web and media feeds. As part of the tours, the frequency and sequence of the specified cameras
used for the tour is maintained. This process will be handled by the System Administrator.
Maintain Tours - 12/20/99
5
1
Name Preset
Add a Tour Name
Tour Name
Need to Maintain
Tours
Modf iy /Delete Selected
6
13
List Cameras
Camera List
D2
AVCM
List Tours
Tour List
Display List
List of Cameras
14
Select Tour
7
Selected Tour-Modif y
While Not Done Select Camera
D1
Tour
Selected Tour - Delete
15
Delete Tour
f rom Database
Selected Camera
10
Tour f or Save
Tour f or Deletion
Delete Tour
Sav e Tour
16
Delete Tour from
Scheduled Ev ents
Log Deletion
17
Log Data
D3
Operations Log
Log Sy stem Operation
Figure 2-90. Maintain Tours(August 2000)
CHART II Business Area Architecture Report
180
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.4.6 Activate Tour
The Activate Tours process is used when a CHART Operator needs to activate a tour of cameras.
This is an operational process.
Activate Tour - 9/17/99
1
D1
Tour
List Tours
Tours
Tour List
2
Select Tour
Selected Tour
Wall Monitor
Configuration
D2
4
Monitors
List Monitors
Monitor List
6
Log System
Operation
Log Tour Activation
5
Select Monitor
for Tour
Selected Monitor and Tour
Log Data
3
For Each Camera in Tour
D3
Operations
Log
3.1
For Configured Amount of Time
3.1.1
Request Camera
Feed
Camera Feed
D4
Wall Monitor
Assignment
Store Monitor Assignment
3.1.2
Dsiplay
Camera on
Monitor
Figure 2-91. Activate Tour(August 2000)
CHART II Business Area Architecture Report
181
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.4.7 Control Camera
The Control Camera process is an operational function, which enables the CHART Operators to
take control of a camera, as needed, as part of an incident verification. Use of a specific camera
for incident verification should be noted in the Incident Log.
View Camera
Camera being viewed
Control AVCM -11/5/99
15
Update Device
Status
2
D2
Camera State Data
Select Control Option
Camera Status
Store Previous State
Camera Id
1
3
If camera is being controlled
5
4
Determine Current
Controller
3.1
Camera is available
Camera is being Used
Take Control of Camera
and Store Previous
State
Controlled Camera
Deny Media &
Web Access
Send Alert to
Controlling Operator
Camera Controlled
6
While Not Done
Log Control
Log Alert Sent
6.1
Pan/Tilt/Zoom Camera
8
6.1.1
Format
Command for
AVCM
Operations
Log
D1
Log Info
Log Operations Log
Retrieve Previous State
Log Camera Released
Formatted Command
6.1.2
7
Control Complete
Release Control
Send Command
toAVCM
Camera at Default
Send Command
Camera
Media Access Returned
Camera to Preset Message
9
AVCM
Best View
Select Camera State
Previous State
14
10
Time of Day
Load Best View
Preset
Last Location
13
Last Location
12
Load Time of
Day Preset
Release to WWW
Web and Media
Previous Camera
State
If OK Area-Release to Public
11
Return Web and Media
Access
Release Camera
Web Access Message
Figure 2-92. Control Camera(August 2000)
CHART II Business Area Architecture Report
182
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.5
Detectors
The Detectors process group is comprised of Custodial processes which first receive information
regarding traffic flow, generate system response plans based on the traffic flow data, then alert
key personnel should information received point to a disruption in traffic flow.
2.2.4.4.5.1 Handle Polled Detector Data
The Handle Polled Detector Data process is used to receive data from FMS in order to analyze
the flow of traffic, and to alert individuals if traffic flow falls below pre-determined parameters.
As data is received from FMS, either smoothed data or a failure status is sent to the CHART
system. If a failure is reported, the failure is logged in the failure log. If smoothed data is
received, the information received will be used to calculate the new history. The smoothed data
is then sent to the Handle Detector Rules process for evaluation against traffic flow thresholds.
This process will need to be closely reviewed during detailed design to verify the availability of
the types of data from the detectors, as well as confirmation of the level of data stored in the
operational and archive databases.
CHART II Business Area Architecture Report
183
January 8, 2006
CHART II Business Area Architecture Report
Handle Detector Data 11/9/99
1
FMS
D1
Store Smoothed
Data
Smoothed Data
If Not T ime to Calculate History
Failure Log
Failure Info
Failure Status
Smoothed Data for Storage
2
Send Alert
Device ID
Log Failure
D5
# of Failures before Alert
System
Parameters
Handle
Detector
Rules
If Time to Calc History
History # minutes
D2
Alert Info
Updated Status
History period data - 15 minutes
4
D11
Alert Data
9
Update Device
Status
Calculate History
Updated Status & T ime Stamp
Pavement Info
Previous Historical
Calculated
Value Historical Data
D4
Pavement
Sensor Data
D3
Historical
Data
Figure 2-93. Handle Polled Detector Data(August 2000)
CHART II Business Area Architecture Report
184
January 8, 2006
Smoothed Detector Data
Smoothed
Data
CHART II Business Area Architecture Report
2.2.4.4.5.2 Handle Detector Rules
The Handle Detector Rules process compares incoming smoothed detector data against
thresholds stored as system parameters and historical data. Historical data is maintained based on
type of day, day of week, time of day (15 minute increments), and type of weather. Current
weather sensor data is used to define the set of historical data to be used for comparison.
The results of the evaluation may show normal flow, congested flow, or a potential incident. If
the evaluation shows a normal flow, it is determined if there was a previous congested or
incident state for this detector device. If the detector had been in a non-normal flow state, it is
determined if the flow has returned to normal for a configured number of polling cycles and, if
so, closes the associated congestion or incident log. The first polling cycle showing a normal
state will not trigger the release of devices to prevent premature deactivation.
If the result of the evaluation shows congestion, the congestion response process is activated to
generate a congestion log and determine the correct device response for traveler information.
If the result of the evaluation shows a potential incident, the incident response process is
activated to generate an alert, incident log, and determine the correct response plan.
CHART II Business Area Architecture Report
185
January 8, 2006
CHART II Business Area Architecture Report
Handle Detector Rules -12/13/99
Handle Detector Data
Smoothed Detector Data
20
Generate Incident
Response
Log Incident Detection to
Open Incident Log
18
Incident Log Exists - Incident Detected - Update Log
Check detector for current
use in congestion/incident
Non - Normal Speed/ NO Incident Log Open
Log ID/Type if it exists
Generate Congestion
Response
2
Congestion Detected/No Activity Log Open
19
Compare Data to
Historical
Congestion Log Exists - Congestion Detected - Update Log
Update Incident Data
Log Congestion Detection
to Open Congestion Log
Historical Data
Pavement Sensor Data
D6
Update Congestiion Data
Historical Data
D8
D9
Congestion
Log
Incident Log
Thresholds
Flow Normal and Greater Than 35 MPH
D10
1
D2
System
Parameters
Pavement
Sensor Data
Congestion Log ID
Has # Normal
Responses Reached #
Needed to De-Activate
Inc-Cong Response
# Normal Polls Needed to De-Activate Inc/Cong Response
Incident Log ID
5
# Reached
Determine Log Type &
Retrieve Log Id
# NOT Reached
Devices De-Activated
Log Id for De-activation
11
6
Increment # Normal
Responses
Update Map
If change in threshold
Log De-Activate
Log Increment
17
D3
Operators Log
Log Data
Log System Operation
Figure 2-94. Handle Detector Rules(August 2000)
CHART II Business Area Architecture Report
186
January 8, 2006
Close Log
CHART II Business Area Architecture Report
2.2.4.4.5.2.1 Generate Congestion Response
When the evaluation of incoming detector data in Handle Detector Rules shows congestion, and
the previous reporting of the device did not show congestion, a congestion log is opened. The
devices in a pre-determined radius from the detector are added to the system-generated response
plan for display or broadcast of messages created from the congestion response rules. Any
defined notification is added to the system-generated response plan. The system is configured to
require operator confirmation or allow activation of the plan without operator confirmation. If
confirmation is required, an alert is sent to the operator(s) at the center responsible for the
detector that triggered this process. If confirmation is not required, the system generated
response plan is activated. The system may be configured to alert the operator that a congestion
response plan has gone into affect. The location of the congestion and all activated system
responses are logged in the congestion log for later archive.
CHART II Business Area Architecture Report
187
January 8, 2006
CHART II Business Area Architecture Report
Generate Congestion Response12/3/99
HandleDetector
Rules
Congestion Detected/Not a Special Event/No Previous Congestion Detected
Location/Detector Data
12
D9
Detector
Detector ID/Log ID- Flag as Used
CreateActivity Log
Congestion Log Id
Log ID
4
Determine Response
Devices From
Detector Loc
Devices in Congested Area
D1
Device
Configuration
D4
Message Rules
Devices
8
Build Congestion
Response Messages
Congestion Rules
Devices & Messages
D8
Congestion Log
9
Determine Notification
List
D5
Cong Notify List
Notification List
Plan Complete
19
Store Response Plan
D10
Congestion Log IDand Response Plan
Response Plan
Plan Stored
20
Determine If
Confirmation Required
Confirmation Statusand Data
Confirmation Required
No Confirmation Required
18
14
Generate an Alert
Congestion Log ID& ResponsePlan
D7
Alert Data
Store Data if Alert Notification of Activation Required
Activate Congestion
Response
Congestion Response
Activate Response
If AlertRequired
Log ID& ResponsePlan
Send Alert
Alert Sent-ConfirmRequired
Congestion Plan Activated-No Confirm
17
Log System Operation
Log Data
D3
Operations Log
Figure 2-95. Generate Congestion Response(August 2000)
CHART II Business Area Architecture Report
188
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.5.2.2 Respond to Congestion Alert
The Respond to Congestion Alert provides the capabilities to activate the system-generated
response plan, which may be modified by the operator.
If the system is configured to require a confirmation of a system generated congestion response
plan or notification of an activated congestion response plan, an alert has been sent and appears
on the appropriate users’ screen. Once a user acknowledges the alert, a congestion log is
displayed with the location of the congestion, time of detection, the system generated response
plan, and any other information. The operator can send the plan as is, modify and send the plan,
or cancel the plan. If the congestion response plan is cancelled, the congestion log is closed. The
operator may accept or modify a delay period before another congestion alert is initiated from
the same device. While the congestion log is open, the detector, whose data was used in the
evaluation of this congestion, will be indicated as in a congested state. No further notification of
congestion is sent while the detector remains in a congested state.
CHART II Business Area Architecture Report
189
January 8, 2006
CHART II Business Area Architecture Report
1
Acknowledge
Alert
Respond to Congestion Alert - 12/6/99
Ack Alert
2
D1
Alert Data
View Congestion
Log
Log ID
Congestion Log Data
Log Open
3
D6
Response
Plan
Open System
Generated
Response Plan
Response Plan
Activate Response
If Confirmation Required
4
User
Updates/Confirms
System Generated
Response Plan
Congestion Response Cancelled
Plan Inactive-Confirmed- Plan OK/Updated
Response Plan Data
D4
Plan Active - Ok
Plan Active - Needs Update
5
CloseLog
6
Plan Active Needs Update
Cancel the Congestion
Response
Congestion Log ID
7
Plan Active
and OK
Congestion
Log
8
Activate System
Generated Response
Plan
Open Log for Modification
Activated Response
Log Close
Log Congestion Log
9
Store Response Plan
with Log
10
D5
Detector
Time Period Disabled
Default Disable Time Period
Active System Generated Response Plan
Log Operator Response
User Flags Detector No Congestion
Response
Log Plan OK
11
Log Cancellation Data
Log System Operation
Log Activation
Log Data
D2
Operations
Log
Figure 2-96. Respond to Congestion Alert(August 2000)
CHART II Business Area Architecture Report
190
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.5.2.3 Generate Incident Response
When the evaluation of incoming detector data in Handle Detector Rules shows a potential
incident, and the previous reporting of the device did not show an incident, an incident log must
be opened. The devices in a pre-determined radius are added to the system-generated response
plan for display or broadcast of messages created from the incident response rules. Any defined
notification is added to the system generated response plan. The system is configured to
necessitate operator confirmation or allow activation of the plan without operator confirmation.
If confirmation is not required, the system generated response plan is activated and an alert sent
notifying the operator of this system action. If confirmation is required, an alert is sent to the
operator(s) at the center responsible for the detector, which triggered this process.
Generate Inc ident Res pons e - 11/15/99
Handle Detector Rules
Within Inc ident Thres hold/No Prev ious Incident Detec ted
13
Loc ation/Detec tor Data
Detec tor ID/ Log ID - Flag as us ed
D9
Detec tor
Open Inc identLog
D8
Inc ident Log
D1
Dev ic e
Configuration
D4
Mes sage Rules
D5
Notific ation List
Inc ident Log Id
Log ID
3
Determine Res pons e
Devic es FromDetec tor
Loc ation
Dev ic es in Area
Dev ic e Lis t
7
D7
Inc ident Rules
AlertData
Build Res ponse Mes s ages
Inc Log Id & Plan
Mes sages
15
AlertTriggered with
Respons e Plan and
Inc ident Log ID
10
Inc Notify Lis t
Confirmation Required
Determine Incident
Notific ation List
If No Confirmation Required
AlertOperator Res ponse Plan Activ ated
16
Inc ident ID & Res pons e Plan
Ac tivate Inc ident Res pons e
Inc ident Res pons e
Ac tivate Res pons e
Send Alert
Log In c ident Res pons e Ac tiv ation
Log In c ident Res pons e Alert Sent
17
Log Sy s tem Operation
Log Data
D3
Operations Log
Figure 2-97. Generate Incident Response(August 2000)
CHART II Business Area Architecture Report
191
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.5.2.4 Respond to Incident Alert
If confirmation is needed for activating an incident response plan, an alert is sent and appears on
the appropriate user’s screen. Once a user clicks on the alert, the nearest camera is located,
displayed on the user’s monitor, and control is given to the user. If another operator is using it,
that user is relieved of control and control is given to the operator handling this incident alert. An
incident log is opened and displayed with the location of the incident, time of detection, current
weather conditions, the system generated response plan, and other information. Based on the
operator’s verification of the incident, the operator can send the system generated response plan,
modify and send the response plan, or cancel the plan. If the plan is cancelled the incident log is
closed. While the log is open, the detector responsible for the data used in the evaluation of this
incident will be in an incident state.
1
Acknowledge Alert
Respond to Incident Alert - 11/15/99
Ack Alert
2
D1 Alert Data
Log ID
Retrieve Incident Log
Incident Log Data
Log Open
3
Response Plan
Open System Generated
Response Plan
Plan on screen
4
Determine Closest
Camera
Closest Camera Id
D3
Device
Configuration
Camera Id & monitor Id
5
AssignCamera to
Monitor
Camera Id & Monitor
Control Wall Monitor
Assignments
If Camera Available
Camera ID
Control AVCM
If In Use
6
Re tu rn s Co n fi rm e d or Un c o n fi rm e d
Released Camera
Control Camera
7
Release Users
Control of
Camera
D4
In c i d e nt L o g Id & Cl os u re Da ta
Update/Confirm/Cancel Plan
12
Change Incident
Log toCongestion
Log
9
Incident NOT Verified - Close Log
Incident
Log
Cl o s e Lo g
Disable for Time Period
13
User Updates/Confirms
System Generated
Response Plan
Un c o n fi rm e d /Do No thi n g
Cl o s e In c i d e n t L o g &Do
No th i ng
Associate With Open Log ID
15
User Flags Detector to Disable Incident Response
15.2
Incident Confirmed-Plan OK/Updated
15.1
Associate Detector
with Previous
Incident
User Disables Incident
Response for TimePeriod
10
Activate System
Generated Response
Plan
Re s p o ns e Pl a n Da ta
Ac ti v a te Re s p o n s e Pla n
Disabled Time Period
Open Log ID
Default Time Period
D5
Log Close
Activated Response
Detector
In c i d e nt L o g Cl o s u re Da ta
Ch a n g e to Co n g e s ti on L o g
Ge n e rate Co n g e s ti o n
Re s p on s e
11
Log Association
Store Response Plan
with Log
Log Detector Disabled
ActiveSystem Generated Response Plan
Log Activation
8
Log System Operation
Log Data
D2
Operations
Log
Figure 2-98. Respond to Incident Alert(August 2000)
CHART II Business Area Architecture Report
192
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.5.2.5 Activate Response Plan
Once the response plan is created, and confirmed if necessary, the plan is activated. The
commands are read from the plan and executed in sequence. Each command in the plan is
executed by interfacing with its related process/application and all arbitration rules apply.
Activate System Generated Response -12/10/99
D1
Congestion Log
Congestion Response Information
D5
Response
Plan
1
Response Plan
Retrieve System Generated
Response Plan Information
Weather Sensor Response Information
D4
Weather Sensor
Alert Log
Incident Response Information
Plan Info
Incident Log
D3
2
For Each Device Message/Notification
2.1
DMS-Add a Message
Log Id/Msg
Perform Action
Log Data
3
Log System
Operation
Log ID/Message
Log Info
D2
Log ID/Notification
HAR - Add a Message
Perform Notification
Figure 2-99. Activate Response Plan(August 2000)
CHART II Business Area Architecture Report
193
January 8, 2006
Operations
Log
CHART II Business Area Architecture Report
2.2.4.4.6
Equipment
The Equipment Processes group is used for the following functions: to maintain equipment
inventories at Maryland SHA maintenance shops used for CHART incident response, to
maintain the status of that equipment, to alert shops of necessary updates on associated
equipment status.
2.2.4.4.6.1 Maintain Equipment Inventory
The Maintain Equipment Inventory process is a centrally controlled function used to add,
modify, or delete equipment inventories for each maintenance shop responsible for assisting with
incident response. The inventory represents all pieces of equipment regardless of status.
Maintain Equipment Inventory - 9/17/99
1
Equipment List
List Categories
Equipment List for Deletion
2
Select Category for Modification
3
Select Category for Deletion
2.1
4
Add New Equipment
Category Name
4.1
Add Number in
Category
Modify # of
Equip in
Category
3.1
Delete
Category from
Database
# of Equipment
List
2.2
Update Category
in Database
Deleted Equipment Info
New E quipment Type
Updated Equipment Info
5
D1
New Inventory Info
Store Equipment Inventory
Equipment
Inventory
Inventory Update
6
Log System
Operation
Log Data
D2
Operations
Log
Figure 2-100. Maintain Equipment Inventory(August 2000)
CHART II Business Area Architecture Report
194
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.6.2 Maintain Equipment Status
The Maintain Equipment Status process is used by the individual Maryland SHA maintenance
shops to update the status of their equipment. This is vital because, as a CHART operator is
notifying a shop to dispatch equipment to an incident, he/she needs to know what equipment
(i.e., front-end loader) is there and whether or not it’s available.
Maintain Equipment Status - 9/17/99
1
List
Shops/Locations
D3
Shops/Locations
Center
List of Shops
2
Select
Shop/Location
Selected Shop
3
List Equipment
Equipment List
List of Equip for selected shop
4
Select Equipment
D1
Selected Equipment
Equipment
Status
5
Modify Number
Available for Use
Changed Availability
7
Store Equipment
Status
Equipment Status
Log Update Info
6
Log System
Operation
Log Data
D2
Operations
Log
Figure 2-101. Maintain Equipment Status(August 2000)
CHART II Business Area Architecture Report
195
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.6.3 Alert for Delinquent Equipment Status
The Alert for Delinquent Equipment Status process is used to assure the accuracy of information
reported by the maintenance shops. On a pre-determined schedule, the equipment status for each
shop is polled by the CHART system to see if the equipment status has been updated within the
given parameters. If not, an alert is sent to the shop, notifying them that the status needs to be
updated.
Alert for Delinquent Equiment Status - 10/26/99
1
Poll Equipment Status
1.1
For Each Shop
D1
System
Parameter
D2
Center
Polling Frequency/Update Frequency
1.1.1
Determine if Status Has
Been Updated
Center List Filtered by Shop Type
If Status Has not Been Updated
1.1.2
D3
Alert Data
Alert Data
Send Alert and Store
Alert Data
Alert Sent
Send Alert
Figure 2-102. Alert for Delinquent Equipment Status(August 2000)
CHART II Business Area Architecture Report
196
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.6.4 Respond to Delinquent Equipment Status Alert
The Respond to Delinquent Equipment Status Alert process allows the shop to acknowledge
receipt of the alert, and then update equipment status.
10/6/99
Date/T ime and User
1
Acknowledge
Alert
Alert Data
D1
Alert Data
Alert Ackd
Maintain
Equipment
Status
Figure 2-103. Respond to Delinquent Equipment Status Alert(August 2000)
CHART II Business Area Architecture Report
197
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.7
Signals
The Signals process group is used to receive periodic data for each of the signal devices, respond
to signal failure alerts, and store individual signal device and controller data to the archive.
There are a couple issues with signals to be reviewed before the following business processes
can be implemented as defined. (1) Current communications with traffic controllers is via dialup modems and would be cost prohibitive to poll on a frequent basis – there should be a change
in communications before implementing these processes. (2) There is an effort underway to
convert all the signal controllers to adaptive controllers, hence these processes do not identify a
method to change signal timings. Both of these issues should be reviewed during detailed design
to verify their status.
2.2.4.4.7.1 Handle Signal Polling Data
The Handle Signal Polling Data process is used to receive data from FMS or Econolite in order
to analyze the flow of traffic and to alert individuals if traffic flow thresholds reach unacceptable
pre-determined parameters. As data is received from FMS or Econolite, either flow data or a
failure status is sent to the CHART system. If a failure is reported, the failure is logged in the
failure log and an alert is sent. The response to the failure alert will be handled by the Respond to
Device Failure Alerts process (Section 2.2.4.2.2.6). The flow data received will be compared to
pre-determined system parameters. If a determination is made that the flow falls below the
thresholds, the device status will be updated and an alert will be sent
This process will require a thorough review during detailed design to determine the current
communications capabilities.
CHART II Business Area Architecture Report
198
January 8, 2006
CHART II Business Area Architecture Report
Ha ndl e Si gn al Pol l in g Data-1 1/08/99
Ec ono li te or
FMS
Status D ata
2
D2
Fa il u re
Log
System
Parame ters
D4
De te rmi n e
Hea lth Statu s
Th re sho l ds an d Vol Al arm Level s
Fa il u re D ata
Fa il e d
Traffic V ol ume
3
4
Lo g Fa il ure
Ch eck fo r
Thres ho ld
Cha nge s i n
Vol ume Level s
7
Si gn al S ta tu s
Up date De vi ce
Status
Th re sho l d Cha nge
Store Al ert D ata
Status U pda ted
D5
Al ert D ata
Exce ede d Vol um e Level
6
Lo g System
Ope ra ti o n
Si gn al Fai l ure/Acti on L og Info
Op eratio ns D ata
D3
Op eratio ns
Log
Se nd Al ert
Figure 2-104. Handle Signal Polling Data(August 2000)
CHART II Business Area Architecture Report
199
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.7.2 Respond to Exceeded Signal Threshold Alert
The Respond to Exceeded Signal Threshold Alert process is used to react to a situation where the
traffic signal data determines there is an abnormal traffic flow. Once the CHART II operator
acknowledges the alert, an Action Log is opened allowing the operator to record data about the
situation. In addition, the traffic flow data is displayed.
Respond to Exceeded Volum e Threshold Alert-10/21/99
1
Acknowledge
Alert
Alert Data
Date/Time/User
Alert Ackd
2
Initiate Action
Log
D1
Alert Data
Action Log Info
Action Log Opened
3
Threshold/Traffic Flow Data
Display Threshold
vs Traffic Flow Data
Pertinent Data Displayed
Log Action
Log
Figure 2-105. Respond to Exceeded Signal Threshold Alert(August 2000)
CHART II Business Area Architecture Report
200
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.7.3 Download Signal Data
The Download Signal Data process is a custodial process performed once a day to archive data
for each signal device. At a specified time, based on system parameters, the data for each signal
device is retrieved. If there is a failure of the device, the failure is logged in the Failure Log and
the device status is updated. If there is a command failure, it is logged in the Operations Log. If
the attempt to retrieve the data is successful, the device traffic data is manipulated, summarized,
and stored in an Archive data store.
CHART II Business Area Architecture Report
201
January 8, 2006
CHART II Business Area Architecture Report
Do wnl oa d Traffi c Co un ts -1 1/08 /9 9
D1
System
Parame ter
s
Do wnl oa d Start Ti me
1
D2
At Spe ci fi c Ti me
In ti ti ate Dow nl oad o f
Traffi c Co un ts
De vi ce
Con fi gu ratio n
Ec ono li te or
FMS
Traffic C oun t Do wnl o ad
4
Fo r Ea ch Si g nal Devi ce
Si gn al D evic es
4.1
Re tri eve Traffi c
Cou nt D ata
Re spo ns e from De vi ce
De vi ce Fai lu re
Co mman d Fai l ure
Ra w Tra ffi c Co unts
4.5
Ma ni pul a te /
Summa rize/
Store Traffi c
Cou nts
Fa il u re D ata
D3
Fa il u re
Log
Re tri eved Da ta
4.6
4.3
Lo g Sys te m
Ope ra ti o n
Lo g Fa il ure
Fa il u re L ogg ed
Al ert D ata
4.4
Se nd Al ert
Up date De vi ce
Status
Arch ive Traffic C oun ts
Lo g Data
D4
Arch ive
D5
Op eratio ns
Log
Figure 2-106. Download Signal Data(August 2000)
CHART II Business Area Architecture Report
202
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.8
AVL
The Automated Vehicle Location (AVL) processes group is comprised of processes that poll the
AVL devices which are on-line, processes AVL messages input by the operators of the devices,
and handles responses to alerts as a result of specific AVL messages which are transmitted.
2.2.4.4.8.1 Handle AVL Polling Results
The Handle AVL Polling Results process updates the results of periodic health checks of online
AVL devices. The frequency of polling these devices is controlled by System Parameters. The
AVL package will perform the actual communication with the devices at the specified frequency
and pass the resulting health check information to CHART II. If the device is okay (within
acceptable diagnostic parameters), the status of the device is updated to indicate a healthy status
and the date/time stamp of the last poll. If the device is not okay (outside acceptable diagnostic
parameters), the failure information is written to the Failure Log, an alert is sent, and the status of
the device is updated to reflect a failure status and the date/time stamp of the last poll. The
response to the failure alert will be handled by the Respond to Device Failure Alerts process at
paragraph 2.2.4.2.2.6.
Handle AVL Polling Res ults -12/15/99
D3
Alert Data
If OK
1
Update Device
Status
FMS/ AVL
COTS
If Failure
Vehicle Location & Speed
Device Status Refres hed
Store Alert Data
2
Log Failure
Failure Info
# of Failures before Alert
3
Update AVL
Map Layer
Failure Alert
Send Alert
D1
D2
AVL
Failure Log
Figure 2-107. Handle AVL Polling Results(August 2000)
CHART II Business Area Architecture Report
203
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.8.2 Perform AVL Function Processing
The following Perform AVL Function Processing processes are used to take the information that
has been received by the AVL devices, and process accordingly. Once the information has been
received, the incoming message is logged, the vehicle and operator call sign data is retrieved, and
the message type is determined for further processing. The five main messages to be handled
further are:

In/Out of Service

Mayday

Arrival On-Scene

Assisting Disabled Vehicle

Assisting Disabled CHART Vehicle

Available
Implementation Considerations:
The AVL solution is seen as being a COTS package, which initially will have limited
functionality. In the future, the AVL will interface more intelligently to allow the status from the
console to add to open logs, as well as allow for input of more message types and specific data
types.
CHART II Business Area Architecture Report
204
January 8, 2006
CHART II Business Area Architecture Report
FMS/C OTS
AVL Mess ag e/Cal l # /V ehi cl e ID/Loc ati on
2
1
Proc ess A VL Me ssa ges - 02/14 /0 0
Messag e Type/Call #/Vehicle Id/Date Timestamp
Log Incoming Message
Lo g System Ope ra ti o n
Lo g Data
Messag e
3
D3
De te rmi ne Mess ag e Typ e an d If Log Exi sts for Thi s Veh i cl e
D1
Ve hi cl e Data
Op eratio ns L og
Lo g ID a nd Type - If i t Exis ts
Assist Disabled CH ART Message/Log Id
Mayday Message/Log Id
As si st D is abl ed Mes sag e/Log Id
Avai la bl e Me ssa ge
Process AVL
Mayday Message
Process AVL Assist
Disable CHART
Vehicle Message
Process AVL
Assist Disable
Message
In or Out S ervi ce Mess age
On Sc en e Mes sag e/Lo g ID
Process AVL On
Scene Messag e
Process AVL In/Out
Service Message
Process AVL
Available Message
Figure 2-108. Perform AVL Function Processing(August 2000)
CHART II Business Area Architecture Report
205
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.8.2.1 Process AVL In/Out of Service Message
The Process AVL In/Out of Service Message process is used by the system to update the
CHART II system when a vehicle operator has chosen either the In Service or Out of Service
functions from the AVL device. The notification is received into the CHART II system and is
logged in the Communications Log. The vehicle status and operator call sign is stored in the
Vehicle Data store. Whether the In- or Out of Service functions are chosen, the device will either
be placed On- or Off-Line to either start or stop the polling process of the device.
Assumption: Operator call-sign will be captured by the AVL device system.
Process AVL
Messages
Process AVL In/Out Service Message -11/8/99
Message
1
In/Out Service
Message Recieved
In/Out Service Message
2
Open Comm Log In
T he Background
Log ID
Comm Log ID
3
D3
Communications
Log
Message/Vehicle ID/Call ID
Store In/Out Service
Message In Comm
Log
Info Stored
4
Close Log
Close Comm Log
Store Update
5
D1
Vehicle
Data
Vehicle ID/Call ID/Location/State
Store Updated Vehicle
State
Start/Stop Polling AVL Device
7
Set Device
Offline
If Out of Service Message
Set the AVL Device
Online or Offline
If In Service Message
Set Device
Online
Figure 2-109. Process AVL In/Out Service Message(August 2000)
CHART II Business Area Architecture Report
206
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.8.2.2 Process AVL Mayday Message
The Process AVL Mayday Message process is used by the system to notify the CHART II
operators when a vehicle operator has activated the Mayday functions from the AVL device (or
from some hidden button). The notification is received into the CHART II system and logged in
the Incident Log. An alert is sent to the CHART II operators, and the vehicle status and operator
call sign is stored in the Vehicle Data store.
Proces s AVL
Mes sages
Proces s AVL Mayday Mess age - 11/8/99
Mes s age/Call ID/Vehicle Id/ Any Exis ting Log ID
D3
Incident Log
Mayday Data
2
1
Store Data in Incident
Log
Mayday Mes s age
Recieved
If Incident Log Exists
Incident Log ID
If Incident Log Does Not Exis t
3
D4
Alert Data
Alert Data
Store Alert Data and
Send Alert
Alert Information
Send Alert
Info Stored
5
D1
Vehicle Data
Store Updated Vehicle
State
Vehicle ID/Call ID/Location/State
Figure 2-110. Process AVL Mayday Message(August 2000)
CHART II Business Area Architecture Report
207
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.8.2.3 Process AVL Arrival On-Scene Message
The Process AVL Arrival On-Scene Message process is used by the system to notify the
CHART II operators when a vehicle operator has chosen the Arrival On-Scene function from the
AVL device. The notification is received into the CHART II system and is logged in the Incident
Log, Disabled Vehicle Log, or Action Log for which the vehicle was dispatched. If a log does
not exist for which the vehicle was dispatched, an alert is sent to the CHART II operators, and
the vehicle status and operator call sign is stored in the Vehicle Data store.
Proces s AVL
Mes sages
Proces s AVL On Scene Mes sage - 11/8/99
Mes s age/Call ID/Vehicle Id/ Log ID If One Exists
2
1
Store Data in Open
Log
On Scene Mess age
Recieved
If An Incident or Dis abled Log Exists Related to Vehicle Id
Log ID
Incident Log Does Not Exis t
3
D3
Incident Log
D4
Alert Data
Alert Data
Store Alert Data and
Send Alert
Send Alert
Alert
Info Stored
5
D1
Vehicle Data
Store Updated Vehicle
State
Vehicle ID/Call ID/Location/State
Figure 2-111. Process AVL Arrival On-Scene Message(August 2000)
CHART II Business Area Architecture Report
208
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.8.2.4 Process AVL Assist Disabled Vehicle Message
The Process AVL Assist Disabled Vehicle Message process is used by the system to notify the
CHART II operators when a vehicle operator has chosen the Assist Disable Vehicle function
from the AVL device. The notification is received into the CHART II system and logged in the
Disabled Vehicle Log if a log entry has already been opened. If a log does not exist, then a new
one is opened. An alert is sent to the CHART II operators, and the vehicle status and operator
call sign are stored in the Vehicle Data store.
In evaluating an AVL solution, it would be desirable that the solution allowed for the driver to
input the type of assistance provided to the disabled vehicle.
Proces s AVL
Mes sages
Proces s AVL As s is t Dis abled Mess age - 11/8/99
Mes s age/Vehicle Id/ Call ID/Log ID If One Exists
2
1
Store Data in Dis abled
Log
Ass is t Disabled
Mes sage Recieved
If A Disabled Log Exists Related to Vehicle Id
Log ID
Dis abled Log Does Not Exis t
3
D3
Dis abled Log
D4
Alert Data
Alert Data
Store Alert Data and
Send Alert
Send Alert
Alert
Info Stored
5
D1
Vehicle Data
Vehicle ID/Call ID/Location/State
Store Updated Vehicle
State
Figure 2-112. Process AVL Assist Disabled Vehicle Message(August 2000)
CHART II Business Area Architecture Report
209
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.8.2.5 Process AVL Assist Disabled CHART Vehicle Message
The Process AVL Assist Disabled CHART Vehicle Message process is used by the system to
notify the CHART II operators when a CHART vehicle operator has chosen the Assist Disabled
CHART Vehicle function from the AVL device. The notification is received into the CHART II
system and logged in the Disabled Vehicle Log if a log entry has already been opened. If a log
does not exist, then a new one is opened. An alert is sent to the CHART II operators, and the
vehicle status and operator call sign are stored in the Vehicle Data store.
Figure 2-113. Process AVL Assist Disabled CHART Vehicle Message(August
2000)
CHART II Business Area Architecture Report
210
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.8.2.6 Process AVL Available Message
The Process AVL Available Message process is used by the system to notify the CHART II
operators when a vehicle operator has chosen the Available function from the AVL device. This
selection is used when a vehicle operator is leaving the scene in response to an Incident Log,
Action Log, or Disabled Vehicle Log. It lets the CHART II operators know the driver is
available to respond to other calls. The notification is received into the CHART II system where
vehicle status and operator call sign are stored in the Vehicle Data store.
Process AVL
Messages
Process AVL Available Message - 02/11/2000
Message/Vehicle ID/Call # / Log Id If One Exists For This Vehicle
1
D4
Action Log
Available Message
Recieved
Action Log ID
Message
D3
D5
2
Disabled Log
Disabled Log ID
Close Log- If One
Exists
Incident Log
Incident Log ID
Vehicle State Data
5
D1
Vehicle Data
Store Updated Vehicle
State
Vehicle ID/Call #/Location/State
Figure 2-114. Process AVL Available Message(August 2000)
CHART II Business Area Architecture Report
211
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.8.3 Respond to AVL Alerts
The Respond to AVL Alerts processes which follow are used to take the information received
from the alerts sent by the CHART II system display the alerts on the work station of the
CHART II operators.
2.2.4.4.8.3.1 Respond to AVL Mayday Alert
The Respond to Mayday Alert process is used when a person using an AVL device selects the
Mayday button. At the time the alert is acknowledged, the following information will be
displayed in graphical form on the map:

Icon showing vehicle location

Operator call sign

Vehicle ID Number

Mayday status

Last message transmitted from driver, plus time of message
In addition, a pop-up window will be displayed on the screen of the center and Maryland State
Police barracks responsible for responding to this AVL at its current geographical location. As
soon as the center operator acknowledges the alert, an Action Log will be displayed showing the
current information. As the situation progresses, the operator at the center will key the pertinent
information into the Action Log and close the log when appropriate.
CHART II Business Area Architecture Report
212
January 8, 2006
CHART II Business Area Architecture Report
Respond to Mayday Alert from AVL-10/20/99
1
Acknowledge
Alert
Date/Time and User
D1
Alert Data
Alert Data
Alert Ackd
2
Open Action
Log
Log Opened
Log Action Log
Figure 2-115. Respond to Mayday Alert from AVL(August 2000)
CHART II Business Area Architecture Report
213
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.8.3.2 Respond to AVL Arrival On-Scene Alert
The Respond to Arrival On-Scene Alert process is used when a person using an AVL device
selects the Arrival On-Scene button.
An alert will be shown to the CHART II operator at the center. Once the center operator
acknowledges the alert, either a new Incident Log will be displayed showing the current
information, or an existing Log will be opened which corresponds with the driver who was
dispatched and has arrived on the scene of the incident. The driver will contact the center and
report pertinent information (i.e., vehicle tag information, vehicle description) to be added to
Log. As the situation progresses, the operator will input additional information into the Log and
close it when appropriate.
Respond to Arrival On-Scene Alert from AVL-11/15/99
1
Acknowledge
Alert
7
Find One of Logs
D2
Incident
Log
Alert Data
D1
Alert Ackd
Incident Data
2
3
Find Log with
Dispatch Info
D3 Action Log
Alert Data
Date/Time and User
Log Exists
Open
Appropriate
Log
Action Data
No Log Exists
Disabled Data
Log Updated
6
D4
Disabled
Log
Inform
Operator that
no Dispatch
Exists
5
Update Log
Figure 2-116. Respond to Arrival On-Scene Alert from AVL(August 2000)
CHART II Business Area Architecture Report
214
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.4.8.3.3 Respond to AVL Disabled Vehicle Alert
The Respond to Disabled Vehicle Alert process is used when a person using an AVL device
selects either the Disabled Vehicle or the CHART Disabled Vehicle button.
An alert will be shown to the CHART II operator at the center responsible for the AVL equipped
vehicle. Once the center operator acknowledges the alert, a Disabled Vehicle Log will be
displayed showing the current information. If the alert is for a CHART vehicle, the vehicle data
(Vehicle ID, Call ID, Location) will be inserted into the log automatically. If the disabled vehicle
is a non-CHART vehicle, the driver will contact the center and report pertinent information (i.e.,
vehicle tag information, vehicle description) for addition to the Log. As the situation progresses,
the operator will input additional information into the Log and close it when appropriate.
Respond to Disabled Vehicle Alert from AVL-10/20/99
1
Acknowledge
Alert
Date/Time and User
D1
Alert Data
Alert Data
Alert Ackd
2
Open Disabled
Vehicle Log
Log Opened
Log Disabled
Vehicle Log
Figure 2-117. Respond to Disabled Vehicle Alert from AVL(August 2000)
CHART II Business Area Architecture Report
215
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.5
Alerts
The Alerts processes includes the common processes that physically send alerts required by other
processes and, if required by the alert type, checks for the need to re-route/re-send alerts due to a
non-response to an alert.
Alerts - 11/16/99
1
Alerts
1.3
Send Manual Alert
1.1
Send Alert
1.2
Escalate Alert
Figure 2-118. Alerts(August 2000)
CHART II Business Area Architecture Report
216
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.5.1
Send Manual Alert
The Send Manual Alert process is used by a CHART II operator to notify one of the shops of the
need for assistance during the following instances: disabled vehicle, congestion, special event,
weather sensor alert, weather advisory, action, or incident. While the CHART II operator is in
the associated log, the operator will have an option to Send a Manual Alert. Once this selection is
made, the operator is able to choose who will be alerted, what type of alert will be sent, and can
input additional text that the shop being notified will receive. When the CHART II operator is
satisfied with the alert to be generated a ‘Send Alert’ selection will be made, the alert will be
sent, and the operator returns to the associated log with the updated information about the alert
sent.
1
Need to Send
Manual Alert
Send Manual Alert-12/6/99
Format Alert
2
Select Center
Center Data
D1
Center
Center Selected
3
Select Alert
Type
Alert Types
D2
Functional
Responsibility &
Alert Type
Alert Type Selected
4
D3 Alert Data
Log Sy stem
Operation
5
Alert Data
Enter Alert Text
Alert Data Updated
Log Data
Alert Sent
Send Alert
D4
Operations
Log
Figure 2-119. Send Manual Alert(August 2000)
CHART II Business Area Architecture Report
217
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.5.2
Send Alert
The Send Alert process is used to send alerts to operators from various processes. Once it has
been determined an alert must be sent, the alert type and center information is retrieved; this
establishes where the alert must be sent. Based on the information received, the system retrieves
the users that are logged in at that location. If no users with the appropriate functional rights to
handle the alert are logged on, an alert failure is recorded and the next center in the hierarchy is
alerted through the Escalate Alert process. If no users are currently logged on, but the alert type
can wait to be received until a user does logon, the system will display the alert to the next user
to logon. If there are users logged on, the alert is sent and displayed on the operators’ screen.
Once a user acknowledges the alert, it is removed from the screen of other users at the receiving
center. All alerts are sent to a receiving center except the weather alert from the National
Weather Service. This alert will be sent to all users with the exception of the media. The
following list identifies the types of Alerts to be generated from the CHART II system :

Action from open report

Alarm Timeout Alarm

Device Failure from System

Equipment Request from open report

Transfer of Resources

Incident from open report (roadwork)

Incident from Detector

Incident from AVL

Disabled from AVL

Disabled CHART Vehicle from AVL

Mayday from AVL

Congestion from Detector

Response Plan Generation

Weather forecast

Weather Sensor

CHART II infrastructure failure

External source, incident

Delinquent Equipment Status
CHART II Business Area Architecture Report
218
January 8, 2006
CHART II Business Area Architecture Report
Send Alert - 10/6/99
Alert Must be Sent
Location and Alert Type
1
D1
Functional
Responsibility &
Alert Type
Retrieve Alert Type
Config Data
Alert Type Config Data
Config Data/Location/Alert Type
2
Retrieve Center
D3
Center
Centers Within the AOR for Alert Location and Type
Centers to Receive Alert Type
4
D4
User
3
Users Logged on at Center
Retrieve Users
Logged in at Center
Display Alert When Next
Person At Center Logs In
User Does Not Need to be Logged In
Alert to User
User Logged In
Alert Data for Storage
No User Logged In
6
Display Alert
Store Alert Data
D6
Alert Data
5
Fail Alert
Alert Not Sent Data
Alert Failed
Alert Sent Data
7
Log System
Operation
Log Data
Alert Failed- No User Logged In
D5
Alert Waiting Data
Operations
Log
9
Alert Type - Failed to Ack
Send Alert to Next
Center in Hierarchy
Figure 2-120. Send Alert(August 2000)
CHART II Business Area Architecture Report
219
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.5.3
Escalate Alert
The Escalate Alert process monitors those sent alerts that require a response within a specified
time frame. If no response is received, it accomplishes the necessary steps to escalate the alert up
the operation center hierarchy. This process will capture date and time of the failed response,
determine the next level of hierarchy and center with the appropriate alert type and area of
responsibility, and send the alert to this center. Until the alert is responded to or escalated to the
SOC, this process will continue to monitor and escalate the alert upwards through the center
hierarchy.
This process will also be used to escalate alerts when no user is logged on at the receiving center.
Escalate Alert - 10/7/99
1
D1
Alert Data
Current Alerts
Check Alert Data
Alert Ack - Max Time
Functional
D2 Res ponsibility &
Alert Types
Alert Needs Es calation
Send Alert
Send Alert to Next Center in Hierarchy
2
Escalate Alert to
Next Center in
Hierarchy
Alert Res ponsibility Data
Geographic Res ponsibility Data
D3
Geographic
Res ponsibility
D4
Operations
Log
Log Es calation
3
Log Sys tem
Operation
Log Data
Figure 2-121. Escalate Alert(August 2000)
CHART II Business Area Architecture Report
220
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.6 Plans
The Plans processes include all those processes necessary to define, setup and control the
activities involved in handling plans. These processes are divided into groups related to
maintaining and processing of plans.
Plans are sets of commands equivalent to functions that an operator might perform. A plan is
comprised of a set of commands which, when the plan is activated, are executed in sequence.
When a plan is deactivated, the converse of the individual commands is executed in sequence.
Plans - 9/8/99
1
Plans
1.1
Maintain Plans
1.3
Activate Plan
1.2
De-Activate Plan
Figure 2-122. Plans(August 2000)
CHART II Business Area Architecture Report
221
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.6.1
Maintain Plans
The Maintain Plans process provides for the establishment and maintenance of plans.
Plans may be used for such activities as displaying specified messages on DMS devices,
broadcasting of specified messages on HAR devices, setting devices on/off line, setting AVCM
presets, assigning cameras to wall monitor configurations, activating tours, plan
activation/deactivation, notifications, and logging.
A single plan may define the control of multiple devices, which will all be initiated by activating
the plan.
Maintain Plans - 9/27/99
1
Need to Maintain Plans
Schedule
Data
D2
Modify or Delete Selected
11
List Plans
List of Plans
Schedule Data
Plan List
Plan ID to Delete
14
Add Plan Selected
12
Select Plan
Selected Plan for Deletion
Check for Use in
Schedule
If Used
If Not Used
16
Delete
Message
Plan to Delete
Modify Plan Data
D1
8
4
Delete Plan from Database
While Updating a Plan
Deleted Plan
5
Add New Plan Name
4.2
Add Plan Data
Maintain Plan Associated Data
Updated Plan
13
Associated Plan Ev ent Data can be:
Set Device Online
Set Device Of f line
DMS Reset
Activ ate Tour
Control Wall Monitor Asssignment
Perf orm Notif ication
DMS: Display a Message/Beacon On/Of f
DMS: Blanks a Message/Beacon OFF
HAR: Broadcast a Message/ SHAZAM On/Of f
HAR: Blank/SHAZAM Of f
Disabled Log Report
Incident Log Report
Ref resh Def ault AVCM Presets
Store Updated Plan
Updated Plan Information
Change in Plans
D3
15
Log System
Operation
Operations Log
Log Data
Figure 2-123. Maintain Plans(August 2000)
CHART II Business Area Architecture Report
222
January 8, 2006
Plan
CHART II Business Area Architecture Report
2.2.4.6.2
Activate Plan
The Activate Plan process may be initiated by an operator, as an item in a schedule, or as a
response to a weather alert. If there is no log associated with the plan, this process initiates a log.
The type of log is dependent on the type of plan and the function it performs. The stored
commands are read from the plan and executed in sequence. Each command in the plan is
executed by interfacing with its related process/application.
1
Display Plan List
Activate Plan - 12/10/99
Plans
Plan List
2
D1
Plan
Select Plan
Selected Plan
4
Retrieve Plan
Information
Plan Information
Process Scheduler Event Start
Scheduler Priority for all Messages
Plan Info/Priority Operator if NOT Scheduler
Create Log
9
If Not Activated from
Log/Scheduler - Open Log
Log Id #
Log ID
3
For Each
Device/Notification/Report In Plan
Control Wall Monitor
Assignment
3.2
Control Wall Monitors
DMS - Arbitrate Message
Queue
Activate Tour
Activate Tour
DMS ID/ Message/Priority
Refresh Default
AVCM Presets
Refresh AVCM Presets
D3
Set Device Offline
Perform Action
Set Device Offline
Set Device Online
HAR - Arbitrate Message
Queue
Set Device Online
Perform Notification
Notify
HAR ID/Message/Priority
Log
DMS Reset
Reset DMS
Report
Disabled Log Report
Updated Log Data
3.8
Update Log
Update Information
Log Data
7
Log System
Operation
Command Info
D2
Operations
Log
This Log can be Special Event Log,
Congestion Log, Safety Message
Log or Weather Advisory Log.
Figure 2-124. Activate Plan(August 2000)
CHART II Business Area Architecture Report
223
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.6.3
Deactivate Plan
The Deactivate Plan process is activated by an operator or as an item in a schedule. The stored
commands are read from the plan and processed in sequence. A determination is made as to the
appropriate deactivation of the original command (for example, a DMS – Add A Message
command will have a deactivation command of DMS – Remove A Message). Some original
commands will logically have no deactivation command (for example, print a report command
would have no deactivation command). Each deactivation command derived from the plan is
executed by interfacing with the appropriate process or application. If, after all resources
associated with the plan are released, there are no other resources associated with log, the user is
asked whether the log should be closed. The log is then closed on confirmation.
1
Display Plan
List
Active Plan List
De-Activate Plan - 12/10/99
Plans
2
Select Plan
D1
Active Plan
Plan
Plan Info
3
Process Scheduled Event End
Scheduler Log ID
Retrieve Plan
Information
Plan Data
4
Retrieve Log Id
D3
Log Id
Log
Log ID and Plan Data
DMS -Arbitrate
Message
Remove DMS Message from Queue
5
Release All
Resources In
Plan
If All Resources in Log Are Released
Close Log
Close Log Confirmed
HAR - Arbitrate
Message
Remove HAR Message from Queue
Log Plan De-Activation
6
7
Confirm Close
Log
Log System
Operation
Log Data
D2
Operations
Log
Figure 2-125. Deactivate Plan(August 2000)
CHART II Business Area Architecture Report
224
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.7 Scheduled Events
The Scheduled Events processes include those processes necessary to define, setup and control
the activities involved in handling scheduled events. These processes are divided into two
individual processes related to maintaining and processing of scheduled events. The following
figure identifies each group.
Scheduled Events - 11/16/99
1
Scheduled Events
1.3
1.1
1.2
Maintain
Sc heduled
Events
Pro cess
Sc heduled
Events Sta rt
Pro cess Sche duled
Events End
Figure 2-126. Scheduled Events(August 2000)
CHART II Business Area Architecture Report
225
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.7.1
Maintain Scheduled Events
The Maintain Scheduled Events process is used to add, modify, or delete schedules and the
activities involved in handling a scheduled event. Schedules include identification of the
schedule and date/time stamps for starting and stopping the execution of the activities. Some of
the activities to be executed within a schedule are; setting devices on/off line, DMS displays,
HAR messages, AVCM presets, wall monitor configuration, tours, plan activation/deactivation,
notifications, and reports. All activities within the schedule are executed in sequence at the start
time of the schedule.
The system needs to be able to process scheduled events based on time of day, day of week, day
of month, and also provide operator control to manually initiate and terminate any schedule.
The maintenance of scheduled events is a System Administrator process.
Each schedule will include the type of activity to which it’s related so that a corresponding type
of Activity Log may be generated to track the CHART activity. Schedule types will include
Special Events, Recurring Congestion, and Safety Messages.
CHART II Business Area Architecture Report
226
January 8, 2006
CHART II Business Area Architecture Report
9
M a i n tai n Sc h e d u l e rEv e n ts - 8 /2 6/9 9
Need to Maintain Scheduled Events
Add New Event
Modify/Delete
1
SelectNew
Scheduled Event
Name
2
List Scheduled
Events
New Event
Events
List
16
8
4
Determine Scheduled
EventType
SelectScheduled
Event
List Data
10
WhileNot Done
DeleteEvent
DeleteScheduled
EventData
Deleted Data
Eventto Modify
10.1
List Associated Data
Associated Data
New Data
List ofEvent Data
10.2
Select
Associated
Data
D1
Scheduler
Data
Data toMaintain
10.3
Maintain Associated Data
Scheduler Date/Time Data
D2
Operations Log
14
Checkfor Scheduler
Conflicts
Log Data
If No Conflicts
15
Log System
Operation
7
Updated Data
Store Scheduled Event Data
Scheduler Data
*** Associated Scheduler Event Data can be:
Set Device Online
Set Device Offline
DMS Reset
Activate Tour
Control Wall Monitor Assignment
Perform Notification
DMS: Display a Message/ Beacon On/Off
DMS: Blanks a Message/Beacon Off
HAR: Broadcast a Message/SHAZAM On/Off
HAR: Blank/SHAZAM OFF
Disabled Log Report
Incident Log Report
Refresh Default AVCM Presets
Activate a Plan
De-Activate a Plan
_____________________________________
Scheduled Event Type can be (First Draft List):
Specisl Events
- Orioles
- Ravens
- Concert
- Parade
Construction
Congestion
Administrative
- Reports
- EORS Upload
Figure 2-127. Maintain Scheduled Events(August 2000)
CHART II Business Area Architecture Report
227
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.7.2
Process Scheduled Events Start
The Process Scheduled Events process is a custodial process. The system will open a log (based
on type of scheduler event – recurring congestion, special event, or safety message) and begin
executing the activities of the schedule according to the date/time stamp of the schedule
information. Each activity is processed in sequence. Each activity in the schedule is executed by
interfacing with its related process/application.
CHART II Business Area Architecture Report
228
January 8, 2006
CHART II Business Area Architecture Report
1
At Specified Start T ime
1.1
Retrieve Scheduled
Event Information
Scheduler Info/Log T ype
D2
Scheduler Data
Process Scheduled Events Start - 12/10/99
Scheduler Header/Events
Log Id
1.3
Create Log
Create Log T ype
Event List
1.2
For Each Device/Plan/Notification
HAR - Arbitrate
Message Queue
Activate Plan
1.2.1
HAR ID/ Message/Scheduler Priority
Scheduler Priority for any Messages
D4
DMS - Reset
Control Wall Monitor
Assignment
Reset
Set Device Offline
Device Offline
Action SHAZAMOn
DMS ID/ Message/Scheduler Priority
DMS - Arbitrate Message
Queue
Perform Action
Activate Tour
Perform Notification
Action Activate Tour
Set Device Online
Device Online
Action Perform Notification
Action Generate Report
Activation Results Data
1.2.2
Update Log
Updated Log Data
Scheduler Activation Data
4
Log Operations Log
D3
Operations Log
Log Info
Figure 2-128. Process Scheduled Events Start(August 2000)
CHART II Business Area Architecture Report
229
January 8, 2006
Report
Recurring
CongestionSafetySpecial
Events
Log
CHART II Business Area Architecture Report
2.2.4.7.3
Process Scheduled Events End
The Process Scheduled Events End process retrieves the Log ID of the associated log and calls
the Close Log process to release all shared resources. If the scheduled event will not be repeated,
it is deleted from the system.
Log can be:
Recurring Congestion
Special Event
Safety
Process Scheduled Events End - 12/10/99
1
At Specified End Time
1.1
Retrieve Log ID
Log Id
D4
Log
Event List
1.2
Close the Log
Releasing All
Resources
Close Log
Log Type and Id
Evaluate if Schedule is Repeated
1.3
If Scheduled Event
Not Repeated Delete Item
Delete Item
D5
Scheduled Data
D3
Operations Log
Log Scheduled
1.4
Log Operations Log
Log Data
Figure 2-129. Process Scheduled Events End(August 2000)
CHART II Business Area Architecture Report
230
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.8 EORS Interface
The EORS Interface processes include all those processes necessary to identify and process road
construction-related closures and tracking of declared snow emergencies at the county level. The
following figure identifies the individual processes within each group.
EORS Interface - 10/7/99
1
EORS Interface
1.1
Construction
1.2
Snow Emergency
1.3
Phone Book
1.1.1
1.2.1
1.3.1
Download EORS
Permits
Maintain Snow
Emergency
Declaration
Access Phone Book
1.1.3
Activate EORS
Icon on Map
1.1.2
Activate EORS
Permit
Figure 2-130. EORS Interface(August 2000)
CHART II Business Area Architecture Report
231
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.8.1
Construction
The Construction group of processes identifies how road construction requests are received into
the system (Download EORS Permits), how the EORS permits are displayed (Activate EORS
Icons on Map), and how the permits are activated (Activate EORS Permit) as Incidents.
2.2.4.8.1.1 Download EORS Permits
The Download EORS Permits process is used to download information on planned road
construction-related closures from the EORS system. The information from EORS is two-tiered
with permit information on the first tier and schedule information associated to the permit on the
second tier. This is a custodial process, which, at a parameter specified time interval, retrieves
the EORS information for a parameter specified time period and stores the permit and schedule
information in the CHART system. The primary intent of this process is to download the permits
for the next day or two so they can be available on CHART before the road closures take place.
The process also determines if there is a conflict with a special event item scheduled during the
same time frame and stores conflict data with the permit data.
Download EORS Permits -11/10/99
EORS
EORS Permits
1
At Parameter Specif ied Interv al
1.1
D3
Scheduler
Data
Scheduler Data
Retriev e Permit Inf o f rom
EORS
Download Frequency
D2
System
Parameter
Permit Inf o for Storage
1.3
Check for and Flag
Scheduler Conf licts
Permit and conf lict data
1.2
Store Permit Inf o
Permit Inf o
D1
Permit
Inf ormation
Figure 2-131. Download EORS Permits(August 2000)
CHART II Business Area Architecture Report
232
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.8.1.2 Activate EORS Icons on Map
The Activate EORS Icons on Map process is a custodial process in which the system periodically
analyzes the downloaded EORS permit information. For those permits scheduled to start within a
parameter specified time period, it generates map icons for these permits in preparation for the
Activate EORS Permit process.
Activate EORS Icon on Map - 9/17/99
1
Retrieve EOR Icon
Time Period
Parameter
D1
Display Start Time
System
Parameter
At Parameter Specified Time
2
When Scheduled
2.1
Create Map
Icon
Permit Info
2.2
Associate
Permit Data
EORS Permit Data
2.3
Store Map Data
Map Permit Data
D2
EORS Map
Data
Figure 2-132. Activate EORS Icons on Map(August 2000)
CHART II Business Area Architecture Report
233
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.8.1.3 Activate EORS Permit
The Activate EORS Permit process provides the capabilities for operators to initiate Incident
Logs related to lane closure(s) due to road construction. Operators receive phone calls from the
construction crews advising them that one or more lanes will be blocked and providing the
permit information relative to this closure. The operator selects the relative EORS permit icon
and indicates the start time and specific lanes for the closure. The system checks the current
status of the location of the intended closure and notifies the operator of any planned special
events and current incidents or congestion. The operator may deny activation of the permit based
on this information. If the operator determines conditions are acceptable for permit activation,
the system generates an Incident Log and performs the usual Log Incident Log process steps.
Information is sent to the EORS system to indicate activation of the permit/schedule item.
From this point the operator may decide to either transfer the responsibility for this incident to
another center or manage the incident from his/her center.
CHART II Business Area Architecture Report
234
January 8, 2006
CHART II Business Area Architecture Report
1
Receive EORS
Permit Activation
Notification
Activate EOR Permit - 12/6/99
Lane Level location info
D5
7
Special Event Data
Special Event
Log
Check for
Incident/Activity
Conflict
Congestion
Log
D4
Congestion Location Data
Incident Location Data
Incident Log
No Conflict
Conflict
8
2
Operator Evaluation
Select Permit on
Map
Conflict - Operator Override
D3
Incident Log ID
Log Incident Log
Lane-level Construction Info
Conflict - Cancel Permit
Permit Activation Info
9
6
Activation Not Allowed
Check Permit Start
T ime
If After Start T ime
Permit Start T ime
Permit Conflict Data
3
EORS Permit
Information
D1
Permit Info
Store Permit
Activation Info
Activation Info
EORS
Display Info
Permit Data
Log Operator Action
4
5
Log System Operation
If Not Reponsible Center
T ransfer Resources
Display Active
Permit on Map
Log Data
D2
Operations Log
Figure 2-133. Activate EOR Permit(August 2000)
CHART II Business Area Architecture Report
235
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.8.2
Snow Emergency
The Snow Emergency process group identifies county-level snow emergency declarations and
provides a visual display of the declared/not declared counties. This information is provided to
the operators to assist in wintertime traffic management.
2.2.4.8.2.1 Maintain Snow Emergency Declaration
The Maintain Snow Emergency Declaration process is a custodial process that periodically
interrogates information in the EORS system related to county snow emergency declarations.
When it is determined that a county has declared a snow emergency, a county-based snow
emergency map layer is updated, a response plan is activated, and specified individuals and
organizations are notified. As snow emergencies are canceled, the map layer is updated and the
Weather Advisory Log is closed.
CHART II Business Area Architecture Report
236
January 8, 2006
CHART II Business Area Architecture Report
Ma in ta in S now E mer. De cl arati on -2/14/0 0
6
EOR S
Sn ow Eme rg Ca nc el le d
Re cei ve Noti ce of
Sno w Emerge ncy
Can cel l ati on
Cl os e Log
Cl os e Weathe r
Advis ory L og
Sn ow Eme rg enc y De cl ared
1
Re cei ve Sno w
Emerge nc y
Dec la ra ti o n
D1
Co unty/Sta rt Tim e
Co unty Sn ow
Emerge nc y
Data
Sn ow Eme rg enc y Lo cati on
2
Ad d Emerge ncy to
Map L ayer
D2
Sn ow Area
Co unty Sn ow
Emerge nc y Map
Data
No ti fy Cen ters
5
No ti fy Al l Ce nters
Pe rform Noti fi ca tio n
No ti fy Cen ters of S now Em ergen cy
De te rmi ne Pla n to Exe cute
Ac ti va te Pl an
Lo g Acti on s
4
Lo g System
Ope ra ti on
Lo g Data
D3
Op eratio ns
Log
Figure 2-134. Maintain Snow Emergency Declaration(August 2000)
CHART II Business Area Architecture Report
237
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.8.3
Phone Book
The Phone Book group consists of a single process: Access Phone Book.
2.2.4.8.3.1 Access Phone Book
The Access Phone Book process is a way for CHART operators to view the CHART Phone
Book being maintained under the EORS application. No process flow is shown for this process.
The CHART system must provide a front-end access point to the Phone Book application built
into EORS.
CHART II Business Area Architecture Report
238
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.9 Weather Support
The Weather Support processes include all those processes necessary to define how National
Weather Service alerts and hazardous driving
conditions will be detected and communicated.
Weather Support -11/15/99
These processes are divided into groups related to National Weather Service and SCAN. The
following figure identifies the individual processes within each group.
1
Weather Support
1.1
National Weather Service
1.2
Scan
1.1.1
View National
Weather Service
Data
1.2.1
Handle Weather
Sensor Data
1.1.2
1.2.2
Process Weather
Alerts from the
NWS
Generate
Weather Sensor
Response
1.1.3
1.2.3
Respond to
Weather Sensor
Alert
Respond to NWS
Alert
1.1.4
Fax Weather
Report
Figure 2-135. Weather Support(August 2000)
CHART II Business Area Architecture Report
239
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.9.1
National Weather Service
The National Weather Service (NWS) group of processes identifies how National Weather
Service data is viewed (View National Weather Service Data), how alerts from the National
Weather Service will be handled (Process Weather Alerts from the National Weather Service),
and how notifications are made (Fax Weather Report).
2.2.4.9.1.1 View National Weather Service Data
The View National Weather Service Data process provides operators with the capability to view
National Weather Service data stored on the SHA Web pages. From the CHART navigator,
operators can select the specific NWS weather data/web page they need to view. If the browser
has not been opened, the browser on the selected page will be opened. If the browser is already
open, the selected page will be displayed in a new window/page over the current one on the
browser (rather than opening a new browser). This is done to keep the memory requirements
minimized for the workstation, as well as, keeping clutter off the operator’s display.
View NWS Da ta - 8/10 /99
1
List Weather
Ser vice Web
Pages
Wea the r Servi ce Web Pages
2
If Br ow ser is Closed
Select Weather
Ser vice Web
Page
If Br ow ser is Open
3
4
Ope n Brow ser w ith
selected Page
Change to
Sel ecte d Page
Comma nd to Open At Spe cified Page
Comma nd to Change to Spec ified Page
Web
Bro w ser
Figure 2-136. View National Weather Service Data(August 2000)
CHART II Business Area Architecture Report
240
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.9.1.2 Process Weather Alerts from the National Weather Service
The Process Weather Alerts from The National Weather Service process is used to detect and
alert operators if the National Weather Service has issued/updated any severe weather alerts. This
is a custodial process that checks the file size of NWS alert file on the SHA Web server. If the
file size is greater than a specified size a weather alert is sent to all users with the exception of
the media.
Process NWS Alert - 10/26/99
1
Retrieve Parameter
Data
Parameter data
D1
System
Parameter
Time Interval
2
At Specified Time Interval
2.1
Check Weather Service
Alert File Size
File Size
D2
NWS Alert
File
If File Size is Greater Than Default
4
D4
Alert Data
Store Alert Data
Send Alert to Everyone
Allowed - no media
Weather Alert Information
Send Alert
Weather Service Alert Data
D3
5
Log Data
Operations
Log
Log System Operation
Figure 2-137. Process Weather Alerts from National Weather Service(August
2000)
CHART II Business Area Architecture Report
241
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.9.1.3 Respond to National Weather Service Alert
The Respond to Weather Alert process is used to allow the individual being sent the Weather
Alert to acknowledge it. When the alert is acknowledged, the date and time is captured, and the
weather alert is displayed.
10/6/99
1
Date/Time and User
Acknowledge
Alert
Alert Data
D1
Alert Data
Alert Ackd
3
Display Weather
Alert
Figure 2-138. Respond to National Weather Service Alert(August 2000)
CHART II Business Area Architecture Report
242
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.9.1.4 Fax Weather Report
The Fax Weather Report process will periodically distribute weather reports via fax to specified
recipients. The weather report is retrieved from the SHA Web server at a system parameterspecified frequency. A fax is then formatted and sent to recipients identified in the Notification
List.
Fax Weather Report -11/10/99
1
At a Polling Interval
D5
System
Parameters
D2
Weather File
1.1
Check for Weather
Report Update
Weather File Polling Interv al
Weather File
Weather Report Updated
1.2
Create Fax
Formatted Fax
Perf orm Notif ication
Log Weather Notification
6
Log Sy stem
Operation
Log Data
D4
Operation Log
Figure 2-139. Fax Weather Report(August 2000)
CHART II Business Area Architecture Report
243
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.9.2
SCAN
The SCAN group process is used to handle sensor information captured from specific locations
along the roadways and to provide traveler information based on deteriorating conditions.
2.2.4.9.2.1 Handle Weather Sensor Data
The Handle Weather Sensor Data process is used to process information received from the
SCAN database and to enable the information to be communicated via the CHART system. The
CHART system polls the SCAN database and, if there is no device failures reported, the CHART
system stores and evaluates the information received. Weather sensor data received from SCAN
is updated to CHART to show the current device status. Weather and road condition data is
analyzed against device specific thresholds to determine if conditions necessitate notification of
poor weather or roadway conditions. If poor conditions exist, processing will continue to the
Generate Weather Sensor Response process.
This process assumes an interface with the SCAN database to obtain weather sensor status and
data. These sensors are polled on a low frequency basis possibly due to the current
communications architecture between the SCAN server and sensors (long distance dial-up).
Should the frequency of polling need to be significantly increased, analysis of alternative
communication options could be reviewed with an eye towards an FMS/PBX type interface that
might provide a cost trade-off to be considered; lower communications versus FMS/PBX
development and implementation costs.
CHART II Business Area Architecture Report
244
January 8, 2006
CHART II Business Area Architecture Report
SCAN
Handle Weather Sensor Data -11/15/99
Sensor Data
Request Inf ormation
7
Poll Scan
Database
D1
Polling Frequency
Failure Log
Failure Inf o
OK Status
Failure Status
2
1
Log Failure
Store Sensor Data
Sensor Data f or Storage
D2
Pav ement and
Weather Sensor
Data
D10
Data f or Ev aluation
Updated Status
Store Alert Data
3
8
Update Dev ice
Status
D9 Alert Data
Sensor Status
Evaluate Data
Thresholds
If Dev ice Threshold Change
Alert on Dev ice Failure
6
Send Alert
Update Dev ice
On Map
If Alert Threshold Reached
Generate Weather
Sensor Response
Figure 2-140. Handle Weather Sensor Data(August 2000)
CHART II Business Area Architecture Report
245
January 8, 2006
Weather
Station
CHART II Business Area Architecture Report
2.2.4.9.2.2 Generate Weather Sensor Response
When the evaluation of weather sensor data in Handle Weather Sensor Data shows a change to
hazardous weather or roadway conditions, the system generates a weather sensor response plan
to notify travelers of the potential danger. Messages that are for DMS and HAR devices are
retrieved from a plan associated with the specific weather sensor, or created from pre-defined
message generation rules. Any required notification is sent to the proper recipients and, if also
required, an alert is sent.
There is a need to be able to provide different response schemes for different weather or roadway
conditions, for example: wind, fog, frozen pavement, etc.
This process assumes that a response plan may be a combination of an existing plan and rulesbased responses.
Based on system parameters, an alert may be sent to the responsible operation center to request
activation of the response plan, or to notify the responsible center of the activation of the
response plan.
CHART II Business Area Architecture Report
246
January 8, 2006
CHART II Business Area Architecture Report
Generate Weather Sensor Response - 12/6/99
HandleWeather
Sensor Data
Weather ThresholdChange
D9
Pavement
Sensor Data
12
Sensor ID/Log ID -Flag as Used
Sensor Location and Data
D8
Weather Sensor
Log
D1
Device
Configuration
D10
Plan
D4
Message Rules
D5
Notification List
D12
Response Plan
CreateWeather
Sensor Alert Log
D11 Sensor Data
Sensor ID - Flaggedas used in log
Weather Sensor Alert Log Id
Log ID
4
Determine Response
Devices From Sensor
Location
Devices in Area
Devices
19
Determine if a Planis
Available
Plan
Plan Data
8
Build Weather
Response Messages
Weather Rules
Devices & Messages
9
Determine Notification
List
Weather Notify List
If No Confirmation Required
20
Store Response Plan
SystemGeneratedResponse Plan
Response Plan Stored
21
Determine If
Confirmation Required
Confirmation Required
Confirmation NOT Required
18
14
Generate an Alert
Activity Log ID & Response Plan
Activate Weather
Response
D7
Alert Data
If AlertNotificationRequired -Store Data
Log ID& ResponsePlan
Activate Response
Weather ResponsePlan
If AlertRequired
Log Confirmation Required
Send Alert
Log Weather Response Plan Activation
17
Log Data
Log System Operation
D3
Operations Log
Figure 2-120. Generate Weather Sensor Response(August 2000)
CHART II Business Area Architecture Report
247
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.9.2.3 Respond to Weather Sensor Alert
If confirmation of a weather sensor response plan is required, an alert is sent to the operator(s) at
the center responsible for the sensor that triggered this process. Once a user acknowledges the
alert, a Weather Sensor Alert log is displayed with the location of the sensor, time of detection,
the system generated response plan, and any other information. The operator may then activate
the response plan or cancel the plan. If the plan is cancelled, the operator is allowed to flag the
weather sensor for a user-determined period of time so future evaluation would not trigger the
generation of another response plan. While the Weather Sensor Alert Log is open, the triggering
sensor device will generate no new alerts. Once the sensor returns values within normal
parameters the log is closed.
The system may also be configured to alert the operator that a weather sensor response plan has
gone into effect.
CHART II Business Area Architecture Report
248
January 8, 2006
CHART II Business Area Architecture Report
1
Acknowledge
Alert
Ack Alert
2
Respond to Weather Sensor Alert - 12/8/99
D1
Alert Data
Log ID
View Weather
Sensor Alert Log
Weather Sensor Alert Log Data
Log Open
D7
Response
Plan
3
Open System
Generated
Response Plan
Response Plan
Activate Response
If Confirmation Required
4
User
Updates/Confirms
System Generated
Response Plan
Weather Response Cancelled
D4
5
CloseLog
Weather Sensor ALert Log ID
Cancel the Weather
Sensor Alert Log
Response Plan Data
Plan Inactive - Confirmed- Plan OK/Updated
6
Activate System
Generated Response
Plan
Plan Active - OK
Plan Active- Needs Modification
Log Close
9
D5
Pavement and
Weather
Sensor Data
Default Disable Time Period
User Flags Sensor No Weather
Response Alert
10
11
Plan Active - Needs
Modification
Plan Active and OK
Activated Response
Time Period Disabled
Open Log for Modification
Log Weather
Sensor Alert Log
8
Store Response Plan
with Log
Actived System Generated Response Plan
Log Operator Response
Log Cancellation Data
Log Plan OK
Log Activation
7
Log System Operation
Log Data
Figure 2-141. Respond to Weather Sensor Alert(August 2000)
CHART II Business Area Architecture Report
249
January 8, 2006
D2
Operations
Log
Weather
Sensor
Alert Log
CHART II Business Area Architecture Report
2.2.4.10 Archiving and Reports
The Archiving and Reports process group is separated into two groups: Archiving processes and
Report processes.
Archiving and Reports - 12/15/99
1
Archiving and Reports
1.4
Archiving
1.1
Reports
Figure 2-142. Archiving and Reports(August 2000)
2.2.4.10.1 Archiving
Archiving is a function that allows large amounts of information to be stored for later purposes.
The primary uses of archived information are:

Information will be available for other Maryland state agencies,

Information will be used for CHART II simulation,

Information will be available for legal purposes, and

Information will be used for generating various reports.
CHART II is intended to maintain a 14-day operational set of data for use by the online
operational parts of the system. At the end of each day, the current day’s data will be copied or
CHART II Business Area Architecture Report
250
January 8, 2006
CHART II Business Area Architecture Report
added to the Archive data set, so that the Archive data should never have more than a 24-hour
lag in data. It is also intended that log data will be both added and updated to the Archive data
set. This implies that open logs may exist in the Archive data set, which may be updated as a
result of the next day’s processing in the operational system, and then be updated the following
day in the Archive.
To maintain the 14-day operational data set, the oldest day’s data need to be deleted from the
operational data set each day after the Archive data is processed. An exception to this is open
logs, in that they must remain on the operational data set until they are closed and reflected in the
Archive. The following diagram illustrates the concept for adding/updating to the Archive and
maintaining 14 days worth of data in the Operational database.
OPERATIONAL DATABASE
TODAY
TODAY
-1
TODAY
-2
TODAY
-3
TODAY
-4
TODAY
-5
TODAY
-6
TODAY
-7
TODAY
-8
UPDATES
TO THE
ARCHIVE
TODAY
-9
TODAY
10
TODAY
-11
TODAY
-12
TODAY
-13
TODAY
-14
TODAY
-XX
DELETE
CLOSED
LOGS FOR
TODAY
-14 AND
OLDER
ADDITIONS TO THE ARCHIVE
ARCHIVE
DATABASE
In order to understand the Archive, it is most important to understand what data will be kept in
the Archive. The table below shows the data types of the CHART II system, and identifies which
data types are/are not planned to be stored in the Archive.
CHART II Business Area Architecture Report
251
January 8, 2006
CHART II Business Area Architecture Report
Data Type
Archive
No
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
No
Yes
Yes
Yes
Yes
Yes
No
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Address Book
Alert Data
AVCM (Video)
AVL
Center
CHART Map Data
County Snow Emergency Data
Detector
Device Status
Dictionary
DMS
EORS Data
Equipment Data
Failure Log
HAR
Incident Interchange Database
Link
Location Navigation Information
Logs
Message Rules
Operations Log
Plan
Scheduler Data
Sensor Data
System Parameter
User
The concept for capturing Archive data is to perform a daily add/update from the operational
database to the archive database. The table below shows which data types will be added,
updated, or both.
CHART II Business Area Architecture Report
252
January 8, 2006
CHART II Business Area Architecture Report
Data Type
Add /Update
Add
Add
Add
Add
Add
Add
Add
Add
Add
Add
Add
Add
Add
Add/Update
Add
Add
Add
Add
Add
Add
Alert Data
AVL
Center
CHART Map Data
County Snow Emergency Data
Detector
Device Status
DMS
Equipment Data
Failure Log
HAR
Incident Interchange Database
Link
Logs
Operations Log
Plan
Scheduler Data
Sensor Data
System Parameter
User
CHART II Business Area Architecture Report
253
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.10.1.1 Archive Update – Add
The Archive Update-Add process is a custodial process. The operational database will contain 14
days of operational data. Each day begins with 14 days of data. At a pre-determined time, the
current day’s information (Day 15) will be copied to the archive, unless in the case of Logs, the
log is still open. The flow pictured below shows the addition of Day 15 operational data to the
archive.
Archive Update Additions 12/10/99
4
Find Data to be Added to Archive
Date/Time of Last
Update
D5
Archive Data
Archive
3
Data Added
Add Data to Archive
Figure 2-143. Archive Update - Add(August 2000)
CHART II Business Area Architecture Report
254
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.10.1.2 Archive Update – Update Log Data
The Archive Update-Update Log Data process is a custodial process. In the case of logs that
remain open, instead of the information being copied, the information will be updated to reflect
the most current information. This is to reflect any changes in the logs that have been made since
the last data transfer. To see which data types will be updated – as opposed to only copied – see
the table above.
Before any data from the logs can be transferred, the database must be analyzed for changes:

Logs that have been closed since the last update will be copied to the Archive.

Logs which have been closed, but are still within the 14-day operational database, and
have been updated since the last Archive update, will be updated in the Archive.

Logs that remain open, and have been updated since the last update, will be updated in
the Archive.

For logs that remain open, and have not been updated since the last update, no data
transfer will take place.
The flow pictured below shows the process.
CHART II Business Area Architecture Report
255
January 8, 2006
CHART II Business Area Architecture Report
Archive Update - Update Log Data - 12/10/99
D1
Log
Date/time of Last Archive
Log Data
1
Analyze Log Data
Log Open-Not Updated
Log Closed
Log Open Updated
Log Closed-Updated
3
2
Update Data in
Archive
Copy Data to
Archive
4
No Updates
Made to
Archive
Data Updated
Data Copied
5
D2
Archive
Update Data
Update Time of
Last Update
Figure 2-144. Archive Update – Update Log Data(August 2000)
CHART II Business Area Architecture Report
256
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.10.1.3 Real Time System Update – Delete
The Real Time System Update-Delete process is a custodial process. In order for the real time
system to remain optimized, it is necessary to keep it manageable in size. To accomplish this,
only 14 days of data will be kept in the database.
Once the Day 15 data has been copied to the Archive, Day 1 data is deleted from the operational
database. The only data that will not be deleted are logs that are still open.
Operational Database Update - Delete -- 12/8/99
D1
Operational Database
Day 1 Data to be Deleted
1
Delete Data
Figure 2-145. Real Time System Update - Delete(August 2000)
CHART II Business Area Architecture Report
257
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.10.2 Reports
The Reports section is separated into two groups: Operational Reports, and Reports From
Archive.
2.2.4.10.2.1 Operational Reports
The Operational Reports process group includes those processes that provide reporting
capabilities to CHART users in the areas of operational reports, administrative reports, and
management/statistical reports. The data for these reports will be taken directly from the real
time system, which contains 14 days of data plus data for all logs that remain open.
For the purposes of the BAA Report, it is assumed that CHART II will utilize a commercial-offthe-shelf (COTS) package as a report development and generation tool. This position further
assumes that the COTS package will provide process capabilities for the input of selection or
filtering data and will provide on-screen viewing and hard copy printout capabilities. This COTS
approach reduces the Reports process flow to a description of the steps for the user to take to
select the specific report to be produced.
The Reports process provides the user with the capabilities to select a report from one of three
lists of reports. Once a report is selected, the operator will interface with the COTS report writer
to define the selection criteria for the report (if required), to select the number of copies, and to
direct the report to a specific printer.
The specific reports defined are the following:
Operational Reports
1. Center Situation Data
2. Disabled Vehicle Log
3. Incident Log Report
Administrative Reports
1. Device Report
2. Device Failure Report
3. User Activity Report
4. Center Activity Report
5. Communications Log Report
6. Device Configuration Report
Management/Statistical Reports
1. DMS Usage Classification Report
2. DMS Usage Message Type report
3. HAR Usage Classification Report
4. HAR Usage Message Type Report
5. ERU/ETP Assist Type Report
6. ERU/ETP Total Assists Report
7. ERU/ETP Average Response Times
CHART II Business Area Architecture Report
258
January 8, 2006
CHART II Business Area Architecture Report
8. Incident Clearance Time Report
9. Incident Roadway Capacity Restoration Report
10. Incident Duration by Type
11. Alarm Acknowledgement Report
12. Detection Subsystem Report
13. Shop Equipment Report
Reports - 10/6/99
Report Inf o
1
Operational Selected
List Report Ty pes
D1
System
Parameters
Management Selected
Administrative Selected
2
3
4
List Operational
Reports
List Administrativ e
Reports
List Management
Reports
Operational Report List
Admin Report List
5
Report List
6
Select
Administrative
Report
Select Operational
Report
7
Select Management
Report
Report Ty pe Admin
Report Ty pe Oper
8
Send Report Ty pe to
COTS Report
Package
Report Ty pe
Management Report Type
COTS Report
Package
Figure 2-146. Reports(August 2000)
CHART II Business Area Architecture Report
259
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.10.2.2 Reports from Archive
In addition to the standard reports identified in Section 2.2.4.10.2.1 Operational Reports, the
following reports will be needed:
Operations
1. Weather detectors/road conditions
2. Percent down (system components, devices)
Management
1. Workload reports (open vs. activities)
2. Resource utilization (ETP vs. Logs, coverage area)
3. Cost of Incident Clearance (cost based on duration and dispatched vehicles)
Performance Management
1. Meantime to clear incidents/congestion
Reporting Characteristics/Types
1. Interface to allow users to select what they want and for what timeframe.
2. Access to all information captured:
 Signs displayed
 Logs
 Detector information
 Sensor data
3. Logs reports
4. Detection data and graphs (traffic flows)
5. Geographical selection
6. Recurring vs. Ad Hoc reports
7. Paper reports and electronic reports (converted to file for e-mail)
8. E-mail capability once report generated
9. Reporting of report usage
CHART II Business Area Architecture Report
260
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.11 Simulation
The University of Maryland has responsibility for the development of simulation tools for the
CHART II system. This section of the BAA presents the conceptual approach to simulation to
identify the uses of simulation and integration of the simulation tools into the overall CHART II
system.
As discussed in a BAA workshop, simulation can provide tools to CHART in support of traffic
management and the operational system defined in this BAA report. A summary of the support
that simulation can provide is reflected in the following paragraph.
 Assist CHART II operators in a number of ways:
 Assist with incident management and decision making
 Represent lags in detector information to give a graphical representation of traffic
flows
 Estimate queue data on traffic congestion to tell how quickly a queue will clear
 Allows for “what if” scenarios for handling situations differently
 Change signal timing on secondary roads during an incident or congestion situation
 Evaluate results of incident management and suggest improvements
 Gather metrics for future road planning
 Assist traffic planners with adjusting signal timing to improve traffic flows
The following diagram illustrates the conceptual relationships between the CHART operational
system (highlighted in gray) and the simulation support tools. As illustrated, the simulation
component utilizes real-time, archive and map data from the operational system to perform its
functions, and outputs estimates, predictions, comparisons, and simulations in support of various
aspects of traffic and roadway management for SHA and other MDOT agencies.
Surveillance Estimates/Impact of
Incident Response
Real-Time Surv. Data
(i.e. lane closure, demand, signal timing, plan preview)
CHART II Simulation
Incident Response
Real Time
CHART II
Surveillance & Control
Archived Data
Map Data
Off-Line
Actual
Planning
Engineering
Maintenance
Evaluation
Simulation
CHART II
GUI
It was determined that simulation should be capable of providing three modes of support: RealTime, Off-Line, and Training. These three modes are discussed in more detail in the following
paragraphs.
CHART II Business Area Architecture Report
261
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.11.1 Real-Time Mode
Real-Time mode is intended to provide simulation and decision support capabilities to support
ongoing traffic management activities. As operators work a particular traffic management
problem, they should be able to switch to the simulator in Real-Time mode and obtain
evaluations of their current response plan as well as estimates of certain parameters that could
affect the effectiveness of their response plan. By using inputs (i.e., real-time surveillance data,
archived data, map data) from CHART II, the simulator will give the CHART II operators the
ability to bring up the current response plan in the simulator. The simulator should be able to
evaluate the effectiveness of the current response plan based on past experience calculated from
the Archive data. The simulator should also be able to predict traffic conditions as a result of the
response plan, recommend changes to the response plan and project the resulting traffic
conditions over time periods as the traffic situation continues or is affected by other projected
conditions or the response plan.
The simulator needs to take into account other planned activities that might affect the response
plan as the plan is implemented; such as planned special events and expected roadwork closures.
The simulator should provide the operator with the reasoning behind its recommendations (for
example, identify that the congestion or queue will increase because a special event or recurring
congestion is expected in the next 30 minutes, or it is the normal phenomenon of the current
situation). Operators should also be able to tweak the current or suggested response plan (using
the same CHART II-type functions) to evaluate and build a better response plan, then be able to
optionally modify and implement that enhanced plan when switching back into operational
mode.
The use of the Real-Time simulation mode would usually be used for incident management and
non-recurring congestion situations. It is expected that the simulation and decision support
capabilities would assist the operators in these areas:
 DMS – when to post messages, where and when to change/clear messages
 Fill in surveillance (detector) gaps with estimates based on Archived data analysis,
redirection of traffic, and planned special events or roadwork
 Signal timing recommendations where appropriate
 Secondary roads – surveillance estimates and signal timing recommendations
 Estimate future traffic conditions – queues, travel times
 Assistance with estimating movement of backup queue due to congestion/incident
It is expected that the Archive data will form the basis for the historical analysis and best
practices capabilities of the simulator. It should be expected that the output results from the
simulator would become more accurate over time as the Archive data increases. Some
balance/priority needs to be considered in defining CHART II system releases in starting to
collect Archive data as early in the release strategy as possible, but without delaying critical
operational capabilities.
CHART II Business Area Architecture Report
262
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.11.2 Off-Line Mode
The Off-Line simulation mode is expected to provide capabilities to analyze a specific past
traffic situation and propose or evaluate the response plan; also to provide for the exercising of
proposed response plans or scheduled events to validate their expected results.
This mode will provide capabilities for evaluating how a past traffic situation was handled and
then have the simulator suggest ways to improve the response. A past traffic situation should be
able to be “replayed” and altered to see if the situation had been handled in a different way what
the expected outcomes would have been. The simulator is expected to offer recommendations
and critiques of the response activities based on analysis of the situation as it happened, and
determine the effects of revisions to the response plan.
This mode should provide a means for an operator to input “what-if” scenarios to evaluate and
adjust a proposed plan or scheduled event before entering or modifying it into the operational
system. The simulator is expected to play the scenario and highlight problem areas and make
suggestions for improving the plan. Once a plan is simulated to the satisfaction of the operator,
there should be a way for the operator to save that plan to the operational system.
2.2.4.11.3 Training Mode
Training is the third simulation mode. It is possible that an operator could be trained in managing
specific traffic situations through the use of simulation. In this mode, the simulator is expected to
present a set of specific traffic situations and then allow the operator to react to each of the
situations. Several traffic situation scenarios can be established (with variables to prevent the
same response plan from being anticipated) and played out for the trainee to devise and
implement response plans. The simulator should be able to evaluate the response plans as the
steps are executed and evaluate the results. It should also be possible to simulate changing
conditions as the situation progresses and critique the performance of the trainee at the
conclusion of the exercise. It is assumed that training scenarios and reactions to response plans
would be based on best practices derived from information in the Archive database in order to
provide training specifically tailored to the CHART environment.
CHART II Business Area Architecture Report
263
January 8, 2006
CHART II Business Area Architecture Report
2.2.4.12 Other Agencies
The ability of other agencies to receive/provide information from/to CHART II was discussed in
one of the Design Workshops. Discussions with the other agencies have not been extensive yet,
so there are no hard requirements to be introduced at this point. Detailed requirements and
associated process flows will be developed during more in-depth discussions over the coming
months.
The current list of agencies considered in the process design workshops, are the following:

Montgomery County

Virginia Department of Transportation (VDOT)

Partners in Motion (PIM)

Transcom

911 Centers
Montgomery County
CHART currently allows Montgomery County to view and control CHART’s cameras via
AVCM, but CHART is only able to receive feed from one of their cameras.
It would be desirable to have the following available:

Real-time detector data from Montgomery Co. detectors on FITM routes.

Splats of incidents in Montgomery Co., especially on FITM routes.

Since Montgomery Co. has some of the same PDMS it would be appropriate to have
them integrated into CHART II.
Would like to get cameras from MC TMC on a larger scale, control of some cameras

VDOT
There is currently no information being shared between VDOT and CHART.
It would be desirable to have the following available:

Ability to view cameras (a minimum requirement)

Detector data

Incident data

Sign data
This would include information for routes other than just the Capitol Beltway (I-495), such as
I-95S, I-66, Route 7, etc.
PIM
CHART II Business Area Architecture Report
264
January 8, 2006
CHART II Business Area Architecture Report
On 1/1/2000, PIM will probably be going private. Additional requirements will be defined once
this takes place and more is known about what information is being collected.
TRANSCOM
It would be desirable to have access to data for any incident that affects travelers to and from the
state of Maryland, so information could be parsed and posted in CHART II Incident Logs, as
well as overlay map data.
911 Centers
It is possible that CHART II Incident Logs could be generated from the information being stored
in the 911 Center databases. It would be beneficial to have access to 911 Center databases, so
information could be parsed for incident related calls in order to post incident data.
CHART II Business Area Architecture Report
265
January 8, 2006
CHART II Business Area Architecture Report
3 Organization Model View
This section presents the Organization Direction Model consisting of the principles, constraints and
assumptions to be considered in the design and development of the CHART II application. It is not the
intent of this BAA exercise to analyze and recommend a re-organization of the CHART organization.
3.1 Organization Direction Model
This model shows what organization principles, constraints, and assumptions impact the project.
3.1.1 Organization Principles, Constraints, and Assumptions
Numerous principles, constraints, and assumptions (PCAs) were derived for this particular model view.
The table below shows how the BAA process scored in applying the identified PCAs. The scoring is
defined as follows:

Applied = The PCAs were observed and applied to one or more of the Domains of Change

To Be Applied = The PCAs were not viewed as relevant to this phase of the project, but may be
applied in later phases (i.e., Design, Development, and Deployment)

Not Applicable = The PCAs identified were replaced by different approaches used in process
design
Principles

Device owner will always have overriding control of devices

Anybody may initiate an incident

Everyone with appropriate CHART access can see incident data and add to the
status of the incident

The CHART “response plan” will be displayed for initiation at only one location,
which will be the “active zone of responsibility”

There will be one designated System Administrator who can make adjustments as
necessary and configure zones of responsibility

There will be a “Chief Operator” function to arbitrate conflicts

TOCs and SOC will have the same information and rules
Constraints
None
Assumptions

Personnel will receive training on how and when to access CHART data.
CHART II Business Area Architecture Report
266
January 8, 2006
CHART II Business Area Architecture Report
3.2 Organization Model
This section presents the organization structure for CHART and specifies the expected duties of the
organizational entities as related to the deployment of a new CHART system.
The following diagram depicts the CHART Organization as pertinent to the discussions of this section.
CHART Organization Chart
SHA
Chief Engineer
CHART
Board
CHART
Program
Manager
Operations Team
ITS Development
Team Manager
Integration Team
CHART ITS Systems
Admin
It was mentioned in Visioning and Process Design Workshops that there is a need for a "Chief Operator"
position in the CHART organization to arbitrate conflicts and be the main point of contact for internal
and external customers when responding to traffic incidents. It is envisioned this position would be filled
at all times (24 x 7) and would be responsible for coordinating intra-agency activities; and serve as a
single point of contact to coordinate and take responsibility for inside operations (device activation and
resource notification). This position would also alleviate the problem of those times when calls for
information come in and no single point of contact (team leader) is available to handle this responsibility
by being the point of contact for information requests.
The following table identifies the major responsibilities of the organizational entities as related to the
deployment, management and operation of the CHART system described in the other sections of this
document. The responsibilities identified in this table also reflect many of those responsibilities
necessary to continue the growth of CHART as well as support the continuing efforts to further integrate
other systems and transportation modals into a state-wide ITS.
Organizational Entity
CHART II Business Area Architecture Report
Major Responsibilities
267
January 8, 2006
CHART II Business Area Architecture Report
Organizational Entity
Major Responsibilities
SHA Chief Engineer

Strategy and Planning

Manage budget and funding

Define business objectives

Strategy and Planning

Manage budget and funding

Define, measure, and manage business objectives

Define and monitor operational objectives


Traffic management of state highways and arterials
Manage ETP, ERU and HOT operations

Monitor, measure, and manage operational
accomplishments

Plan, prepare, and conduct ER training

Investigate new technologies

Develop ITS strategy

Define ITS objectives

Manage ITS development and deployment

ITS Systems planning and strategy

Maintain infrastructure equipment and configuration

CHART application administration and configuration

Network administration and maintenance

Legacy systems administration

Applications change control and configuration
management

CHART application maintenance

Database administration

CHART functional and user training
CHART Program Manager
Operations Team
ITS Development Team
Manager
Integration Team – CHART
ITS Systems Admin
Many of the major responsibilities noted above for the Integration Team – CHART ITS System Admin
organization are expected to be supported by contract personnel during the development of CHART II
and afterwards as part of application maintenance and hardware maintenance contracts. The following
responsibilities have been identified as candidates for contract support, during both development and
maintenance phases:
CHART II Business Area Architecture Report
268
January 8, 2006
CHART II Business Area Architecture Report

Maintain infrastructure equipment and configuration

Network administration and maintenance

Applications change control and configuration management

CHART application maintenance

Database administration

CHART functional and user training.
3.3 Training Requirements
Deployment of a new system has an adverse affect on the organization unless appropriate training is
provided to the organization. The CHART II system is based on re-engineered processes, new
applications and user interface techniques, and a new hardware and operating systems architecture. With
so many of the aspects of the new system being different from the old system and system environment,
several types of training will be required to prepare the organization to effectively utilize, administer, and
maintain the system. Types of training are described in the following paragraphs.
3.3.1 Technical training
3.3.1.1 Windows Operating Systems:
Two types of Windows Operating System training should be provided. One type is for system
administrators to provide them the necessary skills to configure servers, workstations, and users. A
second type is for users to provide them the necessary skills to manipulate Windows-based applications.
3.3.1.2 Other technical training
It has been indicated that selected members of the CHART staff will require additional technical training
to provide system support to the CHART operations. These selected individuals require, at a minimum,
basic technical training on all systems and hardware components of the CHART II system. Examples of
other technical training include Oracle, ATM Switch, Mux, Routers, etc.
3.3.2 Functional Training
3.3.2.1 CHART Application Administration:
This training should provide a functional overview of the system parameters and configuration data used
in the CHART applications to control the processing options and flexibility of the applications. Training
should identify the specific parameters and configuration data that may be maintained, the values of each
parameter and configuration type, and their affect on the applications.
3.3.2.2 CHART User Functions:
This training should provide the users with a conceptual view of the processes supported by the CHART
applications. Training should introduce the users to any new terminology, descriptions of the appropriate
CHART II Business Area Architecture Report
269
January 8, 2006
CHART II Business Area Architecture Report
situations to utilize each function, and the business objectives and reasons for performing each function.
This training should be directed to SOC, TOC, and AOC operators; Maryland State Police; and SHA
Maintenance Shops operators.
3.3.2.3 CHART Archive Data:
This training should provide users with an overview of the data being retained in the Archive Database
and its logical structure and relationships. Training should also include example usage of the data to
obtain performance measurement and statistical data. This training should be directed to CHART
managers and supervisors, and other non-CHART agencies who have expressed a need for access to the
archived data.
3.3.3 User Application Training
3.3.3.1 CHART Application User Training:
This training should provide CHART users with application level training. Training should be directed
to training operators in the use of the CHART II applications at a screen level. This training may include
Windows and/or Oracle training as related to the applications and the current knowledge of the operators.
User training should be related to the functional training so as to provide the operators with continuity
between the two types of training.
3.3.3.2 CHART Archive Training
This training should be provided to CHART managers and interested SHA/MDOT Archive users.
Training should be directed toward use of standard and alternative tools to select, extract, and report on
data in the Archive.
CHART II Business Area Architecture Report
270
January 8, 2006
CHART II Business Area Architecture Report
4 Location Model View
This section presents various model views of the Location domain of change derived from CHART II
visioning and process design workshops. The Direction Model provides the principles, constraints and
assumptions that guide the design of business processes, while the Conceptual Model provides the
specifics of business processes defined and derived as related to specific Locations.
4.1 Location Direction Model
This model shows what location principles, constraints, and assumptions impact the project.
4.1.1 Location Principles, Constraints, and Assumptions
Numerous principles, constraints, and assumptions (PCAs) were derived for this particular model view.
The table, which follows below, shows how the BAA process scored in applying the identified PCAs.
The scoring is defined as follows:

Applied = The PCAs were observed and applied to one or more of the Domains of Change

To Be Applied = The PCAs were not viewed as relevant to this phase of the project, but may be
applied in later phases (i.e., Design, Development, and Deployment)

Not Applicable = The PCAs identified were replaced by different approaches used in process
design
Principles

Each location has one point of control for all data

Ability to expand the number of locations that have access to CHART data

System will provide for remote access capability – possibly with reduced functional
capabilities

Failure at one location will not disable all locations

System will provide the capability to transfer control between locations
Constraints
None
Assumptions

MDOT network access rules support desired capabilities
4.2 Conceptual Location Model
CHART II Business Area Architecture Report
271
January 8, 2006
CHART II Business Area Architecture Report
The Conceptual Location Model defines and identifies types of locations represented in the business
processes and provides a matrix of the allocation of business processes to the location types.
Additionally, this Location Model includes a diagram of the operation center hierarchy of
responsibilities.
The business processes refer to a hierarchy of responsibilities in discussions related to maintaining
operation centers and the processing of alerts. Primarily, this hierarchy defines which organization is
responsible for managing/handling specific alerts/functions at times when the organization with the usual
area of responsibility is unavailable to perform those responsibilities.
4.2.1 Location Types
From the Process Design Workshops, eight location types have been identified. Since the release of the
original BAA the location types list has been revised to the following:

Traffic Operations Centers - SOC/TOC/AOCCentral/AOC South/MCTMC/ PGTRIP/ DDOT –
system operations and traffic management – primary system users and data input sources.

Police Agencies - all MSP and local departments participating in CHART; traffic management,
incident response

Districts/Counties – District and County Offices: primarily monitoring and information viewing,
some perform highway maintenance supervision

Media – outside information re-processors: primarily obtain filtered incident and traffic flow
information, obtain CCTV video feeds, includes private and semi-private entities.

SHA Highway Maintenance – highway maintenance shops responsible for structural repairs, road
signs and posts, potholes, guard rails, etc; response to Action and Incident Logs

Device Maintenance-Signal – signal control and repair shops; respond to Action Logs
Device Maintenance – ITS Devices - (HAR) – radio maintenance shops; respond to failure
alerts/Action Logs for HAR, Radar based detection, CCTV, Weather Towers, DMS – dynamic signs
repair shop; respond to failure alerts/Action Logs for DMS, PDMS, ATR, and Shazam (Device
Maintenacne was broken down into two groups, these maintenance functions have been merged).
911 and Emergency Coordination Centers – all County 911 Centers and Maryland Emergency
Management Agency (MEMA).


Data Processing / System Maintenance – NOC / UMD CATT Lab - Centers that have no operational
functionality; however process CHART Data or have System Maintenacne responsibilies.
4.2.2 Location-Process Matrix
The Location-Process Matrix illustrated in the following figures shows the processes, and indicates
which processes will be operational at which types of locations. Where a process is identified as ‘Not
CHART II Business Area Architecture Report
272
January 8, 2006
CHART II Business Area Architecture Report
Applicable To A Location’, this means the process is viewed as being performed by the system and not a
Not Applicable To A Location (10)
Data Processing (9)
N
911 / Emergency Coordination Agencies (8)
O
I
T
A
C
O
S
E
P
Y
T
L
Device Maint. - ITS (7)
Device Maint. - Signal (6)
Highway Maintenance (5)
Media (4)
Districts/Counties (3)
Police (2)
Traffic Operations Center (1)
1
2
3
4
5
6
7
8
9
X
X
X
X
X
X
X
X
X
X
X
X
X
10
SECURITY AND OPERATIONAL CONTROL
System Administration
a
Maintain Users
X
b
Maintain Roles
X
c
Maintain Functional Rights
X
d
Maintain Functional Responsibilities
X
e
Maintain Geographic Responsibility
X
f
Maintain Operations Center and AOR
X
Operational Control
a
Maintain Center Notepad
X
b
User Logon
X
c
View Center Situation
X
d
Maintain User Preferences
X
X
X
X
X
X
X
X
X
e
Maintain Operator's Notepad
X
X
X
X
X
X
X
X
X
f
Perform CHART Chat
X
X
X
X
X
X
X
X
g
Logout
X
X
X
X
X
X
X
X
h
Change User
X
I
Transfer Resources
X
X
X
j
Respond to Request to Transfer Resources
X
X
X
Configuration Processes
a
Maintain System Parameters
X
b
Maintain Links
X
Maintain FITM Plans
X
FITM Plans
a
Map Configuration
a
Update MDOT GIS Map Data
X
SYSTEM CONFIGURATION AND STATUS
Components
a
Maintain Component Configuration
b
Log System Failures
X
x
Devices
a
Maintain Device Configuration
X
b
Set Device Online
X
X
X
c
Set Device Offline
X
X
X
d
Set Device to Maintenance Mode
X
X
X
e
Handle DMS and HAR Polling Results
f
Respond to Device Failure Alerts
X
X
X
X
X
X
X
X
X
x
INCIDENT/EVENT MANAGEMENT
Logs
location.
a
Log Communications Log
X
b
Log Action Event
X
X
X
Figure 4-1. Location-Process Matrix, Part 1/4(August 2000)
CHART II Business Area Architecture Report
273
January 8, 2006
CHART II Business Area Architecture Report
Not Applicable To A Location (10)
Data Processing (9)
N
911 / Emergency Coordination Agencies (8)
O
I
T
A
C
O
P
T
d
S
E
Y
L
Device Maint. - ITS (7)
Device Maint. - Signal (6)
Highway Maintenance (5)
Media (4)
Districts/Counties (3)
Police (2)
Traffic Operations Center (1)
1
Log Incident Event
X
e
View Historical vs. Current
2
3
X
4
5
6
7
8
X
X
X
X
X
X
X
X
9
10
X
f
Log Congestion Event
X
g
Log Recurring Congestion Log
X
h
Log Special Event
X
i
Log Weather Event
X
j
Log Weather Sensor Log
X
k
Log Safety Message Event
X
g
View Log
X
h
Close Log
X
Location Navigation
a
Maintain Location Navigation Data
X
b
Activate Location Navigator
X
X
X
X
Calculate Queue Length
X
X
X
X
a
Maintain Notification List
X
b
Perform Notificaiton
X
Queues
a
Notification
X
X
SHARED RESOURCE MANAGEMENT
DMS/HAR Common Processes
a
Maintain Acceptable Word Dictionary
X
b
Maintain Unacceptable Word Dictionary
X
c
Perform Responsibility Reminder
X
d
Respond to Responsibility Reminder Alert
X
DMS Processes
a
Maintain DMS Message Library
X
b
DMS – Add a Message
X
X
c
DMS – Remove a Message
X
X
d
DMS – Arbitrate Message Queue
e
DMS – Evaluate Queue
f
DMS – Send a Message
g
DMS – Blank a Sign
h
DMS - Reset
i
DMS – Restore Message
j
DMS- Override Queue
x
x
x
x
X
X
x
X
HAR Processes
a
Maintain HAR Message Library
X
X
b
HAR – Add a Message
X
X
c
HAR – Remove a Message
X
X
d
HAR – Arbitrate Message Queue
e
HAR – Evaluate Queue
x
x
Figure 4-2. Location-Process Matrix, Part 2/4(August 2000)
CHART II Business Area Architecture Report
274
January 8, 2006
CHART II Business Area Architecture Report
Not Applicable To A Location (10)
Data Processing (9)
N
911 / Emergency Coordination Agencies (8)
O
I
T
A
C
O
T
L
S
E
P
Y
Device Maint. - ITS (7)
Device Maint. - Signal (6)
Highway Maintenance (5)
Media (4)
Districts/Counties (3)
Police (2)
Traffic Operations Center (1)
1
2
3
4
5
6
7
8
9
g
HAR – Broadcast Default Message
h
HAR – Set Shazam On/Off
i
HAR – Update Default Message
j
HAR – Send Maintenance Command
k
HAR – Restore Message
l
HAR - Override Queue
X
a
Maintain Wall Monitor Configuration
X
b
Control Wall Monitor Assignment
X
c
Maintain CCTV Presets
X
d
Refresh Default AVCM Presets
e
Maintain Tours
X
f
Activate Tour
X
X
X
X
X
X
X
X
g
Control Camera
X
X
X
X
X
X
X
X
10
x
x
X
X
x
AVCM
X
X
X
X
X
X
X
X
x
Detectors
a
Handle Polled Detector Data
b
Handle Detector Rules
c
Generate Congestion Response
d
Respond to Congestion Alert
e
Generate Incident Response
f
Respond to Incident Alert
g
Activate Response Plan
x
x
x
X
x
X
x
Equipment
a
Maintain Equipment Inventory
X
X
X
X
b
Maintain Equipment Status
X
X
X
X
c
Alert For Delinquent Equipment Status
d
Respond to Delinquent Equipment Status Alert
X
X
X
X
x
Signals
x
a
Handle Signal Polling Data
b
Respond to Exceeded Signal Threshold Alert
c
Download Signal Data
x
a
Handle AVL Polling Results
b
Perform AVL Function Processing
x
x
x
x
x
x
x
x
X
X
AVL
c
Process AVL In/Out of Service Message
d
Process AVL Mayday Message
e
Process AVL Arrival On-Scene Message
f
Process AVL Assist Disabled Vehicle Message
g
Process AVL Assist Disabled CHART Vehicle Message
h
i
j
Process AVL Available Message
Respond to AVL Alerts
Respond to Mayday Alert from AVL
X
Figure 4-3. Location-Process Matrix, Part 3/4(August 2000)
CHART II Business Area Architecture Report
275
January 8, 2006
CHART II Business Area Architecture Report
Not Applicable To A Location (10)
Data Processing (9)
N
911 / Emergency Coordination Agencies (8)
O
I
T
A
O
S
E
P
C
Y
T
Device Maint. - ITS (7)
Device Maint. - Signal (6)
Highway Maintenance (5)
Media (4)
Districts/Counties (3)
Police (2)
L
Traffic Operations Center (1)
l
1
Respond to Disabled Vehicle Alert from AVL
2
3
X
X
4
5
6
7
8
X
X
X
X
9
10
X
ALERTS
a
Send Manual Alert
b
Send Alert
X
c
Escalate Alert
a
Maintain Plans
X
b
Activate Plan
X
c
Deactivate Plan
X
X
X
PLANS
SCHEDULED EVENTS
a
Maintain Scheduled Events
b
Process Scheduled Events Start
c
Process Scheduled Events End
X
X
X
EORS INTERFACE
Construction
a
Download EORS Permits
b
Activate EORS Icon On Map
c
Activate EOR Permit
x
x
X
X
X
Maintain Snow Emergency Declaration
X
X
X
Access Phone Book
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Snow Emergency
a
Phone Book
a
WEATHER SUPPORT
National Weather Service
a
View National Weather Service Data
b
Process Weather Alerts From The NWS
c
Respond to National Weather Service Alert
d
Fax Weather Report
X
a
Handle Weather Sensor Data
b
Generate Weather Sensor Response
X
x
c
Respond to Weather Sensor Alert
X
SCAN
X
X
X
ARCHIVING AND REPORTS
Archiving
a
Archive Update - Add
b
Archive Update - Update Log Data
c
Real Time System Update - Delete
x
x
x
x
Reports
a
Operational Reports
X
X
X
X
X
X
X
X
Figure 4-4. Location-Process Matrix, Part 4/4(August 2000)
CHART II Business Area Architecture Report
276
January 8, 2006
CHART II Business Area Architecture Report
4.2.3 Locations
The following table contains current CHART installation locations broken down by the Location Types
in 4.2.1. CHART also has data / network presence in many other locations not listed; this list just
contains locations that have the ability to use CHART and or CHART Video.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
911 and Emerg Coor. Centers
911 and Emerg Coor. Centers
911 and Emerg Coor. Centers
911 and Emerg Coor. Centers
911 and Emerg Coor. Centers
911 and Emerg Coor. Centers
911 and Emerg Coor. Centers
Data Processing
Data Processing
Data Processing
Device Maint. - ITS
Device Maint. - Signals
District / Counties
District / Counties
District / Counties
District / Counties
District / Counties
District / Counties
Media
Police
Police
Police
Police
Police
Police
Police
Police
Police
Police
Police
SHA Highway Maint. Shop
SHA Highway Maint. Shop
CHART II Business Area Architecture Report
Anne Arundel County 911 Center
Harford County 911 Center
SHA Laurel Maintenance Facility/Shop
Maryland Emergency Management
MIEMS
Baltimore County 911 Center
Howard County 911 Center
CSC Lab Hanover
CSC NOC Hanover
University of Maryland
Radio Shop
Hanover Sign Shop
Anne Arundel County DPW
District 5 Office, Annapolis
District 4 Office, Brooklandville
District 3 Office, Greenbelt
HQ
Virginia Department of Transportation
Traffic.Com
Baltimore County
Lane Bridge Police
MSP A - Jessup
MSP F - North East
MSP J - Annapolis
MSP L - Forrestville
MSP N - Rockville
MSP P - Glen Burnie
MSP Q - College Park
MSP R - Goldenring
US Park Police
SHA Annapolis Shop
SHA Churchville Maintenance Facility/Shop
277
January 8, 2006
CHART II Business Area Architecture Report
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
SHA Highway Maint. Shop
SHA Highway Maint. Shop
SHA Highway Maint. Shop
SHA Highway Maint. Shop
SHA Highway Maint. Shop
SHA Highway Maint. Shop
SHA Highway Maint. Shop
Traffic Operations Center
Traffic Operations Center
Traffic Operations Center
Traffic Operations Center
Traffic Operations Center
Traffic Operations Center
Traffic Operations Center
Traffic Operations Center
SHA Dayton Maintenance Facility/Shop
SHA Fairland
SHA Gaithersburg Maintenance Facility/Shop
SHA Golden Ring Maintenance Facility/Shop
SHA Hereford Maintenance Facility/Shop
SHA Upper Marlboro Maintenance
Facility/Shop
SHA Owings Mills Maintenance Facility/Shop
Fort McHenry Tunnel Vent Bldg.
Hanover Statewide Operations Center
MC Traffic Management
Prince George's County
PSI Net Stadium
Fedex Stadium
DC DOT
MAA Commuications
Figure 4-5. CHART II, Locations
CHART II Business Area Architecture Report
278
January 8, 2006
CHART II Business Area Architecture Report
5 Application Model View
This section presents various model views of the Application domain of change as gathered from
CHART II visioning workshops derived from analysis of the business processes. The Direction
Model provides the principles, constraints and assumptions that guide the design of applications,
while the Conceptual Model provides the specifics of the application design.
5.1 Application Direction Model
This model shows what application principles, constraints, and assumptions impact the project.
5.1.1 Application Principles, Constraints, and Assumptions
Numerous principles, constraints, and assumptions (PCAs) were derived for this particular model
view. The table below shows how the BAA process scored in applying the identified PCAs. The
scoring is defined as follows:

Applied = The PCAs were observed and applied to one or more of the Domains of
Change

To Be Applied = The PCAs were not viewed as relevant to this phase of the project, but
may be applied in later phases (i.e., Design, Development, and Deployment)

Not Applicable = The PCAs identified were replaced by different approaches used in
process design
Principles

Open application architecture

Distributed applications to increase fault tolerance

Designed for functional expansion of devices, modules (functionality), and graphical
capabilities

Common user interface for all functions, including legacy systems

Easy to use interface for system configuration

Device control may be available from any workstation

Configurable user rights including zones of responsibility

System feedback will be provided for each user action (both positive and negative
feedback)

System will notify user of preset alarms

System will be self-monitoring and attempt self-recovery
CHART II Business Area Architecture Report
279
January 8, 2006
CHART II Business Area Architecture Report
Principles

System must automate resetting of traffic control devices and traveler information
devices at clearance of an incident

Device communications must take place at the closest available location

Minimize user steps to accomplish system functions

System will maintain incident response plans

System shall not allow unauthorized access to user functions and data

System will support simulation and preview mode

System will interface with the Signal Control System

Simulation will be an off-line process

FITM maps shall be overlays to CHART map

System will provide decision support-type operator support

Code will be written to appropriate standards and be fully documented

Automate system maintenance activities to the extent possible

Application will be compliant with ITS Standards

Failure of one process will not force the failure of another process
Constraints

Must use SHA GIS data

Must use existing field devices
Assumptions

There is an ORB that is standard and meets the needs of CHART II

FMS will be in place, stable, and meets expectations

Will be able to retrieve legacy system data

AVCM will be in place, stable, and meets expectations
CHART II Business Area Architecture Report
280
January 8, 2006
CHART II Business Area Architecture Report
5.2 Conceptual Application Model
5.2.1 Application Architecture
The Application Architecture provides a conceptual description (at several levels of detail) of the
application areas that will be required to satisfy the CHART II future business needs and the
Commercial Off-The-Shelf (COTS) packages that are either current in use, or are targeted for
use, to fulfill the needs.
5.2.1.1 Conceptual Application Architecture Diagram
The Application Architecture Diagram provides a high-level, graphical description of the
characteristics that will be built into the application systems to satisfy future enterprise
requirements. The diagram shown below represents, at a conceptual level, a high-level view
showing the CHART II system and its external interfaces. The CHART II system gives and
receives information to and from other sources which are linked to the system. The diagram
below illustrates how the CHART II system will interface with legacy systems, as well as with
other external interfaces, and COTS software. These applications assist the users of the CHART
II system to monitor the roadways, notify individuals and groups that may need to assist with
situations or be aware of what’s happening, and receive additional information to assist with
current or future situations.
CHART II Business Area Architecture Report
281
January 8, 2006
CHART II Business Area Architecture Report
FAX,page,email
Recipient
FMS
AVCM
CHART CCTV
Module
message
device
commands
device status
SCAN / Web
weather
sensor
data
camera
commands
video
CHART II
weather
alerts
incident
reports
EORS
Winter Deployment Data
Lane Closures Permit Data
External
Incident Report
Source
NTCIP Center to
Center
Figure 5-1. Application-level Diagram(August 2000)
Future releases of CHART II will also incorporate a CHART-Lite version of the application, and
a Simulation application:

CHART-Lite is seen to be a fully functional version of the application, that will be deployed
anywhere, and communicate with the CHART II system. Although this has not been fully
defined, the current vision is that it will be provided via a web interface for ease of use and
cost reduction, since having a separate workstation deployed at multiple sites could be very
costly and difficult to maintain. (IMPLEMENTED)

The University of Maryland will have responsibility for the development of simulation tools
for the CHART II system. Further definition of requirements and development will be
undertaken at a later date. (In-Progress UM CATT Lab)
CHART II Business Area Architecture Report
282
January 8, 2006
CHART II Business Area Architecture Report
5.2.1.2 Conceptual Application Areas
Seven future application areas have been conceptualized and defined. A conceptual description
of the application areas required to satisfy the CHART II future business needs is shown in the
table below. Their order within the following table does not suggest a release sequence or
development priority.
Application Area
Description
Traffic and Roadway Monitoring
(PARTIALLY IMPLEMENTED –
CHART II, CHART LITE)
Incident Management
(PARTIALLY IMPLEMENTED –
CHART II, CHART LITE)
Shared Resource Management
(PARTIALLY IMPLEMENTED –
CHART II, CHART LITE)
Status Display Management
(PARTIALLY IMPLEMENTED –
CHART MAP)
System Configuration and
Administration
(IMPLEMENTED – CHART II,
CHART LITE)
Operations Support
(IMPLEMENTED – CHART II,
CHART LITE)
Monitor traffic and roadway conditions and
evaluate roadway detector data.
Report Generation
(IMPLEMENTED – CHART
REPORTING TOOL)
Provide tools for generating reports from
system log files.
Provides the operator with tools to assist in
incident management and documentation.
Handle allocation and control of shared
devices (DMS, HAR) and receive and log
roadway detector data.
Maintain the state of the display map.
Provides tools for managing and
administering the system
Provides user access control and support
utilities.
Figure 5-2. Future State Application Names
Each of the seven application areas are defined in detail in the following section of this report.
CHART II Business Area Architecture Report
283
January 8, 2006
CHART II Business Area Architecture Report
5.2.1.3 Conceptual Application Area Definitions
This section has not been updated so as to convey the original thoughts recorded from the
methodology employed to create the BAA which is an important viewpoint to maintain for
the CHART Project. Figure 5-2 can be referenced to determine what processes have
actually been implemented.
For each of the application areas identified, there are four sections:
 Description
A brief summary of the application area.

Functions
List of functions which will be performed by the application area.

Interfaces
A table representing the source/target for the application, the type of interface, and a
description of the source/target type.

Diagram for Application Area
The diagram depicts the application area, external interfaces, and major data sources and
links. The major data flows are shown in the diagram. Data flows considered part of the
application infrastructure (e.g. logging of system messages) are not shown in this high level
diagram. The diagram uses the following conventions:
 Circles represent the proposed future applications.
 Regular rectangles represent external agents or entities.
 Double horizontal lines represent databases.
 Arrows represent the flow of information.
CHART II Business Area Architecture Report
284
January 8, 2006
CHART II Business Area Architecture Report
5.2.1.3.1
Traffic and Roadway Monitoring
Description:
The Traffic and Roadway Monitoring application area is responsible for the collection of data
associated with monitoring traffic and roadway conditions, the analysis of this data, and issuing
alerts for roadway congestion and incidents. The application compares current speed and traffic
flow data with historical traffic flow data and weather information. It makes a determination
whether or not congestion or a traffic incident has occurred on a roadway, determines the
responsible center and operator, and issues an alert. The application periodically checks EORS
for road closure and snow emergency information and the scheduled events list for scheduled
events. It checks the National Weather Service for weather bulletins, alerts the operators if a
bulletin has been issued, and initiates a FAX of the bulletin to a predetermined list of sites. As
the status of objects such as detectors and links changes the state of the objects are updated so
that the change may be reflected on the map display.
Functions:
 Analyze roadway detector data.

Receive weather alerts.

Receive weather sensor data.

Receive road closure information.

Receive snow emergency information.

Generate traffic, weather, and incident alerts.

Check for scheduled events.

FAX weather report.

Update state of objects.
CHART II Business Area Architecture Report
285
January 8, 2006
CHART II Business Area Architecture Report
Interfaces:
Source/
Target
SCAN / Web
Interface
Type
App-to-App
EORS
Detector
History
Shared
Resource
Management
Status
Display
Management
Incident
Management
Operations
Support
App-to-App
Data Store
Scheduled
Events
Data Store
App-to-App
Description
Receive weather sensor data from field devices,
National Weather information from the SHA Web
Page.
Receive road closure status.
Query traffic history data.
App-to-App
Receive current detector data.
Issue a traffic plan message if indicated by traffic or
weather conditions.
Update display icons.
App-to-App
Object status updates.
App-to-App
Retrieve user and center information for
determining where to send alerts. Send weather
report to be faxed.
Retrieve scheduled event information.
CHART II Business Area Architecture Report
286
January 8, 2006
CHART II Business Area Architecture Report
Diagram for Traffic and Roadway Monitoring :
SCAN
EORS
Shared Resource
Management
Scheduled
Events
road closure status
current detector data
weather sensor data
traffic plan
event
Traffic and
Roadway Monitoring
weather report
system log message
Operations
Support
d
an
er
us
r
nte
ce
inf
weather message
o
history data
display update
Status Display
Management
Detector
History
CHART II Business Area Architecture Report
Web Page
287
incident alert
Incident
Management
January 8, 2006
CHART II Business Area Architecture Report
5.2.1.3.2
Incident Management
Description:
This application area handles those activities associated with managing an incident. Incidents are
initiated either manually by the user or are automatically initiated by an alert received from the
Traffic and Roadway Monitoring application. This application area provides the operator with an
interface to log various types of messages; communications with those outside the center,
communications received about non-blockage events and actions taken, communications
received about disabled vehicles, and an incident management log for recording information
about traffic incidents. It calculates queue length information for inclusion in an incident log
entry. As a result of an incident the application may format a message for sending by page, FAX,
or email to a list of recipients. It provides an interface for the user to select a plan to activate or to
deactivate a plan that is currently active.
Functions:
 Create entries in the Communications log.

Create entries in the Action log.

Create entries in the Disabled Vehicle log.

Create entries in the Incident Management log.

Calculate queue length.

Activate/deactivate a plan.

Format text message for sending to page/FAX/email list.
CHART II Business Area Architecture Report
288
January 8, 2006
CHART II Business Area Architecture Report
Interfaces:
Source/
Target
External
Incident
Report Source
Comm log
Actions log
Disabled
vehicle log
Incident log
Operations
Support
Shared
Resource
Management
Traffic and
Roadway
Monitoring
Interface
Description
Type
External agent The operator may receive reports of incidents from a
number of outside sources such as #77 call-ins, the
police, etc.
Data Store
A log is maintained for recording communications
with outside entities.
Data Store
A log is maintained for recording actions taken for
non-blocking events.
Data Store
A log is maintained with information on all disabled
vehicle reports.
Data Store
A log is maintained with information on all incidents.
App-to-app
Based on an evaluation of an incident a FAX, page,
or email may be sent to a specified list of recipients.
App-to-App
Issue an incident message for a confirmed incident.
Receive current detector data for queue length
calculation
App-to-App
Receive an incident alert.
CHART II Business Area Architecture Report
289
January 8, 2006
CHART II Business Area Architecture Report
Diagram for Incident Management :
Traffic and
Roadway Monitoring
incident alert
Comm Log
External
Incident
Report
Source
comm log entry
manual incident alert
actions log entry
fax/page/email message
system log message
Incident
Management
Actions Log
disabled vehicle log entry
Disabled
Vehicle Log
incident log entry
Operations
Support
confirmed incident alert
Incident Log
current detector data
Shared Resource
Management
CHART II Business Area Architecture Report
290
January 8, 2006
CHART II Business Area Architecture Report
5.2.1.3.3
Shared Resource Management
Description:
This application area communicates with and controls the system’s shared devices. It receives
and logs information from data collection devices such as speed and loop detectors. As detector
data is received the detector history file is updated with summary information. The application
area enables control of DMS, HAR, and camera devices and arbitrates their allocation. Cameras
are controlled through the AVCM while detector data and communication with DMS and HAR
devices is handled via the FMS. The application maintains the DMS and HAR message libraries
and the SHA equipment inventory database. The state of the objects are updated as the status of
objects such as detectors, DMS, and HAR changes so that the change may be reflected on the
map display.
Functions:
 Receive data from roadway detectors.

Receive device status information.

Archive sensor data.

Send commands to reset devices.

Turn on/off a SHAZAM.

Maintain DMS and HAR message libraries.

Post a message to a DMS or HAR.

Blank a DMS.

Control a CCTV device.

Maintain CCTV presets.

Control/arbitrate shared device allocation.

Maintain equipment inventory and equipment status.
CHART II Business Area Architecture Report
291
January 8, 2006
CHART II Business Area Architecture Report
Interfaces:
Source/
Target
FMS
Interface
Type
App-to-App
AVCM
Detector Data
Archive
Detector
History
Incident
Management
Traffic and
Roadway
Monitoring
Status Display
Management
Operations
Support
Message
Library
Equipment
Inventory
App-to-App
Data Store
Receive device status and detector data.
Send device commands, DMS messages, and HAR
messages.
Send camera commands
Archive detector data.
Data Store
Create detector history data.
App-to-App
Receive confirmed incident alert.
App-to-App
Receive traffic plan.
App-to-App
Update objects for display.
App-to-App
Log a system message.
Data Store
Update DMS and HAR entries in the message
library.
Update equipment and equipment status.
Data Store
CHART II Business Area Architecture Report
Description
292
January 8, 2006
CHART II Business Area Architecture Report
Diagram for Shared Resource Management :
Status Display
Management
AVCM
la
disp
y up
Message
Library
date
camera cmd
dms and har messages
Equipment
Inventory
device status
detector data
FMS
equipment status
Shared Resource
Management
device cmd
dms meesage
har message
detector data
detector history data
system log message
current detector data
confirmed incident alert
Detector
Data Archive
Detector
History
traffic plan
Operations
Support
Traffic and
Roadway Monitoring
Incident
Management
CHART II Business Area Architecture Report
293
January 8, 2006
CHART II Business Area Architecture Report
5.2.1.3.4
Status Display Management
Description:
The Status Display Management application area is responsible for updating the main operations
display map with the current status of all objects selected for display. As the state of devices,
road segments, and other map objects change, the changes are reflected on the display.
Functions:
 Display weather map overlays.

Update map display with new object states.
Interfaces:
Source/
Target
Web Page
Traffic and
Roadway
Monitoring
Operations
Support
Incident
Management
Shared
Resource
Management
Interface
Type
External
Agent
App-to-App
Retrieve and display weather map information.
App-to-App
Object status updates.
App-to-App
Object status updates.
App-to-App
Object status updates.
CHART II Business Area Architecture Report
Description
Object status updates.
294
January 8, 2006
CHART II Business Area Architecture Report
Diagram for Status Display Management:
Traffic and
Roadway Monitoring
display updates
he
eat
yw
ap
rm
rla
ove
Web Page
Status Display
Management
system log message
display updates
Operations
Support
display updates
Shared Resource
Management
Incident
Management
CHART II Business Area Architecture Report
295
January 8, 2006
CHART II Business Area Architecture Report
5.2.1.3.5
System Configuration and Administration
Description:
This application area provides those functions required to administer the CHART II system and
to maintain the system configuration. It provides functions for adding users to the system and
authorizing users to perform specific functions within the system. The application also provides
functions for maintaining center information such as the list of centers, the center geographic
area of responsibility, and maintenance shop equipment status. It will support the addition and
deletion of words from the acceptable and banned words dictionaries.
Functions:
 Maintain users and roles.

Maintain functional rights.

Maintain geographic responsibilities.

Maintain system parameters.

Maintain links.

Maintain words dictionary.

Maintain location navigation data.

Maintain notification list.

Maintain plans.

Maintain scheduled events.
CHART II Business Area Architecture Report
296
January 8, 2006
CHART II Business Area Architecture Report
Interfaces:
Source/
Target
Plans
Scheduled
Events
Notification
list
Words
dictionary
Users, Rights,
and
Functional
information
System
parameters
Center
information
System
component
and device
data
Operations
Support
Interface
Type
Data Store
Data Store
Data Store
Description
Update to plan library.
Update to scheduled events list.
Data Store
Update to list of recipients for pages, Faxes, and
email.
Update to acceptable/banned words dictionary.
Data Store
Update to user authorization and control.
Data Store
Update to system parameters.
Data Store
Update to center information.
Data Store
Update to component and device configuration.
App-to-App
Log a system message.
CHART II Business Area Architecture Report
297
January 8, 2006
CHART II Business Area Architecture Report
Diagram for System Configuration and Administration :
Scheduled
Events
schedule event update
Notification
list
Plans
plan
s
ate
upd
Users,
Rights, and
Functional
information
use
r
recipient address
dictionary update
info
Words
dictionary
System
Configuration and
Administration
e
dat
r up
ete
am
par
System
parameters
center info
configuration update
system log message
Operations
Support
CHART II Business Area Architecture Report
System
component
and device
data
298
Center
information
January 8, 2006
CHART II Business Area Architecture Report
5.2.1.3.6
Operations Support
Description:
The Operations Support application area controls access to the system and provides support to
other CHART applications. It provides a system login and logout function to control access to
the CHART system. It provides users with the capability to transfer resources currently allocated
to them to other users. It also provides a system message logging function to log system status
and error messages.
This application area includes two general utility functions, Chat and Notepad. Chat is an
operations utility that allows the CHART operators to converse through an online message
window. This allows conversations between remote operators without tying up phone lines and
without interrupting the operator’s ability to listen for audio queues from scanners and other
devices. Notepad is another operations utility that provides operators with an online notepad for
recording information. Both a personal and a center-wide notepad are supported.
Functions:
 Allows a user to determine which users are logged into the CHART system.

Allows a user to select another user to exchange text messages with.

Provides an online personal and center notepad.

Provide system login/logout.

Provide transfer of allocated resources to another user.

Log messages to the Operations log.
CHART II Business Area Architecture Report
299
January 8, 2006
CHART II Business Area Architecture Report
Interfaces:
Source/
Target
CHART
Operator
Recipient of
FAX, page, or
email
Center
information
Users, Rights,
and Functional
information
Notepad
Interface
Type
External
agent
External
agent
Operations log
Incident
Management
Shared
Resource
Management
Status Display
Management
Traffic and
Roadway
Monitoring
System
Configuration
and
Administration
Data Store
App-toApp
App-toApp
Description
Operators exchange online messages.
Destination of a FAX, page, or email.
Data Store
Retrieve center information for center responsibilities.
Data Store
Retrieve user information for authorization and access
control.
Data Store
View and update center and operator notepad
messages data.
Log system status and error messages.
Receive messages for operations log.
Receive messages for operations log.
App-toApp
App-toApp
Receive messages for operations log.
App-toApp
Receive messages for operations log.
CHART II Business Area Architecture Report
Receive messages for operations log.
300
January 8, 2006
CHART II Business Area Architecture Report
Diagram for Operations Support:
Center
information
System
Configuration and
Administration
Recipient of FAX,
page, or email
system log message
message
center info
Users,
Rights, and
Functional
information
system log message
user info
Operations
Support
Notepad
Incident
Management
system log message
Shared Resource
Management
es
ssag
d me
a
p
e
not
system log message
system log message
system log entry
chat messages
Operations
log
Status Display
Management
Traffic and
Roadway Monitoring
Chart
Operator
CHART II Business Area Architecture Report
301
January 8, 2006
CHART II Business Area Architecture Report
5.2.1.3.7
Report Generation
Description:
This application area supports the generation of reports from the logs. Reports may be displayed
online, printed, or saved to a text file.
Functions:
 Generate reports based on time.

Generate reports based on a specific incident.
Interfaces:
Source/
Target
Operations
log
Interface
Type
Data Store
Description
Read entries from system log files.
Diagram for Report Generation:
Operations
Log
log entries
CHART II Business Area Architecture Report
Report
Generation
302
January 8, 2006
CHART II Business Area Architecture Report
5.2.1.4 COTS Packages
The table below lists the Commercial Off-The-Shelf (COTS) packages or categories of COTS
packages that have been identified as candidates for supporting CHART II business processes.
In cases where a specific package has been identified, the vendor and package name are given.
The Usage column describes what the package is to be used for, the Status column gives the
current status of the package, and the Supported Processes column lists those CHART business
processes that the package will support. In some cases the COTS package provides general
infrastructure support as opposed to supporting specific business processes.
COTS Package
SSI, SCAN Web
Usage
Weather sensor
data retrieval
Traffic signal
status retrieval
Paging
software
Econolite, Traffic
Signal Software
Silverlake
Software,
Airsource Web
Microsoft Outlook Email
Email
FAX package
FAX
Nuance
Text to speech
conversion
Report
generation
Automatic
vehicle
location
Object request
broker, trader
services
Online help
Java Runtime
Environment
Database
management
Web Server
InetSoft Style
Report 6
AVL package
Object Oriented
Concepts,
ORBacus
Sun, Java Help
Sun, Java JRE
Oracle
Jakarta Tomcat
4.1.31
CHART II Business Area Architecture Report
Status
Existing
Supported Processes
Handle Weather Sensor Data
Existing
Handle Signal Polling Data
Existing,
review
required
Existing,
review
required
Market Survey
Required
Selected
Perform Notification
Perform Notification
Perform Notification
Market survey
required
Maintain HAR Message Library
HAR – Add a Message
Operational Reports
Reports from Archive
Handle AVL Polling Results
Perform AVL Function Processing
Selected
General infrastructure support
Selected
Selected
General infrastructure support
General infrastructure support
Selected
General infrastructure support
Selected
General infrastructure support
Selected
303
January 8, 2006
CHART II Business Area Architecture Report
5.2.2 Process / Application Matrix
The Process/Application Matrix relates the future business processes to the future application
areas that support them. It defines, at a conceptual level, the business content of each application.
The matrix conveys the following information:

Matrix Columns - The column headings represent the key future application areas.

Matrix Rows - The row titles represent business process threads and are categorized by
type of responsibility.

Matrix Cells – An ‘x’ appearing in a cell indicates that the process is supported by the
application area.
CHART II Business Area Architecture Report
304
January 8, 2006
CHART II Business Area Architecture Report
Operations Support
System Configuration and Administration
Shared Resource Management
Status Display Management
Report Generation
Incident Management
Traffic and Roadway Monitoring
1
2
3
4
5
6
7
SECURITY AND OPERATIONAL CONTROL
System Administration
a
Maintain Users
X
b
Maintain Roles
X
c
Maintain Functional Rights
X
d
Maintain Functional Responsibilities
X
e
Maintain Geographic Responsibility
X
f
Maintain Operations Center and AOR
X
Operational Control
a
Maintain Center Notepad
X
b
User Logon
X
c
View Center Situation
X
d
Maintain User Preferences
X
e
Maintain Operator's Notepad
X
f
Perform CHART Chat
X
g
Logout
X
h
Change User
X
I
Transfer Resources
X
j
Respond to Request to Transfer Resources
X
Configuration Processes
a
Maintain System Parameters
X
b
Maintain Links
X
Maintain FITM Plans
X
FITM Plans
a
Map Configuration
a
Update MDOT GIS Map Data
X
SYSTEM CONFIGURATION AND STATUS
Components
a
Maintain Component Configuration
b
Log System Failures
X
X
Devices
a
Maintain Device Configuration
b
Set Device Online
X
c
Set Device Offline
X
d
Set Device to Maintenance Mode
X
e
Handle DMS and HAR Polling Results
X
f
Respond to Device Failure Alerts
X
X
INCIDENT/EVENT MANAGEMENT
Logs
a
Log Communications Log
X
b
Log Action Log
X
c
Log Disabled Vehicle Log
X
X
X
Figure 5-3. Process by Application Matrix - Part 1/4(August 2000)
CHART II Business Area Architecture Report
305
January 8, 2006
CHART II Business Area Architecture Report
Operations Support
System Configuration and Administration
Shared Resource Management
Status Display Management
Report Generation
Incident Management
Traffic and Roadway Monitoring
d
1
Log Incident Log
e
2
3
4
5
6
7
X
View Historical vs. Current
X
f
Log Congestion Log
X
g
Log Recurring Congestion Log
X
h
Log Special Event Log
X
i
Log Weather Advisory Log
X
j
Log Weather Sensor Log
X
k
Log Safety Message Log
X
l
View Log
m
Close Log
X
X
Location Navigation
a
Maintain Location Navigation Data
b
Activate Location Navigator
X
X
Calculate Queue Length
X
Queues
a
Notification
a
Maintain Notification List
b
Perform Notificaiton
X
X
SHARED RESOURCE MANAGEMENT
DMS/HAR Common Processes
a
Maintain Acceptable Word Dictionary
b
Maintain Unacceptable Word Dictionary
X
c
Perform Responsibility Reminder
X
d
Respond to Responsibility Reminder Alert
X
X
X
DMS Processes
a
Maintain DMS Message Library
b
DMS – Add a Message
X
X
c
DMS – Remove a Message
X
d
DMS – Arbitrate Message Queue
X
e
DMS – Evaluate Queue
X
f
DMS – Send a Message
X
g
DMS – Blank a Sign
X
h
DMS - Reset
X
i
DMS – Restore Message
X
j
DMS- Override Queue
X
HAR Processes
a
Maintain HAR Message Library
X
b
HAR – Add a Message
X
c
HAR – Remove a Message
X
d
HAR – Arbitrate Message Queue
X
e
HAR – Evaluate Queue
X
f
HAR – Broadcast a Message
X
Figure 5-4. Process by Application Matrix - Part 2/4(August 2000)
CHART II Business Area Architecture Report
306
January 8, 2006
CHART II Business Area Architecture Report
Operations Support
System Configuration and Administration
Shared Resource Management
Status Display Management
Report Generation
Incident Management
Traffic and Roadway Monitoring
1
2
3
4
5
g
HAR – Broadcast Default Message
X
h
HAR – Set Shazam On/Off
X
i
HAR – Update Default Message
X
j
HAR – Send Maintenance Command
X
k
HAR – Restore Message
X
l
HAR - Override Queue
X
a
Maintain Wall Monitor Configuration
X
b
Control Wall Monitor Assignment
X
c
Maintain CCTV Presets
X
d
Refresh Default AVCM Presets
X
e
Maintain Tours
X
f
Activate Tour
X
g
Control Camera
X
6
7
AVCM
Detectors
a
Handle Polled Detector Data
X
X
b
Handle Detector Rules
X
X
c
Generate Congestion Response
d
Respond to Congestion Alert
e
Generate Incident Response
f
Respond to Incident Alert
g
Activate Response Plan
X
X
X
X
X
Equipment
a
Maintain Equipment Inventory
X
b
Maintain Equipment Status
X
c
Alert For Delinquent Equipment Status
X
d
Respond to Delinquent Equipment Status Alert
X
Signals
a
Handle Signal Polling Data
b
Respond to Exceeded Signal Threshold Alert
c
Download Signal Data
X
X
X
X
AVL
a
Handle AVL Polling Results
b
Perform AVL Function Processing
X
X
c
Process AVL In/Out of Service Message
X
d
Process AVL Mayday Message
X
e
Process AVL Arrival On-Scene Message
X
f
Process AVL Assist Disabled Vehicle Message
X
g
Process AVL Assist Disabled CHART Vehicle Message
X
h
Process AVL Available Message
X
i
Respond to AVL Alerts
j
Respond to Mayday Alert from AVL
X
k
Respond to Arrival On-Scene Alert from AVL
X
Figure 5-5. Process by Application Matrix - Part 3/4(August 2000)
CHART II Business Area Architecture Report
307
January 8, 2006
CHART II Business Area Architecture Report
Operations Support
System Configuration and Administration
Shared Resource Management
Status Display Management
Report Generation
Incident Management
Traffic and Roadway Monitoring
l
1
2
3
4
5
6
Respond to Disabled Vehicle Alert from AVL
7
X
ALERTS
a
Send Manual Alert
X
b
Send Alert
X
c
Escalate Alert
X
a
Maintain Plans
b
Activate Plan
X
X
c
Deactivate Plan
X
X
PLANS
X
SCHEDULED EVENTS
a
Maintain Scheduled Events
b
Process Scheduled Events Start
X
X
X
c
Process Scheduled Events End
X
X
EORS INTERFACE
Construction
a
Download EORS Permits
b
Activate EORS Icon On Map
c
Activate EOR Permit
X
X
X
Snow Emergency
a
Maintain Snow Emergency Declaration
X
Phone Book
a
Access Phone Book
X
WEATHER SUPPORT
National Weather Service
a
View National Weather Service Data
X
b
Process Weather Alerts From The NWS
c
Respond to National Weather Service Alert
d
Fax Weather Report
X
a
Handle Weather Sensor Data
X
b
Generate Weather Sensor Response
X
c
Respond to Weather Sensor Alert
X
X
X
SCAN
ARCHIVING AND REPORTS
Archiving
a
Archive Update - Add
X
b
Archive Update - Update Log Data
X
c
Real Time System Update - Delete
X
Reports
a
Operational Reports
X
b
Reports from Archive
X
Figure 5-6. Process by Application Matrix - Part 4/4(August 2000)
CHART II Business Area Architecture Report
308
January 8, 2006
CHART II Business Area Architecture Report
6 Data Model Views
This section presents various model views of the Data domain of change as derived from CHART
II visioning and process design workshops. The Direction Model provides the principles,
constraints and assumptions that guide the design of data stores. The Conceptual Model
provides the identification and definition of conceptual entities identified in the business
processes, and Process-to-Entity matrices summarizing the usage of entities within the business
processes.
6.1 Data Direction Model
This model shows what application principles, constraints, and assumptions impact the project.
6.1.1 Data Principles, Constraints, and Assumptions
Numerous principles, constraints, and assumptions (PCAs) were derived for this particular model
view. The table below shows how the BAA process scored in applying the identified PCAs. The
scoring is defined as follows:

Applied = The PCAs were observed and applied to one or more of the Domains of
Change

To Be Applied = The PCAs were not viewed as relevant to this phase of the project, but
may be applied in later phases (i.e., Design, Development, and Deployment)

Not Applicable = The PCAs identified were replaced by different approaches used in
process design
Principles

Single entry of data

Near real time distribution of incident, device, and system status

System must retrieve and distribute legacy data

System must provide the ability to widely distribute raw data from archive off-line

Data will be validated at the time of data entry

Data will be configured to support pre-defined and ad-hoc reporting

System must log all operator actions in the system

System must leverage/share all incident information with CHART partners
CHART II Business Area Architecture Report
309
January 8, 2006
CHART II Business Area Architecture Report

All data from a device may be stored

Data will be imported/exported to CHART partners (other agencies)

Data will be TMDD compliant

The system will provide the capability to configure data logging (on/off)

The system will provide the capability to configure data import (on/off)

The system will allow event driven configuration overrides

The system will have the ability to configure device data recording (times or
conditions)
Constraints
None
Assumptions

Sensor data is assumed to be valid
6.2 Conceptual Data Model
The data model views for CHART II include a conceptual entity relationship diagram depicting
major data entities and their relationships with one another, a table of Entity Definitions, and a
Process/Entity Matrix identifying which entities are utilized in each process.
6.2.1 Entity Relationship Diagram
The Entity Relationship Diagram (ERD) depicts the data entities referred to in the business
process model data flow diagrams and identifies the relationships between the entities. The
following two figures present the ERD from the BusinessTeam modeling tool.
CHART II Business Area Architecture Report
310
January 8, 2006
CHART II Business Area Architecture Report
Operational Database Entity Relationship Diagram - 12/15/99
NWS Alert File
Message Rules
Location Navigation
Info
Dictionary
EORS Map Data
Equipment Inventory
County Snow Emergency Data
Equipment Status
County Snow Emergency Map Data
Chart Map Data
Acceptable Word
Dictionary
EORS Permit Information
Weather File
Unacceptable Word
Dictionary
Scheduler Data
Alert Data
System Parameter
Address Book
HAR Message Library
Scheduler Item
Plan
Link
Notification
Data
DMS Stored
Message
HAR Stored Message Text
DMS Message Library
HAR Voice Message
Library Msg
PlanItem
Notification List
Figure 6-1. Conceptual Entity Relationship Diagram, Part 1/3(August 2000)
CHART II Business Area Architecture Report
311
January 8, 2006
CHART II Business Area Architecture Report
Weather Station
Operational Database Entity Relationship Diagram - 12/10/99
Sensor Data
Operators Notepad
Functional Right
Users Center
Weather Sensor Data
Pavement Sensor Data
Failure Log
Component
Configuration
Role
AVL
Vehicle Data
Organization
DMS Message
Arbitration Queue
DMS
User
SHAZAM
HAR
Device Configuration
User Preferences
Camera State Data
AVCM
Tour
HAR Message
Arbitration Queue
Shared Resource
Presets
Operations Log
Wall Monitor
Configuration
Wall Monitor Assignment
Detector
Center
Center
Notepad
Geographic Responsibility
Incident Interchange Database
Smoothed Data
Functional Responsibility
Group
Functional Responsibility &
Alert Types
Figure 6-2. Conceptual Entity Relationship Diagram, Part 2/3(August 2000)
CHART II Business Area Architecture Report
312
January 8, 2006
Historical Data
CHART II Business Area Architecture Report
Log
FITM Plan
Communication
Log
Action Log
Disabled Log
Communication
Log Text
Action Log Text
Disabled Log Text
Congestion
Log
Incident Log
Congestion
Log Text
Incident Log Text
Recurring
Congestion
Log
Special Event
Log
Recurring
Congestion
Log Text
Special Event
Log Text
Weather
Advisory Log
Weather
Advisory Log
Text
Queue Data
Operational Database Entity Relationship Diagram - 12/15/99
Response Plan
Each Response Plan can be associated with Notification
and Stored Messages for both HAR and DMS.
Figure 6-3. Conceptual Entity Relationship Diagram, Part 3/3(August 2000)
CHART II Business Area Architecture Report
313
January 8, 2006
Weather
Sensor Log
Weather
Sensor Log
Text
Safety
Message Log
Safety Message
Log Text
CHART II Business Area Architecture Report
6.2.2 Entity Definitions
The following tables give a brief description of each of the Entities identified in the Entity Relationship Diagram.
Table 6-1. Entity Definitions
Entity
Acceptable Word Dictionary
Action Event
Action Event Text
Address Book
Alert Data
Archive
AVCM
AVL
Camera State Data
Center
Center Notepad
Chart Map Data
Communications Log
Communications Log Text
Component Configuration
CHART II Business Area Architecture Report
Description
List of words and phrases considered acceptable as a part of a message to be displayed on a
device.
Information related to the disposition of the actions related to device failures and non-blockage
events (i.e., signals, debris, utility, signs).
Text entry to identify action taken in relation to specific action log.
Names, work-related phone numbers, e-mail addresses, and pager numbers of CHART related
personnel.
Information related to each alert sent in the system.
A separate database that contains a collection of real-time database information for reporting and
simulation.
Configuration information identifying camera devices used to monitor roadways.
Configuration information for automated vehicle location (AVL) devices, as well as information
related to actions of each AVL device.
Information on each camera that captures what the current position of the camera is when it is
being controlled, and what the default state should be so the camera can be returned to its default
state, once control is relinquished. Information would include: camera ID, camera name, preset
ID, preset name, and positioning (i.e., pan/tilt/zoom positions).
Configuration information that is required to define an operation center with associated
functional responsibilities and a geographic area. Data may include center name, center ID, alert
types, functional responsibility groups, and location.
Free-form text data for each center. Data may include center name, center ID, and free text.
Data required for displaying all map layers.
Data received from any source that requires no further action. Information may include receiving
operator ID, source, and method of communication.
Text entry to identify action taken in relation to specific communication log.
Contains data needed to identify system components. Information may include polling frequency,
314
January 8, 2006
CHART II Business Area Architecture Report
Entity
Description
error checks, and component correction data.
Information received from the system and outside sources relating to congestion situations. Will
include source data (detector and operator), the tracking of all shared resources used associated
with the log, and notifications made.
Congestion Event Text
Text entry to identify action taken in relation to specific congestion log.
County Snow Emergency Data
Contains data pertaining to each instance of a declared county snow emergency. This includes all
data received from the EORS system.
County Snow Emergency Map Data Contains data for display of a county snow emergency on the map.
Detector
Configuration data for a detector including location, type, and polling frequency.
Device Configuration
Superset of all device type configuration data.
Disabled Event
Information related to a single instance of providing assistance to a disabled vehicle. Data
includes vehicle identification, data/time, ETP/ERU unit providing assistance, and location.
Disabled Event Text
Text entry to identify action taken in relation to specific disabled vehicle log.
DMS
Configuration information relative to a dynamic message sign (DMS), including location and
communications information.
DMS Message Arbitration Queue Queue data for each DMS device. Each queue contains priority levels, and when being used the
information pertaining to the message such as text and associated Log ID. Each priority may
have multiple messages or slots.
DMS Message Library
Multiple topic-oriented libraries, each containing information defining each DMS stored message
including the message name, type/sub-type, and beacon state of each stored message.
DMS Stored Message
Message text associated with each stored message listed in the DMS Message Library.
EORS Map Data
All information required for the proper display of roadwork icons on the map. This data may
include icon type, color, location, and map layer
EORS Permit Information
Permit data downloaded from the EORS database. This data may include permit ID, construction
company information, general location and type of construction. Each permit may have multiple
schedule entries, which include specific location, start date/time, end date/time, and lane closures.
Equipment Inventory
Number and type of equipment used by the Maryland State Highway Administration’s shops in
assisting with CHART II related actions. The data is organized by shop and would show the
types of equipment and the respective quantities.
Equipment Status
Status information relating to the inventory. Data to include equipment type, total quantity in the
shop, quantity available for use, and quantity of equipment that is not available.
Congestion Event
CHART II Business Area Architecture Report
315
January 8, 2006
CHART II Business Area Architecture Report
Entity
Description
Failure Log
Information related to each detected instance of hardware or component failure. Data may
include device ID, date/time stamp, and failure code. Exact failure data returned from a device
during polling may be stored.
FITM Plan
Information related to a FITM response plan. Will include: scanned images, response text, and
map data.
Functional Responsibility and Alert Table of functional responsibilities and alert types that may be assigned to the operational centers
Types
(either directly or through functional responsibility groups)
Functional Responsibility Group
Groups of functional responsibilities and alert types. Included would be names of groups, and
links to related functional responsibility and alert type.
Functional Right
Table of functional capabilities allowed for operators of the system. Included are: functional
rights name and ID.
Functional Rights Group
Shows groups of functional rights. Included would be names of groups, and ID.
Geographic Responsibility
Data used to define a geographical area. Geographic boundaries used to designate the geographic
areas of responsibility for the operational centers.
HAR
Contains configuration data to define Highway Advisory Radio (HAR) device.
HAR Message Arbitration Queue Queue data for each HAR device. Included are: priority level of message, log to which the
message is associated, the associated message to be broadcast, and the status of whether the entry
is currently being broadcast or not.
HAR Message Library
Contains listing of all messages that have been developed for each HAR device, whether for
message text or voice. Messages will have an associated ID.
HAR Stored Message Text
All text associated with each stored message in the HAR Message Library. Each message will
have header, body, and footer information.
HAR Voice Message
All voice (WAV) files for each voice message in the HAR Message Library.
Historical Data
Normal traffic flow data for a given detector keyed on type of day, day of week, time of day (15
minute increments), pavement conditions/weather conditions. Each instance will contain volume,
occupancy, and speed.
Incident Interchange
A separate database that will have a subset of data for incidents. Information to be stored will be
incident ID information, such as: location, lane closure information, type of incident, queue
length, and estimated clear time. There will be no text entries from the incident logs.
Incident Event
Data received relating to each incident captured in the system. Information will include source of
data, status, location, type of incident, Each tracked item will include appropriate date/time
CHART II Business Area Architecture Report
316
January 8, 2006
CHART II Business Area Architecture Report
Entity
Incident Event Text
Link
Location Navigation Info
Log
Message Rules
Notification Data
Notification List
NWS Alert File
Operations Log
Operators Notepad
Organization
Pavement/Weather Sensor Data
Plan
Plan Item
Presets
CHART II Business Area Architecture Report
Description
stamps for performance measurement calculations.
Text entry to identify action taken in relation to the specific incident log.
Relationships of specific detectors to the CHART map data. The relation to CHART map data is
necessary to specify where each link is to be displayed on the map. (Specific definition of a Link
is undefined.)
Map coordinates for landmarks, exits, intersections, etc. for each highway, for pinpointing
location of activity to be recorded in the appropriate Log.
Highest level of information of all logs in the system. Mainly log ID, type, start/end date and
time.
Data necessary for the system to generate a response plan for automatic detection of congestion,
incident, and bad weather. Types of data may include log (situation) type, area of coverage
(distance from detector), type of devices, and generic message format.
All information for individuals listed for notification. Types of data included would be group
name, individual name, notification method, and all associated contact data (i.e., pager number,
e-mail address, fax number).
List of all individual listed by function, notification individual, notification group.
Alert data related to a National Weather Service alert.
Information related to all actions taken by individuals within the system. Mostly used as an audit
trail to keep track of changes. Data to include UserID, date/time, function performed, and related
functional data.
Free-form text of information stored by each individual in the system.
Data to define what shared resources are owned by which group of the organization.
Data received from pavement and weather sensor polling of each device. Information could
include temperature, moisture, and content for pavement sensors, and temperature, wind speed,
fog, etc. for weather sensors.
Identification information defining a plan in the system. Included data items will be Plan ID,
name, and type.
Individual command line of a plan. Data may include Plan ID, function identifier, and specific
data items to perform the function.
Pre-determined pan/tilt/zoom specifications for AVCM cameras. Information would include:
preset ID, preset name, and positioning (i.e., pan/tilt/zoom positions).
317
January 8, 2006
CHART II Business Area Architecture Report
Entity
Queue Data
Recurring Congestion Log
Recurring Congestion Log Text
Response Plan
Role
Safety Message Event
Safety Message Event Text
Scheduler Data
Scheduler Item
Sensor Data
SHAZAM
Signal
Smoothed Data
Special Event
Special Event Text
CHART II Business Area Architecture Report
Description
Subset of incident log information. Information taken from sensors or entered by an operator to
record the estimated queue (backup) length of traffic in one or more directions in relation to an
incident. Data may include Log ID, direction, and queue length, date/time. Any one incident log
may have multiple sets of queue data over the duration of the incident.
Information received from the system and outside sources related to recurring congestion
situations. Will include source data (detector and operator), the tracking of all shared resources
used associated with the log, and notifications made.
Contains the individual lines of free form or system-generated text describing the actions taken
related to each recurring congestion log.
Data contained in a system-generated response to a detected instance of congestion, instance or
poor weather conditions. Would include message text and identity of DMS or HAR to
display/broadcast the message.
Values designating the various security roles defined. Maintains the relation to the set of
Functional Rights identifying the system capabilities associated with each Role.
Information pertaining to the display and/or broadcast of safety messages. All shared resources
used are logged.
Contains the individual lines of free form or system-generated text related to each safety message
log.
Header information related to events in the scheduler. Data would include ID and name of
scheduled event, start and end times, and any other associated header data.
The detailed information for each action to be taken when the scheduled event is initiated. Data
will include Scheduler Data ID, action code, parameter data related to the action code.
Information retrieved from the SCAN database that provides pavement sensor data. Data could
include temperature, moisture, and content for pavement sensor (hockey pucks).
Configuration data to identify a SHAZAM and its relation with one or more HAR devices. Also,
since a DMS could act as a SHAZAM, information relating to this would also be stored.
Sub-type of device configuration. Configuration information to identify each signal device.
Detector data averaged over the polling period.
Information received from the system and outside sources relating to a special event. Will
include source data (scheduled plan and operator), location, and start/end times.
Contains the individual lines of free form or system-generated text related to tracking of all
318
January 8, 2006
CHART II Business Area Architecture Report
Entity
System Parameters
Tour
Unacceptable Word Dictionary
User
User Preferences
Users Center
Vehicle Data
Wall Monitor Assignment
Wall Monitor Configuration
Weather Event
Weather Event Text
Weather File
Weather Sensor Log
Weather Sensor Log Text
Weather Station
CHART II Business Area Architecture Report
Description
shared resources used that are associated with the log and any notifications made for each special
event log.
Data used to control the processes in the CHART II system.
Data related to displaying a sequence of camera images on a monitor, wall, media feeds, or web
feeds.
List of words and phrases considered unacceptable as a part of a message to be displayed on a
device.
Configuration data as it relates to each authorized CHART II user. Data may include user name,
ID, authorization password, and links to one or more role(s).
Data defining each individual user’s interface preferences.
Links between User and Center to define which centers the user is authorized to represent. Each
user may be assigned to one or more centers.
Polled or received data on vehicles equipped with AVL. Information stored may be time stamp,
location, speed, operator call sign, and status.
Linkage data relating a video feed to a specific wall monitor to control which cameras are being
displayed on which wall monitors. Information may link a single camera or a tour to a wall
monitor.
Configuration information needed to identify a wall monitor to accept display camera and tour
data.
Information received from the system and outside sources relating to National Weather Service
advisories. Will include source data, weather conditions, location, start/end time.
Contains the free form or system-generated text related to tracking of all shared resources used,
notifications made, and disposition data for each weather advisory log.
NWS weather report that is stored on the SHA web page.
Information received from the system and outside sources relating to a weather sensor alert. Will
include location of sensor and sensor data causing the alert.
Contains the free-form or system generated text related to returned, tracking of all shared
resources used, notifications made, and other actions taken in relation to each weather sensor log.
Configuration information needed to identify a weather station for use on the CHART II system.
Information would include location, communications protocol, and polling frequency.
319
January 8, 2006
CHART II Business Area Architecture Report
6.2.3 Process/Entity Matrix
The Process/Entity Matrix provides a cross-reference of business processes and data entities,
identifying which entities are referenced in which processes. The intersection of Processes and
Entity indicates the action performed on the Entity by the Process. These actions are expressed
with the following codes:

C = Create

R = Read

U = Update

D = Delete
The following figures present this matrix.
CHART II Business Area Architecture Report
320
January 8, 2006
CHART II Business Area Architecture Report
R
R
C
CR
CUD
CRUD
R
C
C
CRU
CR
CR
CR
C
C
321
January 8, 2006
C
County Snow Emergency Data
CRUD
R
R
Congestion Log Text
R
R
CRUD
Congestion Log
Component Configuration
Communication Log Text
R
Figure 6-4. Process/Entity Matrix, Part 1/20(August 2000)
CHART II Business Area Architecture Report
Communication Log
Chart Map Data
Center Notepad
Center
Camera State Data
AVL
AVCM
Archive
Alert Data
Address Book
Action Log Text
Action Log
Acceptable Word Dictionary
SECURITY AND OPERATIONAL CONTROL
System Administration
a
Maintain Users
b
Maintain Roles
c
Maintain Functional Rights
d
Maintain Functional Responsibilities
e
Maintain Geographic Responsibility
f
Maintain Center and AOR
Operational Control
a
Maintain Center Notepad
b
User Logon
c
View Center Situation
d
Maintain User Preferences
e
Maintain Operator's Notepad
f
Perform CHART Chat
g
Logout
h
Change User
i
Transfer Resources
j
Respond to Request to Transfer Resources
Configuration Processes
a
Maintain System Parameters
b
Maintain Links
FITM Plans
a
Maintain FITM Plans
Map Configuration
a
Update MDOT GIS Map Data
SYSTEM CONFIGURATION AND STATUS
Components
a
Maintain Component Configuration
b
Log System Failures
Devices
a
Maintain Device Configuration
b
Set Device Online
c
Set Device Offline
d
Set Device to Maintenance Mode
e
Handle DMS and HAR Polling Results
f
Respond to Device Failure Alerts
INCIDENT/EVENT MANAGEMENT
Logs
a
Log Communications Log
b
Log Action Log
c
Log Disabled Vehicle Log
CHART II Business Area Architecture Report
Functional Right
Functional Responsibility
Group
Functional Responsibility
and Alert Types
FITM Plan
Failure Log
Equipment Status
CRUD
CRUD CRUD
R
R
R
R
CRUD
C
CRUD
R
R
R
CRU
CR
C
CR
Figure 6-5. Process/Entity Matrix, Part 2/20(August 2000)
CHART II Business Area Architecture Report
Equipment Inventory
EORS Permit Information
EORS Map Data
DMS Stored Message
DMS Message Library
DMS Message Arbitration
Queue
DMS
Disabled Log Text
Disabled Log
Device Configuration
Detector
County Snow Emergency
Map Data
SECURITY AND OPERATIONAL CONTROL
System Administration
a
Maintain Users
b
Maintain Roles
c
Maintain Functional Rights
d
Maintain Functional Responsibilities
e
Maintain Geographic Responsibility
f
Maintain Center and AOR
Operational Control
a
Maintain Center Notepad
b
User Logon
c
View Center Situation
d
Maintain User Preferences
e
Maintain Operator's Notepad
f
Perform CHART Chat
g
Logout
h
Change User
i
Transfer Resources
j
Respond to Request to Transfer Resources
Configuration Processes
a
Maintain System Parameters
b
Maintain Links
FITM Plans
a
Maintain FITM Plans
Map Configuration
a
Update MDOT GIS Map Data
SYSTEM CONFIGURATION AND STATUS
Components
a
Maintain Component Configuration
b
Log System Failures
Devices
a
Maintain Device Configuration
b
Set Device Online
c
Set Device Offline
d
Set Device to Maintenance Mode
e
Handle DMS and HAR Polling Results
f
Respond to Device Failure Alerts
INCIDENT/EVENT MANAGEMENT
Logs
a
Log Communications Log
b
Log Action Log
c
Log Disabled Vehicle Log
322
January 8, 2006
R
CHART II Business Area Architecture Report
January 8, 2006
NWS Alert File
323
Notification List
CRU
Notification Data
CRUD
Message Rules
R
Log
CRUD
R
Location Navigation Info
CRUD
Figure 6-6. Process/Entity Matrix, Part 3/20(August 2000)
CHART II Business Area Architecture Report
Link
Incident Log Text
Incident Log
Incident Interchange
Historical Data
HAR Voice Message
HAR Stored Message Text
HAR Message Library
HAR Message Arbitration
Queue
HAR
Geographic Responsibility
Functional Rights Group
SECURITY AND OPERATIONAL CONTROL
System Administration
a
Maintain Users
b
Maintain Roles
c
Maintain Functional Rights
d
Maintain Functional Responsibilities
e
Maintain Geographic Responsibility
f
Maintain Center and AOR
Operational Control
a
Maintain Center Notepad
b
User Logon
c
View Center Situation
d
Maintain User Preferences
e
Maintain Operator's Notepad
f
Perform CHART Chat
g
Logout
h
Change User
i
Transfer Resources
j
Respond to Request to Transfer Resources
Configuration Processes
a
Maintain System Parameters
b
Maintain Links
FITM Plans
a
Maintain FITM Plans
Map Configuration
a
Update MDOT GIS Map Data
SYSTEM CONFIGURATION AND STATUS
Components
a
Maintain Component Configuration
b
Log System Failures
Devices
a
Maintain Device Configuration
b
Set Device Online
c
Set Device Offline
d
Set Device to Maintenance Mode
e
Handle DMS and HAR Polling Results
f
Respond to Device Failure Alerts
INCIDENT/EVENT MANAGEMENT
Logs
a
Log Communications Log
b
Log Action Log
c
Log Disabled Vehicle Log
CHART II Business Area Architecture Report
C
C
C
C
C
C
C
C
C
RD
RD
324
January 8, 2006
SHAZAM
C
Sensor Data
CRUD
Scheduler Item
Scheduler Data
R
Figure 6-7. Process/Entity Matrix, Part 4/20(August 2000)
CHART II Business Area Architecture Report
Safety Message Log Text
R
CRUD
R
C
C
C
Safety Message Log
C
C
C
C
C
C
Role
Response Plan
Recurring Congestion Log
Text
Recurring Congestion Log
Queue Data
Presets
Plan Item
Plan
Pavement/Weather Sensor
Data
Organization
Operators Notepad
Operations Log
SECURITY AND OPERATIONAL CONTROL
System Administration
a
Maintain Users
b
Maintain Roles
c
Maintain Functional Rights
d
Maintain Functional Responsibilities
e
Maintain Geographic Responsibility
f
Maintain Center and AOR
Operational Control
a
Maintain Center Notepad
b
User Logon
c
View Center Situation
d
Maintain User Preferences
e
Maintain Operator's Notepad
f
Perform CHART Chat
g
Logout
h
Change User
i
Transfer Resources
j
Respond to Request to Transfer Resources
Configuration Processes
a
Maintain System Parameters
b
Maintain Links
FITM Plans
a
Maintain FITM Plans
Map Configuration
a
Update MDOT GIS Map Data
SYSTEM CONFIGURATION AND STATUS
Components
a
Maintain Component Configuration
b
Log System Failures
Devices
a
Maintain Device Configuration
b
Set Device Online
c
Set Device Offline
d
Set Device to Maintenance Mode
e
Handle DMS and HAR Polling Results
f
Respond to Device Failure Alerts
INCIDENT/EVENT MANAGEMENT
Logs
a
Log Communications Log
b
Log Action Log
c
Log Disabled Vehicle Log
CHART II Business Area Architecture Report
c
Maintain Functional Rights
d
Maintain Functional Responsibilities
e
Maintain Geographic Responsibility
f
Maintain Center and AOR
Operational Control
a
Maintain Center Notepad
b
User Logon
c
View Center Situation
d
Maintain User Preferences
e
Maintain Operator's Notepad
f
Perform CHART Chat
g
Logout
h
Change User
i
Transfer Resources
j
Respond to Request to Transfer Resources
R
R
R
CRUD
R
Configuration Processes
a
Maintain System Parameters
b
Maintain Links
CRUD
FITM Plans
a
Maintain FITM Plans
Map Configuration
a
Update MDOT GIS Map Data
SYSTEM CONFIGURATION AND STATUS
Components
a
Maintain Component Configuration
b
Log System Failures
R
Devices
a
Maintain Device Configuration
b
Set Device Online
c
Set Device Offline
d
Set Device to Maintenance Mode
e
Handle DMS and HAR Polling Results
f
Respond to Device Failure Alerts
INCIDENT/EVENT MANAGEMENT
Logs
a
Log Communications Log
b
Log Action Log
c
Log Disabled Vehicle Log
Figure 6-8. Process/Entity Matrix, Part 5/20(August 2000)
CHART II Business Area Architecture Report
325
January 8, 2006
Weather Station
CRUD
Weather Sensor Log Text
Maintain Roles
Weather Sensor Log
Maintain Users
b
Weather File
a
Weather Advisory Log Text
System Administration
Weather Advisory Log
Wall Monitor Configuration
Wall Monitor Assignment
Vehicle Data
Users Center
User Preferences
User
Unacceptable Word
Dictionary
Tour
System Parameters
Special Event Log Text
Special Event Log
Smoothed Data
Signal
SECURITY AND OPERATIONAL CONTROL
CHART II Business Area Architecture Report
County Snow Emergency
Data
Congestion Log Text
Congestion Log
Component Configuration
Communication Log Text
Communication Log
C
C
CR
C
C
C
CRUD
C
CR
R
R
R
R
Figure 6-9. Process/Entity Matrix, Part 6/20(August 2000)
CHART II Business Area Architecture Report
Chart Map Data
Center Notepad
Center
Camera State Data
AVL
AVCM
Archive
Alert Data
Address Book
Action Log Text
Action Log
Acceptable Word
Dictionary
d
Log Incident Log
e
View Historical vs. Current
f
Log Congestion Log
g
Log Recurring Congestion Log
h
Log Special Event Log
i
Log Weather Advisory Log
j
Log Weather Sensor Log
k
Log Safety Message Log
l
View Log
m
Close Log
Location Navigation
a
Maintain Location Navigation Data
b
Activate Location Navigator
Queues
a
Calculate Queue Length
Notification
a
Maintain Notification List
b
Perform Notification
SHARED RESOURCE MANAGEMENT
DMS/HAR Common Processes
a
Maintain Acceptable Word Dictionary
b
Maintain Unacceptable Word Dictionary
c
Perform Responsibility Reminder
d
Respond to Responsibility Reminder Alert
DMS Processes
a
Maintain DMS Message Library
b
DMS – Add a Message
c
DMS – Remove a Message
d
DMS – Arbitrate Message Queue
e
DMS – Evaluate Queue
f
DMS – Send a Message
g
DMS – Blank a Sign
h
DMS - Reset
i
DMS – Restore Message
j
DMS- Override Queue
HAR Processes
a
Maintain HAR Message Library
b
HAR – Add a Message
c
HAR – Remove a Message
d
HAR – Arbitrate Message Queue
e
HAR – Evaluate Queue
f
HAR – Broadcast a Message
326
January 8, 2006
C
CHART II Business Area Architecture Report
U
R
R
R
R
R
R
CRUD
R
R
CRUD
RU
U
R
R
RU
327
January 8, 2006
Functional Right
R
Functional Responsibility
Group
Functional Responsibility
and Alert Types
FITM Plan
R
R
Figure 6-10. Process/Entity Matrix, Part 7/20(August 2000)
CHART II Business Area Architecture Report
Failure Log
Equipment Status
Equipment Inventory
EORS Permit Information
EORS Map Data
DMS Stored Message
DMS Message Library
DMS Message Arbitration
Queue
DMS
Disabled Log Text
Disabled Log
Device Configuration
Detector
County Snow Emergency
Map Data
d
Log Incident Log
e
View Historical vs. Current
f
Log Congestion Log
g
Log Recurring Congestion Log
h
Log Special Event Log
i
Log Weather Advisory Log
j
Log Weather Sensor Log
k
Log Safety Message Log
l
View Log
m
Close Log
Location Navigation
a
Maintain Location Navigation Data
b
Activate Location Navigator
Queues
a
Calculate Queue Length
Notification
a
Maintain Notification List
b
Perform Notification
SHARED RESOURCE MANAGEMENT
DMS/HAR Common Processes
a
Maintain Acceptable Word Dictionary
b
Maintain Unacceptable Word Dictionary
c
Perform Responsibility Reminder
d
Respond to Responsibility Reminder Alert
DMS Processes
a
Maintain DMS Message Library
b
DMS – Add a Message
c
DMS – Remove a Message
d
DMS – Arbitrate Message Queue
e
DMS – Evaluate Queue
f
DMS – Send a Message
g
DMS – Blank a Sign
h
DMS - Reset
i
DMS – Restore Message
j
DMS- Override Queue
HAR Processes
a
Maintain HAR Message Library
b
HAR – Add a Message
c
HAR – Remove a Message
d
HAR – Arbitrate Message Queue
e
HAR – Evaluate Queue
f
HAR – Broadcast a Message
CHART II Business Area Architecture Report
NWS Alert File
Notification List
Notification Data
Message Rules
Log
C
R
R
C
CRUD
R
CRUD
R
R
CR
C
C
C
C
R
R
R
CRUD
R
R
CRUD
RU
U
C
C
Figure 6-11. Process/Entity Matrix, Part 8/20(August 2000)
CHART II Business Area Architecture Report
Location Navigation Info
Link
CR
Incident Log Text
CU
Incident Log
Incident Interchange
Historical Data
HAR Voice Message
HAR Stored Message Text
HAR Message Library
HAR Message Arbitration
Queue
HAR
Geographic Responsibility
Functional Rights Group
d
Log Incident Log
e
View Historical vs. Current
f
Log Congestion Log
g
Log Recurring Congestion Log
h
Log Special Event Log
i
Log Weather Advisory Log
j
Log Weather Sensor Log
k
Log Safety Message Log
l
View Log
m
Close Log
Location Navigation
a
Maintain Location Navigation Data
b
Activate Location Navigator
Queues
a
Calculate Queue Length
Notification
a
Maintain Notification List
b
Perform Notification
SHARED RESOURCE MANAGEMENT
DMS/HAR Common Processes
a
Maintain Acceptable Word Dictionary
b
Maintain Unacceptable Word Dictionary
c
Perform Responsibility Reminder
d
Respond to Responsibility Reminder Alert
DMS Processes
a
Maintain DMS Message Library
b
DMS – Add a Message
c
DMS – Remove a Message
d
DMS – Arbitrate Message Queue
e
DMS – Evaluate Queue
f
DMS – Send a Message
g
DMS – Blank a Sign
h
DMS - Reset
i
DMS – Restore Message
j
DMS- Override Queue
HAR Processes
a
Maintain HAR Message Library
b
HAR – Add a Message
c
HAR – Remove a Message
d
HAR – Arbitrate Message Queue
e
HAR – Evaluate Queue
f
HAR – Broadcast a Message
328
January 8, 2006
CHART II Business Area Architecture Report
SHAZAM
Sensor Data
Scheduler Item
Scheduler Data
Safety Message Log Text
Safety Message Log
C
CR
C
U
C
C
C
C
C
C
C
C
C
RD
RD
RD
RD
C
C
C
C
C
C
C
C
Figure 6-12. Process/Entity Matrix, Part 9/20(August 2000)
CHART II Business Area Architecture Report
Role
Response Plan
CR
Recurring Congestion Log
Text
Recurring Congestion Log
Queue Data
Presets
Plan Item
Plan
Pavement/Weather Sensor
Data
Organization
Operators Notepad
Operations Log
d
Log Incident Log
e
View Historical vs. Current
f
Log Congestion Log
g
Log Recurring Congestion Log
h
Log Special Event Log
i
Log Weather Advisory Log
j
Log Weather Sensor Log
k
Log Safety Message Log
l
View Log
m
Close Log
Location Navigation
a
Maintain Location Navigation Data
b
Activate Location Navigator
Queues
a
Calculate Queue Length
Notification
a
Maintain Notification List
b
Perform Notification
SHARED RESOURCE MANAGEMENT
DMS/HAR Common Processes
a
Maintain Acceptable Word Dictionary
b
Maintain Unacceptable Word Dictionary
c
Perform Responsibility Reminder
d
Respond to Responsibility Reminder Alert
DMS Processes
a
Maintain DMS Message Library
b
DMS – Add a Message
c
DMS – Remove a Message
d
DMS – Arbitrate Message Queue
e
DMS – Evaluate Queue
f
DMS – Send a Message
g
DMS – Blank a Sign
h
DMS - Reset
i
DMS – Restore Message
j
DMS- Override Queue
HAR Processes
a
Maintain HAR Message Library
b
HAR – Add a Message
c
HAR – Remove a Message
d
HAR – Arbitrate Message Queue
e
HAR – Evaluate Queue
f
HAR – Broadcast a Message
329
January 8, 2006
R
CHART II Business Area Architecture Report
Weather Station
Weather Sensor Log Text
Weather Sensor Log
Weather File
Weather Advisory Log Text
Weather Advisory Log
R
CR
C
CR
C
CR
R
CRUD
R
R
R
R
Figure 6-13. Process/Entity Matrix, Part 10/20(August 2000)
CHART II Business Area Architecture Report
Wall Monitor Configuration
Wall Monitor Assignment
Vehicle Data
Users Center
User Preferences
User
Unacceptable Word
Dictionary
Tour
System Parameters
Special Event Log Text
Special Event Log
Smoothed Data
Signal
d
Log Incident Log
e
View Historical vs. Current
f
Log Congestion Log
g
Log Recurring Congestion Log
h
Log Special Event Log
i
Log Weather Advisory Log
j
Log Weather Sensor Log
k
Log Safety Message Log
l
View Log
m
Close Log
Location Navigation
a
Maintain Location Navigation Data
b
Activate Location Navigator
Queues
a
Calculate Queue Length
Notification
a
Maintain Notification List
b
Perform Notification
SHARED RESOURCE MANAGEMENT
DMS/HAR Common Processes
a
Maintain Acceptable Word Dictionary
b
Maintain Unacceptable Word Dictionary
c
Perform Responsibility Reminder
d
Respond to Responsibility Reminder Alert
DMS Processes
a
Maintain DMS Message Library
b
DMS – Add a Message
c
DMS – Remove a Message
d
DMS – Arbitrate Message Queue
e
DMS – Evaluate Queue
f
DMS – Send a Message
g
DMS – Blank a Sign
h
DMS - Reset
i
DMS – Restore Message
j
DMS- Override Queue
HAR Processes
a
Maintain HAR Message Library
b
HAR – Add a Message
c
HAR – Remove a Message
d
HAR – Arbitrate Message Queue
e
HAR – Evaluate Queue
f
HAR – Broadcast a Message
330
January 8, 2006
C
CHART II Business Area Architecture Report
R
R
R
CRU
C
C
C
R
C
R
CR
CR
R
R
R
C
CR
C
CR
C
C
R
CR
C
C
C
C
R
CR
CR
January 8, 2006
County Snow Emergency
Data
Congestion Log Text
Congestion Log
331
Component Configuration
R
Figure 6-14. Process/Entity Matrix, Part 11/20(August 2000)
CHART II Business Area Architecture Report
Communication Log Text
Communication Log
Chart Map Data
Center Notepad
Center
Camera State Data
AVL
AVCM
Archive
Alert Data
Address Book
Action Log Text
Action Log
Acceptable Word
Dictionary
g
HAR – Broadcast Default Message
h
HAR – Set Shazam On/Off
i
HAR – Update Default Message
j
HAR – Send Maintenance Command
k
HAR – Restore Message
l
HAR - Override Queue
AVCM
a
Maintain Wall Monitor Configuration
b
Control Wall Monitor Assignment
c
Maintain CCTV Presets
d
Refresh Default AVCM Presets
e
Maintain Tours
f
Activate Tour
g
Control Camera
Detectors
a
Handle Polled Detector Data
b
Handle Detector Rules
c
Generate Congestion Response
d
Respond to Congestion Alert
e
Generate Incident Response
f
Respond to Incident Alert
g
Activate Response Plan
Equipment
a
Maintain Equipment Inventory
b
Maintain Equipment Status
c
Alert For Delinquent Equipment Status
d
Respond to Delinquent Equipment Status Alert
Signals
a
Handle Signal Polling Data
b
Respond to Exceeded Signal Threshold Alert
c
Download Signal Data
AVL
a
Handle AVL Polling Results
b
Perform AVL Function Processing
c
Process AVL In/Out of Service Message
d
Process AVL Mayday Message
e
Process AVL Arrival On-Scene Message
f
Process AVL Assist Disabled Vehicle Message
g
Process AVL Assist Disabled CHART Vehicle Message
h
Process AVL Available Message
i
Respond to AVL Alerts
j
Respond to Mayday Alert from AVL
k
Respond to Arrival On-Scene Alert from AVL
CHART II Business Area Architecture Report
C
U
RU
U
RU
R
R
R
CRUD
CRUD
C
R
C
C
R
R
R
R
332
January 8, 2006
Functional Right
Functional Responsibility
Group
Functional Responsibility
and Alert Types
R
FITM Plan
R
Figure 6-15. Process/Entity Matrix, Part 12/20(August 2000)
CHART II Business Area Architecture Report
Failure Log
Equipment Status
Equipment Inventory
EORS Permit Information
EORS Map Data
DMS Stored Message
DMS Message Library
DMS Message Arbitration
Queue
DMS
Disabled Log Text
Disabled Log
Device Configuration
Detector
County Snow Emergency
Map Data
g
HAR – Broadcast Default Message
h
HAR – Set Shazam On/Off
i
HAR – Update Default Message
j
HAR – Send Maintenance Command
k
HAR – Restore Message
l
HAR - Override Queue
AVCM
a
Maintain Wall Monitor Configuration
b
Control Wall Monitor Assignment
c
Maintain CCTV Presets
d
Refresh Default AVCM Presets
e
Maintain Tours
f
Activate Tour
g
Control Camera
Detectors
a
Handle Polled Detector Data
b
Handle Detector Rules
c
Generate Congestion Response
d
Respond to Congestion Alert
e
Generate Incident Response
f
Respond to Incident Alert
g
Activate Response Plan
Equipment
a
Maintain Equipment Inventory
b
Maintain Equipment Status
c
Alert For Delinquent Equipment Status
d
Respond to Delinquent Equipment Status Alert
Signals
a
Handle Signal Polling Data
b
Respond to Exceeded Signal Threshold Alert
c
Download Signal Data
AVL
a
Handle AVL Polling Results
b
Perform AVL Function Processing
c
Process AVL In/Out of Service Message
d
Process AVL Mayday Message
e
Process AVL Arrival On-Scene Message
f
Process AVL Assist Disabled Vehicle Message
g
Process AVL Assist Disabled CHART Vehicle Message
h
Process AVL Available Message
i
Respond to AVL Alerts
j
Respond to Mayday Alert from AVL
k
Respond to Arrival On-Scene Alert from AVL
CHART II Business Area Architecture Report
C
R
C
CRU
R
C
CR
CR
R
C
R
R
January 8, 2006
R
R
R
R
NWS Alert File
Notification List
Notification Data
333
Message Rules
R
R
R
RU
Figure 6-16. Process/Entity Matrix, Part 13/20(August 2000)
CHART II Business Area Architecture Report
Log
Location Navigation Info
Link
Incident Log Text
Incident Log
Incident Interchange
Historical Data
HAR Voice Message
HAR Stored Message Text
R
HAR Message Library
R
R
HAR Message Arbitration
Queue
HAR
Geographic Responsibility
Functional Rights Group
g
HAR – Broadcast Default Message
h
HAR – Set Shazam On/Off
i
HAR – Update Default Message
j
HAR – Send Maintenance Command
k
HAR – Restore Message
l
HAR - Override Queue
AVCM
a
Maintain Wall Monitor Configuration
b
Control Wall Monitor Assignment
c
Maintain CCTV Presets
d
Refresh Default AVCM Presets
e
Maintain Tours
f
Activate Tour
g
Control Camera
Detectors
a
Handle Polled Detector Data
b
Handle Detector Rules
c
Generate Congestion Response
d
Respond to Congestion Alert
e
Generate Incident Response
f
Respond to Incident Alert
g
Activate Response Plan
Equipment
a
Maintain Equipment Inventory
b
Maintain Equipment Status
c
Alert For Delinquent Equipment Status
d
Respond to Delinquent Equipment Status Alert
Signals
a
Handle Signal Polling Data
b
Respond to Exceeded Signal Threshold Alert
c
Download Signal Data
AVL
a
Handle AVL Polling Results
b
Perform AVL Function Processing
c
Process AVL In/Out of Service Message
d
Process AVL Mayday Message
e
Process AVL Arrival On-Scene Message
f
Process AVL Assist Disabled Vehicle Message
g
Process AVL Assist Disabled CHART Vehicle Message
h
Process AVL Available Message
i
Respond to AVL Alerts
j
Respond to Mayday Alert from AVL
k
Respond to Arrival On-Scene Alert from AVL
CHART II Business Area Architecture Report
R
Figure 6-17. Process/Entity Matrix, Part 14/20(August 2000)
CHART II Business Area Architecture Report
334
January 8, 2006
SHAZAM
C
R
Sensor Data
R
R
Scheduler Item
CRUD
R
Scheduler Data
Safety Message Log Text
Safety Message Log
Role
Response Plan
Recurring Congestion Log
Text
Recurring Congestion Log
Queue Data
Presets
Plan Item
Plan
Pavement/Weather Sensor
Data
Organization
Operators Notepad
Operations Log
g
HAR – Broadcast Default Message
C
h
HAR – Set Shazam On/Off
C
i
HAR – Update Default Message
C
j
HAR – Send Maintenance Command
C
k
HAR – Restore Message
l
HAR - Override Queue
C
AVCM
a
Maintain Wall Monitor Configuration
C
b
Control Wall Monitor Assignment
C
c
Maintain CCTV Presets
C
d
Refresh Default AVCM Presets
C
e
Maintain Tours
C
f
Activate Tour
C
g
Control Camera
C
Detectors
a
Handle Polled Detector Data
b
Handle Detector Rules
C
c
Generate Congestion Response
C
d
Respond to Congestion Alert
C
e
Generate Incident Response
C
f
Respond to Incident Alert
C
g
Activate Response Plan
C
Equipment
a
Maintain Equipment Inventory
C
b
Maintain Equipment Status
C
c
Alert For Delinquent Equipment Status
d
Respond to Delinquent Equipment Status Alert
Signals
a
Handle Signal Polling Data
C
b
Respond to Exceeded Signal Threshold Alert
c
Download Signal Data
C
AVL
a
Handle AVL Polling Results
b
Perform AVL Function Processing
C
c
Process AVL In/Out of Service Message
d
Process AVL Mayday Message
e
Process AVL Arrival On-Scene Message
f
Process AVL Assist Disabled Vehicle Message
g
Process AVL Assist Disabled CHART Vehicle Message
h
Process AVL Available Message
i
Respond to AVL Alerts
j
Respond to Mayday Alert from AVL
k
Respond to Arrival On-Scene Alert from AVL
CHART II Business Area Architecture Report
CRUD
R
U
R
R
CRUD
R
CR
R
R
R
R
R
R
R
C
C
C
C
C
C
January 8, 2006
Weather Station
RU
Weather Sensor Log Text
Weather Sensor Log
Weather File
335
Weather Advisory Log Text
R
Figure 6-18. Process/Entity Matrix, Part 15/20(August 2000)
CHART II Business Area Architecture Report
Weather Advisory Log
Wall Monitor Config
Wall Monitor Assignment
Vehicle Data
Users Center
User Preferences
User
Unacceptable Word
Dictionary
Tour
System Parameters
Special Event Log Text
Special Event Log
Smoothed Data
Signal
g
HAR – Broadcast Default Message
h
HAR – Set Shazam On/Off
i
HAR – Update Default Message
j
HAR – Send Maintenance Command
k
HAR – Restore Message
l
HAR - Override Queue
AVCM
a
Maintain Wall Monitor Configuration
b
Control Wall Monitor Assignment
c
Maintain CCTV Presets
d
Refresh Default AVCM Presets
e
Maintain Tours
f
Activate Tour
g
Control Camera
Detectors
a
Handle Polled Detector Data
b
Handle Detector Rules
c
Generate Congestion Response
d
Respond to Congestion Alert
e
Generate Incident Response
f
Respond to Incident Alert
g
Activate Response Plan
Equipment
a
Maintain Equipment Inventory
b
Maintain Equipment Status
c
Alert For Delinquent Equipment Status
d
Respond to Delinquent Equipment Status Alert
Signals
a
Handle Signal Polling Data
b
Respond to Exceeded Signal Threshold Alert
c
Download Signal Data
AVL
a
Handle AVL Polling Results
b
Perform AVL Function Processing
c
Process AVL In/Out of Service Message
d
Process AVL Mayday Message
e
Process AVL Arrival On-Scene Message
f
Process AVL Assist Disabled Vehicle Message
g
Process AVL Assist Disabled CHART Vehicle Message
h
Process AVL Available Message
i
Respond to AVL Alerts
j
Respond to Mayday Alert from AVL
k
Respond to Arrival On-Scene Alert from AVL
CHART II Business Area Architecture Report
County Snow Emergency
Data
Congestion Log Text
Congestion Log
Component Configuration
336
Communication Log Text
CR
C
C
R
R
R
R
C
C
CR
C
C
R
Figure 6-19. Process/Entity Matrix, Part 16/20(August 2000)
CHART II Business Area Architecture Report
Communication Log
Chart Map Data
Center Notepad
Center
Camera State Data
AVL
AVCM
Archive
Alert Data
Address Book
Action Log Text
Action Log
Acceptable Word
Dictionary
l
Respond to Disabled Vehicle Alert from AVL
ALERTS
a
Send Manual Alert
b
Send Alert
c
Escalate Alert
PLANS
a
Maintain Plans
b
Activate Plan
c
Deactivate Plan
SCHEDULED EVENTS
a
Maintain Scheduled Events
b
Process Scheduled Events Start
c
Process Scheduled Events End
EORS INTERFACE
Construction
a
Download EORS Permits
b
Activate EORS Icon On Map
c
Activate EOR Permit
Snow Emergency
a
Maintain Snow Emergency Declaration
Phone Book
a
Access Phone Book
WEATHER SUPPORT
National Weather Service
a
View National Weather Service Data
b
Process Weather Alerts From The NWS
c
Respond to National Weather Service Alert
d
Fax Weather Report
SCAN
a
Handle Weather Sensor Data
b
Generate Weather Sensor Response
c
Respond to Weather Sensor Alert
ARCHIVING AND REPORTS
Archiving
a
Archive Update - Add
b
Archive Update - Update Log Data
c
Real Time System Update - Delete
Reports
a
Operational Reports
b
Reports from Archive
January 8, 2006
CHART II Business Area Architecture Report
CR
C
C
R
January 8, 2006
Functional Right
C
C
Functional Responsibility
Group
Functional Responsibility
and Alert Types
FITM Plan
337
Failure Log
R
R
R
Figure 6-20. Process/Entity Matrix, Part 17/20(August 2000)
CHART II Business Area Architecture Report
Equipment Status
Equipment Inventory
EORS Permit Information
EORS Map Data
DMS Stored Message
DMS Message Library
DMS Message Arbitration
Queue
DMS
Disabled Log Text
Disabled Log
Device Configuration
Detector
County Snow Emergency
Map Data
l
Respond to Disabled Vehicle Alert from AVL
ALERTS
a
Send Manual Alert
b
Send Alert
c
Escalate Alert
PLANS
a
Maintain Plans
b
Activate Plan
c
Deactivate Plan
SCHEDULED EVENTS
a
Maintain Scheduled Events
b
Process Scheduled Events Start
c
Process Scheduled Events End
EORS INTERFACE
Construction
a
Download EORS Permits
b
Activate EORS Icon On Map
c
Activate EOR Permit
Snow Emergency
a
Maintain Snow Emergency Declaration
Phone Book
a
Access Phone Book
WEATHER SUPPORT
National Weather Service
a
View National Weather Service Data
b
Process Weather Alerts From The NWS
c
Respond to National Weather Service Alert
d
Fax Weather Report
SCAN
a
Handle Weather Sensor Data
b
Generate Weather Sensor Response
c
Respond to Weather Sensor Alert
ARCHIVING AND REPORTS
Archiving
a
Archive Update - Add
b
Archive Update - Update Log Data
c
Real Time System Update - Delete
Reports
a
Operational Reports
b
Reports from Archive
CHART II Business Area Architecture Report
NWS Alert File
Notification List
Notification Data
Message Rules
338
Log
R
CR
R
R
R
R
R
Figure 6-21. Process/Entity Matrix, Part 18/20(August 2000)
CHART II Business Area Architecture Report
Location Navigation Info
Link
Incident Log Text
Incident Log
Incident Interchange
Historical Data
HAR Voice Message
HAR Stored Message Text
HAR Message Library
HAR Message Arbitration
Queue
HAR
Geographic Responsibility
Functional Rights Group
l
Respond to Disabled Vehicle Alert from AVL
ALERTS
a
Send Manual Alert
b
Send Alert
c
Escalate Alert
PLANS
a
Maintain Plans
b
Activate Plan
c
Deactivate Plan
SCHEDULED EVENTS
a
Maintain Scheduled Events
b
Process Scheduled Events Start
c
Process Scheduled Events End
EORS INTERFACE
Construction
a
Download EORS Permits
b
Activate EORS Icon On Map
c
Activate EOR Permit
Snow Emergency
a
Maintain Snow Emergency Declaration
Phone Book
a
Access Phone Book
WEATHER SUPPORT
National Weather Service
a
View National Weather Service Data
b
Process Weather Alerts From The NWS
c
Respond to National Weather Service Alert
d
Fax Weather Report
SCAN
a
Handle Weather Sensor Data
b
Generate Weather Sensor Response
c
Respond to Weather Sensor Alert
ARCHIVING AND REPORTS
Archiving
a
Archive Update - Add
b
Archive Update - Update Log Data
c
Real Time System Update - Delete
Reports
a
Operational Reports
b
Reports from Archive
January 8, 2006
R
CHART II Business Area Architecture Report
C
C
C
CRUD
R
R
D
C
C
C
CRUD
R
D
R
C
C
C
C
C
C
C
C
RU
R
C
R
January 8, 2006
C
RU
SHAZAM
Sensor Data
Scheduler Item
Scheduler Data
339
Safety Message Log Text
C
C
C
Figure 6-22. Process/Entity Matrix, Part 19/20(August 2000)
CHART II Business Area Architecture Report
Safety Message Log
Role
Response Plan
Recurring Congestion Log
Text
Recurring Congestion Log
Queue Data
Presets
Plan Item
Plan
Pavement/Weather Sensor
Data
Organization
Operators Notepad
Operations Log
l
Respond to Disabled Vehicle Alert from AVL
ALERTS
a
Send Manual Alert
b
Send Alert
c
Escalate Alert
PLANS
a
Maintain Plans
b
Activate Plan
c
Deactivate Plan
SCHEDULED EVENTS
a
Maintain Scheduled Events
b
Process Scheduled Events Start
c
Process Scheduled Events End
EORS INTERFACE
Construction
a
Download EORS Permits
b
Activate EORS Icon On Map
c
Activate EOR Permit
Snow Emergency
a
Maintain Snow Emergency Declaration
Phone Book
a
Access Phone Book
WEATHER SUPPORT
National Weather Service
a
View National Weather Service Data
b
Process Weather Alerts From The NWS
c
Respond to National Weather Service Alert
d
Fax Weather Report
SCAN
a
Handle Weather Sensor Data
b
Generate Weather Sensor Response
c
Respond to Weather Sensor Alert
ARCHIVING AND REPORTS
Archiving
a
Archive Update - Add
b
Archive Update - Update Log Data
c
Real Time System Update - Delete
Reports
a
Operational Reports
b
Reports from Archive
CHART II Business Area Architecture Report
Weather Station
Weather Sensor Log Text
Weather Sensor Log
Weather File
Weather Advisory Log Text
Weather Advisory Log
Wall Monitor Configuration
Wall Monitor Assignment
Vehicle Data
Users Center
User Preferences
User
Unacceptable Word Dictionary
Tour
System Parameters
Special Event Log Text
Special Event Log
Smoothed Data
Signal
l
Respond to Disabled Vehicle Alert from AVL
ALERTS
a
Send Manual Alert
b
Send Alert
c
Escalate Alert
R
PLANS
a
Maintain Plans
b
Activate Plan
c
Deactivate Plan
SCHEDULED EVENTS
a
Maintain Scheduled Events
b
Process Scheduled Events Start
c
Process Scheduled Events End
EORS INTERFACE
Construction
a
Download EORS Permits
b
Activate EORS Icon On Map
c
Activate EOR Permit
R
R
R
Snow Emergency
a
Maintain Snow Emergency Declaration
Phone Book
a
Access Phone Book
WEATHER SUPPORT
National Weather Service
a
View National Weather Service Data
b
Process Weather Alerts From The NWS
c
Respond to National Weather Service Alert
d
Fax Weather Report
R
R
R
SCAN
a
Handle Weather Sensor Data
b
Generate Weather Sensor Response
CR
c
Respond to Weather Sensor Alert
CR
R
ARCHIVING AND REPORTS
Archiving
a
Archive Update - Add
b
Archive Update - Update Log Data
c
Real Time System Update - Delete
Reports
a
Operational Reports
b
Reports from Archive
Figure 6-23. Process/Entity Matrix, Part 20/20(August 2000)
CHART II Business Area Architecture Report
340
January 8, 2006
CHART II Business Area Architecture Report
7 Technology Model View
This section presents model views of the Technology domain of change as derived from CHART
II visioning workshops and analysis of the technological architecture required to support the
proposed processes. The Direction Model provides the principles, constraints and assumptions
that guide the design of the technological architecture. The Diagnostic Model describes existing
components that will be considered for use. The Conceptual Model presents a high-level view of
the planned architecture for the CHART II system. The Performance Model provides a summary
of the performance requirements for the system.
7.1 Technology Direction Model
This model shows what application principles, constraints, and assumptions impact the project.
7.1.1 Technology Principles, Constraints, and Assumptions
Numerous principles, constraints, and assumptions (PCAs) were derived for this particular model
view. The table below shows how the BAA process scored in applying the identified PCAs. The
scoring is defined as follows:

Applied = The PCAs were observed and applied to one or more of the Domains of
Change

To Be Applied = The PCAs were not viewed as relevant to this phase of the project, but
may be applied in later phases (i.e., Design, Development, and Deployment)

Not Applicable = The PCAs identified were replaced by different approaches used in
process design
Principles

CHART II will use the statewide communications network to meet the bulk of its wide
area network requirements

Existing technical components will be incorporated (as deemed appropriate) to support
future business requirements.

The CHART II system will have the capability of being fully distributed.

A RDBMS will be used to store and manage persistent data.

The Common Object Request Broker Architecture (CORBA) will be used to manage
and distribute objects between clients and servers.
Constraints and Standards
CHART II Business Area Architecture Report
341
January 8, 2006
CHART II Business Area Architecture Report

All appropriate components will be NTCIP compliant.

The solution will be compatible with the Windows XP operating system.
Assumptions

The MDOT Managed Network will continue to be in place to support the CHART
Operations Environment.
7.1.2 Key Technical Performance Factors
Key technical performance factors are a high-level summary of factors presenting risks or
challenges from a technical perspective.

The system will support operations 24 hours a day, 7 days a week.

Provide a highly available system through redundancy and geographic distribution.

The state of the system (device status, current messages, etc) shall be maintained and
shall persist through a system shutdown and startup cycle.
7.1.3 Technology Requirements Model
The Technology Requirements model documents the technical services, hardware, system
software, and network communications needs of the system.
Enterprise-Wide Standard Technology Requirements
Category
Hardware
Requirements
The following are the estimated minimum requirements for CHART
hardware. Actual hardware deployed will be based on the detailed
hardware requirements and will take into account the current state of
the industry (e.g. use of the latest processor chips).

Standard workstation hardware is 2.8GHz (or better) processor, 1
GB memory, 20 GB storage.

Standard server hardware is Pentium III Zeon (or better) quad
processor, 4GB memory, 80GB RAID.

CHART-Lite hardware is 2.4GHz (or better) single processor,
3GB memory, 20GB storage.
CHART II Business Area Architecture Report
342
January 8, 2006
CHART II Business Area Architecture Report
Category
Software
Requirements



Operating system software is Windows 2000 Server SP4
(Servers)
Operating system Software is Windows XP Professional
(Workstations)
Standard workstation software suite includes:
- Novell GroupWise email
- Microsoft Office
- Web browser (Internet Explorer)

Standard server software suite includes:
- Oracle 10g
Communications

Communications between servers and from servers to the field
devices must be available 24 hours/day.

Failure of communications to a server or failure of a server will
not affect the ability of other servers from communicating with
field devices.
Technology Requirements Matrix
Technology Location
Node
Requirements
Statewide Operations
Center (SOC)
Servers and
workstations

Supports all CHART applications.

Central site for CHART administration
and configuration.
Traffic Operations Centers
(TOC)
Servers and
workstations

Supports all CHART applications.

Ability to take over full range of
CHART functions from SOC in an
emergency.
Authority Operations
Center (AOC)
Servers and
Workstations

Supports all CHART applications.

Configured to be SOC Server Backup
Site

Ability to take over full range of
CHART functions from SOC in an
emergency.

Capability to perform any SOC
function. Allowable functions
Network Operations Center
(NOC)
Workstations
CHART II Business Area Architecture Report
343
January 8, 2006
CHART II Business Area Architecture Report
controlled on a per user basis.
Police Agencies (MSP, BA
Co PD, MdTA)
Workstations

Capability to perform any SOC
function. Allowable functions
controlled on a per user basis.
Maintenance Shops
Workstations

Capability to perform any SOC
function. Allowable functions
controlled on a per user basis.
CHART-Lite users
CHART-Lite
Workstations

Capability to perform any SOC
function. Allowable functions
controlled on a per user basis.

Capability to perform any SOC
function. Allowable functions
controlled on a per user basis.
Local Level TMC’s
MCTMC, PGTRIP
CHART II Business Area Architecture Report
344
January 8, 2006
CHART II Business Area Architecture Report
7.2 Technology Diagnostic Model
7.2.1 Technology Profile
The Technology Profile summarizes key information about current technology capabilities.
NOTE: Refer to latest release documents and System Architecture Guide for most up to date
hardware configurations and network diagrams.
Hardware
Location
Technology Type
Vendor
Description
SOC
Server
Compaq
Proliant ML570
AOC
Server
Compaq
DL380
SOC
Workstation
Compaq
HP XW6000
TOC-4
Workstation
Compaq
HP XW6000
TOC-3
Workstation
Compaq
HP XW6000
AOC
Workstation
Compaq
HP XW6000
NOC
Workstation
Compaq
HP XW6000
NOC
Workstation
Compaq
Professional 5000
Software
Location
Technology Type
Vendor
Description
SOC
Application
Silverlake
Paging software
SOC
Application
SSI
SCAN WEB (Weather
Pavement Sensors)
SOC
Productivity
Novell
GroupWise email
CHART II Business Area Architecture Report
345
January 8, 2006
CHART II Business Area Architecture Report
7.3 Conceptual Technology Model
7.3.1 Technology Concept Diagram
The diagram below shows the conceptual architecture of the future system illustrating the use of
the CORBA ORB for process communication.
Information Exchange Network
Partners-In-Motion
VDOT Traffic Management System
SCAN for Windows
EIS EORS
SSI Weather Source
Detectors
DMS
HAR
Shazam
External Systems Server
Legacy Systems Server
Security Server
Zone Management Server
FMS
Remote
TCP/IP
Communication
Legacy
Database
FMS Server
CHART Server
CORBA ORB
Web Server
Web Export Server
GUI Client
CHART II Database Server (TMDD schema)
CORBA ORB
AVCM Server
Fax Server
Pager Server
Page Recipients
Fax Recipients
Cameras
Figure 7-1. CHART II Conceptual Architecture
CHART II Business Area Architecture Report
346
January 8, 2006
CHART II Business Area Architecture Report
7.3.2 Network Concept Diagram
Below is a network concept diagram showing the future system network connectivity.
DMS
ROA DWORK
EX I T 1 0 - 1 2
1 0 P M- 3 A M
Windows 2000 Svr SP4
CHART II Client
AVCM Client
Windows XP Prof.
CHART II Client
AVCM Client
Cisco 2516
SHAZAM
TOC
s
Modem
CHART Workstation
Travelers
InformationTune Radio to
1650 AM
Windows XP Prof.
CHART II Client
AVCM Client
CHART Workstation
Multiplexer
CHART Workstation
Switches
Cisco 7206
Greenbelt
ATM
Switch
BA
Frame Relay
HAR
Switches
Brooklandvill
ATM
e
Switch
n x T-1
CSU/DSU
Cisco 2524
CHART Backbone
BA
Frame Relay
CHART Backbone
Cisco 2524
HAR
Remote
FMS
SERVER
Travelers
InformationTune Radio
to 1650 AM
Cisco 7206
Remote
FMS
SHAZAM
Server
Windows 2000 Svr
SP4
ISDN/POTS interface (COTS)
Telephony Board
Comunications Service
ISDN/POTS
Windows 2000 Svr SP4
ISDN/POTS interface (COTS)
Telephony Board
Comunications Service
MDOT WAN
Hanover
ATM
Switch
CSU/DSU
CHART
Backbone
Multiplexer
ISDN/
POTS
Detector
CHART
Serve II
r
NT Server 4.0 SP5
Cisco 2516
AOC
Oracle 8i RDBMS
CHART II Server AppsMDTA
Modem
Modem
DMS
R O A D WO R K
EX I T 1 0 - 1 2
1 0 P M- 3 A M
Trader Service
Event Service
User Manager Service
Traffic Event Service
DMS Service
Message Utility Service
TSS Service
EORS Permit Service
HARS Service
TTSService
Modem
Cisco 7206
Windows 2000 Svr SP4
Oracle 10g RDBMS
CHART II Server Apps
Trader Service
Event Service
User Manager Service
Traffic Event Service
DMS Service
Message Utility Service CHAR
TSS Service
T
II
Serve
EORS Permit Service
HARS Service
r
TTSService
CHART
Workstation
Windows XP Prof.
CHART II Client
AVCM Client
EORS DB
Server
Switches
Detector
Windows XP Prof.
CHART II Client
AVCM Client
CHART Workstation
Switches
CHART II Web
Server
0
Figure 7-2. CHART II Network Concept Diagram
CHART II Business Area Architecture Report
347
January 8, 2006
CHART II Business Area Architecture Report
7.4 Performance Engineering Model
7.4.1 System Performance
The tables presented below summarize the performance requirements that have been identified as
being drivers in the design of the system. This includes response time requirements, transaction
volume estimates, and storage requirements.
Response Time
Category
Response Time (seconds)
Source
Redraw/update screens
3
Requirement M-P1
Update message on a DMS
10
Goal
Transaction Volume
The transaction rates shown in the table below are aggregate rates for the entire system. The
conceptual architecture does not limit the transaction volume that the system can handle. Higher
transaction rates can be accommodated by adding additional hardware (and possibly network
bandwidth) as needed.
Transaction
Aggregate System Rate
Detector data
1.6 entry/sec
Source
187 detectors (minimum)
1 entry/detector/2 min
Weather data
<1/min (summer)
44 weather stations
2.2/min (winter)
1 entry/detector/60 min
(summer)
1 entry/detector/20 min
(winter)
Operations Log
2.5/min
Derived
Storage
Storage estimates presented in the table below are for the major data sources and account for the
majority of the storage requirements.
Item
Devices characteristics
Size
Source
10,000 devices * 1868 bytes MDSHA CHART Software
= 1.8MB
Functional Requirements
Document
CHART II Business Area Architecture Report
348
January 8, 2006
CHART II Business Area Architecture Report
Operations Log
Event Log
Detector data
Weather data
3,500 entries/day * 1439
bytes = 5MB/day
Derived
20 entries/day * 14K bytes
= 0.3MB/day
Derived
134,640 entries/day * 30
bytes = 4MB/day
Derived
1,056 entries/day * 30 bytes Derived
= 32KB/day (summer)
3168 entries/day * 30 bytes
= 95KB/day (winter)
7.4.1 System Availability
The CHART system must support operations 24 hours per day year round. To achieve this the
system architecture definition is guided by the following concepts:
 Redundancy
 Redundant hardware at key locations guards against loss of service due to hardware
failures.
 Replication of key data guards against loss of service due to loss of data access.
 Fault Tolerance
 Distributed architecture (with data replication) ensures that a failure at one location does
not jeopardize continued operations from other locations.
 Multi-path communications network (combined with the distributed architecture)
minimizes the chance of an operational device becoming completely unreachable.
 Fault Identification
 System monitoring and alerting provides timely notification of system problems to
operations personnel so that corrective action can be taken promptly.
CHART II Business Area Architecture Report
349
January 8, 2006
CHART II Business Area Architecture Report
Appendix A – List of Acronyms
The following acronyms appear throughout this document:
AOC
Authority Operations Center
AOR
Area of Responsibility
ATM
Asynchronous Transfer Mode
ATMS
Automated Transportation Management System
AVCM
ATM Video Control Module
AVL
Automatic Vehicle Locator
BAA
Business Area Architecture
CCTV
Closed-Circuit Television
CHART
Coordinated Highways Action Response Team
CORBA
Common Object Request Broker Architecture
COTS
Commercial Off-The-Shelf (usually a software package)
DBMS
Database Management System
DMS
Dynamic Message Sign
EORS
Emergency Operations Reporting System
ERU
Emergency Traffic Patrol
ETP
Emergency Response Unit
FITM
Freeway Incident Management Traffic Management
FMS
Field Management Station
GIS
Geographic Information System
GUI
Graphical User Interface
HAR
Highway Advisory Radio
HOT
Highway Operations Technician
CHART II Business Area Architecture Report
350
January 8, 2006
CHART II Business Area Architecture Report
IEN
I-95 Corridor Coalition Information Exchange Network
ITS
Intelligent Transportation System
MDOT
Maryland Department of Transportation
MdTA
Maryland Transportation Authority
MSP
Maryland State Police
MTA
Mass Transit Administration
NIA
National ITS Architecture
NWS
National Weather Service
PIM
Partners in Motion
R1B1
Release 1, Build 1 of the CHART II System
SHA
State Highway Administration
SOC
Statewide Operations Center
TMDD
Traffic Management Data Dictionary
TOC
Traffic Operations Center
VDOT
Virginia Department of Transportation
VMS
Variable Message Sign
XAD
Accelerated Application Development
CHART II Business Area Architecture Report
351
January 8, 2006