Module 44 - A307b

A307b: Understanding Requirements for Advanced Transportation Controllers Based on ATC 5201 Standard v06

HTML of the PowerPoint Presentation

(Note: This document has been converted from a PowerPoint presentation 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.)

Slide 1:

(Extended Text Description: Welcome - Graphic image of introductory slide. A large dark blue rectangle with a wide, light grid pattern at the top half and bands of dark and lighter blue bands below. There is a white square ITS logo box with words "Standards ITS Training" in green and blue on the middle left side. The word "Welcome" in white is to the right of the logo. Under the logo box is the logo for the U.S. Department of Transpotation, Office of the Assistant Secretary for Research and Technology.)

Slide 2:

(Extended Text Description: This slide, entitled "Welcome" has a photo of Ken Leonard, Director, ITS Joint Program Office, on the left hand side, with his email address, Ken.Leonard@dot.gov. A screen capture snapshot of the home webpage is found on the right hand side - for illustration only - from August 2014. Below this image is a link to the current website: www.its.dot.gov/pcb - this screen capture snapshot shows an example from the Office of the Assistant Secretary for Research and Development - Intelligent Transportation Systems Joint Program Office - ITS Professional Capacity Building Program/Advanced ITS Education. Below the main site banner, it shows the main navigation menu with the following items: About, ITS Training, Knowledge Exchange, Technology Transfer, ITS in Academics, and Media Library. Below the main navigation menu, the page shows various content of the website, including a graphic image of professionals seated in a room during a training program. A text overlay has the text Welcome to ITS Professional Capacity Building. Additional content on the page includes a box entitled What's New and a section labeled Free Training. Again, this image serves for illustration only. The current website link is: https://www.its.dot.gov/pcb.)

Slide 3:

Slide 4:

A307b:

Understanding Requirements for Advanced Transportation Controllers Based on ATC 5201 Standard v06

Slide 5:

Instructor

Ralph W. Boaz

President

Pillar Consulting, Inc.

San Diego, CA, USA

Slide 6:

Target Audience

• Traffic management and engineering staff;
• Traffic Management Center/operations staff;
• Traffic signal maintenance staff;
• System developers;
• Software developers;
• Private and public sector users including manufacturers; and
• Procurement personnel.

Slide 7:

Recommended Prerequisites

• I101: Using ITS Standards: An Overview
• A101: Introduction to Acquiring Standards-based ITS Systems
• A102: Introduction to User Needs Identification
• A201: Details On Acquiring Standards-based ITS Systems
• A202: Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content
• A103: Introduction to ITS Standards Requirements Development
• A203: Writing Requirements When ITS Standards Do Not Have SEP Content

Slide 8:

Recommended Prerequisites (cont.)

• C101: Introduction to the Communications Protocols and Their Uses in ITS Applications
• A207a: Building an ITS Infrastructure Based on the ATC 5201 Standard Part 1 of 2
• A207b: Building an ITS Infrastructure Based on the ATC 5201 Standard Part 2 of 2
• A208: Using the ATC 5401 Application Programming Interface Standard to Leverage ITS Infrastructures
• A307a: Understanding User Needs for Advanced Transportation Controllers Based on ATC 5201 Standard v06

Slide 9:

Curriculum Path

(Extended Text Description: This slide contains a graphic illustration indicating the sequence of training modules that lead up to this course. Each module is represented by a box with the name of the module in it and arrows showing the logical flow between the modules. There are 12 boxes in total; three rows of 4 boxes. The sequence goes from left to right with the fourth box on the first and second rows having arrows which connect to the first box on the second and third rows respectively. The module titles are as follows:

• I101 Using ITS Standards: An Overview
• A101 Introduction to Acquiring Standards -based ITS Systems
• A102 Introduction to User Needs Identification
• A201 Details on Acquiring Standards-based ITS Systems
• A202 Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content
• A103 Introduction to ITS Standards Requirements Development
• A203 Writing Requirements When ITS Standards Do Not Have SEP Content
• C101 Intro. to Comm. Protocols and Their Uses in ITS Applications
• A207a Building an ITS Infrastructure Based on the ATC 5201 Standard (Part 1)
• A207b Building an ITS Infrastructure Based on the ATC 5201 Standard (Part 2)
• A208 Using the ATC 5401 Application Programming Interface Standard to Leverage ITS Infrastructures
• A307a Understanding User Needs for Advanced Transportation Controllers (ATC) Based on 5201 Standard v06
• A307b Understanding Requirements for Advanced Transportation Controllers Based on 5201 Standard v06

The last box is highlighted indicating that it represents the current module in the series.)

Slide 10:

Learning Objectives

1. Describe a systems engineering-based ATC specification development process
2. Write requirements for ATCs based on user needs
3. Describe a specification based on ATC 5201 Standard v06
4. Verify an ATC procurement specification

Slide 11:

Learning Objective #1: Describe a Systems Engineering-Based ATC Specification Development Process

• Traditional approaches to developing transportation controller procurement specifications
• Systems engineering approach to developing an ATC procurement specification
• Benefits of the specification development process
• Challenges to preparing a good ATC specification

Slide 12:

Learning Objective #1

Traditional Approaches to Developing Transportation Controller Procurement Specification

• Not based on formalized user needs and requirements
  • Agencies often use an existing specification, copy it, and distribute
  • Not connected to other stakeholders who may have user needs that apply to the transportation controller
• Funding problems as policy makers and senior managers see no relationship between their approved strategic or regional plans and the potential solutions offered by ATCs
• Hardware and application procurement are combined for a single purpose; for example, signal control, ramp metering, and data collection

Slide 13:

Learning Objective #1

Systems Engineering Approach to Developing an ATC Procurement Specification

• Develop Concept of Operations (ConOps) with user needs
• Develop requirements based on user needs
• Capture requirements and show traceability to user needs in an ATC specification

Slide 14:

Learning Objective #1

Systems Engineering Processes Used in Standards Development

IEEE - Systems Engineering

An interdisciplinary collaborative approach to derive, evolve, and verify a life cycle balanced system solution that satisfies customer expectations and meets public acceptability.

(Extended Text Description: This slide, entitled "Systems Engineering Processes Used in Standards Development," uses a graphic that illustrates the systems engineering process used in standards development. This graphic introduces three circles evenly spaced in a descending fashion from left to right. They contain the text "User Needs," "Requirements" and "Design," respectively. There is a curved arrow leading from the "User Needs" circle to the "Requirements" circle. There is a curved arrow leading from the "Requirements" circle to the "User Needs" circle. This same arrange of arrows occurs between the "Requirements" circle and the "Design" circle.)

Graphics: Ralph W. Boaz

Slide 15:

Learning Objective #1

Systems Engineering Specification Development Process

(Extended Text Description: This slide, entitled "Systems Engineering Specification Development Process," 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.")

Graphics: Ralph W. Boaz

Slide 16:

Learning Objective #1

Relationships of User Needs and Requirements

(Extended Text Description: This slide, entitled "Relationships of User Needs and Requirements," uses graphics to highlight the relationships between a user needs and requirements. User needs are represented by green boxes on the left side of the slide labeled "Need #1," "Need #2," "Need #3," and "Need #4." Requirements are represented by green boxes on the right side of the slide labeled "Requirement #1," "Requirement #2," "Requirement #3," and "Requirement #4." Three relationships between the user needs and the requirements are represented using solid blue lines with arrows on each end connecting the needs and requirements as follows:

• One-to-One – Need #1 is connected to Requirement #1;
• One-to-Many – Need #2 is connected to Requirement #2 and Requirement #3; and
• Many-to-One – Need #3 and Need #4 are connected to Requirement #4.

The slide is animated displaying each relationship as the instructor introduces it one at a time until all are shown.)

Graphics: Ralph W. Boaz

Slide 17:

Learning Objective #1

Benefits of the Systems Engineering Specification Development Process

• User needs identified by a broad base of stakeholders
• Existing strategic or regional plans already approved by policy makers and higher management are covered in the user needs
• Provides justification for investment in ATC units that non-technical people can understand
• Shows accountability to the public

Slide 18:

Learning Objective #1

Challenges to Preparing a Good ATC 5201 Standard v06-Based Specification

• Internal resistance to change
• External resistance to change
• Procurement schedules may not allow for the time and effort to go through a rigorous process
• Identifying and getting stakeholders together
• Difficulty getting stakeholders to describe their user needs as opposed to design requirements
• Often, people procuring the equipment are unfamiliar with a systems engineering process

Slide 19:

Slide 20:

Learning Objective #1

An agency specification comes out of what part of the systems engineering specification development process?

Answer Choices

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

Slide 21:

Learning Objective #1

Review of Answers

a) Concept of operations
Incorrect. A concept of operations is the result of user needs development.

b) Requirements development
Correct! Requirements are stated in the agency's specification.

c) Strategic plan
Incorrect. A strategic plan may be an input to the user needs development process.

d) User needs development
Incorrect. User needs are stated in a concept of operations.

Slide 22:

Summary of Learning Objective #1

Describe a Systems Engineering-Based ATC Specification Development Process

• Traditional approaches to developing transportation controller procurement specifications
• Systems engineering approach to developing an ATC procurement specification
• Benefits of the specification development process
• Challenges to preparing a good ATC specification

Slide 23:

Learning Objective #2: Write Requirements for ATCs Based on User Needs

• Structure and characteristics of well-formed requirements
• Writing requirements for ATCs based on agency user needs
• Resolving conflicting requirements

Slide 24:

Learning Objective #2

Definition of a "Well-Formed" Requirement

[Actor] [Action] [Target] [Constraint] [Localization]

Actor - Identifies who or what does the action

Action - Identifies what is to happen

Target - Identifies who or what receives the action

Constraint - Identifies how to measure success or failure of the requirement

Localization - Identifies the circumstances under which the requirement applies

Localization and constraint portions are important but not all requirements will have both.

Slide 25:

Learning Objective #2

Example of a Well-Formed Requirement

[Actor] [Action] [Target] [Constraint] [Localization]

5.3.7 Color Graphics Display

(Extended Text Description: This slide, entitled "Example of a Well-Formed Requirement," provides an example transportation controller requirement. As the instructor speaks, five ovals appear which encompass various parts of the requirement that are part of the structure of a well-formed requirement. The ovals are identified by uppercase text using arrows. "The transportation controller" is encompassed by an oval and pointed to by "ACTOR." "Shall provide" is encompassed by an oval and pointed to by "ACTION." "A liquid crystal display (LCD)" is encompassed by two ovals and pointed to by "TARGET." "That is capable of color graphics" is encompassed by an oval and pointed to by "CONSTRAINT.")

If a requirement can't be stated in this simple format, you probably need to use multiple requirements.

Slide 26:

Learning Objective #2

Characteristics of Well-Formed Requirements

• Necessary
  • Must be useful and traceable to needs
• Concise
  • Minimal, understandable and expressed in declarative language such as "shall statements"
• Attainable
  • Realistic to achieve within available resources and time
• Standalone
  • Stated completely in one place
• Consistent
  • Does not contradict itself, nor any other stated requirement

Slide 27:

Learning Objective #2

Characteristics of Well-Formed Requirements (cont.)

• Unambiguous
  • Susceptible to only one interpretation
• Verifiable
  • Requirement can be met through: inspection, analysis, demonstration, or test

Slide 28:

Learning Objective #2

User Needs from Strategic and Regional Plans

Case Study

This section 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 ten 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.

Slide 29:

Learning Objective #2

Example "Strategy" and User Needs From Case Study

Strategy Example

CC1 - Countywide Communications Master Plan: Physical and logical connectivity to support multi-modal and multi-agency operations and data sharing needs.

User Need Example

7.4.3.1 Multi-Network Ready

The city needs transportation controllers equipped with communications capabilities to accommodate connectivity with multiple systems and communications networks. The city has legacy center-to-field (C2F) communications to some arterials. The majority of the arterials are supported by Ethernet communications through fiber or high speed radios. It is expected that some applications will share a physical network while others will require separate networks.

Slide 30:

Learning Objective #2

Example of a Well-Formed Requirement

[Actor] [Action] [Target] [Constraint] [Localization]

5.4.9 Dual Ethernet Capability

(Extended Text Description: This slide, entitled "Example of a Well-Formed Requirement," provides an example transportation controller requirement. As the instructor speaks, four ovals appear which encompass various parts of the requirement that are part of the structure of a well-formed requirement. The ovals are identified by uppercase text using arrows. "The transportation controller" is encompassed by an oval and pointed to by "ACTOR." "Shall provide" is encompassed by an oval and pointed to by "ACTION." "A minimum of two Ethernet ports supporting 10/100 BaseT communications" is encompassed by an oval and pointed to by "TARGET." "With RJ45 physical connectors" is encompassed by an oval and pointed to by "CONSTRAINT.")

Slide 31:

Learning Objective #2

Example "Strategy" and User Needs From Case

Study

Strategy

CC3 - Provide a Connected Vehicles Platform: Allow for the future possibility of connected vehicles in order to capitalize on the robust local operational environment and further enhance the existing foundation.

User Need Example

7.5.1 Connected Vehicle V2I Communications

The city needs transportation controllers that will be capable of performing Connected Vehicle Vehicle-to-Infrastructure (V2I) communications. Connected vehicle applications have the potential for a major advancement in integrated traveler information, safety, transportation management, and eco driving. It is anticipated legacy controller units that were installed over eight years ago will not have the processing power to perform V2I communications.

Slide 32:

Learning Objective #2

Example of a Well-Formed Requirement [Actor] [Action] [Target] [Constraint] [Localization]

5.5.1 Processing Power

(Extended Text Description: This slide, entitled "Example of a Well-Formed Requirement," provides an example transportation controller requirement. As the instructor speaks, four ovals appear which encompass various parts of the requirement that are part of the structure of a well-formed requirement. The ovals are identified by uppercase text using arrows. "The transportation controller" is encompassed by an oval and pointed to by "ACTOR." "Shall have" is encompassed by an oval and pointed to by "ACTION." "A CPU" is encompassed by an oval and pointed to by "TARGET." "With a minimum CoreMark Benchmark of 600 per specification by the chip manufacturer" is encompassed by an oval and pointed to by "CONSTRAINT.")

Slide 33:

Learning Objective #2

Example "Strategy" and User Needs From Case Study

Strategy

MM2 - Bus Rapid Transit: Roll out BRT service in a two-step implementation process. Technology applications could include transit signal priority (TSP), real-time bus arrival information, and automated fare collection.

User Need Example

7.8.3.3 Increase Public Use of Transit Buses

The city needs transportation controllers that can be used to help increase ridership of transit buses. The city needs to improve customer service and ridership experience through the use of field applications that may include transit signal priority (TSP), real-time bus arrival information, automated fare collection and others.

Slide 34:

Learning Objective #2

Example of a Well-Formed Requirement [Actor] [Action] [Target] [Constraint] [Localization]

5.3.5 Screen Size

(Extended Text Description: This slide, entitled "Example of a Well-Formed Requirement," provides an example transportation controller requirement. As the instructor speaks, four ovals appear which encompass various parts of the requirement that are part of the structure of a well-formed requirement. The ovals are identified by uppercase text using arrows. "The transportation controller" is encompassed by an oval and pointed to by "ACTOR." "Shall have" is encompassed by an oval and pointed to by "ACTION." "A minimum screen size" is encompassed by an oval and pointed to by "TARGET." "Of 16 lines by 40 characters" is encompassed by an oval and pointed to by "CONSTRAINT.")

Slide 35:

Learning Objective #2

Example of Constraint Identified by Operations Staff

6.5.1 NEMA TS 2 Equipment

The city needs transportation controllers equipped for its existing transportation field cabinet systems. The city has 70% of its TFCSs that are NEMA TS 2 Type 1 and 30% of its TFCSs are NEMA TS 2 Type 2. The transportation controller should be suitable for these cabinet systems.

Slide 36:

Learning Objective #2

Example of a Well-Formed Requirement [Actor] [Action] [Target] [Constraint] [Localization]

5.2.1 NEMA TS 2 Type 2 Interfaces

(Extended Text Description: This slide, entitled "Example of a Well-Formed Requirement," provides an example transportation controller requirement. As the instructor speaks, four ovals appear which encompass various parts of the requirement that are part of the structure of a well-formed requirement. The ovals are identified by uppercase text using arrows. "The transportation controller" is encompassed by an oval and pointed to by "ACTOR." "Shall provide" is encompassed by an oval and pointed to by "ACTION." "Physical interfaces" is encompassed by an oval and pointed to by "TARGET." "Per NEMA TS 2 Standard v02.06 Section 3.3 for Type 2 controller units" is encompassed by an oval and pointed to by "CONSTRAINT.")

Slide 37:

Learning Objective #2

Write Requirements for ATCs Based on User Needs - Additional Guidance

• Review Module A103 Learning Objective #2 "Avoiding the Pitfalls When Writing Requirements"
• There must be at least one requirement for every user need identified in the Concept of Operations (ConOps)
• Requirements that pertain to optional portions of ATC 5201 Standard v06 must be written in a specification (see LO#3)
• Requirements that pertain to non-optional portions of ATC 5201 Standard v06 may or may not be not written in the specification

Slide 38:

Learning Objective #2

Resolving Conflicting Requirements

• ATC 5201 Standard v06 generally describes a minimum level of capability for conforming controller units
• Specifications-based ATC 5201 Standard v06 are a composite of standards and/or other specifications (referenced documents)
• This composite may consist of:
  • Explicit requirements developed by the agency
  • Explicit requirements gleaned from referenced documents
  • Referenced requirements (or sections) in the referenced documents
  • Inherited requirements from referenced documents with an established document precedence

Slide 39:

Learning Objective #2

Establish Precedence Between Referenced Standards Documents and Specifications to Resolve Conflicting Requirements

• In the case where there is a conflict between the requirements in referenced documents that is not directly addressed by a stated requirement, the precedence of the referenced documents shall be as follows:
  1. Agency Specific Requirements
  2. ATC 5201 Standard v06 Requirements
  3. TFCS Requirements (e.g. NEMA TS 2, Model 332, ITS Cabinet v01)

Slide 40:

Learning Objective #2

ATC Specification with Requirements That Exceed ATC 5201 Standard v06

• Sometimes an agency requirement may go beyond the standard
  5.4.10 Ethernet Ports
  The transportation controller shall provide a minimum of six Ethernet ports supporting 10/100 BaseT communications with RJ45 physical connectors.
• From ATC 5201 Standard v06, Section 7.3
  "The ATC shall provide two internal 100BASE-TX store and forward Ethernet switches per the IEEE 802.3 specification for 10/100 Mbps...
  Switch 1...provides two RJ45 Ethernet connectors...
  Switch 2...provides two RJ45 Ethernet connectors..."
• Such instances are not considered conflicting and the specification would still be considered conformant to ATC 5201 Standard v06

Slide 41:

Learning Objective #2

Watch for Requirements That Subsume Others as It Can Cause Confusion

• Sometimes one requirement is subsumed by another:
  5.4.13 Generic Serial Port 1
  The transportation controller shall have a general purpose serial port using a male DB9 connector.
  
  5.2.1 NEMA TS 2 Type 2 Interfaces
  The transportation controller shall provide physical interfaces per NEMA TS 2 Standard v02.06 Section 3.3 for Type 2 controller units.
• In this case, the physical connections described in NEMA TS 2 Standard v02.06 Section 3.3 provides such a port.

Slide 42:

Slide 43:

Learning Objective #2

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

Answer Choices

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

Slide 44:

Learning Objective #2

Review of Answers

a) Action
Incorrect. There is always an action in a well-formed requirement, for example, shall [blank].

b) Constraint
Correct! Well-formed requirements may not have a constraint that provides the bounds of a requirement.

c) Target
Incorrect. There is always a target that receives the action in a well-formed requirement.

d) Actor
Incorrect. There is always an actor in a well-formed requirement. Typically, a system, subsystem, or name thereof.

Slide 45:

Summary of Learning Objective #2

Write Requirements for ATCs Based on User Needs

• Structure and characteristics of well-formed requirements
• Writing requirements for ATCs based on agency user needs
• Resolving conflicting requirements

Slide 46:

Learning Objective #3: Describe a Specification

Based on the ATC 5201 Standard v06

• Structure of ATC 5201 Standard v06
• Components of a specification based on ATC 5201 Standard v06
• Essential areas that must be addressed so that a controller unit conforms to ATC 5201 Standard v06

Slide 47:

Learning Objective #3

Structure of the ATC 5201 Standard

Section 1 - Introduction

Section 2 - Overall Description

Section 3 - Functional Requirements

Section 4 - Engine Board Details

Section 5 - Communication Interface Details

Section 6 - Physical and User Interface Details

Section 7 - Parallel and Serial I/O Details

Section 8 - Environmental and Test Procedures

Slide 48:

Learning Objective #3

Structure of the ATC 5201 Standard (cont.)

Section 9 - Performance and Material Requirements Section 10 Quality Control

Appendix A - Linux Operating System and Minimum Kernel Configuration

Appendix B - Required Device Driver Interfaces

Appendix C - Historical Background of Traffic Controllers

Slide 49:

Learning Objective #3

Transportation Controller Specifications are Subject to the Agency's Procurement Process

• Agency specifications are written based on how the agency will be purchasing equipment
  • Agencies may create a specification based on a particular project
  • Agencies may create standing specifications for use over multiple procurements
• Agencies may have a prequalified vendors list or a single vendor selected through a bid process

Slide 50:

Learning Objective #3

Proposed Outline for an ATC Specification

1. Purpose
2. Scope
3. References
4. Background
5. Requirements
   • 5.1 General Requirements
   • 5.2 Transportation Field Cabinet System Requirements
   • 5.3 User Interface Requirements
   • 5.4 I/O Requirements
   • 5.5 Performance Requirements
   • 5.6 Environmental and Testing Requirements
   • 5.7 Warranty Requirements
   • 5.8 Other Requirements

Slide 51:

Learning Objective #3

Essential Areas That Must be Addressed so

That a Controller Unit Conforms to ATC 5201 Standard v06

• Operational voltages*
• User interface requirements*
• I/O Requirements*
• CPU Performance and Memory Requirements
• Other Requirements

*Areas that are influenced by the TFCS standard or specification in which the ATC unit is to operate.

Slide 52:

Learning Objective #3

Example Operational Voltage Requirements

Operational voltages are dictated by the TFCS

5.6.1 Operating Voltage

The transportation controller shall meet the operating voltage requirements per Section 2.1.2 of the NEMA TS 2 Standard.

5.6.2 Operating Frequency

The transportation controller shall meet the operating frequency requirements per Section 2.1.3 of the NEMA TS 2 Standard.

5.6.3 Power Interruptions

The transportation controller shall meet the power interruption requirements per Section 2.1.4 of the NEMA TS 2 Standard.

Slide 53:

Learning Objective #3

User Interface Requirements - ATC Minimums

(Extended Text Description: This slide, entitled "User Interface Requirements – ATC Minimums," highlights the minimum ATC user interface requirements. The graphic consists of three large text boxes that are aligned vertically and extend the width of the slide. They are outlined by heavy solid lines. The content of the text boxes is as follows:
Text Box 1 (top)

• CPU ACTIVE LED Indicator
• Ethernet Port
• USB Port (for removable memory device only)

Text Box 2 (middle)

• EIA-574, 9-pin "D" serial connector for console

OR
• RJ45, serial connector for console
Text Box 3 (bottom)

• EIA-574, 9-pin "D" connector for an external front panel

OR

• Keyboard, LCD, Bell

There is a large plus sign between Text Box 1 and Text Box 2 and between Text Box 2 and Text Box 3 all centered on the slide.)

Graphics: Ralph W. Boaz

Slide 54:

Learning Objective #3

User Interface Options

• User Interface Optional Features
  • Datakey
  • AUX Switch (only available for Keyboard/LCD/Bell configuration)
• Power Supply Optional Features ° Power Switch
  • Power LEDs

Slide 55:

Learning Objective #3

User Interface Options

• ATC controller user interfaces may have some restrictions based on the TFCS architecture selected
• ATC 5201 allows expansion of user interface requirements to include high-resolution graphics and additional front panel keys

Agencies are cautioned to verify that these types of interfaces will also operate in a mode that supports the basic ATC 5201 and ATC 5401 standard interfaces

Agencies are cautioned that requiring manufacturer-specific front panel keys in their specifications will restrict their option of ATC providers

Slide 56:

Learning Objective #3

Example User Interface Requirements

• The transportation controller shall provide a user interface with the following:
  • CPU ACTIVE LED Indicator
  • Ethernet Port (at least one in front)
  • USB Port
  • EIA-574, 9-pin "D" serial connector for console
  • Standard ATC Keyboard
  • Liquid Crystal Display
  • Bell
  • Power LEDs

Slide 57:

Learning Objective #3

Serial and Parallel I/O Requirements

• A TFCS standard or specification may set requirements for serial and parallel I/O requirements
• Additional serial ports may be specified based on the agency's needs

Agencies are cautioned to not unnecessarily require communications ports as it can drive up costs and limit choices of vendors

Slide 58:

Learning Objective #3

Example I/O Requirements

5.4.13 Generic Serial Port 1

The transportation controller shall have a general purpose serial port using a male DB9 connector.

5.4.14 Generic Serial Port 2

The transportation controller shall have a general purpose serial port using a male DB25 connector.

Slide 59:

Learning Objective #3

CPU Performance and Memory Requirements

ATC 5201 Standard v06 Minimum Requirements

• CPU - CoreMark of 500 minimum
• Short Term Volatile Memory, such as DRAM - 64 MB Minimum
• Short-Term Non-Volatile Memory, such as SRAM - 1 MB Minimum
• Long-Term Non-Volatile Memory, such as FLASH - 16 MB Minimum

Agencies are cautioned not to arbitrarily require the highest number of MIPS and memory available as it can drive up costs and limit choices of vendors

Slide 60:

Learning Objective #3

Example CPU Performance and Memory Requirements

5.5.2 DRAM Memory

The transportation controller shall have DRAM capacity of 128 MB minimum.

Slide 61:

Learning Objective #3

Example Other Requirements

5.8.4 Software Requirements

5.8.4.1 Application Tool Chain

The vendor shall identify in writing the tool chain (compiler and C libraries) used to create application programs for the Engine Board of the transportation controller.

5.8.4.2 Linux BSP Tool Chain

The vendor shall identify in writing the tool chain (compiler and C libraries) used to create the Linux Board Support Package for the Engine Board of the transportation controller.

5.8.4.3 Linux BSP Source Code

The vendor shall provide access to the source code used to produce the Linux Board Support Package environment for the Engine Board. (Note: This requires special arrangements, possibly an escrow.)

Slide 62:

Learning Objective #3

Example Other Requirements

5.8.4.4 API Software

The vendor shall provide operational API software for their transportation controllers once the API Reference Implementation is available from AASHTO, NEMA, and ITE.

Important:

See slides on "Creating a Specification Based on the ATC 5401 Standard" and "Additional Guidance When Procuring Application Software" in Module A208.

Slide 63:

Slide 64:

Learning Objective #3

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

Answer Choices

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

Slide 65:

Learning Objective #3

Review of Answers

a) Optical disk requirements
Correct! There is no mention of optical disks in ATC 5201 Standard v06.

b) CPU performance requirements
Incorrect. CPU performance requirements should be set by the user as the minimums allowed are low for contemporary processors.

c) TFCS requirements
Incorrect. The TFCS architecture in which the ATC unit is going to reside must be stated in the specification.

d) User Interface requirements
Incorrect. There are various UI options provided by ATC 5201 Standard v06. These requirements should be explicit.

Slide 66:

Summary of Learning Objective #3

Describe a Specification Based on the ATC 5201 Standard v06

• Structure of ATC 5201 Standard v06
• Components of a specification based on ATC 5201 Standard v06
• Essential areas that must be addressed so that a controller unit conforms to ATC 5201 Standard v06

Slide 67:

Learning Objective #4: Verify an ATC Procurement Specification

• Verifying the specification using traceability
• Verifying conformance and compliance

Slide 68:

Learning Objective #4

Verifying the Specification Using Traceability

• Create a traceability matrix of user needs to requirements
• Tool used to help verify completeness and correctness
• Suggest capturing traceability throughout the requirements development process

Slide 69:

Learning Objective #4

Needs-To-Requirements Traceability

• Every user need must be addressed by at least one requirement
• Every requirement must trace to at least one user need
• Any user need that is not addressed by at least one requirement means:
  • A requirement was missed or
  • The user need must be re-evaluated

Slide 70:

Learning Objective #4

Needs-To-Requirements Traceability (cont.)

• Any requirement that does not address at least one user need means:
  • The requirement must be re-evaluated or
  • A user need was missed
• Every aspect of each user need should be addressed in requirements

Slide 71:

Learning Objective #4

Needs-to-Requirements Traceability Matrix (NRTM)

UN ID	User Need	Req ID	Requirement
6.5.1	NEMATS2 Equipment	5.2.1	NEMA TS 2 Type 2 Interfaces
		5.6.1	NEMA Operating Voltages
		5.6.2	NEMA Operating Frequencies
		5.6.3	NEMA Power Interruptions
7.3.1	Minimum Display Size	5.3.3	Text-Based Display Size

Slide 72:

Learning Objective #4

Verifying Conformance and Compliance

• Conformance
  • A condition that exists when an item meets all of the mandatory requirements as defined by a formal standard
  • Typically, a procurement specification or a physical device is said to conform to a standard
  • Conformance is not enough to achieve compatibility, portability, interoperability, and interchangeability for an agency
  • Verification of conformance of a procurement specification is performed by inspection—comparing the specification to the ITS standard(s)

Slide 73:

Learning Objective #4

Verifying Conformance and Compliance

• Compliance
  • A condition that exists when an item meets all of the requirements of a procurement specification
  • Typically, devices, software, and communications are said to comply to an agency's procurement specification
  • Agencies should write their procurement specifications so that compliance will make compatibility, portability, interoperability, and interchangeability possible
  • Verification of compliance of a device, software, or communications is performed through inspection, demonstration, analysis, and testing

Slide 74:

Slide 75:

Learning Objective #4

Which of the following is a TRUE statement?

Answer Choices

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

Slide 76:

Learning Objective #4

Review of Answers

a) Agencies use standards so that they don't have to use specs
Incorrect. Agencies use standards to write their procurement specifications.

b) There should only be one requirement per user need
Incorrect. There may be multiple requirements needed to fully address a user need.

c) Demonstration may be used to verify compliance
Correct! Other methods of verifying compliance are through inspection, analysis, and testing.

d) Traceability is not used in verifying specifications
Incorrect. Traceability is used to help determine if the specification is complete and that all user needs identified are addressed.

Slide 77:

Summary of Learning Objective #4 Verify an ATC Procurement Specification

• Verifying the specification using traceability
• Verifying conformance and compliance

Slide 78:

What We Have Learned

1. In a systems engineering development process, the agency specification is the result of requirements development.
2. Specifications based on the ATC 5201 Standard v06 are a composite of standards and/or other specifications.
3. Areas that must be addressed in an ATC specification are operational voltages, user interface requirements, input/output requirements, CPU, performance, and memory requirements.
4. Agencies should verify that their ATC specification conforms to ATC 5201 Standard v06 and verify that vendors provide controllers that comply with their ATC specification.

Slide 79:

Resources

• United States Department of Transportation. Systems Engineering Guidebook for Intelligent Transportation Systems Version 3.0. USDOT, November 2009. http://www.fhwa.dot.gov/cadiv/segb/
• Caltrans Transportation Electrical Equipment Specifications (TEES), 12 March 2009
• NEMA Standards Publication TS 2-2003 v02.06 Traffic Controller Assemblies with NTCIP Requirements
• Institute of Transportation Engineers http://www.ite.org/standards/
• ITS PCB Training Home
• Orange County Strategic Deployment Plan 2013 Update http://www.scag.ca.gov/Documents/OrangeCounty Aug2013Update Final.pdf

Slide 80: