Office of Operations
21st Century Operations Using 21st Century Technologies

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

U.S. Department of Transportation - Federal Highway Administration (logo)

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


On-Ramp to Innovation - Every Day Counts (logo)

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.

Research Funding Sources

In addition to identifying internal funding sources, research other funding opportunities such as the possibilities below.

State Transportation Innovation Councils (STIC) Incentive Program

Offers technical assistance and funds—up to $100,000 per STIC per year—to support the costs of standardizing innovative practices in a state transportation agency or other public sector STIC stakeholder.

Accelerated Innovation Deployment (AID) Demonstration Program

Provides funding as an incentive to accelerate the implementation and adoption of innovation in highway transportation (up to $1 million). Applications accepted under Opportunity Number FHWA2016-21063 through

Advanced Transportation and Congestion Management Technologies Deployment (ATCMTD) Program

Provides grants for the development of model deployment sites for large-scale installations and operation of advanced transportation technologies to improve safety, efficiency, system performance, and infrastructure return on investment.

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

It is important to know how you intend to use the technology and what your needs are before writing specifications. Operators and managers should be informed well in advance and throughout the project what the expectations are. Problems should be addressed as quickly as possible. If possible, do a pilot project in advance to identify issues and opportunities. Be open to possibilities for additional use of the technology. Look for all of the value that you can get. Learn from the experience of your peers in other organizations.

Source: Nebraska DOT

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.

West Des Moines Public Services has installed technology and sensors on all 16 plow trucks. This figure shows the technology installed in the interior of a truck.

Figure 1: West Des Moines Public Services has installed technology and sensors on all 16 plow trucks.
(Source: West Des Moines Public Services)

Step 3: Develop Requirements and Architecture


Regularly scheduled calibration of equipment is essential to ensure optimal performance and quality data. West Des Moines, Iowa, found that some sensors can take up to 15-30 minutes to accurately measure outside pavement temperature after being inside a warmer, garage environment, which needs to be accounted for in data reporting.

Technology integration

Installing sensors adds complexity to plow truck hydraulic and/or electrical systems. If not handled appropriately this can present challenges between the technology, plow operator, and person maintaining the technology. Although it may seem as if everything works in unison, agency staff must integrate the technology such that the entire system is not shut down if one component fails, so the plow truck can continue to operate on the road when needed. Increased collaboration with system vendors may be useful in addressing these issues.

Source: City of West Des Moines, Iowa

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:

Communication within the IMO project team and with the users of IMO technologies is vital to a successful deployment.

Prior to deploying IMO, provide a field demonstration, a powerful communication tool, to gain widespread acceptance for implementing IMO technologies.

Keep the drivers engaged:

  • Institute a weekly report sent to all drivers showing each driver the number of miles driven as well as photos taken.
  • Conduct a weekly meeting to update the team on how the technology works; planned software upgrades; installation plans; and providing an opportunity for questions and concerns from the drivers.
  • Provide a detailed report that serves as the basis for each week's discussion of the major issues facing the team for the coming week with each issue ranked in order of importance and that includes: description of the problem and status, the risk, the mitigation plan, expected completion date, project goals affected, and number of vehicles affected.
  • Report progress to upper management on a regular basis.
  • 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.


Leveraging other agencies' experience in RFP and requirements development, procurement, installation, and operations is extremely valuable.

Specifications of the system in the RFP should not be too specific to limit agency's options and flexibility.

Using an all-encompassing contract to hire one single vendor to be responsible for delivering a desired solution reduces agency staff resources required and helps integration of multiple systems; although this approach might increase the overall project cost.

Experience shows that support from executive management makes procurement and roll-out quicker.

An aggressive installation schedule may hinder an agency's ability and opportunity to perform desired level of user outreach.

Adequate training is key to buy-in and successful operation. Having tech-savvy staff performing outreach, conveying key messages, and supporting installation and operations helps alleviate concerns and promote buy-in.

Timing of the AVL system installation should be arranged to avoid conflicting with winter seasons when the availability of winter maintenance vehicles may be limited.

Source: Utilization of AVL/GPS Technology Case Study: Michigan DOT

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 ( 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 ( 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.


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

CAN bus

The CAN bus can provide valuable information about the performance of the vehicle and the state of its components (e.g., brake or wiper status), but there are many challenges in obtaining the data.

Vehicles come in different model years, models, and trim, and with different accessory, and safety packages. Automakers have a difficult time finding information for models that are 2 or 3 years old much less 7 or 8 years old. Engineers are focused on current and future development. As the result of staff reductions and outsourcing, there are also fewer engineers that know how to interpret the CAN bus message codes.

Experience suggests not beginning a CAN bus implementation until a manufacturer not only provides the necessary CAN data, but also agrees to provide technical support regarding CAN bus message codes and data acquisition.

Having the support of product development supervisors who can work in the engine control unit area can be very valuable in providing CAN code interpretation.

  • 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:

For additional information, please contact:

Roemer Alfelor
(202) 366-9242

Ray Murphy
(224) 415-1449

Gabriel Guevara
(202) 366-0754

Joe Huneke
Minnesota DOT

Steve Cook
Michigan DOT

Rod Schilling
Nevada DOT

Office of Operations