Home > Publications

Printable Version [PDF 102 KB]
To view PDF files, you need the Adobe Acrobat Reader.
Contact Information: Paul Pisano at Paul.Pisano@dot.gov
Road Weather Management Progam Web Site

Concept of Operations for Clarus - The Nationwide Surface Transportation Weather Observing and Forecasting System


By

Paul A. Pisano
Federal Highway Administration
Road Weather Management Program
400 7th Street, S.W.
HOTO-1 Room 3408
Washington, D.C. 20590 USA
Voice: 202-366-1301
Fax: 202-366-3225
paul.pisano@fhwa.dot.gov

James S. Pol
Federal Highway Administration
ITS Joint Program Office
400 7th Street, S.W.
HOIT-1 Room 3416
Washington, D.C. 20590 USA
Voice: 202-366-4374
Fax: 202-493-2027
james.pol@fhwa.dot.gov

Lynette C. Goodwin
Mitretek Systems, Inc.
Intelligent Transportation Systems
600 Maryland Avenue, S.W., Suite 755
Washington, D.C. 20024 USA
Voice: 202-488-3033
Fax: 202-863-2988
lynette.goodwin@mitretek.org

Andrew D. Stern
Mitretek Systems, Inc.
Oceanic, Atmospheric and Space Systems
3150 Fairview Park Drive South
Falls Church, Virginia 22042 USA
Voice: 703-610-1754
Fax: 703-610-1563
astern@mitretek.org

Corresponding Author: Paul A. Pisano
Submission Date: 1 August 2005
Word Count (text body): 3,106
Relevant Committees: AH010T Task Force on Surface Transportation Weather, AHB15 Intelligent Transportation Systems, AHD65 Winter Maintenance

Abstract. Clarus is a U.S. DOT initiative to develop and demonstrate an integrated surface transportation weather observation data management system, and to establish a partnership to create a nationwide surface transportation weather observing and forecasting system. The Clarus Concept of Operations defines the environment in which the Clarus system will operate. It defines user needs, describes functional scenarios, and includes a conceptual system architecture. The Concept of Operations document is the first step in the systems engineering process being used to develop the Clarus system design. Designers have developed high level system requirements that satisfy the needs and objectives articulated in the Concept of Operations. Ultimately, the use of Clarus data will lead to the creation of new and enhanced environmental information products and datasets for both the surface transportation and weather communities.

INTRODUCTION

The purpose of this paper is to describe the Concept of Operations for the Clarus system. Clarus (which is Latin for "clear") is an initiative to develop and demonstrate an integrated surface transportation weather observation data management system, and to establish a partnership to create a nationwide surface transportation weather observing and forecasting system. The objective of Clarus is to enable weather service providers to provide enhanced information to all road, rail and transit managers and users to reduce the effects of adverse weather (e.g., fatalities, injuries, and delay) (1). The Clarus Initiative aims to demonstrate how an open, integrated approach to observational data management can be used to consolidate surface transportation environmental data. Surface transportation environmental data assimilated by the Clarus system will include atmospheric data, pavement and subsurface data, as well as hydrologic (water level) data - all of these types of data and information are referred to as "environmental data" and "environmental information" in this paper.

The Clarus Initiative is a joint effort of the U.S. Department of Transportation (DOT) Intelligent Transportation Systems (ITS) Joint Program Office and the Federal Highway Administration (FHWA) Road Weather Management Program, which resides in the Office of Transportation Operations. The initiative has four primary motivations (2):

  1. Provide a North American resource to collect, quality control, and make available surface transportation environmental observations so that state and local transportation agencies can be more productive in maintaining safety and mobility.
  2. Support real-time operational responses to weather events and weather impacts through the collection of surface transportation environmental observations.
  3. Enhance and extend the existing weather data sources that support general purpose weather forecasting for the protection of life and property.
  4. Integrate surface transportation environmental observations with existing observation data to support the enhancement and creation of models that make better predictions in the atmospheric boundary layer and near the Earth's surface to support more accurate forecasts.

The Clarus Initiative consists of two development components. The first component is the Clarus system—a network for assimilating and exchanging quality-controlled environmental data related to surface transportation. The second component involves service providers using Clarus system data to create tailored tools (e.g., decision support systems, route-specific forecasts). Such tools will illustrate the utility of these data sets and provide the genesis for new and enhanced environmental information products for the surface transportation community. The Clarus Initiative road map is shown in Figure 1.

BACKGROUND

The deployment of environmental observing systems by state agencies has been inconsistent due to funding constraints and other institutional issues (3). Federal surface observation efforts focus primarily on the aviation community and the installation of sensors at airports. Since weather observations collected at airports do not adequately meet the needs of state DOTs, they have invested in Environmental Sensor Stations (ESS) deployed along or near roadways and the Road Weather Information Systems (RWIS) that collect data from these field stations. Transportation managers utilize weather and pavement condition data from ESS to support operational decisions that improve both mobility and safety.

State and local transportation agencies have deployed over 2,500 ESS to provide managers with weather, pavement, and water level data. However, surface transportation environmental observing networks are not being leveraged for 21st century transportation operations. Currently, data from ESS are not managed to develop a comprehensive, coherent picture of regional or national conditions. The ESS owned by transportation agencies are a mix of various brands and models, and provide data in different formats at varying levels of quality. Central RWIS utilize numerous communication protocols, polling frequencies, and user interfaces. Further, transportation agencies have limited observation data sharing capabilities and few quality assurance methods. These conditions limit the utilization of these valuable data not only for surface transportation activities but also for use in the greater meteorological community. Clarus Initiative resources will be devoted to integrating data from fixed ESS as well as investigating the feasibility of obtaining environmental data from vehicle-based and remote sensing technologies (e.g., low power radar or Closed Circuit Television cameras).

To garner stakeholders' input, Clarus Initiative leaders have formed the Initiative Management Team, which includes representation from key constituent organizations and agencies, as well as the Initiative Coordinating Committee (ICC) which serves as an interdisciplinary source of expertise and guidance. The ICC is comprised of members of the transportation and meteorological communities in the public, private, and academic sectors (1). Stakeholders include observation system owners, instrument and observation platform suppliers, transportation system operators, weather information service providers, the National Oceanic and Atmospheric Administration (NOAA), and researchers. More information on the ICC can be found at www.clarusinitiative.org.

The ICC structure is shown in Figure 2. Through participation in ICC Task Forces, stakeholders have provided valuable input on the development of the Clarus Concept of Operations and system requirements documents. The Clarus Concept of Operations was completed in October 2005 (2). System requirements were finalized during fall 2005. By the end of 2006, the system design will be completed and a limited proof-of-concept demonstration will be conducted. After refinement of the system design, a multi-state regional demonstration will occur followed by a second regional demonstration during an FHWA model deployment project.

CLARUS CONCEPT OF OPERATIONS

The Clarus Concept of Operations defines the environment in which the Clarus system must operate. It is the first step in the systems engineering process being used to develop the system. The Concept of Operations describes the operational needs of users, depicts the behavior of the system and its interfaces, describes operational objectives of the system, and outlines a conceptual architecture for the system. The Concept of Operations document utilizes Unified Modeling Language (UML) use cases to visualize connections within the Clarus system and interfaces with external entities.

Clarus User Needs

The Concept of Operations focuses on describing the needs of various stakeholders and defining the system structure to meet these user needs. The users having the most immediate contact with the Clarus system will include the owners and operators of the observing systems that are providing information to Clarus, as well as those directly accessing the data contained within the Clarus system. The context diagram of Clarus user needs in Figure 3 depicts the entities interfacing with Clarus as well as data flows between entities and the Clarus system.

The primary contributors of surface transportation environmental data to the Clarus system are organizations that maintain observation data collection systems, such as state DOT maintenance divisions, local traffic management agencies, the railroad industry, and transit agencies. In addition to providing data, these direct users will receive metadata and flags indicating data quality from the system. Private and public sector weather service providers are also direct Clarus users. These providers will access raw Clarus data, along with data from other sources, to create value-added products and decision support tools that are customized for the surface transportation community. Other potential users include academic institutions, research organizations, and archival agencies, such as NOAA's National Climatic Data Center.

Functional Scenarios

To help define needs for the Clarus system design, the Concept of Operations presents a framework scenario for the system and outlines functional scenarios for various user groups. Because there is significant overlap across the functional scenarios, a general scenario was developed to describe common processes. The unique features related to specific user communities are represented in the functional scenarios. The general scenario can be supplemented with a functional scenario to demonstrate how the system will be employed for a particular market segment. Functional scenarios include narrative operational descriptions for the following user groups.

To illustrate typical concepts associated with applications of Clarus system data, the general scenario contains UML use case and sequence diagrams. The use case diagram defines the things that the actors want the system to do, while the sequence diagram portrays a typical sequence of operation between the actors and the Clarus system. An actor is defined as any external operator or system interfacing with Clarus. The general scenario includes a step-by-step flow of activities that depicts how Clarus data are collected, processed, and distributed to various users or product consumers. In the following list of activities, entities are noted with bullets and sub-bullets represent the activities that each entity is responsible for. Time generally increases as the list progresses.

In general, surface transportation organizations (e.g., a State DOT) collect environmental observation data from their ESS and transfer this data to the Clarus system database. Clarus also acquires environmental data from external sources, including observing systems operated by NOAA. The system then consolidates and evaluates the data in a quality control process that flags anomalous observations. Due to their extensive involvement in the collection, processing, quality control and assimilation of hydro-meteorological data, it is anticipated that NOAA data will provide the foundation for the quality control function within the Clarus system. The quality-controlled data will then be made available to three groups: Flagged data will be transferred back to surface transportation agencies to indicate potential anomalies within their data set. Service providers will integrate and transform Clarus data to create enhanced presentations and value-added products for end users or consumers. Clarus data will also be integrated with NOAA data to enhance forecasts. Both the surface transportation and weather information communities will benefit from the tools and products created by service providers.

Conceptual System Architecture

Based upon operational objectives, the Concept of Operations identifies a conceptual architecture framework for the Clarus system. The system design must be sufficiently robust to ensure reliable acquisition, processing and distribution of large volumes of observation data in a timely manner. The system must be designed with the flexibility to manage data from thousands of ESS deployed around the country, environmental and location data from vehicle platforms, as well as data derived from other sources such as Closed Circuit Television (CCTV) images and phased array radar (4). The extent of these data types presents challenges associated with quality control and database design. An extensible system will be needed to accommodate data from new sensor technologies (e.g., non-invasive pavement condition sensors) and incorporate new user functions as the system evolves. The Clarus system must also facilitate regional sharing of surface transportation environmental data while supporting data integration with national resources, such as the Integrated Surface Observing System (ISOS) program under development by NOAA, as well as international systems such as Canada's Road Weather Information Network (RWIN) (2).

In order for Clarus to achieve these operational capabilities, a broad range of technical issues must be addressed as the system architecture is defined. Regarding data acquisition and integration, the system must accommodate disparate data types, data formats, database structures, and communication protocols. Many state agency observing systems utilize non-standard and proprietary communication interfaces. The architectural framework must support such systems as well as data standards employed by both transportation and weather communities.

Data validation will occur once data has been collected and stored in the Clarus database. The system will have to detect and flag erroneous data, out-of-range data, and data that is inconsistent with surrounding observations prior to distribution. The system architecture must support various data delivery formats and multiple access modes to serve both transportation and weather information stakeholders. Scheduled delivery, request-based, subscription-based, and data-driven dissemination methods should all be supported.

CLARUS SYSTEM DESIGN

Design documents for an open, extensible Clarus system are being created using a systems engineering approach. Designers have developed system requirements that satisfy the needs and objectives articulated in the Clarus Concept of Operations and by stakeholders via Initiative Coordinating Committee (ICC) Task Forces. The system design effort involves development of system requirements, an architecture analysis and a design gap analysis, as well as development of hardware configuration and system software specifications. The deployed Clarus system is envisioned to include:

Clarus High Level System Requirements

High level system requirements specify the environment and operating state for the Clarus system without allocating capabilities to specific modules or subsystems. This approach limits the high level requirements to those that can be derived from a context diagram, Figure 4, which depicts the Clarus system as a single functional block with interfaces. These requirements describe data input to the system by observing system owners, what happens within the Clarus system (e.g., data integration, quality control), dissemination of data or output, the controlling rules and constraints under which the system operates, and the means of data management.

The high level system requirements are categorized into functional requirements, performance requirements, and organizational requirements. Functional requirements identify what is done by the system, what inputs are transformed to what outputs, and what specific operations are required. The functional requirements are grouped by general functions, data functions, and interface functions. The general functional requirements apply to the system as a whole. Functional data requirements describe the management of data to be acquired, processed, and disseminated by the system. The functional interface requirements describe the functional interfaces between observation system owners and Clarus, and between the system and service providers.

Performance requirements specify the static and dynamic capacity for the number of users, connections, and other performance related factors. These requirements are divided into design constraints, quality requirements, and system performance requirements. Design constraints are imposed by standards and regulations, or software and hardware limitations. Quality requirements address the general quality, usability, extensibility, flexibility, and maintainability of the system required for a high level of service. System performance requirements quantitatively describe system functions and time constraints.

Organizational requirements include policies and procedures to support the implementation, operations, training, security, and institutional arrangements for the system. These requirements also detail logical characteristics between the system and external data sources, specify the level of integration with external systems, define the interfaces with each user group, and specify communications interfaces and protocols that should be supported.

Designers have also developed detailed system requirements that describe computing resources and information flows for all functions in the high level system requirements document. Together, the high level system requirements and detailed system requirements documents contain all functional, performance, organization, hardware, software, interface and testing requirements for Clarus.

CONCLUSION

The ITS Joint Program Office and the FHWA Road Weather Management Program have embarked on a multi-year effort to design the Clarus system and plan for an operational nationwide surface transportation weather observing and forecasting system. The Clarus Initiative combines systems engineering techniques, network and software design, technology research, and increasingly complex field demonstrations to develop and establish an advanced surface transportation environmental observing system. This paper describes the Clarus Concept of Operations that defines user needs, depicts the system architecture and describes operational scenarios, which lay the foundation for the system designers to develop system requirements.

Clarus will leverage investments in ESS to collect, quality control, archive and disseminate surface transportation environmental observations. One-stop access to quality-controlled Clarus data will stimulate creation of new observational products and foster development of more accurate, route-specific forecasts and decision support applications. The long term vision of the Clarus initiative includes broadened participation and resource sharing by public and private sectors across both the surface transportation and weather information communities.

REFERENCES

  1. Intelligent Transportation Society of America, "Clarus Initiative Web Site," 2005, www.clarusinitiative.org.
  2. Iteris and Meridian, "Clarus Concept of Operations," prepared for the FHWA, October 2005.
  3. National Research Council, "Where the Weather Meets the Road: A Research Agenda for Improving Road Weather Services," page 78, National Academies Press, www.nap.edu/catalog/10893.html.
  4. Pisano, P., et al, "Clarus – the Nationwide Surface Transportation Weather Observing and Forecasting System," presented at the Annual Meeting of the Transportation Research Board, January 2005.
  5. Mixon/Hill, Inc., "Clarus Weather System Design: High Level System Requirements Specification," prepared for the FHWA, July 2005.

Figures

Figure 1 displays the Clarus Initiative road map. Track 1 consists of Stakeholder Coordination starting Fiscal Year 2004 to 2009; Track 2 System Design starting Fiscal Year 2004 to 2006, and Track 3 Multi-State Regional Demonstration starting Fiscal Year 2006 to the beginning of Fiscal Year 2008 and Final Design, Model Deployment starting Fiscal Year 2008 to 2009.
Figure 1 - Clarus Initiative Road Map (1) Return


Figure 2 dsplays the chart of the Clarus Initiative Coordinating Committee (ICC) Structure.
Figure 2 - Clarus Initiative Coordinating Committee (ICC) Structure (1) Return


Figure 3 displaying the context Diagram of Clarus User Needs. The following feeds raw data to Clarus: Federal, State and Local Agencies; Transit; Vehicle; and Rail. Clarus feeds quality controlled data back to them. Clarus also feeds quality controlled data to Surface Transportation Weather Service Providers; Research; Data Archives; and Weather Service Providers.
Figure 3 - Context Diagram of Clarus User Needs (2) Return


Figure 4 depicts the Clarus system as a single functional block with interfaces. The interfaces are Controls (Operations Management, Constraints), Input (Environmental Dta Collection), Output (Data Dissemination) and Means (Data Management, Infrastructure).
Figure 4 - High Level System Requirements Context Diagram (5) Return