Project Status

SunGuideSunGuideSMSM Software Development Project Software Development Project

End of the Year ITS Working Group MeetingEnd of the Year ITS Working Group MeetingDecember 7, 2005December 7, 2005

December 7, 2005SunGuide Update 2

Project Status


Release-Oriented Release-Oriented Development ApproachDevelopment Approach


Development StatusDevelopment Status

Development Process:– FDOT provided SwRI with system requirements– SwRI provided FDOT software requirements (FDOT provided

comments)– SwRI developed against the software requirements– Test procedures developed against the requirements (FDOT

provided comments)– Factory Acceptance Testing based on test procedures– FDOT plans an independent IV&V of the system

Releases:– Release 1.0: January 2005– Release 1.1: June 2005– Release 2: November 2005

Development efforts are complete (in a “maintenance phase”)


Release 2.0 Unique Functionality


Center-to-Center (C2C):Center-to-Center (C2C):Providing “connectivity” across centersProviding “connectivity” across centers


Templates:Templates:Used for Response Plans and Travel TimesUsed for Response Plans and Travel Times

IM Response plans and Travel times can be generated with a variety of message formats (specific to a Center)

These are “template” driven and configurable by the administrator.


Templates: Travel TimesTemplates: Travel TimesUsed for Response Plans and Travel TimesUsed for Response Plans and Travel Times


Cost Status (as of 12/1/05)Cost Status (as of 12/1/05)

Development Activities:– Release 1:

• Allocated: $4,335,554• Spent: $4,327,043

– Release 2:• Allocated: $2,732,303• Spent: $2,449,625

– UNDERUN: $291,189

Deployments:– Allocated: $282,303– Spent: $115,419

Support - on-site support and FDOT directed support (thru 6/2008):– Allocated: $548,219– Spent: $224,518


Project FactoidProject Factoid

Development activities (25 months):– Began October 7, 2003– Ended November 3, 2005– Initial project schedule requested by FDOT: 25 months– Staff time: 48,577 hours

Papers/Presentation (outside of FDOT): – International: 4 papers/presentations– National: 2 papers/presentations– Invited presentations: 2 (TRB and California)

Lines of code: 925K SLOC (generic framework saved SLOCs)


DeploymentsDeployments

June 2005: Ft. Lauderdale

November 2005:Miami

October 2005:Jacksonville


Project Web Site:Project Web Site:Everything you wanted to know about the project!Everything you wanted to know about the project!

http://sunguide.datasys.swri.edu


Enhancements


SunGuideSunGuideSMSM Enhancements Enhancements

The following will be discussed on the following slides

IM C2C:– Amount: $121,275 (code and documentation)– Authorized: November 2005

Proportional Font support:– Estimated amount: $174,631 (code and documentation)– Authorized: TBD

Road Ranger subsystem:– Estimated amount: $122,916 (code and documentation)– Authorized: TBD


IM C2C RequirementsIM C2C Requirements

Requirements:– C2C #1: The CCTV switching function shall support the

switching of C2C video sources to a Barco Video Wall.

– C2C #2: SunGuide shall provide a mechanism to include DMS devices from available from the C2C interface when generating a IM response plan.

– C2C #3: When SunGuide receives a DMS request from another center a configurable parameter shall be provided as to whether or not an operator has to approve the posting of the DMS request to the MAS subsystem.

– C2C #4: Device requests received via the C2C interface shall be validated


Specifying Other District’s Specifying Other District’s Devices (in the DMS Link Editor)Devices (in the DMS Link Editor)

Must establish “DMS relationships” for creating response plans:– Indicate “downstream” devices

SunGuide access C2C data for detailed information


IM C2C: Response Plan IM C2C: Response Plan GenerationGeneration

When response plans are created, other center’s devices (DMS and HAR) will be considered when:– DMS relationships have been

established in the Link Editor– Devices are available via C2C (i.e.

C2C is running)– Devices are within the “search

distance”– Other center’s devices will be in the

recommended response plan Operator still manually “approves”

response plan for execution (C2C devices can be manually added)


IM C2C: Manual ApprovalIM C2C: Manual Approval

Prompt option for remote centers:– Startup up option that will require C2C DMS/HAR

requests (received from other centers) to be “manually” approved

– Sample screen (design not finalized):


Proportional FontsProportional Fonts

Issue:

– Support for proportional fonts in SunGuide

Challenges:

– Different vendors implement variety of fonts

– SunGuide must support multiple DMS protocols

Solution:

– Proportional font usage is an OPTION

– Allow fonts to be defined with the SunGuide editor:

• Default width will be established for EACH font

• Administrator enters “unique” characters

– Each DMS device can have a DIFFERENT font

– DMS controller must have a “default” font established that matches the configuration in the Administrative editor


Proportional Fonts:Proportional Fonts:RequirementsRequirements

FEAT9.11: SunGuide shall allow a user to define a font using the following characteristics: Name of font, character height in pixels, default character width in pixels, and width in pixels for any characters whose width differs from the default.

FEAT9.12: SunGuide shall require that a font be assigned to each DMS device. Note: The DMS hardware must be configured to have the assigned font as the default font.

FEAT5.3.33: The incident management function shall use each DMS' font characteristics to determine response plan messages.

FEAT9.13: DMS shall use each device's font characteristics to determine whether a message can be displayed.


Proportional Fonts:Proportional Fonts:ImplementationImplementation

GUI:– Characters will be displayed in a fixed width font (HTML

limitations)– Correct number of characters per line will be displayed

IM:– Will use the existing IM template concept– Will “check size” after each abbreviation is applied– Will minimize the number of abbreviations applied

DMS Subsystem and driver:– Will deliver the previously formatted message to the

device– Default font must be set– Default font attributes must match Administrative editor


Road Ranger Subsystem ConceptRoad Ranger Subsystem Concept

Objective:– Collect Road Ranger data and store in common format– Facilitate the local and state reporting process


Road Ranger RequirementsRoad Ranger Requirements

Requirements derived from “Road Ranger Procedure Draft Version 6”, Traffic Operations

Driven by statewide data collection requirements

Does not address data collection mechanism

Interface is at computer-to-computer level


Questions?

Documents

Project Status