Systems Engineering Guidebook for ITS - Example Project 3 - Implementing a New Central Management System

4.11.3 Example Project 3 - Implementing a New Central Management System

[Please note that the solution given here is for this example only. Other viable solutions may be possible and each must be evaluated for a given project.]

This project involves replacing an obsolete traffic signal management system with a new system. This system uses computers located at City Hall to provide remote monitoring and control of traffic signals. The existing system is no longer supported by the manufacturer. It is unreliable and not maintainable. It lacks the functionality needed and available in more modern systems. A needs & feasibility study identified needs, high-level requirements, investigated the capabilities, and costs of available off-the-shelf traffic signal management systems. It concluded that an off-the-shelf system using existing communications infrastructure will suffice. However, the existing signal controllers [not cabinets], central computers, and software will need to be replaced. The estimated project cost is $1,500,000, exclusive of on-going operation and maintenance costs. There is no immediate need for center-to-center interaction between this system and other systems. The stakeholders desire is to exchange data in the future.

This is a relatively straight-forward project that requires a low to moderate level of systems engineering. The absence of new software development, use of COTS components, re-use of existing communications infrastructure, and absence of integration with other systems… all reduce risk and complexity. On the other hand, selection of the optimum system, ensuring the new system operates effectively, achieving a smooth transition from the old system to the new, ensuring operations & maintenance personnel are adequately trained, and having the project completed within budget and schedule will require careful project management [including appropriate systems engineering].

Process Step	Estimated Level of Effort	Check list of supporting activities	Check list of issues	Check list of risks	Examples
Feasibility	Medium 2-5 pages	R Products survey R Identification of alternative approaches R High-level trade study R Stakeholder involvement [personnel from management, operations, maintenance] R Risk management	R Documentation and analysis of: R Needs to be addressed R Possible solution concepts R Estimated cost and benefit R Feasibility with off-the-shelf systems R Project risks R Compatibility with regional ITS architecture R Technical metrics and performance measures	R Picking a point solution without considering the business case or cost benefit of alternatives. R Proposing a solution that is too costly R Incompatible components	Definition of the need: “Provide a traffic signal management system that is reliable, maintainable, and provides the needed functionality”. Source of quote Feasibility: Do available off-the-shelf products address the need? How much of the existing equipment and infrastructure will need to be replaced or upgraded? Is there an affordable solution? Trade study and cost benefit: Evaluate alternative approaches, such as retaining existing computers, controllers, cabinets, and communications infrastructure versus replacing some or all of these. Consider alternative communications protocols, their impact on initial and future product choices, communications infrastructure requirements, and options. Stakeholder issues: Consider performance measurement, needs of management, monitoring, control features needed by operations personnel, and self-diagnostic features needed by maintenance personnel. Risk management: Ask product vendors for input and cost estimates to ensure proposed solution is feasible and affordable Base analysis on mature, proven products Forego requirements that would require modification to off-the-shelf software or hardware Give preference to flexible, standards-based solutions
Planning	Medium 3-5 pages Systems Engineering Management Plan	R Describe the work tasks including project management R Identify project execution team, its organization, and the role of each member R Identify any consultant, system integrator, or vendor contracts needed R Document estimated cost and funding sources R Prepare a project time schedule R Identify needed Systems Engineering Plans and their outlines	R Availability and expertise of in-house staff R Effort and time required to get consultants on board R Need for independent verification [acceptance testing] R Allowance for contingencies in budget and schedule R Project management techniques and tools to be used R Consider need for on-going maintenance contract with vendor	R Loss of control of the project deliverable, schedule, and budget R Missing critical activities R Personnel changes	The identified systems engineering plans might include: Deployment Plan Verification and Validation Plans Project Plan Operations & Maintenance Plan Configuration Management Plan Risk Management Plan
Concept of Operations and Validation Plan	Low 1-2 pages Traffic signal management systems are well understood and do not need an elaborate concept of operations or Validation Plan	R Elicitation R Stakeholder involvement R Risk management R Trade studies R Technical reviews	R Description of the way the system will operate and be maintained R Identification of the project level stakeholders e.g. R Maintenance R Operators R Managers R IT department R Definition of user needs at the project level R Agency’s normal operations & maintenance standards R Project goals and measures of effectiveness [for validation]	R Lack of understanding on: R How the system will be operated or maintained R Scope of the project R What functionality is available in off-the-shelf products	How the system will operate: Central software will continuously monitor the operation of traffic signals, reporting current status, traffic flow data, and alarms. The system automatically synchronizes the clocks in signal controllers and commands controllers to change timing patterns when appropriate. Operators periodically check status, update signal timings, respond to alarms, use collected data in various analyses, add new signals to the system, and use the system to temporarily adjust signal timings during incidents. Measures of effectiveness for validation: Traffic signal equipment failures are reliably detected and appropriate personnel notified in a timely manner Data collected by the system are successfully used for traffic analysis and signal timing refinement Adjusted signal timings are downloaded reliably when needed The system is used to temporarily adjust signal timings during incidents. Controller clocks are kept synchronized System users give favorable reports as to the ease of use and effectiveness of the system The system has a low failure rate and does not require an unreasonable amount of maintenance The number of citizen complaints that could be avoided by an effective system is reduced
Development of System Level Requirements and Verification Plans	Low - Medium 2-4 pages Requirements and 2-4 page Verification Plan	R Stakeholder involvement R Elicitation R Technical reviews R Trade studies R Risk management R Configuration management R Traceability	R Identification of system requirements to support the identified needs R What will be used as the basis for accepting the installed system? R New risks that may be uncovered R Are all the needs addressed and are each need addressed completely? R What will be needed to support operations & maintenance? R Project cost update	R Not having a basis to accept the system when completed R Not completely defining what the system is to do R Scope creep R Expectations not met R Project cost R Losing control and visibility of the development R Requirements not validated by stakeholders	Definition of what the system is to do to support the identified needs. “The traffic signal system shall automatically synchronize controller clocks at a user-selectable time of day.” “The system shall allow users to upload and store controller data sets.” “The system’s central software shall operate on personal computers using the Windows operating system.” “The system shall provide three workstations.”. What will be used for the basis of verification and acceptance of the system? Verification Plan would include, for example: Configure the server clock to update the time in the near future and check that the test controller’s clock changes to match the server’s clock at that time Upload a designated controller’s data set, store the data, restart the database server, check that the stored data are available and match that in the controller What will be needed to support operations & maintenance? Users and maintenance documentation shall be provided. System configuration documentation shall be provided
System design	Low - medium 5-8 pages Design Document including map and diagrams	R Stakeholder involvement, R Trade studies R Risk management R Configuration management R Technical reviews R Procurement	R Evaluate alternative off-the-shelf systems by comparing against requirements and considering costs R Procure the preferred system R Work with supplier to prepare system design R Project costs and risks R Refine Verification Plan	R Not deployable R Not maintainable R Inflexible R Lack of standards R Project costs	Examples of design elements: Including any cabinet wiring changes, controller options, communication protocol choice, computer furniture, graphics style. Map showing location of signals to be integrated in the new system and communication infrastructure used. Any cabinet wiring modifications Controller firmware version to be installed Process for converting and transferring existing controller data sets to the new controllers Any new racks and furniture needed at central Configuration of computers Graphics style and source of base drawings Naming conventions Definition of signal groupings Cutover Plan Training Plan Project costs Revised cost estimate based on final system design
Development of Component Level Design	No detailed component-level design needed since all system components are off-the-shelf.
Hardware and software development	Not needed, since all components are off-the-shelf
Unit verification	Defined by the Deployment Plan and Verification Plan	R Technical reviews R Configuration management R Risk management	R Inspect and test the units of software and hardware R Traceability to detailed design R Complete unit functionality	R Propagating defects to a higher level R Inability to verify units	Inspect and test the units of software and hardware Computers and installed software – before any signals are connected Controllers and installed firmware – stand alone bench tests
Unit integration	Defined by the Deployment Plan	R Technical review – verification readiness review R Configuration management R Risk management	R Integrate units of software into sub-systems R Develop sub-system verification procedures	R Interfaces are not compatible R Propagating defects to a higher level	Integrate components into sub-systems Prepare and install a test controller in a bench cabinet. Connect the bench controller in a cabinet to the communications server Install software and data sets in all controllers, ready for installation
Sub-system verification	Defined by the Verification Plan and Verification Procedures	R Technical review – verification readiness review R Configuration management R Risk management	R Verification of sub-systems for functionality R Make ready for the next level of integration R Update user documentation	R Interfaces are not compatible R Sub-system functions not complete R Not meeting performance R Propagating defects to a higher level	Verification of sub-systems for functionality Verify that the central software can successfully communicate with a test controller on the bench Test system functionality with the bench controller connected
Sub-system integration	Defined by the Deployment Plan	R Technical review R Verification readiness review R Configuration management R Risk management	R Integrate sub-systems together into the final system configuration R Update user documentation R Update Operations & Maintenance Plans R Initial deployment and transition into Operations Plan update R System verification procedures	R Operating agency staff not ready for operations & maintenance R Final configuration is not appropriate R Documentation for users is not ready R Propagating defects to a higher level	Integrate sub-systems into the final system’s configuration Make any needed modifications to cabinets in the field. Install new controllers in the field. Complete installation of computers and other central equipment. Connect field controllers to the central communications server. Complete central software configuration
System verification	Defined by the Verification Plan	R Stakeholder involvement R Technical reviews R Verification readiness reviews R Configuration management R Risk management	R Verify that the system meets all requirements R All documentation is updated and ready for users R Complete system functionality	R System not fully implemented R System does not meet requirements R System does not meet the needs of the user	System passes all acceptance tests. Perform system-level acceptance tests in accordance with the Verification Plan All documentation is updated and ready for users All user training, maintenance, and user manuals are completed. The system configuration is fully documented
Deployment	Since this is a replacement system, deployment has already occurred by this stage.	R	R	R New system cannot be co-installed with old system R New system cutover has the ability to fall back to the old legacy system if problems occur
Validation	Defined by SEMP Validation Plan	R Stakeholder involvement	R Evaluate system effectiveness	R Not meeting the expectations of the stakeholders R Not meeting the needs as specified in Concept of Operations	System evaluation Does the system provide the benefits expected? Are users able to use it effectively? Are field equipment faults reported reliably and quickly? Is it reliable and easy to maintain?
Operations & Maintenance	Defined by the Operations & Maintenance Plan	R Stakeholder involvement R Configuration management	R On-going maintenance costs R On-call service contracts with vendors R IT support for servers and remote access	R Lack of maintenance R Lack of vendor support	On-going operation and maintenance. Ensure operations staff are available and using the system as needed Arrange vendor support contracts if needed, after warranty period Provide operation & maintenance training for new employees Maintain spare parts inventory Keep system configuration documentation up to date Track system shortcomings and additional needs Plan changes & upgrades when needed.
Changes & upgrades	Defined by the new project SEMP	R Stakeholder involvement R Configuration management	R System not performing needed functions R System becoming difficult to maintain.	R Need for new software development R Locked into a specific vendor	Examples of reasons to change or upgrade Equipment or software may become obsolete May need to add a center-to-center connection May need to add cameras or signs

Process Step

Estimated
Level of Effort

Check list of supporting activities

Check list of issues

Check list of risks

Examples

Feasibility

Medium

2-5 pages

R Products survey

R Identification of alternative approaches

R High-level trade study

R Stakeholder involvement [personnel from management, operations, maintenance]

R Risk management

R Documentation and analysis of:

R Needs to be addressed

R Possible solution concepts

R Estimated cost and benefit

R Feasibility with off-the-shelf systems

R Project risks

R Compatibility with regional ITS architecture

R Technical metrics and performance measures

R Picking a point solution without considering the business case or cost benefit of alternatives.

R Proposing a solution that is too costly

R Incompatible components

Definition of the need:

“Provide a traffic signal management system that is reliable, maintainable, and provides the needed functionality”. Source of quote

Feasibility:

Do available off-the-shelf products address the need?

How much of the existing equipment and infrastructure will need to be replaced or upgraded?

Is there an affordable solution?

Trade study and cost benefit:

Evaluate alternative approaches, such as retaining existing computers, controllers, cabinets, and communications infrastructure versus replacing some or all of these. Consider alternative communications protocols, their impact on initial and future product choices, communications infrastructure requirements, and options.

Stakeholder issues:

Consider performance measurement, needs of management, monitoring, control features needed by operations personnel, and self-diagnostic features needed by maintenance personnel.

Risk management:

Ask product vendors for input and cost estimates to ensure proposed solution is feasible and affordable

Base analysis on mature, proven products

Forego requirements that would require modification to off-the-shelf software or hardware

Give preference to flexible, standards-based solutions

Planning

Medium

3-5 pages

Systems Engineering Management Plan

R Describe the work tasks including project management

R Identify project execution team, its organization, and the role of each member

R Identify any consultant, system integrator, or vendor contracts needed

R Document estimated cost and funding sources

R Prepare a project time schedule

R Identify needed Systems Engineering Plans and their outlines

R Availability and expertise of in-house staff

R Effort and time required to get consultants on board

R Need for independent verification [acceptance testing]

R Allowance for contingencies in budget and schedule

R Project management techniques and tools to be used

R Consider need for on-going maintenance contract with vendor

R Loss of control of the project deliverable, schedule, and budget

R Missing critical activities

R Personnel changes

The identified systems engineering plans might include:

Deployment Plan

Verification and Validation Plans

Project Plan

Operations & Maintenance Plan

Configuration Management Plan

Risk Management Plan

Concept of Operations and Validation Plan

Low

1-2 pages

Traffic signal management systems are well understood and do not need an elaborate concept of operations or Validation Plan

R Elicitation

R Stakeholder involvement

R Risk management

R Trade studies

R Technical reviews

R Description of the way the system will operate and be maintained

R Identification of the project level stakeholders e.g.

R Maintenance

R Operators

R Managers

R IT department

R Definition of user needs at the project level

R Agency’s normal operations & maintenance standards

R Project goals and measures of effectiveness [for validation]

R Lack of understanding on:

R How the system will be operated or maintained

R Scope of the project

R What functionality is available in off-the-shelf products

How the system will operate:

Central software will continuously monitor the operation of traffic signals, reporting current status, traffic flow data, and alarms. The system automatically synchronizes the clocks in signal controllers and commands controllers to change timing patterns when appropriate. Operators periodically check status, update signal timings, respond to alarms, use collected data in various analyses, add new signals to the system, and use the system to temporarily adjust signal timings during incidents.

Measures of effectiveness for validation:

Traffic signal equipment failures are reliably detected and appropriate personnel notified in a timely manner

Data collected by the system are successfully used for traffic analysis and signal timing refinement

Adjusted signal timings are downloaded reliably when needed

The system is used to temporarily adjust signal timings during incidents.

Controller clocks are kept synchronized

System users give favorable reports as to the ease of use and effectiveness of the system

The system has a low failure rate and does not require an unreasonable amount of maintenance

The number of citizen complaints that could be avoided by an effective system is reduced

Development of System Level Requirements and Verification Plans

Low - Medium

2-4 pages Requirements and 2-4 page Verification Plan

R Stakeholder involvement

R Elicitation

R Technical reviews

R Trade studies

R Risk management

R Configuration management

R Traceability

R Identification of system requirements to support the identified needs

R What will be used as the basis for accepting the installed system?

R New risks that may be uncovered

R Are all the needs addressed and are each need addressed completely?

R What will be needed to support operations & maintenance?

R Project cost update

R Not having a basis to accept the system when completed

R Not completely defining what the system is to do

R Scope creep

R Expectations not met

R Project cost

R Losing control and visibility of the development

R Requirements not validated by stakeholders

Definition of what the system is to do to support the identified needs.

“The traffic signal system shall automatically synchronize controller clocks at a user-selectable time of day.”

“The system shall allow users to upload and store controller data sets.”

“The system’s central software shall operate on personal computers using the Windows operating system.”

“The system shall provide three workstations.”.

What will be used for the basis of verification and acceptance of the system?

Verification Plan would include, for example:

Configure the server clock to update the time in the near future and check that the test controller’s clock changes to match the server’s clock at that time

Upload a designated controller’s data set, store the data, restart the database server, check that the stored data are available and match that in the controller

What will be needed to support operations & maintenance?

Users and maintenance documentation shall be provided. System configuration documentation shall be provided

System design

Low - medium

5-8 pages Design Document including map and diagrams

R Stakeholder involvement,

R Trade studies

R Risk management

R Configuration management

R Technical reviews

R Procurement

R Evaluate alternative off-the-shelf systems by comparing against requirements and considering costs

R Procure the preferred system

R Work with supplier to prepare system design

R Project costs and risks

R Refine Verification Plan

R Not deployable

R Not maintainable

R Inflexible

R Lack of standards

R Project costs

Examples of design elements:

Including any cabinet wiring changes, controller options, communication protocol choice, computer furniture, graphics style.

Map showing location of signals to be integrated in the new system and communication infrastructure used.

Any cabinet wiring modifications

Controller firmware version to be installed

Process for converting and transferring existing controller data sets to the new controllers

Any new racks and furniture needed at central

Configuration of computers

Graphics style and source of base drawings

Naming conventions

Definition of signal groupings

Cutover Plan

Training Plan

Project costs

Revised cost estimate based on final system design

Development of Component Level Design

No detailed component-level design needed since all system components are off-the-shelf.

Hardware and software development

Not needed, since all components are off-the-shelf

Unit verification

Defined by the Deployment Plan and Verification Plan

R Technical reviews

R Configuration management

R Risk management

R Inspect and test the units of software and hardware

R Traceability to detailed design

R Complete unit functionality

R Propagating defects to a higher level

R Inability to verify units

Inspect and test the units of software and hardware

Computers and installed software – before any signals are connected

Controllers and installed firmware – stand alone bench tests

Unit integration

Defined by the Deployment Plan

R Technical review – verification readiness review

R Configuration management

R Risk management

R Integrate units of software into sub-systems

R Develop sub-system verification procedures

R Interfaces are not compatible

R Propagating defects to a higher level

Integrate components into sub-systems

Prepare and install a test controller in a bench cabinet.

Connect the bench controller in a cabinet to the communications server

Install software and data sets in all controllers, ready for installation

Sub-system verification

Defined by the Verification Plan and Verification Procedures

R Technical review – verification readiness review

R Configuration management

R Risk management

R Verification of sub-systems for functionality

R Make ready for the next level of integration

R Update user documentation

R Interfaces are not compatible

R Sub-system functions not complete

R Not meeting performance

R Propagating defects to a higher level

Verification of sub-systems for functionality

Verify that the central software can successfully communicate with a test controller on the bench

Test system functionality with the bench controller connected

Sub-system integration

Defined by the Deployment Plan

R Technical review

R Verification readiness review

R Configuration management

R Risk management

R Integrate sub-systems together into the final system configuration

R Update user documentation

R Update Operations & Maintenance Plans

R Initial deployment and transition into Operations Plan update

R System verification procedures

R Operating agency staff not ready for operations & maintenance

R Final configuration is not appropriate

R Documentation for users is not ready

R Propagating defects to a higher level

Integrate sub-systems into the final system’s configuration

Make any needed modifications to cabinets in the field. Install new controllers in the field. Complete installation of computers and other central equipment. Connect field controllers to the central communications server. Complete central software configuration

System verification

Defined by the Verification Plan

R Stakeholder involvement

R Technical reviews

R Verification readiness reviews

R Configuration management

R Risk management

R Verify that the system meets all requirements

R All documentation is updated and ready for users

R Complete system functionality

R System not fully implemented

R System does not meet requirements

R System does not meet the needs of the user

System passes all acceptance tests.

Perform system-level acceptance tests in accordance with the Verification Plan

All documentation is updated and ready for users

All user training, maintenance, and user manuals are completed. The system configuration is fully documented

Deployment

Since this is a replacement system, deployment has already occurred by this stage.

R New system cannot be co-installed with old system

R New system cutover has the ability to fall back to the old legacy system if problems occur

Validation

Defined by SEMP Validation Plan

R Stakeholder involvement

R Evaluate system effectiveness

R Not meeting the expectations of the stakeholders

R Not meeting the needs as specified in Concept of Operations

System evaluation

Does the system provide the benefits expected?

Are users able to use it effectively?

Are field equipment faults reported reliably and quickly?

Is it reliable and easy to maintain?

Operations & Maintenance

Defined by the Operations & Maintenance Plan

R Stakeholder involvement

R Configuration management

R On-going maintenance costs

R On-call service contracts with vendors

R IT support for servers and remote access

R Lack of maintenance

R Lack of vendor support

On-going operation and maintenance.

Ensure operations staff are available and using the system as needed

Arrange vendor support contracts if needed, after warranty period

Provide operation & maintenance training for new employees

Maintain spare parts inventory

Keep system configuration documentation up to date

Track system shortcomings and additional needs

Plan changes & upgrades when needed.

Changes & upgrades

Defined by the new project SEMP

R Stakeholder involvement

R Configuration management

R System not performing needed functions

R System becoming difficult to maintain.

R Need for new software development

R Locked into a specific vendor

Examples of reasons to change or upgrade

Equipment or software may become obsolete

May need to add a center-to-center connection

May need to add cameras or signs