Improving Transportation Systems Management and Operations – Capability Maturity Model Workshop White Paper – Systems and Technology

3. State of the Practice for the Systems and Technology Dimension

3.1 The Systems and Technology Dimension

Systems and Technology reflects the systems engineering requirements of TSM&O, including systems architecture, concepts of operation and interoperability, standardization, and documentation processes. It does not focus on the actual technology infrastructure, but rather focuses on key processes and aspects of technology procurement, integration, operations and technology planning. The capability-level criteria used in the self-assessments for this dimension are shown in Table 3.1.

Table 3.1 Self-Assessment Workshop Levels of Capability Maturity for Systems and Technology

	Systems and Technology Criteria for Level Achievement
Capability Level 1	Ad hoc approaches to system implementation without consideration of systems engineering and appropriate procurement processes
Capability Level 2	Regional or statewide ConOps and architectures developed and documented with costs included; appropriate procurement process employed
Capability Level 3	Systems and technology standardized and integrated on a regional or statewide basis (including arterial focus) with other related processes and training as appropriate
Capability Level 4	Architectures and technology routinely upgraded to improve performance; systems integration/interoperability maintained on continuing basis

Among the 23 Workshops, the average self-assessed capability for Systems and Technology is 2.02 – with seven sites at Level 1 and four sites at Level 3 or 4. Among dimensions selected for inclusion in Implementation Plans, Systems and Technology appeared in 14 plans. Figure 3.1 indicates how the Systems and Technology dimension was assessed relative to the other dimensions.

Figure 3.1 Graph. Systems and Technology Compared to Other Dimensions of Capability

(Source: Cambridge Systematics, Inc. and Parsons Brinckerhoff.)

The discussion of the state of the practice regarding the Systems and Technology dimension below is divided into key elements based on the approach used in the AASHTO Guide to Transportation Systems Management and Operations:

• Regional architectures;
• Project systems engineering/testing and validation; and
• Standards/interoperability.

The material that follows discusses the current state of play in each key element.

3.2 Regional Architectures

• Regional and statewide ITS architecture documents and use. A critical requirement for continuous improvement of TSM&O is a rigorous and systematic systems engineering approach. Clear consensus-based concepts of operations shared by all key participants are essential to identifying appropriate roles and relationships for each TSM&O application. The related ITS systems architecture provides a common framework for planning, defining, and integrating ITS deployments. All states/regions in the workshops have some kind of an ITS architecture (either statewide or regional) consistent with Federal standards and the national ITS architecture; however, the use of the architecture for project planning or procurement varied widely. In many instances, some workshop participants (not directly involved with technology or TMC operations) were not involved first-hand with the ITS architecture development and were not familiar with how such a tool could be used. In some cases, regional ITS architectures were developed by MPOs; while State DOTs were partners, they were not the “owners” of the regional ITS architecture. Most states/regions have developed systems architectures with extensive Federal guidance, and the modest pace of deploying new applications has made updates less compelling. The deployment of new applications and technologies, however, such as active traffic management and integrated corridor management, highlights the need for updates. Many participants did recognize the need to update regional or statewide architecture. At the same time few State DOTs have the in-house capacity for systems engineering. ITS is added onto capital projects piecemeal without a rigorous systems approach, often exploiting an opportunity rather than fulfilling a need. The value of a strong architecture was recognized and revising or updating the architecture was one of the action items mentioned most often for this dimension in the workshops.
  State DOT technical staff – especially at the regional or district level – have a well-developed understanding of systems and technology issues, in part because of Federal support but also because of professional interest in technology.

3.3 Project Systems Engineering/Testing and Validation

• Improve awareness and training. The systems engineering process was generally employed by DOTs and MPOs for ITS projects, following the guidance provided in the National Architecture program and requirements of using the systems engineering process, in place since 1998. When the National Architecture program was initially rolled out by the U.S. DOT, there were many training opportunities afforded to the State DOTs that were specific to systems engineering processes. It was often noted in the workshops that system engineering training options once offered by the U.S. DOT would be helpful if reinstituted (see the Organization and Staffing Dimension). A catalogue of best practices associated with system engineering processes would also be helpful in increasing the awareness and use of the systems engineering process, thereby advancing operations. Although training programs specific to systems engineering may still exist, an increased awareness of these training opportunities would benefit many State DOT programs.
  As expansion occurs and new technologies enter TMC, lack of staff development has become a serious challenge. Some of these challenges are being met by an increased level of outsourcing of technical responsibilities to the private sector, especially within TMC (see the Collaboration and Organization and Staffing Dimensions). In addition to the systems engineering training requested, general training on technology aspects of ITS elements and internal TMC functions are needed to advance TSM&O programs. DOTs have rotational training programs that often do not include a slot for a TMC post. Developing ITS training programs and getting TMC in the rotation were noted by several locations as a way to increase staffing capabilities and overall agency knowledge of systems and technologies.
• Procurement challenges. Often times States noted that purchasing ITS hardware and software introduced great challenges due to the way that State agencies procure IT equipment. The internal process can take too long resulting in the purchase of outdated products and requires several levels of approvals; when requirements are not clearly defined, unsuitable items are purchased. There are additional challenges with agency enterprise requirements (such as low bid, security requirements, etc.), which might not align with specific ITS or TSM&O requirements. Several States mentioned concerns about their ability to procure the latest equipment when ITS is buried in large “new construction” projects and contractors are looking for the least expensive acceptable product that meets whatever requirements have been included in the procurement package.
  One way to potentially streamline procuring ITS equipment would be to develop qualified product lists (see approved vendor bullet below), although higher costs might become an issue when too few vendors qualify on the list for certain products. FHWA funding structures can make it difficult for States and regions to update their procurement processes. Developing relationships with information technology (IT) groups and an understanding of IT procurement processes as they relate to TSM&O would also be useful from two perspectives: helping the TSM&O group understand the IT processes and informing IT groups about the unique aspects of procuring TSM&O technologies. The need to improve the way ITS elements are procured was the most noted action item resulting from the workshops.
• Outsourcing. Some State DOTs have had success in outsourcing TMC operations (operators and service patrols). This has been especially helpful in situations when there have been internal staffing and budget restrictions. By outsourcing TMC staffing, the DOT also is removed from the cycle of hiring and training of operators and gains more flexibility for increasing or decreasing staff levels. Outsourcing staff at the TMCs was generally viewed as a successful practice when performance criteria were tied to payment conditions (see Organization and Staffing Dimension).
• Keeping pace. There were quite a few workshop locations that pointed out the challenge of keeping pace with rapidly evolving technology and the difficulties this creates, such as obsolescence of deployed equipment, outdated specifications, legacy equipment’s incompatibility with newer equipment, incompatibility with deployed software, and maintenance capabilities. There also were a wide range of issues associated with keeping up with maintenance of equipment, including learning to maintain new technology while maintaining older deployed technology when vendors move on to newer and more advanced equipment.
  Specific maintenance and asset management challenges were mentioned in several places, including difficulty with maintaining equipment and keeping pace with equipment maintenance. Staff and budgets have not kept pace with deployments and several locations outsource their device maintenance duties. Maintenance responsibilities might be split between different groups (i.e., TMC/district maintenance), causing additional coordination challenges.

3.4 Standards/Interoperability

• Interoperability. Working together in a region requires standards that support the interoperability of various systems and facilitation of the interchange of field and central system hardware and software operations. Some State DOTs have made interoperability of systems a priority. Legacy systems can constrain an agency’s future equipment purchasing flexibility or limit expansion options. There is a reluctance to upgrade large legacy systems when they are incompatible with newer equipment. Interoperability is often an issue for systems maintained by various agencies within a region, such as voice and data communications between a DOT and Public Safety Agency (PSA) or transit agency; furthermore, incompatible systems can impact the ability to share data within and across agencies. Data generated by TSM&O devices and analysis can help to support other agency functions if it is available and able to be integrated into those processes. This in turn can help increase agency support and respect for TSM&O. Several workshops identified the need for state police Computer Aided Dispatch (CAD) integration with the regional/statewide TMC.
• Standards. Standards developed for the ITS industry are used to harmonize data communications, database exchanges, and information displays among diverse systems. It is essential that standards be integrated into the system development and acquisition program. Workshop participants noted that it was necessary to update standards regularly to stay on the forefront of quickly evolving technologies, with interoperability as the motivating goal. By reorienting standards away from technical specifics to functional requirements allowed for an improved ability to keep pace with technology and open standards allowed for more flexibility in procurements.
• Documentation. ConOps and project architectures exist for technology projects, but they often lack important information components such as cost elements, performance requirements, and evaluation. When strong documentation exists it paves the way for expansion and solid standardization of processes. Continuing to advance the documentation for technology projects would benefit most all agencies, specifically in the areas of costs and performance measures. Ad hoc approaches to system implementation, with limited documentation, were oftentimes still employed, thereby holding back the success of agencies’ programs. Although an important part of the systems engineering process, a ConOp was not necessarily identified as a required element, except for larger, complex projects or where federal funding requirements necessitated developing one.
• Approved vendor product lists. Agencies find that having qualified product lists facilitates purchasing ITS elements and can reduce the time needed to acquire products. This listing in essence pre-certifies products meeting the requirements and interoperability needs of the system. The challenge of having (and continually maintaining) a good set of specifications for field equipment was cited in several workshops. Even a very good vendor product list becomes problematic if the set of specifications on which it is based does not reflect new products or technologies in the marketplace.
• Arterial Expansion. Agencies had a good grasp on freeway management and each workshop location had deployed freeway management systems in their urban areas. Not as well deployed or integrated into their freeway management systems were arterial signal systems. About half of the workshop locations had incorporated signal systems into the freeway management centers, and many noted an interest in expanding or including arterial signal systems. Workshop action items centered on developing plans and institutionalizing TSM&O freeway and arterial applications and performance guidelines. Other systems expansions were often noted for traveler information, transit coordination, traffic incident management, computer aided dispatch integration, and ramp metering.