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
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.
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.
(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.
(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
- Institute of Transportation Engineers, Application Programming Interface (API) Standard for the Advanced Transportation Controller (ATC) v02.17. ATC Joint Committee, 1 September 2011. http://www.ite.org/standards/index.asp
- Institute of Transportation Engineers, ATC 5201 Advanced Transportation Controller (ATC) Standard Version 06.10. ATC Joint Committee, 30 July 2012. http://www.ite.org/standards/index.asp
- Institute of Transportation Engineers, ATC 5202 Model 2070 Controller Standard Version 03. ATC Joint Committee, 28 December 2012. http://www.ite.org/standards/index.asp
- Institute of Transportation Engineers, ATC5401 Application Programming Interface (API) Standard for the Advanced Transportation Controller (ATC) v02. ATC Joint Committee, 15 September 2013. http://www.ite.org/standards/index.asp
- Institute of Transportation Engineers, Intelligent Transportation System (ITS) Standard Specification for Roadside Cabinets v01.02.17b. ATC Joint Committee, 16 November 2006. http://www.ite.org/standards/index.asp
- National Electrical Manufacturers Association, NEMA Standards Publication TS 2-2003 v02.06 Traffic Controller Assemblies with NTCIP Requirements. NEMA, 2003.
- National Electrical Manufacturers Association, NEMA Standards Publication TS 1-1989 Traffic Control Systems. NEMA, 1989.
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.
|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|
|COR||Contract Officer's Representative|
|COTM||Contract Officer's Task Manager|
|FHWA||Federal Highway Administration|
|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|
|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.|
|Operational User||A technician or transportation engineer who uses the controller to perform its operational tasks.|
|PCB||Printed Circuit Board|
|PMP||Project Management Plan|
|POP||Period of Performance|
|RITA||Research and Innovative Technology Administration|
|SDO||Standards Development Organization|
|SOW||Statement of Work|
|SRS||Software Requirements Specification|
|TBD||To Be Determined|
|TFCS||Transportation Field Cabinet System|
|TOD||Time of Day|
|USDOT||United States Department of Transportation|
|WBS||Work Breakdown Structure|
- California Department of Transportation, Caltrans Transportation Electrical Equipment Specifications (TEES). California Department of Transportation, 12 March 2009.
- Institute of Transportation Engineers http://www.ite.org/standards/
- ITS PCB Training http://www.pcb.its.dot.gov/
- NEMA Standards Publication TS 2-2003 v02.06 Traffic Controller Assemblies with NTCIP Requirements
- Orange County Strategic Deployment Plan 2013 Update http://www.scag.ca.gov/Documents/OrangeCounty Aug2013Update Final.pdf
- United States Department of Transportation Federal Highway Administration. Systems Engineering for Intelligent Transportation Systems. January 2007. https://www.fhwa.dot.gov/cadiv/segb/
- United States Department of Transportation Federal Highway Administration. Systems Engineering Guidebook for Intelligent Transportation Systems Version 3.0. November 2009. https://www.fhwa.dot.gov/cadiv/segb/
7. Study Questions
1. Which of the following features of ATC units allows them to run concurrent application programs?
- Has a computational capability that can grow with technology
- Works with all major transportation field cabinet systems
- Works with NTCIP standards
- Runs API Software
2. Which of the following is NOT a good source for discovering user needs?
- Regional Plans
- Integration testing
- Strategic plans
3. Which of the following is NOT a source of user needs for the specification development process?
- Brand of controller equipment currently used by the agency
- Existing type of transportation field cabinet systems
- Existing strategic or regional plans
4. Which of the following is a TRUE statement?
- There is only one way to organize user needs in a ConOps
- A ConOps for an ATC is written from a vendor's point of view
- Consider your specification when organizing your user needs
- A ConOps is just "busy work"