Docstoc

Printable Blank Charts - DOC

Document Sample
Printable Blank Charts - DOC Powered By Docstoc
					           Maryland State Highway Administration’s (MDSHA)
         Chesapeake Highways Advisory Routing Traffic (CHART)
             Software Functional Requirements Document


CHART Mission

It is CHART’s mission to improve efficiency and safety on Maryland’s major
highways through the application of ITS technology and interagency teamwork.
The CHART program relies on communication, coordination, and cooperation
among agencies and disciplines, both within Maryland and with neighboring
states, to foster the teamwork necessary to achieve our goal. This is consistent
with MDSHA’s overall mission which is to provide Maryland with an effective and
efficient highway system.

CHART is unique to other ITS deployments nationally in that:

    It was the first statewide program (others are focused on regions or
      metropolitan areas).

    It consists of a Statewide Operations Center (SOC) facility that is
      interconnected to several satellite/regional facilities.

    The SOC combines four separate functions previously performed out of
      separate locations: freeway traffic management, traffic signal
      management,     emergency     management        and     maintenance
      communications.

    It serves a primary coverage area comprised of two major urban centers
      (Baltimore and Washington, DC) as well as two other urban areas
      (Annapolis and Frederick).

    It is the first program to integrate the efforts of a state highway agency,
      state toll authority and state police.

    In the future, the program will be expanded to include coordination with
      local jurisdictions within the State of Maryland as well as neighboring
      states.

CHART Overview

CHART is currently comprised of the following major components:




                                  1
(1)   Traffic and Roadway Monitoring: Remote sensors, commercial travel
      services, field units, and individual travelers all combine to provide the
      information necessary to assess real-time traffic flow. CHART traffic
      monitoring tools include:

          Traffic speed detectors (currently at 97locations) deployed along
            155 centerline miles of the heaviest traveled freeways. These
            detectors provide the average speed of traffic flow along a segment
            of roadway. This information is used for early detection of traffic
            congestion and incidents.

          Existing in-pavement loop detection traffic counting devices (at 33
            locations) which are being retrofitted to provide speed information.

          Video verification is provided by Closed Circuit Television (CCTV)
            (currently 26 cameras) which provide visual information on traffic
            congestion, incidents and roadway conditions during inclement
            weather.

          Pavement weather sensors installed and operating at 44 locations
            statewide plus and additional 44 from surrounding jurisdictions.
            These sensors are placed at locations that are the first sites to
            freeze during winter conditions.     They provide pavement
            temperature, moisture, and degree of chemical treatment during
            winter operations.

          A #77 cellular call-in system by which individual motorists can
            report disabled vehicles and accidents. This service, coordinated
            through the MSP, receives more than 10,000 calls annually.

          Reports from field units including State and local police as well as
            MDSHA’s own units, and information from commercial radio traffic
            spotters who operate from aerial as well as ground units.

(2)   Incident Management: Once the traffic and roadway monitoring system
      has identified a problem, an immediate response is initiated to clear the
      incident and re-open lanes as quickly as possible, while protecting the
      safety of victims, travelers and emergency personnel. CHART operates a
      nationally recognized incident management program which depends
      heavily on the cooperation and teamwork developed among the MDSHA,
      the MSP and the MdTA. The tools used for incident management include:




                                  2
          Emergency Traffic Patrols (ETP) used to provide emergency
            motorist assistance and to relocate disabled vehicles out of travel
            lanes.

          Emergency Response Units (ERU) used to set up overall traffic
            control at accident locations.

          Freeway Incident Traffic Management (FITM) Trailers, pre-stocked
            with traffic control tools such as detour signs, cones, and
            trailblazers used to quickly set up pre-planned detour routes when
            incidents require full roadway closure.

          A Clear the Road policy which provides for the rapid removal of
            vehicles from the traveled lanes rather than waiting for a private
            tow service or time consuming off-loading of disabled trucks which
            are blocking traffic.

          An Information Exchange Network (IEN) Clearinghouse, provided
            by the I-95 Corridor Coalition, which through a workstation at the
            SOC shares incident and traveler information to member agencies
            along the Corridor.

          A variety of other tools are used to facilitate incident management.
            These include portable arrow boards, portable variable message
            signs, and portable travelers advisory radio transmitters for traffic
            management; front end loaders, tow rigs and push bumpers to
            move vehicles; and training exercises to maintain a high
            competency level for teams working under hazardous conditions.

(3)   Traveler Information: CHART provides real-time information concerning
      travel conditions on the main roads in the primary coverage area.
      Traveler information focuses on planned or accidental traffic disruptions,
      such as accidents, chemical spills, snow, ice, floods, major special events,
      seasonal recreational peaks, and roadway construction. CHART uses
      several ways to disseminate traveler information, including:

          Variable Message Signs (VMS), which are programmable message
            boards (permanent and portable) capable of displaying real time
            traffic information to motorists. There are currently 35 permanent
            and nearly 100 portable units.

          Travelers Advisory Radio (TAR) stations which are low power radio
            stations that provide information on traffic conditions and special




                                  3
            events.   There are currently 30 permanent stations 10 portable
            units.

          Commercial radio and television broadcasts - by providing accurate
            and timely information to commercial broadcasters, CHART
            reaches a wide audience of listeners and viewers.

          Travelers Advisory Telephone (TAT) is currently used seasonally
            for both summer beach traffic and winter storm management and is
            in the planning phase for possible broader application.

(4)   Communications: The communications network is the glue that connects
      CHART’s functional components together. As a whole, these components
      collect, process and disseminate real time information concerning the
      transportation system. The success of CHART relies on accurate and
      timely information and therefore requires a sophisticated information
      system and communications network that is continually functioning and
      highly accurate.

      Like the CHART program, the communications network has grown from a
      grass-roots effort, pieced together from different areas within MDSHA.
      And as the CHART program grows so will the underlying communications
      network. As is common practice in the private sector, such a network
      should be designed and built cost-effectively, but with an eye to other
      potential users. MDOT recognizes that the State may be able to
      capitalize on a rare opportunity: the beginnings of a statewide network for
      all agencies. To this end, MDOT has and will continue to work with the
      Department of Budget and Management’s Office of Information
      Technology (DBM OIT) in developing the best network solution for the
      MDOT as well as the State.

      In addition to working with other agencies to share technology resources,
      MDOT has also worked with the private sector in pursuing mutually
      beneficial resource sharing opportunities.      In cooperation with the
      Department of General Services Telecommunications Office (now under
      the Department of Budget and Management’s Office of Information
      Technology), MDOT has pursued and succeeded in opportunities to
      obtain bandwidth capacity in exchange for right-of-way access. To date,
      the State has obtained approximately 75 miles of fiber optics in a shared
      resource initiative. The remainder of CHART’s communications network
      is leased.

(5)   Traffic Management: The CHART system strives to manage freeway
      and arterial traffic flows with the goal of greater efficiency and safety.



                                  4
             When freeways and other primary routes are unexpectedly congested,
             some traffic will shift to surface arterial. Arterial signal systems are being
             installed statewide to provide remote and adaptive traffic signal control
             and coordinated signal timing. Traffic signal technicians and CHART
             system operators can better balance demand and capacity by adjusting
             traffic signal timing remotely.

CHART Primary Coverage Area

The CHART program has its roots in early efforts that began in FY 1987 to improve
summer peak travel to and from Maryland’s Eastern Shore (an initiative known as
Reach the Beach). A second initiative started in FY 1988 which involved a joint effort
with the State of Virginia to focus on clearing incidents more rapidly on the Capital
Beltway. The lessons learned provided the basis for MDSHA, MdTA, and MSP to begin
applying these same principles to the state as a whole with emphasis on the
Washington, Baltimore, Annapolis, and Frederick transportation grid starting in FY
1990. CHART now focuses on approximately 375 miles of Interstate highways, and
170 miles of State Highway arterial in this area. The scope of the CHART primary
coverage area will be evaluated with each update of the Business Plan to ensure that
CHART responds to the changing needs of the traveling public.

Operations/Communications Facilities

CHART currently operates as a hub and satellite system design with the SOC located in
the center of the primary coverage area (immediately south of BWI Airport) supported
by localized Traffic Operation Centers (TOC’s). The SOC combines CHART’s traffic
management functions with MDSHA’s emergency management and regular
maintenance communications, and is the nation’s first integrated statewide operations
center. The SOC can function as a Traffic Operations Center for the primary CHART
coverage area simultaneously monitoring weather sensors, speed monitors, CCTV,
TAR, VMS, and adaptive control traffic signal systems deployed throughout the state,
24 hours a day, 7 days a week. The more localized TOC’s operate from 5 AM to 9 PM
focusing primarily on peak traffic periods, rapid clearing of incidents, and providing
traveler information on conditions along major highways. TOC’s operate during
weekdays from MSP barracks in the Baltimore and Washington areas and from
Montgomery County’s Transportation Management Center. The MdTA’s Authority
Operations Center operates continuously, and also serves as a CHART TOC, among
its other functions. On a seasonal basis, a TOC is activated in western Maryland at
MDSHA’s District office to handle winter weather conditions in the mountains. Another
TOC is activated seasonally on weekends at the MdTA Bay Bridge for Reach the Beach
traffic.




                                          5
Current Network CHART Proof Of Concept (CPOC):

In the recently published PBFI/CSC CHART Telecommunications Analysis Summary
Report, the highest cost component for CHART communications was attributed to traffic
monitoring and use of CCTV to validate incidents. One of the recommendations
included in the report was that significant CHART operational cost savings could be
realized by implementing distributed management of traffic monitoring devices and
video distribution to CHART traffic management authorities. The basis for the cost
savings was a significant reduction in circuit mileage charges by connecting devices
and CCTV cameras to the closest SHA facility, preprocessing device data at the SHA
facility to minimize CHART network congestion, and only transporting video to the SOC
that is needed there at any one time.
A primary purpose of this project is to develop an Asynchronous Transfer Mode (ATM)
Video Control Manager (AVCM), a prototype Field Management Station (FMS) for
distributed polling of speed detectors, and an Interim Operational Telecommunications
Capability (IOTC) to validate and implement these recommendations. An initial ATM
network will be installed on an existing State SONET network which will include the
Greenbelt District Office near Washington D.C., the Brooklandville District Office near
Baltimore, MD, and the SOC as nodes. This network will support the eight new
cameras which are being installed as part of the Jack Kent Cooke Memorial Stadium
project. It will also support the 26` existing CHART cameras, the two MD2-US50
cameras, and the four CCTV Project 4 cameras which are already installed in the field.
This initial network will be in-place near the end of 1997. In addition, support will be
provided for the ongoing planning and deployment of the interim CHART/SHA
telecommunications network and field devices designated as "high priority"
implementations in the recently completed CHART Strategic Plan. The PBFI Team
performing this work consists of PB Farradyne Inc., Computer Sciences Corporation,
Whitney Bailey Cox & Magnani, InfoPro, Inc., and Information Systems &
Communications, Inc. Proof-of-concept capability will be implemented in a way which
will allow efficient migration to the operational CHART system, interface to the interim
telecommunications/data network, and is intended to be a building block towards a fully
distributed CHART system.

Performance and Functional Specifications for the CHART System. The following
requirements are the performance and functional based specifications that the CHART
Systems Team would like to see. The State offers these to give a general idea of
where the program would like to go, however the State expects the consultants to
modify these requirements where called for by good systems design principles or life
cycle costs impacts. These modifications would need to be justified in writing.

Map, General:

The mapping subsystem shall be designed to be the navigation page in use by the
operator most of the time and will be able to launch all necessary subsystems as
needed . Speed and ease of use are the key elements, no screen should take longer
than 3 seconds to update / redraw. Icons / Map Display:


                                         6
The map shall graphically display (either by color or GUI change) system status,
allowing the user at a glance to see device status for (VMSs, CCTVs, TARs, SHAZAM
Signs, Traffic Signals, Detectors and Pavement Sensors. The graphical status will
include off-line (set to off by system operator), communications failed (communications
lost over a preset period of time) hardware failed (hardware failure at field equipment),
VMS online - no message (default configuration), VMS online - (with predefined or
scheduled message), VMS online (incident message), VMS online (incident message -
preview mode, TAR online - NOAA Weather broadcast message (default configuration),
TAR online - (with predefined or scheduled message), TAR online (incident message)
or TAR online (incident message - preview mode.) By clicking the mouse in a
predefined way on the above icons will pop up a window displaying Equipment ID,
operational status, current message (if appropriate) and current center responsible for
the current message (if appropriate.)

The map shall also graphically display the following information accessed from other
MDSHA existing systems:
      Road Closure Status (EORS)
             Roadwork Icon displayed at location sent to incident subsystem by
               EORS
      Pavement Sensor Data (Scan Pavement Sensors)
             GUI showing pavement temperature by range predefined on existing
               SSI system (green = dry, blue = some moisture, yellow = chemically
               wet or snow and ice watch, red = snow and ice warning and black =
               old data) and site identification tag.1 Clicking on this GUI will bring up
               identical GUI on SSI system showing details (pavement temperature,
               pavement status, chemical percentage, freeze point, ice percentage,
               subsurface temperature, wind speed, wind direction, average wind
               speed, relative humidity, maximum wind direction, minimum wind
               direction, gusting wind speed, precipitation identification, precipitation
               rate per hour, precipitation intensity, precipitation accumulation,
               visibility.) The preceding data only displays if selected on a global
               selection menu for SSI data.
      Information Exchange Network (IEN) I-95 Corridor Coalition
             Incident Icon displayed at location sent to incident subsystem by IEN
             Clicking in the above GUI will display a movable and resizable window
               containing:
                    location
                    text description
                    lanes closed
                    start time

1
  In this specification, specific colors are identified for various types of displays. This requirement reflects the
State’s current thinking on the use of colors to represent various equipment and roadway states. However, as a
general requirement, it shall be possible for the user to modify these colors without requiring recompilation or
reloading of the system.


                                                          7
                    button to allow user to bring up full incident report
        Maryland Weather Information (Weather for Windows)
             Overlay radar image over CHART map

A method shall be provided for the user to filter the map displays to only show the
desired information (e.g. show any combination of VMSs, CCTVs, TARs, SHAZAM
Signs, Traffic Signals, Road Closures, Weather Related Road Closures, Detectors,
Vehicles (AVL), Pavement Sensors, Incidents.) Layers must be customizable in all map
views. All other field equipment and system user interfaces must be accessible from
the map by clicking the mouse in a predefined way on the appropriate above mentioned
icons on the map. This will bring up a menu next to the icon on the map that will allow
the launching of the device specific portion of CHART for the detailed, complete
operation of the device.

A single click on any defined object (link or icon) shall select it, highlighting the object as
a visible indication of the selection and displaying the ID next to the object. Double
clicking will query the last known system status of the object (e.g. does not poll the
object) and will display a text description in a window on the map that will update
automatically in accordance with the system’s normal poll cycle. The description shall
include:

        VMS -
             ID
             Location (closest mile marker, exit, etc.)
             Current Message
             status
             owner
             button allowing polling of the device to collect updated status as
                defined above

        CCTV -
             ID
             Location (closest mile marker, exit, etc.)
             status
             owner

        Lane level link (detector) -
              ID
              status
              speed (graphical and numeric)
              volume (numeric)
              occupancy (numeric)
              Date and time of last update
              FPU Assigned



                                             8
       Multi-lane level link (detector) -
             ID
             status
             speed (graphical and numeric) for all lanes monitored by detector
             volume for all lanes monitored by detector
             occupancy for all lanes monitored by detector
             Date and time of last update

       Field Processing Unit (FPU) -
              ID
              Location (closest mile marker, exit, etc.)
              status
              detectors assigned

The status that appears shall be attached to the icon selected and shall be repositioned
as the map is panned or zoomed. These attached windows will remain on top as other
windows are selected. The user shall have the ability to manually move these windows
with them reanchoring where they are dropped. Up to 64 individual status windows
may be activated at any one time.

Up to 8 independent map processes may be run concurrently on any one workstation.

The map will be rendered from the MDSHA GIS database and must be able to be
updated using the MDSHA GIS Section Database which is provided in an Arcview 3.x
and greater compatible format. All map builder interfaces shall be designed so that a
user with minimal computer experience can graphically alter/update any information on
the map, to include adding, defining and deleting devices and intelligent lanes. The
administrator shall be able to relocate a previously defined device icon and anchor it to
a new geographic location with all required database operations being made
automatically. The map shall also include “Polygon Event Icons” representing important
landmarks of the map such as Camden Yards, or the Bay Bridge. Clicking on the icon
will call up a window containing a list of preset action plans for field equipment and
allow for preview and activation. From the imported data the system shall take a user
defined area (e.g. I-95 DE to VA) and create an intelligent link model from the GIS
database auto-numbering each link. Link lengths shall vary between 100 feet and 10
miles, and shall be identified in the database as both alpha and numeric, listing Route /
direction / milepost (e.g. I-095N123.25) allowing the device to be acknowledged by the
auto scenario builder as a useable device. Map must also support “free roaming icons”
for CHART’S AVL System. The above mentioned map modification tools are designed
to be easy to use, intuitive, completely graphical off-line applications, but must be able
to be integrated with the operational system with a minimum of impact and must not
require a complete system shutdown.




                                          9
      Map, Zoom levels:

      The map shall allow for rubber band zooming and the following equipment must
      show up at predefinable levels. It shall be possible for the user to alter the
      predefined zoom levels without requiring any program recompilation, and without
      a need to discontinue system operation.
    The highest zoom level shall show the I-95 Corridor showing state boundaries,
      state names and major metropolitan areas, interstate freeways and major
      arteries with appropriate roadway shields and names. This map will have to be
      developed for MDSHA and will use the same data format and the same
      graphical map editors developed for the MDSHA GIS data as described above.
           must show imported weather radar / satellite data
           shall be able to display all defined incident icons
           shall be able to display all available weather/pavement sensor data in the
             coalition
    The next level shall show the State of Md. and adjacent States (Pennsylvania,
      Delaware, Virginia and West Virginia), showing all interstates, county lines and
      Major cities.
       This map will use the same data format and the same graphical map editors
          developed for the MDSHA GIS data as described above
    The Maryland statewide view will be the default view and will be drawn from the
      MDSHA GIS database and will be resizable from a full view of the state down to
      individual road view.
       All items listed under Icons / Map Display will be definable using the
          graphical map editor to be automatically displayed up to and including a
          defined layer.
           The last view, declutter option and equipment status windows selected by
             the user will be able to be saved and used as the default view when the
             user logs back in. The user will be able to restore to system default at
             anytime during his session.

Reports General:

The Reports Subsystem is a standalone, off-line process that will present predefined
system information upon user request in a printed report format. All system information
from the Operations Logger as well as application generated information shall be
captured by the Archive Subsystem and will be transferred to an archiving SQL
compliant database residing on the MDSHA Enterprise network. Reports shall be
generated using Microsoft Office 95 and will contain standard reports that are already
formatted and allow for new reports to be run or created from queries. The systems
integrator shall define the manner in which new reports can be created.

The reports subsystem shall work with and allow access from the MDSHA Enterprise
Network for personnel with appropriate rights. All reports must be printable from each
workstation.



                                        10
      Reports Requirements (predefined reports):

    Incident Report, A user shall be able to view and print a report for a specific
      incident. A search tool will be provided to aid the user in finding a specific
      incident. The incident report shall be contain the following information:
           Report # - from Incident Handler
           Location - from Incident Handler
           Qualifier - from Incident Handler
           Type Incident - from Incident Handler
           Lane Affected, worst case from report - from Incident Handler
           Source - from Incident Handler
           Time opened - time recorded from when incident was declared
           Time 1 incident responder arrived - from Incident Handler
                      st

           Time incident closed - time recorded from when incident closed
           Total duration - calculated from time opened and closed
           Weather information - taken from operational scan pavement site
              automatically if within preset distance of incident.
           Chronological history of incident - from details entry window in incident
              handler.
                   including all device actions and messages.
                   Including all communications logs referenced the incident.
    Device Report, a search tool shall be provided to allow for searches based on a
      device or devices for a specific time period. The report shall show all user
      activity and system activity for the specified time period.
    Device Usage Report, A user with appropriate system rights shall be able to
      generate a spread sheet type report showing selected devices and what each
      was used for. For example, Device 508 was used in the specified time period for
      accident messages 100 times and roadwork messages 300 times. A pie graph
      with this information shall also be available.
    System Health report, A user with appropriate system rights shall be able to
      generate a report showing the failures and operational alarms for each selected
      device for a specified time period. The report shall include failure type and down
      time for each failure. A total percent downtime figure shall also be included for
      each device for the specified time period.
    User Report, A user with appropriate system rights shall be able to generate a
      report for all activities associated with a user for a specified time period.
    Operation Center Report, A user with appropriate system rights shall be able to
      generate a summary report for all activities associated with a specified
      operations center for a specific time period. The report shall include all activities
      that originated from the specified operations center.

Administrative General:

The Administrative subsystem will be a Graphical User Interface that will generally be
limited to the System Administrator who will be required to perform general


                                          11
housekeeping functions such as setting up and maintaining user accounts and system
parameters.

       Administrative Requirements:

    System Administrator must be able to create new users
           Assign users to access levels
           Be able to define users access levels by allowing or disallowing access to
              subsystems
    Set screen colors and default views
    Define and divide the State into user responsibility zones. As a user logs in they
      will log into a particular geographical zone. All devices within the zone shall
      indicate any alarms (both equipment distress as well as detection or) to the
      operator responsible for that area. A user may be assigned new or additional
      zones during his shift by a user with the appropriate administrative privileges.
           Equipment/incident responsibility reminders shall be configurable by the
              use change the frequency of the alarm. The System Administrator shall
              be able to configure a default as well as a maximum allowed sleep time to
              be enforced system-wide.
           A user in any zone may view information related to any equipment or
              incident in any zone.
    Set detection sub-system alarm configuration
    System Admin. can immediately query all devices for health
    System Admin. can set Metric or English as unit of measure for system
    System Admin. can schedule specific reports to run at specified times.
    System Admin. can kill processes controlling subsystems at local workstations
      without affecting subsystem on other local workstations
    System Admin. can deliver software upgrades on local workstations on WAN
      from a central delivery point
    Start and stop individual subsystems remotely
    System Admin. can configure who to be notified of failures by System Controller.
      Different failures may be sent to different technicians or be held on a log file for
      the next work day.
    System administrator shall be able to define responsibility zones and system
      access rights on a time-of-day basis.

System Controller, General:

The System Controller shall be the central point through which all subsystems report.
The System Controller shall poll each sub-system or connection to legacy systems for
process health. All failures shall be written out to a log, notify a designated operator at
the SOC and page out to the system administrator or designee using the existing
paging system. System Controller shall arbitrate control of devices and notify a
designated operator at the SOC when conflicts occur, showing him the current
message and conflicting message and allowing him to choose the correct message. A



                                          12
management tool shall be provided to allow the manager to shift these responsibilities
from user to user if necessary. System Controller shall arbitrate user responsibilities
while logged in and will transfer responsibilities to another user both automatically in
case of shift change and manually by an appropriate manager if desired. All field
equipment that is monitored for status will generate a visual and audible alarm when the
equipment reports an error during a poll. Equipment errors that require field
maintenance will have the capability of being written automatically to the CHART
maintenance reporting system.

Device Control General:

The Device Control Subsystem must be able to control all devices defined in the current
CHART System and also the MdTA’s control systems with at a minimum the same
functionality as the current systems. Software must be designed to allow for expansion
of up to 10,000 devices and 100 protocols. All user commands and relevant internal
processes such as error messages must be recorded in the system log. All GUI’s must
be updated dynamically from information received from the field devices when new
information is received from the device. Device Control shall include a scheduling
function that can activate individual devices or plans of multiple devices for a set time of
day, day of week, week of month, month of year, or indefinite. A confirm option must
exist so that some schedules can be set up and go out automatically without user
notification while some must be user confirmed prior to activation by any user at a
specified operations center. System shall have a custom dictionary of words for
messages. Users without full editing rights will only be able to use these previously
defined words. All functions of device control must be accessible via map GUI, pull
down menus and right mouse click pop-up menus in each device type control module.

       Requirements VMS :

    Must be able to blank (return to normal) all highlighted devices
           Must allow for multiple devices to be blanked at the same time.
           Blanking a sign will 1st check the state of the sign prior to its last activation
             and if other than a scheduled message or blank, will prompt the user if the
             last message should be resent to the device (showing the user the details
             of the last message). 2nd will look to scheduler and display any scheduled
             message due to be up on the device. 3rd will send a blank to the device.
    Provide messages libraries to store messages, by geometric sign type
    A quick message function for all devices must allow for non-library messages to
      be sent to a device provided the user has the appropriate authority
    Includes a plan function that can activate any number of different device types
      with pre-stored library messages. Plans will activate in a hierarchical fashion,
      sending messages to TARs and VMS not associated with TAR, once TARs are
      activated then any device such as a SHAZAM, VMS, or Drum sign associated
      with a TAR will be activated.
    System uses parameters from the Incident Handler Subsystem to create VMS
      messages and activate stored messages.


                                           13
    All message libraries shall be organized numerically

      Requirements TAR & SHAZAM:

    Must be able to blank (return to normal) all highlighted devices
           Must allow for multiple devices to blanked at the same time.
           Blanking a sign will 1st check the state of the TAR prior to its last activation
             and if other than a scheduled message or blank, will prompt the user if the
             last message should be resent to the device (showing the user the details
             of the last message). 2nd will look to scheduler and display any scheduled
             message due to be up on the device. 3 rd will send a blank (TAR controller
             message 2) to the device.
    Provide messages libraries to store TAR messages
    A quick message function for all devices must allow for non-library messages to
      be sent to a device provided the user has the appropriate authority
    Includes a plan function that can activate any number of different device types
      with pre-stored library messages. Plans will activate in a hierarchical fashion,
      sending messages to TARs and VMS not associated with TAR, once TARs are
      activated then any device such as a SHAZAM, VMS, or Drum sign associated
      with a TAR can be activated.
    System uses parameters set in Incident Handler subsystem to create “computer
      voice” TAR messages utilizing latest text to voice technologies.
    SHAZAM devices are attached to a specific TAR
           SHAZAMs are always turned on after the TAR message is sent
           SHAZAMs are always turned off before the TAR message is blanked
    System must be able to program at a minimum 4 TARs simultaneously

Camera Control, General:

The Camera Control Module shall provide a means to control MDSHA’s CCTV
Cameras. The module shall also be the interface to manipulate all other video related
resources graphically. In terms of the present CHART System, it must provide the
same functionality as the AMX Touch Screen currently at the SOC. Camera control
module must be usable from all operator workstations. When a user has accessed
control for a camera, all other users that request that camera will see an icon on the
CCTV GUI that will identify the fact that they will get a “view-only” image. Any user will
be able to graphically determine the current controllers of any camera. A designated
security level at the owning agency for the CCTV shall be able to release control of any
camera being used by a lower security level. Control of the camera shall be able to be
relinquished without relinquishing the image when the user is finished manipulating the
device to allow another user to control the camera. The new CHART network will
include a way to arbitrate selection of CCTV images through SNMP commands to the
nearest ATM switch. This SNMP control module is being built with the fact in mind that
a final centralized GUI CHART control process will be built to manage it. It will be in-
place by early 1998.



                                           14
Camera Control, Requirements:
        
         Must provide a graphical interface at each operator workstation to control
           the following.
               Provide means to select a camera for control.
                       Provide means to Pan / Tilt / Zoom
                       Provide means to control pre-set locations for each camera
                       Provide means to store and program pre-sets remotely
                       Provide means to program text for each preset that will be
                          displayed on a camera.
                       Provide means to identify owner (user) of a camera
                       Provide means to release camera being used by lower
                          security level
               Provide means to select a camera for view-only
               5 Electrohome Marquee 2000 Projection Units at SOC.
                       Power on / off all selected units
                       Standby on / off all selected units
                       Route an NTSC or RGB signal to selected unit
               16 Electrohome Marquee 900 Projectors (wall) at SOC.
                       Power on / off all selected units
                       Standby on / off all selected units
                       Route up to any combination of 4 individual NTSC or RGB
                          signals or a single image of either type through Synalac to
                          be displayed on wall.
               Various other NTSC/RGB monitors at other locations linked by the
                   CHART ATM network
               Mitsubishi RGB Printer at SOC.
                       Route an RGB signal to be printed.
               4 Panasonic Time Lapse VCRs.
                       Route an NTSC signal to selected VCR.
                       Control all recording and playback functions.
                              Record
                              Play
                              Fast Forward
                              Fast Forward Scan
                              Rewind
                              Rewind Scan
                              Select Record speed
                              Select Time Lapse
                              Pause
                              Stop
               12 Panasonic 21” monitors at SOC.
                       Route an NTSC signal to selected Monitor
               12 Panasonic 9” monitors at SOC.


                                       15
                        Route an NTSC signal to selected Monitor
                        As the Incident Handler defines a specific camera to an
                          incident, automatically display the camera on the user’s 1 st
                          available local monitor.
                  2 Panasonic Monitors at each TOC / AOC
                        Route an NTSC signal to selected Monitor
                        As the Incident Handler defines a specific camera to an
                          incident, automatically display the camera on the user’s 1 st
                          available local monitor.
            Provide a means for a user with the appropriate system rights to control
              the NTSC routes directly.

Operations Logger General:

The Operations Logger Subsystem is to record an operations log including all manually
input user information and all system information relevant to a user. The user should
have full access to all past information logged by the system and be able to filter for
the type of information to be written out to the screen. The quantity of historical log
data maintained by the system shall be determined by the system’s mass storage
capacity. The operator shall be alerted when 80% of the available capacity has been
utilized to permit the operator to copy the log information to another media. In the event
that the mass storage device approaches a dangerous lack of capacity a scheme shall
be implemented to prevent system malfunction (e.g. automatic backup or auto delete of
oldest data in worst case.) All information generated from the Operations Logger
subsystem are dynamically updated to the Reports and Archive modules when
requested by them or upon logout.

        Operations Logger Requirements:

      Allows user to input and save an operations log via keyboard
      Automatically captures relevant systems information that apply to operator
      Each entry shall display the date, time, source, and details.
      Allows user to filter display to show only events entered by their own ID
      Allows user to filter display to show all system generated events (incident alarms,
        equipment alarms, login, etc.)
      Allows for searches for specific information within a 48 hour time period
      Allows user access to information for 48 hours from current time
      Allows user to associate a log entered with a specific incident report
      Each entry shall allow up to 256 characters, Any log exceeding 256 characters
        will be saved to a separate log entry
      Allows user to print a report based on filter used




                                           16
Incident Handler, General:

The incident handler subsystem will be the tool operators use to input and manage
incident data. The incident handler must process and present information from both the
user and automated sources. Through a series of entry boxes / questions, users shall
define parameters that will allow the incident handler to make suggestions for VMS and
TAR messages to be activated. Guidelines for the system to use to make VMS and
TAR messages have been developed by MDSHA and are below.

      Incident Handler, Requirements:

    As speed detector alarms are acknowledged by users, the incident handler will
      activate.
    An input screen containing text entry / pick list boxes for all necessary
      information concerning an incident.
    The system must store all submitted incidents for historical data.
    Defined incidents will be located on an attributed map base with icon by user or
      automatically by a system utilizing highway inventory data attributes and/or street
      locator functions.
    Incident Handler will distribute submitted incident data to other systems for
      dissemination, e.g. VMS, TAR, paging, faxing or E-mail as well as to the
      Northern Virginia Traffic Management System (NOVA.) Incidents in Virginia will
      be automatically displayed on the CHART map and will be able to have the
      details pulled up as an incident.
    Once an incident is located on the map, the closest camera within 2 miles shall
      automatically be activated to the users local monitor. If the camera is under
      control by another user, the operator submitting the report shall be notified as to
      who has control (see camera subsystem).
    Once an incident is closed, all attached devices shall be returned to their
      previous state and notification shall be made to all dissemination sources such
      as paging, faxing, E-mail, WWW server.

Incident Scenario Automation:

The below recommendations are meant to speed operator response and message
accuracy when an incident is detected. Currently, a Freeway Incident Traffic
Management (FITM) plan is jointly developed by multiple agencies within MDSHA that
details alternate routing and signing necessary if a major shutdown of the Interstate
system is required. This book has been automated and entered into CHART in a
graphical fashion and should be modified to be included in the new Incident Scenario
Automation. Once basic information on an incident is defined in a report format, a
response screen shall pop-up listing all applicable devices ordered from near to far from
the incident. Message content will then be suggested. The operator will be able to
review the suggested response in a preview mode graphically on his map and will hear
the TAR messages at his workstation and, depending upon the operators system rights,
edit the messages to better fit the situation and execute the response. It is our


                                         17
expectation that the suggested message will be utilized most of the time. Other devices
that were not suggested could also be added into the plan at this point by clicking on
non-participating equipment on the map in a particular way. This will launch the
appropriate field equipment subsystem to allow programming the equipment and adding
them to the scenario. As the incident progresses and information is updated (lane
closure changes, etc.) in the incident report, the changes will also take place on the
devices activated. This system will accommodate incident, roadwork, and congestion
messages. Other more specific messages such as plans for Camden Yards or the
tunnels can be accessed from icons on the map.

Auto Incident Basic Flow Diagram:
   Incident is Reported
      and verif ied by
         Operator




     Incident Report                   Incident report updated
        Submitted                         to ref lect changes




      System uses
   predef ined rules f or
      building TA R /
     V MS messages




  Operator review s plan
     and acitvates




   Incident Finished /
 report closed / devices
         blanked




Information Sources:
      An incident report form will be the starting point for the device automation.
      Information such as location, description, and lanes affected will be defined by
      an operator. That information will be processed through rules to allow the system
      to make device and message selections.
               Location will be derived by the operator plotting a point on the map or
                 will be passed from the detection subsystem.
               The primary method for device control shall start from an incident
                 report


                                         18
Location Rules:
              The mapping system shall base all device selections from distance
                away from the plotted incident location.
              Mapping system must be able to suggest devices on routes other than
                the route the incident is plotted on.

Distance Rules:
      VMS
                100% blockage use VMS for 30 miles back
                75% blockage use VMS for 25 miles back
                50% blockage use VMS for 20 miles back
                25% blockage use VMS for 15 miles back
                Accident activity on shoulder use VMS for 2 miles back
                Roadwork activity on shoulder no VMS usage

      TAR
                100% blockage use TAR for 50 miles back
                75% blockage use TAR for 45 miles back
                50% blockage use TAR for 30 miles back
                25% blockage use TAR for 20 miles back
                No message for incidents or roadwork with no lanes blocked as rule

VMS Rules:
       The basis of VMS rules are the following questions: what it is, where it is, and
what to do. The operators’ incident report form shall have a pick list for “type” of
incident. These choices shall include disabled vehicle in travel portion, Hazmat
incident, or Accident with injuries. As far as the question “What it is” is concerned for
building VMS messages the word “Accident” shall be used to describe all roadway
blockages other than roadwork. The group felt that most motorists identify with the
word accident. No suggested message shall be more than 2 phases.

      What it is:
             ACCIDENT
             ROADWORK
             EXPECT DELAYS

      Where it is:
            The word “AHEAD” when used alone shall refer to incidents less than
                1 mile from the device.
            Mileage and the word AHEAD shall be used if no exits are between
                the device and the incident. Provided the device and the incident is on
                the same route. For example “5 MILES AHEAD”




                                          19
              For incidents on the same route as the device and have an exit in
                proximity to the incident use “AT, PRIOR, PAST - Ex. # - MD, I, US -
                #”.
                     If no route number use name.
                     Unless above, do not use route name.
              For incidents on a different route than the device use “MD, I, US - # -
                direction - AT, PRIOR, PAST - EX. # - MD, I, US #”.
                     If no route number use name.
                     Unless above, do not use name.

      What to do:
              If specific lane information is unknown then use “STAY ALERT”
              If the incident is on a different route than the device use “STAY
                 ALERT”
                     Exception - If incident is on a different route than the device and
                        all lanes are closed use “CONSIDER ALT. ROUTE”.
             If a VMS has been defined in the system as in range of a TAR device,
                a half SHAZAM sign will be placed on the VMS structure. The half
                SHAZAM will inform motorists to tune radio to the TAR for travel
                information. As a rule if the message is one page display “TUNE
                RADIO (frequency) AM” on page two after the TAR has been
                successfully programmed.
                     If message is already 2 pages, do not display “TUNE RADIO”
                        text (rely on half SHAZAM).
                     Anytime a VMS is to display a message reading “TUNE RADIO”
                        the system shall program the TAR first before activating the
                        VMS.
              Do not acknowledge shoulder use for incidents on VMS, as a rule.
              Format for when specific lane information is given: “USE - RT., LF.,
                 Center, # RT., # LF., # CENTER - LANE, LANES”.
              If incident has all lanes closed, and their is not an exit between the
                 VMS and the incident use “ALL LANES CLOSED”.
              If incident has all lanes closed, and their is an exit between the VMS
                 and the incident add “CONSIDER ALT ROUTE” to message.
              No activation of VMS for shoulder work.
              Use VMS for accidents with no lanes blocked within 2 miles of device.
                 Message to read “STAY ALERT”.

Message Text Priority and Positioning:

CHART currently has signs with displays of 3x8, 3x10, 3x18, 3x20 and 3x21. Due to
the variety of sign widths the following text priority rules have been established. After
an incident is declared the system should first decide which signs meet the distance
criteria then build messages to fit each device type. Recommended messages have
been developed based on the manner in which motorists read these signs. Thus a



                                         20
philosophy has been developed in which complete thoughts are grouped together as
much as possible. For example, a line reading “I 695 W PRIOR EX 7 MD 295” conveys
a compete location and is easy to comprehend, unfortunately the above line exceeds
the capabilities of existing devices To that end, messages need to be broken up at
specific spots such as between the direction and specific location. To simply display
the text line by line as allowed by device size would be not understandable at road
speeds.

      Text Priority:
             Required - ACCIDENT, ROADWORK, or EXPECT DELAYS.
             Required only if incident is on different route than device - Route Type
                of Rte. Incident is located on. (MD, I, US)
             Required only if incident is on different Route than device - Route # of
                Rte. Incident is located on.
             Required only if incident is on different Route than device - direction (
                N, S, E, W).
             Not Required - AT, Prior, Past (higher priority than exit #)
                      “AT” may (not required) be substituted for “PAST or PRIOR” or
                        signs less than 10 characters wide if the first choice will not fit.
             Not Required - Exit # (exit closest to incident).
             Required - Route Type of route closest to incident.
             Required - Route Number of route closest to incident.
             Not Required - What to Do statements as listed above.
             Not Required - Route name

      Text Positioning:
             All lines shall be centered
             Any phase with one line of text shall be displayed on the center line.
             Any phase with two lines of text shall have that text displayed on lines
               one and three.
             The phrase “Expect Delays” may be broken up between two lines.
             Route Types and Route Numbers may not be broken up.
             Directions containing the Route the incident is located and the direction
               may be broken up as shown in the below example (after the direction).
             The phrase “Stay Alert” may be broken up between two lines.


The following examples are provided to show how these guidelines can be used for
various sign types. The 1st example is to warn of delays on a different route than the
device is located on. The second example is for an accident on a different route than
the device with all lanes blocked.




                                          21
                   E   X   P   E   C   T       D   E    L       A       Y       S

                           I       6   9   5       W

         P    R    I   O   R       E   X       7        M       D               2       9       5

             3 x 21 Sign


                       S   T   A   Y       A   L   E    R       T




              E    X   P   E   C   T       D   E   L    A       Y       S

                       I       6   9   5       W

    P    R     I   O   R       E   X       7       M    D               2       9       5

             3 x 20 Sign


                       S   T   A   Y       A   L   E    R       T




         E    X    P   E   C   T       D   E   L   A    Y       S

                       I       6   9   5       W

P   R    I    O    R       E   X       7       M   D            2       9       5

             3 x 18 Sign


                   S   T   A   Y       A   L   E   R    T




         E    X    P   E   C   T                            E       X       P       E       C       T

         D    E    L   A   Y   S                            D       E       L       A       Y       S

         I         6   9   5       W                        I               6       9       5           W


        3 x 10 Sign                                         3 x 8 Sign
A   T         M    D       2   9   5                        P       R       I       O       R



S   T    A    Y        A   L   E   R   T                    M       D               2       9       5




                                                       22
                          A    C   C   I   D   E   N       T

                               I       9   5       S

         P    A   S   T        E   X       4   3           M       D               1       0       0

             3 x 21 Sign


         C    O   N   S    I   D   E   R       A   L       T               R       O       U       T       E




                          A    C   C   I   D   E   N       T

                               I       9   5       S

    P    A    S   T       E    X       4   3       M       D               1       0       0

             3 x 20 Sign


    C   O     N   S   I   D    E   R       A   L   T               R       O       U       T       E




                      A   C    C   I   D   E   N   T

                           I       9   5       S

P   A    S    T       E   X        4   3       M   D               1       0       0

             3 x 18 Sign


C   O    N    S   I   D   E    R       A   L   T           R       O       U       T       E




    A    C    C   I   D   E    N   T                   A       C       C       I       D       E       N       T

         I        9   5        S                               I               9       5               S

A   T         M   D       1    0   0                           M       D               1       0       0


        3 x 10 Sign                                            3 x 8 Sign
    C   O     S   I   D   E    R                       C       O       N       S       I       D       E       R

                                                                       A       L       T

A   L    T        R   O   U    T   E                           R       O       U       T       E




                                                       23
      Beacon Usage:
            Use for all incidents within 10 miles if on same route.
            Use for all incidents with 75% blockage.

TAR Rules:

Each TAR message shall be composed of the following parts; Opening, , Condition,
Location, What to do, Closing. It is the goal set by the CHART Technical Team to have
automated TAR messages for the next CHART Software Version. As with VMS the
Incident Scenario Automation Group has defined rules that a computer could use to
build and play TAR messages.

      Opening:
             Keep generic no SOC VS TOC 3 VS AOC (operations issue).
                 For example: “THIS IS MARYLAND’S CHART PROGAM’S
                 TRAVELERS ADVISORY RADIO NETWORK WITH A TRAFFIC
                 ALERT.”

      Condition:
             Usage of one of the following, dependent upon what the operator
                chooses in the incident report.
                    “THERE IS AN ACCIDENT”
                    “THERE IS ROADWORK”
                    “THERE IS EMERGENCY ROADWORK”
                    “YOU MAY EXPECT DELAYS”

      Location:
              Location format for accident and roadwork: “ ALONG - MD, I, US -
                ROUTE # - DIRECTION - AT, PRIOR, PAST - EXIT # - MD, I, US -
                ROUTE # - ROAD NAME.
              Location format for expect delays messages: “ ALONG - MD, I, US -
                ROUTE # - DIRECTION - BETWEEN - EXIT # - MD, I, US - ROUTE #
                - ROAD NAME - AND EXIT # - MD, I, US - ROUTE # - ROAD NAME.

      What to do:
             What to do format for accident messages: “CURRENTLY THE - RT.,
               LF., CENTER, # RT., # LF., # CENTER - LANE / LANES ARE
               BLOCKED AT THIS TIME. PLEASE STAY ALERT AS YOU MOVE
               THROUGH THIS AREA”.
             What to do format for roadwork messages: “THE - RT., LF., CENTER,
               # RT., # LF., # CENTER - LANE / LANES WILL BE CLOSED
               BETWEEN THE HOURS OF ##### PM / AM ON DAY / DATE - AND
               #### PM / AM ON DAY / DATE. PLEASE STAY ALERT AS YOU
               MOVE THROUGH THIS WORKZONE”.



                                        24
                What to do format for expect delays messages: “ALL LANES ARE
                  REPORTED TO BE OPEN AT THIS TIME, PLEASE STAY ALERT AS
                  YOU MOVE THROUGH THIS AREA”.
      Closing:
             Keep generic and short, for example “THIS STATION WILL BE
               UPDATED AS CONDTIONS CHANGE. THIS IS STATION (CALL
               SIGN). THIS MESSAGE WILL BE REPEATED”.

SHAZAM Rules:

       SHAZAM signs shall be tied to a specific TAR.
       The direction the incident is reported by the operator in the report form shall
         determine which SHAZAM devices are to be activated.
       When a TAR and a SHAZAM are to be used for a plan, the TAR shall always
         be programmed first then the SHAZAM. Allowing the message to be on the
         air before advising motorists to tune in.
       When a TAR that has an activated SHAZAM sign is blanked, the SHAZAM
         device shall be turned off first.

Drum Sign Rules:

       Each Drum device shall be tied to a specific TAR.
       The direction the incident is reported by the operator in the report form shall
         determine which drum devices are to be used.
       When a TAR and a Drum are to be used, together the TAR shall always be
         programmed first then the Drum sign. Allowing the message to be on the air
         before advising motorists to tune in.
       When a TAR has a Drum device advising motorists to tune in is blanked, the
         Drum sign shall always be blanked first then the TAR.
       The Drums message shall be determined by the information submitted in the
         incident report.

Initial Detector Subsystem, Requirements:

The initial System assumes that the Field Management Station being developed by
Computer Sciences Corporation is not available by the implementation of this system
and shall be configurable through System Administration Tools to set up threshold
alarm levels by speed, volume and occupancy. The detectors in the field call a central
number once per hour or when speed falls below a preset threshold that sends artery
speed data back to the SOC over multiple T1s. New detectors going on-line in the next
few months will call the SOC directly with lane specific speed, volume and occupancy
data. The data is currently sent over the ethernet with each detector assigned to a port
on the detector server.

The updated Detection subsystem shall maintain a running average for each detector in
order to determine “normal” traffic. As information is processed it will be compared to


                                         25
the average for last 3 weeks for the same time. This average will have the capability of
discarding abnormal averages (e.g. holidays and special events) and will allow manual
inputs when desired. A user-settable percent below average shall be used as a
threshold alarm baseline for what the normal speed, occupancy or volume should be for
specific detector. As an alarm condition is identified the operator shall be notified via a
pop-up window with audio signal and flashing indicator in the window. Alarm
notification signals shall be configurable from the System Administration Tool. The
window shall identify the alarm location, threshold passed, speed, volume and
occupancy. The operator should still be able to manipulate the system without
acknowledging the alarm in order to finish any current tasks. The window should
however remain in view of the user at all times. Once acknowledged the map should
be automatically zoomed to the location from which the alarm originated, automatically
showing the details of the detector involved. The incident handler should then be
opened with a report partially complete based on the known information. The System
should also incorporate logic to avoid the initiation of alarms for delays that occur
upstream of an already active alarm with a working incident report.

Final Detector Subsystem, Requirements:

System shall be configurable through System Administration Tools to set up threshold
alarm levels by speed, volume and occupancy. The detector subsystem shall receive
data from polling PCs placed in the field. These PCs will poll the detectors at specified
intervals for artery speed and time-stamp of last reading or lane specific speed, volume,
occupancy and time-stamp of last reading depending on the type of detector. The PCs
will merge this information into a rolling average and send this average to the to the
detection subsystem for use in detecting incidents. The raw data will be stored at the
PCs until requested for archiving by the Data Archive subprocess.

The Detection subsystem shall maintain a running average for each detector in order to
determine “normal” traffic. As information is processed it will be compared to the
average for last 3 weeks for the same time. The average shall be used as a threshold
alarm baseline for what the normal speed, occupancy or volume should be for specific
detector. As an alarm condition is identified the operator shall be notified via a pop-up
window with audio signal and flashing indicator in the window. Alarm notification
signals shall be configurable from the System Administration Tool. The window shall
identify the alarm location, threshold passed, speed, volume and occupancy. The
operator should still be able to manipulate the system without acknowledging the alarm
in order to finish any current tasks. The window should however remain in view of the
user at all times. Once acknowledged the map should be automatically zoomed to the
location from which the alarm originated, automatically showing the details of the
detector involved. The incident handler should then be opened with a report partially
complete based on the known information. The System should also be intelligent
enough to not initiate alarms for delays that occur upstream of a already active alarm
with a working incident report. The system will allow for “special” days (e.g. Redskin’s
Monday night) in its average calculation of normal speeds.




                                          26
Legacy Systems Interfaces General:

It is one of the goals of this project to incorporate the vast majority of the functions of
CHART and EOC into one user interface. Several standalone systems are currently
used to support CHART. These systems include WSI Weather for Windows / Weather
Workstation, SSI Scan Software for Windows (Weather Pavement Sensors), EIS
Emergency Operations Reporting System (EORS), Econolite Traffic Signal Software,
Silverlake Airsource Pro Paging Software, Novell Groupwise e-mail, I-95 Corridor
Coalition Information Exchange Network (IEN) and Partners in Motion Independent
Service Provider (ISP). It is our intention to import and export information from each of
these systems using CHART GUIs talking to the legacy systems using APIs or other
system threads and calls to open databases where possible. Below is a breakdown of
and explanation of the functionality CHART requires to integrate from each system and
how generally the information is to be used.

      Legacy Systems Interfaces, Requirements:

      WSI, Inc. Weather for Windows / Weather Workstation:

      SHA contact:          Dave Rossbach - (410) 582-5545

      Current Usage: Weather workstation provides weather products such as:
      National Weather Service (NWS) forecasts / warning statements, local and
      national radar imagery, satellite imagery, and other graphic weather maps.
      These products are stored on server and are accessed via Weather for Windows
      software.

      Integration Goal: Information shall be imported from the server. A screen shall
      allow for viewing of forecasts and weather statements. All radar and satellite
      image loops shall be a layer of the System Map. Product driven weather based
      alarms shall be available on CHART workstation. All administration and control
      functions shall remain on the WSI workstation.

      SCAN Weather Pavement Sensors:

      SHA contact:          Dave Rossbach - (410) 582-5545

      Current Usage: MDSHA has a field deployment of approx. 45 weather stations
      with pavement sensors strategically located around the state. SOC / EOC /
      Maintenance personnel actively monitor these sensors for weather and road
      conditions, then dispatch maintenance crews accordingly. Information is
      collected by 7 servers located in the Districts that poll each site and request a
      download. The District servers then replicate the data over the enterprise
      network to the main scan server at SOC. Scan for Windows software is used by
      end user to view all sensor data. Web browser application is used to view text
      only sensor data via SHA Intranet.


                                          27
Integration Goal: Information shall be taken from the Scan server in timed
intervals. Specific site information shall be accessible from icons on the system
map. Sensor information shall be attached to each incident report from the
closest site. Information received shall be filtered for alarms to notify system
users via screen or field personnel by a page. These alarms shall be
configurable by the System Administrator. An alarm threshold may be set to a
sites operational status or weather / pavement sensor condition reported. All
Scan related administrative functions shall remain on the Scan Server.

EIS Inc. Emergency Operations Reporting System (EORS):

SHA Contact:                Dave Rossbach - (410) 582-5545

Current Usage: EIS developed client/server software for MDSHA to report and
track all information regarding resources, personnel and road conditions during
emergency operations. This data is gathered at the maintenance shop and
district offices and compiled on a statewide server at the SOC. Seven district
servers are replicated via statewide server to share information via maps and
reports to clients statewide. Currently EORS is an SQL compliant database and
Microsoft Access 7.x front end. The MDSHA roadwork closure permit process is
also being migrated to EORS. EORS has a map interface in which icons are
displayed representing roadway closure / road conditions / weather information.

Integration Goal: CHART System must take the graphical condition information
from EORS and display it as a level on the System Map. The personnel
database part of EORS called SHADE (State Highway Administration Data
Encyclopedia) must also be available from the Incident Response subsystem of
CHART.

Econolite Traffic Signal Software:

SHA Contact:                Ed Rodenhizer

Current Usage: MDSHA is using manufacture software to dial up individual signal
systems and make changes or check status. Communications between the
Signal Shop at the Hanover Complex and the SOC consists of a Novell Server.

Integration Goal: All signals shall be defined by icons on the map. Signals with
telemetry shall be identified by a different color icon. Clicking in a particular way
on a signal shall give details such as who maintains the signal and the system it
is on. During an incident if a FITM is declared in the incident handler report, any
signals attached to the FITM plan for the incident shall be contacted and a pre-
programmed emergency mode shall be enacted and the signal shop technician
on duty will be paged with all pertinent data. The operator shall have no other
control than to activate and deactivate the emergency mode.



                                    28
Silverlake Software, Airsource Pro:

SHA contact: Dale Lineweaver

Current Usage: MDSHA informs and directs both internal and external personnel
through the use of alphanumeric pagers. Each time an incident is confirmed or
conditions change approximately sixty people are advised through this medium.
Currently MDSHA has PageNet under contract as the paging provider.

Integration Goal: As the a report is submitted through the incident handler the
user shall be able to select the notification resources to use. Paging should be
one of the choices available. The groups to be paged should automatically be
determined by the geographic location of the incident. All message text should
be taken from the report automatically.        A separate tool window should be
available to allow the user to select individual personnel to send messages to.
All message sending functionality of current paging software must be available.
The paging database must reside in one location, allowing any updates to be
done at one time.

Novell Groupwise e-mail, MDSHA Enterprise Network:

SHA Contact         Steve Branagan

Current Usage: MDSHA is currently using Group Wise as its e-mail software.

Integration Goal: CHART System users should be able to have the same e-mail
capabilities as normal MDSHA personnel using PCs.

I-95 Corridor Coalition, IEN:

SHA contact:        Dale Lineweaver

Current Usage: MDSHA is a member of the I-95 Corridor Coalition, a information
sharing agency for the east coast. Operations centers from Maine to Virginia
have IEN machines that are networked through dial-up communications. Each
agency manually enters information into a form which is then distributed to all
other members. A map is also included to located incidents geographically.
Microsoft Access is the database used to support the IEN program.

Integration Goal: All operators shall have the ability to send submitted incident
reports to the IEN through the Incident Handler Software. All incoming IEN
alarms shall be graphically viewable as a level of the System map as well as
readable as a textual description of all IEN incidents.




                                  29
      Partners in Motion Independent Service Provider (ISP):

      SHA contact:         Dale Lineweaver

      Current Usage: MDSHA is a member of the Partners in Motion, a information
      sharing consortium for the Washington D.C. area. Operations centers from
      Maryland to Virginia have ISP machines that are networked through dial-up
      communications. Each agency manually enters information into a form which is
      then distributed to all other members. A map is also included to located
      incidents geographically.

      Integration Goal: All operators shall have the ability to send submitted incident
      reports to the ISP through the Incident Handler Software. All incoming ISP
      alarms shall be graphically viewable as a level of the System map as well as
      readable as a textual description of all ISP incidents.

Fax Tool, General:

From each workstation the user shall be able to send faxes, either as free form or as an
incident information worksheet. Current CHART System Group Notification Tool
consists of a PC Server, with four fax cards. Any workstation may send a fax to
multiple pre-defined destinations. The Fax Server queues all jobs to go four at a time
until done.

      Fax Tool, Requirements:

      Each fax from CHART shall automatically have a header to contain the CHART
      Logo, date, time , location (SOC, TOC3, etc.) and user sending the fax.

      A screen shall be provided to allow users to create free form faxes and send
      them to numbers not previously defined.

      System Administrator shall be able to set up groups of multiple destinations to
      allow a user to select one group name that will send the same message to all
      destinations in the group.

      System must be able to send at a minimum four faxes simultaneously.

      System Administrator shall be able to assign fax groups to geographic areas on
      the map. When a incident is submitted the users shall be able to choose fax as
      a notification method and the incident report shall automatically be sent to the
      group or groups selected for the incidents location.

      The user should receive notification when the fax is sent and when the fax is
      unsuccessful.




                                         30
      All Fax Tool activities shall be logged.

AVL / Mayday, General:

Contractor shall design and implement an AVL / Mayday System for CHART Response
Vehicles. System shall transmit speed, location and vehicle identification for each
tracked vehicle and will contain a mayday feature that allows the vehicle driver to send
a silent alarm back to the SOC. A library of up to 64 pre-programmed messages
(programmed by PC interface) will be available in an easy scroll-down selection list for
broadcast to SOC. Vehicle will also accept messages from SOC.

      AVL / Mayday, Requirements:

      System shall support 20 vehicles for initial deployment.

      System shall be able to support up to 2048 vehicles.

      The following Information shall be shown in graphical form on the system map:

             Icon showing vehicle location on system map
             Name of vehicle as a 12 point Ariel font 15 character alphanumeric
               (transponder tag + database information)
             Clicking on above icon will pop up stationary window showing:
                   Name of vehicle (as specified above) (transponder tag +
                      database information)
                   Driver (database information)
                   Mayday status (transponder tag information)
                   Last message from driver plus time of message

      Mayday activation shall alert the Team Leader via a pop up window, audio signal
      and change of icon color. Message receipt from vehicle shall alert the Team
      Leader via an audio signal with a pop up window displaying the message.

      Reports for each vehicle shall be written to the archive server and will show idle
      time and average speed for specified time periods.

Archive, General:

All logged system and application information shall be written out to a Data Archive
Server. All system program binaries, data and database will be archived to a System
Archive Platform.

      Data Archive, Requirements:

      Archive server will be an appropriately sized Pentium PC with necessary
      software to run an SQL compliant database and all necessary query software.


                                          31
      The design concept is to have all necessary information written to this database
      for up to 50 users to simultaneously access system data (e.g. user login data,
      peripheral error messages, etc.) and application information (e.g. speed counts,
      VMS messages, etc.) with a set number of graphically presented pre-defined
      queries as well as ad-hoc queries from an SQL prompt.

      Users on MDSHA Enterprise Network with appropriate rights must be able to
      access the system Archives using pre-defined queries and SQL prompt for ad-
      hoc queries and have file transfer privileges.

      All System archives shall be scheduled by System Administrator to be run
      automatically. This can be from once per hour up to once per week and will be
      controlled from a Graphical User Interface accessible from any system
      workstation but only to users with the appropriate system security level.

      System Archive Requirements:

      System shall have manual schedulable graphical capability to perform a
      complete binary system backup of all system disks. System shall automatically
      incrementally backup to storage devices as scheduled by the System
      Administrator and will be controlled from a Graphical User Interface accessible
      from any system workstation but only to users with the appropriate system
      security level.

WWW Export, General:

System shall have a GUI that allows the exporting of specified map data to the WWW
Server by users with the appropriate privileges. WWW Server shall be updated at a
minimum every two minutes.

      WWW Export, Requirements:

      All data exported shall be configurable by the System Administrator from the
      Administration Tools.

      Data to be exported shall include (as a minimum):
             Video
             TAR messages (WAV files)
             VMS messages
             Speed Data
             Incident Data
             Scan Pavement Sensor Data
             EORS Road closure data




                                        32
     Development Schedule:

     Because of the on-going modification to the CHART network as well as on-going
     modification to the CHART field devices, this system development, delivery and
     implementation is designed to be a multi-stage process. Although the Contractor is
     expected to submit his own schedule, based on knowledge gained during early project
     meetings, our current implementation schedule is expected to be:


1.   Basic integrated graphical control of Field Equipment + integration of Legacy Systems
2.   Detailed stand-alone reporting
3.   Detector subsystem through polling PCs
4.   Automated scenario generation




                                             33
GLOSSARY
AOC      Authority Operations Center
ATM      Asynchronous Transport Mode
ATMS     Advanced Transportation Management System
AVCM     ATM Video Control Manager
AVL      Automated Vehicle Location
BWI      Baltimore/Washington International Airport
CCTV     Closed Circuit Television
CHART    Chesapeake Highway Advisories Routing Traffic
COTS     Commercial off-the-shelf
CPOC     CHART Proof of Concept
DBM      Maryland Department of Budget and Management
DGS      Maryland Department of General Services
EOC      Emergency Operations Center
EORS     Emergency Operations Reporting System
ERU      Emergency Response Unit
ETP      Emergency Traffic Patrol
FITM     Freeway Incident Traffic Management
FMS      Field Management Station
FPU      Field Processing Unit
GIS      Graphical Information System
GUI      Graphical User Interface
IEN      Information Exchange Network
IOTC     Interim Operational Telecommunications Capability
ISP      Information Service Provider
ITS      Intelligent Transportation System
MDOT     Maryland Department of Transportation
MDSHA    Maryland State Highway Administration
MdTA     Maryland Transportation Authority
MSP      Maryland State Police
NOVA     Northern Virginia Traffic Management System
NTSC     National Television Standards Committee
PC       Personal Computer
RGB      Red, Green, Blue (computer graphics display)
SNMP     Simple Network Management Protocol
SOC      Statewide Operations Center
SONNET   Synchronous Optical Network
SQL      Structured Query Language
TAR      Travelers Advisory Radio
TAT      Travelers Advisory Telephone
TOC      Traffic Operations Center
VMS      Variable Message Sign
WWW      World Wide Web




                                   34

				
DOCUMENT INFO
Description: Printable Blank Charts document sample