Module 2 - A101

A101: Introduction to Acquiring Standards-based ITS Systems

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: Graphic image of introduction information. 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 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 are the words “RITA Intelligent Transportation Systems Joint Program Office.” )

Slide 2:

Welcome

Shelley Row, P.E., PTOE

Director

ITS Joint Program Office

Shelley.Row@dot.gov

(Extended Text Description: Slide 2: Screen capture snapshot of RITA website - for illustration only. Below this image is a link to the current website: https://www.its.dot.gov/pcb - this screen capture snapshot shows an example from the RITA website from June 3, 2011. At the top of the page it shows the RITA logo with the text Research and Innovative Technology Administration - Intelligent Transportation Systems. Below the main site banner, it shows the main navigation menu with the following items: About RITA, Communities of Interest, Contact Us, Press Room, RITA Offices, Site Map, and a Search button. Below the main navigation menu, it shows a sub-navigation menu with the following items: About Us, T3 Webinars, ITS Peer-to-Peer, Resources, Local ITS PCB and Testimonials. Beneath the sub-navigation menu, the page is sub-titled "ITS Professional Capacity Building Program" and is divided into sub-sections such as "Welcome to ITS Professional Building", "News", "ITS Technical Assistance" and "Scheduled T3 Webinars". Again, this image serves for illustration only. The current website link is: https://www.its.dot.gov/pcb)

ITS PCB Home

(Note: There is additional text attached to this slide that includes the following introductory information from Shelley Row):

"ITS Standards can make your life easier. Your procurements will go more smoothly and you’ll encourage competition, but only if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems.

I am Shelley Row the director of the ITS Joint Program Office for USDOT and I want to welcome you to our newly redesigned ITS standards training program of which this module is a part. We are pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines web based modules with instructor interaction to bring the latest in ITS learning to busy professionals like you.

This combined approach allows interested professionals to schedule training at your convenience, without the need to travel. After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the webinars.

ITS Standards training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB program we prepare professionals to adopt proven and emerging  ITS technologies that will make surface transportation safer, smarter and greener which improves livability for us all. You can find information on additional modules and training programs on our web site ITS PCB Home.

Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you for participating and we hope you find this module helpful."

Slide 3:

(Extended Text Description: A101 Introduction to Acquiring Standards-based ITS Systems title. Footer graphic with dark blue long rectangle with words “RITA Department of Transportation Research and Innovative Technology Administration” in white to the left side, and the “Standards ITS Training” logo (white box, lettering in green and blue) box to the right side. )

Slide 4:

Target Audience

• Procurement managers
• Procurement decision makers
• Project managers

Slide 5:

Instructor

Ken Vaughn, P.E.
President
Trevilon Corporation Herndon, VA, USA

Slide 6:

Recommended Prerequisites

• I101: Using ITS Standards: An Overview
• Helpful to have knowledge of
  • Intelligent Transportation Systems (ITS)
  • Managing ITS deployment projects
  • Government procurement processes
  • Benefits of standards
  • Systems engineering process (SEP)

Slide 7:

Curriculum Path (SEP)

(Extended Text Description: Curriculum Path (SEP). A graphical illustration indicating the sequence of training modules for the standards that include Systems Engineering Process content. Each module is represented by a box with the name of the module in it and an arrow showing the logical flow of the modules and the current module highlighted. There are six boxes in two rows of three. The first box is labeled “I101 Using ITS Standards: An Overview.” An arrow from this box connects it to a highlighted purple box labeled “A101 Introduction to Acquiring Standards-Based ITS Systems,” representing this module. An arrow from this box connects it to a box labeled “A102 Introduction to User Needs Identification.” An arrow from this box connects it to a box located at the start of the next line labeled “A201 Details on Acquiring Standards-Based ITS Systems.” An arrow from this box connects it to a box labeled “Understanding User Needs” with three lines below reading A311a NTCIP 1203, A313a NTCIP 1204 v03, and A321a TMDD v3.0. Finally, an arrow from this box connects it to a box labeled “Specifying Requirements” with three lines below reading A311b NTCIP 1203, A313b NTCIP 1204 v03, and A321b TMDD v3.0.)

Slide 8:

Curriculum Path (Non-SEP)

(Extended Text Description:Curriculum Path (Non-SEP). A graphical illustration indicating the sequence of training modules for the standards that do not include Systems Engineering Process content. Each module is represented by a box with the name of the module in it and an arrow showing the logical flow of the modules and the current module highlighted. There are nine blue boxes in three rows of three. The first box at the upper left corner is labeled “I101 Using ITS Standards: An Overview.” An arrow from this box pointing directly to the right connects it to a highlighted purple box labeled “A101 Introduction to Acquiring Standards-Based ITS Systems,” representing this module. An arrow from this box connects it to a box labeled “A102 Introduction to User Needs Identification.” An arrow from this box connects it to a box located at the start of the next line labeled “A201 Details on Acquiring Standards-Based ITS Systems.” An arrow from this box connects it to a box labeled “A202 Identifying and Writing User Needs When ITS Standards Do Not Have SEP Content.” An arrow from this box connects it to a box labeled “A103 Introduction to ITS Standards Requirements Development.” An arrow from this box connects it to a box located at the start of the next line labeled “A203 Writing Requirements When ITS Standards Do Not Have SEP Content.” An arrow from this box connects it to a box labeled “A3xxa Identifying and Writing Specific User Needs for NTCIP 12xx vxx.” Finally, an arrow from this box connects it to a box labeled “A3xxb Developing and Writing Specific Requirements for NTCIP 12xx vxx.” The last two boxes contain an asterisk indicating that they are expected to be included in the Year 2 training modules.)

*Expected in year 2 training modules.

Slide 9:

Learning Objectives

1. Identify what managers should know
2. Articulate process for acquiring standards-compliant ITS systems
3. Differentiate between standards with and without SEP

Slide 10:

Slide 11:

Discuss

• What do you think of when someone mentions "ITS Standards"?
• Use the chat pod to answer

Slide 12:

Learning Objective #1

Types of ITS Standards

• Data Standards
  • Define domain-specific information
  • DMS, ESS, TMDD, etc.
• Communication Standards
  • Define low-level communications
  • TCP/IP, Ethernet, serial, etc. in ITS environment
• Both must be defined for a system interface

Slide 13:

Additional Key Terms

• Management system
• Device

Slide 14:

Slide 15:

Multiple Choice Poll

• How do ITS standards assist in procurements?
  • They define all requirements
  • They define details, but need tailoring
  • Communication standards are precise, but data standards need to be tailored
  • Data standards define precise requirements, but communication standards need to be tailored

Slide 16:

Learning Objective #2

Benefits of ITS Standards

• Standards define technical details, but need tailoring
  • Standard provides a checklist of features to consider
    • Optional features (e.g., display of graphics)
    • Desired ranges (e.g., number of messages)

Slide 17:

Learning Objective #2

Other Benefits of ITS Standards

• Management Benefits
  • Addressed in Module I101
• Acquisition Benefits
  • Price competition among product vendors
  • Easier to switch from one vendor to another
  • Reduced integration costs for central system
  • Market synergies
    • Off-the-shelf testing tools

Slide 18:

Slide 19:

Discussion

• How do we determine the appropriate tailoring?
• Use the chat pod to answer

Slide 20:

Learning Objective #1

Systems Engineering Process (SEP)

(Extended Text Description: Systems Engineering Process (SEP). 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. 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.)

Slide 21:

Learning Objective #1

Benefits of SEP

• Helps define scope
  • Higher level of stakeholder participation
  • More likely that system meets user expectations
  • Better system documentation
• Reduced risk of cost and schedule overruns
  • Fewer defects in accepted product
  • More predictable outcomes

Slide 22:

Slide 23:

Discuss Roles

• Who are the key players that are involved in a typical systems procurement?
• Use the chat pod to answer

Slide 24:

Learning Objective #1

Roles

• Identify key players of the systems engineering process
  • System owner
  • Systems engineering assistant
  • Development team

Slide 25:

Learning Objective #1

Interaction Among Team

• Communication is critical
  • All three roles have distinct perspectives and skills
  • Each role provides value to the project
  • Issues should be identified and discussed early

Slide 26:

Slide 27:

Multiple Choice

• Where do the standards fit into the SEP "V" diagram?
  • At the top of the "V"
  • Concept of Operations, System Requirements, and High-Level Design
  • High-Level Design and Detailed Design
  • ITS standards address issues outside of the "V" diagram

Slide 28:

Learning Objective #2

ITS Standards and the SEP

(Extended Text Description: ITS Standards and the SEP. The “V” portion of the SEP diagram (described on Systems Engineering Process (SEP) above) with highlights drawn on it as follows: 1)The left side of the detailed design step is highlighted to depict that this is the primary subject area of all ITS standards; 2) After a mouse click, the left side of the high-level design and subsystem requirements steps is highlighted to depict the fact that standards that include SEP content also define details from the high level design; 3) After another mouse click the right side of the unit test, subsystem integration, and subsystem verification steps is highlighted to indicate that some standards now include test procedures.)

Slide 29:

Learning Objective #3

Standards With SEP Content

• Define subsystem user needs
  • E.g., manage fonts for a message sign
• Define subsystem requirements
  • E.g., determine number of fonts
  • Traced to user needs
• Trace each requirement to a single design

Slide 30:

Learning Objective #3

Standards Without SEP Content

• Earlier ITS standards only document design
  • Content was derived by perceived needs
  • Context has to be inferred by user
  • Missing components need to be defined by user
    • User needs
    • Requirements
    • Some design details
  • Must map user requirements to remaining details

Slide 31:

Slide 32:

Multiple Choice

• How rigid are subsystem requirements?
• What type of contract do you use to acquire this subsystem?
  • Requirements are known, use fixed price
  • Requirements will be revised, use cost-plus
  • It depends

Slide 33:

Learning Objective #2

Combining SEP and Procurement

• Devices are largely off-the-shelf
  • Requirements are well-known
• Management systems often require software development
  • Requirements are refined during project life
• Different scope requires
  • different procurement vehicle
  • different interface within the SEP

Slide 34:

Learning Objective #2

Typical Scope of Device Vendor

(Extended Text Description: Typical Scope of the Device Vendor. The “V” portion of the SEP diagram (described on the Systems Engineering Process (SEP) diagram above) with shading on it that 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.)

Slide 35:

Learning Objective #2

Typical Scope of System Integrator

(Extended Text Description: Typical Scope of the Systems Integrator. The “V” portion of the SEP diagram (described on the Systems Engineering Process (SEP) diagram 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.)

Slide 36:

Learning Objective #2

ITS Standards

• Reduce work
  • Simplifies project specification
  • Allows reuse of design and implementation
  • Facilitates testing
• Reduce risk
• Reduce schedule

Slide 37:

Four Procurement Scenarios

• Device procurement
  • Standard with SEP content
  • Standard without SEP content
• Management system procurement
  • Standard with SEP content
  • Standard without SEP content

Slide 38:

Learning Objective #1

Preparatory Steps

• Define system concept of operations
  • Inform public about current traffic-related events
• Define system requirements
  • System shall allow the user to define the message to convey to the public, which will automatically expire when the event ends

Slide 39:

Learning Objective #1

Preparatory Steps

• Define major subsystems
  • Management system
  • Message signs
• Define communications environment
• Identify services needed from external subsystems

Slide 40:

Learning Objective #3

Device: Standard With SEP Content

• Select services from defined user needs
  • Define a message
  • Activate and display a message
• Select subsystem requirements from standard
  • Support multi-page messages
• Mapping to design elements is standardized

Slide 41:

Learning Objective #3

Device: Standard Without SEP Content

• Define needed services
• Define subsystem requirements
• Map to standardized design elements
  • Define missing design elements (e.g., dialogs)

Slide 42:

Learning Objective #3

Management System: Standard With SEP Content

• Standard with SEP Content
  • Select user needs from standard
  • Select requirements from standard
  • Define scenarios when data exchange is required

Slide 43:

Learning Objective #2

When Do We Document Need for Standardized Features?

(Extended Text Description: When Do We Document Need for Standardized Features. The same SEP “V” diagram (described onTypical Scope of the Systems Integrator diagram above) with a line that emphasizes that the system integrator’s role starts at a point in time and they then review all previously developed documentation. The diagram is also supplemented with the text “Constantly harmonize all system documentation” in the lower left corner to emphasize the importance of reviewing all previous documentation as new information is discovered in later steps.)

Slide 44:

Learning Objective #3

Management System: Standard Without SEP Content

• Standard Without SEP Content
  • Define detailed requirements for each exchange
  • Map exchanges to design details and enhance
• Dialog
• Messages
• Data Elements
  • Define scenarios when data exchange is required

Slide 45:

Management System: Real-World

• Most management systems will control multiple types of devices
  • Some based on standards with SEP content
  • Some based on standards without SEP content
  • Some not based on standards
• All projects should follow SEP
  • The SEP content within standards merely simplify this work

Slide 46:

Learning Objective #1

Follow-on Steps

• Select communication stacks and standards
• Define other requirements (e.g., hardware)
• Procure
• Implement
• Test

Slide 47:

Learning Objective #3

Testing with SEP

• Standards with SEP Content
  • Standardized test procedures (ESS and soon for DMS)
• Facilitates testing and testing market
  • Others have reusable test procedures in industry
• Requirements are standardized and stable
• Once a test procedure is written for one deployment, it can be reused repeatedly
• Standards without SEP Content
  • Test development effort is more involved since tests must be based on system requirements

Slide 48:

Learning Objective #2

Testing the Final Product

• Testing is critical step
  • Verify subsystems meet standardized interface
  • Verify system integrates all components together
  • Validate system meets user needs
• Document all testing
  • Allows reproducible results
  • Documents what was done
• Budget and schedule for multiple rounds
  • Allows for problems identified during initial tests

Slide 49:

Slide 50:

Practical Impacts

• What are your concerns about applying the Systems Engineering Process, as we have described, to acquire standards-based ITS systems?
• Use the chat pod to answer

Slide 51:

Learning Objective #1

Practical Impacts

• How large is the resulting specification?
  • Specifications should be as detailed as necessary
• Is a feature important? If yes,
  • Identify in concept of operations
  • Define in requirements
  • Verify in a test procedure
  • Validate that it meets user needs
  • Budget for the effort

Slide 52:

Learning Objective #1

Understanding Cost Implications

• SEP requires
  • Time
  • Experienced personnel
  • Commitment
• Proven to lower risks and increase quality
• Requires investment

Slide 53:

Learning Objective #1

Benefits of SEP

(Extended Text Description: Benefits of SEP. A scatter chart diagram depicting the relative amount of cost overrun on projects against the percentage of the project cost spent on systems engineering effort. The scatter points show that projects spending less than 4% of the budget on systems engineering effort can range from coming in right at planned project cost to being more than double planned project cost with a mean near 1.5 times the planned project cost. When systems engineering effort is increased to 8%, the range is nearly the same, but the mean is closer to 1.3 times the planned project cost. With 12% systems engineering effort, the range of data points is concentrated to 0.8 times planned project cost to 1.4 times planned project cost with a mean of about 1.1 - 1.2 times planned project cost. Data points beyond a 15% systems engineering effort are all located at almost exactly 1.0 times planned project cost.)

Eric Honour, "Understanding the Value of Systems Engineering," 2004.

Slide 54:

SEP Benefits vs. Type of Acquisition

• SEP reduces risks
• Even acquiring a DMS entails risks
• Risks are higher for standards without SEP content
• Risks are higher for custom development (e.g., central systems)
• Risks are higher when dealing with multiple standards (e.g., central systems)

Slide 55:

Today's Objectives

• Identified key concepts that managers should know
• Described process for acquiring standards compliant ITS systems
• Differentiated between standards with and without SEP

Slide 56:

What Did We Learn Today?

1. All projects should follow the Systems Engineering Process.
2. The SEP assists in defining the Scope for a project and in meeting the project Budget and Schedule .
3. ITS Standards with SEP content reduce Systems Engineering effort on a project.
4. ITS Standards without SEP content still Assist in projects using the SEP.
5. All requirements should be fully Tested prior to acceptance.

Slide 57:

Where to Learn More

• Module supplement
  • NTCIP Guide
  • TMDD Guide -IEEE 1512 Guide
  • Systems Engineering Guidebook for ITS
• Other ITS courses
  • A102: Next module for all standard curriculum paths
  • A201: Follows A102 for all paths
  • T101: For more information on testing

Slide 58: