Module 44 - A307b

A307b: Understanding Requirements 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.)

A307b: Understanding Requirements 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 - 8

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. Module A307a focused on developing a Concept of Operations emphasizing the identification and formalization of user needs for ATC 5201 equipment. Module A307b focuses on creating a specification based on the user needs in the ConOps and the features and requirements of ATC 5201 Standard v06. The module demonstrates how to write requirements, discusses the contents of a specification based on ATC 5201 Standard v06 and how to verify the specification.

2. Samples/Examples

Figure 1 illustrates the processes (stages) of the Systems Life Cycle. Figure 1 highlights the Concept of Operations 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:

There is an oval around the left side of the Vee diagram that covers the left side of the "V".)

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 Concept of Operations. 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.

This figure uses a graphic that illustrates the systems engineering process used to develop a specification. 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. There is 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 are dotted double arrows extending between the first and second documents and between the second and third documents. The double arrows are 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) An agency specification comes out of what part of the systems engineering specification development process?

  1. Concept of operations
  2. Requirements development
  3. Strategic plan
  4. User needs development

2) When a requirement is well-formed, which part of the requirement may not be present?

  1. Action
  2. Constraint
  3. Target
  4. Actor

3) Which of the following is NOT an essential part of an ATC specification?

  1. Optical disk requirements
  2. CPU performance requirements
  3. TFCS requirements
  4. User interface requirements

4) Which of the following is a TRUE statement?

  1. Agencies use standards so that they don't have to use specs
  2. There should only be one requirement per user need
  3. Demonstration may be used to verify compliance
  4. Traceability is not used in verifying specifications