Module 61 - A325

A325: Determining Known Risks with Standards in Your Deployment

HTML of the Student Supplement

(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)

Table of Contents

Module Description - 2

Introduction/Purpose - 2

Overview - 2

Systems Engineering and Architectures - 2

ARC-IT Physical and Communication Views - 5

Glossary - 8

Learning Objectives - 10

References - 10

Study Questions - 10

 

1. Module Description

This module provides an overview of how to use the Architecture Reference for Cooperative and Intelligent Transportation (ARC-IT) to identify the standards that might be needed within an ITS deployment and how to identify the known risks associated with these standards.

 

2. Introduction/Purpose

Intelligent transportation systems and connected vehicles have the potential to improve the safety, sustainability, efficiency, reliability, and comfort of transportation. Deploying these systems in an efficient manner requires proper planning to ensure that interfaces between system components properly address all stakeholder needs in a manner that is consistent with industry norms. Reference architectures can be a useful tool in ensuring that deployments are designed in a manner that is consistent with the industry as a whole.

This module provides an introduction to ITS reference architectures and how ARC-IT and associated tools can be used to manage the risks associated with deploying ITS.

The module starts with an introduction to architectures in general and explains differences among project (a.k.a., deployment), planning (a.k.a. regional), and reference architectures. It then discusses ITS reference architectures in more detail, explaining their purpose and format. The course explains the relationship between the Harmonized Architecture Reference for Technical Standards (HARTS) and ARC-IT. HARTS was intended as a snapshot, in part to see if the major reference architectures could be merged into a single product and experiment on ways to document and publicize the known gaps and overlaps of standards internationally so that the industry can better determine where it can most benefit from working together. Now that the experiment has been completed, the content of HARTS will be merged into and maintained as a part of future versions of ARC-IT. Finally, the course explains how this enhanced communications view can be used by ITS deployment projects to become aware of key issues with standards and how to get involved in addressing them.

By taking this module, participants will learn about the useful resources available for planning their ITS deployments and guiding them through the pitfalls related to their specific project.

 

3. Overview

3.1. Systems Engineering and Architectures

Part of project management is identifying risks to a project as early as possible. Figure 1 provides an overview of the systems engineering project lifecycle according to the standard V diagram and shows that architectures are developed at the beginning of the process making them the perfect location to capture likely risks. As a result, ARC-IT 9.0 will begin to identify the major issues with known standards.

Please see Extended Text Description below.

(Extended Text Description: This figure contains 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.

The standard V diagram is overlaid with 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."

Finally, both the regional and deployment architectures are indicated as being derived from the reference architecture.)

Figure 1: Systems Engineering V Diagram

 

The structure of ARC-IT is the result of decades of work and it conforms to ISO 42010:2011 Systems and software engineering - Architecture description, the major international standard defining how to develop and describe system architectures. The structure defined by this standard is summarized in Figure 2.

Please see Extended Text Description below.

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

)

Figure 2: Conceptual model of an architecture description

 

Figure 2 indicates that every system of interest exhibits an architecture, which can be expressed by an architecture description. An architecture description should identify the following:

The architecture description is then defined using the following:

3.2. ARC-IT Physical and Communication Views

One of the views within ARC-IT is the Physical View, which includes service package diagram models, an example of which is shown in Figure 3. Within this diagram, users can identify specific information transfers, such as the one circled, and hyperlink to the associated Communications View model, including the communication diagrams, as shown in Figure 4. The association between the circled information transfer element in Figure 3 and the communication diagram in Figure 4 is an example of a correspondence, which follows a pair of correspondence rules that state every information transfer is to be associated with a Communication View model for that information transfer and that every information transfer that does not involve a human is to have a communication diagram.

Please see Extended Text Description below.

(Extended Text Description: Author’s relevant notes: This figure 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.)

Figure 3: Sample Service Package Diagram with One Information Transfer Selected

 

Please see Extended Text Description below.

(Extended Text Description: This figure contains a Sample Communications Diagram Showing Gaps with the ITS Station Reference Architecture diagram with the following standards within the various areas of the diagram:

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

Figure 4: Sample Communications Diagram Showing Gaps

 

Each communications diagram (e.g., Figure 4) identifies the standards that define how to implement the information flow (e.g., circled arrow) in the service package diagram (e.g., Figure 3). The communications diagram arranges the standards according to the structure defined in the ITS Station Architecture, which is defined in ISO 21217. The areas of this diagram include the following:

The ARC-IT 9.0 communications diagram identifies all known gaps and overlaps (i.e., issues) with each of the standards associated with a proposed solution for an information transfer. Project managers can link to details for each of these issues and then incorporate this information into the risk management plan for the project to ensure that the risks are properly mitigated. The meaning of each type of gap is shown in Figure 5.

Please see Extended Text Description below.

(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.)

Figure 5: Gap icons

 

4. Glossary

Term Definition
ARC-IT Architecture Reference for Cooperative and Intelligent Transportation, which is the U.S. National ITS reference Architecture. Version 9.0 will enhance the communications view as discussed in this module.
Architecture <System> Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution [ISO 42010:2011].
CVRIA Connected Vehicle Reference Implementation Architecture; a historic reference architecture that was developed to document how connected vehicles would work. Its content has since been incorporated into ARC-IT.
Deployment architecture Architecture that provides a vision of a specific deployment of a system within a geographic area [ISO 14812 (draft)].
FRAME The reference architecture developed by the European Commission.
FRAME-NEXT The current project to update the reference architecture developed by the European Commission.
FSK Frequency Shift Key; a type of modem technology used transmit data over twisted pair copper wire.
Functional object A group of similar system processes from the functional view of the architecture that are jointly assigned to a physical object in the physical view [ISO 14812 (draft)].
Gap An issue that indicates a defined architectural need is not currently fulfilled.
HARTS Harmonized Architecture Reference for Technical Standards; a reference architecture developed to harmonize the reference architectures of Australia, Europe, and the United States and to identify gaps and overlaps within interface standards.
IETF Internet Engineering Task Force; the international standards body that developed many of the well-known protocols used on the Internet, including the Internet Protocol (IP) and Transmission Control Protocol (TCP).
Information flow Information that is exchanged between physical objects.
Information transfer Information flow from a physical object acting as an information provider and sent to another physical object acting as an information consumer.
Issue An item that might need to be addressed by the standards community. Issues include gaps and overlaps.
ITS Station Communications Architecture An arrangement of layers and entities that provides a more holistic view of a communications interface than the OSI reference model provides.
MIB Management Information Base; a text file that formally defines data elements for use with SNMP.
NIA National ITS Architecture; a reference architecture developed for a country. Australia, Canada, and the United States have NIAs, although the United States has recently renamed its NIA to "ARC-IT."
OSI Open Systems Interconnection; an ISO standard (ISO 7498) that defines a common reference model for defining the layers of handling interface communications.
Overlap An issue that indicates that there are two (or more) competing standards (or solutions) to implement an information flow that should perhaps be addressed by the standards community.
Physical object Material entity that interacts with other material entities in the provision of ITS services [ISO 14812 (draft)].
Planning architecture Architecture that provides a long-term vision of system elements that may be deployed and managed by different projects and/or entities within a geographic area.
Project architecture See Deployment Architecture (the term "Project Architecture" is often used within the United States).
RAD-IT Regional Architecture Development for Intelligent Transportation; a tool to assist planners in developing a planning architecture based on ARC-IT.
Reference architecture Architecture that provides a template solution for planning and deployment architectures.
Regional architecture See Planning Architecture (the term "Regional Architecture" is often used within the United States).
RFC Request for Comments; the name that the IETF uses to refer to their completed standards documents.
Service package A portion of an architecture that conveys one or more high-level approaches to providing one interoperable ITS service.
SET-IT Systems Engineering Tool for Intelligent Transportation; a tool to assist engineers in developing a deployment architecture based on ARC-IT.
SNMP Simple Network Management Protocol, an Internet standard for retrieving and storing data in a remote device.
Solution A specific set of standards arranged per the ITS Station Communications Architecture.
TLS Transport Layer Security; an internet standard for authenticating and encrypting data across an TCP/IP link.

 

5. Learning Objectives

  1. Explain system architectures
    Provides an overview of the purpose of system architectures and the levels of abstraction used within ITS.
  2. Compare ITS reference architectures
    Provides an overview of the major ITS reference architectures and discusses the viewpoints that each of the reference architectures include.
  3. Link reference architecture content to standards
    Explains the communications view as used in ARC-IT 9.0 with a focus on the communication diagram, which identifies known issues with standards.
  4. Identify known risks with standards
    Provides an example of the types of issues that exist and how a project might choose to address the identified issues.
  5. Provide recommended resources to learn more about architecture efforts
    Identifies links for the various reference architectures identified as well as training courses and toolsets.

 

6. References

Architecture Reference for Cooperative and Intelligent Transport (ARC-IT), http://local.iteris.com/arc-it/

Harmonized Architecture Reference for Technical Standards (HARTS), http://htg7.org

Connected Vehicle Reference Implementation Architecture (CVRIA), http://local.iteris.com/cvria/

European Framework Architecture (FRAME), https://frame-online.eu

FRAME-NEXT Project, https://frame-next.eu

See style guide on how to document publications/websites, etc.

 

7. Study Questions

1. Which type of architecture provides a solution template that can be customized for each site?

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

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

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

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

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

4. What does a moderately severe issue indicate?

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

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

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

↑ Return to top