sunguide sm software development project release 3.0 design review may 8-9, 2007

SunGuideSunGuideSMSM Software Development Project Software Development Project

Release 3.0 Design ReviewRelease 3.0 Design ReviewMay 8-9, 2007May 8-9, 2007

May 8-9, 2007Design Review 2

AgendaAgendaMay 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 Claus/Moczygemba

3:00 – 3:20 Break

3:20 – 5:00 Event Management Barbosa

May 9, 2007

8:30 – 10:00 Event Management – continued Barbosa

10:00 – 10:20 Break

10:20 – 11:45 Reporting Barbosa

11:45 – 1:15 Lunch

1:15 – 3:15 Reporting – continued Barbosa

3:15 – 3:30 Break

3:30 – 4:00 Open Discussion / Action Item Summary All


Introductions








10:00 – 10:20 Break



11:45 – 1:15 Lunch


3:00 – 3:20 Break


May 9, 2007


10:00 – 10:20 Break


11:45 – 1:15 Lunch


3:15 – 3:30 Break



Meeting ObjectivesMeeting 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


Release 3.0 Development Release 3.0 Development ActivitiesActivities


SRS DiscussionSRS 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)








10:00 – 10:20 Break



11:45 – 1:15 Lunch


3:00 – 3:20 Break


May 9, 2007


10:00 – 10:20 Break


11:45 – 1:15 Lunch


3:15 – 3:30 Break



Configuration EditorConfiguration 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)


Configuration Editor: Configuration Editor: RequirementsRequirements

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


Config Editor: GUI MockupsConfig 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.


Config Editor: GUI Mockups – Config Editor: GUI Mockups – con’tcon’t

Selecting a configuration file to open

Clicking “Open” after selecting the file will load the configuration file into the editor



Users can drill down into the file to select options to change



Parameters may be modified by editing the value in the panel on the right side



After modifications are made, changes must be saved using the File menu



Creation wizards can be used to help make a large change to the file safely at an appropriate location.


Configuration Editor Questions?








10:00 – 10:20 Break



11:45 – 1:15 Lunch


3:00 – 3:20 Break


May 9, 2007


10:00 – 10:20 Break


11:45 – 1:15 Lunch


3:15 – 3:30 Break



Event Viewer (EV)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


Event Viewer: RequirementsEvent 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


Event Viewer: Requirements – Event Viewer: Requirements – con’tcon’t

Allow access restriction based on IP address

Support use of SSL security via Microsoft IIS



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



Associated events will contain links between event details pages


Event Viewer: Derived Event Viewer: Derived RequirementsRequirements

Accessible via SunGuide website

Site will not be accessible to IP addresses outside the allowed range specified within IIS


Event Viewer: GUI MockupsEvent Viewer: GUI MockupsLogin ScreenLogin 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


Event Viewer: GUI MockupsEvent Viewer: GUI MockupsSummary and Detail ScreensSummary 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


Event Viewer Questions?








10:00 – 10:20 Break



11:45 – 1:15 Lunch


3:00 – 3:20 Break


May 9, 2007


10:00 – 10:20 Break


11:45 – 1:15 Lunch


3:15 – 3:30 Break



Incident Detection: Design Incident Detection: Design OverviewOverview

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


Incident Detection: Design Incident Detection: Design Overview – con’tOverview – 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


Incident Detection: RequirementsIncident 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








10:00 – 10:20 Break



11:45 – 1:15 Lunch


3:00 – 3:20 Break


May 9, 2007


10:00 – 10:20 Break


11:45 – 1:15 Lunch


3:15 – 3:30 Break



Incident DetectionIncident DetectionArchitectural OverviewArchitectural 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


Incident DetectionIncident DetectionAdministrative Editor (for “devices”)Administrative Editor (for “devices”)

Device location

Device identifier information

Associate closest SunGuideSM CCTV


Incident DetectionIncident DetectionOperator InterfaceOperator Interface

Alarm dialog will be presented to users subscribed via Data Bus

Location will be provided


Incident DetectionIncident DetectionOverview of Data Flow – client to driversOverview of Data Flow – client to drivers


Incident DetectionIncident DetectionData Flow – Subsystem to DriverData Flow – Subsystem to Driver


Incident Detection Questions?








10:00 – 10:20 Break



11:45 – 1:15 Lunch


3:00 – 3:20 Break


May 9, 2007


10:00 – 10:20 Break


11:45 – 1:15 Lunch


3:15 – 3:30 Break



AVL: Design OverviewAVL: 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


AVL: Design Overview – cont.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


AVL: RequirementsAVL: 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


AVL: Requirements – cont.AVL: Requirements – cont.

An External Sources driver will be developed to retrieve XML-formatted 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



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



External source data will be re-formatted 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



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



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


AVLAVLArchitectural OverviewArchitectural 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


AVL Administrative EditorAVL Administrative EditorAdministrative Editor – Add/Edit VehiclesAdministrative Editor – Add/Edit Vehicles


AVL Administrative EditorAVL Administrative EditorAdd and Edit AVL External Data Sources Add and Edit AVL External Data Sources


AVL GUIAVL GUI

AVL Status Summary DialogAVL Status Summary Dialog

AVL Status Summary TooltipAVL Status Summary Tooltip


AVL GUIAVL GUIAVL Detailed Status Dialog AVL Detailed Status Dialog


AVL GUIAVL GUIAVL Vehicle List DialogAVL Vehicle List Dialog


AVLAVLOperator Map with AVL Status


AVLAVLGeo-Fence EditorGeo-Fence Editor


AVLAVLData Flow – Data Flow – Subsystem Subsystem to Driverto Driver


AVL Questions?








10:00 – 10:20 Break



11:45 – 1:15 Lunch


3:00 – 3:20 Break


May 9, 2007


10:00 – 10:20 Break


11:45 – 1:15 Lunch


3:15 – 3:30 Break



Road RangerRoad 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


Road Ranger: continuedRoad 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


Road Ranger: RequirementsRoad 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.


Road Ranger: Requirements – Road Ranger: Requirements – con’tcon’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


Road Ranger: Requirements – Road Ranger: Requirements – con’tcon’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


Road RangerRoad RangerArchitectural OverviewArchitectural 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


Road RangerRoad RangerAdministrative EditorAdministrative Editor

Admin Editor will allow adding / modifying / deleting of Road Ranger Operators, Trucks, and Beats

Maximum stop length: should be configurable per truck, system-wide, etc?


Road RangerRoad RangerOperator Map GUIsOperator Map GUIs

Status window will allow selection of one or more RR trucks

Truck Manager window will allow operators to modify trucks


Road RangerRoad RangerData Flow –Data Flow –Between Subsystem Between Subsystem and Driversand Drivers


Road Ranger Concept of Operations Road Ranger Concept of Operations (based on requirements)(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 / non-billable activities, etc.


Is this ConOps consistent with District needs?


RR OptionsRR 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.


Road Ranger Questions?








10:00 – 10:20 Break



11:45 – 1:15 Lunch


3:00 – 3:20 Break


May 9, 2007


10:00 – 10:20 Break


11:45 – 1:15 Lunch


3:15 – 3:30 Break



Event Management (EM)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”


EM: continuedEM: 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


Responder AuditResponder 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


EM: RequirementsEM: 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


EM: Requirements – con’tEM: 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



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



Identification of work zones

Data Archiving

Diversion routes



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.



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



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



Event creation time recorded

Event Status includes:– Unresolved– Closed– False Alarm

Lane Blockage time recorded

Record vehicle descriptions including make, model, color, state, tag



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



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



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



Road Ranger Report includes information regarding vehicle type, incident discovery and the cause for stop



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



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



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)



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



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



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


EM: Derived RequirementsEM: 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


EM Quesitons?Break for the day…








10:00 – 10:20 Break



11:45 – 1:15 Lunch


3:00 – 3:20 Break


May 9, 2007


10:00 – 10:20 Break


11:45 – 1:15 Lunch


3:15 – 3:30 Break



EM GUIsEM 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?


EM: GUI MockupsEM: GUI MockupsEvent Manager (Event List) dialogEvent 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


EM: GUI MockupsEM: GUI MockupsEvent Manager (Event List) dialog – con’tEvent 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


EM: GUI MockupsEM: GUI MockupsAdd New Event DialogAdd 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 pre-populated by the system

Add Event without map – Event Location information will not be pre-populated by the system.

Event Location input is optional


EM: GUI MockupsEM: GUI MockupsAdd New Event Dialog – con’tAdd 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.


Event Details Event Details DialogDialog

EM: GUI MockupsEM: GUI Mockups


EM: GUI MockupsEM: GUI MockupsEvent Details DialogEvent 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


EM: GUI MockupsEM: GUI MockupsEvent Details Dialog – con’tEvent 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


EM: GUI Mockups:EM: GUI Mockups:Administrative Details SubsectionAdministrative 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


EM: GUI Mockups:EM: GUI Mockups:Event Location and CongestionEvent 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


EM: GUI Mockups:EM: GUI Mockups:Lane BlockageLane 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


EM: GUI Mockups:EM: GUI Mockups:DMS AssignmentDMS 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


EM: GUI MockupsEM: GUI Mockups Report and DispatchingReport 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


EM: GUI MockupsEM: GUI Mockups Report and Dispatching – con’tReport 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


EM: GUI MockupsEM: GUI MockupsRoad Ranger Procedural ErrorRoad Ranger Procedural Error

This Road Ranger Procedural Error Subsection allows the operator to add, modify and delete errors and comments directly in the list.


EM: GUI MockupsEM: GUI MockupsEvent DetailsEvent 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


EM: GUI MockupsEM: GUI MockupsVehicles InvolvedVehicles 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 Pop-up


EM: GUI MockupsEM: GUI MockupsWeather ConditionsWeather Conditions

The Weather Conditions area allows the operator to save the weather conditions including pavement, precipitation, wind, visibility and illumination conditions


EM: GUI MockupsEM: GUI MockupsEvent Comments and HistoryEvent 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


EM: GUI MockupsEM: GUI MockupsResponder ListResponder 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


EM: GUI MockupsEM: GUI MockupsSuggest Response PlanSuggest Response Plan

Recommended response plan is simply “recommendations” presented to the operator


EM: GUI MockupsEM: GUI MockupsSuggest Response PlanSuggest 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


EM: GUI MockupsEM: GUI MockupsActivate Response PlanActivate Response Plan

Allows the plan to “activated” (implemented, sent to MAS for queuing)


EM: GUI MockupsEM: GUI MockupsActivate Response PlanActivate Response Plan

Add, Edit & Remove DMS, HAR and Email Messages

Add one of the pre-defined plans


EMEM

EM Questions?


Response Plan GenerationResponse 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


Response Plan GeneratorResponse Plan GeneratorCreating Recommended Response PlansCreating 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


Response Plan Generator: Response Plan Generator: RequirementsRequirements

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


Response Plan GeneratorResponse Plan Generator

Response Plan Questions?








10:00 – 10:20 Break



11:45 – 1:15 Lunch


3:00 – 3:20 Break


May 9, 2007


10:00 – 10:20 Break


11:45 – 1:15 Lunch


3:15 – 3:30 Break



Reporting SubsystemReporting 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


Reporting: RequirementsReporting: 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


Reporting: Requirements – con’tReporting: 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



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



Camera Usage Report for camera locking history

Equipment tracking including CCTV, DMS, RWIS uptime and downtime



Traffic Flow Monthly Report will include:– Average Speed– Average Volume– Average Travel Time– Average Density

SunGuide Software Availability Report for tracking central software reliability



Traveler Information Monthly Report– # of website visits– Most frequently visited

pages– Referring web site– # of DMS message posted– DMS posting time



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



Vehicle Position and Status Report for tracking vehicle history

Minimum identification criteria: truck number, beat, driver, radio/telephone number, position, speed, track and status



Reports and report formats will be selectable via dropdown list

Report format will be formatted to fit traditional display sizes


Reporting: Derived RequirementsReporting: Derived Requirements

Access to ‘Data Editing’ and ‘Performance Measures’ functionality shall be restricted to users with data editing permissions


Reporting: Derived RequirementsReporting: Derived Requirements

Event List Report

Beat/Route Coverage Summary Report

DMS Message Report

Ability to Calculate/Recalculate the Performance Measures (PM) reports








10:00 – 10:20 Break



11:45 – 1:15 Lunch


3:00 – 3:20 Break


May 9, 2007


10:00 – 10:20 Break


11:45 – 1:15 Lunch


3:15 – 3:30 Break



Reporting: GUI MockupsReporting: GUI MockupsStandard ReportsStandard 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.


Reporting: Reporting: GUI MockupsGUI MockupsStandard ReportsStandard Reports


Reporting: GUI MockupsReporting: GUI MockupsPerformance Measures (PM) Calculation and Performance Measures (PM) Calculation and Report GenerationReport 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


Report ExamplesReport Examples


Audit: GUI MockupsAudit: GUI MockupsAuditAudit

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


Audit: GUI MockupsAudit: GUI MockupsResponder Notification Timeline AuditResponder Notification Timeline Audit

Ability to Add, Modify and Delete the responder notification timeline


Audit: GUI MockupsAudit: GUI MockupsNotifying Agency and Notifying Contact AuditNotifying Agency and Notifying Contact Audit

Ability to modify the Notifying Agency and Notifying contact for the Event


Audit: GUI MockupsAudit: GUI MockupsEvent Location AuditEvent Location Audit

Ability to Add, Modify and Delete Event Location information and timing


Audit: GUI MockupsAudit: GUI MockupsEvent Congestion AuditEvent Congestion Audit

Ability to Add, Modify and Delete Event Congestion information and timing


Audit: GUI MockupsAudit: GUI MockupsEvent Status AuditEvent Status Audit

Ability to Add, Modify and Delete Event Status information and timing


Audit: GUI MockupsAudit: GUI MockupsLane Blockage AuditLane Blockage Audit

Ability to Add, Modify and Delete Event Blockage information and timing


Audit: GUI MockupsAudit: GUI MockupsVehicle Identification AuditVehicle Identification Audit

Ability to Add, Modify and Delete Vehicle descriptions for the event


Audit: GUI MockupsAudit: GUI MockupsRoad Ranger Status AuditRoad Ranger Status Audit

Ability to Add, Modify and Delete the Road Ranger Vehicle status and timing


Audit: GUI MockupsAudit: GUI MockupsRoad Ranger Dispatch AuditRoad Ranger Dispatch Audit

Ability to dispatch, arrive, cancel and depart vehicles for an event

Ability to modify the timing


Audit: GUI MockupsAudit: GUI MockupsDMS Message or TimeDMS Message or Time

Ability to Add, Modify and Delete DMS assignment


Reporting & Audit Questions?








10:00 – 10:20 Break



11:45 – 1:15 Lunch


3:00 – 3:20 Break


May 9, 2007


10:00 – 10:20 Break


11:45 – 1:15 Lunch


3:15 – 3:30 Break



Obsolete Obsolete requirements requirements (R1.x or R2.x) (R1.x or R2.x) that have been that have been “overcome” by “overcome” by newer newer requirementsrequirements


Discussion?

sunguide sm software development project release 3.0 design review may 8-9, 2007

Documents

xml file

master configuration

gui mockupsthe file

design reviewmay

gui mockups contselecting

gui mockups contusers

gui mockups contparameters

requirements contsections