Weather-Savvy Roads
Integrating Mobile Observations: Lessons from Front Line Deployers

Printable version [PDF 1.9 MB]
You may need the Adobe® Reader® to view the PDFs on this page.
Contact Information: Operations Feedback at OperationsFeedback@dot.gov

U.S. Department of Transportation
Federal Highway Administration
Office of Operations
1200 New Jersey Avenue, SE
Washington, DC 20590
ops.fhwa.dot.gov

FHWA-HOP-18-076

Integrating Mobile Observations (IMO) involves collecting atmospheric weather, road conditions, and native data from government fleet vehicles' ancillary weather sensors and vehicle-based controllers. The data provide maintenance and operations managers with a more detailed view of the weather and road conditions as well as asset locations along the highway network. This information supports a host of road weather management strategies, including maintenance, traffic, and performance management.

This fact sheet incorporates many of the lessons learned and best practices that were captured from the Minnesota (MnDOT), Nevada (NDOT), and Michigan (MDOT) Departments of Transportation (DOTs) that have been involved with IMO for several years. Each of the DOTs used a systems engineering approach to implement IMO. The information conveyed is centered around the systems engineering process. Information also comes from the Clear Roads Pooled Fund study on automatic vehicle location and global positioning systems (AVL/GPS). This fact sheet is intended for those who deploy IMO technologies, breaking down deployment into key steps to help make it manageable.

Step 1: Engage Stakeholders and Champions

The first step is to identify key stakeholders and champions, including all those who will be using, approving, funding, or managing the project. Establishing a diverse set of stakeholders and champions is paramount to success. Factors to consider at this stage include:

• Engage a set of champions to keep positive momentum going throughout the project.
• Keep upper management informed.
• Engage stakeholders throughout who will be affected by the data, such as maintenance, operations, construction, IT, etc. Include contributors and consumers of the data.
• Engage IT from the beginning as they will be essential throughout the project.
• Engage other agencies throughout the State as appropriate, such as highway patrol, metropolitan planning organizations, and local transportation agencies.

MDOT selected staff supervisors in each region to be champions for the project. For MDOT, selecting champions dramatically increased participation and sustainability. MDOT staff supervisors helped sell the idea at every level in their organization and kept management apprised of each situation.

Step 2: Develop a Concept of Operations and Identify Needs

A Concept of Operations (ConOps) is a document that provides an initial definition of the IMO system. Development of a ConOps allows each of the stakeholders to reach a common understanding of how the system will meet its users' needs and expectations and how it will be operated. It is therefore essential that the ConOps examines and defines the proposed system from the viewpoints of each of the system users—managers, operators, and maintainers. Developing well-formed use cases in the ConOps will help define the functional requirements in Step 3.

The ConOps is the one systems engineering document that must be presented in the most accessible, easy-to-understand, and non-technical style. If this is accomplished, the document will have the greatest likelihood of achieving the goal of allowing all the stakeholders to buy into the IMO concept that is being proposed.

In developing the ConOps, identify and document the needs of prospective users of the IMO system. Typically, this involves choosing between what is necessary and what are "nice to have", based on what can be done, what is affordable, and what is achievable. Identifying these needs will form the foundation for creating requirements that can then be traced throughout the IMO project.

Step 3: Develop Requirements and Architecture

Developing requirements that are sound and detailed is another crucial step in the systems engineering process. Effective requirements will limit scope creep, alleviate disappointment, support budget and schedule management, and ensure that a solution is delivered in line with expectations. This step will transform the narrative discussion of needs and pictorial use cases in the ConOps into a measurable list of functional, performance, and organizational requirements that effectively describe the overall operation and constraints of the desired system. Requirements describe what the system must do—not the detail of how it is done or what specific inputs or outputs might look like. Requirements that are vague, open-ended, or unbounded must be constrained and re-stated, or they cannot be tested when the system is complete.

Data Uses and Sharing to Consider for Requirements

There are many uses for the data received and it can be used by multiple departments within the agency. Some ideas follow:

• Include IMO data in the Maintenance Decision Support System (MDSS) to enhance the available road weather observations for enhanced treatment recommendations.
• Use Controller Area Network (CAN) bus engine diagnostics and trouble codes to identify vehicles with maintenance issues.
• Generate reports such as:
  • Recommended versus actual treatment applications
  • Vehicle speed while applying chemicals End-of-shift Material usage by route
  • End-of-shift
  • Material usage by route
  • AVL status
  • Spreader status
• Provide the public with traveler information including the location of plows, pictures, and road weather observations.
• Share the IMO data internally with TMCs for operations; work zone or construction teams to plan activities; and maintenance supervisors for scheduling activities such as herbicide applications, striping, mowing, pothole repair, etc.
• Share the IMO data externally with FHWA's Weather Data Environment to quality-check the data and make it available to developers, researchers, applications, etc.
• Use the IMO data to track instrumented vehicles.
• Consider using the Pikalert® system to quality check the data and create forecasts and traveler information messages.
• Integrate the IMO data into asset management systems
• Automatically populate timesheets or end-of-shift reports based on IMO data.

A detailed description of system architecture is usually created at the same time as the requirements. The description of the architecture shows what interfaces connect the sub-systems and what requirements are allocated to each sub-system and interface.

At a minimum, sections should be created from the following viewpoints:

• Operational: Overview of the purpose, scope, and roles played by the system.
• Information: Overview of the data schemes, data interfaces, and data flows for the system.
• Software: Overview of the computational objects (software modules), program interactions and behavior, and software interfaces that form the system.
• Hardware: Overview of the planning for the hardware, communications, and operational support for the system.
• Technology: Overview of what relevant technologies will be used, how industry standards and specifications will be implemented, and what technologies will be required to support testing of the system.
• National Intelligent Transportation Systems (ITS) Architecture and Connected Vehicle Reference Implementation Architecture (CVRIA): An understanding of how the proposed system fits into the National ITS and CVRIA architectures. This includes the system's relationship to the standard market packages and to the National ITS and CVRIA physical and logical architectures.
• State and Regional ITS Architecture: An understanding of how the proposed system fits into the State and regional ITS architectures. This includes the system's impact on the State and regional architectures and the system's relationship to the standard market packages and to the National ITS physical and logical architectures. As the project progresses, the State and regional architectures should be updated to include the IMO details.

Step 4: Develop a Detailed System Design

The system design addresses stakeholders' concerns as identified in previous tasks, consistent with the system requirements and architecture. Design decisions should be documented on interfaces, input and output, algorithms, resources, and error handling, providing traceability from requirements and architecture to implementation.

The system design will provide the overview necessary for understanding the implementation and the rationale of design decisions. It also will specify the tools and processes to be used to make the system real. The design should describe the context of the system and interaction of components within the system, as well as the logical structure of and interfaces between components using sequence diagrams, class diagrams, use-case diagrams, and other diagrams as appropriate.

Individual software processes should be described, including their distribution across the system and network, indicating what processes will be hosted on a vehicle versus what will be hosted on a backhaul system. In addition, the design should identify what application and business logic will be supported by each process. Distribution and responsibilities of software components should be decided on to provide a robust, reliable solution that minimizes technical risks that would affect the successful implementation of IMO.

During the design phase, all types of equipment and communication platforms should be decided on such as external weather sensors that provide atmospheric and pavement observations that can be used by maintenance personnel, decision support systems, and traveler information; cameras that provide snapshots of roadway conditions in near real time; AVL/GPS that provides the location of the vehicle, such as latitude, longitude, and elevation; commercial off-the-shelf (COTS) and/ or custom software that will be needed to tie all the pieces together, including collecting data, transforming the data for transmission, storing the data, and making the data available to other systems; and communication platforms for transferring data from the vehicles to the back office (e.g., cellular, dedicated short-range communications [DSRC], and radio).

Step 5: Implementation

The implementation phase contains several critical activities for the successful deployment of IMO: procurement, software and hardware development, and installation. The steps for the implementation phase apply to small- and large-scale deployments.

Procurement

Procurement of IMO hardware, software, and communications can be the most expensive and time-consuming part of the IMO project. During procurement planning, start by taking advantage of solicitations created by other IMO deployers. There may be many requirements that can be reused in the procurement documents.

When considering hardware options: Use industrial grade products; recognize that proprietary software may be required to run COTS hardware; evaluate the physical size of the hardware (it must fit the available space in/on the vehicle); verify that the data collection device has sufficient ports (cable connections) for current and future needs and that the ports are the correct types (e.g., serial, USB, or HDMI); negotiate prices for bulk and individual purchases (it is generally more expensive to purchase a few at a time); establish integration processes to the spreader controller; determine the level of customer support provided for installation, troubleshooting, and training; make sure to evaluate the warranty period; negotiate the waiting period for replacement equipment/parts; and consider including a maintenance contract.

• External Weather Sensors: Some observation types for consideration are air temperature, surface status, relative humidity, dew-point temperature, friction, and surface temperature. Validate that sensors comply with NTCIP 1204; consider custom sensors for observations such as wiper status, but verify that the technology can be supported.
• AVL/GPS: Evaluate the need for a full AVL/GPS system—additional information can be found on the Clear Roads website (http://clearroads.org). Consider a cell card to provide this information.
• Spreader Controller: Whenever possible, use COTS spreader controllers that conform to the Clear Roads specifications for interoperability (http://clearroads.org). Specify the data that should be collected by the spreader controller, such as the chemical application rate, the state (e.g., on or off) of the spreader or sprayer, and the chemical being applied.
• Cameras: Determine the camera's intended use (e.g., road weather condition, atmospheric condition, backing up, material output) and the mounting location (e.g., ceiling, windshield, top of cab, back of vehicle) to specify the correct type.
• Communication Platforms
  • Cellular: Requires at least a 3G connection; specify a cell card, not a cell phone (cell phones are very susceptible to extreme weather temperatures); utilize in areas where cell coverage is good (MnDOT has deployed cellular statewide); negotiate a contract with the carrier to minimize monthly costs; consider turning the system off during the summer weather season.
  • DSRC: Requires roadside units; utilize in areas where cellular is unavailable or basic safety messages are required.
  • WiFi: Certain data (e.g., accelerometer data) doesn't make sense to send in near real time, so create a WiFi hot spot at the shop to download the data. When data is unable to be sent via cellular or DSRC, utilize hot spots along a route.
  • Radio: Short, compact messages can be sent over the State's radio system; the priority of the message will probably be rated low because it could be competing with entities such as the highway patrol.

Software and Hardware Development

In some cases, it may be necessary to develop custom software and hardware. When that is required, ensure qualified staff are in place; have a detailed sustainability plan; use modern coding standards; document the code with comments; enable remote software updates; establish a version control system that ensures the stability of the software; use open-source software wherever possible; and check with IMO deployers for existing software available.

Installation

Implementing IMO technologies into the vehicles requires planning and thoughtful consideration. Key factors to consider are:

• Determine the ages of the vehicles you are not going to instrument (e.g., no vehicles over 8 years old).
• Create schematics for installers for each vehicle type, manufacturer, and model showing interfaces, equipment location, etc.
• Train installers throughout the State to minimize out-of-service time.
• Schedule installations well in advance.
• Instrument all new vehicles before they are deployed into the field.
• Train drivers on the IMO technologies—not just the equipment, but how the data will be used and the expected benefits.
• Install the camera on the ceiling of the cab or high on the windshield (when installed on the dash, it may be used as a hat rack or materials may be placed in front of it obscuring the lens); avoid interfering with the operator's field of view.

Step 6: Test Everything

During the testing phase, create two documents (or combine them into one): a test plan and test scripts. The test plan forms the basis of the system acceptance and describes the scope, approach, resources, and schedule of the test activities.

The test scripts are a series of step-by-step instructions for testing that are based on the requirements, architecture, and design. The results of the testing are documented at each instruction. The test scripts can then be used throughout installation by installers, database administrators, IT support personnel, evaluators, and others.

Final Thoughts

IMO can be a powerful resource for capturing and using data for many road weather management strategies, including maintenance, traffic, and performance management decision-making. Utilizing a systems engineering approach helps ensure that all the requirements are included in the design and implementation of the IMO system. Reach out to other IMO deployers when issues arise; the IMO community may have the answers or solutions. Share best practices, lessons learned, procurement, and systems engineering documents with other IMO deployers on the Road Weather Management Exchange: https://go.usa.gov/xnS8V.

For additional information, please contact:

Roemer Alfelor
roemer.alfelor@dot.gov
(202) 366-9242

Ray Murphy
ray.murphy@dot.gov
(224) 415-1449

Gabriel Guevara
gabriel.guevara@dot.gov
(202) 366-0754

Joe Huneke
joseph.huneke@state.mn.us
Minnesota DOT

Steve Cook
cookS9@michigan.gov
Michigan DOT

Rod Schilling
roschilling@dot.nv.gov
Nevada DOT

www.fhwa.dot.gov