Module 2 - A101

A101: Introduction to Acquiring Standards-based ITS Systems

HTML of the Student Supplement

(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)

(Extended Text Description: Large graphic cover page with dark blue background with the title in white letters “A101 Introduction to Acquiring Standards-based ITS Systems.” At the middle left is the “Standards ITS Training” logo with a white box and letters in blue and green. The words “Student Supplement” and “RITA Intelligent Transportation Systems Joint Program Office” in white lettering are directly underneath the logo. Three light blue lines move diagonally across the middle of the blue background.)

A101: Introduction to Acquiring Standards-based ITS Systems

Table of Contents

Introduction - 3

System Engineering "V" Diagram - 3

Types of Contracts and Roles in Systems Engineering - 5

Challenges in Coordinating Multiple Contracts - 7

Useful Web Sites - 8

Introduction

This guide is intended to serve as a supplement to the online training module A101: Introduction to Acquiring Standards-Based ITS Systems.

Background

The Federal Highway Administration (FHWA) has developed a series of training modules to guide users on the use of Intelligent Transportation Systems (ITS) standards.

The A101 module is the second module in a standard curriculum path and is intended for procurement managers, procurement decision makers, and project managers. It is intended to follow I101: Using ITS Standards: An Overview and to precede A102: Introduction to User Needs Identification.

Purpose of this supplement

The modules are designed to be brief courses; the supplement is designed to provide additional information to the participant about various topics covered by the course.

Systems Engineering "V" Diagram

The "V" diagram used by the ITS industry, as shown in Figure 1, reflects a customization of the more general systems engineering process (SEP), but follows widely accepted guidelines.

Figure 1: Systems Engineering "V" Diagram for ITS

(Extended Text Description: Systems Engineering “V” Diagram for ITS. A graphic of the systems engineering process (SEP). The main graphic of the SEP is a V-shaped diagram in gradated blue with some additional horizontal extensions on the left and right side of the top of the V shape. Each section is separated with dark blue lines. There is a key at the lower right showing the blue separator lines, and designating them as “Document/Approval.” The left horizontal extension is labeled as “Lifecycle Processes” and include the sections “Regional Architecture” (separated by a white space) to the second section labeled “Needs Assessment,” (blue line) “Concept Selection,” (blue line) “Project Planning,” (blue line) and “Systems Engineering Management Planning.” At this point the sections begin to descend the left side of the V with “Concept of Operations,” “System Requirements,” “High-level Design,” “Subsystem Requirements,” “Detailed Design,” and “Software Coding / Hardware Fabrication” at the bottom juncture of the V shape. Underneath the bottom point of the V shape are the words “Implementation” then “Development Processes” and a long thin arrow pointing to the right labeled “Time Line.” There is a long thin diagonal arrow pointing down along the left side of the V labeled “Decomposition and Definition.” From the bottom point of the V, the sections begin to ascend up the right side of the V with “Unit Testing,” (blue line) “Subsystem Integration,” (blue line) “Subsystem Verification,” (blue line) “System Integration,” (blue line) “System Verification,” (blue line) “Initial Deployment,” (blue line) “System Validation,” and (blue line) “Operations and Maintenance.” There is a long thin arrow pointing up along the right side of the V shaped labeled “Integration and Recomposition.” At this point the sections on the right “wing” of the V are labeled with “Changes and Upgrades” and (white space) “Retirement/Replacement.” Between the V shape there are a series of gray dashed arrows connecting the related sections on each left/right side of the V shape. The first arrow (top) is labeled “System Validation Plan” and connects “Concept of Operations” on the left and “System Validation” on the right. The second arrow is labeled “System Verification Plan (System Acceptance)” and connects “System Requirements” on the left and “System Verification and Deployment” on the right. The third arrow is labeled “Subsystem Verification Plan (Subsystem Acceptance)” and connects “High-Level Design” on the left and “Subsystem Verification” on the right. The last arrow (at the bottom) is labeled “Unit/Device Test Plan” and connects “Detailed Design” on the left and “Unit/Device Testing” on the right. The SEP steps can also be described as parts of phases which are listed across the top of the graphic: Phase -1 (Interfacing with Planning and the Regional Architecture), Phase 0 (Concept Exploration and Benefits Analysis), Phase 1 (Project Planning and Concept of Operations Development), Phase 2 (System Definition and Design), Phase 3 (System Development and Implementation), Phase 4 (Validation, Operations and Maintenance, Changes and Upgrades), Phase 5 (System retirement/replacement). Numerous cross-cutting activities are listed vertically to the left of the V diagram: Stakeholder involvement, Elicitation, Project Management Practices, Risk Management, Program Metrics, Configuration Management, Process Improvement, Decision Gates, Trade Studies, Technical Reviews, and Traceability.)

The "V" starts with identifying the portion of the regional ITS architecture that is related to the project. Other artifacts of the planning and programming processes that are relevant to the project are collected and used as a starting point for project development. This is the first step in defining an ITS project.

Next, the agency develops a business case for the project. Technical, economic, and political feasibility are assessed; benefits and costs are estimated; and key risks are identified. Alternative concepts for meeting the project's purpose and need are explored, and the superior concept is selected and justified using trade study techniques. Once funding is available, the project starts with the next step.

The "V" then begins to dip downward to indicate an increased level of detail. The project stakeholders reach a shared understanding of the system to be developed and how it will be operated and maintained. The Concept of Operations (ConOps) is documented to provide a foundation for more detailed analyses that will follow. It will be the basis for the system requirements that are developed in the next step.

At the system requirements stage, the stakeholder needs identified in the ConOps are reviewed, analyzed, and transformed into verifiable requirements that define what the system will do but not how the system will do it. Working closely with stakeholders, the requirements are elicited, analyzed, validated, documented, and baselined.

The system design is created based on the system requirements including a high-level design that defines the overall framework for the system. Subsystems of the system are identified and deconstructed further into components. Requirements are allocated to the system components, and interfaces are specified in detail. Detailed specifications are created for the hardware and software components to be developed, and final product selections are made for off-the-shelf components.

Hardware and software solutions are created for the components identified in the system design. Part of the solution may require custom hardware and/or software development, and part may be implemented with off-the-shelf items, modified as needed to meet the design specifications. The components are tested and delivered ready for integration and installation.

Once the software and hardware components have been developed, the "V" changes direction to an upward slope. The various components are individually verified and then integrated to produce higher-level assemblies or subsystems. These assemblies are also individually verified before being integrated with others to produce yet larger assemblies, until the complete system has been integrated and verified.

Eventually, the system is installed in the operational environment and transferred from the project development team to the organization that will own and operate it. The transfer also includes support equipment, documentation, operator training, and other enabling products that support ongoing system operation and maintenance. Acceptance tests are conducted to confirm that the system performs as intended in the operational environment. A transition period and warranty ease the transition to full system operation.

After the ITS system has passed system verification and is installed in the operational environment, the system owner/operator, whether the state Department of Transportation (DOT), a regional agency, or another entity, runs its own set of tests to make sure (i.e., validate) that the deployed system meets the original needs identified in the ConOps.

Once the customer has approved 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 upgrades are identified, they are documented, considered for addition to the system baseline, and incorporated as funds become available. An abbreviated version of the SEP is used to evaluate and implement each change. This occurs for each change or upgrade until the ITS system reaches the end of its operational life.

Finally, operation of the ITS system is periodically assessed to determine its efficiency. If the cost to operate and maintain the system exceeds the cost to develop a new ITS system, the existing system becomes a candidate for replacement. A system retirement plan will be generated to retire the existing system gracefully.

To find more information on the SEP, see the links provided in the Useful Web Sites section of this supplement.

Types of Contracts and Roles in Systems Engineering

The SEP is designed to ensure that the systems owner obtains a product that meets the users' needs; however, much of the work is performed by others.

Those who perform the bulk of the "V" process should be familiar with systems engineering. Typically, the systems owner will hire staff and/or consultants to perform this work. This includes the tasks from project inception through the development of procurement specification for each of the major subsystems.

The procurement specifications are then released and the systems owner, along with the systems engineering assistant, will select the desired development team for each subsystem.

If the subsystem is a well-defined, off-the-shelf (or nearly so) product (for example a message sign) the procurement is fairly simple, as shown in Figure 2. The systems engineering assistant will typically be able to produce a specification that details the desired product in enough detail and the manufacturer is unlikely to find requirements that break their standard implementation. As a result, the manufacturer is able to produce their product with very little interaction with the systems engineering assistant or systems owner. While there may be some customization for the project, e.g., the exact size of the sign, it is likely to be built from known, product-line modules.

Figure 2: Procurement of an off-the-shelf product

(Extended Text Description: Figure 2: Procurement of an off-the-shelf product. The “V” portion of the SEP diagram described on Figure 1 above has shading on the lower juncture point and the first section on the right diagonal which shows that the device vendor’s role covers: 1)The detailed design, except for the portion covered by the area previously highlighted in slide 27, indicating that they do not need to duplicate the work of the standard; 2) All of the software and hardware development; 3) All of the unit testing; 4) All of the subsystem integration and verification. The shading is darker as you move down the V indicating that the more detailed processes are largely hidden from the view of the agency, whereas the shading of the subsystem verification is barely existent indicating that this step is done with the presence of the agency.)

The main interaction among the parties occurs on the delivery of the product when the systems owner, with help from the systems engineering assistant, verifies that the delivered subsystem meets the project's specifications. The development team often monitors the verification so that they can gain additional insights to the problems that are identified.

If the subsystem represents a product for which there is no widely accepted industry definition, or requires customized development, then a more extensive contract must be used, as shown in Figure 3. Most management systems fall into this category.

When procuring a custom product, the systems engineering assistant should work with the systems owner to identify the expectations for the system, including the user needs for the system and the institutional constraints as to how the systems owner will interact with the system. The systems engineering assistant then derives the requirements and even begins to define the high-level design details. This information should be included in the procurement specification with a clear indication that the primary goal is to fulfill the concept of operations with a solution that matches the requirements and design as closely as possible. The systems owner will then be able to select the desired development team with the assistance of the systems engineering assistant.

In practice, most development teams will propose to base their development on reusing some existing base product. However, since the systems engineering assistant prepared the requirements without the knowledge of which product would be used as a base, there are likely to be inconsistencies between the design assumptions in the requirements and the design assumptions in the base product. Thus, the development team's first task should be to review the project documentation and propose modifications that may be able to meet the defined user needs while minimizing customization efforts. This task will require a great deal of detailed interaction among the systems owner, systems engineering assistant, and development team.

Figure 3: Procurement of a customized product

(Extended Text Description: Figure 3: Procurement of a customized product. The “V” portion of the SEP diagram described in full on Figure 1 above with shading on it that shows that the system integrator’s role covers: 1) The detailed design, except for the portion covered by the area previously highlighted in slide 27, indicating that they do not need to duplicate the work of the standard; 2) Portions of all prior steps starting at the same point in time (i.e., the boundary of the shaded area forms a vertical line against the slanted V with each previous stage receiving less and less shading); 3) The software and hardware development; 4) The unit testing; 5) The subsystem integration and verification; 6) The system integration and verification; 7) The initial deployment; 8) The system validation. The shading is darker as you move down the V indicating that the more detailed processes are largely hidden from the view of the agency, whereas the shading of the higher level steps is minimal indicating that these steps are highly visible to the agency.)

Once the parties reach agreement on the details, the actual development is performed with relatively little direct involvement of the systems owner or systems engineering assistant. However, the interaction starts again once the development team begins finalizing its subsystem. The systems engineering assistant and systems owner will typically review the subsystem verification test reports from the development team and may perform their own subsystem development tests. Once the subsystem is deemed to be ready, it is integrated into the larger system, and the systems owner and systems engineering assistant perform the system verification tests, with the development team still available to correct problems found.

Finally, the system is deployed and validated by the systems owner.

Challenges in Coordinating Multiple Contracts

Some of the biggest problems have arisen in ITS projects when the channels among the systems owner, systems engineering assistant, and development team are limited and there is a need for customization. There are various reasons why communications can become limited, including:

• The systems owner may not appreciate the importance of holding frequent meetings to allow these parties to talk among each other.
• The systems owner and/or the systems engineering assistant fail to hold the development team responsible for meeting their deliverables early in the project; thus, requirements are never discussed in detail and the development team adopts a revised definition until the problem is discovered late in the project.
• The systems owner and/or systems engineering assistant fail to require the development team to maintain system documentation. As a result, verbal agreements are never captured and refined to a consensus point, which results in disagreements at the end at the project.
• Contractual relationships may limit communications. For example, the development team might be hired as a part of a large construction contract where the construction contractor wants to limit conversations between their subconsultants and the client.

Parties should be aware of these challenges and strive to prevent them on their projects.

Useful Web Sites

Understanding the Systems Engineering Process (SEP): https://www.incose.org/

Understanding benefits of SEP: https://www.standishgroup.com/

Systems Engineering for ITS: https://ops.fhwa.dot.gov/publications/seitsguide/

Systems Engineering Guidebook for ITS: https://www.fhwa.dot.gov/cadiv/segb/

ITS Standards: https://www.standards.its.dot.gov/

NTCIP: https://www.ntcip.org/

TMDD: https://www.ite.org/technical-resources/standards/tmdd/

Incident Management (IEEE 1512): http://grouper.ieee.org/groups/scc32/imwg/index.html. (Content is no longer available.)

Guides

NTCIP: http://www.ntcip.org/library/standards/default.asp?standard=9001. Content is no longer available.

IEEE 1512: http://grouper.ieee.org/groups/scc32/imwg/guide.pdf. Content is no longer available.

Testing: https://www.ntcip.org/file/2018/11/NTCIP9012v0127r.pdf. (Content is no longer available.)

Standards that Contain SEP Information as of 19 October 2010

NTCIP 1203: Object Definitions for Dynamic Message Signs (DMS)

NTCIP 1204: Environmental Sensor Station Interface Standard (ESS)

NTCIP 1209: Object Definitions for Transportation Sensor Systems (TSS)

NTCIP 1210: Objects for Signal System Masters (SSM)

NTCIP 1211: Objects for Signal Control and Prioritization (SCP)

NTCIP 1213: Objects for Electrical and Lighting Management Systems (ELMS)

NTCIP 2306: Application Profile for XML in ITS Center-to-Center Communications

TMDDv3.0: Traffic Management Data Dictionary (TMDD) and Message Sets for External Traffic Management Center Communications (MS-ETMCC)