3.5.4 Scenario C - TRAVELER INFORMATION FUNCTION

3.5.4.1 Traveler Information Representative Scenario Description

Getting ready for her trip home over the long weekend from college, Kerry is in such an excited hurry that she forgets to check the weather forecast and road conditions on her PC.  She had been concerned about the trip home because of the heavy rains that seemed to persist all week. Now as she dashes out of her dormitory into the cool fall air, her duffel bag slung over one shoulder, she notices that the gray skies have finally have given way to a sky full of twinkling stars and only the first hints of sunrise are peaking over the hills. Realizing that the rains may have caused some problems in the narrow Appalachian valleys, she feels it would be wise to check the weather and road conditions using the 511 system.After starting her car and while waiting for the engine to warm, Kerry takes out her cell phone and dials in 5-1-1.

Hearing the familiar introduction to the regional traveler information system, Kerry uses the interactive voice response features of the system to indicate that she will be traveling on State Route 200, heading east from Rowley up the Ripple River gorge. The 511 voice response system immediately advises her that State Route 200 is closed between Haggars Crossing and Porkys Bluff due to flooding. She then checks US Route 12, which is a longer drive that takes her south along the western slopes of the Appalachians before turning east at the National River and over Freedom Gap. The weather report indicates clear and cool weather along each segment of her route with local areas of fog, but no problems with road conditions.   Kerry has no idea that behind the scenes the 511 system is tapping into the nationwide Clarus System and the state’s Road Condition Reporting System. Information from these data collection networks coupled with weather information from the National Weather Service network and high-resolution weather and pavement condition forecasts form the core for the weather and road condition component of the State DOT’s 511 system. Had she taken time before leaving her dorm, she could also have accessed the information from the State DOT web page.

Hanging up, Kerry gives a brief call to her parents before starting her drive home to tell them that she will be a bit later arriving because Route 200 is closed due to flooding and road conditions are better on US Route 12. As Kerry heads south on US-12 driving conditions are good except for occasional areas of fog that she seems to run into each time she drops into a valley. Even though she passes through these zones of fog, some of them seem to be getting a little denser as the first light of morning begins to appear. Kerry knows that there are a couple of deep valleys to cross before she gets to the National River, so she stops briefly in Whiskey Run to check the weather conditions once more. The report for the segment of US-12 from Devils Ridge to Highland indicates that there is dense fog in the Tumbling River valley. 

Kerry is not aware that a network of visibility sensors and video cameras are installed along US-12 to monitor for dense fog areas. The data from these sensors is transmitted routinely over the Clarus network and made available to weather service providers, who then transform the reports and images into advisory messages along specific segments of the highway. Currently, the visibility sensors in the Tumbling River valley are reporting visibilities under 1/8 mile. Kerry continues south and as she approaches the crest of Devils Ridge, she sees the fog advisory message on the dynamic message sign the stretches overhead across the highway. It reads, “DENSE FOG 2 MILES AHEAD, DRIVE WITH CAUTION”. As she starts dropping into the valley, Kerry can see the bottom of valley shrouded in fog with the first rays of sunshine streaming across the ridgeline to the east. As the road winds down the side of the valley, it finally becomes partially obscured in the fog. Another DMS pops out of the fog, this one with a flashing warning, “VISIBILITY LESS THAN 100 FEET, 2000 FEET AHEAD”. Kerry checks to make sure her low beams are on and she slows her vehicle.

As she reaches the bottom of the valley, the visibility drops to near zero making it difficult to even see the superstructure on the bridge over the Tumbling River. Kerry cautiously picks her way through the fog and up the south slope of the valley toward the Highlands. As she drives out of the fog and back into the first rays of the day, Kerry is pleased that the fog monitoring system is there and that it provided her the necessary warning to permit her to adjust her driving habits appropriately.

3.5.4.2 Traveler Information Technical Description

For the traveling public, a wide range of weather-related decision aides are available that have become an essential part of evolving advanced traveler information systems (e.g. web sites, 511, and traveler information kiosks). The information provides important weather-related travel planning information both pre-trip and en-route. Often the information provided to travelers comes from existing data and information resources collected by State DOTs (Autonomous Layer) and are provided to travelers through mechanisms such as web sites describing current weather and road conditions. Some State DOTs have folded this information into 511 traveler information systems where the information is often included with weather forecast information acquired from public and private service providers.

Travel decisions rely upon the availability of timely road conditions and weather information. The preparation of travel information requires the use of a broad range of weather data to formulate how weather conditions will evolve over an entire road network.   This information is consolidated with the latest road condition reports from State DOTs and State Law Enforcement to provide an information service to travelers conveyed through various communications methods.

Service providers extract data, as needed, from the Clarus System. They receive quality-controlled data and associated metadata information for the specified data request. Service Providers then integrate the Clarus data with other pertinent weather and non-weather data to produce specific products and services that respond to the needs of the traveler such as road condition information. These products and services are distributed to the traveler through various devices and communications methods to satisfy their particular needs.

The information that follows provides a step-by-step flow of activities that depicts a general scenario unique to the traveler information function in conjunction with the Clarus Framework scenario. Each successive heading and set of bullets constitutes the next stage of activities with a general flow of time increasing as the list progresses. The entity responsible for each is noted on the line before each set of bullets.

AUTONOMOUS ENTITY
VEHICLE COLLECTION – INFORMATION SERVICE PROVIDER (ISP)

• Private Vehicle systems detect and time-stamp location, weather, and pavement conditions
• Private Vehicle systems upload stored reports to Vehicle Data Collector
• Vehicle Data Collector stores aggregated vehicle-based data in a database

CLARUS
See the Clarus Framework Scenario

INFORMATION SERVICE PROVIDERS
DATA INTEGRATION

• The Information Service Providers collect, store, and consolidate the Clarus data with observed meteorological data from various other sources
• The Information Service Providers acquire forecast guidance products to complement the observed data
• Observed data are consolidated and composed into presentations showing the data from various sites displayed on a GIS background
• The observed and forecasted data are composed into route-specific weather and road condition analyses and forecasts

DATA TRANSFORMATION

• Weather condition and forecast data for specific route segments are stored in a database on information delivery systems ready for access by travelers, transportation agencies and the media. Maintenance activity and weather-related road closure information are collected and added to Clarus data and stored in a database for use in generating road condition information
• Pavement and hydrologic conditions are computed for segments of a given highway, combined with reported road condition information, and stored along with the weather condition and forecast information

TRAVELER INFORMATION DECISION SUPPORT

• The observed weather, pavement and water level conditions are correlated with traffic data to assess the current and future conditions for numerous representative points along a segment of highway
• Using observations and forecasts as well as road closure, vehicle restriction, and transit/rail service information, the DSS provides recommended messages/content for dissemination via DMS, Highway Advisory Radio (HAR), interactive telephone systems (e.g., 511) and traveler information web sites based upon visibility distance, wind speed/direction and/or pavement conditions.
• These products are composed into value-added applications and stored for distribution to or immediate delivery to end-users (i.e., product consumers)

PRODUCT CONSUMER
TRAVEL INFORMATION

• Weather, pavement condition, road closure, vehicle restriction, transit/rail service and maintenance activity information are acquired from Information Service Providers and NOAA
• Calls to statewide 511 systems and other interactive telephone systems support decisions on travel plans and en-route travel activities
• Information is displayed on DMS regarding adverse travel conditions or rapidly changing weather and road conditions anticipated along the traveler’s direction of travel. Similar information is transmitted via HAR.
• Information on adverse travel conditions is provided to State Patrol for use in planning activities.
• Information is displayed on traveler information web sites (e.g., DOT web pages).
• Information is displayed on in-vehicle devices and Personal Digital Assistants (PDAs) regarding changing weather and road conditions anticipated along current direction of travel and driver-selected route
• Roadside kiosks provide geographical display and printed outputs of current and forecasted travel weather conditions
• Media outlets access traveler information systems and relay the information on radio and television supporting traveler planning activities

3.5.5 Scenario D - TRANSIT MANAGEMENT FUNCTION

3.5.5.1 Transit Management Representative Scenario Description

Buster, the manager for the Transit Authority in Mobile Flats, supervises a recently completed, rapid transit train service designed to minimize congestion in the downtown business district and assure easy access to the renowned medical research center and hospital complex near the heart of the city. The success of the transit program revolves around the well-orchestrated coordination between the bus feeder system and the modern train service. The Transit Authority teamed with a local company to create a sophisticated scheduling system that monitors the position of all buses and trains and attempts to keep all buses and the trains on the prescribed schedule. The scheduling module uses a complex traffic model to determine the effects of traffic volume and occasionally adjusts the schedules to account for changes in traffic patterns.

Prior to the installation of the new transit service, sporadic storms and especially decaying tropical depressions hit the city causing local flooding that totally disrupted the bus service schedule. The new scheduling program now deals with these events and adjusts schedules to account for delays along specific routes. Since modifications in the schedules affect the user base of the Mobile Flats public transportation system, the Transit Authority implemented a thorough schedule information system. Monitors are located at train terminals and numerous bus waiting shelters throughout the city. Users may also access the Transit Authority website from any location and find when a bus or train is expected at a specific location in the city. In addition, the information is available via a handheld device, which a user may already own, or one the Transit Authority will provide as part of their Regular Riders program. In addition, anyone can call the Transit Authority’s Schedule Line and get the current arrival time at any point via an interactive voice response telephone system.

Since weather is the primary factor affecting scheduling adjustments, the Transit Authority integrates observed and forecasted weather and pavement conditions into the scheduling program. Occasional flooding also affects routing so the Transit Authority, in conjunction with the City of Mobile Flats, has invested in an extensive network of Environmental Sensor Stations (ESS) to monitor both road weather and hydrological conditions. ESS sites near flood prone streams have been instrumented with water depth sensors that determine the depth of water in the stream. Mobile Flats has also deployed an additional network of sensors that just monitors water depth in flood prone areas. The information from the city’s ESS sites and water depth sensors has become part of the new nationwide Clarus System. Data from the State DOT ESS network also is collected and integrated by the Clarus System.

Ready access to all of this data from one source has permitted the Transit Authority’s weather service provider to more efficiently access environmental information and assimilate it into an assessment of weather and pavement conditions within and around the city. The weather service provider continually updates the existing conditions and short-term weather and pavement forecasts. Although the scheduling program can ingest the weather and pavement input automatically and modify the scheduling without human intervention, Buster and his staff monitor the conditions and forecasts closely to assure that the schedule adjustments seem reasonable. Operators may override the schedule modifications as necessary.

At this moment, Buster is watching the remnants of Xavier, a tropical storm that dumped over 20 inches of rain across the metropolis. Radar and ground reports shown on the internal website indicate a few weak rain bands are still associated with the disappearing storm. Twenty percent of the routes in the bus network have been affected by local flooding. Some have been rerouted or actually terminated until the water recedes. Any additional rain makes the road closure process a dynamic situation and each route change tends to ripple through the entire system, so Buster is monitoring the progress closely. He has already talked to Jerry at the weather service office and has Tammy, his assistant, monitoring radio traffic amongst highway maintenance personnel within the city and surrounding communities to pick up reports of heavier rain squalls. If indications of another rain band develop, Buster will assess the impact of the projected rain and adjust the scheduling directly or coordinate with Jerry to update the area affected by the rain and have the updated information reissued to the scheduling program.

3.5.5.2 Transit Management Technical Description

Transit operations revolve around scheduling and it is essential that all components of the multi-modal transportation scheme reach each designated location at specified times. Transit system users depend upon this scheduling consistency. However, inclement weather affects different components of the multi-modal system in different ways. Therefore, it becomes important to know specifically what the type and intensity of weather is expected and how this weather scenario is likely to affect the performance of the fleet. Winter storm and heavy rain conditions tend to disrupt bus and ferry scheduling more significantly than rail performance, thus significant attention needs to be placed on pavement and wave conditions and their impacts on bus and ferry traffic flow.

Support for transit management functions by Clarus involves weather-, pavement-, and transit-related data collected from diverse sources owned and/or operated by surface transportation organizations. Some transit organizations own weather data collection systems and many rely on reports from their transit operators that may be captured in for use within the Clarus System. The data from these systems are transferred at routine intervals to one or more data fusion centers to form the Clarus database. Service providers and other users (e.g., transit authorities) extract data, as needed, from the Clarus System. They receive quality-controlled data and associated metadata for the specified data request. Service Providers then integrate the Clarus data with other pertinent weather and non-weather data to produce specific products and services.

The information that follows provides a step-by-step flow of activities that depicts a general scenario unique to a transit management function in conjunction with the Clarus Framework scenario. Each successive heading and set of bullets constitutes the next stage of activities with a general flow of time increasing as the list progresses. The entity responsible for each is noted on the line before each set of bullets.

AUTONOMOUS ENTITY
VEHICLE COLLECTION – TRANSIT AGENCY

• Transit Vehicle systems detect and store weather, pavement, and transit operations information as a function of time and location over their routes
• The Vehicle Data Collector uploads the data from the transit vehicle at specified intervals, or drop points, and stores the aggregated vehicle-based route and operations data in an operational database

CLARUS
See the Clarus Framework Scenario

PUBLIC AND PRIVATE SURFACE TRANSPORTATION WEATHER SERVICE PROVIDERS
TRANSIT MANAGEMENT DECISION SUPPORT

• The observed weather, pavement and water level conditions are coupled with reported maintenance actions to assess the current condition of the road surface for numerous representative points along a segment of highway
• For route-based transit operations (e.g., Ferries and Light Rail), the observed weather and route conditions are used to assess the current condition of the route
• Using the observed and forecasted weather conditions, Transit Management Decision Support System assesses the anticipated pavement and/or route conditions and recommends service adjustments including transit parking
• These observations and projections are composed into value-added deliverables which may be stored for distribution or sent directly to the end users
• Weather, water level, route and road condition data are processed and alerts are generated when specific operational thresholds are exceeded

PRODUCT CONSUMER
TRANSIT MANAGEMENT ACTIVITIES

• Weather, water level, route and road condition advisory information is acquired from Service Providers and NOAA
• Decisions are made on the impact of the projected conditions on the schedules of transit vehicles within the fleet
• Schedules and routes are adjusted to accommodate for the impact of the weather, route conditions, road conditions, wave height conditions, and traffic flow
• Revised schedules and routes are computed and made available to transit system users

3.5.6 Scenario E - EMERGENCY AND PUBLIC SAFETY FUNCTION

3.5.6.1 Emergency and Public Safety Representative Scenario Description

Jane is an emergency management coordinator for the City of Fertile, a small community in the midst of the Corn Belt. Her team maintains the 911 service plus interfaces with the local and regional police and fire departments, ambulance services, medical facilities, and other emergency management agencies. Because many of the incidents her group deals with are associated with inclement weather conditions, the city has equipped her emergency management operations center with a dedicated weather support console. The console has three monitors that the emergency management operator can connect to various information resources such as the city’s network of video cameras, the state ESS network, websites containing free weather information, and a website provided under contract from a surface transportation weather service provider.  

The surface transportation service provider and the State DOT allow Fertile to have access to the Maintenance Decision Support System (MDSS) the DOT has implemented in the DOT district in which Fertile resides. This program has been under development within the district for the last couple of years and became more robust when the nationwide Clarus System went operational to collect weather, pavement and hydrologic data from surface transportation monitoring sites around the country, including from the various sources surrounding Fertile.   The Clarus data increased the density of the weather information available to analyze weather conditions and provided pavement temperature and surface conditions used to assess the impact of maintenance actions. Jane and her staff are not meteorologists by any means but because of their need to stay up on the weather, the emergency management team has become “the local weather experts” and assists with decision support information for school closures, county maintenance decisions, and other local activities where the team can help without jeopardizing their primary emergency management services.

On this particular January evening, Jane is on duty and the City of Fertile is in the midst of a winter storm. Looking out the window Jane estimates that there are 4 to 6 inches of snow on the ground so far and another 2 to 3 inches are expected. That amount fits with the reports that Jane has been hearing from the state maintenance drivers as they work the local highways in the area around Fertile. It also fits with the snowfall totals that the MDSS estimates for the road segments in the Fertile area. Jane has been watching the maintenance activities in the area by monitoring the MDSS display that shows the location of the maintenance trucks and the reported and estimated road conditions. The team knows that these trucks are instrumented with data logging equipment that telemeters the data back to a central computer at least once every ten minutes.  This information is immediately processed and updated on their MDSS display. The team has gained confidence that the reports are current and reliable.

As Jane monitors the maintenance activity, she is watching the plowing and treatment progress knowing that two trucks are out of action from the Loam garage.   Although the Interstate that is just 10 miles east of Fertile is in good shape, US-49 is in marginal shape, and State Routes 10, 33, and 46 have not even been touched yet. So far, these conditions have not been a problem. The emergency calls have been a few vehicles off the road and a couple of fender benders in town. At 10:18 PM this all changes. A 911 medical emergency call comes in from a residence 2 miles northwest of Sandy City just off State Route 33.

Jane addresses the issue, conferences in the Centralia hospital, confirms that an ambulance needs to be dispatched immediately from Centralia, and contacts the ambulance service and confirms with all parties that the ambulance is on the way. She also calls the State Police and advises them of the emergency. However, Jane is aware that State Route 33 has not been plowed or treated yet. She immediately contacts Lenny, the supervisor for the Loam garage who is working with staff at the garage to get one or both of the inoperable trucks back on the road. Since Lenny is in the shop and not his office, he asks Jane to tell him where trucks 9984 and 3762 are currently and where the ambulance needs to go. She indicates the trucks last positions from the MDSS map and the spot of the emergency. Lenny indicates that since truck 3762 is near the US-52 intersection with State Route 10; he will have Dale jump onto route 33 just west of Centralia and clear the road in front of the ambulance.

Meanwhile, he will ask Roger in truck 9984 to take a short cut along county AB onto route 33 so he can pick up the plowing activity about half way between Centralia and Sandy City. Lenny then asks Jane if she will contact Dean in Sandy City and see if they can get a city truck to make sure the road is clear to the emergency site. Jane contacts Dean who initiates action to get a truck on the road to the residence. Jane then begins to monitor the progress of the maintenance vehicles, the ambulance, and the State Highway patrol car dispatched by the Highway Patrol to assist and calls back to the 911 contact to provide information on the emergency response activities. Once the Highway Patrol officer arrives on site, Jane passes responsibility to the officer.  However, she continues to monitor the progress of the ambulance and updates the officer when he requests a position.

3.5.6.2 Emergency and Public Safety Technical Description

Responses to local or regional emergencies or general public safety functions may be significantly impacted by weather-related conditions. The aggregation of many local and regional support services rendered by members of the service provider community becomes an important part of the agency’s decision process. Service providers acquire quality-controlled Clarus data and integrate it with data from other sources (e.g., observed hydro-meteorological data from other public and private sources, numerical weather prediction model data, road condition reports, and camera imagery) to produce consumer products.

Local emergency and public safety operations focus on quick mobilization of resources.  Inclement weather affects the mobilization plan in different ways depending upon the character of the weather situation. Precipitation impacts road conditions and the subsequent effect on the mobilization plan is dependent upon traffic impacts and the maintenance or flood control actions taken by local agencies. Wind speed and direction can affect the dispersion of plumes and emergency responses taken to protect public safety.

Regional emergency and disaster management operations also focus on quick mobilization of diverse resources. They may also require an immediate, highly localized assessment of the transport of hazardous materials within the atmosphere around and disseminating from a disaster site. Inclement weather affects the mobilization plan in different ways depending upon the character of the weather situation. In disaster situations, the airborne movement of noxious, lethal, or hazardous materials or gases is often dependent upon local weather conditions in the area of the disaster and the effect of the event on these meteorological factors.  The determination of safety zones around the disaster needs to be defined as soon as possible after the event. In addition, the evacuation or movement of affected parties needs to be implemented quickly. The response scenario becomes a dynamic process if the source of hazardous materials persists and weather conditions change.

Support for emergency and public safety functions by Clarus is enhanced by weather, pavement, and hydrologic data collected from diverse sources owned and/or operated by surface transportation organizations. Although local emergency and public safety authorities are not typically owners of surface transportation weather data collection systems, they benefit from the data collected by other agencies within their area of operation. The process to provide support for these public safety agencies requires that data from these local and regional environmental information systems be transferred at routine intervals to one or more data fusion centers to form the Clarus database.

The information that follows provides a step-by-step flow of activities that depicts a general scenario unique to a local or regional emergency and public safety function in conjunction with the Clarus Framework scenario. Each successive heading and set of bullets constitutes the next stage of activities with a general flow of time increasing as the list progresses. The entity responsible for each is noted on the line before each set of bullets.

AUTONOMOUS ENTITY
VEHICLE COLLECTION – PUBLIC SAFETY AGENCY

• Emergency Vehicle systems detect and store weather, pavement, and emergency operations information as a function of time and location
• Vehicle Data Collector uploads the data from the vehicle at specified intervals or drop points and stores the aggregated vehicle-based data in an operational database

CLARUS
See the Clarus Framework Scenario

PUBLIC AND PRIVATE SURFACE TRANSPORTATION WEATHER SERVICE PROVIDERS
EMERGENCY AND PUBLIC SAFETY DECISION SUPPORT

• The observed weather, pavement and hydrologic conditions are coupled with reported maintenance actions to assess the current condition of the road surface or route for numerous representative points along a segment of highway
• Observed and forecasted weather conditions serve as input into a dispersion model that simulates the flow of air and local environmental factors
• Observed and forecasted precipitation events and hydrologic conditions serve as input into a water level model that predicts the location and timing of roadway flooding
• Using the forecasted weather conditions, the Service Provider pavement condition model or DSS assesses the anticipated pavement conditions assuming no maintenance actions
• The DSS also assesses the anticipated pavement and route conditions based upon input from highway crews and their expected route timing.
• These observations and projections are composed into value-added deliverables that may be stored for distribution or sent directly to the end users.

PRODUCT CONSUMER
LOCAL EMERGENCY AND PUBLIC SAFETY ACTIVITIES

• Weather and road condition advisory information are acquired from Service Providers and NOAA
• Decisions are made on the impact of the projected weather and pavement conditions on the response timing of emergency vehicles within the local area
• Response times and routes are adjusted to accommodate for the impact of the weather, road conditions, and traffic flow and integrated into an emergency management deployment system
• Information regarding weather, road conditions, traffic flow, and emergency management logistics is displayed on in-vehicle devices and PDAs to facilitate coordinated emergency and public safety activities
• Output from the dispersion model feed into the emergency management deployment system which provides guidance on the appropriate deployment of available resources and possible evacuation and response plans associated with the disaster event
• Emergency management and law enforcement personnel coordinate with traffic managers to evacuate residents from hazardous areas

3.5.7 Scenario F - RAIL OPERATIONS MANAGEMENT FUNCTION

3.5.7.1 Rail Operations Management Representative Scenario Description

As a dispatcher for Rogers Railroad, Jimmie is always on the watch for changing weather conditions that could jeopardize his schedule and the safety of the trains currently in the rail network. Knowing that trains are susceptible to ‘blow-overs’ when strong winds or wind gusts hit the train from the side, Jimmie is especially careful to monitor for thunderstorm complexes or weather patterns that create a potential for high winds. On this Thursday in mid-April, Jimmie is watching a thunderstorm complex develop over the Texas Panhandle. He is aware that this area may become a potential concern based upon Weather Watches issued by the National Weather Service, advisory notices posted on a couple of websites that he has checked in the last hour, and the notification he received from the weather service provider a little over an hour ago. Rogers Railroad uses this weather service provider as its primary source of information but confirms their forecasts by checking products from the NWS and other sources.

Jimmie particularly likes the geo-referenced RailNet display that the provider developed jointly with Rogers. The entire Rogers Railroad network is the primary display and each train in the system appears in its current position on the display. Jimmie has the ability to add or delete state and county boundaries, rivers, lakes, highways, cities, and other geographic reference parameters. On top of this background, Jimmie can add one or more weather or rail-related parameters to create a composite display of the rail system and weather conditions. In addition, he can zoom the display area to create regional or local areas of the Rogers network. Once he has a display combination and an area he likes and can use in the future, he saves both the view areas and parameter combinations for future use.

Jimmie finds the display of weather information improved over the weather overlay system from two years ago due to the additional data that is available from the surface transportation sector via the Clarus System. Even though this additional data is not directly rail related, it filled a number of weather data voids where neither NOAA nor Rogers Railroad had weather observation sites. Jimmie has also found the added water depth information from HiFAS (Highway Flooding Analysis System) that is communicated through the Clarus System has proven helpful in augmenting the flood potential display previously derived from just the hydrological data derived from NOAA sources.

The Texas Panhandle storms are developing quickly. Jimmie is monitoring the progress of a freight train bound from Nashville to Albuquerque that is currently 70 miles east of Amarillo. It is carrying mostly of benign commercial goods but does have 10 cars containing a toxic commercial solvent. Jimmie is keeping an eye on the radar overlay of the storms on the rail configuration in the northern Panhandle as he manages the movement of trains throughout the southwestern quadrant of the United States. While he is sending a message to a train west of Salt Lake City, the WeatherWatch system initiates an alert indicating a strong thunderstorm south of Amarillo moving northeast is projected to cross the rail line somewhere along a segment roughly 10 to 30 miles east of Amarillo in approximately 45 minutes.

The WeatherWatch program has derived this path from the attribute data provided by the NexRAD radar and has placed a flashing display of the potential path of the storm on the RailNet display of the northern Panhandle of Texas. The display indicates there is a potential for brief high winds, hail, and heavy rain. Jimmie finishes his note to the Utah train and immediately edits an advisory note with the specifics of the storm that had been auto-generated by WeatherWatch system for transmission to the Nashville to Albuquerque train.  Jimmie now focuses his attention on this train. Jimmie has the ability to perform “what-if” analyses using the combined capabilities of the RailNet/WeatherWatch system. Based upon the current speed of the train, the train and the storm will be in the same vicinity at roughly the same time.

Jimmie decides to test some modifications to the train’s speed and see if he can slow the train to avoid the timing of this well organized thunderstorm cell. As he tests a couple of scenarios, the WeatherWatch system updates the storm track information. The update indicates that the storm is intensifying and now the segment is better defined in a range of 15 to 25 miles east of Amarillo. In addition, Jimmie now notices the highlighted 54 mph wind gust entry taken from surface observations near the current thunderstorm position. Because of the toxic material on this particular train, Jimmie decides to slow the train to 25 mph to try to avoid the thunderstorm.  He sends notification to the engineer to reduce the speed to 25 mph and be prepared to bring the train to a complete stop if this thunderstorm or additional storms along the line of cells will pass the rail line near the position of the train.

3.5.7.2 Rail Operations Management Technical Description

For the railroad industry, value-added products created by members of the service provider community become an essential part of decision support for planning and daily operations. Railroad operation decision-making relies upon the availability of timely current and forecasted weather information along thousands of miles of rail line across the nation that experience extreme weather conditions ranging from violent thunderstorms to bitter cold air temperatures. Safeguarding the movement of freight and passengers requires knowledge of weather events that can result in derailment due to high winds, the buckling of track due to extreme temperatures or rail washout due to flooding. The preparation of the appropriate weather information requires the use of a broad range of weather information to formulate how weather conditions will evolve over an entire rail network along with site-specific information relating transient weather conditions that result in isolated, yet severe, weather conditions along the railroad right of way.   Likewise, military rail operations need rail network weather information in order to plan and manage shipment of sensitive military assets.

The information that follows provides a step-by-step flow of activities that depicts a general scenario unique to a railroad operations management function in conjunction with the Clarus Framework scenario. Each successive heading and set of bullets constitutes the next stage of activities with a general flow of time increasing as the list progresses. The entity responsible for each is noted on the line before each set of bullets.

 

AUTONOMOUS ENTITY

VEHICLE COLLECTION – RAIL VEHICLES

• Railroad Vehicle (e.g., train cars, rail maintenance vehicles) systems detect and store weather and route operations information as a function of time and location
• Vehicle Data Collector uploads the data from the railroad vehicle at specified intervals or drop points and stores the aggregated vehicle-based data in an operational database

CLARUS

See the Clarus Framework Scenario

 

PUBLIC AND PRIVATE SURFACE TRANSPORTATION WEATHER SERVICE PROVIDERS

DATA INTEGRATION

• The Service Providers collect, store, and consolidate the Clarus data with observed meteorological, hydrologic and rail data from various other sources
• The Service Providers acquire forecast guidance products to complement the observed data
• Observed data are consolidated and composed into presentations showing the data from various sites displayed on a geo referenced background
• The observed and forecasted data are composed into route-specific weather forecast and rail condition products
• The forecasts are organized into textual and geographical presentations

DATA TRANSFORMATION

• Weather condition, hydrologic conditions and forecast data for specific railroad segments and routes are stored in a database on information delivery systems ready for access.
• Rail conditions are computed for segments of a given geographical region and are stored along with the weather condition, hydrologic condition and forecast information

RAILROAD OPERATIONS DECISION SUPPORT

The observed weather, hydrologic, route and rail conditions are coupled with railroad operations data to assess the current condition of the railroad network.
• Using the forecasted weather conditions, the DSS assesses the anticipated impacts to rail traffic and recommends routing guidance and/or actions to mitigate short-term threats.
• These observations and projections are composed into value-added deliverables that may be stored for distribution or sent directly to the end users.

PRODUCT CONSUMER

RAIL OPERATIONS MANAGEMENT ACTIVITIES

• Weather and rail condition advisory information is acquired from Service Providers and NOAA
• Decisions are made on the impact of the projected conditions on heavy rail train routing and rail carrier schedules
• Schedules are adjusted to accommodate for the impact of the weather, rail conditions, and train traffic
• Revised schedules are computed and made available to rail system users
• Decision support advisories are followed to maintain effective right-of-way control

3.5.8 Scenario G - COMMERCIAL VEHICLE OPERATIONS FUNNTION

3.5.8.1 Commercial Vehicle Operations Representative Scenario Description

Commercial Express, a trucking firm with over 3500 trucks operating throughout the United States, recently decided to take aggressive action to counter the effect the cost of fuel was having on their profit margin.  Commercial was aware that fuel usage on a given route was significantly impacted by factors such as wind resistance, rolling friction, engine efficiency, vehicle speed, speed consistency (minimal starting and stopping), distance traveled, elevation changes, the type of vehicle, and the operational state of the vehicle (level of maintenance).   Barry, the director of research at Commercial Express had done a literature review of all of these factors and had developed a set of algorithms to estimate the effect of each parameter on fuel efficiency.   What Barry found was that many of the factors were greatly impacted by the weather and pavement conditions along the route.

Barry discussed his weather requirement with Route Decisions, a surface transportation weather service provider, and the two firms agreed to develop a decision support system to assess scheduling and operational techniques to minimize the total cost of operating a truck between two locations. Route Decisions would provide a high-resolution analysis and forecast of weather and pavement conditions for the entire highway network that Commercial Express uses. This forecast would cover a 72-hour period and would be replaced every 12 hours and updated more frequently, if adjustments were needed. Commercial Express would then define a “shipment” – that is, the truck and its operating characteristics, the type of trailer, the gross weight of the shipment, and the operational status of the truck and trailer.

The decision support model would simulate the movement of the truck along its route and compute the operational costs associated with the forecasted weather and pavement conditions in each 10 km segment along the entire route. The mock shipment would then be recomputed over the potential routes at sequentially later start times (the typical evaluation was done for start times one hour apart out to a maximum departure delay of 24 hours). At the end of the simulation, the dispatcher would receive a listing of the estimated operational costs for each potential route and departure time. If specific departure times indicated that significant reductions in cost would occur, the dispatcher would assign that shipment with a specified departure time and itinerary. Commercial Express completed the decision support program two years ago and is now nearing the end of the second year of the test. The evaluation has been performed on a set of test routes representing 5% of their total operation over the two-year period.

Barry has worked closely with the dispatchers and Route Decisions through the first two years verifying the cost estimates against actual costs and documenting the performance of the forecasts provided by Route Decisions. Results indicate a substantial improvement in the short haul costs during this second year of the program and Theodore, the research technician at Route Decisions, has documented that this improvement is largely associated with the improved data set that became available last summer when the Clarus System became operational this last summer. Detailed weather and pavement condition reports are now available from one source and these reports fill major gaps in their previous weather and pavement database. Route Decisions has archived the data from the first two years and Barry is presently rerunning the “shipments” using actual observed data in place of the forecasted data for the second year of operations.

Results for the first year and initial indications from the second indicate that shifts in the scheduling produce significant reductions in operational costs and that the scheduling recommended from the operational forecasts tend to capture reasonable route start-time adjustments. Theodore has also told Barry that several of the states are instrumenting their maintenance vehicles with maintenance data collection systems and the data will be telemetered from the trucks to the central collection point on a nearly continual basis. This information will be carried over the Clarus System and will considerably aid in the assessment of current road conditions and subsequently improve route forecasts. Barry feels the first two years of the route planning decision support system has proven successful and with the data support enhancements offered by Clarus Barry is ready to implement the program throughout the entire Commercial Express network.

3.5.8.2 Commercial Vehicle Operations Technical Description

The management of commercial vehicle fleets may be significantly impacted by weather-related conditions. Fleet management of commercial vehicles revolves around scheduling and routing, and it is essential that all components of the inter-modal transportation scheme reach each designated location at specified times. Commercial vehicle operators depend upon this scheduling consistency. However, inclement weather affects different components of the inter-modal system in different ways, thus it becomes important to know specifically what the type and intensity of weather is expected and how this weather scenario is likely to impact the performance of the fleet. High wind conditions and precipitation events causing vehicle instability and slick pavement tend to disrupt commercial vehicles the most because of their wind profile and weight, thus significant attention needs to be placed on these conditions and their impact on commercial vehicles.

Support for commercial vehicle fleet management functions by Clarus involves weather, pavement, and commercial vehicle-related data collected from diverse sources owned and/or operated by surface transportation organizations. Commercial vehicle fleet management can provide vehicle-based environment data collection systems or provide services within jurisdictions that maintain collection systems for other transportation requirements. The data from these systems are transferred at routine intervals to one or more data fusion centers to form the Clarus database.

The information that follows provides a step-by-step flow of activities that depicts a general scenario as to how a commercial vehicle operations function in conjunction with the Clarus Framework scenario would occur. Each successive heading and set of bullets constitutes the next stage of activities with a general flow of time increasing as the list progresses. The entity responsible for each is noted on the line before each set of bullets.

AUTONOMOUS ENTITY

VEHICLE COLLECTION – COMMERCIAL VEHICLE OPERATIONS

• Commercial Vehicle systems detect and store weather, pavement, hydrologic and commercial vehicle operations information as a function of time and location
• The Vehicle Data Collector uploads the data from the commercial vehicle at specified intervals, or drop points, and stores the aggregated vehicle-based data in an operational database

CLARUS
See the Clarus Framework Scenario

PUBLIC AND PRIVATE SURFACE TRANSPORTATION WEATHER SERVICE PROVIDERS
COMMERCIAL VEHICLE DECISION SUPPORT

• The observed weather, pavement, and hydrologic conditions are coupled with reported maintenance actions to assess the current condition of the road surface for numerous representative points along a segment of highway
• Using the forecasted weather conditions, the Decision Support System (DSS) assesses the anticipated pavement conditions
• The DSS also assesses the anticipated pavement conditions based upon input from highway crews and their expected route timing.
• Commercial Vehicle Rollover potential and fuel economy predictions are calculated based on current and forecasted wind speed and direction along specified routes
• These observations and projections are composed into value-added deliverables that may be stored for distribution or sent to the end users.

PRODUCT CONSUMER
COMMERCIAL VEHICLE OPERATIONS MANAGEMENT ACTIVITIES

• Weather and road condition advisory information is acquired from Service Providers
• Decisions are made on impact of the projected conditions on the routing and schedules of commercial vehicles within the fleet
• Schedules and routing are adjusted to accommodate for the impact of the weather, road conditions, and traffic flow
• Revised schedules and routes are computed and made available to commercial vehicle operators

3.6 Comparison of the Clarus System to Other Federal Systems

The development of the Clarus System relative to present and future federal weather observation systems is important in order to preserve complementary systems rather than competing systems.  This is particularly important given the present efforts within the National Oceanic and Atmospheric Administration (NOAA) to develop a next generation weather observation system known as the Integrated Surface Observing System (ISOS). ISOS will be designed to gather data from the National Weather Service's Automated Surface Observing System (ASOS), the Climate Reference Network, Integrated Flood Observing and Warning System (IFLOWS), and Hydrometeorological Automated Data System (HADS), as well as from all non-NOAA surface environmental monitoring networks that provide complementary data (e.g., surface transportation weather networks and other private networks) NOAA’s Environmental Real-time Observation Network (NERON) will provide the data gathering and processing infrastructure. When fully operational the ISOS will provide the data to NWS forecast offices as well as to the academic and private sectors to improve forecasts and warnings, to improve water management, and to improve the detection of changes in climate. Given the direction of the NOAA ISOS to provide a national support mechanism for weather data access, it is important for the Clarus System design to consider elements found within these existing federal systems in the United States and similar systems in Canada.

The Clarus System continues the efforts begun with past national weather data collection initiatives to expand the volume and coverage of remote and direct observations of the atmosphere and environment. In fact, the growth of atmospheric science and operational weather forecasting in the United States was facilitated by the expansion of weather data collections beyond surface observations in the 1930’s with the growth of commercial aviation and the acquisition of observed pilot reports. Since then, NOAA, the Department of Defense (DoD), the National Aeronautics and Space Administration (NASA) and the Federal Aviation Administration (FAA) have dramatically expanded weather observations to include a national network of Doppler weather radars, a constellation of advanced weather satellites, networks of surface-based atmospheric profilers and sounders, and a network of over 4,200 federally operated surface observation sites including nearly 1,000 Automated Surface Observation System (ASOS) stations. More recently the contributions of the private and academic sectors to expand routine weather observations has resulted in a sophisticated network of weather observations that is unsurpassed at any other location in the world. The next generation data system comprised of the integration of the above data system will constitute the NOAA ISOS of which the Clarus System will be a valuable contributor and data source.

The integration of surface transportation-based weather information into the existing national observing infrastructure through Clarus will serve three primary purposes:

1. Surface transportation-based weather observations will enhance and extend the existing national observation database, supporting general improvements to weather forecasting capabilities, and enhancing the protection of life and property,
2. A national collection of real-time surface transportation-based weather observations will provide for much broader access to this valuable dataset in support of real-time responses to observed weather conditions, and
3. Integration of surface transportation-based weather observations with existing observed data would permit broader support for surface transportation-specific models, which predict the impacts of weather on maintenance and traffic-related concerns.

As the national observing infrastructure is comprised of many national-scale weather observation systems, the weather data collection facilitates support a broad set of applications generally geared toward a particular end use (e.g. aviation, fire, agriculture, radar, satellite, upper air, water supply, etc.).  Although the Clarus System will be a component of ISOS, the organizational structure in itself provides logic applicable to the problem of bringing together all the surface transportation weather observations under a single nationwide system.

The national observational network, which serves as the model for central points of data collection within the national weather venue, has proven valuable and reliable. The Clarus System will provide a central collection point for surface transportation-based weather observations that can be incorporated into ISOS through accepted existing operational methods. Similar central collection points presently exist within the national observational network including those of the National Environmental Satellite Data Information Service (NESDIS) for managing collection and quality control of information from the constellation of earth observing satellites, the National Climatic Data Center for managing collection and quality control of data from NOAA’s national network of Doppler weather radars, and the FAA AWOS (Automated Weather Observation System) Data Acquisition System (ADAS) that is maintained in each of the 22 Air Route Traffic Control Centers nationwide. The purpose of these central collection points is to manage the high volume of observational traffic and to provide for coordinated entry of data into the national observational database. This concept is consistent with the anticipated operation of the Clarus System, which will have the responsibility of collecting, storing, quality controlling, and distributing surface transportation weather observations, traffic data, and roadway characteristics, providing the coordinated entry of this data into the NSWOS, and making the information available for stakeholder data users.

However, the Clarus System is different from previous weather observation data collection initiatives in that it is specifically associated with the measurement of weather and environmental conditions with respect to the surface transportation infrastructure (e.g. roadway, railway, etc.). The method of this data collection is further distinct from most of the existing observation networks in that the collection of the observations is performed not by federal agencies. Rather, the data collected within the Clarus System is primarily collected by state and local transportation agencies (referred to within the Clarus Concept of Operations as the ‘autonomous layer’ to identify the independence of these agencies from the Clarus System operations). This single element is the greatest differentiator between the Clarus System data collection and those of existing federal elements within the national observing framework.   Beyond this difference the contrasts between the Clarus System and other data collection systems becomes less distinct.

For example, all data collection systems must consider data management, data distribution, quality control, and data archive. A unique challenge of the Clarus System over those of existing surface observation collection efforts will be the added challenge of proper handling and quality control of the non-atmospheric data elements (e.g. pavement temperature, pavement chemical concentration, water depth). In general, the quality of the ESS data, based on varied calibration, maintenance practices and sensor siting, is not uniform. There needs to be quality control of the data to ensure that spurious or incorrect data are properly identified to outside systems and users. Methods must be designed for the data as it is collected to be tagged with metadata and filtered as part of the data fusion process. This is especially true for identifying ESS observations that may be pertinent to localized road maintenance applications, but not properly located to provide acceptable representation of atmospheric conditions useful for broader meteorological analysis and forecasting. Effective methods of maintaining quality control from observations that invite non-homogeneity with adjacent observations present particular challenges.

Some systems have begun to investigate methods to incorporate ESS data into the broader database of weather observations from different data collection networks. The NOAA Forecast Systems Laboratory (FSL) has an established research effort to develop methods to broaden the collection of federal and non-federal observation data, including proprietary public and private data, into the national collective through a program known as the Meteorological Assimilation Data Ingest System (MADIS). Although considered to be experimental and primarily for support of research endeavors, MADIS provides collection of surface mesoscale network (mesonet) data from locales not previously supported in the national framework including a limited amount of ESS data provided to MADIS by State DOTs.

Currently, MADIS is the gateway representing the only routine federal incorporation of surface transportation weather information into the NSWOS. MADIS provides data to end-users in netCDF flat file format that includes quality control statistics for the observed data. MADIS addresses methods for handling restricted access data. These data may be restricted by public and private data providers (e.g. State DOTs desiring not to release non-atmospheric data or private sector data providers who maintain agreements to only provide data to the NWS).  As the Clarus System will incorporate similar data restriction issues, MADIS efforts afford the opportunity to Clarus System designers to evaluate the effectiveness of maintaining these important distinctions between proprietary and non-proprietary data.

Recently, NOAA has indicated that MADIS will be transformed from a research effort into an operational system. As such, given the present incorporation of ESS data into MADIS, the NOAA effort must be strongly considered as a model for the Clarus System and will require close inspection during the Clarus System Design.

Another existing system that holds promise as a template from which the Clarus System can emulate is the Road Weather Information Network (RWIN) established through funding from Transport Canada and operated by the Meteorological Service of Canada (MSC). RWIN started as a side project in Canada for weather information integration and it soon became a focus project.  The RWIN is similar to MADIS in that it integrates data from various weather sources into one database. RWIN relies on geo-spatial and information management technologies for real-time data acquisition, quality assurance and control, spatial data storage and real-time delivery of quality assured data to clients.

The RWIN is based on a client/server, distributed computing architecture and makes use of the GIS, spatial data browsing and visualization, and spatial data management technologies. The RWIN data architecture is scalable and is capable of handling text, snap shots, video, image, GIS and raster data sets. The web dissemination architecture supports spatial data browsing, data views in a map form, and data exchange in an interactive and batch mode using various web services. A Metadata catalogue for ESS and for non-ESS datasets enables a user to view data spatially and temporally and to view an ESS performance, status and maintenance history. The plug and play, and reusable software components architecture provides the flexibility of adding new applications or new data sources easily.

A prototype for RWIN is currently undergoing acceptance testing in Ontario and will soon start to accept test data from Quebec. The RWIN orientation session is set for May 2005, with a revised and enhanced version available by June 2005. By 2006-2007, metadata files are to be populated and by 2007-2008, a functional, tested system will be deployed. Participating jurisdictions sign a Road Weather Information System (RWIS) Agreement that requires them to share weather information with the MSC for at least the first two years following acceptance of the agreement. This provision could serve as an important example for the Clarus System to promote the adoption of the Clarus System. As data becomes shared with the MSC, the MSC is able to control how this data is further shared.

Additional benefits of RWIN to the Clarus System will result from the present efforts of RWIN to overcome deployment challenges in Canada and to utilize these solutions within the Clarus System Design. Further, teamwork between the Canadian RWIN and the U.S. Clarus System would promote sharing of weather information across boundaries and could stimulate better operations and research within surface transportation.

4 Conceptual System Architecture

The National Academy of Sciences report, Where the Weather Meets the Road, found that system robustness must be a major objective of an integrated road weather observation and data management system. For Clarus to achieve this capability the system must thoroughly address the broad range of technical issues it will face. These technical issues frame the system architecture and include:

• data acquisition,
• data integration and management,
• validation / quality control, and
• data availability / distribution.

This Concept of Operations has addressed each of these categories relative to the various core Clarus Use Case Functions. A Clarus system design will be required that permits the functional requirements of each Use Case to be comprehensively addressed with respect to the detailed user needs of the weather service and surface transportation weather service provider communities. This includes, but is not limited to:

• consideration of the specific technical issues associated with providing the convenient and consistent flow of ESS data from the Autonomous Layer into the Clarus System,
• the effective accessibility of Clarus data to the transportation related user community via the private surface transportation weather service providers, and
• the support for public weather service providers (e.g., NOAA) to provide for public safety and protection of property.

The following sections briefly discuss the challenges associated with each of these broad technical issues.

4.1 Data Acquisition

One challenge of data acquisition and integration will be to overcome the disparate, and in some cases proprietary, data formats and database protocols.  Standards for data exchange need to be supported in the weather and transportation communities. Adherence to these standards will help to eliminate unnecessary complexities within the Clarus System. Until these standards are more widely adopted, the Clarus System will also likely need to communicate with the Environmental Sensor Station (ESS) network databases and/or their individual ESS through application programming interfaces (API) special to those systems. However, a successful Clarus System has the potential of fostering a much more rapid adoption of standards within the industry. Regardless of how it is accomplished, the Clarus System must include diverse and innovative ways of collecting data from these systems without unduly inconveniencing the data providers or increasing their cost of operations.

Data collected and distributed by Clarus will span both traditional fixed sensors along the roadway and those collected from mobile platforms. The fixed sensors along the roadway are a predominant part of the existing 2,500+ ESS deployments nationwide. Mobile ESS platforms are increasing in popularity, and over time will likely become more predominant than fixed sensors for collection of road weather data. These mobile platforms will provide an additional level of complexity in data collection and will present challenges associated with quality control and database design, since the location metadata becomes highly time dependent. In addition, new sensor design and deployment for both fixed and mobile platforms will continue as emphasis on surface transportation weather increases in the coming decades. This will influence sensor configurations and will require the Clarus System to be adaptive to storage and dissemination of information from emerging sensor technologies. One such technology that is presently growing in use without a clear method of incorporation within either a data management and/or weather utilization schema is video capture from ESS locations via NTCIP standards. The Clarus System should also be able to support the inclusion of non-automated road and route condition observations. The ITS architecture for the inclusion of traffic and weather information is well defined and provides a strong basis for the Clarus System to build upon.

As stated above, the lack of a standard for reporting of ESS data is a critical problem. Each vendor has its own method for storing and communicating data, and in many cases, different methods even for different models from the same vendor. More critically, in cases where the data format is reasonably clear, metadata are not easily attainable, and in some cases, not accurate, greatly diminishing the utility of the data. These issues can only be remedied with the application of a detailed but flexible standard to the data reporting formats for ESS data. Such a standard must include both mandatory information (such as location), and sensor-dependent information (the data available by virtue of the sensors at that location). The Clarus System must also address missing data, since some current systems do not differentiate between nominal and missing data. Once the data are collected by the Clarus System, they will need to be converted to a standard format.  This standard format should have the same data element definitions that are used by the standardized weather message set.

4.2 Data Integration and Management

The architectural framework found within the National Intelligent Transportation Systems (ITS) Architecture is a valuable guide on integration of information from ESS networks. Although more research on the needs of the user community will be required as the Clarus System evolves, the pros and cons of database architectures and concepts as they apply to the Clarus Initiative must be considered. One of the biggest issues for the Clarus System may simply be the volume of data involved (not so much the number of bytes, but more the number of observations). ESS data may include data from a variety of sensors (including video cameras) and the frequency of observations can be as high as once per minute. The VII Initiative’s vehicular data will present a much bigger data storage problem, as these vehicles may report data at intervals of one second or less. Regardless of the chosen database format, the Clarus System should be abstracted and modularized to the point that any new data stream can be handled with minimal effort and without disruption to the streams that are already present within the system.

Several types of database concepts may be applied in the Clarus System. One option is a hierarchical database. As implied by its name, data in a hierarchical database is stored in a hierarchy, usually utilizing a directory structure on a file system. This is a very straightforward means of organizing data. The subdirectories of the hierarchy are used to group the data with other data with similar attributes (such as sensor, time, source, etc.).

A second database concept that could be adopted within the Clarus System is a relational database. A relational database would collect data items organized as a set of formally described tables from which data would be accessed or reassembled in many different ways without having to reorganize the database tables. One of the largest advantages of utilizing a relational database is the power of being able to easily use high-level languages such as the structured query language (SQL) to query and access the data. Further, scripting languages such as Perl, Tcl, Python, Ruby, and PHP greatly facilitate the quick development of high-level abstractions of the data. Although careful thought must be given to the layout of the tables in a relational database in order to optimize performance, they are generally easy to create and have another important advantage of being easy to extend. After the original database creation, a new data category can be added without requiring that all existing applications be modified.

A critical aspect of the Clarus System will be the speed of data throughput. Whatever database structure is utilized, the usefulness of the Clarus System will likely depend upon the ability of the end user to extract desired data with minimal latency. It is therefore essential that the Clarus System database system anticipate the common current and future applications of a surface transportation weather database. Clarus, fundamentally, is a system to collect, store, and disseminate near-real-time data. Thus, the priority must be on the rapid storage and retrieval of data. Although Clarus does not directly address the needs associated with archived data, inclusion of Clarus data within long-term data holdings is critical for application of the data in future research and analysis efforts. At present, no such national historical archive exists for surface transportation weather data at any federal, state, university or private sector location within the United States.  In order to ensure that the real-time system operates at peak efficiency and with minimum latency the Clarus archives would likely need to reside on a separate server. However, the conceptual design of such an archive system is intertwined with the Clarus design and should be a consideration in the Clarus system design and development process.

The efficiency and reliability of the Clarus System may depend upon whether it is a centralized National system or a series of regional databases. Regional databases have the advantage of breaking the quantity of data down into a size that is easier to manage, and can possibly reduce latencies in retrieving data for regional users. Since many users will likely seek the data only from small regions, this method could work well. More compelling reasons, however, exist for a National database. First, users may need access to data from multiple regions, and accessing multiple databases to acquire the data defeats one of the fundamental purposes for developing Clarus. Second, the quality control (QC) modules will need to make use of data over a continuous plane. Thus, arbitrary divisions into regions could hamper QC efforts, unless there is an overlap of regions, which would further complicate the scenario and increase overhead.

Finally, the operation of several regional database centers would undoubtedly cost more in the long run than one efficient center. Despite the scope of the challenge, it does appear likely that a National database would be best for the project. The few apparent advantages of regional servers can likely be overcome with redundant centralized systems and an allowance for major stakeholders to host Clarus mirror servers on a regional basis or even on their internal networks. This latter configuration could be used by a State DOT to make Clarus data available to its personnel without the problems associated with Internet access while having the additional benefit of reducing bandwidth loads on the Clarus System.

4.3 Data Validation and Quality Control

Quality control (QC) of surface transportation weather and road/route observations presents special challenges not faced with many observing networks. In general, the quality of ESS data is not uniform due to varied calibration and maintenance practices, sensor quality, and sensor siting issues. A rigorous data QC and data qualification process is therefore necessary to ensure that suspect or otherwise unrepresentative data are not disseminated to outside systems and users without appropriate quality assurance and metadata information.

Quality control of ESS and other road weather observations presents some unique challenges. For example, a faulty road condition sensor that is reporting, “Dry” may be difficult to catch until a significant precipitation event occurs. The QC flagging process would need to be robust enough to remember that the sensor was flagged as bad and not get tricked into unflagging the sensor simply because it gets exposed to an extended period of dry weather again. Likewise, the QC needs to be multivariate in that spatial or temporal consistency checks on any given variable must take into account the whole situation at each site. For example, a midsummer pavement temperature observation of 65° F may appear incorrect when compared to surrounding observations of well over 120° F in a spatial consistency check, but this situation occurs frequently in the real world when isolated thunderstorms occur. This is a relatively simple situation for a human to recognize, but is much more difficult to handle with a software program. As described in all of the Use Case Scenarios it will be necessary to draw upon observational datasets external to the Clarus System for QC processes.

The ability of users to accept and utilize ESS information with additional quality control measures will serve to vastly enhance the applicability of the data.  However, metadata information associated with each observation is equally as important. Since the locations of ESS and other surface transportation weather observations are often dictated by the location of troublesome stretches of roadway, many of these observations come from unrepresentative areas by design. The metadata that reveals this situation to the data user therefore becomes very important to the user community in deciding how that data might be reasonably applied.

4.4 Data Availability and Distribution

Data availability, data distribution and the user-friendliness of these processes are vital to the success of Clarus. The Clarus System must support the common modes of access of the various user communities and should support on-the-fly reformatting of exported data to meet the user’s needs. In many cases, the data will be imported into other software applications that can enhance the usefulness of that data. The Clarus System Design should provide methods of multiple data delivery formats to support the user’s ability to receive data in formats that facilitate effective utilization of the Clarus data.  Scheduled, request-based, publish/subscribe and data-driven data distribution methodologies must all be supported.  Use of evolving methods such as the Canadian Meteorological Markup Language (CMML) and the Japanese Road Web Markup Language (RWML) to communicate data across platforms must be considered in achieving effective availability. Both user-friendly and system-friendly access to Clarus is critical for the usability and long-term success of the system.

As of 2004, approximately 2,500 ESS were taking point-specific measurements and observations of meteorological, hydrologic and pavement conditions. This figure will continue to grow over the next decade, perhaps exponentially as mobile observing platforms become more common. The frequency of observation within this network varies widely based upon the operational needs of the managing agency. Although observations are generally taken at least once every 10 to 15 minutes, the cost of communications between the collection points and the remote processing units (RPUs) often dictates that the data is actually retrieved at less frequent intervals.

Since the value of this data generally decreases quickly after the time of observation, especially in critical situations where conditions are changing quickly, processing and redistributing the data with a minimum latency is a primary operational concern of the Clarus Initiative. The variable observation times of ESS networks coupled with the internal processing functions of the Clarus System (communications techniques, data consolidation for quality control, collection of site reports for regional report lists) considerably impact the potential data latency. The Clarus design must carefully weigh the requirements for a structured delivery format against the need for minimal data latency.

ESS data have the potential to fill significant holes within the surface weather observation network. Many sensors are placed far from other sources of weather information specifically to address data voids, and in these situations, provide a vital link to conditions in a generally isolated area. Even in locations where they are nearly co-located with stations from other networks, the addition of more sensors can lend increased confidence in meteorological data QC processes.

The envisioned relationship between Clarus and ISOS is illustrated in Figure 17. ISOS is comprised of many National-scale weather observation systems, each a product of automated weather data collection and generally geared toward a particular end use (e.g. aviation, fire, agriculture, radar, satellite, upper air, water supply, etc.). Each of the systems has its own particular sensor siting and operational characteristics. Although the Clarus System is envisioned to become a component of ISOS, its organizational structure itself provides logic applicable to the problem of bringing together all the surface transportation weather observations under a single nationwide system.

Figure 17. The Relationship Between Clarus and the Integrated Surface Observing System (ISOS) Infrastructure.

The model for central points of data collection within the National weather venue has proven valuable and reliable. The Clarus System will provide a central collection point for surface transportation-based weather observations that can be incorporated into the national observational infrastructure through accepted existing operational methods. Similar central collection points presently exist within the national observing framework including those of the National Environmental Satellite Data Information Service (NESDIS) for managing collection and quality control of information from the constellation of earth observing satellites, the National Climatic Data Center for managing collection and quality control of data from the national network of Doppler weather radars, and the FAA AWOS Data Acquisition System (ADAS) that is maintained in each of the 22 Air Route Traffic Control Centers nationwide.

The purpose of these central collection points is to manage the high volume of observational traffic and to provide for coordinated entry of data into ISOS.  This concept is consistent with the anticipated operation of Clarus, which will have the responsibility of collecting, storing, quality controlling, and distributing surface transportation weather observations, providing the coordinated entry of this data into the NSWOS, and making the information available for stakeholder data users.

The fragmented physical architecture of existing ESS networks has been identified as one of the major obstacles that must be overcome with Clarus. At a most fundamental level, existing systems may be integrated into the Clarus System in a data flow approach. This is the model presently used by MesoWest, a research collaborative housed at the University of Utah that integrates information from many dissimilar automated weather observation systems.  This tiered model of data integration can provide an intermediary step in the deployment of Clarus. In this case, it is envisioned that the existing weather observation systems maintained by the individual surface transportation system operators deliver data in a standardized format to Clarus. This configuration has historically limited the time horizon of data at a National tier to a longer period than at the local, e.g. hourly versus fifteen minute, due to parsing, quality assurance, and processing time requirements. A challenge and design opportunity of Clarus is to place all three tiers in real time on a nationwide scale.

4.5 Clarus Subsystem Components and the Relationships between Components

The operation of the Clarus System will involve five major components (Figure 18):

1. collection of ESS and related data from the Autonomous Layer into a Clarus central and/or regional spatial database server;
2. the Clarus database systems;
3. quality control of data within the Clarus database(s);
4. maintaining and storing special metadata information associated with the data; and
5. dissemination of Clarus data to the stakeholder community.

Figure 18. Components Central to the Clarus System Design.

These components are in addition to the elements outside of Clarus that will be required to support the Clarus Initiative. These include the sensors that collect environmental data (either fixed or mobile), the communications systems, and the software utilized by the User to acquire and turn Clarus data into applications and information for the User Client (e.g., the traveling public, maintenance operations, etc.).  

One significant component not within the Clarus System, but central to the success of Clarus, is the collection of the data by indigenous statewide or regional networks that will subsequently be collected by Clarus. This includes fixed and mobile ESS data, road and route condition observations, and perhaps even winter maintenance data as automated maintenance activities data collection becomes more commonplace. A significant portion of this data collection is already in place and will require limited design effort aside from identification of existing deployments.  These data collection networks represent the one area that is almost entirely out of the direct control of the Clarus System management. Issues associated with this non-Clarus component will require the understanding of data distribution restrictions, proprietary data formats and data, real and perceived liability issues pertaining to ESS data redistribution, and the definition of ownership of the observed data.

The first Clarus subsystem component provides a significant challenge since Clarus must establish interfaces that permit off-loading of data from primarily vendor-specific equipment and databases onto the Clarus System. Many of these vendor databases and their communications interfaces are, at least initially, non-NTCIP compliant and/or proprietary. Often, these databases reside behind firewalls that may require considerable negotiation with information technology personnel to penetrate. These two issues pose significant obstacles to Clarus’ development. Data may either be pushed or pulled into the Clarus System depending upon the agreements negotiated with data providers. Some data providers may be able to provide File Transfer Protocol (FTP) access for Clarus to retrieve data from their existing servers. In other situations, the data provider may maintain a server that contains the data but which does not support FTP or similar access to that data. Special procedures may need to be developed in order to allow the Clarus System to access data from these systems. In still other cases, Clarus may need to communicate directly with an ESS in order to retrieve data, possibly even resorting to the use of a dial-up modem. Once the data enters the Clarus System, some entry-level QC checks can be made (e.g., bounds checking).

The potential designs and obstacles for the Clarus database component were discussed earlier. Among those issues were the database design (hierarchical vs. relational) and the concepts of regional databases vs. a central redundant database. This second subsystem is the heart of the Clarus System and will require considerable forethought. The database must serve both present and anticipated user needs, must be kept flexible to acceptance of new types of data that are not presently available, must balance utility and user-friendliness with response time and system cost, and must possess a considerable degree of redundancy to prevent loss of service in the event of catastrophic equipment or communications failures. The Clarus database should be kept isolated from the varied and often proprietary data formats of much of the data available from present ESS networks.

Once data has been stored in a unified format within the Clarus database, the third Clarus subsystem will then be able to request recent and incoming data from the Clarus database(s), perform validity as well as internal and spatial consistency checks on the data as a whole, and return quality control flags pertaining to the data back to the Clarus database(s). These quality flags will then be made available to the Clarus user in a simple format alongside the Clarus data. If the Clarus database ends up being developed as a relational database users may even limit their queries to return data that has not been flagged as suspect through simple statements within the SQL requests. The Clarus System will not attempt to correct or remove suspect data.

The fourth Clarus subsystem can be considered a metadata management system. This is a sorely needed element of the ESS networks of today. Users often misuse or are hesitant to use ESS data because, unlike most meteorological observing networks, these systems are often placed in unrepresentative areas for very specific monitoring purposes. Blind application of this data can often cause the ESS data to be more of a detriment than an asset. The lack of data qualification with a consistent metadata format is probably second only to insufficient routine maintenance and calibration as the leading cause of questionable data. Misunderstandings about the data source cause users to perceive the ESS network information as unreliable. The Clarus database must accommodate not only the data and associated quality control information, but also convenient ways for accessing and/or limiting information based on metadata attributes.

The final (and most visible) Clarus subsystem component is the delivery system. This system is comprised of the user interfaces, servers, and communications mechanisms used to retrieve data from the Clarus System. Since this is the only part of the Clarus System that will be a concern to most users, it is essential that it be user and system friendly and reliable. The delivery system needs to support both push and pull data distributions. Data pushing will permit scheduled delivery, possibly through a publish and subscription mechanism, of Clarus data to end users needing a steady supply of information for their applications, including routine delivery to the NSWOS for integration with other weather data types. Once within the NSWOS, the data is also available for distribution through established dissemination methods such as the National Weather Service Telecommunications Gateway.

Data-driven push methods can also help to reduce latencies for users needing near real-time access to data, as the system can automatically distribute data to waiting parties as soon as it becomes available rather than waiting for the user to query or poll for it. Data pull methods of access should include the use of web portals for display and/or download of user-selected data as well as support of FTP or similar access to the data. This subsystem should have a prioritized data caching capability for data that is time critical. Since many users will have a desire to import Clarus data into other applications as a decision aid, it is envisioned that the Clarus System will have a primary standardized interface with some flexibility to translate different formats in which these users wish to retrieve or receive the data. This capability will lessen the need for middleware obstacles to perform data conversion and thus promote much broader application of Clarus data.

5 References

1. Clarus – The Nationwide Surface Transportation Weather Observing and Forecast System. Pisano, Pol, Stern, and Goodwin, TRB 2005, pp12.

2. National ITS Architecture, Version 5.1, April 2005, FHWA, U.S. DOT.

3. Weather Information in the National ITS Architecture Version 5.0, Meridian Environmental Technology, Inc., August 2004, pp. 58.

4. Clarus Initiative Coordinating Committee (ICC) Management Plan, Revision 1, September 2004, James Pol, U.S. DOT.

5. Surface Transportation Weather Decision Support Requirements, Version 1.0, January 2000, Mitretek Systems, Inc., p. 150.

6. Weather Information for Surface Transportation: National Needs Assessment Report, Office of the Federal Coordinator for Meteorology, FCM-R18-2002, pp 298.

7. Weather and Environmental Content on 511 Services, Deployment Assistance Report #6, June, 2003, ITS America, 511 Deployment Coalition.

8. NTCIP 1204 v02, Environmental Sensor Station Interface Standard – Version 02, version 02.23b, July 2005, published by the National Electrical Manufacturers’ Association, the American Association of State Highway and Transportation Officials, and the Institute of Transportation Engineers.

9. Where the Weather Meets the Road: A Research Agenda for Improving Road Weather, 2004, The National Academies, BASC-U-02-06-A.

10. Road Weather Information Systems (RWIS) Data Integrations Guidelines, October 2002, Castle Rock Consultants, p. 69.

11. Draft Report: Joint TMC/TOC System Integration Study for Emergency Transportation Operations and Weather: Baseline Conditions, Battelle, 2004, (in review).

12. Weather Information for Surface Transportation (WIST) Initiative Paper, First  Steps to Improve the Nation’s WIST Capabilities and Services, July 2005, Office of the Federal Coordinator for Meteorology, page 13.

Appendix A – Clarus Use Case Actor Descriptions

A.1 Clarus Manually Entered Data Collector

The Clarus Manually Entered Data Collector actor allows for the collection of data pertinent to Clarus through a Human-Machine Interface (HMI). This capability allows Clarus users to supplement weather-related information received via other systems through a manual entry mechanism.

A.2 Clarus Operator

The Clarus Operator actor manages the collection, integration and dissemination of all data within the Clarus System.

A.3 Commercial Vehicle

The Commercial Vehicle actor provides the sensory, processing, storage, and communications functions necessary to support safe and efficient commercial vehicle operations. Commercial Vehicles could provide vehicle identification, location, wiper system state, exterior temperature, rain sensor status, sun sensor status, fog lamp status, and traction control state.

A.4 Commercial Vehicle Fleet Operations

The Commercial Vehicle Fleet Operations actor provides the capability for commercial drivers and fleet managers to receive weather information and to monitor the safety and security of their commercial vehicle drivers and fleet.

A.5 Emergency Management Operations

The Emergency Management Operations actor represents the humans and systems that monitor all emergency requests, (including those from the E911 Operator) and sets up pre-defined responses to be executed by an emergency management system. Based on received weather information, Emergency Management Personnel may also override predefined responses where it is observed that they are not achieving the desired result. This actor includes dispatchers who manage an emergency fleet (police, fire, ambulance, HAZMAT, etc.) or higher order emergency managers who provide response coordination during emergencies.

A.6 Emergency Vehicle

The Emergency Vehicle actor provides the sensory, processing, storage, and communications functions necessary to support safe and efficient incident response. Emergency Vehicles could provide vehicle identification, location, wiper system state, exterior temperature, rain sensor status, sun sensor status, fog lamp status, and traction control state.

A.7 ESS Data Collector

The ESS Data Collector actor collects ESS measurement data from the ESS Equipment actor.

A.8 ESS Equipment

The ESS Equipment actor represents the Environmental Sensor Stations collecting environmental data as well as Railroad ESS monitoring the wayside.

A.9 Information Service Provider

The Information Service Provider (ISP) actor collects, processes, stores, and disseminates transportation information to system operators and the traveling public. The ISP delivers traveler information to subscribers and the public at large. Information provided includes weather information, basic advisories, traffic and road/route conditions, transit schedule information, yellow pages information, ride matching information, and parking information. The ISP can utilize both basic one-way (broadcast) and personalized two-way information communication. The ISP provides the capability for an informational infrastructure to connect providers and consumers.

A.10 Maintenance and Construction Vehicle

The Maintenance and Construction Vehicle actor provides the sensory, processing, storage, and communications functions necessary to support highway maintenance and construction. All types of maintenance and construction vehicles are covered, including heavy equipment and supervisory vehicles. A wide range of operational status is monitored, measured, and made available, depending on the specific type of vehicle or equipment. For example, for a snowplow, the information would include whether the plow is up or down and material usage information. The actor may also contain capabilities to monitor vehicle systems to support maintenance of the vehicle itself and other sensors that monitor environmental conditions including the road condition and surface weather information. This actor can represent a diverse set of mobile environmental sensing platforms, including wheeled vehicles and any other vehicle that collects and reports environmental information. Maintenance and Construction Vehicles could provide vehicle identification, location, wiper system state, exterior temperature, rain sensor status, sun sensor status, fog lamp status, and traction control state.

A.11 NOAA (ISOS)

This actor represents NOAA's Integrated Surface Observation System (ISOS), which is envisioned to be a National Mesonet.

A.12 NOAA (non-ISOS)

This actor represents NOAA's systems that do not include the Integrated Surface Observation System (ISOS), which is envisioned to be a National Mesonet.

A.13 NOAA Collector for Clarus Data

The National Oceanic and Atmospheric Administration, which runs the National Weather Service (NWS), that provides weather, hydrologic, and climate information and warnings of hazardous weather including thunderstorms, flooding, hurricanes, tornadoes, winter weather, tsunamis, and climate events. It provides atmospheric weather observations and forecasts. The interface provides formatted weather data products suitable for on-line processing and integration with other ITS data products as well as Doppler radar images, satellite images, severe storm warnings, and other products that are formatted for presentation to various ITS users. The NOAA Collector for Clarus represents the NOAA interface point that receives the weather information processed by the Clarus System.

A.14 NOAA Integrator

The NOAA Integrator actor represents the NOAA interface point where NOAA's processed data are disseminated to other systems including the Clarus System and other Weather Service Providers.

A.15 NOAA Research

The NOAA Research actor represents the NOAA research activities that utilize archived NOAA weather data.

A.16 Non-Surface Observations

The Non-Surface Observations actor represents the collection of atmospheric weather observation data by both International and U.S equipment.

A.17 Private Sector Weather Observation Equipment

The Private Sector Weather Observation Equipment actor represents environmental sensing equipment that provides weather observation data to Private Weather Service Providers.

A.18 Private Surface Transportation Weather Service Provider

The Private Surface Transportation Weather Service Provider actor receives data from the Clarus System and provides value-added weather and surface transportation data integration and interpretation to the Weather Information User Community.

A.19 Private Vehicle

The Private Vehicle actor provides the sensory, processing, storage, and communications functions necessary to support efficient, safe, and convenient travel. Private Vehicles could provide anonymous vehicle identification, location, wiper system state, exterior temperature, rain sensor status, sun sensor status, fog lamp status, and traction control state.

A.20 Private Weather Data Collector

The Private Weather Data Collector actor collects data and provides it to the Clarus System based on its weather observation equipment. Together with the Private Weather Data Disseminator actor, the Private Weather Data Collector provides all of the general weather data interfaces for the Private Weather Service Provider.

A.21 Private Weather Data Disseminator

The Private Weather Data Disseminator actor receives data from the Clarus System and provides value-added general weather data integration and interpretation to the Weather Information User Community.

A.22 Private Weather Service Provider

The Private Weather Service Provider actor provides data to the Clarus System based on its weather observation equipment. The Private Weather Service Provider integrates, transforms and interprets general weather data including data from the Clarus System for dissemination to the Weather Information User Community.

A.23 Public Sector Weather Observation Equipment (non-NOAA)

The Public Sector Weather Observation Equipment (non-NOAA) actor represents other environmental sensing equipment besides ESS that provides weather observation data to Public Weather Data Collectors other than NOAA.

A.24 Public Surface Transportation Weather Service Provider

The Public Surface Transportation Weather Service Provider actor receives data from the Clarus System and provides value-added weather and surface transportation data integration and interpretation to the Weather Information User Community.

A.25 Public Weather Data Collector (non-NOAA)

The Public Weather Data Collector (non-NOAA) actor collects data and provides it to the Clarus System based on its weather observation equipment. Together with the Public Weather Data Disseminator actor, the Public Weather Data Collector provides all of the general weather data interfaces for the Public Weather Service Provider.

A.26 Public Weather Data Disseminator

The Public Weather Data Disseminator actor receives data from the Clarus System and provides value-added general weather data integration and interpretation to the Weather Information User Community.

A.27 Railroad Management Operations

The Railroad Management Operations actor represents the management systems and people responsible for making decisions regarding rail operations based on received weather information.

A.28 Railroad Vehicle

The Railroad Vehicle actor provides the sensory, processing, storage, and communications functions necessary to support rail operations. The Railroad Vehicle may be a train, locomotive, railroad maintenance vehicle or other vehicle that traverses the railway. Railroad Vehicles could provide vehicle identification, location, wiper system state, exterior temperature, rain sensor status, sun sensor status, fog lamp status, and traction control state.

A.29 Roadway Condition Collector

The Roadway Condition Collector actor represents the transportation agency collection of weather-related surface conditions, road/route conditions, CCTV images and radar derived data from the Roadway Condition Equipment.

A.30 Roadway Condition Equipment

The Roadway Condition Equipment actor represents transportation agency equipment that detects weather-related surface conditions and road/route conditions as well as CCTV images and flooding e.g., stream gauges).

A.31 Roadway Construction Operations

The Roadway Construction Operations actor monitors and manages roadway infrastructure construction activities. Representing both public agencies and private contractors that provide these functions, this actor manages fleets of construction vehicles. This actor receives a wide range of status information from these vehicles and performs vehicle dispatch, routing, and resource management for the vehicle fleets and associated equipment. The actor manages equipment at the roadside, including environmental sensors and automated systems that monitor and mitigate adverse road and surface weather conditions. Additional interfaces to weather information providers (the weather service and surface transportation weather service providers) provide current and forecast weather information that can be fused with other data sources and used to support advanced decision support systems that increase the efficiency and effectiveness of construction operations.

A.32 Roadway Seasonal (non-Winter) Maintenance Provider

The Roadway Seasonal (non-Winter) Maintenance Provider actor monitors and manages roadway infrastructure for non-winter maintenance activities (e.g., road striping). Representing both public agencies and private contractors that provide these functions, this actor manages fleets of non-winter maintenance, or special service vehicles (e.g., pot hole-filling equipment). The actor receives a wide range of status information from these vehicles and performs vehicle dispatch, routing, and resource management for the vehicle fleets and associated equipment. This actor manages equipment at the roadside, including environmental sensors and automated systems that monitor and mitigate adverse road and surface weather conditions. This actor manages the repair and maintenance of both non-ITS and ITS equipment including the traffic controllers, detectors, dynamic message signs, signals, and other equipment associated with the roadway infrastructure. Additional interfaces to weather information providers (the weather service and surface transportation weather service providers) provide current and forecast weather information that can be fused with other data sources and used to support advanced decision support systems that increase the efficiency and effectiveness of non-winter maintenance operations.

A.33 Roadway Winter Maintenance Operations

The Roadway Winter Maintenance Operations actor monitors and manages roadway infrastructure winter maintenance activities. Representing both public agencies and private contractors that provide these functions, this actor manages fleets of winter maintenance, or special service vehicles (e.g., snow and ice control equipment). The actor receives a wide range of status information from these vehicles and performs vehicle dispatch, routing, and resource management for the vehicle fleets and associated equipment. This actor manages equipment at the roadside, including environmental sensors and automated systems that monitor and mitigate adverse road and surface weather conditions. This actor manages the repair and maintenance of both non-ITS and ITS equipment including the traffic controllers, detectors, dynamic message signs, signals, and other equipment associated with the roadway infrastructure. Additional interfaces to weather information providers (the weather service and surface transportation weather service providers) provide current and forecast weather information that can be fused with other data sources and used to support advanced decision support systems that increase the efficiency and effectiveness of winter maintenance operations.

A.34 Roadway Service Patrol Vehicle

The Roadway Service Patrol Vehicle actor provides the sensory, processing, storage, and communications functions necessary to support emergency assistance to vehicles on the freeway. Roadway Service Patrol Vehicles could provide vehicle identification, location, wiper system state, exterior temperature, rain sensor status, sun sensor status, fog lamp status, and traction control state.

A.35 Surface Observation Networks

The Surface Observation Networks actor represents all of the observations from the surface of the earth including both International and U.S equipment.  These observations are fed into NOAA’s ISOS.

A.36 Traffic Management Operations

The Traffic Management Operations actor monitors and controls traffic and the road network. It represents centers that manage a broad range of transportation facilities including freeway systems, rural and suburban highway systems, and urban and suburban traffic control systems. This actor monitors and manages traffic flow and monitors the condition of the roadway, surrounding environmental conditions, and field equipment status.

A.37 Transit Management Operations

The Transit Management Operations actor manages transit vehicle fleets and coordinates with other modes and transportation services. It provides operations, maintenance, customer information, planning and management functions for the transit property. It spans distinct central dispatch and garage management systems and supports the spectrum of fixed route, flexible route, paratransit services, transit rail, and bus rapid transit (BRT) service. This actor takes into account current and forecasted weather conditions when deciding on current and future transit service levels.

A.38 Transit Vehicle

The Transit Vehicle actor provides the sensory, processing, storage, and communications functions necessary to support safe and efficient movement of passengers. The types of transit vehicles contained in this actor include buses, paratransit vehicles, light rail vehicles, other vehicles designed to carry passengers, and supervisory vehicles. Transit Vehicles could provide vehicle identification, location, wiper system state, exterior temperature, rain sensor status, sun sensor status, fog lamp status, and traction control state.

A.39 Travelers

The Travelers actor collects, processes, stores, and disseminates transportation information to system operators and the traveling public. The actor can play several different roles in an integrated ITS. In one role, the Traveler actor provides a general data warehousing function, collecting information from transportation system operators and redistributing this information to other system operators in the region and other ISPs. In this information redistribution role, the Traveler actor provides a bridge between the various transportation systems that produce the information and the other ISPs and their subscribers that use the information. In a second role, a Traveler actor is focused on delivery of traveler information to subscribers and the public at large. Information provided includes basic advisories including weather, traffic and road/route conditions, transit schedule information, yellow pages information, ride matching information, and parking information. In a third role, the Traveler actor may be dedicated to, or even embedded within, the dispatch system.

A.40 Vehicle

The Vehicle actor provides the sensory, processing, storage, and communications functions necessary to support safe vehicle travel on the roadway. Vehicles could provide vehicle identification, location, wiper system state, exterior temperature, rain sensor status, sun sensor status, fog lamp status, and traction control state.

A.41 Vehicle Data Collector

The Vehicle Data Collector actor collects Vehicle measurement data from the various Vehicle actors. The Vehicle Data Collector could be the roadside collection units or a secondary aggregated collection unit that may be part of the US DOT VII Initiative.

A.42 Weather Information User Community

The Weather Information User Community actor represents the entire user community of Clarus System data including both public and private sector users.

 

Appendix B – Use Case Descriptions

B.1    Archive Weather Data Use Case

The Archive Weather Data use case is part of the NOAA processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case takes the environmental data collected from the NOAA ISOS and non-surface weather observation systems and combines it with the pertinent Clarus data for archival and use by NOAA’s research community.

B.2   Check and Flag Collected ESS Data Use Case

The Check and Flag Collected ESS Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is responsible for checking and flagging the collected ESS data. This first phase of the Clarus quality control process will check for out-of-tolerance limits and other data characteristics that would require flagging of the data based on individual ESS measurements. The Clarus Operator will have the capability to fine-tune the algorithm parameters that does the checking and setting of flagging thresholds.

B.3   Check and Flag Manually Entered Data Use Case

The Check and Flag Manually Entered Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is responsible for checking and flagging manually entered data into the Clarus System.  The manually entered data includes environmental conditions, roadway conditions and weather nowcasts and forecasts. This first phase of the Clarus quality control process will check for out-of-tolerance limits and other data characteristics that would require flagging of the data based on the manually entered data. The Clarus Operator will have the capability to fine-tune the algorithm parameters that does the checking and setting of flagging thresholds.

B.4   Check and Flag Non-Clarus External Environment Data Use Case

The Check and Flag Non-Clarus External Environment Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is responsible for checking and flagging the collected non-Clarus external environment data from NOAA and other service providers. This first phase of the Clarus quality control process will check for out-of-tolerance limits and other data characteristics that would require flagging of the data from NOAA or the Service Providers. It is preferred that raw sensor data be collected along with any standardized metadata. If the data has been pre-processed, Clarus would need to know what type of processing has been performed on the data in order to use it in further processing by the Clarus System. The Clarus Operator will have the capability to fine-tune the algorithm parameters that does the checking and setting of flagging thresholds and possible preprocessing constraints.

B.5   Check and Flag Road Condition Data Use Case

The Check and Flag Road Condition Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is responsible for checking and flagging the collected road condition data. This first phase of the Clarus quality control process will check for out-of-tolerance limits and other data characteristics that would require flagging of the data based on individual road condition measurements. The Clarus Operator will have the capability to fine-tune the algorithm parameters that does the checking and setting of flagging thresholds.

B.6   Check and Flag Vehicle Data Use Case

The Check and Flag Vehicle Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is responsible for checking and flagging the collected vehicle data. This first phase of the Clarus quality control process will check for out-of-tolerance limits and other data characteristics that would require flagging of the data based on individual vehicle measurements. The Clarus Operator will have the capability to fine-tune the algorithm parameters that does the checking and setting of flagging thresholds.

B.7   Collect Non-Surface Observations Use Case

The Collect Non-Surface Observations use case is part of the NOAA processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is responsible for collecting non-surface (e.g., atmospheric) weather observations for NOAA.

B.8   Collect Surface Observations Use Case

The Collect Surface Observations use case is part of the NOAA processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is responsible for collecting surface (e.g., temperatures) weather observations for NOAA as part of the ISOS (Integrated Surface Observing System).

B.9   Compare ESS, Vehicle and Road Condition Data with External
Weather Data Use Case

The Compare ESS, Vehicle and Road Condition Data with External Weather Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case takes the phase 1 quality controlled ESS, Roadway Condition, Vehicle, Manually Entered Weather Data and External Weather data and compares it by similar geographic location and type as part of the phase 2 quality control. The Clarus Operator will have the capability to fine-tune the algorithm parameters that does the comparing and setting of flagging thresholds.

B.10 Generate General Weather Nowcasts and Forecasts Use Case

The Generate General Weather Nowcasts and Forecasts use case is part of the NOAA processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case takes the environmental data collected from the NOAA ISOS and non-surface weather observation systems and combines it with the pertinent Clarus data to create general weather nowcasts and forecasts.

B.11 Generate NOAA Numerical Forecasts Use Case

The Generate NOAA Numerical Forecasts use case is part of the NOAA processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case takes the environmental data collected from the NOAA ISOS and non-surface weather observation systems and combines it with the pertinent Clarus data to create numerical forecasts.

B.12 Generate Severe Weather Forecasts Use Case

The Generate Severe Weather Forecasts use case is part of the NOAA processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case takes the environmental data collected from the NOAA ISOS and non-surface weather observation systems and combines it with the pertinent Clarus data to create severe weather forecasts.

B.13 Integrate and Transform Service Provider Data Use Case

The Integrate and Transform Service Provider Data use case is part of the Service Provider processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case integrates the public (non-NOAA) and private weather data in preparation for the use by public and private general and surface transportation-specific weather service providers.

B.14 Integrate NOAA Data Use Case

The Integrate NOAA Data use case is part of the NOAA processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case integrates the ISOS and non-ISOS (non-surface weather observations) data in preparation for the generation of numerical forecasts, severe weather forecasts, general weather nowcasts and forecasts and data archival.

B.15 Provide ESS Measurements Use Case

The Provide ESS Measurements use case is outside of the Clarus, NOAA and Service Provider processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). The purpose of this use case is solely to depict end-to-end functionality. This use case takes the ESS measurements from each ESS Equipment actor, which could be either publicly or privately owned, and sends the data to the ESS Data Collector actor.

B.16 Provide NOAA Weather Data Use Case

The Provide NOAA Weather Data use case is part of the NOAA processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case represents the transfer of NOAA data to the Traveler actor and the Weather Information User Community actor. The Weather Information User Community actor represents the following surface transportation users as depicted in Figure 13: Commercial Vehicle Fleet Operations, Emergency Management Operations, Railroad Management Operations, Roadway Construction Operations, Roadway Seasonal (Non-Winter) Maintenance Operations, Roadway Winter Maintenance Operations, Transit Management Operations and Traffic Management Operations.

B.17 Provide Private Weather Data Use Case

The Provide Private Weather Data use case is part of the Service Provider processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case processes data from Private Sector Weather Observation Equipment to Private Weather Data Collectors.

B.18 Provide Public Weather Data (non-NOAA) Use Case

The Provide Public Weather Data (non-NOAA) use case is part of the Service Provider processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case processes data from Public Weather Observation Equipment (non-NOAA) to Public Weather Data Collectors (non-NOAA).

B.19 Provide Roadway Conditions Use Case

The Provide Roadway Conditions use case is outside of the Clarus, NOAA and Service Provider processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). The purpose of this use case is solely to depict end-to-end functionality. This use case takes the roadway conditions (e.g., pavement, route) from each Roadway Condition Equipment actor, which could be either publicly or privately owned, and sends the data to the Roadway Condition Collector actor.

B.20 Provide Traveler Information Use Case

The Provide Traveler Information use case is part of the Service Provider processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is where the Information Service Provider disseminates their value-added weather information affecting travelers to the Travelers actor for no or minimal cost. It is expected that in the future 5-1-1 traveler information systems will contain weather information to assist travel planning and notification.

B.21 Provide Value-added Private Surface Transportation Weather

Information Use Case

The Provide Value-added Private Surface Transportation Weather Information use case is part of the Service Provider processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is where the Private Surface Transportation Weather Service Provider disseminates their value-added weather information affecting the surface transportation network to the Weather Information User Community. The Weather Information User Community actor represents the following surface transportation users as depicted in Figure 13: Commercial Vehicle Fleet Operations, Emergency Management Operations, Railroad Management Operations, Roadway Construction Operations, Roadway Seasonal (Non-Winter) Maintenance Operations, Roadway Winter Maintenance Operations, Transit Management Operations and Traffic Management Operations.

B.22 Provide Value-added Private Weather Information Use Case

The Provide Value-added Private Weather Information use case is part of the Service Provider processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is where the general Private Weather Service Provider disseminates their value-added weather information to the Weather Information User Community. The Weather Information User Community actor represents the following surface transportation users as depicted in Figure 13: Commercial Vehicle Fleet Operations, Emergency Management Operations, Railroad Management Operations, Roadway Construction Operations, Roadway Seasonal (Non-Winter) Maintenance Operations, Roadway Winter Maintenance Operations, Transit Management Operations and Traffic Management Operations.

B.23 Provide Value-added Public Surface Transportation Weather
Information Use Case

The Provide Value-added Public Surface Transportation Weather Information use case is part of the Service Provider processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is where the Public Surface Transportation Weather Service Provider disseminates their value-added weather information affecting the surface transportation network to the Weather Information User Community. The Weather Information User Community actor represents the following surface transportation users as depicted in Figure 13: Commercial Vehicle Fleet Operations, Emergency Management Operations, Railroad Management Operations, Roadway Construction Operations, Roadway Seasonal (Non-Winter) Maintenance Operations, Roadway Winter Maintenance Operations, Transit Management Operations and Traffic Management Operations.

B.24 Provide Value-added Public Weather Information Use Case

The Provide Value-added Public Weather Information use case is part of the Service Provider processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is where the general Public Weather Service Provider disseminates their value-added weather information to the Weather Information User Community. The Weather Information User Community actor represents the following surface transportation users as depicted in Figure 13: Commercial Vehicle Fleet Operations, Emergency Management Operations, Railroad Management Operations, Roadway Construction Operations, Roadway Seasonal (Non-Winter) Maintenance Operations, Roadway Winter Maintenance Operations, Transit Management Operations and Traffic Management Operations.

B.25 Provide Vehicle Measurements Use Case

The Provide Vehicle Measurements use case is outside of the Clarus, NOAA and Service Provider processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). The purpose of this use case is solely to depict end-to-end functionality. This use case takes the Vehicle measurements from each Vehicle actor, which could be either publicly or privately owned, and sends the data to the ESS Data Collector actor. The vehicles, as a minimum, fall into the following categories as depicted in Figure 14: Commercial Vehicle, Emergency Vehicle, Maintenance and Construction Vehicle, Private Vehicle, Railroad Vehicle, Roadway Service Patrol Vehicle or Transit Vehicle.

B.26 Send Flagged ESS Data Use Case

The Send Flagged ESS Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case takes the phase 1 quality control checked and flagged data and (1) forwards the information to the Clarus use case that compares ESS, Vehicle, and Road Condition Data with External Weather Data from NOAA and various types of service providers and (2) returns potential error metadata to the ESS Data Collector actor.

B.27 Send Flagged ESS, Road Condition and Vehicle QC'd Data to
Collectors Use Case

The Send Flagged ESS, Road Condition and Vehicle QC’d Data to Collectors use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case takes the phase 2 quality control checked and flagged data and (1) forwards the information to the Clarus use case that transfers this data to NOAA and the various service providers and (2) returns potential error metadata to the appropriate collection actor.

B.28 Send Flagged Road Condition Data Use Case

The Send Flagged Road Condition Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case takes the phase 1 quality control checked and flagged data and (1) forwards the information to the Clarus use case that compares ESS, Vehicle, and Road Condition Data with External Weather Data from NOAA and various types of service providers, (2) forwards the information to the Clarus data repository and (3) returns potential error metadata to the Road Condition Collector actor.

B.29 Send Flagged Vehicle Data Use Case

The Send Flagged Vehicle Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case takes the phase 1 quality control checked and flagged data and (1) forwards the information to the Clarus use case that compares ESS, Vehicle, and Road Condition Data with External Weather Data from NOAA and various types of service providers and (2) returns potential error metadata to the Vehicle Data Collector actor.

B.30 Store and Index Quality Controlled Data Use Case

The Store and Index Quality Controlled Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case stores and indexes the data received by Clarus and its associated metadata to the extent needed for the Clarus System quality control process. The Clarus operator has the capability to specify what data should be stored and method of indexing as well as data storage compression mechanisms.

B.31 Transfer ESS Data Use Case

The Transfer ESS Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is responsible for transferring the collected ESS data from the ESS Data Collector actor to the Clarus System.

B.32 Transfer External Weather Data Use Case

The Transfer External Weather Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is responsible for collecting the external weather data from NOAA and various weather data service providers including nowcasts, forecasts, and public or private environmental sensor data from sensors not directly connected to Clarus via the ESS, Roadway and Vehicle Data Collector actors.

B.33 Transfer of Clarus ESS, Vehicle and Road Condition Data and
Flags Use Case

The Transfer of Clarus ESS, Vehicle and Road Condition Data and Flags use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is responsible for taking the processed environmental data obtained from multiple sources and transferring it along with the pertinent metadata to NOAA and the various service providers. The Clarus operator has the capability to specify critical road/route environmental information processing priorities for the Clarus System.

B.34 Transfer Road Condition Data Use Case

The Transfer Road Condition Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is responsible for transferring the collected road condition data from the Roadway Condition Collector actor to the Clarus System.

B.35 Transfer Vehicle Data Use Case

The Transfer Vehicle Data use case is part of the Clarus System processing depicted on the Clarus System Framework Use Case Diagram (Figure 15). This use case is responsible for transferring the collected Vehicle data from the Vehicle Data Collector actor to the Clarus System.

 

Appendix C - Acronym List

AASHTO        American Association of State Highway and Transportation Officials

AMS               American Meteorological Society

ASOS             Automated Surface Observing System

CCTV             Closed-Circuit Television

DMS               Dynamic Message Signs

DoD                Department of Defense

DOT                Department of Transportation

DSS                Decision Support System

ESS                Environmental Sensor Station

FAA                Federal Aviation Administration

HAR                Highway Advisory Radio

ICC                 Initiative Coordinating Committee

IMT                  Initiative Management Team

ISP                  Information Service Provider

ITE                  Institute of Transportation Engineers

ITS                  Intelligent Transportation Systems

ITS America Intelligent Transportation Society of America

FHWA           Federal Highway Administration

MADIS            Meteorological Assimilation Data Ingest System

MDSS            Maintenance Decision Support System

MDT                Mobile Data Terminal

NASA             National Aeronautics and Space Administration

NHI                  National Highway Institute

NOAA             National Oceanic and Atmospheric Administration

NTCIP             National Transportation Communications for ITS Protocol

NSWOS        National Surface Weather Observing System

NWS               National Weather Service

PDA                Personal Digital Assistants

RWIS              Road Weather Information System

SEP               Systems Engineering Process

STWDSR      Surface Transportation Weather Decision Support Requirements

STWSP         Surface Transportation Weather Service Provider

TBDL              To Be Developed Later

TMC                Traffic Management Center

TRB                Transportation Research Board

UML                Unified Modeling Language

VII                    Vehicle Infrastructure Integration

VSL                Variable Speed Limit

WIST               Weather Information for Surface Transportation

Appendix D - Alternative Text

Alternative text for Figure 1

This conceptual map diagram is enhanced by example photos of ESS, vehicle, and external weather data sources and shows the flow direction including brief descriptions of data management steps. Clarus is shown in the center with its key functions of collecting, checking, flagging, and sending of RWIS and vehicle data, collecting external weather data and comparing it with RWIS and vehicle data, transferring the quality controlled data on to users. The data sources are shown to the left of Clarus and the data users are shown to the right. ESS field equipment is shown providing ESS data to a state agency RWIS computer from which Clarus collects it. Patrol or maintenance vehicle data is shown being gathered by a roadside data collector that provides it to the local agency vehicle location computer from which Clarus collects it. External weather data sources such as radar is shown being provided to a Weather Information Service Provider such as NOAA from which it is collected by Clarus. Surface Transportation Weather Information Service Provider is the sole recipient of data from Clarus. The Surface Transportation Weather Information Service Provider is also shown receiving integrated and transformed data from the Weather Information Service Provider. The Surface Transportation Weather Information Service Provider is shown providing observation and forecast data and decision support information along two separate paths to an end user. A Traffic Operations Center is shown in that role in this figure.

Back to Figure1

Alternative text for Figure 2

Figure 2 is a high level diagram that depicts the principal interfaces that are included in the Road Weather Data Collection Market Package. It includes the following subsystems and associated equipment packages:

Subsystem	Equipment Package
Emergency Management	Emergency Environmental Monitoring
Information Service Provider	ISP Traveler Data Collection
Maintenance and Construction Management	MCM Environmental Information Processing
Traffic Management	TMC Environmental Monitoring
Transit Management	Transit Environmental Monitoring

Direction arrowed lines that are labeled with a data description in the figure show the architecture flow.  This is described in the following table.

Source Subsystem / Terminator	Architecture Flow	Destination Subsystem / Terminator
Emergency Management	transportation weather information request	Surface Transportation Weather Service
Information Service Provider	transportation weather information request	Surface Transportation Weather Service
Maintenance and Construction Center Personnel	maintenance and construction center personnel inputs	Maintenance and Construction Management
Maintenance and Construction Management	road weather information	Emergency Management
Maintenance and Construction Management	road weather information	Information Service Provider
Maintenance and Construction Management	maintenance and construction operations information presentation	Maintenance and Construction Center Personnel
Maintenance and Construction Management	road weather information	Media
Maintenance and Construction Management	road weather information	Other MCM
Maintenance and Construction Management	road weather information	Rail Operations
Maintenance and Construction Management	road data	Surface Transportation Weather Service
Maintenance and Construction Management	road weather information	Surface Transportation Weather Service
Maintenance and Construction Management	transportation weather information request	Surface Transportation Weather Service
Maintenance and Construction Management	road weather information	Traffic Management
Maintenance and Construction Management	road weather information	Transit Management
Maintenance and Construction Management	road weather information	Weather Service
Other MCM	road weather information	Maintenance and Construction Management
Surface Transportation Weather Service	transportation weather information	Emergency Management
Surface Transportation Weather Service	transportation weather information	Information Service Provider
Surface Transportation Weather Service	transportation weather information	Maintenance and Construction Management
Surface Transportation Weather Service	transportation weather information	Traffic Management
Surface Transportation Weather Service	transportation weather information	Transit Management
Traffic Management	transportation weather information request	Surface Transportation Weather Service
Traffic Management	traffic operator data	Traffic Operations Personnel
Traffic Operations Personnel	traffic operator inputs	Traffic Management
Transit Management	transportation weather information request	Surface Transportation Weather Service
Weather Service	weather information	Emergency Management
Weather Service	weather information	Information Service Provider
Weather Service	weather information	Maintenance and Construction Management
Weather Service	weather information	Traffic Management
Weather Service	weather information	Transit Management

Back to Figure 2

Alternative text for Figure 3

Figure 3 is a high level diagram that depicts the principal interfaces that are included in the Weather Information Processing and Distribution market package. It includes the following subsystems and associated equipment packages:

Subsystem	Equipment Package
Emergency Management	Emergency Environmental Monitoring
Emergency Vehicle Subsystem	On-Board EV Environmental Monitoring
Information Service Provider	ISP Probe Information Collection
Maintenance and Construction Management	MCM Environmental Information Collection
Maintenance and Construction Vehicle	MCV Environmental Monitoring
Roadway Subsystem	Roadway Environmental Monitoring
Roadway Subsystem	Roadway Probe Beacons
Traffic Management	TMC Environmental Monitoring
Traffic Management	TMC Probe Information Collection
Transit Management	Transit Environmental Monitoring
Transit Vehicle Subsystem	On-Board Environmental Monitoring
Vehicle	Smart Probe

Direction arrowed lines that are labeled with a data description in the figure show the architecture flow.  This is described in the following table.

Source Subsystem / Terminator	Architecture Flow	Destination Subsystem / Terminator
Emergency Management	road network probe information	Maintenance and Construction Management
Emergency Management	road network probe information	Traffic Management
Emergency Vehicle Subsystem	environmental probe data	Emergency Management
Information Service Provider	road network probe information	Maintenance and Construction Management
Information Service Provider	road network probe information	Traffic Management
Maintenance and Construction Center Personnel	maintenance and construction center personnel inputs	Maintenance and Construction Management
Maintenance and Construction Field Personnel	maintenance and construction field personnel inputs	Maintenance and Construction Vehicle
Maintenance and Construction Management	maintenance and construction operations information presentation	Maintenance and Construction Center Personnel
Maintenance and Construction Management	environmental sensors control	Maintenance and Construction Vehicle
Maintenance and Construction Management	environmental sensors control	Roadway Subsystem
Maintenance and Construction Management	environmental conditions data	Surface Transportation Weather Service
Maintenance and Construction Management	road data	Surface Transportation Weather Service
Maintenance and Construction Management	environmental conditions data	Weather Service
Maintenance and Construction Vehicle	maintenance and construction field personnel information presentation	Maintenance and Construction Field Personnel
Maintenance and Construction Vehicle	environmental probe data	Maintenance and Construction Management
Maintenance and Construction Vehicle	environmental conditions data	Roadway Subsystem
Maintenance and Construction Vehicle	environmental sensors control	Roadway Subsystem
Roadway Environment	environmental conditions	Emergency Vehicle Subsystem
Roadway Environment	environmental conditions	Maintenance and Construction Vehicle
Roadway Environment	environmental conditions	Roadway Subsystem
Roadway Environment	environmental conditions	Transit Vehicle Subsystem
Roadway Environment	environmental conditions	Vehicle
Roadway Subsystem	environmental conditions data	Maintenance and Construction Management
Roadway Subsystem	environmental conditions data	Maintenance and Construction Vehicle
Roadway Subsystem	environmental conditions data	Surface Transportation Weather Service
Roadway Subsystem	environmental conditions data	Traffic Management
Roadway Subsystem	environmental probe data	Traffic Management
Roadway Subsystem	environmental conditions data	Weather Service
Surface Transportation Weather Service	environmental conditions data	Maintenance and Construction Management
Surface Transportation Weather Service	environmental sensors control	Roadway Subsystem
Surface Transportation Weather Service	environmental conditions data	Traffic Management
Traffic Management	environmental sensors control	Roadway Subsystem
Traffic Management	environmental conditions data	Surface Transportation Weather Service
Traffic Management	environmental conditions data	Weather Service
Transit Management	road network probe information	Maintenance and Construction Management
Transit Management	road network probe information	Traffic Management
Transit Vehicle Subsystem	environmental probe data	Transit Management
Vehicle	environmental probe data	Information Service Provider
Vehicle	environmental probe data	Roadway Subsystem
Weather Service	environmental conditions data	Maintenance and Construction Management
Weather Service	environmental sensors control	Roadway Subsystem
Weather Service	environmental conditions data	Traffic Management

Back to Figure 3

Alternative text for Table 1

Table 1 is a 3 x 3 matrix showing types of weather information products.  They are cross-referenced to a type of product along the matrix headers and the weather data used to create them is shown down the left side.

Back to Table 1

Alternative text for Table 2

Table 2 is a two column table showing the types of ESS data elements in the left column. In the right column are the elements assigned as sub categories for each of the data types.

Back to Table 2

Alternative text for Figure 15

Figure 15 is a detailed and complex high level use case diagram illustrating the associations, use cases, and actors within the full framework of the Clarus system. It shows three large rectangles vertically stacked that represent from top to bottom of the diagram: NOAA, Clarus, and Service Providers.  Inside each of these boxes are the actors, associations, and use cases that are specific to these groupings. Actors, associations, and use cases that are designated to the balance of the Autonomous and User Layers lie outside the boxes. Some associations cross between boxes and from outside the boxes to inside. The following descriptions of what is shown are organized by the box where it is located.

Outside all rectangles and left of the NOAA and Clarus rectangles are the following sets of actors and associations:

Non-Surface Observations (actor)

• Communicates with Use Case: 'Collect Non-Surface Observations'

Surface Observation Networks (actor)

• Communicates with Use Case: 'Collect Surface Observations'

ESS Equipment (actor)

• Communicates with Use Case: 'Provide ESS Measurements'

ESS Data Collector (actor)

• Communicates with Use Case: 'Collect Surface Observations'
• Communicates with Use Case: 'Send Flagged ESS, Road Condition and Vehicle QC'd Data to Collectors'
• Communicates with Use Case: 'Send Flagged ESS Data'
• Communicates with Use Case: 'Transfer ESS Data'
• Communicates with Use Case: 'Provide ESS Measurements'

Class Name: Roadway Condition Equipment (actor)

• Communicates with Use Case: 'Provide Roadway Conditions'

Roadway Condition Collector (actor)

• Communicates with Use Case: 'Send Flagged ESS, Road Condition and Vehicle QC'd Data to Collectors'
• Communicates with Use Case: 'Send Flagged Road Condition Data'
• Communicates with Use Case: 'Transfer Road Condition Data'
• Communicates with Use Case: 'Provide Roadway Conditions'

 Vehicle (actor)

• Communicates with Use Case: 'Provide Vehicle Measurements'

Vehicle Data Collector (actor)

• Communicates with Use Case: 'Send Flagged ESS, Road Condition and Vehicle QC'd Data to Collectors'
• Communicates with Use Case: 'Provide Vehicle Measurements'
• Communicates with Use Case: 'Send Flagged Vehicle Data'
• Communicates with Use Case: 'Transfer Vehicle Data'

Outside of all rectangles and to the right of the Clarus rectangle are the following:

Travelers (actor)

• Communicates with Use Case: 'Provide NOAA Weather Data'
• Communicates with Use Case: 'Provide Traveler Information'

Weather Information User Community (actor)

• Communicates with Use Case: 'Provide Value-added Private Surface Transportation Weather Information'
• Communicates with Use Case: 'Provide Value-added Private Weather Information'
• Communicates with Use Case: 'Provide Value-added Public Weather Information'
• Communicates with Use Case: 'Provide Value-added Public Surface Transportation Weather Information'
• Communicates with Use Case: 'Provide NOAA Weather Data'

Within the NOAA rectangle are the following:

NOAA (ISOS) (actor)

• Communicates with Use Case: 'Integrate NOAA Data'
• Communicates with Use Case: 'Collect Surface Observations'

NOAA (ISOS) (actor)

• Communicates with Use Case: 'Integrate NOAA Data'
• Communicates with Use Case: 'Collect Non-Surface Observations'

NOAA Integrator (actor)

• Communicates with Use Case: 'Provide NOAA Weather Data'
• Communicates with Use Case: 'Transfer External Weather Data'
• Communicates with Use Case: 'Generate NOAA Numerical Forecasts'
• Communicates with Use Case: 'Generate Severe Weather Forecasts'
• Communicates with Use Case: 'Generate General Weather Nowcasts and Forecasts'
• Communicates with Use Case: 'Archive Weather Data'

NOAA Collector for Clarus Data (actor)

• Communicates with Use Case: 'Transfer of Clarus ESS, Vehicle and Road Condition Data and Flags'
• Communicates with Use Case: 'Integrate NOAA Data'

NOAA Research (actor)

• Communicates with Use Case: 'Archive Weather Data'

Within the Clarus rectangle are the following:

Clarus Manually Entered Data Collector (actor)

• Communicates with Use Case: 'Check and Flag Manually Entered Data'
• Communicates with Use Case: 'Send Flagged ESS, Road Condition and Vehicle QC'd Data to Collectors'

Clarus Operator (actor)

• Communicates with Use Case: 'Check and Flag Vehicle Data'
• Communicates with Use Case: 'Check and Flag Collected ESS Data'
• Communicates with Use Case: 'Check and Flag Non-Clarus External Environment Data'
• Communicates with Use Case: 'Store and Index Quality Controlled Data'
• Communicates with Use Case: 'Compare ESS, Vehicle and Road Condition Data with External Weather Data'
• Communicates with Use Case: 'Check and Flag Road Condition Data'
• Communicates with Use Case: 'Check and Flag Manually Entered Data'

Within the Service Provider rectangle are the following:

Public Weather Observation Equipment (non-NOAA) (actor)

• Communicates with Use Case: 'Provide Public Weather Data (non-NOAA)'

Public Weather Data Collector (non-NOAA) (actor)

• Communicates with Use Case: 'Provide Public Weather Data (non-NOAA)'
• Communicates with Use Case: 'Integrate and Transform Service Provider Data'
• Communicates with Use Case: 'Transfer External Weather Data'
• Private Sector Weather Observation Equipment (actor)
• Communicates with Use Case: 'Provide Private Weather Data'

Private Sector Weather Observation Equipment (actor)

• Communicates with Use Case: Provide Private Weather Data'

Private Weather Data Collector (actor)

• Communicates with Use Case: 'Integrate and Transform Service Provider Data'
• Communicates with Use Case: 'Provide Private Weather Data'
• Communicates with Use Case: 'Transfer External Weather Data'

Information Service Provider (actor)

• Communicates with Use Case: 'Provide Traveler Information'
• Communicates with Use Case: 'Transfer of Clarus ESS, Vehicle and Road Condition Data and Flags'

Private Surface Transportation Weather Service Provider (actor)

• Communicates with Use Case: 'Integrate and Transform Service Provider Data'
• Communicates with Use Case: 'Provide Value-added Private Surface Transportation Weather Information'
• Communicates with Use Case: 'Transfer of Clarus ESS, Vehicle and Road Condition Data and Flags'

Public Surface Transportation Weather Service Provider (actor)

• Communicates with Use Case: 'Provide Value-added Public Surface Transportation Weather Information'
• Communicates with Use Case: 'Transfer of Clarus ESS, Vehicle and Road Condition Data and Flags'
• Communicates with Use Case: 'Integrate and Transform Service Provider Data'

Private Weather Data Disseminator (actor)

• Communicates with Use Case: 'Transfer of Clarus ESS, Vehicle and Road Condition Data and Flags'
• Communicates with Use Case: 'Provide Value-added Private Weather Information'
• Communicates with Use Case: 'Integrate and Transform Service Provider Data'

Public Weather Data Disseminator (actor)

• Communicates with Use Case: 'Transfer of Clarus ESS, Vehicle and Road Condition Data and Flags'
• Communicates with Use Case: 'Provide Value-added Public Weather Information'
• Communicates with Use Case: 'Integrate and Transform Service Provider Data'

Back to Figure 15

Alternative text for Figure 16

Figure 16 is a UML sequence diagram that summarizes all the sequences described in the text. It is comprised of three vertically stacked rectangles, one each representing the three groupings: NOAA, Clarus, and Service Providers.  The following tables organize the content of the figure into what the message of the sequence is, where it originates, and where it terminates. There are two “super” classes, NOAA and Clarus, which represent the entire NOAA entity or Clarus system.

NOAA Sequences

Message	From Class	To Class
Collect Surface Observations	Surface Observation Networks	NOAA
Collect Non-Surface Observations	Non-Surface Observations	NOAA
Transfer ESS Data	ESS Data Collector	NOAA
Provide NOAA Weather Data	NOAA Integrator	Travelers
Provide NOAA Weather Data	NOAA Integrator	Weather Information User Community
Transfer External NOAA Weather Data	NOAA Integrator	Clarus

Clarus Sequences

Message	From Class	To Class
Transfer ESS Data	ESS Data Collector	Clarus
Transfer Roadway Conditions Data	Roadway Conditions Collector	Clarus
Transfer Vehicle Data	Vehicle Data Collector	Clarus
Send ESS Data Error Report	Clarus	ESS Data Collector
Collect Clarus Manually Entered Data	Clarus Manually Entered Data Collector	Clarus
Collect Public Weather Data (non-NOAA)	Public Weather Data Collector (non-NOAA)	Clarus
Collect Private Weather Data	Private Weather Data Collector	Clarus
Transfer Clarus ESS, Vehicle and Road Condition Data and Flags	Clarus	NOAA Collector for Clarus Data
Transfer ESS, Vehicle and Road Condition Data and Flags	Clarus	Public Surface Transportation Weather Service Provider
Transfer ESS, Vehicle and Road Condition Data and Flags	Clarus	Private Surface Transportation Weather Service Provider
Transfer ESS, Vehicle and Road Condition Data and Flags	Clarus	Information Service Provider
Transfer ESS, Vehicle and Road Condition Data and Flags	Clarus	Private Weather Data Disseminator
Transfer ESS, Vehicle and Road Condition Data and Flags	Clarus	Public Weather Data Disseminator

Service Provider Sequences

Message	From Class	To Class
Provide Value-Added Public Surface Transportation Weather Information	Public Surface Transportation Weather Service Provider	Weather Information User Community
Provide Value-Added Private Surface Transportation Weather Information	Private Surface Transportation Weather Service Provider	Weather Information User Community
Provide Traveler Information	Information Service Provider	Travelers
Provide Value-Added Private Weather Information	Private Weather Data Disseminator	Weather Information User Community
Provide Value-Added Public Weather Information	Public Weather Data Disseminator	Weather Information User Community

Back to Figure 16

---