240 likes | 443 Views
SunGuide SM Software Development Project End of the Year ITS Working Group Meeting December 7, 2005. Project Status. Release-Oriented Development Approach. Development Process: FDOT provided SwRI with system requirements SwRI provided FDOT software requirements (FDOT provided comments)
E N D
SunGuideSM Software Development ProjectEnd of the Year ITS Working Group MeetingDecember 7, 2005
Project Status SunGuide Update
Release-Oriented Development Approach SunGuide Update
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”) Development Status SunGuide Update
Release 2.0 Unique Functionality SunGuide Update
Center-to-Center (C2C):Providing “connectivity” across centers SunGuide Update
Templates:Used 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. SunGuide Update
Templates: Travel TimesUsed for Response Plans and Travel Times SunGuide Update
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 SunGuide Update
Project 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) SunGuide Update
Deployments June 2005: Ft. Lauderdale November 2005: Miami October 2005: Jacksonville SunGuide Update
Project Web Site:Everything you wanted to know about the project! http://sunguide.datasys.swri.edu SunGuide Update
Enhancements SunGuide Update
SunGuideSM 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 SunGuide Update
IM 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 SunGuide Update
Specifying Other District’s Devices (in the DMS Link Editor) • Must establish “DMS relationships” for creating response plans: • Indicate “downstream” devices • SunGuide access C2C data for detailed information SunGuide Update
IM C2C: Response Plan Generation • 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) SunGuide Update
IM 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): SunGuide Update
Proportional 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 SunGuide Update
Proportional Fonts:Requirements • 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. SunGuide Update
Proportional Fonts:Implementation • 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 SunGuide Update
Road Ranger Subsystem Concept • Objective: • Collect Road Ranger data and store in common format • Facilitate the local and state reporting process SunGuide Update
Road 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 SunGuide Update
Questions? SunGuide Update