SunGuideSM Software Development Project
Release 3.0 Design Review
May 8-9, 2007
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
2
Introductions
Design Review
May 8-9, 2007
3
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
4
Meeting Objectives

Requirements:
– Provide a high level review
– Provide SwRI’s interpretation (via a design) of
the requirements

Design
– High level architectural overview
– Operator actions and reactions
– Prototype screens / reports

Not an objective:
– Revise requirements
Design Review
May 8-9, 2007
5
Release 3.0 Development
Activities
Design Review
May 8-9, 2007
6
SRS Discussion

SwRI’s interpretation of FDOT’s
requirements

FDOT “system” requirements
assigned as “FEAT”
requirements

SwRI “derived” requirements
listed as “SUB” requirements

Document contains
requirements from < R3.0

The text of “FEAT”
requirements is contractually
limited (i.e. do not edit)
Design Review
May 8-9, 2007
7
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
8
Configuration Editor

‘config.xml’ file is the master
configuration file for all
SunGuideSM processes

If an error is made in editing the
XML file it can cause serious side
effects

Windows based editor will be
developed that simplifies the
editing process (and make it less
error prone)
Design Review
May 8-9, 2007
9
Configuration Editor:
Requirements

Provide a “easy to use” editor
to facilitate editing of the
SunGuideSM configuration file
(config.xml)

Changes will be to the
parameters identified in the
VDD (no source code changes
will be required)

Appropriate permissions will be
required to access the editor
Design Review
May 8-9, 2007
10
Config Editor: GUI Mockups

The “File” menu provides
options to open a
configuration file and to
save the edited
configuration file

Selecting “Open” from
the file menu opens a
dialog to used to select
the configuration file for
editing.
Design Review
May 8-9, 2007
11
Config Editor: GUI Mockups –
con’t

Selecting a configuration
file to open

Clicking “Open” after
selecting the file will load
the configuration file into
the editor
Design Review
May 8-9, 2007
12
Config Editor: GUI Mockups –
con’t

Users can drill down into
the file to select options
to change
Design Review
May 8-9, 2007
13
Config Editor: GUI Mockups –
con’t

Parameters may be
modified by editing
the value in the panel
on the right side
Design Review
May 8-9, 2007
14
Config Editor: GUI Mockups –
con’t

After modifications are made, changes must be saved
using the File menu
Design Review
May 8-9, 2007
15
Config Editor: GUI Mockups –
con’t

Creation wizards can be used to help make a large change to
the file safely at an appropriate location.
Design Review
May 8-9, 2007
16
Configuration Editor
Questions?
Design Review
May 8-9, 2007
17
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
18
Event Viewer (EV)

Read-only web site displaying:
– Active events with a lane blockage
– Active events without a lane blockage
– Recently inactive events

Details page displays information about a specific event
record

Runs on a Windows IIS server

Prompts for a username and password
Design Review
May 8-9, 2007
19
Event Viewer: Requirements

Logout button provided to end
secure access

Data will refresh automatically
at a configurable interval

Events will be flagged as
‘inactive’ after a configurable
amount of time has passed
without activity
Design Review
May 8-9, 2007
20
Event Viewer: Requirements –
con’t

Allow access restriction based
on IP address

Support use of SSL security via
Microsoft IIS
Design Review
May 8-9, 2007
21
Event Viewer: Requirements –
con’t

Sections of the event list will
differ in background color

Selecting (clicking) an event
will open then event details for
the event

Event details will contain:
– Event data
– Related Road Ranger data
– Agency response data
– Event chronology summary
Design Review
May 8-9, 2007
22
Event Viewer: Requirements –
con’t

Associated events will contain
links between event details
pages
Design Review
May 8-9, 2007
23
Event Viewer: Derived
Requirements

Accessible via SunGuide
website

Site will not be accessible to IP
addresses outside the allowed
range specified within IIS
Design Review
May 8-9, 2007
24
Event Viewer: GUI Mockups
Login Screen

ASP.NET application

IIS provides the ability to
restrict users by:
– Domain
– IP (single or range)
– Username / password

Application security will be
based on SunGuideSM user
credentials
Design Review
May 8-9, 2007
25
Event Viewer: GUI Mockups
Summary and Detail Screens

Directed to retain existing D4
Smart Viewer “look and feel”:
– Yes?

Events summarized by:
– Active with lane blockage
– Active with no lane
blockage
– Inactive events

Details presented in a READ
ONLY fashion
Design Review
May 8-9, 2007
26
Event Viewer Questions?
Design Review
May 8-9, 2007
27
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
28
Incident Detection: Design
Overview

Subsystem Development
– Design new database tables
– Subscribe for incident alarms from VisioPaD driver
– Subscribe for incident alarms from TSS Alarm driver
– Publish combined alarms to subscribers
– Log alarms to database

VisioPaD Driver Development
– Accept incident data from CitiLog TCP Server
– Publish incident alarms to ID subsystem
Design Review
May 8-9, 2007
29
Incident Detection: Design
Overview – con’t

TSS Alarm Driver Development
– Subscribe for TSS alarm data from TSS
– Publish incident alarms to ID subsystem

GUI Development
– Adapt current TSS Alarm handling to incident alarms
– Send Alarm Confirmed or Canceled message to IDS
– Create and send new Event message to EM
– Develop Admin Editor screen for defining CitiLog
camera locations
Design Review
May 8-9, 2007
30
Incident Detection: Requirements

Incident detection (previously
part of TSS) will be centralized
into the Incident Detection
subsystem

When potential incidents are
identified, the alert will be
published to Data Bus –
subsystems subscribed to
incident alerts will be notified
(e.g. EM subsystem)

A driver for VisioPAD will be
developed
Design Review
May 8-9, 2007
31
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
32
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
33
Incident Detection
Architectural Overview






Database stores alerts and
Citilog camera mapping data
IDS Subscribe Handler manages
sending alert data to clients
IDS Retrieve Data Handler
manages reception of data from
drivers
IDS Config Handler delivers
CitiLog camera mapping data to
VisioPaD driver
VisioPaD Event Handler manages
connection with and data from
the CitiLog server
TSS Alarm Handler subscribes
for and manages alarm data from
TSS
Design Review
May 8-9, 2007
34
Incident Detection
Administrative Editor (for “devices”)

Device location

Device identifier
information

Associate closest
SunGuideSM CCTV
Design Review
May 8-9, 2007
35
Incident Detection
Operator Interface

Alarm dialog will be
presented to users
subscribed via Data Bus

Location will be provided
Design Review
May 8-9, 2007
36
Incident Detection
Overview of Data Flow – client to drivers
Design Review
May 8-9, 2007
37
Incident Detection
Data Flow – Subsystem to Driver
Design Review
May 8-9, 2007
38
Incident Detection
Questions?
Design Review
May 8-9, 2007
39
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
40
AVL: Design Overview

Subsystem Development
– Design new database tables
– Subscribe for vehicle location data from Road Ranger
Location driver
– Subscribe for vehicle location data from External Data
driver
– Publish location update data to subscribers
– Store location update data to database
– Develop queries for retrieving vehicle track records
– Develop geo-location queries for geo-fence violations

External Data Driver Development
– Develop file retrieval from URL, FTP, and shared folder
sources
– Parse and translate AVL data to SG format
– Publish external source location data to AVL subsystem
Design Review
May 8-9, 2007
41
AVL: Design Overview – cont.

Road Ranger Location Driver Development
– Subscribe for Road Ranger location data from RR
subsystem
– Publish Road Ranger location data to AVL subsystem

GUI Development
– Develop vehicle icon selector
– Develop geo-fence creation and editing facility
– Develop vehicle status and position updates for display
– Develop vehicle list, summary, and detail dialogs
– Develop “Find Vehicle on Map” facility
– Develop “breadcrumb track” data retrieval and display
– Develop Admin Editor screen for add and deleting
tracked vehicles
– Develop Admin Editor screen for maintaining AVL data
source locations
Design Review
May 8-9, 2007
42
AVL: Requirements

New Admin Editor screens for
managing external sources and
tracked vehicles will be
developed

Time-stamped location data for
tracked vehicles will be stored
in the SunGuide database

GUI will include support for
icon selection and a tabular
vehicle list window
Design Review
May 8-9, 2007
43
AVL: Requirements – cont.

An External Sources driver will
be developed to retrieve XMLformatted vehicle location data
from URL, FTP, and shared
folder sources

Current position of tracked
vehicles will be shown on the
Operator Map using selectable
icons

A vehicle status summary
“tooltip” dialog will be
displayed by mouse hovering
Design Review
May 8-9, 2007
44
AVL: Requirements – cont.

AVL will support at least four
availability status values

A detailed vehicle status dialog
will be available when clicking
on a vehicle icon or selecting a
vehicle from the vehicle list

Detailed vehicle status data will
include stopped time or moving
time as appropriate
Design Review
May 8-9, 2007
45
AVL: Requirements – cont.

External source data will be reformatted and re-ordered as
necessary

The location of the closest road
will be substituted and flagged
for inexact location data

A Road Ranger Location driver
will be developed that will
retrieve RR location data from
the RR subsystem

Vehicle locations on the map
will be updated as data is
received
Design Review
May 8-9, 2007
46
AVL: Requirements – cont.

AVL will need roadway and
cross-street geo-data in Oracle
Locator tables to convert lat/lon
to roadway text description

AVL and Operator Map will
support real-time and playback
display of previous location
position (“breadcrumb trail”)

Position replays will support
vehicle selection and time span
selection
Design Review
May 8-9, 2007
47
AVL: Requirements – cont.

A new map-based geo-fence
editor GUI will be developed,
similar to the TSS Link Editor

Geo-fence polygon data will be
stored in Oracle geo-spatial
tables that support queries for
finding points in shapes
Design Review
May 8-9, 2007
48
AVL
Architectural Overview






Database stores vehicle track
and external sources data
AVL Subscribe Handler manages
sending location data to clients
AVL Retrieve Data Handler
manages reception of data from
drivers
AVL Config Handler delivers
external sources data to External
Sources driver
External Sources Handler
manages location data retrieval
from external sources
RR Location Handler subscribes
for and manages location data
from Road Ranger
Design Review
May 8-9, 2007
49
AVL Administrative Editor
Administrative Editor – Add/Edit Vehicles
Design Review
May 8-9, 2007
50
AVL Administrative Editor
Add and Edit AVL External Data Sources
Design Review
May 8-9, 2007
51
AVL GUI
AVL Status Summary Dialog
AVL Status Summary Tooltip
Design Review
May 8-9, 2007
52
AVL GUI
AVL Detailed Status Dialog
Design Review
May 8-9, 2007
53
AVL GUI
AVL Vehicle List Dialog
Design Review
May 8-9, 2007
54
AVL
Operator Map with AVL Status
Design Review
May 8-9, 2007
55
AVL
Geo-Fence Editor
Design Review
May 8-9, 2007
56
AVL
Data Flow –
Subsystem
to Driver
Design Review
May 8-9, 2007
57
AVL Questions?
Design Review
May 8-9, 2007
58
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
59
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
60
Road Ranger

The RR subsystem will be used to manage, dispatch, and
collect data of RR Service Patrols

Collect and provide RR vehicle status information
– RR vehicle and beat identification
– Status (e.g. patrolling, assist-motorist, etc)

Collect and provide shift information
– Shift start and end times
– Vehicle mileage
– Driver, vehicle, radio, and route identification
Design Review
May 8-9, 2007
61
Road Ranger: continued

Collect and provide service call information
– Dispatch, arrival, and departure times
– Location
– Reason for stop
– Services rendered
– Lane blockages

Drivers:
– District 4 Tablet PC
– XML based interface
Design Review
May 8-9, 2007
62
Road Ranger: Requirements

New Admin Editor screens for
managing RR personnel,
trucks, beat association, etc.
will be developed.

Time-stamped status data and
activities for monitored RRs will
be stored in the SunGuide
database to track billable hours
and availability.

GUI will include support for
operator input to change
status, radio number, beat, and
driver for RR trucks.
Design Review
May 8-9, 2007
63
Road Ranger: Requirements –
con’t

Radio and District numbers will
be time-stamped and stored in
the SunGuide database at the
beginning of RR shifts.

Vehicle mileage will be
recorded similarly at the end of
RR shifts.

Event data will include items
such as:
– Enroute
– At Scene
– Cleared Scene
– On Break
– Assisting Others
Design Review
May 8-9, 2007
64
Road Ranger: Requirements –
con’t

GUI will notify operators when
drivers are stopped for a
configurable length of time
without justification.

Road Ranger drivers will be
built to support
communications with service
vehicle data collection streams.
– RR Tablet driver
– XML Interface driver
Design Review
May 8-9, 2007
65
Road Ranger
Architectural Overview







Database stores RR status,
activity, and shift data
RR Status Handler manages
periodic RR event progress
RR Shift Handler collects shift
start and end times
RR Config Handler processes
added/modified and removed
RRs from the system
RR Retrieve Data Handler
manages reception of data
from drivers
RR Activity Handler manages
reported, performed activities
RR Subscribe Handler
manages sending RR updates
to clients
Design Review
May 8-9, 2007
66
Road Ranger
Administrative Editor

Admin Editor will allow
adding / modifying /
deleting of Road
Ranger Operators,
Trucks, and Beats

Maximum stop length:
should be configurable
per truck, systemwide, etc?
Design Review
May 8-9, 2007
67
Road Ranger
Operator Map GUIs
Status window will
allow selection of one
or more RR trucks
Truck Manager window
will allow operators to
modify trucks
Design Review
May 8-9, 2007
68
Road Ranger
Data Flow –
Between Subsystem
and Drivers
Design Review
May 8-9, 2007
69
Road Ranger Concept of Operations
(based on requirements)

At the 10,000 foot level, the requirements indicate that a mobile
device (RR) resembles a TMC operator workstation with respect to
data entry for an event.

SwRI’s understanding of the requirements:
– Road rangers perform data entry into the tablet
– The tablet data is transmitted wirelessly to the SunGuide
software (D4) or is uploaded at the end of a shift to the
SunGuide software
– SunGuide software utilizes that data to add to an active event,
or create a new event
– TMC operators and road rangers may add to or change data,
both being recorded in the event description with TMC
operator resolving inconsistencies.

There are other requirements which deal with geo-fencing, beat /
off-beat detection, tracking of AVL enabled vehicles, billable / nonbillable activities, etc.
Design Review
May 8-9, 2007
70
Is this ConOps consistent
with District needs?
Design Review
May 8-9, 2007
71
RR Options

Current Option #1 (blue)
– Based on 3.0 requirements,
RR collects data and pushes
new events to EM

Enhancement Option #2 (red)
– Add functionality for RR to
pull event data from EM to
approve/confirm
assignments.
Design Review
May 8-9, 2007
72
Road Ranger Questions?
Design Review
May 8-9, 2007
73
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
74
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
75
Event Management (EM)

Migrating Release 2.2.0 to “SunGuideSM Compliant”; implies
building an “EM Subsystem” that is compliant to the
SunGuideSM Architecture Guidelines

EM will be based on the Release 2.2 event management
related functional requirements

Release 2.2.0 had two methods of “event management”:
– HTML GUI that supports single incident management
– Tabular GUI that supports multiple “events”

Features will be combined into a SINGLE GUI and termed
“event management”
Design Review
May 8-9, 2007
76
EM: continued

Manage events and EM user permissions
– Users may add, modify, delete events
– Users may associate related events, contacts

Activate and deactivate response plans
– Send DMS, HAR, remote messages to MAS as
recommended
– Send recommended email messages

Process event data subscriptions

GUI enables input for Road Ranger performed activities
Design Review
May 8-9, 2007
77
Responder Audit

In SWAM #11 FDOT is adding
responder audit functionality

These requirements are now
included in the Release 3.0
baselined requirements

The work to implement
responder audit was assigned
to IBI

These new requirements are
included the EM and Reporting
sections that follow
Design Review
May 8-9, 2007
78
EM: Requirements

Easy to use, intuitive user
interface

Efficient and ergonomic design

The EM GUI is designed to
minimize the number of key
strokes and actions to be
performed by the operator
Design Review
May 8-9, 2007
79
EM: Requirements – con’t

Fully integrated Event
Management and Response
Plan generation interface

Single Response Plan
generation interface supports
the generation and
dissemination of DMS, HAR and
Email messages
Design Review
May 8-9, 2007
80
EM: Requirements – con’t

Event Management screens
similar to those in R 2.2 (similar
in look, feel and navigation)
shall facilitate the management
of incidents, deployment of
responders, the accurate
recording of incident
information and the expedition
of incident clearance
Design Review
May 8-9, 2007
81
EM: Requirements – con’t

Identification of work zones

Data Archiving

Diversion routes
Design Review
May 8-9, 2007
82
EM: Requirements – con’t

The Event Management and
Response Plan generation
subsystems (and associated
GUIs) shall generally inherit the
event management and
response plan generation
functionality of the existing IM
and EMPM Subsystems.
Design Review
May 8-9, 2007
83
EM: Requirements – con’t

Canceled Response Plans clear
all message from queues

Events are release when
operator logs out of the system

All ownerships changes are
stored in database

Events can only be modified by
the owner
Design Review
May 8-9, 2007
84
EM: Requirements – con’t

Event Manager List – summary
view of all active events

Edit Agency Timeline data in
real-time

Edit Lane Blockage data using
point-click methods

Edit Lane Configuration for the
event

Operator Comments
Design Review
May 8-9, 2007
85
EM: Requirements – con’t

Event creation time recorded

Event Status includes:
– Unresolved
– Closed
– False Alarm

Lane Blockage time recorded

Record vehicle descriptions
including make, model, color,
state, tag
Design Review
May 8-9, 2007
86
EM: Requirements – con’t

Select Event Type from list

Events are geo-coded using
latitude and longitude

Specify Event Location
including:
– County
– Roadway
– Direction
– Exit
– Relationship to Exit

Specify weather conditions
Design Review
May 8-9, 2007
87
EM: Requirements – con’t

Responders
– TMC Notified flag
– Notification/Dispatch Time
– Arrive On-Scene Time
– Departure Time
– Additional contact
information stored for each
responder

Email Alert Notification through
Response Planning including:
– Choosing email groups
– Entering sensitive
information
– Free-text changes
Design Review
May 8-9, 2007
88
EM: Requirements – con’t

Matching vehicle tag search

Road Rangers can respond to
events multiple times (multiple
responder entries)

Set multiple activities for each
response

For each Road Ranger stop the
following times are recorded:
– Dispatch Time
– Arrival Time
– Departure Time
Design Review
May 8-9, 2007
89
EM: Requirements – con’t

Road Ranger Report includes
information regarding vehicle
type, incident discovery and
the cause for stop
Design Review
May 8-9, 2007
90
EM: Requirements – con’t

List of Road Ranger services is
configurable through the Admin
Editor application

Save and calculate the
Response Time for each
confirmed incident

Recording agency notification
times

Store law enforcement arrival
times
Design Review
May 8-9, 2007
91
EM: Requirements – con’t
Definitions:

Response Time = Arrival Time Initial Notification

Lane Clearance Time = time
when all lanes are cleared

Incident Clearance Time =
Arrival Time – Lane Clearance
Time

Initial Incident Notification Time
= time of initial notification of
law enforcement
Design Review
May 8-9, 2007
92
EM: Requirements – con’t

Event Manager List allows for
filtering of events by ID

Supported Lane Types include:
Mainline, HOV, On, Off, On/Off
Ramps, Shoulder, C/D and a
new type: High Occupancy Toll
(HOT)
Design Review
May 8-9, 2007
93
EM: Requirements – con’t

Track queue lengths based on
the Event Location & Event
Congestion information

Road Ranger activities can be
modified using the Admin
Editor and include: Tire, Fuel,
Mechanical, Jump Start, etc.

Supports the addition of
contact information for each
agency
Design Review
May 8-9, 2007
94
EM: Requirements – con’t

Event confirmation time
recorded

Support for various event
types, including Amber Alert

Support for the addition of
lanes anywhere within the
existing lane configuration
(based on lane index)

Support for lane re-ordering
using point-and-click methods
Design Review
May 8-9, 2007
95
EM: Requirements – con’t

Response Plan request and
activation content and times
recorded

All event data changes shall be
logged in the database for
traceability, including new
value, previous value, change
date/time and relevant user.

Support for the addition,
deletion and editing of vehicle
response records and
associated activities
Design Review
May 8-9, 2007
96
EM: Derived Requirements

Event Viewer permission via
Event Management permission
user configuration

Event Management GUI /
Subsystem shall provide
Response Plan Generation
Subsystem with all required
event information

Event Management GUI shall
allow for the entry of ‘sensitive’
information for dissemination
to relevant email subscriber
groups
Design Review
May 8-9, 2007
97
EM Quesitons?
Break for the day…
Design Review
May 8-9, 2007
98
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
99
EM GUIs

The “look and feel” of Release 3.0 EM GUIs will be
based on the look and feel of Release 2.2 EM GUIs

This look and feel is “different” than the rest of
SunGuideSM

The development team wants to confirm this
approach with FDOT:
– Yes?
Design Review
May 8-9, 2007
100
EM: GUI Mockups
Event Manager (Event List) dialog


The Event Manager dialog
is used to display all
active events in the list.
The events are grouped
into 4 categories:
– Active Events with
Travel Lane Blockage
– Active Events without
Travel Lane Blockage
– Unconfirmed Events
– Unresolved Events
Design Review
May 8-9, 2007
101
EM: GUI Mockups
Event Manager (Event List) dialog – con’t

The Event List can be sorted by any of the fields, ID, Event Name, Primary
Vehicle, Event Type, Blockage, Road Ranger Vehicle, Organization, and the
relevant dates

Events are sorted within the 4 major groups

The event manager also allows for filtering of the list using the textbox
and filter type dropdown list

Actions that can be performed on the event include:
– View Event Details – accessed by clicking on the event, opens the
Event Details dialog
– View Response Plan – clicking on the button will launch the Response
Plan dialog
– Nearest Camera – clicking on the button will launch the camera
control dialog with the nearest camera automatically selected
– Find on Map – clicking on the button will re-center the map on the
selected event.
– Audit Event – available only to users with appropriate permissions
Design Review
May 8-9, 2007
102
EM: GUI Mockups
Add New Event Dialog

The Add New Event dialog allows
the operator to add a new event to
the system. The dialog can be
accessed via the map or via the
event list dialog

Add Event with map - Event
Location information will be prepopulated by the system

Add Event without map – Event
Location information will not be
pre-populated by the system.

Event Location input is optional
Design Review
May 8-9, 2007
103
EM: GUI Mockups
Add New Event Dialog – con’t

Upon pressing the Create Event
Button, the event is created by the
system and the Event Details
dialog is opened with the new
event.

Cancelling the event does not
delete the event from the system,
but marks it as a False Alarm.
Design Review
May 8-9, 2007
104
EM: GUI Mockups
Event Details
Dialog
Design Review
May 8-9, 2007
105
EM: GUI Mockups
Event Details Dialog

The Event Details Dialog contains all the
information regarding the event including the
following sections:
– Administrative Details
– Impact on Roadways including Event Location,
Congestion, Lane Blockage
– Report & Dispatch including the ability to view
the status of Road Ranger vehicles and the
ability to dispatch, arrive, cancel, depart, set
status and set activities for the road ranger
vehicles.
– Event Details nearest CCTV cameras, vehicles
involved, injuries and weather conditions.
– Responder List
– Event History & Comments
Design Review
May 8-9, 2007
106
EM: GUI Mockups
Event Details Dialog – con’t

Take/Release Event Ownership – only events under
ownership are available for editing by the operator

Save Changes –saves the event object including
all subsections. The button is available in multiple
location for convenience, but each button
performs the same function.

Cancel Changes – closes the Event Details dialog
without saving changes to the database.

Save, Get Response – saves the event object
including all subsections and launches the
Suggested Response Plan dialog.

Find on Map - clicking on the button will re-center
the map on the selected event.

Generate Chronology Report
Design Review
May 8-9, 2007
107
EM: GUI Mockups:
Administrative Details Subsection

The administrative details subsection allows the user to view the timing
(added, status update) and status of the event as well as the ability to
quickly add contacts.

The contact list is hidden by default and can be expanded via the Contacts
link. The operator has the ability to add, modify and delete a contact from
the list using the grid
Design Review
May 8-9, 2007
108
EM: GUI Mockups:
Event Location and Congestion

The Event Location & Congestion subsection displays the current
location and the congestion
 Each section allows the operator to select the exact location using
the dropdown lists:
– County
– Roadway
– Direction
– Exit
– Relationship to Exit: Before, At, Beyond
– Mile marker and Distance from exit
Design Review
May 8-9, 2007
109
EM: GUI Mockups:
Lane Blockage

The Lane Blockage subsection allows the operator to identify
which lanes are blocked due to the event, as well as change the
lane configuration for the event. The lane configuration is initially
defined by the location of the event.

The graphical lane configuration allows the following actions:
– Change lane order by using the blue arrows
– Add Lane to specific lane index
– Remove Lane from specific lane index
Design Review
May 8-9, 2007
110
EM: GUI Mockups:
DMS Assignment


Used to resolve bindings between the messages
posted manually to a sign (without response
planning) and the Event
Operator selects the message from a list of
Design Review
May 8-9, 2007
111
EM: GUI Mockups
Report and Dispatching

The Report and Dispatching subsection allows the operator
to view the current status of all vehicles and dispatch,
arrive, set status and activity for vehicles specific to this
event

Record Road Ranger Errors

Specify the Organization, Agency and Notifier Contact
Design Review
May 8-9, 2007
112
EM: GUI Mockups
Report and Dispatching – con’t

The dispatching of Road Ranger vehicles is now performed inside the grid
with the following functionality:
– New vehicle can be dispatched by selecting a vehicle id and pressing
the dispatch button.
– Once a vehicle is dispatched it can be “Arrived” or Cancelled”.
– The operator can also select the Status or Activity the Road Ranger is
performing
– The operator can
“Depart” the vehicle
– All actions automatically
record the time of the
operation
Design Review
May 8-9, 2007
113
EM: GUI Mockups
Road Ranger Procedural Error

This Road Ranger Procedural Error Subsection allows the
operator to add, modify and delete errors and comments
directly in the list.
Design Review
May 8-9, 2007
114
EM: GUI Mockups
Event Details

The Event Details subsection displays information
regarding the event including the Event Type, Injuries,
Vehicles Involved, Weather Conditions and links to primary
and secondary events
Design Review
May 8-9, 2007
115
EM: GUI Mockups
Vehicles Involved

The Vehicles Involved section allows the operator to
add, remove and modify vehicles involved in the event
 Tag numbers are checked against other events and
matches are identified through the Vehicle Tag Alert Popup
Design Review
May 8-9, 2007
116
EM: GUI Mockups
Weather Conditions

The Weather Conditions area allows the operator to save
the weather conditions including pavement, precipitation,
wind, visibility and illumination conditions
Design Review
May 8-9, 2007
117
EM: GUI Mockups
Event Comments and History


The Event Comments and History subsection allows the
operator to add a new comment to the event and view the
event history
The history represents the chronology of the event through
time
Design Review
May 8-9, 2007
118
EM: GUI Mockups
Responder List

The Responder List allows the operator to
save the timing information for the
responders and notifiers in the list. The list
also allows the operator to save additional
information for each agency including the
contact name and phone number

The grid allows for 3 times, notification, on
scene and departed times to be stored for
each responder (FHP). Non-responders
allow for the capturing of the notification
time

All agencies can be classified as
Responders or Notifiers using the Admin
Editor
Design Review
May 8-9, 2007
119
EM: GUI Mockups
Suggest Response Plan

Recommended response plan is simply
“recommendations” presented to the operator
Design Review
May 8-9, 2007
120
EM: GUI Mockups
Suggest Response Plan

Ability to view suggested DMS, HAR messages

Ability to view suggested Email messages

Generate new suggestions based on DMS and HAR
radius

Set as Response Plan
Design Review
May 8-9, 2007
121
EM: GUI Mockups
Activate Response Plan

Allows the plan to “activated” (implemented, sent to MAS
for queuing)
Design Review
May 8-9, 2007
122
EM: GUI Mockups
Activate Response Plan

Add, Edit & Remove DMS, HAR and Email Messages

Add one of the pre-defined plans
Design Review
May 8-9, 2007
123
EM
EM Questions?
Design Review
May 8-9, 2007
124
Response Plan Generation

“Old” Incident Management subsystem is migrating to a
“Response Plan Generator” (i.e. all incident/event management
will be combined in the EM subsystem)

Generate response plans
– Messages generated as specified by:
• Message templates
• Abbreviations
• Device linking information
• Event parameters (location, severity, etc.)
Suggest applicable email alert messages when generating a
response plan
Recommend predefined response plans as appropriate
Manage message and device templates
– Add, modify, and delete message templates
Manage device templates
Manage predefined plans
– Add, modify, and delete predefined plans





Design Review
May 8-9, 2007
125
Response Plan Generator
Creating Recommended Response Plans

Releases of SunGuideSM prior
to 2.2.0 used only an “Incident
Management” subsystem (this
handled incidents and
response plans)

With the new approach to EM
(introduced in R2.2.0) the old IM
became obsolete (i.e. the IM
GUIs will no longer exist, only
EM GUIs)

The “Response Plan” creation
component of the legacy IM is
being retained for Release 3.0
Design Review
May 8-9, 2007
126
Response Plan Generator:
Requirements

Recommended response plans
will be generated in the same
why as in Release 1.x and 2.x

Devices will be recommended
based on their physical
relationship to the location of
the event (using the device
linking file)

Existing “template” concept to
format messages will be
retained
Design Review
May 8-9, 2007
127
Response Plan Generator
Response Plan Questions?
Design Review
May 8-9, 2007
128
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
129
Reporting Subsystem

Migrating Release 2.2.0 to “SunGuideSM Compliant” based on the
requirements provided (i.e. provide all applicable R 2.2.0 reports)

Generate reports for the following:
– Performance measures
– Road Ranger activities and status
– SunGuideSM software availability:
• Central computer system
• Information portal
• Video Wall
– Device availability
– Camera usage
– Incident management monthly report
– Traveler information monthly report
– Traffic flow monthly report
– Vehicle and position report
– Beat/Route coverage summary report
Design Review
May 8-9, 2007
130
Reporting: Requirements

Reports can be filtered by any
of the Event properties

Save reports to PDF, Word,
Excel

Generation and Recalculation
of weekly, monthly, quarterly
and yearly Performance
Measures Reports
Design Review
May 8-9, 2007
131
Reporting: Requirements – con’t

Road Ranger data can be
viewed in Excel, Word and PDF
formats

Road Ranger data is in XML
format

Reports can be filtered using
Event properties

Reports can be generated and
saved in Excel, Word and PDF
formats
Design Review
May 8-9, 2007
132
Reporting: Requirements – con’t

Activity Summary Report
contains all information needed
to summarize all activities for
the provided date range

Vehicle Status Report will
include all stops for the Road
Ranger

Vehicle Status Report will be
able to be filtered by event
properties
Design Review
May 8-9, 2007
133
Reporting: Requirements – con’t

Camera Usage Report for
camera locking history

Equipment tracking including
CCTV, DMS, RWIS uptime and
downtime
Design Review
May 8-9, 2007
134
Reporting: Requirements – con’t

Traffic Flow Monthly Report will
include:
– Average Speed
– Average Volume
– Average Travel Time
– Average Density

SunGuide Software Availability
Report for tracking central
software reliability
Design Review
May 8-9, 2007
135
Reporting: Requirements – con’t

Traveler Information Monthly
Report
– # of website visits
– Most frequently visited
pages
– Referring web site
– # of DMS message posted
– DMS posting time
Design Review
May 8-9, 2007
136
Reporting: Requirements – con’t

Incident Management Monthly
Report
– # of incidents by county,
roadway, level and notifying
agency
– Incident detection method
– Incident durations
– # of secondary incidents
– Road Ranger dispatch and
response time periods
– Road Ranger activities
summary
– Road Ranger responses by
beat summary
Design Review
May 8-9, 2007
137
Reporting: Requirements – con’t

Vehicle Position and Status
Report for tracking vehicle
history

Minimum identification
criteria: truck number, beat,
driver, radio/telephone
number, position, speed,
track and status
Design Review
May 8-9, 2007
138
Reporting: Requirements – con’t

Reports and report formats will
be selectable via dropdown list

Report format will be formatted
to fit traditional display sizes
Design Review
May 8-9, 2007
139
Reporting: Derived Requirements

Access to ‘Data Editing’ and
‘Performance Measures’
functionality shall be
restricted to users with data
editing permissions
Design Review
May 8-9, 2007
140
Reporting: Derived Requirements

Event List Report

Beat/Route Coverage
Summary Report

DMS Message Report

Ability to
Calculate/Recalculate the
Performance Measures (PM)
reports
Design Review
May 8-9, 2007
141
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
142
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
143
Reporting: GUI Mockups
Standard Reports

The Standards Reports dialog allows the user with
appropriate permissions to run any of the reports
summarized in the Report Requirements Document. The
GUI uses a common set of filters for the report which
include:
– Event Range and Date/Time Properties
– Event Properties
– Location Properties
– Road Ranger/Vehicle Properties

The reports have been grouped into sections and are
selectable via the report dropdown lists. Each report is
available in PDF, Word and Excel formats.
Design Review
May 8-9, 2007
144
Reporting:
GUI Mockups
Standard Reports
Design Review
May 8-9, 2007
145
Reporting: GUI Mockups
Performance Measures (PM) Calculation and
Report Generation

The Performance Measures Calculation and Report
Generation allows the user to:
– View the Performance Measures calculation for a
specific Week, Month, Quarter or Year
– Recalculate the Performance Measures for a specific
Week, Month, Quarter or Year
– Generate the Performance Measures Report for a
specific Week, Month, Quarter or Year
Design Review
May 8-9, 2007
146
Report Examples
Design Review
May 8-9, 2007
147
Audit: GUI Mockups
Audit

The Audit GUIs allow the manager with the appropriate
permissions to modify the contents of the event
information. The editable sections include:
– Responder Notification Timeline
– Notifying Agency & Notifying Contact
– Event Location
– Event Congestion
– Event Status
– Lane Blockage
– Vehicle Identification
– Road Ranger Status
– Road Ranger Dispatch
– DMS Message or Time
Design Review
May 8-9, 2007
148
Audit: GUI Mockups
Responder Notification Timeline Audit

Ability to Add, Modify and Delete the responder
notification timeline
Design Review
May 8-9, 2007
149
Audit: GUI Mockups
Notifying Agency and Notifying Contact Audit

Ability to modify the Notifying Agency and Notifying
contact for the Event
Design Review
May 8-9, 2007
150
Audit: GUI Mockups
Event Location Audit

Ability to Add, Modify and Delete Event Location information
and timing
Design Review
May 8-9, 2007
151
Audit: GUI Mockups
Event Congestion Audit

Ability to Add, Modify and Delete Event Congestion
information and timing
Design Review
May 8-9, 2007
152
Audit: GUI Mockups
Event Status Audit

Ability to Add, Modify and Delete Event Status
information and timing
Design Review
May 8-9, 2007
153
Audit: GUI Mockups
Lane Blockage Audit

Ability to Add, Modify and Delete Event Blockage
information and timing
Design Review
May 8-9, 2007
154
Audit: GUI Mockups
Vehicle Identification Audit

Ability to Add, Modify and Delete Vehicle descriptions
for the event
Design Review
May 8-9, 2007
155
Audit: GUI Mockups
Road Ranger Status Audit

Ability to Add, Modify and Delete the Road Ranger Vehicle
status and timing
Design Review
May 8-9, 2007
156
Audit: GUI Mockups
Road Ranger Dispatch Audit


Ability to dispatch, arrive, cancel and depart
vehicles for an event
Ability to modify the timing
Design Review
May 8-9, 2007
157
Audit: GUI Mockups
DMS Message or Time

Ability to Add, Modify and Delete DMS assignment
Design Review
May 8-9, 2007
158
Reporting & Audit
Questions?
Design Review
May 8-9, 2007
159
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
160
Agenda
May 8, 2007
8:30 – 8:40
Introductions and Opening Remarks
Tillander
8:40 – 8:50
High Level Overview – meeting objectives
Heller
8:50 – 9:15
Configuration Editor
Clauss
9:15 – 9:45
Event Viewer
Clauss
9:45 – 10:00
Incident Detection
Clauss
10:00 – 10:20
Break
10:20 – 10:50
Incident Detection (continued)
Clauss
10:50 – 11:45
AVL
Moczygemba
11:45 – 1:15
Lunch
1:15 –3:00
Road Ranger
3:00 – 3:20
Break
3:20 – 5:00
Event Management
Claus/Moczygemba
Barbosa
May 9, 2007
8:30 – 10:00
Event Management – continued
10:00 – 10:20
Break
10:20 – 11:45
Reporting
11:45 – 1:15
Lunch
1:15 – 3:15
Reporting – continued
3:15 – 3:30
Break
3:30 – 4:00
Open Discussion / Action Item Summary
Design Review
Barbosa
Barbosa
Barbosa
May 8-9, 2007
All
161
Obsolete
requirements
(R1.x or R2.x) that
have been
“overcome” by
newer
requirements
Design Review
May 8-9, 2007
162
Discussion?
Design Review
May 8-9, 2007
163