| Related: |  |
 |
|
OBJECTIVES |
Use and maintain the system over the course of its operational life. |
|---|---|
|
Description |
Once the customer has accepted the ITS system, the system operates in its typical steady state. System maintenance is routinely performed and performance measures are monitored. As issues, suggested improvements, and technology refreshes are identified, they are documented, considered for addition to the system baseline, and incorporated. An abbreviated version of the systems engineering process is used to evaluate and implement each change. This occurs for each change or upgrade until the ITS system reaches its end-of-life |
|
COntext |
|
|
INPUT Sources of Information |
· Operations and maintenance procedures · Training materials |
|
PROCESS Key Activities |
· Conduct Operations and Maintenance Plan Reviews · Establish and maintain all operations and maintenance procedures · Provide user support · Collect system operational data · Change or upgrade the system · Maintain configuration control of the system · Provide maintenance activity support |
|
OUTPUT Process Results |
· System performance reports · Operations logs · Maintenance records · Updated operations and maintenance procedures · Identified defects and recommended enhancements · Record of changes and upgrades |
Now that the ITS system is up and running, it enters a “steady state” period which lasts until the system is retired or replaced. The operations and maintenance personnel have all been trained on the system and are ready to perform their duties. During this period, operators, maintainers, and users of the system may identify system issues, suggest enhancements, or identify potential efficiencies. New releases of hardware and software will be installed and routine maintenance will be performed. Approved changes and upgrades are incorporated into the system baseline using the systems engineering process, as shown in Figure 23. Operations and maintenance personnel might also identify process changes that may streamline operations or maintenance activities. All changes to the processes should be documented.
Figure 23: Changes/Upgrades Performed Using Systems Engineering
(Source: FHWA)
The operation process involves the collection of data to support continuous or periodic retesting of the system against the system requirements (System Verification) and against the needs (System Validation) to confirm that the system continues to operate as expected and to have the impact on the environment as expected. If at any time the system fails to meet all system requirements or all needs at the level it did during system verification and system validation, then the system should be fixed or adjusted, or an understanding developed as to what has changed to cause the failed (or partially failed) verification and/or validation (see next section on system Maintenance Process).
If staff operating or maintaining the system changes during operations, then the operation or maintenance training used during the transition process may be reused to get the new staff up to speed on the system operation or maintenance processes.
The risks to be managed are that the system fails to work as required, or that the expected impact on the environment in which the system is operating has changed in some way.
Operations and maintenance do not contain major milestones, although any changes incorporated certainly will, since they will follow the systems engineering process. Therefore, the key activities below are performed periodically, at a pre-determined interval unless a change is considered severe and affects system performance dramatically.
Conduct Operations and Maintenance Plan reviews
Operations and maintenance personnel and the system sponsor should all be in agreement on the level of support to be provided. This could include the staffing profile, frequency of technology refreshes (e.g., how often the software or hardware are upgraded to a new release), performance monitoring and reporting, processes for handling identified issues, level of support provided to the end-user, and so forth.
Establish and maintain all operations and maintenance procedures
Although the processes to be used for identifying, tracking, resolving, recording, and providing feedback on all system issues will have been established during the Initial Deployment step, specific detailed procedures will be further developed and maintained as efficiencies are identified. All personnel will be trained on the procedures and are responsible for their use.
Provide user support
End users of your system, whether they are traffic management center operators or a person whose farecard is not working in the new farecard reader, need to be able to contact someone for user support. This support could be handled by a formal call center or perhaps only a person who performs the task during spare time via e-mail, depending on the type and complexity of the system to be supported. Either way, the user support personnel should be properly trained, should document all calls from initiation through final resolution, and should have access to system experts if needed. These user support personnel should also provide periodic updates on user inquiries and resolutions.
A trouble ticket system or database that holds
information about all user support inquiries can help you to review the types
of calls that were received and to notice trends. If there seems to be a
recurring problem or confusion about some aspect of the system, it could mean
that a system modification should be considered.
Collect system operational data
During earlier phases in the system life cycle, you will have determined how to collect system performance metrics and will have used the performance data to validate the system. During operations, you should collect sufficient performance data to help you determine how well the system is operating over time. For example, in a transit management center, the on-time arrival performance data might be collected from the AVL software. If you are providing a website that displays incident and speed information, a positive response from a user who is asked whether the information was “helpful and accurate” could be collected. Feedback from operators and travelers will provide a measure of customer satisfaction. In-process reviews can be held periodically to review collected metrics, assess system performance, and identify potential system improvements. Some of the outputs that can be created with system operational data are:
• System performance reports both from any installed automated performance monitors and from user support calls received.
• Operations logs identifying the various operations actions undertaken
• The current system configuration, including hardware, software, and operational information.
• A complete record of all system changes performed with version information
Change or upgrade the system
The system will evolve over its lifetime. This could be as a result of issues reported by the users, system improvements identified from the review of operational data, or upgrades to the system. If you decided to deploy only part of the system during the Initial Deployment step, this is when you’ll incrementally add the rest of the system – whether it’s additional functionality or equipment at additional sites (e.g., additional CCTV deployment).
All proposed changes will be prioritized, and will require careful cost estimates, schedules, planning, testing and coordination with operations and maintenance prior to installation. Each approved change will require a new system release level and should be coordinated between the operations and maintenance and development teams.
Each potential change to the system
should be assessed by the affected stakeholders and the project sponsor to
determine whether or not it should be incorporated. You should clearly
understand and document the effect each change will have on other parts of the
system, on the operation of the system as a whole, and on the maintenance of
the system before approving the change. If you make this assessment early on by
following the systems engineering process for the change, you will not discover
a problem months later in the lab when schedule and budget impact is
significantly higher.
You should use the systems engineering process, from requirements through design and verification and installation to add any approved change to the system. Approved changes are typically aggregated into builds or releases, although you may want to introduce particularly complex changes individually.
Each build or release should be
subjected to thorough verification testing prior to installation. There are many
stories of “changes that affected only a few lines of code” that ultimately
resulted in operational failure. Regression tests are also important that
verify that a seemingly minor change in one part of the system didn’t have an
unexpected effect on another part of the system. Statements like “I didn’t
change that area so there is no need to test it.” should be a red flag.
In many cases, the development and
test lab that was available during the initial system development may not be
available once the system has been deployed. (It might even be the system that
was deployed!). Therefore, it’s common to establish a test environment for the
Operations and maintenance to test software product upgrades or minor fixes
without interfering with the current operational system.
Some of the outputs that can be created as part of the system upgrades are:
• Updated operations and maintenance procedures
• Identified defects and recommended enhancements
• Record of changes and upgrades
Maintain configuration control of the system
The deployed system is under configuration control, so every time the system changes, even if only a minor software patch was added, the system baseline must be updated. This means that all documentation, databases, and any other operational data must also be updated.
This is one area where state of the practice lags a bit in ITS. It is common for agencies to require good configuration management practices by their contractors during system development, but then lose configuration control after the system is delivered. For example, if you want to know the configuration of a field controller at a particular location, you will have to take a trip to the field and have a look inside the cabinet at many agencies.
Provide maintenance activity support
A fully functional system should be available for use at all times except for minimal prescheduled maintenance periods during off-hours. Maintenance records on all equipment should be documented. Sufficient equipment, materials, supplies, and spares should be in place, inventoried, and working properly. The suggested quantities for each of these items should be included in the maintenance plan, prior to transitioning to full operational status.
Consider using a database tool or a
similar property management application to help you keep track of all
equipment, together with maintenance records, date due for next maintenance
activity, and so forth. Check it weekly and schedule the maintenance required.
A key output of this activity is are the Maintenance record.
Operations & maintenance are necessary for all systems of any size or complexity. After the ITS system is built, it is made operational and maintained in operational condition for as long as is needed. However, some systems, such as traffic signals, operate autonomously with little routine human input. They need only initial configuration and periodic review and fine-tuning of the settings. Others, such as a closed-circuit television system, require hands-on involvement by a human operator as part of normal operation. But a traffic signal system may involve more intensive maintenance than a CCTV system.
The Operations & Maintenance Plan and associated documents, such as manuals, operating procedures, and system configuration records, should record all the information needed for employees to keep the system operating effectively and for managers to plan for future resource needs. Information provided should include what is needed for day-to-day activities, and also what is needed to plan for occasional activities, such as periodic preventive maintenance and system upgrades. The Concept of Operations, System Requirements, and design documents should be consulted as a checklist of all the system elements and operational aspects that may need coverage in operations & maintenance documentation.
The FHWA Regulation requires that the identification of procedures and resources necessary for operations & maintenance of the system be determined in the systems engineering analysis for ITS projects funded with Federal money from the Highway Trust Fund, including the Mass Transit Account.
Table 11 shows how routine operations records trace back to system requirements relevant to system operations.
Table 11: Operations Traceability
|
Traceable Artifacts |
Backward Traceability To: |
Forward Traceability To: |
|---|---|---|
|
Operations Records (Status of each operations activity.) |
System operation requirements |
N/A |
|
Maintenance Records (Status of each maintenance activity and status of each repair activity.) |
System maintenance requirements |
N/A |
The following checklist can help answer the question “Are all the bases covered?” once the activities above have been planned or performed. The checklist is not sufficient by itself.
R Is management support in place for on-going operations & maintenance (O&M)?
R Has funding for O&M been identified?
R Has an O&M Plan been developed and approved?
R Were all key stakeholders involved in development of the O&M Plan?
R Are resources and training in place for system start-up?
R Are established procedures for continually monitoring the effectiveness of operations & maintenance developed and approved?
R Is there a plan for long term upgrades?
| Related: | |
|
