Module 39 - A307a

A307a: Understanding User Needs for Advanced Transportation Controllers Based on ATC 5201 Standard v06

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.)

A307a: Understanding User Needs for Advanced Transportation Controllers Based on ATC 5201 Standard v06

Table of Contents

Introduction/Purpose - 2

Samples/Examples - 2

Reference to Other Standards - 3

Case Studies - 4

Glossary - 5

References - 7

Study Questions - 7

1. Introduction/Purpose

The advanced transportation controller (ATC) family of standards provides an open architecture hardware and software platform that can support a wide variety of Intelligent Transportation Systems (ITS) field applications including traffic management, safety, security, and other applications. These standards are characterized by their modularity, support of multiple and current application programs, and design to facilitate the adoption of new technologies. ATC 5201 Advanced Transportation Controller Standard v06 defines transportation controller units that can grow with technology, are multipurpose, and can be specified to operate in any of the major transportation field cabinet systems (TFCSs) in use today.

Modules A207b and A208 provided details of ATC 5201 Standard v06 and suggested a procurement specification outline. This module focuses on how such a procurement specification may be developed, emphasizing the identification and formalization of user needs. This module reviews features of ATC controller units, offers new ways to think in developing procurements, discusses the components of an ATC procurement specification, and helps users identify user needs.

2. Samples/Examples

Figure 1 illustrates the processes (stages) of the systems life cycle. Figure 1 highlights the concept of operations (ConOps) development and systems requirements development stages that lead to a software or hardware implementation.

This figure is a graphic representing the systems life cycle in a V-like formation called the Vee Diagram. Please see the Extended Text Description below.

(Extended Text Description: This figure is a graphic representing the systems life cycle in a V-like formation called the Vee Diagram. The Vee Diagram is depicted as a thick light blue graphic "V" with a short horizontal portion (same thickness as the "V" portion graphic) at the left top of the "V" extending to the left and a short horizontal portion at the right top of the "V" extending to the right. It is said that it looks like the letter "V" with wings. There is a long thin horizontal arrow which points to the right at the bottom of the slide with the words "Time Line" sitting on top of it. The arrow extends along the bottom of the slide covering the distance of most of the V-like graphic. The thick lines of the Vee Diagram are sectioned by dark blue lines to delineate the systems life cycle activities (identified below as lifecycle processes). There is a small legend on the lower right of the slide indicating these dark blue lines indicate "Document/Approval." From left to right on the left horizontal portion, there are two sections labeled: "Regional Architecture(s)" and "Feasibility Study / Concept Exploration". Moving downward on the left side of the Vee Diagram there are four sections labeled: "Concept of Operations," "System Requirements," "High-Level Design" and "Detailed Design". There is a bottom section at the vertex of the Vee Diagram labeled: "Software/Hardware Development Field Installation." Moving upward on the right side of the Vee Diagram there are four sections labeled: "Unit/Device Testing," "Subsystem Verification," "System Verification & Deployment" and "System Validation." From left to right on the right horizontal portion there are three sections labeled: "Operations and Maintenance," "Changes and Upgrades" and "Retirement/Replacement." There is an arrow that points downward along the edge of the left side of the Vee Diagram with the label "Decomposition and Definition." At the vertex of the Vee Diagram, there is the label "Implementation." There is an arrow that points upward along the right side of the Vee Diagram with the label "Integration and Recomposition." In a smaller font, underneath the left horizontal portion there are the words "Lifecycle Processes" identifying the sections of the Vee Diagram as life cycle processes. In the same size font at the vertex of the Vee Diagram are the words "Development Processes." It is intended that this identify the nine lifecycle processes "Concept of Operations" through "Systems Validation" as development processes. There are dotted horizontal lines with arrows at each end indicating a relationship between the processes on the left and right sides of the "V" as follows: "Concept of Operations" and "System Validation" have a dotted line labeled "System Validation Plan;" "Systems Requirements" and "System Verification & Deployment" have a dotted line labeled "System Verification Plan (System Acceptance);" "High-Level Design" and "Subsystem Verification" have a dotted line labeled "Subsystem Verification Plan (Subsystem Acceptance);" "Detailed Design" and Unit Testing have a dotted line labeled "Unit/Device Test Plan;" and "Software/Hardware Development Field Installation" at the vertex has no dotted lines associated with it. There is an oval around the left side of the Vee diagram.)

Figure 1. Stages of the Systems Life Cycle

In Figure 2, the systems engineering life cycle stages are modified to show them using process notation. User needs are developed with existing strategic or regional plans as an important input into this process. The output of the user needs development are user needs captured (written) in a ConOps. The user needs are inputs to the requirements development process. Requirements are developed based on the user needs. We have removed the design process typically in a general systems engineering process. Instead, the result of the requirements process is the agency specification. A critical part of this development process is the tracing of user needs to requirements.

The Systems Engineering Specification Development Process. Please see the Extended Text Description below.

(Extended Text Description: This figure uses a graphic that illustrates the systems engineering process used to develop a specification. There are two circles evenly spaced in a descending fashion from left to right representing processes. They contain the text "User Needs" and "Requirements," respectively. There is a curved arrow extending from the User Needs process to the Requirements process. Thereis a curved arrow extending from the Requirements process to the User Needs process. There are three rectangular graphics with lines across them representing documents. The first document is located at the top of the slide and is labeled "Strategic or Regional Plans." It has a curved arrow extending from the document to the User Needs process. There is a curved arrow extending from the User Needs process two the second document located in the lower left of the slide that is labeled "Concept of Operations." There is a curved arrow extending from the Requirements process to the third document located in the lower right of the slide that is labeled "Agency Specification." There is a dotted double arrow extending between the second and third documents. The double arrow is labeled "Traceability.")

Figure 2. The Systems Engineering Specification Development Process

3. Reference to Other Standards

4. Case Studies

This module uses examples from the "Orange County Intelligent Transportation Systems (ITS) Strategic Deployment Plan (SDP) - Update 2013." This SDP was developed by the Orange County Transportation Authority (OCTA) a Metropolitan Planning Organization (MPO) for Orange County,CA.

The SDP uses ITS "strategies" to provide context for the agencies and the private sector who are deploying technology today and for the following 10 years. Strategies are organized as follows: Transit management and multi-modal (MM), traffic management (TM), incident management and emergency response (IM), traveler information (TI), performance monitoring (PM), communications and connectivity (CC), safety (SF), and institutional (IN).

Other strategic or regional plans may have different names and different methods of expressing desired capabilities.

5. Glossary

Term Definition
AASHTO American Association of State Highway and Transportation Officials
API Application Programming Interface
APIRI API Reference Implementation (software)
APIRI Project Entire project managed by this PMP including software, hardware and documentation.
Application Program Any program designed to perform a specific function directly for the user or, in some cases, for another application program. Examples of application programs include word processors, database programs, Web browsers and traffic control programs. Application programs use the services of a computer's O/S and other supporting programs such as an application programming interface.
ATC Advanced Transportation Controller
ATP Authorization to Proceed
CO Contracting Officer
COR Contract Officer's Representative
COTM Contract Officer's Task Manager
FHWA Federal Highway Administration
H/W Hardware
I/O Input/Output
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
ISO International Organization for Standardization
ITE Institute of Transportation Engineers
ITS Intelligent Transportation Systems
JC Joint Committee
JPO Joint Program Office
Linux Low-level software that is freely available in the Linux community for use with common hardware components operating in a standard fashion.
Linux Kernel The Unix-like operating system kernel that was begun by Linus Torvalds in 1991. The Linux Kernel provides general O/S functionality. This includes functions for things typical in any computer system such as file I/O, serial I/O, interprocess communication and process scheduling. It also includes Linux utility functions necessary to run programs such as shell scripts and console commands. It is generally available as open source (free to the public). The Linux Kernel referenced in this document is defined in ATC 5201 Standard v06, Appendix A and Appendix B.
N/A Not Applicable
Operational User A technician or transportation engineer who uses the controller to perform its operational tasks.
O/S Operating System
PCB Printed Circuit Board
PMP Project Management Plan
POP Period of Performance
RI Reference Implementation
RITA Research and Innovative Technology Administration
RTC Real-Time Clock
SDO Standards Development Organization
SOW Statement of Work
SRS Software Requirements Specification
S/W Software
TBD To Be Determined
TFCS Transportation Field Cabinet System
TOD Time of Day
US United States
USDOT United States Department of Transportation
WBS Work Breakdown Structure
WG Working Group

6. References

7. Study Questions

1. Which of the following features of ATC units allows them to run concurrent application programs?

  1. Has a computational capability that can grow with technology
  2. Works with all major transportation field cabinet systems
  3. Works with NTCIP standards
  4. Runs API Software

2. Which of the following is NOT a good source for discovering user needs?

  1. Regional Plans
  2. Integration testing
  3. Stakeholders
  4. Strategic plans

3. Which of the following is NOT a source of user needs for the specification development process?

  1. Brand of controller equipment currently used by the agency
  2. Existing type of transportation field cabinet systems
  3. Existing strategic or regional plans
  4. Stakeholders

4. Which of the following is a TRUE statement?

  1. There is only one way to organize user needs in a ConOps
  2. A ConOps for an ATC is written from a vendor's point of view
  3. Consider your specification when organizing your user needs
  4. A ConOps is just "busy work"