- Briefing Room
U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
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.
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:
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:
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
SYSTEM RETIREMENT/REPLACEMENT PROCESS
Legacy system is the system or major sub-system that is subject to retirement and or replacement.
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.
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.
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.
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.
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.
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?
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:
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?
|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?
|Did the trade studies include the operations & maintenance costs of the legacy and new system/sub-system?
|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?
|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
|Is there a replacement strategy to switch out the legacy system/sub-system with the new?
|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?
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.