U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000


Skip to content U.S. Department of Transportation/Federal Highway AdministrationU.S. Department of Transportation/Federal Highway Administration

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

3.8.1 System Retirement / Replacement

 

OBJECTIVE:

This step describes what activities are needed to determine when an Intelligent Transportation System or major sub-system needs to be retired or replaced. It also provides guidance on a replacement strategy.

DESCRIPTION:

This step in the process provides guidance on determining the end of life for a system or sub-system. The end of life for a system or major sub-system can be a planned event or it can occur as a result of the following factors:

  • high cost of operations & maintenance
  • capabilities of the system are no longer needed or cost effective
  • high cost of upgrades and changes
  • Technology obsolescence making the system/sub-system unsupportable.

Eventually most system/sub-systems will face some major replacement no matter how well it was developed or maintained.

To get the maximum useful life out of a system/sub-system, it must be well designed, documented, and maintained. The following are factors that will certainly shorten the useful life of a system or sub-system:

  • lack of documentation
  • no agreement on a concept of operations
  • inadequate operations & maintenance budget
  • no configuration management process that synchronizes changes with system documentation

When a system or sub-system needs to be replaced, a strategy must be developed to migrate to the new system or sub-system.  This strategy will become part of the systems engineering management plan.

CONTEXT OF PROCESS

Shows the flow for Phase [5] task, System Retirement/Replacement Process.  Summaries are described for inputs, constraints, and enablers into the task;  activities of the task; and outputs from the task.  The flow is described in detail in the accompanying text.

SYSTEM RETIREMENT/REPLACEMENT PROCESS

Inputs:

Legacy system is the system or major sub-system that is subject to retirement and or replacement.

Identified needs are the new user requirements that the legacy system is to address.

Change request is the documentation that defines and describes the changes needed to the legacy system or sub-system to meet the new needs. This comes from the configuration management process.

Controls:

Project Plan/Systems engineering management plan [SEMP]contains the development strategy for the replacement system or sub-system.

Configuration Management Plan would have the processes documented which would evaluate the change history, costs, and impacts of changes.

Enablers:

Stakeholder involvement is essential. Stakeholders who will be affected by the change must be involved in the process of replacement or retirement of the system.

Trade Studies is the process tool which can be used to evaluate whether to replace or upgrade the legacy system. This enables the stakeholders to decide what the most cost effective approach is.

Traceability ensures that the integrity is maintained through replacement, it also supports cost estimation for making decisions to replace or retire.

Outputs:

Retirement/Replacement Plan is part of the Project Plan/SEMP that provides the overall strategy for retirement and replacement of the system.

Retirement/replacement decision versus upgrading and changing the legacy system.

Replacement strategy documents the way the system or sub-system will be replaced. This will become part of the systems engineering management plan for the next evolution of development.

Process Activities:

Plan retirement and replacement

The initial planning of the project may include a replacement plan for the system or sub-system. This may include the deployment of an interim system to address an immediate need. At the time of replacement the system's owner and affected stakeholders should assess and review the plan, to see that it is still viable. It is important to reassess the plan, especially if the needs have changed or there are new stakeholders involved.

Perform Gap Analysis: legacy system capabilities versus capabilities needed

The trade studies process can evaluate the cost/benefit of upgrading the current system or replacement of the entire system or some major sub-system[s]. Can the current system evolve to meet the new needs? Was the technology that was used in the current system obsolete and no longer supportable? Are the operations & maintenance costs to the point where a replacement system is more cost effective?

Evaluate the cost of upgrade versus replacement

The trade study should include life cycle cost analysis, including the operations & maintenance costs, and replacement costs. Issues to address in the evaluation are the vendor support of COTS products and license costs. Is the cost of documenting the existing system prohibitively expensive?

Develop the replacement/retirement strategy

A strategy for system or sub-system replacement needs to be planned for the replacement of an ITS. This planning may require the upgrade of facilities, floor space, air conditioning, communications, furniture, and other such facilities. Because some systems are safety critical, they have to be operational full-time. In this case, the new system would need to be deployed in parallel with the legacy system. A switch-over plan needs to be created to allow the legacy system to act as a back-up while the new system is being verified and validated. There is a cost and deployment impact of having both systems fielded for that period of time. In other cases, functionality may not be safety critical. In these cases, removing the legacy system prior to the deployment of the new system or sub-system may be more cost effective.

Illustrates where Retirement/Replacement occurs in the Vee Development Model.  Retirement/Replacement is defined in the Concept of Operations section.  Retirement/Replacement is performed in the Retirement/Replacement section.     

Where does the Retirement/Replacement activity take place in the project timeline?

Is there a policy or standard that talks about Retirement/Replacement?

This task would include all the tasks from phase [-1] to 4 including all FHWA Final Rule requirements and standards.

Which activities are critical for the system's owner to do?

  • Participate in the reassessment of the replacement/retirement plan. If in the original development, this was a planned replacement or retirement, reevaluate the plan to see if the planned replacement is still needed
  • Be involved in the assessment of alternative replacement systems or sub-systems
  • Participate in the Configuration Management process to assess the cost of upgrade to the legacy system versus its replacement
  • Elicit stakeholder involvement and support for the upgrade or replacement decision
  • Participate in developing the replacement strategy for the system/sub-system

How do I fit these activities to my project? [Tailoring]

The replacement strategy can be tailored for the project but factors that constrain this will be if the legacy system or sub-system is critical to public safety and needs to be operational nearly full time. Are there alternates to the legacy system or sub-system operations that can allow it to be inoperable until the new system is in place, verified, validated, and operational?

What should I track in this process step to reduce project risks and get what is expected? [Metrics]

On the technical side:

  • In replacing a system or sub-system, identify the new capabilities [functions] that will be added to the legacy system/sub-system capabilities.
  • Track and manage the technical documentation of the new system/sub-system. Is the new system/sub-system well documented? For example, is the following documentation available to the system's owner and stakeholders:
  • Requirements specification
  • Design documents
  • Interface specifications
  • Documentation of enabling products [e.g. verification, maintenance, production, development, and training documentation]

On the project management side:

Identify the life cycle cost of the new system/sub-system. Will the new system/sub-system have an improved cost/benefit ratio in operations & maintenance cost over its life? [The new system should work better and cost less to maintain.]

Checklist: Are all the bases covered?

check Was a trade study done on the cost/benefit of upgrading the legacy system/sub-system against the cost/benefit of developing or procuring a new system/sub-system?
check Did the trade studies include the operations & maintenance costs of the legacy and new system/sub-system?
check If there was an initial plan to replace a system or sub-system, has that plan been reviewed prior to replacement to assess if it is still viable?
check Is the new system/sub-system well documented? Does it have at a minimum:
  - New concept of operations
  - Requirements documentation
  - High-level design documentation
  - Detailed design documentation
  - Verification plans
  - Support documentation on development, training, maintenance, and users manuals
check Is there a replacement strategy to switch out the legacy system/sub-system with the new?
check Have all of the affected stakeholders been involved in the replacement/retirement decision, and the planning and replacement strategy for the new system/sub-system?

Are there any other recommendations which can help?

Tip.When a system needs to be replaced, do it in an incremental manner [sub-system by sub-system]. Here are examples of replacement strategies for two different types of systems, "A Traffic Control System" and" A Regional Advanced Transportation Management System".

Strategy for replacing a Traffic Control System

Option 1 - Deploy the new traffic control system in parallel with the legacy traffic control system, incrementally add intersections replacing or reconfiguring field controllers based on the current segmentation of communications layout.

Option 2 - Run "time of day" as the field controllers remove the legacy central host, and deploy the new traffic management system central host, add intersections incrementally replacing or reconfiguring the field controllers. The strategy would depend on the current availability, flexibility, and accessibility of the communications infrastructure that exists.

Replacement of the host software in a Regional Advanced Transportation Management System [ATMS]

In this situation, the replacement strategy is largely driven by the project architecture of the legacy system and the modularity of the legacy software.

If well defined interfaces exist between the field devices and the ATMS host, the replacement strategy is done at these interfaces. The new host system is deployed in parallel with the legacy system and an incremental switch-over is made sub-system by sub-system. For example, the changeable message sign sub-system is switched over, followed by the camera sub-system, then the ramp metering sub-system, then the detection and incident management system. Stand alone functions are the easiest to switch over. Integrated functions such as the detection and incident management functions will be more difficult. The important issue here is to be able to switch back, if needed. If the software of the legacy system is such that removing a sub-system causes the legacy system to act in an unpredictable way, temporary software or hardware simulators may be needed to simulate the missing sub-system from the legacy system until the switch over is completed. The switch over will require additional staff since two systems will be running in parallel.

The overriding concern is the safety to the public. These switch-over events should be done on off- peak hours or divert traffic to a safer route until the switch-over is completed and tested.

If the interfaces to the field devices are not well defined, it is recommended that the interfaces to the field devices be developed first before adding the host system.

 

Checklist  

 

Return to top
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000