December 31, 2008

 

SFpark Logo

 

Configuration Management Plan

 

 

 

 

 

SFMTA LogoDOT Logo

 


Table of Contents

 

Table of Contents. 2

1              Introduction. 3

2              Distributed Ownership. 3

3              Distributed Configuration Management 3

4              Configuration Documentation. 4

5              Change Control 5

6              Hardware Management 7

7              Software Management 7

8              Participant Procedures. 7

8.1        Overview of Procedures. 7

8.2        Configuration Management Scope. 8

8.3        Configuration Documentation. 8

8.4        Configuration Change Request 9

8.5        Configuration Change Review and Approval 10

8.6        Configuration Change Implementation. 11

8.7        Configuration Change Notification. 12

8.8        Configuration Change Documentation. 12


1          Introduction

San Francisco Municipal Transportation Agency (SFMTA) is creating a parking management system that includes individual projects known collectively as SFpark. These SFMTA pilot projects will provide an information exchange network that will be used by SFMTA to manage parking, as well as to provide parking information to Metropolitan Transportation Commission’s 511 and 511.com services. As part of the SFpark pilot projects, SFMTA will enable the real-time sharing of parking availability data. SFpark will also be an opportunity for SFMTA staff to refine the systems and procedures used to operate on- and off-street parking. The pilot projects will also allow SFgo (the SFMTA’s traffic operations group) personnel to provide the public with information about current travel conditions and parking options.

The configuration management plan provides the specifications and processes for recording, and managing changes to, the configuration of hardware, Commercial-off- the- Shelf (COTS) software, and communications facilities that compose the parking management system (PMS). Among other things, it is intended to prevent a situation where one vendor or person may unilaterally make a change that has negative consequences for data collection or system maintenance. It is also intended to prevent situations where a repair or change is needed for the benefit of all, but is made very difficult by inadequate documentation of the current and/or proposed configuration.

 

2          Distributed Ownership

SFpark pilot projects involve a network composed of a variety of field devices (e.g., parking meters, communications hubs, vehicle detectors, variable message signs, and static wayfinding signs), computers, software, and communications links, as well as procedures for its use and maintenance. The SFMTA will own most of the SFpark pilot project components, and others may be independently owned, operated, and maintained by one or more of the involved vendors. To help ensure the success of SFpark, all vendors or participants in the SFpark pilot projects will be required to comply with, and participate in, the processes described in this manual.

 

3          Distributed Configuration Management

Just as ownership of SFpark pilot projects components is distributed among the SFMTA divisions and vendors, so is configuration management. For components owned, each vendor and SFMTA division will retain responsibility for the following key configuration management activities:

·         Maintain comprehensive and accurate configuration records, including updating records after making any change.

·         Consider potential impacts on SFMTA and consult the SFMTA divisions and vendors, when appropriate, before making any configuration change.

·         Inform the SFMTA divisions and vendors of any change.

Each vendor will have its own configuration management procedures used in managing the configuration of the SFpark pilot projects components that it owns or for which is responsible. For the SFMTA pilot projects, configuration management procedures include:

·         Creation and maintenance of configuration records such as drawings or geographical information systems showing the location and connectivity of all components, related or separate tables, and text describing each component and its history and current configuration, documentation of current operation and maintenance procedures, and documentation of current participant cooperation procedures.

·         Change control procedures such as categorization of components and procedures with regard to change control, level of authority needed for change approval for each category, a change control board for at least some categories, and change implementation and notification procedures.

Participants will provide configuration management for all components and procedures affecting SFMTA pilot projects including: field devices providing data, central software managing such devices or processing received data, interfaces to the parking management network, communications equipment and links used, and procedures to be followed by personnel that may affect the operation or maintenance of such components or interactions with SFMTA.

 

4          Configuration Documentation

Participants will maintain accurate records of their resources and procedures used in coordination of the SFpark pilot projects. Such records will be updated whenever any change is approved and made. The following scenarios illustrate why it is important that each participant in each region maintains complete and accurate records of its facilities and procedures:

SFMTA is responsible for maintaining a specific parking management Interface Definition document. This document provides the specific attributes of data elements, messages, protocol, and other aspects of the common (standard) interface across the pilot projects network and each system node. This is the pilot projects side of the interface to each node. The configuration of each node system and the configuration of the COTS interface for a particular node are specific to each node and therefore will be documented by the participant that owns the node system.

 

5          Change Control

In preparing procedures and training personnel, each participant considers the different degrees to which a local change can impact other participants and users and therefore the amount of coordination warranted. The following table is a sample of coordination that is appropriate for local changes involving different degrees of regional impact.

All operations, maintenance, design, and policy personnel that could affect any of the resources used in SFpark pilot projects will be provided with written guidelines and thorough training aimed at making them aware of the potential impacts of local changes on other agencies and of appropriate steps to take if an impact is anticipated. This requirement will not involve significant additional effort or time on the part of participant personnel, just an awareness and consideration of potential impacts, and appropriate, common sense coordination with other agencies when needed. If an employee suspects a planned action may impact the SFpark pilot projects system or specific users, they will raise the issue with their supervisor.

 

Regional Impact

Example Changes

Participant Coordination

None

1.        Change to parking meter rates.

None.

Minor

1.        Upgrade the operating system on a node system server computer.

2.        Change hours of operation.

Notify other entities (SFMTA, vendors) at the time of change if not before.

Potentially Significant

1.        Decommission a communication’s node used as a back-up path for SFpark pilot projects communications.

2.        Decommission a traveler information sign commonly used by other participants.

3.        Replace a broadband Internet link used by SFpark pilot projects with a much slower link.

4.        Change procedures involving interaction with other participants during incidents.

Discuss with the most affected participants prior to making the change. Notify all participants well in advance of making the change. Notify other participants of the actual changes made after successfully completed.

Potentially Major

1.        Add a new node system to SFpark pilot projects.

2.        Remove a system node.

3.        No longer allow parking sensor data to be exported to SFMTA due to lease expiration or company failure

4.        Change the look and feel, or functionality, of the vendor information display.

Formally notify the participants of the proposed change and have it placed on the agenda for at least one meeting of the SFpark pilot projects Technical Advisory Committee. Make a change only after thorough discussion, and attempts at consensus if controversial. Coordinate the changes with other participants. Formally notify participants of the actual changes made after successfully completed.

 

Formal configuration management includes a change control board that reviews and approves proposed changes. The SFMTA Technical Advisory Committee performs that role for the parking management system, but since some SFpark pilot projects components are owned by one participant, only that participant can ultimately decide on changes to that component. Hence the SFMTA Technical Advisory Committee will serve as the change control forum, but does not formally approve changes outside its authority As with all aspects of the pilot projects, the mutual benefits that participating SFMTA departments and agencies derive from their cooperation is the motivation for adhering to the majority, if not consensus, opinion of the Technical Advisory Committee. The chairperson of the SFMTA Technical Advisory Committee will serve as the chairperson of the SFMTA Configuration Control Board.

When a planned change warrants multi-participant discussion, the originating participant (or an appointed representative of multiple members planning a change) will present a briefing document to the SFMTA Configuration Control Board, record the major points of discussion, and the conclusion(s). The originating participant will archive such documentation as a record that others can refer to later if needing to understand the origin or reason for a particular change, or abandonment or alternation of a planned change. Other participants will be kept apprised of the final form of the change, the schedule for its implementation, and confirmation of its implementation once completed. The participant making a change is obligated to coordinate with others, as needed and appropriate, to facilitate their taking any concurrent actions needed to adjust for the change. Configuration documentation is then updated to reflect the change as soon as the change is proven to be successful.

Good configuration management also allows for rolling back to the prior proven (baseline) state in the event that an implemented change causes unforeseen problems. The pilot projects participants therefore will maintain records of the prior state and ensure that implementation procedures allow for roll back if needed.

Each participant will perform periodic reviews of the effectiveness of configuration management documents, procedures, and change experiences. These reviews present an opportunity to address any shortcomings and enhance the effectiveness of configuration management.

 

6          Hardware Management

Hardware Configuration management will likely provide the most significant challenge to the configuration of the SFpark pilot projects system. Variations in hardware components are often difficult to visually detect due to the various hardware and electronic sub assemblies that comprise hardware components.  In the evolving parking management pilot projects, it is particularly important that hardware models, sub assembly replacements, etc. are carefully tracked to insure the integrity of the overall system. Vendors are required to fully disclose all functional and procedural changes made to newer or updated hardware.

 

7          Software Management

Deployment of individual or multiple SFpark pilot projects involves implementation of newly developed software, revised proprietary software and/or Commercial Off The Shelf (COTS) software to provide the required updated interface to each system node and to provide SFMTA the required internal management data and the data for distribution to the travelling public. Effective system performance requires thorough documentation of the software, its initial configuration, and version changes. In the case of developmental software, the contractor must provide those tools needed for building and maintaining the software, requirements documentation, bug tracking, source version management, and other software configuration management functions. SFMTA owns the software product and the supporting documentation and tools.

Each participant is similarly responsible for documentation and tools related to its node system software.

 

8          Participant Procedures

Each SFpark pilot projects participant is responsible for configuration management for hardware and software that are part of the overall parking management system. Each participant will establish procedures for configuration management relative to the components it owns. These procedures are tailored to the circumstances of that office and the types of components it owns.  To the extent that a participant does not already have sound procedures for such configuration management, the following guidelines will assist in their development.

8.1       Overview of Procedures

Documentation of Configuration management procedures will include at a minimum the following:

·         Configuration management scope

·         Configuration documentation

·         Configuration change request

·         Configuration change review and approval

·         Configuration change implementation

·         Configuration change notification

·         Configuration change documentation

To this end they are an aspect of routine employee training, and where necessary, the subject of special training sessions. A regularly conducted review of configuration management procedures will refine them based on feedback as their effectiveness.

8.2       Configuration Management Scope

Configuration management procedures will first identify what components/objects are subject to configuration management. For SFpark pilot projects, this includes:

·         All software;

·         Hardware;

·         Communications facilities involved in the generation, receipt, transmission, or processing of data exchanged or displayed via the traveler information distribution network; and

·         Field devices on which data are exchanged in support of SFpark pilot projects.

The objects involved in SFpark pilot projects will be designated, as this will trigger additional considerations and steps for these components, involving review by other system participants.

Some types of changes to a component could need a high level of change control while other types of changes may only need a lower level change control or no control. Hence, the inventory documentation will indicate which types of change are subject to which levels of change control. Making changes to such recordings of the change control required for each type of change will in itself be subject to change control.

It is not always practical to predetermine the appropriate level of change control for every conceivable type of change that may need to be made. Procedures will state that unless the planned change is clearly in a category that does not require change control or is covered by a prior blanket change approval, then it will be assumed that change approval is needed and will be started by following the procedures for the lowest level of change control. The person to whom the request is referred will then decide if this type of change needs to be elevated to the next level, and so on.

8.3       Configuration Documentation

SFTMA templates and formatting procedures specify the type and format of documentation to be used for components/facilities subject to configuration management. Configuration documentation will include some form of inventory database with fields such as:

·         Component description (including make/model), serial number or other unique identifier, date purchased, current location, current use or purpose served, pointer to another component of which this is a subcomponent, modifications to date.

·         Current status (e.g., awaiting installation, installed but not operational, operational, temporarily failed, stored as spare, etc.).

·         Date of acquisition, date first put into service.

·         Procurement source, procurement method, procurement cost, nature and expiration date of any warranty or maintenance agreement.

·         Identification of personnel with knowledge of this component, identification of any third party maintenance service used.

·         Description of current configuration (or pointer to other documentation containing same), description of last configuration change (or pointer to other documentation containing same).

·         The types of changes subject to each level of change control (e.g., high, medium, low, none) or pointer to other documentation of same, and pointers to further documentation if any (e.g., drawings showing the spatial or logical integration of this component with others, drawings showing details of the component design or configuration, text documents describing the current configuration, users manual, maintenance manual, etc.).

·         History of defects and errors.

Such information may be stored in a geographical information system, relational database, spreadsheet, or any other suitable form as specified by SFMTA. It is good practice to avoid replication of the same information, such as information common to every instance of a particular type of device or software package. This information will be electronically viewable by all system participants.

Most of this information is applicable to both hardware and software.

Procedures include measures for ensuring that the documentation is kept up to date, a new version identifier is assigned each time a document changes, the nature and date of changes is recorded, and conflicting duplicate versions are avoided.

8.4       Configuration Change Request

Procedures will require that no change be made to a component until the proposed change is approved using the procedures applicable to the change control category (e.g., high, medium, low, none) for that type of change. The first step in gaining change approval is making a request for approval. For items in the low level control category, procedures may require only a verbal request to, and approval from, a supervisor or designated person. Medium and high level control categories will require a written request for approval, where that request includes information such as change description, change purpose, change priority (how urgent is it?), procedures to be used to make the change, other changes or actions on which this change is dependent or which depend on this change, proposed time schedule for the change, cost, risks and concerns, risk mitigation measures planned, planned testing prior to making the change, planned testing during and after the change, roll back plan, and any other relevant information. This process is graphically depicted in figure 8-4.1

The configuration control process consists of the following steps and decisions: request changes, evaluate changes, approve or disapporve changes and implement changes.

Figure 8-4-1      Required Configuration Management Process from Initiation to Implementation.

Urgency cannot be an excuse to circumvent the change approval process. However, procedures will allow for urgent temporary changes to be made with a lower level of change control if the temporary change is needed to correct a serious problem and there is insufficient time to complete a higher level of change control even when done as quickly as possible. Such emergency procedures will require either restoration of the former configuration or formal approval of the change, as soon as practical. It is also important that users and maintenance personnel are trained to consider the repercussions of an emergency change on other parking management users. In addition to seeking approval after the fact, it is important to inform all potentially affected parties of the change as soon as practical.

If a certain type of change needs to be made often, such as during routine maintenance, a one-time approval may be sought for all such occurrences rather than repeating the approval process each time.

Some changes may require simultaneous changes to components owned by other participants. Participants must each follow its change approval processes, but attempt to coordinate them and ensure they are jointly reviewed and approved.

8.5       Configuration Change Review and Approval

SFMTA will identify the person to whom a change request will be referred at each level of change control. For example, at the low level, change requests will go to a particular person or position, at the medium level they will need to go to a higher level person within the organization and also be referred to other agencies potentially affected by the change, and at the high level may also be referred to the chair of the SFMTA Technical Advisory Committee. If a particular person is designated to receive change requests, alternates need to be named in case that person is unavailable. SFMTA will maintain a roster of staff personnel authorized to approve changes.

A person receiving a change request will review the request and determine if it needs to be elevated to a higher level of approval and what other people need to review the request prior to making an approval decision. To the maximum extent feasible, the same group of people will review all requests. This staff will comprise the Configuration Control Board (CCB). As possible, Service Level Agreements (SLAs) will be utilized to assist in timetable adherence and create common rules of engagement.

The SFMTA Configuration Control Board is comprised of a team of, at least, three permanent participant members responsible for the configuration control decisions for the SFMTA parking system. The CCB will review and approve or reject all requested changes for hardware, software, documentation and drawings that are under CM control. No changes are allowed to any CM controlled configuration items without the approval of the CCB.

The process to request a change is initiated by a SFMTA Change Request (SFMTA CM FORM 1 see page 11). This completed request along with its supporting documentation will be used to request a change to any data under CM control.

SFMTA does not intend the CCB to be a preliminary investigation tool for problems. In most cases any potential changes to the system will have a recommended resolution prior to the CCB meeting. If a problem does not have a simple resolution that can be defined by the originator, then a staff member will be assigned to lead development of a recommended solution. This resolution manager is required to work with all participants affected by the change and gather their concurrence. Both concurrence and non-concurrence will be brought before the CCB for final approval/disapproval.

Most participants will limit the formal act of approving or rejecting a request to someone within their company, no matter what other participants are involved in the review and decision making process. The SFMTA Technical Advisory committee or other participants acting separately cannot override a decision by the participant owning the component, but the owner must attempt to adhere to the consensus view of all affected participants.

The change review and approval process will result in changes to the proposed work plan (e.g., when the work is to be done, what testing is to be performed, the nature of the change itself, etc.). Those reviewing a proposed change may also request that certain people be notified when the change is about to be made so that they can monitor the system for related problems or inform their operators of the changed condition. The approval notification must clearly indicate what is being approved and any such additional instructions. A simple “approved” or “not approved” response is often not sufficient. Similarly, if a request is for multiple changes, some of those changes may be approved but not others, and the approval notification needs to be very explicit in this regard. Requests containing multiple unrelated changes are not permitted.

Approval to a written request will always be in writing, in addition to any verbal communication. If a request is rejected, an explanation must be provided including, as applicable, any technical explanation.

8.6       Configuration Change Implementation

Procedures require approved changes to be made according to the approved work plan (e.g., nature of the change, time schedule for making the change, testing to be performed, coordination with other, roll back plan, etc.). Even if other participants have not formally requested notification, it is good practice to require those making a change that has been reviewed by other participants to notify them in advance of making the change so they can monitor the system as the change is made or notify their operators of the change and how it may affect them.

Procedures stress the need for thorough testing after a change is made to ensure it has not caused any unforeseen problems. Such testing may involve interaction with operators or maintenance personnel in other agencies.

8.7       Configuration Change Notification

Procedures will require those making an approved change to notify all other participants, as appropriate, once the change is completed. If a change results in unexpected problems or cannot be completed as planned, all parties must be fully briefed on the nature of the problems. Those notified may request a further change or roll back to the former state if they consider the problems warrant so. Unless such further change is in accordance with an already approved roll back plan, it will need to follow the change approval process again. Problems encountered during a change are a learning opportunity for all parties.

8.8       Configuration Change Documentation

Procedures require those making a change to immediately update the facilities inventory and other relevant documentation. It is good practice to require periodic reviews or audits of documentation to ensure it is being kept up to date. Such reviews may involve spot checks or review of the documentation of components known to have recently approved changes.

 

 

8.1.1  SFMTA Change Request Form


SFMTA CHANGE REQUEST

(Attach additional sheets as needed)

SCR NO:

CCB DATE:

SUBMITTED BY:

DATE:

 

SUBJECT:

TYPE CHANGE

SFMTA ONLY

SYSTEM

PRIORITY:

EMERGENCY

URGENT

ROUTINE

CONDITION DESCRIPTION`

PARTICIPANTS/ OFFICES AFFECTED (LIST):

RECOMMENDED SOLUTION:

COORDINATION EFFECTED:

CCB ACTION:

APPROVED

DISAPPROVED

RETURNED FOR ADDITIONAL STUDY/COORDINATION TO:_________________________

CCB MANAGER:

DATE: