Module 42 - A315b Part 2

A315b Part 2: Specifying Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 v03 Standard Part 2 of 2

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:

This slide contains a graphic with the word “Welcome” in large letters. ITS Training Standards “WELCOME” slide, with reference to the U.S. Department of Transportation Office of Assistant Secretary for Research and Technology

Slide 2:

This slide contains a graphic with the word “Welcome” in large letters, photo of Kenneth Leonard, Director ITS Joint Program Office - Ken.Leonard@dot.gov - and on the bottom is a screeshot of the ITS JPO website - www.its.dot.gov/pcb

Slide 3:

Module A315b Part 2:

Specifying Requirements for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 v03 Standard

Part 2 of 2

The title slide shows photo of a 2070 traffic signal controller and indicates the course was updated in July 2020.

Updated July 2020

Slide 4:

Instructor

This slide, entitled “Instructor” has a photo of the instructor, Kenneth Vaughn, on the left-hand side.

Kenneth L. Vaughn

President

Trevilon LLC

Slide 5:

Learning Objectives

Slide 6:

Learning Objective

Slide 7:

Special Considerations: Infrastructure

Overview

Slide 8:

Origins of NTCIP

Original NTCIP Constraints and Origins of Design

NTCIP effort originated in 1993 to support remote communication for traffic signal control

NEMA = National Electrical Manufacturers Association

Slide 9:

Origins of NTCIP

Practical Challenges

Slide 10:

Origins of NTCIP

A Layered Solution

This slide contains three communication reference models. On the left is the Open Systems Interconnect (OSI) model, which is represented as a seven-layer stack. The seven layers, starting from the bottom, are Physical, Data Link, Network, Transport, Session, Presentation, and Application. In the middle is the NTCIP Model, which uses a four-layer stack. The four layers, starting from the bottom, are Subnet, Transport, Application, and Information. the layers of this model are mapped to the ones in the OSI model as follows: NTCIP Subnet equates to OSI Physical and Data Link; NTCIP Transport equates to OSI Network and Transport; NTCIP Application equates to OSI Session, Presentation, and Application. The NTCIP Information Layer resides outside of the OSI stack. On the right is the ITS station reference architecture, which defines 6 areas consisting of a 3-layer stack with additional entities on the left, right, and on top. Starting from the bottom, the three layers are Access, TransNet, and Facility – these are mapped to the Subnet, Transport, and Application Layers of the NTCIP model. On top of the stack and also spanning over the entities on the left and right is the Application Entity, which is mapped to the Information Layer of the NTCIP model. Finally, on the left is the Management Entity and on the Right is the Security Entity.

Slide 11:

Origins of NTCIP

Application Layer

This slide includes the NTCIP model from the previous slide with the Application Layer highlighted.

Slide 12:

Simple Network Management Protocol (SNMP)

SNMP Packet Structure

Author's relevant description: This slide depicts how an SNMP message gets put together across the different layers of the communications stack by showing three levels of analysis. The top layer, labeled Information Layer, depicts an object name of “phaseStatusGroupGreens.1” followed by a value of 32 (indicating a meaning of Phases 2 and 6) followed by the object name of “shortAlarmStatus.0”, which is followed by a value of 0 (indicating a meaning of no error). The Information Layer is shown being miniaturized into the Application Layer, which prepends the following fields as a header: the value of 1 (indicating SNMP version 1), the text “admin” (which represents a community name to control access for the request), the word “Response” (representing the type of message), the value 1 (representing the message ID), the value 0 (representing the error status), and the value 0 (indicating the error index). The Application Layer is then miniaturized into the layer called “Lower Layers” which adds a “Protocol Specific” header and a “Protocol Specific” footer.

Manager decides when to use each object

Slide 13:

Simple Network Management Protocol (SNMP)

Challenges with SNMP

(D)TLS = Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS)

Slide 14:

Simple Transportation Management Protocol (STMP)

STMP Packet Structure

Author's relevant description: This slide depicts how an STMP message gets put together across the different layers of the communications stack by showing three levels of analysis, similar to Slide 12. The top layer, labeled Information Layer, depicts a value of 32 (indicating a meaning of Phases 2 and 6) followed by a value of 0 (indicating a meaning of no error). A note indicates that the object names have been removed as they have been pre-configured. The Information Layer is shown being miniaturized into the Application Layer, which prepends “Response1” as a header to indicate the type of message. A note indicates that there are 13 configurable dynamic objects. The Application Layer is then miniaturized into the layer called “Lower Layers” which adds a “Protocol Specific” header and a “Protocol Specific” footer.

Manager decides configuration of and when to use each "dynamic object"

Slide 15:

Simple Transportation Management Protocol (STMP)

Predominant 1200 bps Environment

Slide 16:

Simple Transportation Management Protocol (STMP)

STMP vs SNMP

Slide 17:

Exception-Based Reporting

A New Approach to Monitoring Equipment

Slide 18:

Exception-Based Reporting

Other Benefits of Approach

Slide 19:

Exception-Based Reporting

Challenges with Exception-Based Reporting

Should consider as a part of cybersecurity migration plan

Slide 20:

Block Objects

Database Uploads and Downloads

Slide 21:

Infrastructure Limitations

Please see extended text description below.

(Extended Text Description: This slide includes three photographs accompanying a table. The table has three columns that describe the capabilities of legacy, mainstream, and emerging infrastructure (i.e., communications and controller equipment). Associated with each column is a photograph of a car. The legacy column depicts a 1930s roadster coupe. The mainstream column depicts a 1970s Ford Mustang. The emerging column depicts recent model Mercedes. The table information is included below:

Capability Legacy Mainstream Emerging
Data Rate 1200-9600 bps 10Mbps >=50 Mbps
Communications Technology Examples Multi-drop Copper Wire, Dial-up Ethernet, LTE Ethernet, WiFi, 5G
Processor Speed 0-4 MIPS 4-60 MIPS >= 60 MIPS
OS and API for CV Applications No Typically no Yes
Controller Examples Type 170 NEMA TS 1 ATC 5202 (2070 L) NEMA TS 2 ATC 5201

)

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

Slide 22:

Infrastructure Limitations

Processor Capability Timeline

Author's relevant description: Processor Capability Timeline: This slide shows a chart that compares millions of instructions per second (MIPS) for processors from ~1951 to ~2017 and shows a fairly steady increase on a logarithmic scale from roughly 0.002 MIPS in 1951 to 100,000 MIPS in 2017. The graph also shows the cost of processors in dollars per million floating point operations per second (MFLOPS) from 1960 to 2017, also on a logarithmic scale. This line starts at roughly $10 million in 1960 and drops to roughly $0.00005 in 2017. Across the chart are three stars that show the processor speed and year for the various controller types discussed in the report. The legacy controllers are represented as a star in 1978 with a processing power of 0.1 MIPS. The mainstream controllers are represented as a star at 1998 with a processing power of roughly 4 MIPS. Finally, the emerging controllers are represented by a star in 2018 and a speed of 400 MIPS

MIPS = Millions of instructions per second

MFLOPS = Millions of floating point operations per second

Source: https://en.wikipedia.org/wiki/FLOPS, https://en.wikipedia.org/wiki/Instructions_per_second#Millions_of_instructions_per_second_(MIPS)

Slide 23:

Infrastructure Limitations

Controller Costs

Slide 24:

Infrastructure Limitations

Photo depicts a 1930's roadster coupe.

Limitations of Legacy Systems for Traffic Signal Control

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

Slide 25:

Infrastructure

Photo of a 1970s Ford Mustang.

Mainstream Systems

Slide 26:

Infrastructure

Photo depitcs a recent model Mercedes nextg to the text Connected Vehicles

Emerging Systems for Traffic Signal Control

Slide 27:

Infrastructure Limitations

Processor Capability Timeline

Processor Capability Timeline: This chart shows a 2012 projection of the percentage of controller deployments from 2011 through 2020 that was developed as a part of the previous version of this course. In 2011, there were just over 300,000 signal controllers in the US and roughly 200,000 of these were in need of replacement to support connected vehicle applications (i.e., legacy controllers) while 100,000 of the controllers were technologically ready. The three lines (total, in need of replacement, and technologically-ready) continue across in a mostly linear fashion until 2018 when there are a total of roughly 340,000 controllers, all of which are shown as technologically-ready. The table is supplemented by text indicating that, at least in Minnesota, in 2019, that this projection has been largely validated as there are only 5% of legacy controllers remaining.

MNDOT data extrapolated from data in https://www.dot.state.mn.us/research/reports/2019/201935.pdf

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

Slide 28:

Communications Loading

Communications Demand Versus Capacity

*https://support.google.com/youtube/answer/2853702?hl=en for 720p resolution

Slide 29:

Communications Loading

Legacy Communications

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

Slide 30:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

Slide 31:

Question

Which of the below is a waning technology that is not recommended for most new deployments?

Answer Choices

  1. Exception reporting
  2. Block objects
  3. STMP
  4. None of the above

Slide 32:

Review of Answers

A small graphical red and yellow X representing incorrect.a) Exception reporting
Incorrect. Exception reporting is a fairly new feature that has been added to NTCIP to reduce overhead in communications.

A small graphical red and yellow X representing incorrect.b) Block objects
Incorrect. Block objects are used to speed the upload and download of large portions of an ASC database.

A small graphical green and yellow check mark representing correct.c) STMP
Correct! STMP is a protocol specific to the transportation industry that requires custom code, extra testing, and integration expenses.

A small graphical red and yellow X representing incorrect.d) None of the above
Incorrect. STMP is a waning technology that is no longer recommended due to its niche market and cost implications.

Slide 33:

Learning Objective

Slide 34:

Special Considerations: Functionality

Overview

Slide 35:

Database Transaction Sets

Need for Complex Transactions

This slide includes a standard 8-phase NEMA traffic signal timing diagram consisting of two rings and two concurrency groups. Ring 1, Concurrency Group A consists of Phases 1 and 2 where Phase 1 is a left turn phase from the left approach turning to the top of the diagram and Phase 2 is a right approach through movement. Ring 1, Concurrency Group B consists of Phases 3 and 4 where Phase 3 is a left turn phase from the top approach turning to the right of the diagram and Phase 4 is a bottom approach through movement. Ring 2, Concurrency Group A consists of Phases 5 and 6 where Phase 5 is a left turn phase from the right approach turning to the bottom of the diagram and Phase 6 is a left approach through movement. Ring 2, Concurrency Group B consists of Phases 7 and 8 where Phase 7 is a left turn phase from the bottom approach turning to the left of the diagram and Phase 8 is a top approach through movement. A barrier line separates the two concurrency groups to indicate that both rings have to cross the barrier at the same time.

Slide 36:

Database Transaction Sets

Impact on operations

Slide 37:

Consistency Checks and Rules

Need for Consistency Checks

Slide 38:

Consistency Checks and Rules

Example Consistency Check

This slide contains the same standard, 8-phase NEMA traffic signal timing diagram that was on Slide 35

Phase 1 2 3 4 5 6 7 8
Ring 1 1 1 1 2 2 2 2
Concurrency 5,6 5,6 7,8 7,8 1,2 1,2 3,4 3,4

Slide 39:

Connected Vehicle Support

Blue label with the text "Connected Vehicles"

Signal Controllers and the Connected Vehicle Environment

Author's relevant description: This slide depicts a diagram similar to that used to depict a service package Physical View in the Architecture Reference for Cooperative and Intelligent Transportation (ARC-IT, http://arc-it.net). At the top is a teal colored box labeled “Traffic Management Center (TMC)”. It is connected to two gold colored boxes (representing field units) with bi-directional lines. One of these boxes is labeled “ITS Roadway Equipment (ASC)”; the line connecting it to the TMC is labeled “NTCIP 1202”. The other gold box is labeled “Connected Vehicle Roadside Equipment (RSE)” and its line connecting to the TMC is labeled “NTCIP 1202/1218”. The two gold boxes are connected with gold dashed lines with a note that these two boxes might be separate physical units or joined into a single unit. There is another bi-directional line between the two gold boxes labeled NTCIP 1202. The ASC includes a white box (showing functionality) within it labeled “Roadway Signal Control”. The RSE is shown with a white box in it labeled “RSE Intersection Management”. Finally, the RSE box is shown with a wireless antenna that is connecting to another wireless antenna hosted by a blue box that is labeled “Vehicle Onboard Equipment (OBE)”

Slide 40:

Connected Vehicle Support

Blue label with the text "Connected Vehicles"

New Features for Connected Vehicles

Slide 41:

Connected Vehicle Support

Blue label with the text "Connected Vehicles"

Challenges with Interface to RSE Intersection Management

TLS = Transport Layer Security

Slide 42:

Clock Coordination

Need for Clock Coordination

This slide includes a timeline at the bottom that starts at 7:59 am and goes until 8:01am. Above the line, there are four stacked gold points representing when four different ASCs might think it is 8:00 am. The four points are shown within a couple of seconds of each other at approximately 8:00:30 am. The distance between 8:00 am and the mean of the four points is labeled “accuracy”. The width of separation of the four points is labeled “precision”.

Slide 43:

Clock Coordination

Blue label with the text "Connected Vehicles"

Need for Clock Coordination

This slide includes the same timeline as shown on Slide 42, but now shows one gold point (representing an ASC) and three blue points (representing vehicles). All four points are stacked at 8:00:00 with very little variance (indicating an accuracy and precision of +/- 50 milliseconds).

Slide 44:

Clock Coordination

Blue label with the text "Connected Vehicles"

Author's relevant description: This slide includes the same timeline as shown on Slide 43, with the same stacked gold and blue points, but the timeline is supplemented by a figure showing how the timing coordination works. At the top of the slide, there are three boxes. The left box is a white box with a gold boundary indicating a function performed by a field device; it is labeled “Roadway Signal Control”, one of the same functions identified in the Figure of Slide 39. A note indicates that this function can use any time source, which might be minutes off from the Global Navigation Satellite System (GNSS) time. The middle box is also a white box with a gold boundary and is labeled “RSE Intersection Management”, which was the other function included in the figure on Slide 39. Connecting these boxes is a green line labeled “intersection control status”, which is an information flow from ARC-IT. This flow includes a note that indicates that the Roadway Signal Control sends what it thinks the current time is in tenths of seconds from the top of the hour according to its unsynchronized clock (e.g., 0.0 seconds) and when it expects to change its phase indication, also in tenths of seconds from the top of the hour (e.g., 4.3 seconds). The RSE Intersection Management box indicates that it will convert the data to GNSS time. It receives GNSS time via a global navigation satellite. It then is connected to a blue “Vehicle OBE” box via a wireless link with a flow name of “intersection status”, which is also defined in ARC-IT. A note on this flow indicates that if the GNSS time reports a current time of 08:00:01.0 (rather than the 0.0 seconds from top of the hour that the ASC thinks it is), the RSE will convert the change time to a GNSS time of 08:00:05.3 (i.e., the current GNSS time of 08:00:01.0 plus the expected change time of 4.3 seconds minus the ASC current time of 0.0 seconds). Finally, the Vehicle OBE also receives the same GNSS signal with time so it can properly interpret the transmitted time from the RSE.

Slide 45:

Managing Expectations for Off-the-Shelf Interoperability

Signal Controllers Have Most Complex Interface

NTCIP 1202 v03 is a step in the right direction

Slide 46:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

Slide 47:

Question

Which of the following most accurately expresses the state of connected vehicle (CV) support in the standard?

Answer Choices

  1. Does not address any CV functionality
  2. Does not define sufficient security for ASCs in a CV environment
  3. Defines a secure solution for intersection maps
  4. Defines a secure solution for signal timing

Slide 48:

Review of Answers

A small graphical red and yellow X representing incorrect.a) Does not address any CV functionality
Incorrect. NTCIP 1202 v03 defines the data to support CV applications, including map and signal timing information

A small graphical green and yellow check mark representing correct.b) Does not define sufficient security for ASCs in a CV environment
Correct! NTCIP 1202 v03 assumes SNMPv1, which is not secure. For CV operation, NTCIP 1202 v03 must only be deployed over a secure protocol (e.g., SNMPv3 with TLS).

A small graphical red and yellow X representing incorrect.c) Defines a secure solution for intersection maps
Incorrect. SNMPv1 does not provide for secure communications.

A small graphical red and yellow X representing incorrect.d) Defines a secure solution for signal timing
Incorrect. SNMPv1 does not provide for secure communications.

Slide 49:

Learning Objective

Slide 50:

Incorporating Requirements Not Supported by Standardized Objects

Overview

Slide 51:

Conditions and Context for Extending the Standard

What is a Custom Extension

Slide 52:

Conditions and Context for Extending the Standard

Reasons to Specify a Custom Extension

Slide 53:

Conditions and Context for Extending the Standard

Costs Associated with a Custom Extension

Slide 54:

Example of Extending the Standard

Orange label with the text "Connected Vehicles"

Connected Vehicle Dilemma Zone Protection: User Need

Slide 55:

Extending the Standard

Orange label with the text "Connected Vehicles"

Connected Vehicle Dilemma Zone Protection: Requirements

Example icon. Can be real-world (case study), hypothetical, a sample of a table, etc.

Slide 56:

Example of Extending the Standard

Orange label with the text "Connected Vehicles"

Connected Vehicle Dilemma Zone Protection: Design

Slide 57:

Example of Extending the Standard

Orange label with the text "Connected Vehicles"

Connected Vehicle Dilemma Zone Protection: Procurement

Slide 58:

Example of Extending the Standard

Orange label with the text "Connected Vehicles"

Connected Vehicle Dilemma Zone Protection: Procurement

Slide 59:

Example of Extending the Standard

Orange label with the text "Connected Vehicles"

Connected Vehicle Dilemma Zone Protection: Procurement

Slide 60:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

Slide 61:

Question

Which of the following is NOT true regarding an extension based on an open solution?

Answer Choices

  1. Documentation is made public
  2. Cost of initial deployment may be higher
  3. Delivered product needs to be tested against requirements
  4. Likely to result in vendor lock-in

Slide 62:

Review of Answers

A small graphical red and yellow X representing incorrect.a) Documentation is made public
Incorrect. The defining characteristic of an open solution is that the documentation is public.

A small graphical red and yellow X representing incorrect.b) Cost of initial deployment may be higher
Incorrect. Vendors are less able to recover costs in subsequent deployments thereby increasing costs for initial deployment.

A small graphical red and yellow X representing incorrect.c) Delivered product needs to be tested against requirements
Incorrect. To obtain the interoperability enabled by an open solution, the product should be tested against the requirements.

A small graphical green and yellow check mark representing correct.d) Likely to result in vendor lock-in
Correct! An open solution prevents true vendor lock-in by ensuring that the design is publicly available

Slide 63:

Learning Objective

Slide 64:

Testing NTCIP 1202 v03 Conformance

Overview

Slide 65:

Systems Engineering Documentation and NTCIP

Systems Engineering Vee-Diagram

This slide displays the Systems Engineering “Vee” Diagram, which shows 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 “Feasibility Study / Concept Exploration.” At this point the sections begin to descend the left side of the V with “Concept of Operations,” “System Requirements,” “High-level Design,” “Detailed Design,” and “Software / Hardware Development Field Installation” 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/Device Testing,” “Subsystem Verification,” “System Verification & Deployment,” “System Validation,” and “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 black 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 & 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 “Subsystem Verification Plan (Subsystem acceptance)” arrow in the middle of the diagram is circled to show that it is the focus of the current discussion.

Slide 66:

Systems Engineering Documentation and NTCIP

Standard Outline for NTCIP 1200 Series

1. General
2. Concept of Operations
3. Functional Requirements
4. Dialogs
5. Management Information Base (MIB)
6. <Other Design Elements>
A. Requirements Traceability Matrix
B. Object Tree
C. Test Procedures
D. Documentation of Revisions
E. <Other Annexes>

Slide 67:

Systems Engineering Documentation and NTCIP

NTCIP 1202 Test Procedures

It is anticipated that Test Procedures may be developed as part of a future revision of NTCIP 1202 v03. Annex C is a placeholder, at present.

- NTCIP 1203 v03

Slide 68:

This slide contains a graphic with the word "Case Study" in large letters. A placeholder graphic of a traffic control center indicating that a real-world case study follows.

Slide 69:

Anaheim Case Study

Gray label with the text "Connected Vehicles"

NTCIP 1202 Standard Testing Project

Slide 70:

Interim Guidance

NTCIP 1202 Standard Testing Project

Slide 71:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

Slide 72:

Question

Which of the below is an appropriate way to test an ASC for conformance to NTCIP 1202 v03?

Answer Choices

  1. Using test procedures contained in Annex C of the standard
  2. Using Anaheim test procedures (when available)
  3. Connecting to system and see if it works
  4. Trusting the vendor

Slide 73:

Review of Answers

A small graphical red and yellow X representing incorrect.a) Using test procedures contained in Annex C of the standard
Incorrect Annex C of NTCIP 1202 v03 is currently a placeholder that does not contain any test procedures

A small graphical green and yellow check mark representing correct.b) Using Anaheim test procedures (when available)
Correct! The Anaheim project aims to develop procedures for all NTCIP 1202 v03 requirements

A small graphical red and yellow X representing incorrect.c) Connecting to system and see if it works
Incorrect While this might provide some insights as whether the device will work under normal conditions, it will omit major tests

A small graphical red and yellow X representing incorrect.d) Trusting the vendor
Incorrect Trust does not equate to testing

Slide 74:

Summary

Module A315b Part 1

Concepts taught in previous Part 1:

  1. Identify NTCIP 1202 v03 Standard Requirements
  2. Explain the Purpose and Benefits of the RTM
  3. Prepare a Project-Level RTM
  4. Prepare an ASC Specification

Slide 75:

Module Summary

Slide 76:

The ASC Curriculum

A small graphical green and yellow check mark representing correct.MODULE 31. A315a:
Understanding User Needs for Actuated Traffic Signal Controllers (ASC) Based on NTCIP 1202 v03 Standard

A small graphical green and yellow check mark representing correct.Module 32: A315b Part 1:
Specifying Requirements for ASC Based on NTCIP 1202 Standard v03 - Part 1 of 2

A small graphical green and yellow check mark representing correct.Module 42: A315b Part 2:
Specifying Requirements for ASC Based on NTCIP 1202 v03 Standard - Part 2 of 2

Blank graphical placeholder for spacing purposes.Module 35: T315:
Applying Your Test Plan to the NTCIP 1202 v03 ASC Standard

Slide 77:

Next Course Module

Module T315: Applying Your Test Plan to the NTCIP 1202v03 ASC Standard

Concepts taught in next module (Learning Objectives):

  1. Recognize the importance of testing ASCs
  2. Apply the rules for developing a sample ASC test plan
  3. List rules for developing test case specifications and procedures
  4. Develop sample test case specifications and procedures
  5. Understand testing results for NTCIP 1202v03

Slide 78:

Thank you for completing this module.

Feedback

Please use the Feedback link below to provide us with your thoughts and comments about the value of the training.

Thank you!

↑ Return to top