sunguide-conops-1.0sunguidesoftware.com/sunguidesoftware... · sunguide-conops-1.0.0 prepared for:...

56
SunGuide SM : Concept of Operations SunGuide-ConOps-1.0.0 Prepared for: Florida Department of Transportation Traffic Engineering and Operations Office 605 Suwannee Street, M.S. 90 Tallahassee, Florida 32399-0450 (850) 410-5600 January 3, 2005

Upload: lykiet

Post on 19-Sep-2018

224 views

Category:

Documents


0 download

TRANSCRIPT

SunGuideSM: Concept of Operations SunGuide-ConOps-1.0.0

Prepared for:

Florida Department of Transportation Traffic Engineering and Operations Office 605 Suwannee Street, M.S. 90 Tallahassee, Florida 32399-0450 (850) 410-5600

January 3, 2005

Concept of Operations

SunGuide-ConOps-1.0.0 i

Document Control Panel

File Name: SunGuide-ConOps-1.0.0.doc File Location: SunGuide CM Repository CDRL: 2-10.2

Name Initial Date

Steve Dellenback, SwRI SWD 3/03/04 Created By: Susan Crumrine, SwRI SBC 3/03/04 Robert Heller, SwRI RWH 3/03/04 Susan Crumrine, SwRI SBC 4/21/04 Steve Novosad, SwRI SEN 8/12/04 Steve Novosad, SwRI SEN 10/27/04 Steve Novosad, SwRI SEN 1/03/05

Reviewed By:

Tammy Duncan, SwRI TD 8/12/04 Steve Dellenback, SwRI SWD 8/12/04 Robert Heller, SwRI RWH 8/12/04 Steve Dellenback SwRI SWD 10/26/04

Modified By:

Steve Dellenback SwRI SWD 12/31/04 Completed By:

Concept of Operations

SunGuide-ConOps-1.0.0 ii

Table of Contents Page

List of Acronyms.......................................................................................................... iv Revision History........................................................................................................... vi

1. Scope.................................................................................................. 1 1.1 Document Identification .......................................................................... 1 1.2 Document Overview ................................................................................ 1 1.3 System Overview ..................................................................................... 1 1.4 Related Documents ................................................................................. 2 1.5 Contacts ................................................................................................... 3

2. Current State of the Practice ............................................................ 4 2.1 Background.............................................................................................. 4 2.2 SunGuideSM Software Initiative............................................................... 4

3. Justification for the SunGuideSM System ........................................ 5 3.1 Justification of Development.................................................................. 5 3.2 Description of Functionality ................................................................... 5 3.3 Priorities Among Functionality............................................................... 7 3.4 Functionality Considered but Not Included........................................... 8

4. Concept for the SunGuideSM System............................................. 10 4.1 Background............................................................................................ 10 4.2 Operational Policies and Constraints .................................................. 10 4.3 Operational Environment ...................................................................... 10

4.3.1 Network Connectivity...............................................................................13 4.3.2 ITS Device Connectivity ..........................................................................13 4.3.3 Video Transmission..................................................................................14 4.3.4 Security.....................................................................................................14 4.3.5 Center-to-Center .......................................................................................14 4.3.6 Configuration Management......................................................................15

4.4 Modes of Operation ............................................................................... 15 4.4.1 Regional Transportation Management Center..........................................16 4.4.2 Satellite Transportation Management Center ...........................................16 4.4.3 Virtual Transportation Management Center.............................................17 4.4.4 Portable Transportation Management Center...........................................17

4.5 User Classes .......................................................................................... 18 4.6 Support Environment ............................................................................ 18

5. Operational Scenarios .................................................................... 21 5.1 Operator.................................................................................................. 21

5.1.1 Normal Operations ...................................................................................21 5.1.2 Incident Management ...............................................................................23

Concept of Operations

SunGuide-ConOps-1.0.0 iii

5.1.3 Center-to-Center .......................................................................................30 5.1.4 Amber Alert..............................................................................................31 5.1.5 DMS Conflict Resolution .........................................................................31 5.1.6 Preplanned Road Closures........................................................................32 5.1.7 Create a New Video Tour.........................................................................34 5.1.8 Manual Incident Creation .........................................................................35 5.1.9 Subsystem Restart.....................................................................................36

5.2 Administrator ......................................................................................... 37 5.2.1 Creating a New User.................................................................................37 5.2.2 Adding a New Camera .............................................................................40 5.2.3 Adding New Servers.................................................................................42

5.3 Manager .................................................................................................. 44 5.3.1 Adding Contacts .......................................................................................44

6. Summary of Impacts ....................................................................... 46 6.1 Operational Impacts .............................................................................. 46 6.2 Organizational Impacts ......................................................................... 46 6.3 Impacts During Development ............................................................... 46

7. Analysis of the SunGuideSM System.............................................. 47 7.1 Summary of Improvements................................................................... 47 7.2 Disadvantages and Limitations ............................................................ 47 7.3 Alternatives and Tradeoffs Considered ............................................... 48

8. Notes................................................................................................. 49

Concept of Operations

SunGuide-ConOps-1.0.0 iv

List of Acronyms ATMS ........................Advanced Traffic Management System

BAFO.........................Best and Final Offer

C2C ............................Center-to-Center

CCTV.........................Closed Circuit Television

CONOPS....................Concept of Operations

DMS...........................Dynamic Message Sign

DOT ...........................Department of Transportation

ESS.............................Environment Sensor Station

FAX............................Facsimile

FDOT .........................Florida Department of Transportation

GIS .............................Geographic Information System

GPS ............................Global Positioning System

GUI ............................Graphical User Interface

HAR ...........................Highway Advisory Radio

HOV...........................High Occupancy Vehicle

IEEE...........................Institute Electrical and Electronic Engineers

IM...............................Incident Management

IMDBMS ...................Integrated Maintenance Database Management System

I/O ..............................Input Output

IP ................................Internet Protocol

ITN.............................Invitation to Negotiate

ITS..............................Intelligent Transportation Systems

LRMS.........................Location Referencing Message Specification

MMS ..........................Maintenance Management System

MODEM ....................Modulator Demodulator

NTCIP........................National Transportation Communications for ITS Protocol

OCD ...........................Operational Concept Document

Pixel ...........................Picture Element

PTMC.........................Portable Transportation Management Center

RM .............................Ramp Metering

Concept of Operations

SunGuide-ConOps-1.0.0 v

RTMC ........................Regional Transportation Management Center

RTMS.........................Remote Traffic Microwave Sensor

RWIS..........................Roadway Weather Information System

STMC.........................Satellite Transportation Management Center

SwRI ..........................Southwest Research Institute

TCP ............................Transport Control Protocol

TCP/IP........................Transmission Control Protocol/Internet Protocol

TMC...........................Transportation Management Center

TSS.............................Traffic Sensor Subsystem

TxDOT.......................Texas Department of Transportation

URL............................Uniform Resource Locator

VIVDS .......................Video Image Vehicle Detection System

VTMC........................Virtual Transportation Management Center

W3..............................World Wide Web

WYSIWYG................What You See Is What You Get

XML...........................Extensible Markup Language

VS ..............................Video Switch

Concept of Operations

SunGuide-ConOps-1.0.0 vi

REVISION HISTORY

Revision Date Changes

1.0.0-Draft March 3, 2004 Initial Release.

1.0.1-Draft August 12, 2004 Significant changes: • Formatted to comply with IEEE 1362-1998 • Added operational scenarios

1.0.2-Draft October 27, 2004 Updated graphics and text.

1.0.0 January 3, 2005 Updated graphics and added a device supported table.

Concept of Operations

SunGuide-ConOps-1.0.0 1

1. Scope

1.1 Document Identification This document will serve as the Concept of Operations (ConOps) for the SunGuideSM software. The content of this document is based on the IEEE Standard 1362-1998, IEEE Guide for Information Technology – System Definition – Concept of Operations (CONOPS) Document.

1.2 Document Overview This document will provide an operational concept of the Florida Statewide Software Library. The following is a listing of the sections that have been included in this document:

• Section 2: Referenced Documents • Section 3: Current State of the Practice • Section 4: Justification for the SunGuideSM System • Section 5: Concept for the SunGuideSM Software • Section 6: Operational Scenarios • Section 7: Summary of Impacts • Section 8: Analysis of the SunGuideSM System • Section 9: Notes

1.3 System Overview

The Florida Department of Transportation (FDOT) is conducting a program that is developing SunGuideSM software. The SunGuideSM software is a set of Intelligent Transportation System (ITS) software that allows the control of roadway devices as well as information exchange across a variety of transportation agencies. The goal of the SunGuideSM software is to have a common software base that can be deployed throughout the state of Florida. The SunGuideSM software development effort is based on ITS software available from both the states of Texas and Maryland; significant customization of the software is being performed as well as the development of new software modules. The following figure provides a graphical view of the software to be developed:

Concept of Operations

SunGuide-ConOps-1.0.0 2

Figure 1-1 - High-Level Architectural Concept

The SunGuideSM development effort spans approximately two years. After the development, the software will be deployed to a number of Districts and Expressway Authorities throughout Florida and support activities will be performed.

1.4 Related Documents

The following documents were used to develop this document:

SwRI Qualification Response: Response to the Invitation to Negotiate (ITN): Statewide Transportation Management Center Software Library System, Negotiation Number: ITN-DOT-02/03-9025-RR, SwRI Proposal No. 10-35924, dated: November 18, 2002.

SwRI Technical Proposal: Technical Proposal for Invitation to Negotiate (ITN): Statewide Transportation Management Center Software Library System, Negotiation Number: ITN-DOT-02/03-9025-RR, SwRI Proposal No. 10-35924, dated: January 31, 2003.

Concept of Operations

SunGuide-ConOps-1.0.0 3

SwRI Cost Proposal: Cost Proposal for Invitation to Negotiate (ITN): Statewide Transportation Management Center Software Library System, Negotiation Number: ITN-DOT-02/03-9025-RR, SwRI Proposal No. 10-35924, dated: January 31, 2003.

SwRI BAFO letter: Southwest Research Institute® Proposal No. 10-35924, “Invitation to Negotiate (ITN): Statewide Transportation Management Center Software Library System”, Reference: Negotiation Number: ITN-DOT-02/03-9025-RR, dated: May 5, 2003.

FDOT procurement document: Invitation To Negotiate (ITN), Negotiation Number: ITN-DOT-02/03-9025-RR, Statewide Transportation Management Center Software Library System, dated: October 21, 2002.

FDOT Scope of Services: Statewide Transportation Management Center Software Library System: Scope of Services, September 22, 2003.

FDOT Requirements Document: Statewide Transportation Management Center Software Library System: Requirements Specification, June 3, 2003.

Southwest Research Institute, TMC Software Study, November 15, 2001.

Southwest Research Institute, Introduction to an Operational Concept For the Florida Statewide Library, FDOT-OCD-1.0, March 31, 2002.

World Wide Web Consortium (W3) website: http://www.w3.org.

SunGuideSM Project website: http://sunguide.datasys.swri.edu.

1.5 Contacts

The following are contact persons for the SunGuideSM software project:

Elizabeth Birriel, ITS Central Office, [email protected], 850-410-5606 Liang Hsia, FDOT Project Manager, [email protected], 850-410-5615 John Bonds, Senior ITS Specialist, [email protected], 408-873-2514 David Chang, ITS Specialist, [email protected], 850-410-5622 Steve Dellenback, SwRI Project Manager, [email protected], 210-522-3914 Robert Heller, SwRI Software Project Manager, [email protected], 210-522-3824 Charlie Wallace, PB Faradyne Deputy Project Manager, [email protected], 352-

374-6635 John Schumitz, PB Faradyne Software Project Manager, [email protected], 301-

816-1852

The following are contacts that will be used by the SunGuideSM software project team to assure consistency with other FDOT projects and FDOT procedures:

Dan Baxter, PB Farradyne, FDOT C2C Project, [email protected], 407-587-7809 David Lambert, University of North Florida, RWIS, [email protected], 904-620-3881 Bob Colins, PBS&J, Emergency Evacuation, [email protected], 850-575-1800 John Fain, FDOT, Comptroller, [email protected], 850-921-7332 Leslie Jacobson, PB Farradyne, Ramp Metering, [email protected], 206-382-5290

Concept of Operations

SunGuide-ConOps-1.0.0 4

2. Current State of the Practice

2.1 Background Within the state of Florida, a number of ITS systems have been developed and deployed. While these systems provide for needs of the organizations that procured the systems, the FDOT desires to have a single software code base (owned by the state of Florida) that can be used by agencies throughout the state.

The following organizations have deployed significant ITS systems:

• District 2 - Jacksonville • District 4 - Broward • District 5 - Orlando • District 6 - Miami • Turnpike Enterprise

The FDOT established a goal of developing a reusable software framework that would allow a single source code base for development and maintenance. In order for this approach to work, it must be understood that not every organization will want to deploy the exact same software due to operational differences and differences in the type of equipment that is needed to accomplish the ITS goals of the organization.

With these constraints in mind, it is important to establish a software framework that would allow organizations to pick and choose software modules based on their operational needs. With this approach, the state of Florida will leverage its development funds by developing software one time and deploying it multiple times. This will also provide a significant savings on software maintenance because a single code based will be maintained for all users.

2.2 SunGuideSM Software Initiative The FDOT funded an initiative to acquire the most technically comprehensive Advanced Traffic Management System (ATMS) software available and establish a standard at transportation management centers (TMCs) throughout the State of Florida. The software is to be flexible and expandable to match the individual needs of each TMC. Each TMC will collect, assess, and manage real-time traffic data and video and deliver meaningful and accurate traffic management information to the public and commercial vehicle operators. The primary goals of the SunGuideSM software project are to reduce congestion and delays while responding to traffic incidents in a rapid, accurate, and effective manner.

The Department has endorsed the concept of providing a centrally managed, publicly owned set of software modules to completely support the functionality of the regional transportation management centers. The SunGuideSM software is based on software available from the states of Texas and Maryland. These states have developed and deployed ITS software for many years and the FDOT wishes to utilize this software as a core for the SunGuideSM project while adding functionality to support the needs expressed by various FDOT government agencies.

Concept of Operations

SunGuide-ConOps-1.0.0 5

3. Justification for the SunGuideSM System

3.1 Justification of Development The SunGuideSM software team carefully compared SunGuideSM requirements against known software that met the other SunGuideSM criteria such software ownership. The software development effort utilizes other ITS system software known to be owned by other state agencies (Maryland and Texas). However, it was determined that the existing software base will need modification to meet the FDOT requirements. There is still a significant benefit in using the existing software because the developers will not have to start from scratch. Furthermore, to take advantage of advances in technology including software technologies, server technologies, and field equipment technologies, significant rewriting of the base software from Maryland and Texas is necessary.

3.2 Description of Functionality The SunGuideSM software project will have the following functionality:

• Database: An Oracle database will be developed that contains configuration information as well as snapshots of the data that is produced, monitored, and controlled by the SunGuideSM. The data stored will include traffic conditions data (volume, speed occupancy), current device settings (e.g., current message displayed), incident information, etc.

• Software Configurability: The subsystems will have a number of operational parameters that can be modified to alter the behavior of the software. The parameterized implementation of software allows a system to take a different “look and feel” in the Districts based on the operational parameters with which the software is initiated.

• Security: A multi-level user security model that is used throughout the TxDOT software will be implemented within the SunGuideSM software. The levels to be defined include: operator, supervisor, administer, and observer.

• Abstraction Layer: A high-level application framework will be provided that forms the basis for implementing SunGuideSM subsystems. This framework will define how interfaces are to be established and conventions for data exchange. This framework provides the basis for how a software system becomes extensible (i.e., expandable) in a highly modular fashion.

• Executive Handler: An executive handling subsystem (for process initiation, termination, restart, and heartbeat monitoring) will exist within the SunGuideSM system.

• Logging: A logging subsystem (for errors and informational messages) will exist within the SunGuideSM system.

• Data Bus: The Data Bus subsystem provides real-time exchange of data between the subsystems of the SunGuideSM. The Data Bus provides a framework to which processes attach and exchange data with other subsystems. Depositing data to the bus must be done in a structured, common format and extracting data from the Data Bus requires an appropriate privilege level.

Concept of Operations

SunGuide-ConOps-1.0.0 6

• Mapping: The mapping subsystem will display primary and secondary roads along with the status information available from the Data Bus. The map will connect to the Data Bus and will be capable of displaying traffic conditions, incidents, lane closures, and device (e.g., DMS, CCTV) status in a real-time fashion. The displayed components will be color coded so that trouble spots can be easily identified by observing a graphical view. The operator will be able to pan and zoom the map so that regions of interest can be expanded or shrunk depending on the operator’s needs. Icons will be displayed for field equipment locations, incidents, and lane closures; an operator can access the field equipment by selecting the icon.

• Graphical User Interface (GUI): The GUI will provide access to various subsystems (e.g., DMS, CCTV, incident management, etc.) using industry standard browser techniques. The approach of a browser implementation provides users the ability to configure their view of the data while providing a flexible user interface.

• Closed-Circuit Television (CCTV) Subsystem: The CCTV subsystem will provide control of cameras as well as video switches. SwRI assumes the video switches will “drive” a video wall and/or video cubes. The SunGuideSM software will allow a user to switch a CCTV input to a video output, this could be a video monitor, video wall/cube or a PC monitor display if the hardware supports the video feed. The CCTV subsystem will support NTCIP CCTV devices. The subsystem will support the switching of IP Video devices and controlling of displays on a Barco/Argus video wall.

• Transportation Sensor Subsystem (TSS): The TSS acquires data from field devices to determine traffic conditions (e.g., speed, volume, and occupancy). The TSS subsystem will support BiTrans B238-I4, EIS RTMS, Wavetronix RTMS, and 3M Canoga microloops.

• Incident Detection: The incident detection subsystem utilizes monitoring algorithms that evaluate information from field devices (through the TSS) to determine if traffic anomalies have arisen. The algorithm utilizes a rolling average that can be weighted by historical data to determine when traffic anomalies occur. When anomalous situations are detected, an alarm will be sent to the incident management software to indicate that a potential problem needs to be evaluated by the operator. Alternatively, a manual entry screen will be provided so that incidents from non-automated sources (e.g., cell phones or 911) can be entered into the subsystem.

• Incident Management: The incident management subsystem will be based on the Maryland CHART II incident management subsystem. The subsystem will receive indicators of traffic congestion and recommended solutions (i.e., how traffic control devices should be altered) will be generated. The subsystem will utilize expert system technology to provide recommended solution scenarios to the operator. After operator approval, the requests to update the traffic control devices will be sent to the appropriate SunGuideSM subsystem for implementation.

• Dynamic Message Signs (DMSs): The DMS subsystem will allow users to control and monitor DMS devices. The DMS subsystem will receive display requests from external subsystems (such as incident management) for display of messages. The subsystem will support FDS NTCIP compliant devices and Mark IV devices.

Concept of Operations

SunGuide-ConOps-1.0.0 7

• HAR: The HAR (Highway Advisory Radio) subsystem will allow the TMC operator to transmit messages to HAR devices when traffic conditions or incident management requirements dictate a new message be presented on the HAR devices.

• Center-to-Center (C2C) Communications: The TxDOT C2C software will be integrated with the FDOT SunGuideSM software. This software allows both status and command/control information to be exchanged between TMCs in a system independent fashion. TMCs participate in the C2C environment by developing “plugins” which are XML interfaces. Status data includes traffic conditions, incident, lane closures, device status information and limited transit information. The command/control capability allows requests to change devices such as DMS, CCTV, video switch, traffic signals, HOV, dynamic lanes, etc.

• Archived Data: This subsystem will structure and store data for long term storage.

• Ramp Metering: This subsystem will allow a user to view the status of a ramp meter and to change the current plan implemented at the ramp meter. The subsystem will utilize the Washington Department of Transportation 170 firmware for data acquisition and ramp signal control. The status information will be available on the Data Bus and control function will be limited to privileged users.

• Web Server: This subsystem will provide traffic data from the SunGuideSM system to be presented on a web server interface. The web server will provide traffic conditions maps (showing traffic speeds, incidents, and lane closures) that will allow the public to access the data from the Internet, if the web server that is hosting the subsystem has been exposed to the Internet.

• Road Weather Information System (RWIS): The RWIS subsystem will interface to NTCIP sensor stations to provide weather conditions information to the SunGuideSM. The data from the RWIS subsystem will be published to the Data Bus.

• Emergency Evacuation Support: A web-based subsystem will be developed that will provide a variety of manual entry screens for data to be entered and reviewed by users of the subsystem. Additionally, much of the external data requested in the FDOT requirements will be provided through the use of URLs (Uniform Resource Locators) to web sites that already gather and maintain the data.

• Inventory and Maintenance: The Inventory and Maintenance subsystem will provide the user with a web-based application that supports the record keeping requirements of the maintenance shop.

3.3 Priorities Among Functionality The following priorities were established for three different releases by FDOT during contract negotiations:

• Essential features:

o Release 1: Database Software Configurability

Concept of Operations

SunGuide-ConOps-1.0.0 8

Security Abstraction Layer Executive Handler Logging Data Bus Mapping Graphical User Interface Closed-Circuit Television Subsystem Transportation Sensor Subsystem Incident Detection Incident Management Dynamic Message Signs

o Release 2: Database (update for the release) Mapping (update for the release) Graphical User Interface (update for the release) Highway Advisory Radio Subsystem Center-to-Center Communications Archived Data Ramp Metering Web Server Road Weather Information System Emergency Evacuation Support Inventory and Maintenance

• Desirable features:

o None identified

• Optional features: o None identified

3.4 Functionality Considered but Not Included As with any significant software development effort, the user requirements will many times exceed the implementation budget available. The following is a list of subsystems that have been identified as needed but have not been included in the current development plans due to limited funds:

• Motorist Call Box Subsystem: A subsystem that would show the location on the graphical map of a motorist initiated call from a call box located along a highway.

• Automated Emergency Evacuation Subsystem: Due to geographical location of Florida, evacuations are a reality that the transportation system operators must address. The initial releases of the SunGuideSM software will have a manual data entry based Emergency Evacuation subsystem, the long term goal is to have a highly automated emergency evacuation subsystem that collects data from a wide variety of sources (beyond typical transportation data sources) and combine them into a common repository.

Concept of Operations

SunGuide-ConOps-1.0.0 9

• Drivers for many ITS legacy devices: The FDOT has a number of legacy devices that do not conform to the protocols that FDOT has selected to support in the SunGuideSM deployment. As of publishing time of this document, the following devices will be supported by the SunGuideSM software:

Subsystem Protocol Reference Release

DMS NTCIP 1203, FDOT MIB (September 2001) 1

DMS Mark IV - I95: Document Number A316111-102 REV. A8 (June 26, 2001) 1

DMS SunGuide Trailblazer 2

CCTV Control NTCIP 1205 v01.08 Amendment 1 v01.08 (August 2004) 1

Video Switching IP Video (VBrick 4200/5200, Teleste

IDP301/IDE301, Coretec VCX2400D/VCX2400E, iMpath i1000)

1

Video Wall Barco/Argus Apollo 1 Traffic Detection BiTrans B238-I4 1 Traffic Detection EIS RTMS, Issue 2 (April 2003) 2

Traffic Detection Wavetronix RTMS: SS105 SmartSensor Data Protocol V2.02 2

Traffic Detection Canoga Microloops, TM-2003-8 (June 2003) 2

HAR Highway Information Systems DR2000 2 Ramp Meters WSDOT 170 Firmware 2 RWIS NTCIP 1204 v02.18 (April 2004) 2

Concept of Operations

SunGuide-ConOps-1.0.0 10

4. Concept for the SunGuideSM System

4.1 Background The SunGuideSM software is a robust software environment that is a collection of subsystems that will provide the FDOT with a state-of-the-art ITS system. The FDOT’s goals in developing the SunGuideSM include:

• Improve transportation safety. • Reduce congestion and delays. • Acquire (own) the most technically comprehensive ITS software. • Establish a software standard at Transportation Management Centers (TMC) throughout

the State of Florida. • Reduce multiple TMC software development, maintenance, and update costs.

Goals specific to the software include:

• Flexible and expandable to match individual TMC needs. • Respond to traffic incidents in a rapid, accurate, and effective manner.

4.2 Operational Policies and Constraints

The SunGuideSM software is being designed and implemented with the following policies and limitations in place:

• The software is designed to support operations twenty four (24) hours a day, seven (7) days a week.

• The software is designed to have at least one user “in the loop” to implement response plans to incidents.

• The SunGuideSM software is designed for the following operating environments: o Servers: Microsoft Windows Server 2003 o Workstations:

Microsoft Windows XP Professional Internet Explorer Version 6.01 or higher

Note that while the above mentioned timeframes were used during the software development, the reality of deploying Microsoft Windows applications is that occasional restarts of the host computers will be required as the underlying operating system needs an occasional restart. It is recommended that the operational servers be rebooted weekly to assure the operational integrity of the Microsoft Windows operating system.

4.3 Operational Environment The SunGuideSM software consists of a large number of processes (software applications) that interact in a cooperative environment (as subsystems) to provide the SunGuideSM environment. It is quite possible to run the SunGuideSM on a single laptop computer, but this configuration would not support many ITS devices. The number of computers required to support the SunGuideSM will vary widely based on the deployment environment (the most significant factor is the number of ITS devices).

Concept of Operations

SunGuide-ConOps-1.0.0 11

A diagram of a typical hardware configuration is included as Figure 4.1 of this document. For typical center installations, each SunGuideSM implementation would need the following:

• Workstations: one for each user console. The SunGuideSM GUI renders many of its images in real-time and therefore a fast processor (> 2.5 GHz) is desired for each workstation.

• Database Servers: One for the local SunGuideSM implementation. Clustering technology or high availability technology can be used, but these hardware architectures are transparent to the SunGuideSM software. Database severs should be configured with significant memory (> 1.0 gigabyte) because Oracle operates most efficiently with large amounts or memory.

• Application Servers: The number of these required varies based on the number of SunGuideSM subsystems deployed and how many ITS devices each of those subsystems is required to support.

Note that dual processor servers could be used to reduce the number of application servers that would need to be deployed. The SunGuideSM software is being developed using techniques that should allow the full capability of a dual processor server to be utilized. However, one dual processor machine cannot simply replace two single processor machines because other issues such as memory requirements and I/O bandwidth (i.e. network connectivity) need to be carefully evaluated.

Concept of Operations

SunGuide-ConOps-1.0.0 12

Figure 4.1 - Typical SunGuideSM Software Hardware Environment

The SunGuideSM software requires that an Oracle database be installed on a server before the SunGuideSM installation can be initiated.

During an installation, the following installation steps are expected to be performed by the local SunGuideSM administrator:

• Develop an implementation plan (determines computer configurations and installation location of software)

• Create the SunGuideSM database (using scripts provided on the installation CD) • Install the SunGuideSM applications on the servers identified in the implementation plan • Populate the SunGuideSM database with the devices to be controlled by the software

(using the administrative tool) • Populate the message library using the GUI • Populate the banned word list • Create users and assign user permissions • Create response plans using the GUI • Configure the web browsers on the workstations to access the SunGuideSM software

Concept of Operations

SunGuide-ConOps-1.0.0 13

4.3.1 Network Connectivity

The SunGuideSM software is a highly distributed computing environment that utilizes Transmission Control Protocol/Internet Protocol (TCP/IP) to communicate between software applications. The SunGuideSM implementation documentation will provide the specific TCP/IP port numbers (which are configurable) that the deployment is utilizing. The host network must support TCP/IP protocol and it must allow the SunGuideSM specific port traffic to be passed through any network appliances that are used to connect computers executing SunGuideSM software.

The network connectivity is the responsibility of the local organization that is installing the SunGuideSM system and not a function of the SunGuideSM software development effort. Before the SunGuideSM software can be installed, TCP/IP connectivity between all SunGuideSM computers must be established.

4.3.2 ITS Device Connectivity

The SunGuideSM software expects to communicate with ITS devices connected to the network and use TCP/IP to communicate with the devices. This will typically be done by connecting the ITS device’s serial port to a terminal server (sometimes called a port server or a serial server) which will then provide the SunGuideSM software TCP/IP access to the terminal server (which converts the TCP/IP packets to a serial data stream for transmission to the physical device).

The only exception to this connectivity requirement are Dynamic Message Signs and Trailblazers which may be connected via modems attached to the SunGuideSM application server that is to communicate to these devices.

In general, for each ITS device to be controlled by the SunGuideSM system, the following types of information are required:

• Geo-location of device (latitude/longitude in ISO microdegrees) • Name of device (arbitrary text string) • Protocol used by the device

For devices which are TCP/IP connected, the following types of information will need to be known when the devices are configured for use in the SunGuideSM software:

• IP address • Port number

For devices which connect using a modem (e.g. DMS or Trailblazer), the following types of information will need to be known when the devices are configured for use in the SunGuideSM software:

• Phone number • Baud rate • Parity • Number of data bits • Number stop bits

Concept of Operations

SunGuide-ConOps-1.0.0 14

An administrative GUI will be available to the SunGuideSM administrator to perform the previously described device configuration.

4.3.3 Video Transmission

The SunGuideSM software does not perform any transmission of video; the software does provide support to initiate video switching but the actual transmission of the video is not within the scope of the SunGuideSM software.

The SunGuideSM software will provide video switch drivers for several different types of video switching devices. If a deployment chooses to use video over IP video for video transmission, it is required that the encoders and decoders are configured to use the same type of protocol (e.g. UDP, RTP, etc.), implement the same video encoding standard, and the same encoding options (transport vs elementary streams). The SunGuideSM software will not address the inter-operability of codecs, rather, it will restrict the user to only connect encoders and decoders that have the same protocol.

There are many facets of video encoding which determine compatibility between encoders and decoders. Among these are video compression standard (MPEG-1, MPEG-2, MPEG-4), options implemented within the standard, and packetization of digitized, compressed video data.

At the time of this writing video encoders and decoders being deployed to support transportation applications are compliant predominantly with the MPEG-2 standard. Of these, most implement main profile and main levels and transmit data either as an elementary or transport stream. Elementary streams are direct outputs of encoders (video or audio), transport streams are multiplexed (multiple or single) video and audio streams with timestamps to facilitate accurate reconstruction of the video signal by a compatible decoder. Additionally, since data must be converted from a raw data stream into packets for transmission, there are additional issues regarding packet sizes, spanning of elementary stream blocks across packet boundaries, etc.

4.3.4 Security

The SunGuideSM software assumes a network environment that will support the exchange of TCP/IP packets between SunGuideSM applications. No specific security (other than the encryption of passwords) is performed by the SunGuideSM software. If additional network security is required by a deploying organization, a careful analysis of how data will be exchanged needs to be made when the implementation plan for the deployment is developed.

4.3.5 Center-to-Center

The SunGuideSM software will utilize Center-to-Center (C2C) software that provides a mechanism for exchanges of two types of data:

Concept of Operations

SunGuide-ConOps-1.0.0 15

• Status data: this type of data a center “pushes” to other centers, this data may include traffic conditions (e.g. speed, occupancy, volume), incident information, special event, current device status (e.g. DMS messages, HAR messages, etc.)

• Command/Control data: this type of data is when an operator in one center issues a command to another center to change the current state of an ITS device (e.g. an operator can send a request to change a DMS that another center operates).

When the SunGuideSM software is installed and configured, the local SunGuideSM administrator configures C2C software to indicate what status data will be published and what commands will be allowed to be received. Additionally, when an operator makes a request from a remote center, the user credentials (e.g. username and password) of the user making the request will be sent to the receiving center for validation prior to the command being processed – this implies that a remote user must have valid credentials in both the local and remote centers.

The C2C interface is transparent to the user of the SunGuideSM software; when devices are presented on either the map or selection lists, the owning center’s information is available but to the SunGuideSM user devices from other centers are accessible (assuming they SunGuideSM administrator configured them to be accessible) in a fashion similar to locally controlled devices.

4.3.6 Configuration Management

One of the key justifications for the SunGuideSM software development project was to have a single source code base for the entire state of Florida. This would allow for software development to be paid for a single time and then to be deployed a number of times; the long term cost savings of this approach will be very beneficial to Florida. With this approach, solid Configuration Management is mandatory to assure that the software base is properly maintained. The SunGuideSM software is designed to be highly modular and conformant to well defined interfaces, this flexibility does not require every installation to be at the same version of software, it is an operation reality that different versions will be deployed.

A configuration management board that regularly meets to discuss enhancements and issues must exist. As development activities are approved by the board, a central repository of software must be maintained and managed so that solid configuration management is retained. Florida must be very careful not to allow different versions of source code to be maintained in multiple places or the cost savings associated with the justification of the project will not occur.

4.4 Modes of Operation

FDOT has defined four types of TMCs that will operate the SunGuideSM software:

• RTMC: Regional Transportation Management Center • STMC: Satellite (or Secondary) Transportation Management Center • VTMC: Virtual Transportation Management Centers • PTMC: Portable Transportation Management Centers

Concept of Operations

SunGuide-ConOps-1.0.0 16

The following table provides a brief comparison of the four types of TMC configurations possible with the SunGuideSM software:

Data Bus Number of

Devices Controlled

Supports GUI

Access Platform Subsystems

Deployed

Device Driver

Deployment

RTMS Uses own Large Yes Multi Server typical

All All

STMC Shares RTMC

Data Bus Moderate No

Single or multiple Server

Single or multiple One or two

VTMC None. None No Desktop / Laptop None None

PTMC Uses own Small Yes Laptop All All

The following sections describe how the SunGuideSM software would be deployed in each of the four types of centers.

4.4.1 Regional Transportation Management Center

RTMCs will serve as hubs for command and control decisions for deployments that have significant amounts of ITS field devices deployed. An RTMC will typically have multiple SunGuideSM application servers that are connected to a Local Area Network (LAN) within the RMTC that provides access to the various ITS devices deployed in the field. It is expected that an RTMC will have an operations room that has a number of operator workstations deployed. An RTMC is distinguished from other types of centers in that it will typically control the network access to a number of ITS field devices.

4.4.2 Satellite Transportation Management Center

STMCs are deployments where ITS field equipment is connected to the network local to the STMC. STMCs would be deployed when device connectivity is centered on remote buildings and the cost of extending the network to the RTMC outweighs the deployment of SunGuideSM servers in an STMC to provide local communications to the devices. An STMC does not provide a user interface, it is simply a device collection implementation of SunGuideSM.

The STMC will utilize the Data Bus of an RTMC as its master data repository and the STMC will simply be an extension of the RTMC. When an STMC is deployed, the subsystem and drivers required to operate the equipment connected to the STMC should be deployed on a

Concept of Operations

SunGuide-ConOps-1.0.0 17

SunGuideSM application server physically in the STMC. The SunGuideSM application server would then make a connection to a RTMC for its central data services. In this context, the STMC does not require a database locally within the STMC. The following figure depicts the relationship between a RTMC and STMC:

4.4.3 Virtual Transportation Management Center

VTMCs are deployments that utilize the SunGuideSM browser interface to perform SunGuideSM operations from other facilities. Although the user is physically located outside the RTMC, the browser access makes his/her location transparent.

4.4.4 Portable Transportation Management Center

PTMCs are deployments that utilize laptop computers to provide “mini” SunGuideSM deployments that are used for demonstration, interim operations or field debugging of software. The SunGuideSM software can operate on a single computer; the limiting factors are the size of the database and the number of ITS field devices that the PTMC is attempting to control.

When deploying a PTMC, the number of ITS devices should be limited to twenty and minimal data archiving should be initiated. When using a PTMC, all of the configuration that must be performed for an RTMC must be performed for the PTMC (there should be less of it since fewer devices are supported).

As an example, an operational use of an PTMC may include a construction project where it is known that network connectivity to the RTMC will be lost from a cluster of devices. In this situation, the operational staff will know what devices will be isolated so that the PTMC may be configured prior to deploying in the field. This type of configuration includes device addresses, type, attributes, etc. The PTMC will have its own database and if standard messages are desired, the message database would need to be populated with these messages.

Since the PTMC is a SunGuideSM implementation, all functionality of SunGuideSM is available within the PTMC. This implies that a C2C connection could be established between the PTMC and the C2C infrastructure, but performance limitations of the PTMC host computer limit how

Concept of Operations

SunGuide-ConOps-1.0.0 18

much data is exchanged between the PTMC and the C2C infrastructure (but again, this data is configurable by the SunGuideSM administrator.

4.5 User Classes The SunGuideSM software comes installed with five user groups defined. Each of the SunGuideSM subsystems has a variety of privileges that are unique to each subsystem. For example, the Dynamic Message Sign subsystem allows the SunGuideSM software to indicate whether or not a user has permission to send a message to a sign. The SunGuideSM deployment administrator can choose to add additional groups or to alter the default permissions assigned to each group.

The five basic groups (along with their intended usage) are:

• Administrator: can alter system configuration such as adding users, devices or altering system parameters (e.g. polling rate) – there would typically be one or two users with these permissions for each deployment of the SunGuideSM software.

• Manager: override equipment locks, approval authority – a user who has administrative oversight and can typically resolve conflicts when multiple users request to use the same device. Typically each shift would have one manager present and available to perform his functions.

• Operator: performs daily operations tasks – this classification of user will be the user who sits at a SunGuideSM console for the majority of the day. The user will handle incidents and perform control of devices to provide information to the traveling public.

• Local guest: camera control, view status – this might be a user from the media or a high-level manager that does not need to perform device control.

• Remote guest: device control (via Center-to-Center), view status – this would be a set of user credentials that would be normally provided by a user working at a remote center so that a remote center could issue device control requests.

As users are added to the system, they are assigned a default group (which they then inherit the current permissions of that group). The SunGuideSM administrator can then alter specific permissions for each user (i.e. they can change the default group permissions they were provided). The permissions capability is provided so that the SunGuideSM administrator can provide access at the appropriate levels to various users. 1

4.6 Support Environment The following support activities will need to be performed on the SunGuideSM software and computers that host the software:

1 After a user is assigned permissions from a group, altering the permissions of that group does not alter the permissions of the user.

Concept of Operations

SunGuide-ConOps-1.0.0 19

• Database host:

o Must be kept current with Microsoft patches and service packs o Critical updates to Oracle must be maintained o Routine database management needs to be performed to assure that the database

integrity is maintained and all available storage space is not consumed by Oracle.

• Application host computers:

o Must be kept current with Microsoft patches and service packs o Monitor the disk space being used by Status Logger

• Workstations:

o Must be kept current with Microsoft patches and service packs o Minimize the addition of applications that make changes to or add plugins for the

browser used to operate the SunGuideSM software

• Development environment:

o Must be kept current with Microsoft patches and service packs o The configuration management repository must be managed as software is

modified.

• Data archive host computer

o Must be kept current with Microsoft patches and service packs o Monitor the disk space being used for archived data files.

Specific responsibility for who performs the support will vary by deployment but it will be important that the support be performed. As the SunGuideSM software ages, it is anticipated that FDOT will continue to upgrade operating systems as Microsoft continues their development efforts. As this occurs, FDOT will need to assure that they evaluate the impact on the SunGuideSM software before making operating system upgrades as these may affect the performance or function of the SunGuideSM software.

As part of routine maintenance of any Windows based server, the system administrator needs to monitor the resources available on the server. This includes disk space as well as disk fragmentation – the performance of Windows applications will degrade if disks become full and heavily fragmented. For example, if the disk on which Oracle becomes full, Oracle will cease to operate and the SunGuideSM software will be unable to operate.

Each SunGuideSM deployment will need to develop a set of system maintenance procedures (that are not specific to the SunGuideSM software) to assure the operational health of the SunGuideSM servers. A regular database backup and cleanup (i.e. remove old data) will need to be performed and the log files from Status Logger may need to be archived if the SunGuideSM administrator configures the Status Logger not to roll over its data files every week.

In order to assure coordinated time stamps on data collected by the SunGuideSM software, each workstation and server should be pointed to a “time server” that will provide a source for coordinated time. This server could be located within the local agency, a statewide server or it could be one of the many time servers available on the Internet (e.g. time.windows.com).

Concept of Operations

SunGuide-ConOps-1.0.0 20

Only two SunGuideSM applications make any significant use of disk space: Status Logger and Data Archiving. The amount of disk space these two applications require during operations is based on what level of logging (and whether the logs are rolled over or retained) is established by the SunGuideSM administrator and how much data is configured to be archived. The other applications use only the disk space allocated when the applications are installed.

Concept of Operations

SunGuide-ConOps-1.0.0 21

5. Operational Scenarios The following section provides example scenarios that operators, administrators, and managers might perform. Example operational scenarios for operators include:

• Normal Operations, • Incident Management, • Center-to-Center, • Amber Alert, • DMS Conflict Resolution, • Preplanned Road Closures, • Create a New Video Tour, • Manual Incident Creation, and • Subsystem Restart.

Example operational scenarios for administrators include:

• Creating a New User, • Adding a New Camera, and • Adding New Servers.

Example operational scenarios for managers include:

• Adding Contracts and • Setting up Responders.

5.1 Operator

5.1.1 Normal Operations

An operator starting his shift sits down at his workstation and logs into the SunGuideSM Traffic Management System. He decides to check the system status to make sure that the systems are functioning. The operator opens Executive Handler and notices that the DMS subsystem has been having some trouble.

Concept of Operations

SunGuide-ConOps-1.0.0 22

The operator switches to Status Logger to get more information about the problems, but does not find much since the log mode was set to ‘Information’. He changes the log level to ‘Detail’ so that he can determine what is wrong with the DMS subsystem.

The operator allows the system to run for some period of time to give the DMS subsystem time to generate messages to the status logger at this new logging level. The operator then views the status log to investigate the problems.

Satisfied that the SunGuideSM system is working well now2, the operator turns his attention to the map view where he observes the local freeways and traffic flow. Data displayed contains speed, volume, density, and occupancy.

2 The Statewide driver logging level is still set to detail. The logging level should be reset to information at some later time.

Concept of Operations

SunGuide-ConOps-1.0.0 23

Traffic conditions look normal for this time of day, so the operator starts to check on the scheduled events for the day.

5.1.2 Incident Management

The operator is alerted of a new incident in his section by Event Manager. The alarm is triggered when speeds on a segment of freeway fall below thresholds associated with that segment (these are configurable by segment, by time of day, by day of week, etc.).

The operator responds by moving the mouse to that area of the freeway on the map, and viewing roadway details in a popup display. The traffic appears to be slowing, so the operator obtains a

Concept of Operations

SunGuide-ConOps-1.0.0 24

lock on the nearest camera, and drags it to the video switching panel so that it will display at his workstation.

The operator pans, tilts, zooms, and focuses the camera to obtain a better view of the area, and is thereby able to confirm the incident.

The incident is a major accident, so the operator switches the camera’s output to the video wall.

Concept of Operations

SunGuide-ConOps-1.0.0 25

The operator wants to view the scene from another angle using a nearby camera, but this camera has a lock in place, so the manager overrides the lock. The operator and his manager see a situation that should not be made public, so they set this second camera to blackout state.

The operator then selects the new incident in the Event Manager panel, and begins editing the incident details.

Concept of Operations

SunGuide-ConOps-1.0.0 26

He enters the incident description, how it was initially reported, and confirms the incident.

The operator clicks on the location tab, verifies the location at which the incident was reported (this is typically based on operator knowledge or location of the traffic detector which reported abnormal traffic flow). The operator may note any adverse weather conditions and/or modify the lane configuration to note which lanes are blocked.

Concept of Operations

SunGuide-ConOps-1.0.0 27

Moving to the “type specific” data entry form, the operator may elaborate on pavement conditions, noting the number of vehicles involved, and hazardous materials that may be involved. The associations tab provides the operator with the ability to associate alternate routes and events with this incident.

Concept of Operations

SunGuide-ConOps-1.0.0 28

The final step before having the Incident Management (IM) system generate a response plan is to review contact information and participating agencies in resolving the incident.

Concept of Operations

SunGuide-ConOps-1.0.0 29

Next, the operator creates a response plan for this incident. He reviews the initial suggested response, including messages for DMSs and HARs, as well as contacts for email and pager notification, and decides to modify it.

Concept of Operations

SunGuide-ConOps-1.0.0 30

Upon receiving approval from his manager, the operator sends the new response plan to the system. Finally, the operator navigates to the incident location on the Map, and views the output of the DMSs listed in the selected response plan. He observes that their messages are changed appropriately. Finally, before moving on to his next task the operator reviews the history of the incident to make sure it is accurate and needs no further adjustment.

5.1.3 Center-to-Center

An operator in a neighboring district receives an email notification as a result of an incident response plan that was sent. The email warns of an imminent traffic slowdown along the highway. She decides to take a look at the incident via a Center-to-Center connection to the camera nearest the incident. When an operator is utilizing the SunGuideSM GUI to access cameras (or any SunGuideSM devices) from other centers, the name of the center will appear in the title of the dialogue, but access to the device is transparent to the user (i.e. the system will automatically route requests to the device). This camera is locked, however, so the operator contacts the controlling center and requests that they release the lock so that she can control the camera. The lock is released, and she is able to view the incident, moving the camera with a

Concept of Operations

SunGuide-ConOps-1.0.0 31

joystick. This operator sets up a local response plan, receives approval for it, and sends it to the local system.

5.1.4 Amber Alert

An operator performing routine traffic monitoring receives notification of an Amber Alert. He quickly prepares the response for the alert, by selecting a predefined message template and modifying it so that it contains the pertinent information for this alert, such as a vehicle description and contact name. The operator confirms that the message priority is set to high, and checks the time duration for displaying the message.

5.1.5 DMS Conflict Resolution

It becomes apparent, however, that there is a conflict between the message for the major accident on the highway and the message for the Amber Alert. The operator’s manager decides it would be best to continue showing and broadcasting incident-related messages on the DMSs and HARs around the accident until the situation begins to clear. The manager resolves the conflict (via Conflict Resolution) and tells the operator that he should check later to make sure the Amber Alert message displays on those DMSs once the incident is cleared.

Concept of Operations

SunGuide-ConOps-1.0.0 32

5.1.6 Preplanned Road Closures

Major repairs will be commencing in one week along a heavily-traveled span of highway, so the decision was made to start notifying travelers along the planned repair route starting today. Additionally, diversion messages will be posted during the repairs, rerouting traffic to avoid congestion. The operator establishes a sequence by selecting DMSs and HARs along the route, and editing their messages to give advance notification of the work. The messages specify the details of the repairs, such as when the repairs will be occurring and what lanes will be affected.

Concept of Operations

SunGuide-ConOps-1.0.0 33

The operator saves the sequence to the ‘Roadwork Sequence’ library, and is notified that the word ‘construction’ is not on the approved words list. Because the operator has permission to modify the approved words list, he adds the word to the list, and notifies his manager that the sequence is ready to be submitted.

Concept of Operations

SunGuide-ConOps-1.0.0 34

The manager reviews and approves the sequence, and the operator submits these new messages so that they will be displayed/broadcast effective immediately. He then views one of the DMSs to which the sequence was sent, and confirms that the new message is being displayed.

The operator also sets up some suggested diversion routes that will be displayed shortly before, as well as during, the repairs. These messages are saved so that they will display later according to schedule.

5.1.7 Create a New Video Tour

The operator next decides to setup a new video tour, covering the sections of the highway for which he is responsible. He opens the video tour editor panel and drags the CCTVs in his section to the panel. For each camera now on the panel, the operator specifies the PTZ settings as well as the amount of time to display its output. The operator then saves and executes the tour.

Concept of Operations

SunGuide-ConOps-1.0.0 35

5.1.8 Manual Incident Creation

While viewing a video tour, the operator spots a potential incident. The operator selects a camera near the potential incident, switches the camera’s output to display on one of his monitors, then pans and tilts the camera until the object of the incident is visible, and zooms in on the object so that it can be better seen. The visual is dark and out-of-focus, so the operator adjusts the iris and the focus as well.

The operator confirms that he has indeed spotted an incident, so he creates a new incident in the system via the Map. First he right-clicks on the approximate location of the incident on the map, selecting the ‘Add New Event’ option from the drop down menu, then enters a name for the incident in the Create New Event dialog box.

Concept of Operations

SunGuide-ConOps-1.0.0 36

The operator confirms that the incident has been added to the system by verifying that it has been added to the list of incidents showing in the Event Manager panel. The operator can then enter additional details using the incident manager GUIs.

The operator then sets up a response plan for this new incident – the suggested plan is accepted without changes. Once the response plan is executed, the operator confirms that the messages on some of the DMSs included in the response plan have been changed appropriately.

5.1.9 Subsystem Restart

An operator receives a phone call notifying him that the website is not updating – the map, incident, and device information displayed has remained the same for over an hour. The operator opens Status Logger which shows her that the web server is not operating normally.

The operator notifies her manager who confirms the problem in Executive Handler. She stops and restarts the web server without incident.

Concept of Operations

SunGuide-ConOps-1.0.0 37

5.2 Administrator

5.2.1 Creating a New User

A new operator is coming in for his first day at work, and his manager has requested that the new operator be added to the system. A user with administrator privileges starts the Administrative Editor.

Concept of Operations

SunGuide-ConOps-1.0.0 38

As a new operator, he will need to have basic access to cameras and signs. The administrator opens the SunGuideSM Administrative Editor and enters the employee as a new user, assigning him a preliminary password, and putting him into the Operator group. A list of permissions, by subsystem, is displayed, with default settings for the Operator group. The administrator determines that the default settings provide a bit more access than the new operator should have at this time, so he deselects some of the settings that are enabled by default.

Concept of Operations

SunGuide-ConOps-1.0.0 39

While doing so, he is distracted numerous times and loses track of the changes that he has made. He decides to reset the permissions back to the default settings for the Operator group, and start over with his changes.

Concept of Operations

SunGuide-ConOps-1.0.0 40

Once the administrator is satisfied with his selections, he accepts the settings, and the new operator is added to the system. The administrator verifies that the new employee has been entered by browsing the list of users that is displayed on the screen after exiting the user entry screen, and confirming that the new employee has been added.

For further confirmation, the administrator selects the employee’s name in the list and opts to edit his information. The new employee’s permission settings are displayed on the screen, and the administrator can see that the specialized settings he chose when adding the employee are still set appropriately. The manager exits the edit screen without making any changes.

5.2.2 Adding a New Camera

New equipment (DMSs, CCTVs, TSS equipment, HARs, video switches, ramp meters, RWIS devices, and Traffic Signals) has been purchased to replace some old failing equipment, as well as to increase the center’s coverage along the highway. The administrator needs to update the system to reflect the new equipment, starting with CCTVs. Some new CCTV cameras are being installed at various locations, so the administrator adds them to the system, specifying their identification and location information.

The operator expands the CCTV/VS option in the left hand frame, then selects cameras and a list of current cameras is displayed.

Concept of Operations

SunGuide-ConOps-1.0.0 41

Selecting Add will display the camera editor and the operator can complete the addition of the camera to the system.

Concept of Operations

SunGuide-ConOps-1.0.0 42

5.2.3 Adding New Servers

Due to the acquisition of some new computers, the system configuration has changed, and the new machines need to be added to the SunGuideSM system. The administrator needs to setup Executive Handler to recognize a new host and the processes that it will be running. Executive Handler is set to show the currently running processes via the Subsystem View. She switches to Host View so that she can view the processes by host machine.

The administrator adds the new computer using the Executive Handler Editor.

Concept of Operations

SunGuide-ConOps-1.0.0 43

Once the host machine is added, the administrator adds the process(es) that will be running on the new computer, so that the process(es) can be controlled via Executive Handler.

She assigns a subsystem tag for this process, selects the auto-restart option, and saves these settings.

Concept of Operations

SunGuide-ConOps-1.0.0 44

The administrator then stops and restarts Executive Handler so that the new host and its process(es) are controlled by the Executive Handler.

5.3 Manager

5.3.1 Adding Contacts

In response to various promotions and shuffling of responsibilities, a manager is tasked with updating the list of contacts in the system. The manager opens the Contacts Editor within the Incident Management Subsystem, and prepares to add a new contact.

Concept of Operations

SunGuide-ConOps-1.0.0 45

Concept of Operations

SunGuide-ConOps-1.0.0 46

6. Summary of Impacts The following sections provide a summary of impacts the SunGuideSM software will have on FDOT operations.

6.1 Operational Impacts

The following operational impacts may arise as the result of the SunGuideSM software development effort:

• User Interface: The SunGuideSM software is a highly integrated environment where data and commands can be manipulated through a single user interface.

• Diagnostics: The device management (for various classes of devices) is managed through the integrated system. The SunGuideSM software will provide “first level” diagnostics and most troubleshooting will be performed with the SunGuideSM software. If the diagnostics are not sufficient, vendor specific diagnostics software can be used (outside the domain of the SunGuideSM software) to perform more detailed problem analysis.

6.2 Organizational Impacts

The following organizational impacts may arise as the result of the SunGuideSM software development effort:

• Staffing: No changes to the number of staff are envisioned. Existing staff will need training on the SunGuideSM software prior to their using the system.

6.3 Impacts During Development

The following impacts during development on FDOT staff have been identified:

• Status meeting participation: FDOT staff will need to attend status meetings to review project performance and to provide insight into local issues that could effect the development or deployment of the SunGuideSM software.

• General document review: FDOT staff will need to review development documents to make sure that the system under development will meet their users needs.

• Requirements review: FDOT staff will need to review and evaluate if the requirements meet their users needs.

• Design document review: FDOT staff will need to review design documents to determine if the system design is supportable in their planned deployment environment.

Concept of Operations

SunGuide-ConOps-1.0.0 47

7. Analysis of the SunGuideSM System The following sections provide a summary of the improvements, limitations and alternatives for the SunGuideSM software system.

7.1 Summary of Improvements

The SunGuideSM system under development is the first fully integrated ITS system to be deployed in Florida that has the following functional components in a fully integrated environment:

• Database • Software Configurability • Security • Abstraction Layer • Executive Handler • Logging • Data Bus • Mapping • Graphical User Interface • Closed-Circuit Television Subsystem • Transportation Sensor Subsystem • Incident Detection • Incident Management • Dynamic Message Signs • Highway Advisory Radio Subsystem • Center-to-Center Communications • Archived Data • Ramp Metering • Web Server • Road Weather Information System • Emergency Evacuation Support • Inventory and Maintenance

The SunGuideSM system, FDOT is developing, is to replace existing ITS systems deployed. FDOT is collecting additional requirements for new functionality and subsystems and these requirements will be evaluated for implementation once the base system described above is completed.

7.2 Disadvantages and Limitations

The SunGuideSM project has not identified any disadvantages and limitations with the software development effort.

Concept of Operations

SunGuide-ConOps-1.0.0 48

7.3 Alternatives and Tradeoffs Considered

Operational alternatives that were considered for the SunGuideSM project include:

• Standard Windows program versus web browser interface for GUI: for maximal portability and simplicity during implementation the project evaluated whether or not a browser user interface would provide adequate performance to support the SunGuideSM user interface requirements. The primary advantage of the browser environment is the thin client nature of the application (i.e. no software must be installed on the target computer). The evaluation concluded that a browser environment would support the SunGuideSM software.

Concept of Operations

SunGuide-ConOps-1.0.0 49

8. Notes None.