Module 61 - A325

A325: Determining Known Risks with Standards in Your Deployment

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:

Slide 2:

Slide 3:

Module A325:

Determining Known Risks with Standards in Your Deployment

Slide 4:

Instructor

Kenneth Vaughn, P.E.

President

Trevilon LLC

Slide 5:

Learning Objectives

• Explain System Architectures
• Compare ITS Reference Architectures
• Link Reference Architecture Content to Standards
• Identify Known Risks with Standards
• Provide Recommended Resources to Learn More About Architecture Efforts

Slide 6:

Learning Objective 1

• Explain System Architectures

Slide 7:

Explain System Architectures

Overview

• Levels of Architectural Abstraction Used in ITS
  • Reference architectures
  • Regional architectures
  • Deployment architectures
• Purpose of Architectures
  • Document system design
  • Define key interfaces for integration
  • Promote a common marketplace

Slide 8:

Levels of Architectural Abstraction

Three Levels of Abstraction

• Reference architecture
  • Provides overall template solutions
• Regional (a.k.a. planning) architecture
  • Provides long-term vision of what is to be deployed within a geographic region
• Project (a.k.a. deployment) architecture
  • Provides technical details related to a specific project deployment

Slide 9:

Purpose of Architectures

Introduction

When do you want to know about risks on your project?

(Extended Text Description: This slide displays the Systems Engineering "V" 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.)

Slide 10:

Purpose of Architectures

Introduction

(Extended Text Description: This slide displays the same "V" diagram described for Slide 9, but also includes two ovals. The first highlights the first three sections (Regional Architecture(s), Feasibility Study / Concept Exploration, and Concept of Operations) and is labeled "regional architecture". The second highlights the first three sections of the downward V (Concept of Operations, System Requirements, and High-Level Design) and is labeled "deployment architecture." At the top of the "V" diagram is the text, "When do you want to know about risks on your project? As soon as possible!")

Slide 11:

Purpose of Architectures

Introduction

(Extended Text Description: This slide displays the same information as Slide 10 but adds an indication that both of the regional and deployment architectures are derived from the reference architecture.)

Slide 12:

Purpose of Architectures

Document System Design

• Every deployment should be based on an architecture
  • Reference architecture simplifies process
• Purpose of system architecture is similar to that for a building
  • Create a design to address all stakeholder concerns
  • Requires multiple "views" to address different concerns
  • Up front planning and refinements are much cheaper than change orders during construction
• One major concern is:
  • What are the known issues and risks with my project?

Slide 13:

Purpose of Architectures

Define Key Interfaces for Integration

• A system deployment typically involves multiple parties
  • If more than one supplier, products must be integrated
  • Reference architecture supports standardization efforts

Sample "Service Package" diagram

• Collection of physical objects and information flows between them required to deliver a set of inter-related services

(Extended Text Description: Author's relevant notes: Diagram for example only, to show architecture helps designers identify the key components and interfaces required to realize the desired functionality. This slide displays a sample service package diagram with various colored boxes (depicting physical objects) with arrows (depicting information transfers) travelling between them. Inside of the physical objects are white boxes (depicting functional objects that represent internal functionality of the physical object). Each arrow and box is labeled with a name. Finally, the diagram has a name and date.)

Slide 14:

Purpose of Architectures

Promote a Common Marketplace

• A reference architecture promotes a common marketplace
  • Greater interchangeability of components
  • Cost sharing for testing and debugging components
  • Creates a larger pool of experts with a common skillset
  • More competitive pricing

Slide 15:

Slide 16:

Question

Which type of architecture provides a solution template that can be customized for each region or project?

Answer Choices

1. Deployment architecture
2. Planning architecture
3. Reference architecture
4. Regional architecture

Slide 17:

Review of Answers

a) Deployment architecture
Incorrect. A deployment architecture defines the before and after details for a specific deployment project.

b) Planning architecture
Incorrect. A planning architecture defines the long-term plan for the architecture within a specific region.

c) Reference architecture
Correct! A reference architecture is a template solution that can be customized for each site, such as the Architecture Reference for Cooperative and Intelligent Transportation (ARC-IT).

d) Regional architecture
Incorrect. The term "regional architecture" is a synonym for a "planning architecture," and is used mainly within the U.S.

Slide 18:

Learning Objective 2

• Compare ITS Reference Architectures

Slide 19:

Compare ITS Reference Architectures

Overview

• Template Solution for ITS Deployments
• Major ITS Reference Architectures
• Typical ITS Reference Architecture Viewpoints
• Support Tools

Slide 20:

Template Solution for ITS Deployments

• Allows customization to meet local needs
  • Identify specific instances of each component
  • Select services to be included
  • Add additional services as needed
  • Refine security and other details as needed
  • Identify interfaces and interface standards

Slide 21:

Major ITS Reference Architectures

(Extended Text Description: This slide shows the timeline relationships among various reference architectures. The left-hand side shows two independent lines starting; the top is labeled FRAME and the bottom is labeled US NIA. The top (FRAME) line continues straight across the slide and ends with the text FRAME-NEXT. Shortly after the start of this line, an offshoot forms below the FRAME line that is labeled AU NIA (for Australian National ITS Architecture) and then that offshoot line continues across the slide and ends with the text AU NIA 3. Likewise, a little after the AU NIA offshoot forms from FRAME, an offshoot forms from the US NIA line that sits above the US NIA and is labeled CVRIA. This offshoot line then rejoins the US NIA line where it is re-labeled ARC-IT 8.0. Further to the right and near the middle of the diagram is the label HARTS which includes offshoot inputs from the CVRIA, FRAME, and AU NIA lines as well as a new line labeled "Japan Content". From the HARTS nexus, a line is then shown that rejoins with the US NIA/ARC-IT 8.0 line where it is then relabeled ARC-IT 9.0. Finally, a dashed line is shown from AU NIA 3 to ARC-IT 9.0 with a link icon indicating that this line represents an expected hyperlink from the Australian architecture to ARC-IT 9.0.)

ARC-IT = Architecture Reference for Cooperative and Intelligent Transport
AU = Australia
CVRIA = Connected Vehicle Reference Implementation Architecture
FRAME = European Framework Architecture
HARTS = Harmonized Architecture Reference for Technical Standards
NIA = National ITS Architecture
US = United States

Slide 22:

Typical ITS Reference Architecture Viewpoints

(Extended Text Description: This slide shows a UML class diagram based on ISO 42010:2011 that depicts the relationships related to the architecture concept. It shows that:

• A system of interest exhibits an architecture
• An architecture description
  • Expresses an architecture
  • Identifies the system of interest
  • Identifies stakeholders
  • Identifies concerns
• An architecture description aggregates
  • correspondence rules
  • correspondences
  • architecture viewpoints
  • architecture views
• A correspondence rule governs correspondences
• A stakeholder has interests in the system of interest and has concerns
• An architecture viewpoint frames concerns and governs architecture views
• An architecture viewpoint is an aggregation of model kinds
• An architecture view addresses concerns
• A model kind governs architecture models
• An architecture view is an aggregation of architecture models

)

[Source: ISO 42010:2011]

Slide 23:

Typical ITS Reference Architecture Viewpoints

Stakeholder Concerns

• What relationships are needed for the entire lifecycle?
• What functionality needs to be provided?
• What components will fulfill this functionality?
• What interfaces do components need to support?
• What data is produced, and can this data be shared?

Slide 24:

Typical ITS Reference Architecture Viewpoints

ARC-IT Viewpoints

• ARC-IT provides a template solution for ITS
  • "Reference architecture"
• ARC-IT currently provides four views
  • ARC-IT 9.0 will begin adding a fifth view: Information

Architecture Reference for Cooperative and Intelligent Transportation (ARC-IT)

(Extended Text Description: This slide shows a four-layered model representing the four views used by ARC-IT. The top (blue) layer is labeled "Enterprise View" and has a group of people on the left and on the right, there is a diagram with a group of squares with lines connecting them in sequence. Text underneath the diagram says, "Relationships between Organizations."

The next (red) layer is labeled "Functional View" and has two processor chips with ones and zeros flowing back and forth on the left and on the right, there is a diagram of circles with lines connecting them in sequence. Text underneath the diagram says, "Logical interactions between functions."

The next (purple) layer is labeled "Physical View" and has a building connected to a CCTV camera, a traffic signal, and a bus on the left and on the right, there is a diagram of rectangles with lines connecting them in sequence. Text underneath the diagram says, "Connections between physical objects."

The bottom (green) layer is labeled "Communications View" and depicts a Wi-Fi router and a computer monitor displaying the names of various protocols on the left and on the right, there is a diagram of showing two three-layer stacks with a bi-directional dashed line connecting them. Text underneath the diagram says, "Layered protocols facilitating data exchange between physical objects."

The entire four-layered model is captioned at top with the text, "Architecture Reference for Cooperative and Intelligent Transport (ARC-IT).")

Slide 25:

Typical ITS Reference Architecture Viewpoints

	Enterprise	Functional	Physical	Communication	Information
FRAME
US NIA 7
AU NIA
Japan
CVRIA
HARTS
ARC-IT 8
ARC-IT 9

Legend

Fully defined
o Partially defined

Slide 26:

Support Tools

ARC-IT Website

• Template solution for ITS deployments
  • Allows customization to meet local needs
  • Website also hosts other important resources

http://local.iteris.com/arc-it/

Slide 27:

Support Tools

RAD-IT

• Key tool for creating regional (a.k.a. planning) architectures:
  • Detailed vision
  • For a specific geographical region
• Assists users in customizing ARC-IT to their region
• Available from ARC-IT website

Slide 28:

Support Tools

SET-IT

• Key tool for creating systems engineering (a.k.a. deployment) architectures:
  • Allows a more detailed architecture description for a project
  • Identifies items as existing/project/future
  • Defines standards to be deployed for each interface
• SET-IT assists users in building their project architectures
• Available from ARC-IT website

Slide 29:

Slide 30:

Question

Which tool is designed to assist in developing a customized deployment architecture?

Answer Choices

1. CVRIA
2. SET-IT
3. RAD-IT
4. HARTS

Slide 31:

Review of Answers

a) CVRIA
Incorrect. CVRIA is the old US reference architecture for connected vehicles; its content is now in ARC-IT.

b) SET-IT
Correct! SET-IT assists in the development of the systems engineering details of a deployment architecture.

c) RAD-IT
Incorrect. RAD-IT is a tool to assist in developing customized "regional architectures", also known as planning architectures.

d) HARTS
Incorrect. HARTS is an international ITS reference architecture that is being incorporated into ARC-IT 9.0.

Slide 32:

Learning Objective 3

• Link reference architecture content to standards

Slide 33:

Link Reference Architecture Content to Standards

Overview

• Concerns addressed by Communications View
• Elements of the Communications View
• Solution stack
  • Traditional Open Systems Interconnect (OSI) reference model
  • ITS Station architecture
  • Bundles
  • Standards information
  • Gaps

Slide 34:

Link Reference Architecture Content to Standards

Concerns addressed by Communications View

• What is the purpose of the information transfer?
• Where is an information transfer used?
• What are the characteristics of the information transfer?
• What are the security requirements for the information transfer?
• What protocols does my device need to support for interoperability?
• What risks are involved with deploying the solution?

(Extended Text Description: This slide displays the bottom (green) layer of the four-layer ARC-IT view stack. The layer is labeled "Communications View" and depicts a Wi-Fi router and a computer monitor displaying the names of various protocols on the left and on the right, there is a diagram of showing two three-layer stacks with a bi-directional dashed line connecting them. Text underneath the diagram says, "Layered protocols facilitating data exchange between physical objects.")

Slide 35:

Elements of the Communications View

Overview

• Communications View includes several artifacts for each information transfer (a.k.a., "triple")
  • Definition
  • Correspondence links showing where the transfer is used
  • Characteristics of the information transfer
  • Security analysis for the transfer
  • Communication diagrams

Information transfer defined by

• Source
• Destination
• Information flow

Connected Vehicle Roadside Equipment → Vehicle OBE: intersection status

Link Type: Short Range Wireless

Slide 36:

Elements of the Communications View

Definition

• Addresses purpose of information transfer by defining:
  • The information flow contained in the transfer
  • The physical object that is the source of the information transfer
  • The physical object that is the destination of the information transfer

Definitions

Intersection status (Information Flow): Current signal phase and timing information for all lanes at a signalized intersection. This flow identifies active lanes and lanes that are being stopped and specifies the length of time that the current state will persist for each lane. It also identifies signal priority and preemption status and pedestrian crossing status information where applicable.

Connected Vehicle Roadside Equipment (Source Physical Object): 'Connected Vehicle Roadside Equipment' (CV RSE) represents the Connected Vehicle roadside devices that are used to send messages lo, and receive messages from, nearby vehicles using Dedicated Short Range Communications (DSRC) or other alternative wireless communications technologies. Communications with adjacent field equipment and back office centers that monitor and control the RSE are also supported. This device operates from a fixed position and may be permanently deployed or a portable device that is located temporarily in the vicinity of a traffic incident, road construction, or a special event. It includes a processor, data storage, and communications capabilities that support secure communications with passing vehicles, other field equipment, and centers.

Vehicle OBE (Destination Physical Object): The Vehicle On-Board Equipment (OBE) provides the vehicle-based sensory, processing, storage, and communications functions that support efficient, safe, and convenient travel. The Vehicle OBE includes

Slide 37:

Elements of the Communications View

Included In: (a.k.a., Correspondences)

• Identifies where the information transfer is used:
  • In service packages

(Extended Text Description: Author's relevant notes: This slide shows the part of the "Included In" tab that lists the service packages where the "Connected Vehicle Roadside Equipment → Vehicle OBE: intersection status" information transfer (a.k.a. "triple") is used. The second item in this list is "TM04: Connected Vehicle Traffic Signal System." An arrow extends from this item to the right and points to the service package diagram for the "Connected Vehicle Traffic Signal System" to indicate that the item in the list is a hyperlink to the service package diagram.)

Slide 38:

Elements of the Communications View

Included In: (a.k.a., Correspondences)

• Identifies where the information transfer is used:
  • In service packages
  • In functional objects

(Extended Text Description: Author's relevant notes: This slide shows the part of the "Included In" tab that lists the functional objects that are associated with the "Connected Vehicle Roadside Equipment → Vehicle OBE: intersection status" information transfer (a.k.a. "triple"). To the right of this list is part of the service package diagram for the "Connected Vehicle Traffic Signal System" that highlights the "intersection status" information flow as well as the source ("RSE Intersection Management") and destination ("Vehicle Intersection Warning") functional objects. These same two functional objects are highlighted in the list from the website as shown on the left. An arrow extends from the "Vehicle Intersection Warning" functional object text in the list, which happens to be at the bottom of the list, down to a partial screen shot of the definition of the functional object to demonstrate that the list item is a hyperlink to its definition.)

Slide 39:

Elements of the Communications View

Included In: (a.k.a., Correspondences)

• Identifies where the information transfer is used:
  • In service packages
  • In functional objects
  • In data flows

(Extended Text Description: Author's relevant notes: This slide shows the part of the "Included In" tab that lists the data flows from the Functional View that further describe the data contained within the "Connected Vehicle Roadside Equipment → Vehicle OBE: intersection status" information transfer (a.k.a. "triple"). The second to last item in this list is "signal_phase_timing_to_vehicle." An arrow extends from this item to the right and points to the definition for this flow to indicate that the item in the list is a hyperlink to the service package diagram.)

Slide 40:

Elements of the Communications View

Characteristics

• Every information transfer is characterized to determine appropriate communication technologies

Characteristics

Characteristic	Value
Time Context	Recent
Spatial Context	Adjacent
Acknowledgement	False
Cardinality	Broadcast
Initiator	Source
Authenticate	True
Encrypt	False

Slide 41:

Elements of the Communications View

Security

• Confidentiality, Integrity, and Availability (CIA) analysis provided with justification

Security

Information Flow Security
	Confidentiality	Integrity	Availability
Rating	Not Applicable	Moderate	Moderate
Basis	This data is intended for all vehicles in the immediate area of the sender.	If this is compromised, the Vehicle OBE will receive messages that are inconsistent with what the traffic signals are displaying. This could lead to confusion and reduce the ability of the application to provide value.	If this is down, the Vehicle OBE doesn't get the information it needs to stay in synch with the actual signal state, reducing or eliminating the value add from having this application. We assume that the Vehicle OBE will detect a lack of availability and choose not to send out-of-date information, so a failure of availability cannot have worse consequences than a failure of integrity which we have previously assessed at MEDIUM.

Security Characteristics	Value
Authenticable	True
Encrypt	False

Slide 42:

Elements of the Communications View

Communication diagrams

• ARC-IT 8.3
  • Based on ISO 7498 Open Systems Interconnection (OSI) -Basic Reference Model
  • Adds an application information layer
  • Adds a security plane

(Extended Text Description: This slide shows the communications diagram for the "Connected Vehicle Roadside Equipment → Vehicle OBE: intersection status" information transfer as currently provided in ARC-IT 8.3. This diagram depicts a box that encompasses two communication stacks next to each other with security plane boxes between them. The top of the encapsulating box is labeled "DSRC-WSMP" with "intersection status →" underneath this title. Each stack is then labeled with a colored heading. On the left, the heading is "Connected Vehicle Roadside Equipment" with an orange background and the right is labeled "Vehicle OBE" on a blue background; the colors correspond to the physical object colors, thereby indicating that the Connected Vehicle Roadside Equipment is a field device whereas the Vehicle OBE is a Vehicle device.

The stacks presented underneath each device heading are identical. The stacks start with an "ITS Application Information Layer", which are shown to be "ISO 19091 and SAE J2735". Underneath this layer the remaining layers correspond to those defined by the ISO Open Systems Interconnection (OSI) Reference Model. In each stack, the:

• Application Layer is "Undefined"
• Presentation Layer is "ISO/IEC 8825-2 ASN.1 PER"
• Session Layer is "Undefined"
• Transport Layer is "IEEE 1609.3"
• Network Layer is "IEEE 1609.3"
• Data Link Layer is "IEEE 1609.4, IEEE 802.11"
• Physical Layer is "IEEE 802.11"

Between the two stacks at the Presentation, Application, and ITS Application Information Layers is a "Security Plane" box showing "IEEE 1609.2." Between the two stacks at the Physical, Data Link, Network, Transport, and Session Layers is a "Security Plane" box showing "Undefined."

After the first click, a yellow highlight box, labeled "OSI Reference Model," is drawn around the OSI Reference Model portion of the right-side stack, including just the lower seven layers. After the second click, a yellow highlight box, labeled "ITS Application Information Layer," is drawn around the ITS Application Information Layer. Finally, after the third click, a yellow highlight box, labeled "Security Plane," is drawn around the two security plane boxes that are sandwiched between the two stacks.)

Slide 43:

Elements of the Communications View

Communication diagrams

• ARC-IT 9.0 (HARTS)
  • Based on ISO 21217 ITS Station Communication Architecture
  • Simplifies OSI Model
  • Includes Security and Application "entities"
  • Adds a Management entity

(Extended Text Description: This slide slowly reveals the ITS Station Communications Architecture as an overlay to the OSI Reference Model. First the OSI Reference Model is shown with its seven layers (listed from the bottom): Physical, Data Link, Network, Transport, Session, Presentation, and Application. Then a dark aqua box, labeled "Access," is overlaid onto the Physical and Data Link Layers. Then a medium aqua box, labeled "TransNet," is overlaid onto the Network and Transport Layers. Then a light aqua box, labeled "Facility" is overlaid onto the Session, Presentation, and Application Layers. Next, a pink box for the Security entity is shown to the right of the OSI Reference Model spanning all seven layers and a purple box, labeled "Application Entity," is shown at top spanning over the Security Entity and the OSI Reference Model layers as well as over an area to the left of the OSI Reference Model. Finally, the area to the left of the OSI Reference Model and underneath the Application Entity is filled in with a cyan box that is labeled "Management.")

Slide 44:

Elements of the Communications View

Communication diagrams

• ARC-IT 9.0 (HARTS)
  • Identifies standards for each area

(Extended Text Description: This slide shows the ITS Station Communications Architecture consisting of the Access, TransNet, and Facility Layers as well as the Security, Application, and Management Entities along with relevant standards/bundles corresponding to each area of the diagram for the "Connected Vehicle Roadside Equipment → Vehicle OBE: intersection status" information transfer, as follows:

• Access: "Bundle: WAVE – Subnet"
• TransNet: "IEEE 1609.3"
• Facility: "SAE J2375" and "SAE J2945/A"
• Security: "Bundle: IEEE 1609.2"
• Application Entity: "SAE J2735", "CEN ISO 19091", and "SAE J2945/A"
• Management: "No Standard Needed"

Next to each standard/bundle is an information icon represented by a black italicized letter "i" on a white circular background with a black border.)

Slide 45:

Elements of the Communications View

Communication diagrams

• ARC-IT 9.0 (HARTS)
  • Identifies standards for each area
  • Information icons provide additional details about each standard

(Extended Text Description: This slide shows the same image as on the previous slide, but it has an overlay showing the results of clicking on the information icon for SAE J2375. This consists of a popup box with a green border on top and bottom and information about the standard within the body of the popup, which has a white background. the information includes the document number, the version, the full name of the document, a link to the document's official website with more information, and a brief description of the document.)

Slide 46:

Elements of the Communications View

Communication diagrams

• ARC-IT 9.0 (HARTS)
  • Identifies standards for each area
  • Information icons provide additional details about each standard
  • Introduces "Bundles" - clicking on hyperlink exposes contents
    • Required items
    • Optional items
    • Alternative items

(Extended Text Description: This slide shows the same image as Slide 44 with the ITS Station Communications Architecture stack for the "Connected Vehicle Roadside Equipment → Vehicle OBE: intersection status" information transfer, except the hyperlink on the bundle in the Access Layer has been selected resulting in the contents of that box to change. The Access Layer is now labeled "Access – Bundle: WAVE – Subnet" and the contents include:

• IEEE 802.11 (Required)
• IEEE 1609.4 (Required)
• ISO/IEC 8802-2 (Required)

Each of these standards have the same information icon next to them as used elsewhere on the diagram.)

Slide 47:

Elements of the Communications View

Communication diagrams

• ARC-IT 9.0 (HARTS)
  • Identifies issues with solution
    • Gaps
    • Overlaps

Issues equate to risks for a project

(Extended Text Description: This slide starts by showing the same image as Slide 44 with the ITS Station Communications Architecture stack for the "Connected Vehicle Roadside Equipment → Vehicle OBE: intersection status" information transfer. After the first click, it shows gap icons in various portions of the model as follows:

• The Application Entity has two moderate and one low severity gap icons shown in the upper left. The moderate gap icon is a white triangle with a yellow border with the word "Gap" inside. The low severity gap icon is a white circle with a blue border with the word "Gap" inside.
• The Security Entity has two moderate severity gap icons in its upper left.
• The Facility Layer has a low severity gap icon in its upper left.

After the second click, a moderately severe overlap icon is shown in the upper left of the Access Layer. The moderately severe overlap icon is a transparent triangle with a yellow border with the letters "Ol" in a black rectangle overlapping a white rectangle containing the letters "ap."

After the third click, the figure is overlaid with gray box containing information about the overlap identified in the Access Layer. the information includes identification that it is a Subnet Gap and an image of the moderately severe overlap icon. It then identifies the name, gap notes, type, severity, and description of the selected issue.)

Slide 48:

Elements of the Communications View

Communication diagrams

• ARC-IT 9.0 (HARTS)
  • Identifies all known potential solutions
  • Solutions with fewest issues on top

(Extended Text Description: This slide shows the solutions and the description for the currently selected solution for the "Connected Vehicle Roadside Equipment → Vehicle OBE: intersection status" information transfer, per HARTS. It shows three solutions:

• EU: Signal Control Messages – BTP/GeoNetworking/G5
• US: SAE Signal Control Messages – WAVE WSMP
• US: SAE Other J2735 – C-V2X WSMP

The "US: SAE Signal Control Messages – WAVE WSMP" is selected with an orange highlight.)

Solution Description

This solution is used within the U.S. It combines standards associated with US: SAE Signal Control Messages with those for V-X: WAVE WSMP. The US: SAE Signal Control Messages standards include upper-layer standards required to implement signal control information flows. The V-X: WAVE WSMP standards include lower-layer standards that support connectionless, near constant, ultra-low latency vehicle-to-any communications within ~300m using the WAVE Short Messaging Protocol (WSMP) over IEEE WAVE in the 5,9QHz spectrum. The broadcast mode is interoperable with M5 FNTP.

Slide 49:

Reference Architecture Content to Standards Summary

(Extended Text Description: This slide displays the bottom (green) layer of the four-layer ARC-IT view stack. The layer is labeled "Communications View" and depicts a Wi-Fi router and a computer monitor displaying the names of various protocols on the left and on the right, there is a diagram of showing two three-layer stacks with a bi-directional dashed line connecting them. Text underneath the diagram says, "Layered protocols facilitating data exchange between physical objects.")

Concerns addressed by Communications View

• What is the purpose of the information transfer?
  • Definition
• Where is an information transfer used?
  • Included in
• What are the characteristics of the information transfer?
  • Characteristics
• What are the security requirements for the information transfer?
  • Security
• What protocols does my device need to support for interoperability?
• What risks are involved with deploying the solution?
  • Shown on ITS Station architecture model

Slide 50:

Slide 51:

Question

Which of the following OSI Layers are not part of the Facility Layer?

Answer Choices

1. Session Layer
2. Application Layer
3. Presentation Layer
4. Data Link Layer

Slide 52:

Review of Answers

a) Session Layer
Incorrect. The Session Layer is a part of the Facility Layer.

b) Application Layer
Incorrect. The Application Layer is a part of the Facility Layer.

c) Presentation Layer
Incorrect. The Presentation Layer is a part of the Facility Layer.

d) Data Link Layer
Correct! The OSI Data Link Layer is contained within the Access Layer of the ITS Station Architecture.

Slide 53:

Learning Objective 4

• Identify known risks with standards

Slide 54:

Identify Known Risks with Standards

Overview

• Identify issue severities
• List types of issues
• Describe practical example
• Describe how to provide feedback
• Explain how standards developers can use information

Slide 55:

Identify Known Risks with Standards

Identify issue severities

(Extended Text Description: Author's relevant notes: This slide includes a table with embedded graphics/icons; the first column shows gap icons, the second column shows overlap icons, the third column indicates the severity level, and the fourth column provides a description. The rows of the table from top to bottom represent low, moderate, high, and ultra severity. The icons for low severity are blue circles; the gap icon includes the text "gap" and the overlap icon includes the letters "ol" in a black box overlapping a white box that has the letters "ap".

The icons for moderate severity are yellow triangles; the gap icon includes the text "Gap" and the overlap icon includes the letters "Ol" in a black box overlapping a white box that has the letters "ap".

The icons for high severity are red octagons; the gap icon includes the text "GAP" and the overlap icon includes the letters "OL" in a black box overlapping a white box that has the letters "AP".

The icon for ultra severity gap is a red circle with a horizontal white rectangle (e.g., a "no entry" sign) with the text "GAP" inside of the white rectangle. There is no ultra severe overlap icon.)

Issue severity rankings are somewhat subjective and "recommendations" are theoretical; agencies have to weight competing demands to determine what might be appropriate to deploy.

Slide 56:

Known Risks with Standards

Sample Issues - Ultra Severity

• Standardization has not started
• Data or messages not defined
• Performance/functionality requirements not defined
• Use case not considered in design

Slide 57:

Known Risks with Standards

Sample Issues - High Severity

• Standard exists or is under development, but major problem(s) exist
  • Data or messages not defined
  • Performance/functionality requirements not defined
  • Use case not considered in design
  • Inadequate guidance for complex data
  • Security not provided
  • Data/communications profile pairing
  • Draft not available

Slide 58:

Known Risks with Standards

Sample Issues - Moderate Severity

• Standard exists but noteworthy problems are known
  • Data or messages not fully defined
  • Performance/functionality requirements not fully defined
  • Use case not fully considered in design
  • Inadequate security
  • Data formatting issues
  • Not defined in an open, vetted standard
  • Overlap of standards

Slide 59:

Known Risks with Standards

Sample Issues - Low Severity

• Projects should consider known issues
  • Implementations may not implement optional features in a consistent manner
  • Data accuracy issues may cause problems if not addressed in specifications
  • A specific security option within the standard must be required in project specifications
  • Standard is under revision
  • Relatively new standard

Slide 60:

Known Risks with Standards Example

Practical Example

• Select the service package of interest: Transit Signal Priority
  • Provide priority to transit vehicles that are behind schedule
  • Onboard logic determines when to request priority

(Extended Text Description: This slide includes the following table:

Public Transportation	PT01	Transit Vehicle Tracking
	PT02	Transit Fixed-Route Operations
	PT03	Dynamic Transit Operations
	PT04	Transit Fare Collection Management
	PT05	Transit Security
	PT06	Transit Fleet Management
	PT07	Transit Passenger Counting
	PT08	Transit Traveler Information
	PT09	Transit Signal Priority
	PT10	Intermittent Bus Lanes
	PT11	Transit Pedestrian Indication

Additionally, the ninth item (PT09 "Transit Signal Priority") is circled with an oval.)

Slide 61:

Known Risks with Standards Example

Practical Example

• Select the information transfer of interest

(Extended Text Description: Author's relevant notes: This slide shows the "Transit Signal Priority" service package diagram. It contains physical objects for Traffic Management Center, Transit Management Center, Transit Operations Personnel, ITS Roadway Equipment, Connected Vehicle Roadside Equipment, Transit Vehicle OBE, and Transit Vehicle Operator. with several information transfers flowing between these physical objects. The "ITS Roadway Equipment → Connected Vehicle Roadside Equipment: intersection control status" information transfer is circled with an oval.)

Slide 62:

Known Risks with Standards Example

Practical Example

• Select the communications diagram

Slide 63:

Known Risks with Standards Example

Practical Example

(Extended Text Description: Author's relevant notes: This slide shows a portion of the HARTS communications diagram for the "ITS Roadway Equipment → Connected Vehicle Roadside Equipment: intersection control status" information transfer. It includes a listing of 6 potential solutions with "US: NTCIP Traffic Signal – SNMPv3" highlighted. The slide also has the ITS Station Reference Architecture diagram with the following standards within the various areas of the diagram:

• Access: "Field SubNet Alternatives"
• TransNet: "Field TransNet Alternatives"
• Facility: "NTCIP 1202" and "ISO 15784-2"; the latter is annotated indicating that it represents SNMPv3
• Security: "IETF RFC 6353", which is annotated indicating that it represents "TLS for SNMP"
• Application Entity: "NTCIP 1202"
• Management: "NTCIP 1201" and "Bundle: SNMPv3 MIB"

There is a moderate gap shown for the Facility Layer and a minor gap shown for the Security Entity.)

Slide 64:

Known Risks with Standards Example

Practical Example

• Identify list of potential solutions for your given region, four possibilities:
  • Multiple solutions for your region
  • Single solution for your region
  • No solutions or "None-Data" for your region
  • Interface labeled as "Out-of-Scope"

Slide 65:

Known Risks with Standards Example

Practical Example

• Multiple solutions for your region
  • Consider each solution and compare the issues for each
  • Make a selection for your project
  • Develop a mitigation plan for the risks associated with the issues

(Extended Text Description: This slide includes a listing of the solutions associated with the United States flag from the "Communications Diagram" page. The solutions include:

• US: NTCIP Traffic Signal – SNMPv3
• US: NTCIP Traffic Signal – SNMPv1/TLS
• US: NTCIP Traffic Signal – SNMPv1

)

(Extended Text Description: At the bottom of the slide, a table is shown with embedded graphical icons, one row for each of these solutions that summarize the gap information for each of the solutions. The SNMPv3 row shows a moderate and low severity gap. The SNMPv1/TLS row shows two moderate and one severe gap. The SNMPv1 row shows two severe gaps. SNMPv3 Issue Summary cell has the text, NTCIP 1202 data is designed for SNMPv1; Should couple SNMPv3 with TLS. SNMPv1/TLS Issue Summary cell has the text, Application-level security is not provided; Use of TLS not vetted by industry with SNMPv1; SNMPv1 not allowed by RSU specification. SNMPv1 Issue Summary cell has the text, Does not provide any security; SNMPv1 not allowed by the RSU specification.)

Slide 66:

Known Risks with Standards Example

Practical Example

• Practical considerations
  • Best solution has a moderate gap; products may not exist
  • Some solution is needed to communicate with traffic signals
  • ARC-IT presents options; agencies are responsible for deciding what should be deployed

Slide 67:

Known Risks with Standards Example

Practical Example

• Single solution for your region
  • Typically, select the solution and note the issues

Triple

Vehicle OBE to Transportation Information Center: vehicle situation data Flow Description

This flow represents vehicle snapshots that may be provided by the vehicle to support traffic and environmental conditions monitoring, Snapshots are collected by the vehicle for specific events (e.g., when a sensor exceeds a threshold) or periodically and reported based on control parameters when communications is available. Traffic-related data includes snapshots of measured speed and heading and events including starts and stops, speed changes, and other vehicle control events. Environmental data may include measured air temperature, exterior light status, wiper status, sun sensor status, rain sensor status, traction control status, anti-lock brake status, and other collected vehicle system status and sensor information. The collected data is reported along with the location, heading, and time that the data was collected.

Slide 68:

Known Risks with Standards Example

Practical Example

• No solutions for your region, or "None-Data"
  • Typically occurs in flows that are not in common usage today
  • Consider if flow is really needed for your project
  • Consider if solutions used by other regions might be appropriate or if they could be tailored for use

Triple

Alternate Mode Transportation Center to Traffic Management Center: alternate mode incident information Flow Description

Details of accidents and other service disruptions that have occurred in an alternative mode. This information supports assessment of their impact upon the road network.

Solutions

Solution Description

This solution is used within the European Union. It combines standards associated with EU: DATEX with those for C-C: DATEX Messaging TCP, The EU: DATEX standards include upper-layer standards required to exchange and share data and information in the field of traffic and travel. The C-C: DATEX Messaging TCP standards include lower-layer standards that support partially secure communications between two centers as commonly used in Europe.

Slide 69:

Known Risks with Standards Example

Practical Example

• Shown as "Out-of-Scope"
  • Typically indicates an information transfer not subject to ITS standards
    • Payment request to Financial Center
  • Work with external service provider to identify appropriate standards

Triple

Transit Management Center to Financial Center: payment request Flow Description

Request tor payment tram financial institution or related financial service requests (e.g., balance inquiry}

Solutions

Solution Description

This solution is used within the U.S., E.U., and Australia, It combines standards associated with (Out of Scope) with those for [Out of Scope]. The (Out of Scope) standards include a set of upper layer standards that are outside the scope of the HTG7 analysis process. The [Out of Scope] standards include a set of lower layer standards that are outside the scope of the HTG7 analysis process.

Slide 70:

Provide Feedback

Provide Feedback

• Issue content in ARC-IT reflects composite industry knowledge
• Comments are welcome
  • Requests for clarification
  • Requests for additional solutions
  • Requests for alternative architectural designs
  • Requests to remove issues that have been resolved
  • Identification of issues not shown

Slide 71:

Provide Feedback

Provide Feedback

• Issue content in ARC-IT is provided "as-is"
• The ARC-IT team welcomes feedback

(Extended Text Description: Author's relevant notes: This slide shows the "Contact the Architecture Team" page of the ARC-IT website. It shows the title of the page along with a request for input and includes the following fields for the user to fill out along with "Submit" and "Reset" buttons:

• Name
• Organization
• E-mail
• Comment

)

Slide 72:

Provide Feedback

Provide Feedback

• Comments are handled in a maintenance cycle
  • Evaluation
  • Assignment to a release
  • Response
  • Implementation
  • Release

Slide 73:

Standards Developer Perspective

Standards Developer Perspective

• Issues in ARC-IT also serves as a resource for the standards development community
  • Comments from users help
    • Improve the list of known issues
    • Provide real-world feedback
  • Database used to prioritize issues to be addressed
• By working with the ARC-IT team, standards developers can ensure that information about their standards are maintained up-to-date

Slide 74:

Slide 75:

Question

What does a moderately severe issue indicate? Answer Choices

1. The issue is expected to be resolved within two years
2. The solution is not recommended for full-scale deployments
3. Users should delay their project until the issue is resolved
4. The solution does not provide adequate security

Slide 76:

Review of Answers

a) The issue is expected to be resolved within two years
Incorrect. ARC-IT does not attempt to estimate when issues will be resolved.

b) The solution is not recommended for full-scale deployments
Correct! While agencies may use the solution in their projects, full-scale deployments are likely to encounter expensive upgrade efforts once the issue is resolved.

c) Users should delay their project until the issue is resolved
Incorrect. Agencies must consider their own competing demands and determine if the risk is worth deployment.

d) The solution does not provide adequate security
Incorrect. While "not providing adequate security" is a moderate gap, there are other types of moderate gaps as well.

Slide 77:

Learning Objective

• Provide Recommended Resources to Learn More

Slide 78:

Recommended Resources

Overview

• Links to architectures
• Links to architecture courses
• Links to toolsets

Slide 79:

Recommended Website Resources

Architecture Websites

(Extended Text Description: Author's relevant notes: This slide includes a table with embedded graphics/icons with the columns Applicability, Architecture, and Link, where each row is a reference to one of the architectures discussed during this module. ARC-IT 9.0 and HARTS are associated with flag icons for Australia, the EU, the US, and Japan. ARC-IT 8.3 and CVRIA are associated with flag icons for the US. FRAME and FRAME-NEXT are associated with the flag icon for the EU. The Australia NIA is associated with the flag icon for Australia. The link for ARC-IT 9.0 and 8.3 is http://local.iteris.com/cvria/. The link for CVRIA is http://local.iteris.com/cvria/. The link for FRAME-NEXT is https://frame-next.eu. The link for FRAME is https://frame-online.eu. The link for Australia NIA is https://austroads.com.au. the link for HARTS is http://htg7.org.)

Slide 80:

Recommended Course Resources

Architecture Courses

(Extended Text Description: This slide shows icons from the "Training Courses and Workshops" page of the ARC-IT website. It shows a figure of the menu drop-down where you can access the information on the left and then three images from the site from top to bottom as follows:

• A humanoid figure laying down on its stomach and interacting with a laptop, labeled "web-based training"
• A humanoid figure standing next to and pointing at an easel displaying a Physical View diagram, labeled "on-site training"
• A humanoid figure standing in front of an audience and next to an easel displaying a Physical View diagram, labeled "workshops"

)

Available in three topic areas

• ITS architecture
• Software tools
• Systems engineering

Slide 81:

Recommended Resources

Toolsets

(Extended Text Description: This slide shows the "Architecture Resources" pull down menu from the ARC-IT website with the options ARC-IT Website Download, Database, Documents, Tools - RAD-IT, SET-IT (RAD-IT and SET-IT are circled in red), Training and Workshops, and Presentations. To the right is a diagram from the "Tools" page that shows the left-hand side of the Systems Engineering V diagram (as explained on Slide 9), which has the first three sections of the figure ("Regional Architecture", "Feasibility Study / Concept Exploration", and "Concept of Operations") encircled in red and labeled "RAD-IT Scope" and the first three sections of the downward "V" ("Concept of Operations", "System Requirements", and "High-Level Design") labeled "SET-IT Scope".)

Slide 82:

Slide 83:

Question

What types of training are advertised on the ARC-IT website?

Answer Choices

1. Systems engineering
2. Software tools for architecture
3. ITS architecture
4. All of the above

Slide 84:

Review of Answers

a) Systems engineering
Incorrect. Software tools and ITS architecture training are also available.

b) Software tools for architecture
Incorrect. Systems engineering and ITS architecture training are also available.

c) ITS architecture
Incorrect. Systems engineering and Software tools training are also available.

d) All of the above
Correct! All three types of training are advertised.

Slide 85:

Module Summary

• Explain System Architectures
• Compare ITS Reference Architectures
• Link Reference Architecture Content to Standards
• Identify Known Risks with Standards
• Provide Recommended Resources to Learn More About Architecture Efforts

Slide 86:

We Have Now Completed the Curriculum for Determining Risks in Deployments

Module 1. I101:
Using ITS Standards: An Overview

Module A325:
Determining Known Risks with Standards in Your Deployment

Slide 87:

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