MDSS Description Version1.0 · This Maintenance Decision Support System (MDSS) Functional Prototype (FP) Description document provides an overview description of the MDSS FP system

Maintenance Decision Support System (MDSS) Functional Prototype Development Project

MDSS FUNCTIONAL PROTOTYPE

OVERVIEW DESCRIPTION

Working Document

Version 1.0

8 April 2002

Prepared by

National Center for Atmospheric Research (NCAR) Boulder, Colorado

Prepared for

Federal Highway Administration (FHWA)

MDSS Functional Prototype Overview Description

MDSS Project FY2002 3

Table of Contents

1 Introduction ................................................................................................................6 2 Scope ..........................................................................................................................6 3 Related Documents.....................................................................................................6 4 Background.................................................................................................................7

4.1 MDSS FP Overview ...........................................................................................8 4.2 MDSS FP Coverage Area ...................................................................................9 4.3 MDSS FP Development Status .........................................................................11

5 MDSS FP Design - Introduction...............................................................................11 6 Data Flow Overview.................................................................................................12 7 Computer System and Hardware ..............................................................................15 8 Networking Design...................................................................................................15

8.1 Network protocol..............................................................................................15 8.2 Redundancy issues ............................................................................................15

9 Program Code...........................................................................................................16 9.1 Programming languages....................................................................................16 9.2 System builds ....................................................................................................16 9.3 Version control .................................................................................................17 9.4 Program configuration......................................................................................17

10 Inter-process Communication...........................................................................17 10.1 System design considerations ...........................................................................17 10.2 File system interface .........................................................................................17 10.3 Glue layer..........................................................................................................18

11 File Formats......................................................................................................18 11.1 External file formats .........................................................................................18 11.2 Internal file formats ..........................................................................................18

12 Process Invocation............................................................................................19 12.1 Schedule driven system.....................................................................................19 12.2 Glue layer..........................................................................................................19

13 Data Logging ....................................................................................................20 13.1 Log files ............................................................................................................20 13.2 Log file organization.........................................................................................20 13.3 Log file hierarchy..............................................................................................20 13.4 Log file-naming conventions ............................................................................20

14 The Data Ingest Subsystem...............................................................................21 14.1 Need for live data..............................................................................................21 14.2 Data ingest using Local Data Manager (LDM).................................................21 14.3 Data ingest using FTP .......................................................................................22

15 Road Weather Forecast (RWFS) Subsystem....................................................22 15.1 RWFS overview................................................................................................22 15.2 RWFS core forecasts ........................................................................................22 15.3 RWFS forecast modules ...................................................................................23

15.3.1 Dynamic MOS forecast modules ..............................................................23 15.4 Forecast integration...........................................................................................26



15.4.1 Integration overview .................................................................................26 15.4.2 Integrator empirics ....................................................................................27 15.4.3 Integrator...................................................................................................28 15.4.4 Non-verifiable data extractor ....................................................................28 15.4.5 Post processor ...........................................................................................28

15.5 Road Weather Forecast System – Development Status ....................................29 15.6 Confidence Metric ............................................................................................29

16 Road Condition and Treatment Subsystem.......................................................30 16.1 Overview of Road Condition and Treatment Module (RCTM)........................30 16.2 Road Temperature Module ...............................................................................31 16.3 Chemical Concentration Module ......................................................................32 16.4 Net Mobility Module ........................................................................................32 16.5 Rules of Practice Module ..................................................................................33

17 MDSS FP Display System................................................................................34 17.1 MDSS Alert Function.......................................................................................36

17.1.1 Weather Alerts Categories ........................................................................36 17.1.2 Road Condition Alert Categories ..............................................................37

17.2 Sample Display Images.....................................................................................37



Acronym Glossary CRREL – U.S. Army Cold Regions Research and Engineering Laboratory DOT - Department of Transportation DSS – Decision Support System EMFP - Ensemble Model Forecast Provider ESRI – Environmental Systems Research Institute ETL – NOAA, Environmental Technology Laboratory FAA – Federal Aviation Administration FHWA – Federal Highway Administration FSL – NOAA, Forecast Systems Laboratory FTP – File Transfer Protocol GRIB – Gridded Binary HOTO - Office of Transportation Operations LDADS – Local Data Acquisition and Dissemination System LDM – Local Data Manager MDSS - Maintenance Decision Support System MDSS FP -Maintenance Decision Support System – Functional Prototype MIT/LL - Massachusetts Institute of Technology - Lincoln Laboratory MOS – Model Output Statistics NCEP - National Center for Environmental Prediction NSF – National Science Foundation NSSL – NOAA, National Severe Storms Laboratory NOAA – National Oceanic and Atmospheric Administration NCAR - National Center for Atmospheric Research NVD - Non-Verifiable Data NWS – National Weather Service OCD – Operational Concepts Description RCTM – Road Condition & Treatment Module RWFS – Road Weather Forecast System RWMP - Road Weather Management Program STWDSR - Surface Transportation Weather Decision Support Requirements VAMS - Value Added Meteorological Services WIST-DSS - Weather Information for Surface Transportation Decision Support System WMO – World Meteorological Organization



1 Introduction This Maintenance Decision Support System (MDSS) Functional Prototype (FP) Description document provides an overview description of the MDSS FP system as developed to date. This document also includes statements related to the status of the development effort and work to be accomplished prior to Release 1, which is scheduled for September 2002. This program is supported by the Federal Highway Administration (FHWA). This work is being performed as a continuation of the Maintenance Decision Support System (MDSS) prototype development effort. The focus of MDSS project work in FY2002 is to develop and demonstrate a functional prototype MDSS. Because the MDSS project is a research and development effort, changes in system design and system content may occur as technical information and scientific results become known. This document should be considered a working document. It should be noted that all MDSS functional prototype components developed by the national labs and with FHWA funding will be available non-exclusively and uniformly to any interested developers, whether or not they are development partners, subject to Intellectual Property (IP) agreements, where applicable. 2 Scope This document provides a high level description of the MDSS FP design including data flow, algorithm modules, hardware requirements, network communication, file formats, process communication, display, data logging and archiving. The MDSS FP has been designed to operate using a live data stream from several sources. It will also include the capability to play back historical data for demonstration purposes. Because the MDSS capability being developed is a prototype, not all envisioned capabilities (Ref., MDSS Operational Concepts Description) of a fully operational MDSS will be coded. The focus of the prototyping effort is to integrate environmental, road condition, DOT operational data, and rules of practice information in order to provide the road maintenance practitioner with decision support guidance related to winter road maintenance (e.g., snow plowing, chemical applications, etc.). 3 Related Documents For additional information on the MDSS Project, the reader is directed to related project documents listed in Table 1.



Table 1. Related Documents

Document and/or Web Sites Source Presentations and documents for the Surface Transportation Weather Decision Support Requirements (STWDSR) Project: http://www.mitretek.org/its/stwdsrt/

Mitretek Systems, Inc.

STWDSR– Version 1.0 (Needs Analysis) http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/9dc01!.pdf

Federal Highway Administration

STWDSR– Operational Concept Description (OCD) Version 2.0 http://www.itsdocs.fhwa.dot.gov/jpodocs/EDLBrow/401!.pdf


STWDSR--Preliminary Interface Requirements (PIR), Version 2.0 http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/@701!.pdf


Maintenance Decision Support System (MDSS) Project Prototype Development Plan, Abridged Version, 11 June 2001. http://www.rap.ucar.edu/projects/rdwx_mdss/mdss-plan-fy2001.pdf

National Center for Atmospheric Research

Maintenance Decision Support System (MDSS) Project Functional Prototype Development Plan for Fiscal Year 2002. Dated 3 August 2001. http://www.rap.ucar.edu/projects/rdwx_mdss/mdss-plan-fy2002.pdf

National Center for Atmospheric Research

4 Background This MDSS Project is part of a federal procurement for FY2001 and FY2002 research projects and deployment advocacy, which is funded through the Intelligent Transportation System (ITS) Joint Project Office (JPO) of the FHWA. The project Agreement Officer’s Technical Representative (AOTR) is Rudy Persaud, FHWA Office of Operations Research and Development (HRDO). It is envisioned that components of the prototype MDSS system developed by this project will be further developed, integrated with other operational components, and deployed by road operating agencies, including state departments of transportation (DOTs), and generally supplied by private vendors (often called Value Added Meteorological Services or VAMS).



Five national research centers are participating in the development of the MDSS FP. The participating national labs include:

• Army Cold Regions Research and Engineering Laboratory (CRREL) • National Center for Atmospheric Research (NCAR) • Massachusetts Institute of Technology - Lincoln Laboratory (MIT/LL) • NOAA National Severe Storms Laboratory (NSSL) • NOAA Forecast Systems Laboratory (FSL)

4.1 MDSS FP Overview The MDSS FP is an integration of MDSS components creating an end-to-end capability. MDSS components include:

a) Standard (NCEP) numerical weather prediction model output (e.g., Eta, AVN, MOS, etc.)

b) Supplemental numerical weather prediction model output (e.g., MM5, RAMS, etc.)

c) Road weather forecast system (a data fusion system) d) Road temperature algorithm e) Road chemical concentration algorithm f) Road mobility algorithm g) Rules of practice logic h) Display system

The decision to limit the functional prototype in FY2002 to the above-mentioned components is based primarily on the maturity of the road condition algorithms and resource limitations. MDSS Program reports, presentations, and documents can be found on the MDSS web site at NCAR at: http://www.rap.ucar.edu/projects/rdwx_mdss/index.html An overview illustration of the MDSS FP components is provided in Figure 1.



Overview descriptions of each of the major modules contained in the MDSS can be found in the Maintenance Decision Support System (MDSS) Project Prototype Development Plan, Abridged Version, dated 11 June 2001 and in subsequent sections of this document. To optimize the efficiency of the development process and demonstration capability, the core processing elements of the MDSS FP have been integrated at NCAR. MDSS FP product generation will occur at NCAR. From time to time sample display products will be made available to interested parties (DOTs, FHWA, VAMS, etc.) via a downloadable display executable. The display system includes capabilities that provide an interactive ability for the user to select overlays, product combinations, domain, animation, and forecast time. The display system runs local processes and operates (e.g., obtains data) over the Internet (client-server). 4.2 MDSS FP Coverage Area Although the MDSS FP has been designed to function anywhere where sufficient observational data, DOT operational data, and numerical forecast model output are available, for prototype development purposes, the MDSS FP area of coverage was limited to specific routes within the state of Minnesota. Minnesota was chosen as the test bed domain primarily due to the abundance of data, frequency of winter weather conditions and familiarity with the MDSS Project goals and objectives.

Figure 1. Overview configuration of the MDSS FP.

PC Display System

Internet Internet

NCAR

Road Weather Forecast System

CRREL/LL Rules of Practice Module

CRREL Road Temperature & Chemical Concentration Algorithms

FSL

Ensemble Forecasting System Four Model Members

NSSL Precipitation Type Algorithms

Web Server

MDSS Display Host

Content Generation

Transportation System Data

NCEP

Eta AVN MOS



Four routes were chosen for the MDSS FP. The routes are:

§ Highway 28 (near Morris, MN) § I-94 (near Alexandria, MN) § I-94 (near Fargo, ND) § Highway 67 (near Granite Falls, MN)

Weather and road condition forecasts as well as treatment guidance and results are provided for the four highway routes. The decision to limit the processing of data within the MDSS FP to only these routes was driven by time and resources constraints. An operational MDSS could be configured and tailored to provide decision support on a broader basis (statewide) based on the requirements of the sponsoring DOT.

Minnesota DOT selected the routes used in the MDSS FP. The Minnesota highway route locations used in the MDSS FP are illustrated in Figure 2.

MN Road Map Here

Fig 3

Figure 2. Map of Minnesota highway system.



4.3 MDSS FP Development Status This section provides an overview of the status of the overall development effort to date (April 2002). It should be recognized that system software development is planned to continue through June 2002. Between June and September 2002, system documentation will be prepared and the system and its components will be prepared for Release-1. Status information related to individual components is provided in subsequent sections of this document. As of 1 April 2002, all of the primary components of the MDSS FP have been coded and integrated. The system currently operates in a live mode, but not all of the interprocess communication software is in place. This will be completed before Release-1. The weather forecasting component of the system (Road Weather Forecast System) requires approximately 100 days to tune itself; therefore it will not be possible to fully evaluate the forecast skill during the winter of 2001-2002. In it’s current state, the MDSS FP is able to automatically generate weather forecasts at specific points, calculate road conditions (road temperature and chemical concentration) for road maintenance routes, provide recommended treatment guidance, and allow users to perform what if calculations for multiple treatment options. It also provides decision support for monitoring stocks (chemicals and abrasives) and crew shifts. In addition, the user is able to delve into the data and view time series information for weather and road condition parameters. Only quick-look reviews of the system output have been achieved at this time. Two cases (23 February and 14 March 2002) have been captured and will be reprocessed to assess system skill and areas for improvement. Verification of additional cases is desired and comparisons of recommended treatment options produced by the system vs. actual treatments should be performed. 5 MDSS FP Design - Introduction The MDSS is designed to perform a variety of tasks with the goal of creating weather forecast and road treatment plans for winter road weather maintenance. In order to achieve this goal the MDSS does the following:

• Ingest various datasets from external sources; • Convert the external data formats to internal MDSS formats; • Run algorithms on the datasets to produce derived products; • Display the data to the users.



6 Data Flow Overview Data for the MDSS FP will originate both from National Center for Environmental Prediction (NCEP), individual State DOT(s), and an Ensemble Model Forecast Provider (EMFP). This section presents an overview of the flow of the data into and through the system. The information is presented using 'data flow diagrams', a common means for representing the flow of data through a computer-based system. Figure 4 shows an overview of the data flow through the entire MDSS FP system. Figure 5 shows an overview of the data ingest from NCEP, State DOT(s), and the EMFP. It also shows the data assimilation step. This data assimilation step extracts the data at the forecast sites and performs straightforward derivations to obtain further data fields. Figure 6 shows an overview of the data flow in the Road Weather Forecast System (RWFS) for the weather forecast generation based on real-time data. Auxiliary RWFS processes which produce empirical data used by other RWFS processes are detailed in section 15. Figure 7 shows an overview of the data flow within the Road Condition and Treatment Module (RCTM). Figure 8 shows an overview of the data flow to the display.

Figure 4. Overview of MDSS Data Flow.

Data Ingest and

Assimilation RWFS Display RCTM

External Data

Providers



State DOT(s)

LDM Data

Assimilation EMFP

NCEP

Figure 5: Data Ingest Subsystem Data Flow Diagram.

.

.

.

Data Ingest and

Assimilation

Forecast Module 1

Forecast Module 2

Forecast Module 3

Forecast Module N

Integrator

Post Processor

Forecast Products

Figure 6: RWFS Real-Time Processing Data Flow.

Non-Verifiable Data



Weather Forecast Products

Roadway Configuration

Data

Road Temperature

and Snow Depth Module

Net Mobility Module

Rules of Practice Module

Road Conditions

and Treatments

Chemical Concentration

Module

Figure 7: RCTM Module Data Flow Diagram. The dashed lines indicate the data flow if the Rules of Practice Module determines that a treatment is required.

Roadway Configuration

Data

Weather Forecast Data

Road Conditions

and Treatments

Display

Figure 8: Overview of Data Flow to the Display.



7 Computer System and Hardware The MDSS FP runs on UNIX platforms (Intel PC) running the Solaris operating system. The MDSS is scalable and if the number of forecast sites is sufficiently large, more machines with the same configuration will be required. The MDSS FP hardware specification for FY2002 is:

Dual 1 GHz processors 250 Gbyte disk space 1 Gbyte memory

A single PC is required to operate the core system as configured for the FP (MN domain with a limited number of routes). The cost for this configuration was < $10,000. 8 Networking Design 8.1 Network protocol All networking is done using the TCP/IP transport layer. This is the underlying protocol standard for most communication on the Internet. 8.2 Redundancy issues The decision on whether to provide redundant components in the system is driven by two main factors:

• The consequences of a failure • The cost of providing redundancy

Since this is not considered a safety-critical system, but rather a prototype forecasting and planning system, a moderately conservative approach to redundancy is appropriate. Most of the input data required by the MDSS can be received in a timely fashion over the Internet with a T1 link. The communications network infrastructure represents a large recurrent cost, with monthly payments to the communications vendor company. It is therefore not cost effective to plan on redundant Internet communications links. However, if desired, the NCEP data can be obtained through a NOAAPort system, which provides a satellite downlink capability. Beyond the cost of the NOAAPort Receiving Dish, there is no recurrent cost. Between these two communications methods, loss of incoming data should be extremely rare.



A web server serves the output forecast and treatment plan data over the Internet to the end user. Operational versions of the system could utilize Internet or Intranet network communications. If snowplow operators are using wireless devices in the field, other network configurations could be implemented. It is beyond the scope of this document to speculate as to what devices the end users might ultimately use. Therefore, we concern ourselves only with Internet delivered output for the functional prototype. If more than one machine is required to run the MDSS system, the data disks should be cross-mounted (NFS) on a Local Area Network (LAN). In this way, all data will appear to be local on any machine. I/O is generally not a bottleneck for the internal processing of the data. Components of the LAN, e.g. routers and switches, have been found to be extremely reliable and it is not considered necessary to have complete redundancy. However, one extra unit of each type should be configured and ready to be swapped should failure occur. Beyond the data ingest processes, complete redundancy can be obtained by having two duplicate processing systems (hardware/software). Unless an extremely large site configuration is used, the cost of these redundant machines should be relatively minor. For the machines in the system, sufficient spare equipment should be kept on hand to allow for quick replacement of the faulty machine or component. 9 Program Code 9.1 Programming languages Each component of the system will be coded in one of the following languages:

• C/C++ • Fortran • Perl • Python

Most of the code has been written in C++. Other languages will be used where applicable for efficiency. To the greatest extent possible, C and C++ code will be POSIX compliant. 9.2 System builds



The libraries and applications in the system were built using the standard UNIX make utilities. Scripts will be set up to check out and build the system components automatically. 9.3 Version control The Concurrent Version System (CVS) has been used for version control of all source code. System releases will be tagged to ensure that the released version can be rebuilt at any time. 9.4 Program configuration

Most of the modules comprising the system require configuration files. The purpose of these files is to allow an administrator to easily re-configure the system for another region, or add additional forecast sites to an existing configuration. The configuration files consist of simple ASCII text. Each file can be edited by hand but must be properly formatted. 10 Inter-process Communication 10.1 System design considerations The individual modules of the MDSS FP have been designed to be relatively simple. Each process, while perhaps doing sophisticated processing, has been designed to know very little about the outside world. For example, the processes know nothing about the file system. Nor do they consult the system clock to find out the time. Instead, all information required for processing, such as file names and relevant time parameters, is passed to the process as command line arguments. One major advantage of this methodology is that every instance of the process is completely repeatable. Log files, described later, keep track of the command line executed as well as the status of each process run. Bugs can easily be traced by repeatedly running the code with the same command line. 10.2 File system interface MDSS inter-process communication is done through the file system. Each process obtains its inputs solely through filenames and UNIX times specified on its command line. Many of these files specified are data files generated by upstream processes or are static binary data files. The remainders are configuration files that contain the list of sites and forecast variables to be processed.



Each process reads its input data from the files on its command line, processes it, and writes its output to a file. The output filename is specified on the command line. Its format is specified in a file named on the command line. 10.3 Glue layer The knowledge of the file system lies within a relatively small piece of code known as the "glue layer". The glue layer's responsibility is to stick the system together. It creates each process's command line through its knowledge of the file system and other system resources. It is described more fully in section 12 of this document. 11 File Formats 11.1 External file formats Files received from external sources such as NCEP are all in their native formats. MDSS FP ingest processes convert these to an internal MDSS format. The raw forecast model data comes in GRIdded Binary ("GRIB") format. This compressed binary format is a WMO standard for gridded data dissemination. Observational data from various human and automatic sensor networks arrives in formats defined by the maintainers of the networks. 11.2 Internal file formats Internally, files are either in ASCII text or binary format. The netCDF format is the only binary format used internally within the MDSS. The netCDF format is a standard developed for scientific applications. It is widely used in the meteorological community. Information on the format can be obtained at www.unidata.ucar.edu. The MDSS typically writes its data files in the binary netCDF format. ASCII text files are typically used for configuration purposes. The format of a file can be determined by the two or three letter extension at the end of its file name. The ASCII text files have an .asc suffix. The netCDF format files use the .nc extension. ASCII text files exist within the system that describe the format of the binary netCDF output files. These files, called Command Description Language (CDL) files, have a .cdl extension.



12 Process Invocation 12.1 Schedule driven system Processes in the MDSS are run on a schedule. The schedule is determined by examination of typical data arrival times and process run times. As much of the MDSS processing is sequential, it is necessary to allow sufficient time between process invocations to ensure that the preceding process will have finished. On the other hand, these inter-process scheduling gaps should be as short as is reasonable to ensure more timely end-to-end processing time. Rather than using a custom scheduler, the MDSS uses the UNIX system scheduling utility cron. Use of this flexible utility can be found online in the UNIX man pages. One drawback of using cron is its temporal resolution. The finest granularity available using cron is one minute. For the MDSS system, this is not a particularly oppressive restriction since the lead times the end user expects to use are more on the order of several hours. The trade-off of less custom development is made in exchange for slightly more latency in the system output. 12.2 Glue layer When cron determines that it is time to take an action, it starts the executable listed in the schedule. For MDSS, this is typically a python super-script whose job it is to start and oversee the execution of the process. This process sets a timer to ensure that the process it invokes finishes within a reasonable length of time. The super-script then invokes another python script specific to the scheduled task. The python script associated with the scheduled task's job is to determine the command line arguments for the scheduled C/C++ module's execution. It does this through its knowledge of the layout of the file system. There exist text-based "index files" at strategic locations within the file system that contain the name of the most recently generated file of a certain type. The python script reads the appropriate index files to obtain the required input file names. Usually, these file names will go directly onto the command line. Other times, the python script will create a configuration file containing a list of the file names. The configuration file's name would then go on the command line. The python script also knows the location of the static files that are required by the C/C++ module. Their file names are also gathered and put on the command line. The python script may also query the system to obtain the current time. This python script then executes the command line it has created. The process's return code is processed to determine whether it was successful in completing its task. Upon success, the script then ensures that the index files are updated with the new file names. If the process does not run to a successful completion, the index files are not updated, and other processes will never use the newly created file.



13 Data Logging 13.1 Log files The MDSS scripts and processes generate output indicating their progress and exit status. This textual output is written to system log files. Examining these log files allows the system administrator to easily verify the status of each completed process and identify where problems occurred. 13.2 Log file organization Three sets of log files are maintained for each process. One file is associated with the python super-script to record its actions. A second log file is associated with the python script that creates and executes the command line. The command line that is actually executed is written to this log file. This allows a developer to re-create and debug the problem. The third log file contains output from the C/C++ module itself. 13.3 Log file hierarchy The first two sets of log files are each generated by a python script. They are responsible for logging information about their internal status as well as monitoring and reporting on their children's status. The third log file only reports on its internal status since it has no children. Each script or process is required to write log messages indicating that it has started. It must also indicate if it has started another process and the command line associated with that invocation. It also must report on the status code returned by its child. Finally, it must log that it is done and report its status code. Specific formats exist for reporting starting and ending status. Searching for bad status messages is an easy means for finding problems. 13.4 Log file-naming conventions The log files are all located in the same directory. For each C/C++ executable, one set of the three log files is created every day. The date associated with the files is part of the log files' names. The logging information for all runs of a particular executable during a given day is contained in these three log files. The names of the log files differ only in their suffix. The python super-script's log file has an .epl suffix. The second python layer's log file has a .pyl suffix for python layer. Finally



the C/C++ executable's log file has an .asc extension. As an example, the log file names for the RWFS integration process, int_fcst, for 13 December 2001 would be:

int_fcst.20011213.epl int_fcst.20011213.pyl int_fcst.20011213.asc

14 The Data Ingest Subsystem 14.1 Need for live data Several types of live data1 are required by the system. These data are all generated and disseminated from external sites and received through a connection to the Internet, or optionally via a NOAAPort system. Various types of numerical prediction model data (gridded or statistical) are used in creating the forecasts, and observation data are required for creating empirical relationships with the forecasts. These data are vital to the system in being able to make accurate weather and road condition forecasts. The live data used by the MDSS FP system are listed below. Unless otherwise indicated, both the 00 and 12 UTC runs are used for NCEP models and NCEP MOS data. Supplemental model data from other sources (e.g., NOAA/FSL and NOAA/NSSL) have been ingested as needed based on the final run schedule.

• NWS ETA model (from NCEP) • NWS AVN model (from NCEP) • FSL ensemble model members (four members) (ETA, MM5 initialized two ways) • NSSL ETA model (different precipitation process scheme than the NCEP version) • NWS MOS (AVN, NGM, and MRF) (from NCEP) • NWS SYNOP (from NCEP) • METAR observations (aviation observations) • RWIS observations (environmental and road condition) from MN DOT through

FSL in LDADS format 14.2 Data ingest using Local Data Manager (LDM) The Local Data Manager (LDM) is used for distributing some of the data in the system. The LDM was developed by the Unidata program at UCAR and is freely available. The LDM is a "push" technology which moves data "products" from one computer to another as the data become available from the source, or upstream computer. Data products can be individual WMO bulletins or files, for example. The LDM runs as a set of daemon processes receiving products continuously. As new products arrive, the LDM files the

1 Live data refers to data that flow into the system shortly after they are measured or obtained.



products and/or starts up decoders (to convert to netCDF for example) as needed for the particular product type. A major benefit of the LDM is that it is a data-driven system and thus it removes the requirement to "poll" a source computer for data. Hence it is very efficient by reducing unnecessary network traffic and CPU cycles that would otherwise be spent actively looking for new data. The LDM is the preferred method of data retrieval. 14.3 Data ingest using FTP

Since some data source machines may not be running the LDM system, traditional FTP must be used to transfer data in particular cases. This process must be automated, so a set of scripts are used that perform the polling for new data and the actual FTP of the necessary files. These scripts are started from cron at a pre-defined interval to poll for the existence of new data. When new data are detected, the script retrieves the data using the ftp command. The data are then converted to the internal netCDF format used within the system. 15 Road Weather Forecast (RWFS) Subsystem 15.1 RWFS overview The RWFS is tasked with ingesting meteorological data (observations, models, statistical data, climate data, etc.) and producing meteorological forecasts at user defined forecast sites and forecast lead times. The forecast variables output by the RWFS are used by the RCTM to calculate the road surface temperature and to determine a suggested treatment plan. In order to achieve this goal, the RWFS generates independent forecasts from each of the data sources using a variety of forecasting techniques. A single consensus forecast from the set of individual forecasts is generated at each user defined forecast site based on a processing method that takes into account the recent skill of each forecast module. 15.2 RWFS core forecasts The RWFS generates point forecasts for locations along the highway system (and elsewhere as configured). However, very few of these sites are observational sites that regularly make automatic reports. At observational sites, forecast parameter tuning based on past performance helps improve the forecasts. This class of sites is called core forecast sites. Forecasts at non-core sites are derived from forecasts at core sites.



The numerical weather model data used by the RWFS has three-hourly resolution. Since the system is primarily model data driven, forecasts are initially generated at three-hour intervals. These times are called the core forecast lead times. The variables output by the RWFS are used by the RCTM and the display. The observational data ingested only contains a subset of the variables required by these downstream processes. The RWFS output variables contained in the observational data sets are called the core forecast variables. 15.3 RWFS forecast modules The RWFS creates several independent forecast estimates. Each forecast module attempts to create the best forecast it can by applying a specific forecast technique to its input data set. Each RWFS forecast module uses one of three basic techniques to generate forecasts. They are:

• Dynamic Model Output Statistics (DMOS), • Interpolation of NWS MOS site forecasts, and • Semi-static techniques.

Each forecast module produces an identically formatted output file. No forecast module is dependent on another forecast module. That is, no forecast module's output is used as input to another forecast module.

15.3.1 Dynamic MOS forecast modules The Dynamic MOS (DMOS) forecast modules are a dynamic variation of the traditional NWS MOS procedures. DMOS, like traditional MOS, finds relationships between model output data and observations using linear regression methods. However, while MOS equations are calculated using many years of data, DMOS uses only the last 3 months (configurable) of data. New regression equations are re-calculated once per week. The DMOS technique has several advantages over traditional MOS. The reliance on only a short history allows DMOS equations to be calculated and DMOS forecasts generated for newly ingested models or models that are changing due to enhancements. Traditional MOS equation generation would require the model to be stable (no changes) for several years. Also, the MOS equations are calculated painstakingly with a large human quality control effort. This makes it difficult to add MOS equations for a new set of forecast sites. DMOS forecasts can be made at these sites immediately provided they have an observational history of at least three months (configurable). A disadvantage of DMOS is that the equations it produces are less stable than MOS equations. For this reason, quality control checks must be put into place to assure that the equations produced will not create nonsensical outlier forecasts.



The DMOS subsystem applied to any model has three components:

• Regressor calculation, • Empirical Relationships Generator, and • Forecast Generator.

The interaction of these three components is diagrammed in Figure 8.

15.3.1.1 Regressor calculation Regressors are variables extracted or derived from model data, which is likely to have a relationship to one of the output forecast variables. These regressors are calculated at each forecast site for each forecast lead-time. About 2/3 of the regressors are variables directly extracted from the model data. Other regressors are derived by combining several variables to estimate meteorological data not explicitly predicted by the models. Since the forecast sites are rarely at model grid points, interpolation techniques are used to generate forecasts at the forecast sites. This requires an understanding of the projection of the model grid and the terrain assumptions used in each model. As some of the

Regressor Calculation

Empirical Relationships

Generator

Forecast Generator

Empirical Relationships

File

Current Regressor

File

Weather Forecast

Regressor History

(100 Days)

Model Data

Observation Data

Figure 8: The interaction of the 3 modules of the RWFS DMOS forecast subsystem is shown. The Regressor Calculation Module extracts and derives forecast point specific data from the model data. A history of these regressor files is accumulated and the Empirical Relationships Generator finds empirical relationships between the regressors and the observed data. These empirical relationships are applied to the current day’s regressor data to generate the DMOS forecast.



regressors are estimates of meteorological variables at the earth's surface, correcting for the simplified terrain used by the model is important and varies from model to model. The regressors from one model run are all stored in one file. The regressor files are put into a regressor history that the DMOS empirics process uses to calculate regression equations.

15.3.1.2 DMOS Empirical Relationships Generator The DMOS Empirical Relationships Generator attempts to find relationships between the regressors and the observations at forecast sites. It does this using a linear regression technique. There are tradeoffs involved in determining the best regression equation. The goodness of fit measure of a regression equation is called its r-squared value. Typically, adding more regressors to an equation increases the r-squared value. However, this also increases the variance of the output forecasts since more regressors are included that do not have a strong relationship to the predictand. Therefore, the desired set of regressors has most of the information leading to a good prediction and does not contain noisy regressors. Equations that do not have a sufficiently high r-squared value are replaced with a default equation. This default equation is a predefined combination of regressors defined by a meteorologist. A default equation is an attempt to generically replicate a meteorologist's logic in coming up with a forecast. Special, usually derived regressors have been developed for this specific purpose. These default equations generally do not produce the erroneous forecasts that a low r-squared equation might. This best combination of regressors will vary from site to site, between forecast lead times, and clearly will be different for each forecast variable. The relationships will also vary from season to season and from model to model. The empirics generator is run once per week for each model to find the equations which best fit the most recent data. These equations are stored in a DMOS empirics file and used later by the DMOS forecast generator.

15.3.1.3 DMOS Forecast Generator The DMOS Forecast Generator applies the empirical relationships generated by the DMOS Empirical Relationships Generator to the most recent regressors. This generates the DMOS forecast. The relationships between regressors that have done well at predicting the observations recently are used again on today's regressor data to make a DMOS forecast. If any of the regressors that appear in a regression equation are missing, a missing forecast is generated.

15.3.1.4 NWS MOS forecast modules These forecast modules are based on the MOS products generated by the National Weather Service. These forecasts are not a perfect match to the desired MDSS forecasts.



The MOS data consist of point forecasts at sites chosen by the NWS. These MOS sites are generally a subset of the MDSS forecast sites. Also, the variables forecast in the MOS output varies for each of the NWS models. In addition, the variables do not directly match the MDSS forecast variables and it is possible that the forecast lead times do not match the MDSS forecast lead times. At a site included in any particular NWS MOS forecast, the forecast module tries to reproduce the exact forecast. Where MDSS variables are explicitly forecast in the MOS product, they are simply copied. Otherwise, if reasonable, the MDSS forecast variable is derived from the MOS data. For some variables, no derivation is reasonable and these variables are left as missing data. If the forecast lead times of the MOS product do not match the MDSS forecast times, the forecast module makes an interpolated forecast where possible. For the majority of the MDSS sites, no MOS forecasts exist. Forecasts for these sites are generated by interpolation techniques. The interpolated forecasts are generated using the forecasts generated at the MOS sites. No satisfactory interpolation technique has been found that works well for all variables in rough terrain. For example, the interpolation of surface winds in the mountains does not work well using any known technique.

15.3.1.5 Semi-static forecast modules Two forecast modules are called semi-static in that their forecasts depend only on historical data, not on any predictive forecast model. These two are the climatology and persistence forecast modules. These two look at the past weather over different time ranges and base their forecast on the average weather seen. The climatology forecast module uses data from up to the last 30 years. Monthly averages of the MDSS forecast variables have been computed and stored in a climatology file. These monthly climatological values are interpolated to the forecast date. The persistence forecast module averages the observations of the MDSS variables seen in recent days to come up with its forecast. The persistence and climatology forecast modules have more effect on the forecasts for longer-term forecasts periods (> 72 hours). These modules will not provide a significant contribution in the MDSS FP, which will be configured to only provide guidance out to 48 hours. 15.4 Forecast integration

15.4.1 Integration overview The RWFS forecast modules each generate as complete a forecast as possible. This includes a forecast for every forecast variable at every forecast site for every forecast lead time. These independent forecast estimates are combined by the integrator to generate one final consensus forecast. Numerous combination techniques have been developed. Investigation has led to a decision to use an enhanced Widrow-Hoff learning method.



This method creates its final forecast using a weighted average of the individual module forecasts. The weights are modified daily by nudging the weights in the gradient direction of the error in weight space. The effect of this is that forecast modules that have been performing well for a particular forecast (variable, site, and lead time) get more weight and the poorly performing modules get less weight. Note that different weight vectors exist for every forecast generation time due to differing latencies in the input data sets. The interaction of components of the integrator is diagrammed in Figure 10.

15.4.2 Integrator empirics This RWFS process runs once per day and updates all the weights based on the performance of the various forecast modules. It reads the observations from the previous day and compares the forecast modules' output that predicted those observations. For each forecast, the errors are computed and the gradient vector in weight space is computed. A step proportional to the size of the combined error is taken in that gradient direction to compute the new weights.

Figure 10: The RWFS Integrator Subsystem is shown. The Integrator Empirics module generates new weights by updating the existing weights based on the performance of the forecast modules. These weights are applied to the current forecast modules output.

Forecast Modules History

Independent Forecast

Modules (N)

New Integrator

Empirics File

Integrator Empirics

Integrator

Current Modules’

Forecasts (N)

Integrated Forecast

Previous Integrator

Empirics File



15.4.3 Integrator The integrator creates a final forecast by making a bias-corrected confidence-weighted sum of the individual module forecasts. It reads the forecasts from the forecast module output files, the weights from the integrator empirics file, performs its calculations, and stores its results.

15.4.4 Non-verifiable data extractor The RWFS forecasting techniques described above only apply to core forecast variables. These are variables that are regularly measured and reported in meteorological observation data. The DMOS forecast modules and the integrator both require specific observations to tune themselves. Some variables required by the RCTM are not included in standard meteorological observation reports. However, several of these variables are generated by numerical weather prediction models. The RWFS attempts to provide the RCTM with reasonable estimates of these variables by using a combination of various models' data. The weights used in the combination are pre-determined by a meteorologist familiar with the models and stored in a configuration file. The model variables to be combined have been extracted by the DMOS regressor calculation process and stored in a regressor file. The Non-Verifiable Data (NVD) extractor reads in the appropriate models' regressor files along with the weight configuration file before creating its weighted combination output.

15.4.5 Post processor The post processor provides a variety of processing options to merge the integrator's forecasts and the NVD forecasts. It attempts also to remove ridiculous forecasts, derive other forecast variables, and spatially and temporally interpolate the forecasts to non-core forecast sites. The output of the post-processor is the output that will be fed into the RCTM. Quality control measures are applied to the integrator's output to ensure that no forecasts are well beyond reasonable ranges. Forecast values near the limits are returned to the bounding values. For example, forecasts of 101% probability of precipitation are turned into forecasts of 100%. Forecasts well beyond the bounds are replaced with a missing data flag. Forecast variables required by the RCTM or the display system are derived from the core set of MDSS forecast variables. For example, relative humidity is derived from temperature and dew point temperature. The MDSS provides forecasts for numerous non-core forecast sites along the highways maintained by the DOTs. The output of the integrator contains only forecasts for core forecast sites. Forecasts at the non-core sites are generated by spatial interpolation from the core sites' forecasts.



Since the MDSS provides forecasts at one hour intervals and the core forecast lead times are at three-hour intervals, temporal interpolation of the three-hourly forecasts is used to generate the desired final forecast temporal resolution. 15.5 Road Weather Forecast System – Development Status Development Status (April 2002): The core technology used within the Road Weather Forecast System (RWFS) was developed as an intelligent data fusion system for public forecasting applications. An operational version of the system has been implemented in the private sector. The RWFS was reapplied for the MDSS application. The RWFS, (as an intelligent data fusion capability) is quite mature. Development is ongoing, but the current version is very robust and produces better forecasts than individual inputs. The impact of adding supplemental models (e.g., special runs of FSL and NSSL models) still needs to be investigated. Work to be Performed: Output from the RWFS for the MDSS application needs additional verification to ensure it is operating as designed. Performance of the system for non-verifiable parameters2 needs to be assessed. 15.6 Confidence Metric The users expressed a strong desire for the MDSS FP to include an overall metric that describes the confidence in the system’s ability to predict the weather and road condition. A lot of scientific work is being conducted in the meteorological community to address confidence and probability forecasting. The recent use of ensemble modeling may be useful in the solution. The RWFS utilizes many inputs (ensemble) and keeps track of its recent skill. How to utilize data within the MDSS FP to address confidence is an ongoing activity. Development Status (April 2002): An initial attempt at an algorithm has been coded as a placeholder, but additional scientific work needs to be performed to define this metric. It is generally agreed that confidence is related to; a) recent forecast skill, b) spread of values between forecast modules, c) forecast lead time, d) magnitude of prediction values, and other factors. The current and simple (placeholder) algorithm is based on an assumption that there is a relationship between forecast spread and confidence. Early results support this assumption, but it is also recognized that this one factor, by itself is not sufficient to capture overall confidence. Work to be Performed: Additional analyses of the factors important to calculate confidence will be performed between April and June 2002. It is anticipated that a slightly more sophisticated algorithm will be implemented in the system before Release-1. 2 Non-verifiable parameters are parameters that are not measured in real time and therefore, cannot be used to train the system.



16 Road Condition and Treatment Subsystem

16.1 Overview of Road Condition and Treatment Module (RCTM) The RCTM ingests and processes environmental forecast data to predict the road surface temperature at all forecast sites and lead times. Using the meteorological forecast data and the pavement temperature data, a predicted mobility index is calculated along with a treatment plan. A small number of forecast sites have been selected per highway route and weather and road condition data have only been processed for those sites. At this point of development, a different treatment plan is calculated (on demand) for each highway forecast point. The treatment plans will vary spatially and no approach is currently in place to resolve the potential discrepancies. These discrepancies may be partially due to differing subsurface structures of the roadways at adjacent points. For example, road conditions on a bridge can be very different from conditions a few hundred meters away. The output of the RCTM is passed to the display. The RCTM, unlike the RWFS, is implemented as a single process. While similar at first glance, there are significant differences between the two subsystems that influence this decision. This is mainly due to feedback effects of plowing and chemical applications on the road. The treatment plan generation algorithm requires time series of pavement temperatures and meteorological variables to determine the appropriate first treatment (time and type). Once that treatment has been implemented, the time series of pavement temperatures beyond that treatment time is invalid because of the sensitivity of the road temperature to the snow cover. The snow on the road when the pavement temperature time series was calculated will not exist (in the same state) after a plowing and chemical treatment. The RWFS design of multiple processes is effective in a forward processing flow system. The complex inter-module interactions led to a decision to implement the RCTM as a single process. The driver process handles one site at a time. After a road temperature and snow depth time series are generated, a treatment plan is developed. If the plan indicates a treatment should be applied, the processing of the site restarts from the first treatment time. The road surface state and meteorological conditions are modified to reflect the treatment action before regenerating another road temperature time series. In the MDSS FP it is assumed that plowing will always take place as part of a treatment. This changes the road surface state by removing existing snow. If the Treatment Module recommends a chemical treatment, the suggested chemical amount is applied. The chemical algorithm then calculates the dissipation and effectiveness of the chemical based on time, traffic, and precipitation. The treatment impacts the road state and a new road temperature time series is calculated starting from the treatment time. This iterative process continues until no treatment is required in the remaining time until the end of the forecast period.



Development Status: The RTCM has been coded and is generating output, which is sent to the display system. Additional code refinements (hardening) are planned before Release-1. Work to be performed: Additional verification of results from the RTCM module is planned prior to release. 16.2 Road Temperature Module The Road Temperature Module, SNTHERM, is a land-surface model developed at CRREL that generates a temperature profile of the road surface and subsurface. This snow/road/soil temperature model is a one-dimensional mass and energy balanced model constrained by meteorological boundary conditions. The model considers the transport of liquid water and water vapor, and phase changes of water (except in the road layer) as components of the heat balance equation. The impact of snow accumulation, ablation, densification, and metamorphosis on the snow thermal optical properties are modeled. The infiltration of water in the snow/soil is modeled assuming gravity flow. The model presently does not consider the flow of water in frozen soil or in the road layer (asphalt or concrete). To accurately represent the flow of water in soils, the capillary pressure effects must be modeled. When snow is present, the water infiltrating to the snow/road surface is artificially drained from the system. The snow, road, and soil are divided into horizontally infinite control volumes (referred to as nodes) and the mass and heat balance equations are applied to each control volume. A spatial discretization scheme similar to a finite-difference method is used in the spatial domain, while a Crank-Nicolson method is used to discretize the time domain. The model uses an adaptive time step procedure that adjusts the time step (typically between 5 and 900 seconds) to obtain the desired accuracy of the solution to the mass and heat balance equations. The governing functions are linearized and a tri-diagonal matrix algorithm is used to obtain the desired solution. SNTHERM was developed in the 1980s in Fortran. It was developed for use in a research mode. SNTHERM's I/O is completely file-based. It reads three input files and produces one output file. The output file contains the temperature profile and the snow depth at each forecast lead-time. SNTHERM was prepared for single run applications and not for repeated iterative use on a number of sites. Significant re-workings of the code would have been required to achieve usability as a subroutine called from within the RCTM. For this reason, SNTHERM is run as a separate process invoked by the RCTM. The RCTM driver creates the input files and starts SNTHERM. When SNTHERM has completed its run, control is passed back to the RCTM driver that parses the SNTHERM output file.



The input files passed to SNTHERM includes one master file FILENAME that contains the file names of the other input files and of the output file. The first of other input files contains the meteorological predictions. The second contains the SNTHERM configuration information and the road subsurface structure and initial conditions. Development Status: The SNTHERM model has been coded and has been integrated into the RTCM. There are still occasions when the model fails. Additional code refinements (hardening) are planned before Release-1. Work to be performed: Additional verification of results from the SNTHERM model is planned prior to release. Code hardening is needed before Release-1. In addition, sensitivity to road subsurface structure needs to be evaluated. 16.3 Chemical Concentration Module The Chemical Concentration Module (NaCl, MgCl, and CaCl) predicts the dilution of chemicals existing on the road. Given an initial concentration applied as part of the treatment process and the weather forecast (e.g., temperature, precipitation type and rate), the module generates an hourly time series of expected chemical concentrations. The concentration is dependent on the road surface temperature and liquid precipitation amount, and secondary factors including traffic volume and road spray. A difficulty is that the road temperature and the chemical concentration are interrelated. To simplify the calculation, an approximation of the road temperature is made using the initial (t= 0) road surface temperature and the forecast air temperature. Given the predicted precipitation, it can be determined when the chemicals put down on the road will become ineffective. Development Status: The Chemical Concentration algorithm (freezing point for chemical solutions) for NaCl only has been coded and has been integrated into the RTCM. It appears to be performing properly given the weather and road condition prediction data. Work to be performed: There is a desire to add additional chemicals to the system. If additional chemicals are added, the process that generates recommended treatments will treat them independently. In the future, there is a desire to have logic that optimizes the treatment plan based on the characteristics of each chemical. 16.4 Net Mobility Module The DOT users indicated a desire to have a single (non dimensional) metric to identify the predicted state of the roadway relative to winter road conditions. A mobility metric has been developed that takes into account pavement condition (wet, dry, snow, snow depth, ice, etc.). The Net Mobility Module reads in the meteorological and road surface conditions and outputs an index describing the amount of mobility a vehicle could encounter on the road.



This index ranges from 0 (no mobility) to 1 (optimal road conditions). A number of tables exist which describe the mobility in certain conditions. A decision tree leads to finding the proper table. The mobility index is found by finding the proper cell in the table that fits the existing environmental and traffic conditions. Development Status: This metric needs additional development, as it does not currently take into account some of the subtle factors (e.g., wet snow, dry snow, snow on ice, etc.) that impact mobility. A simple algorithm has been implemented as a placeholder. The algorithm uses the following general scheme:

Pavement Condition Mobility Index Dry 0.9 Wet 0.7 Snow < 4 inches 0.6 Snow 4-6 inches 0.4 Snow > 6 inches 0.3 Ice 0.2

The utility of a mobility metric must still be investigated. It is anticipated that several iterations with the users and experience will be required to firm up this concept. 16.5 Rules of Practice Module The Rules of Practice Module ingests the time series of weather and road conditions for use in determining a treatment plan. As the RCTM is designed, essentially only the first treatment needs be determined. This is because once that treatment is implemented, the road temperature and snow cover time series become invalid as they have been affected by the plowing or chemical application specified in the first treatment. The inputs are adjusted and the module re-invoked to determine if another plowing run and/or chemical application is needed. The rules module consults what is best described as an electronic version of the FHWA Manual of Practice for Effective Anti-Icing Program to determine the recommended treatment. There are several key decision points for determining treatment:

1) Any amount of snow begins to accumulate on dry roads combined with other favorable environmental conditions.

2) Snow accumulates on the surface of the road to the point where plowing is needed. The recommended treatment (for example an application of NaCl) might be applied before the snowplow point, but the need for plowing triggers the need for prior treatment.

3) Freezing rain* is predicted to fall onto roads that are also below freezing.



Treatment may consist of plowing, sanding, and/or a chemical application. If a chemical application is required, the amount and type of chemicals are also specified. In the case of an initial application of chemicals, the recommendation specifies that the application should be made prior to precipitation onset. Different department practices or resources may dictate that the pre-storm application occurs anywhere from 0 to 12 hours before storm onset. Exactly when the initial treatment is applied is not critical because as long as it is applied before the precipitation begins negligible amounts of chemical dilution should occur. A configuration file, adjustable for each locality and route, is used to set preferred chemical types, application rates, levels of service, and route timing. Routes that cannot be maintained to bare pavement for anti-icing operations, will be given de-icing plowing and chemical application rates until anti-icing operations can be resumed. * As defined in the environmental condition forecast algorithm. Freezing rain may be predicted to occur in general, but surface pavement temperatures may indicate that the precipitation will not freeze to the roadway. Development Status: The Rules of Practice Module has been coded and has been integrated into the RTCM. As the current time, only treatments using plowing, abrasives, and/or NaCl have been coded. There is a desire to add additional chemicals and event triggers. This modules appears to be performing properly given the weather, road condition, and chemical concentration prediction data. Work to be performed: There is a desire to expand the logic to handle additional chemicals, event triggers, and logic to optimize treatments between chemical choices and mixes. 17 MDSS FP Display System Data from the Road Weather and Road Condition subsystems are disseminated to a single interactive display application that allows both high-level and detailed views of weather and road condition over time. Prediction information sent to the display updates every three hours. That is, a new forecast of weather and road condition is available to the user every three hours. The display system allows the user to:

a) View weather information for each user defined forecast point in the State b) Be notified when weather or road conditions are predicted to deteriorate in the

future (current default = 48 hrs) c) View road condition information at each user defined maintenance route d) Calculate winter maintenance treatment plans (e.g., chemical use, plowing, timing

of treatment, and location) for each route e) Review the predicted impact of the recommended treatment plans f) Perform what if scenarios to assess the impact of various user defined treatment

plans g) Compare treatment plans and shift schedules



h) Review the depletion of stock supplies for various treatment plans Users access the display system to determine where, at the state level, the weather is forecast to be poor during the next 48 hours. They can also use the display to determine poor weather and road conditions at the sub-district (route) level. The display system is map-based, and provides alerts where the weather and road conditions are predicted to require road treatment. The state view shows worst weather conditions for districts or sub-districts within the state during the 48 hour prediction period. Areas that are forecast to have weather that may affect road condition are colored to indicate the severity of the forecast. Areas that are forecast to have severe weather flash in this view. The user can click on any district or sub-district to view the forecast for that area. Forecast data can be viewed as a set of time-series graphs. Variables graphed include, but are not limited to air temperature, relative humidity, wind speed, wind direction, probability of precipitation, precipitation rate, precipitation type, road temperature, chemical concentration, mobility, and confidence. A representative forecast station point within each selectable area is used as the source for this information. The sub-district (route) view provides users a way to look at a forecast of weather conditions and road conditions for a set of plow routes associated with a single shed or maintenance garage. This view provides alerts for points where the road condition is forecast to drop below the acceptable level during the forecast period. Detailed information for all the weather forecast points within the area are available to the user for closer inspection – clicking on these points brings up time series plots similar to those described for the state view. In addition, the forecast road condition is available as a series of graphs for each plow segment. Variables from the road condition forecast such as mobility, snow depth on road, and chemical concentration are available on these plots. The initial road condition forecast assumes no treatment, so users will be quickly alerted to areas where road treatment is necessary to counteract the effects of weather. From the sub-district view, users can request road treatment recommendations for a plow route that has an unfavorable weather forecast. The system describes a recommended treatment and shows graphically how that treatment is forecast to affect road conditions. The user can make modifications (edit) to the recommended treatment and view the forecast road conditions based on that custom treatment. The user may want to make custom treatments due to staffing or stock constraints. The user can then compare the treatment options (no treatment, recommended treatment, and custom treatments), and choose the one most suitable for the given conditions. After the user has completed this process of choosing a treatment plan, the alert map for that plow route is colored based on the forecast road condition after the selected treatment has been applied. The display system also provides some basic functionality to allow users to display and print reports of scheduled treatments for each plow route. These reports will be designed in conjunction with DOT personnel so that they are appropriate for the truck drivers to



carry with them on their routes. The simple text based treatment plans could also be sent to user via e-mail or cell phone messages. The e-mail capability has not been implemented as of April 2002. The FP display has been coded as a Java application. The user will be guided through a software download process the first time the code is accessed. The MDSS FP display code will be downloaded to the local PC off a central server. Data necessary to populate the display will be obtained over the Internet. This configuration provides an efficient mechanism for processing and will result in a responsive interactive capability. 17.1 MDSS Alert Function The MDSS provides alerts to users as an aid for identifying when weather and road conditions are predicted to deteriorate over the forecast period.

17.1.1 Weather Alerts Categories Weather alerts appear on the State view page and indicate the worst condition predicted over the forecast period. The alert categories are configurable. The MDSS FP weather alert categories are currently (April 2002) configured as noted in the table below.

Weather Alert

Category

Precip Type Precip Rate (Lq Equiv) (inches/hr)

Wind Speed (mph)

RH (%)

Temperature (F)

Extreme Any ice Snow >= 0.15 “/hr Snow >= 0.05 ”/hr >= 25 mph Poor Snow 0.05-0.15 “/hr Snow >0.025 ”/hr >= 15 mph Rain >= 0.25 ”/hr < 35 F Marginal Snow Any Rain >= 0.01 “/hr None >= 30 mph None >=90% OK All other

conditions



17.1.2 Road Condition Alert Categories Road condition alerts are generated when road conditions are expected to deteriorate over the forecast period. The road condition alerts are based on the predicted mobility level. The MDSS FP road alert categories are currently (April 2002) configured as noted in the table below.

Road Alert Category Mobility Index Extreme 0 – 0.24 Poor 0.25 – 0.49 Marginal 0.5 – 0.74 OK 0.75 – 1.0

17.2 Sample Display Images In this section, sample display images are provided. The screen images represent the display system as of 5 April 2002. This page allows the user to login to the MDSS FP.

The MDSS login Page allows the user to login to the MDSS FP. The user can configure the system to pop up the initial view of choice (e.g., State View or Route View). Other user-defined settings could be added in the future.



The State View allows the user to get an indication of upcoming weather or road condition problems in the next 48-hrs. Weather and road condition alerts for each DOT maintenance zone are provided for 3 time periods. Alerts are color-coded as OK, Marginal, Poor, or Extreme. This graphic shows that southern MN will have poor to extreme conditions within 48 hrs. The user can then mouse over the zones to see detailed information on the cause of the alerts.

From the State View page, the user can select weather parameters and view the data at points within the State. The user can also mouse-over any prediction point and see a graphic of the alert category over time and the reason for the alert. The user can move the curser along the time bar to see data at different times. The user can animate the graphic to see how the weather changes with time.



The Route View page allows the user to see weather and road condition prediction information. A mouse-over on the route or prediction points allows the user to view the alert category and information related to treatment plans. In this example, the Morris domain was selected. Two routes are included in this view. From this page, treatment plans can be generated by clicking on the “Select Treatments” button.

A mouse-over of the route shows the road conditions if no treatment was performed. In this example, with no treatment, 3.8 inches of snow would accumulate and because there was no treatment, the chemical concentration at noon on February 24th is predicted to be zero and mobility decreases to 0.5 (where 1.0 is a dry road).



The Treatment Selector Page (above) for the TH-28 Morris route has been selected. The user asked for the “recommended treatment” to be calculated. The recommended treatment indicated the NaCl should be applied at midnight at a rate of 400 lbs per 2-lane mile. The time series graphic shows the snow depth results of no treatment and the recommended treatment. If the recommended treatment is performed, no snow accumulates on the road. From the Treatment Selector Page (below), the user can view other parameters for each selected treatment. The example shows the road temperature and chemical concentration 48-hr time series with and without the recommended treatment.



Once treatment options are selected, the user can view the results via the Time Series pages or Route Page via mouse-over. In this example, the user can see that at 12 pm on TH-28, the chemical concentration is predicted to be 3.6% and the snow depth on the road will be zero indicating that the recommended treatment plan (NaCl @ 400 lbs per 2 lane mile at 1 am) will melt the snow. Two treatments are recommended for I-94 (Alexandria).

From the Define Treatment Scenario page, the user can edit the recommended treatments or add their own. The results can be viewed on the time series windows. This allows the user to perform “what if” scenarios to determine the best coarse of action.



Once the user has edited the treatment plan and created their own alternative(s), they can view the results (see above). In the example, the recommended treatment (red line) of two applications of NaCl will keep the snow off the road, while the single application of NaCl will fail at noon and snow will accumulate. Other parameters such as chemical concentration can also be viewed for various treatment options.



The Database view (above) allows the user to view the ESS observations for the selected route, input constraints for treatment planning, and input shift information. The user can also select to split shifts. It also allows the user to view current stocks and how the stocks would be depleted for chosen treatment plans. This page assumes that an operational version of the MDSS would interface with the DOT operational database to input and export data.



This page was intentionally left blank.