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.
(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.
(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:
- 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
)
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 system that it describes
- The stakeholders who have interests in the system
- The concerns stakeholders have
The architecture description is then defined using the following:
- Architecture views, which
- Follow a set of rules as defined in an architecture viewpoint
- Address one or more stakeholder concerns
- Are presented as one or more architecture models that conform to a set of rules defined by the model kind
- Correspondences, which define how elements within one view relate to elements in another view according to a set of rules defined by correspondence rules
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.
(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
(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:
- 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.)
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:
- SubNet Layer: This corresponds to the Physical and Data Link Layers of the Open Systems Interconnect (OSI) Reference Model and defines how data is exchanged between two nodes on a network. The layered architecture typically allows for many alternative implementations at the lower layers, as shown in this example citing the "Field SubNet Alternatives." Clicking on this name will reveal a list of the alternatives, which include the various NTCIP 21xx series options supporting RS-232, FSK modems, dial-up, and Ethernet, as well as another alternative group called the "Internet SubNet Alternatives," which supports an even broader array of technologies.
- TransNet Layer: This corresponds to the Network and Transport Layers of the OSI Reference Model and defines how data is exchanged between a source and destination across a network of nodes. As with the SubNet Layer, there are alternatives here as well; in this case, they include the NTCIP 22xx series, which includes an Internet stack and a "Transportation" stack designed for low-bandwidth environments. In addition, standard "Internet TransNet Alternatives" are also listed as an alternative. All of this becomes visible when the user clicks on the underlined field within the website.
- Facility Layer: This corresponds to the Session, Presentation, and Application Layers of the OSI Reference Model and defines how information is structured and encoded within sessions between a source and a destination. In our example, two standards are shown indicating that they are both required. The first is NTCIP 1202, which is the NTCIP standard that defines signal controller data and dialogs—the dialogs are a part of Facility Layer functionality. The second standard listed is ISO 15784-2, which defines how to use the Simple Network Management Protocol (SNMP) version 3 within ITS. This layer is depicted with a medium gap that identifies the fact that NTCIP 1202 has been developed for SNMPv1 and aspects of it need to be converted to SNMPv3 formats.
- Management Entity: This entity manages the operation and configuration of other areas of the model supports remote configuration of the communication services. In our example, two standards are listed. NTCIP 1201 defines the "global" objects that are required for basic device management while the "Bundle: SNMPv3 MIB" defines numerous objects for the basic management of the communications stack.
- Security Entity: This entity provides security services including authentication and encryption services as required by the other components of the model. Our example references IETF RFC 6353, which is the Transport Layer Security (TLS) for SNMP standard. This standard secures Transport Layer communications, which can include the authentication of each end of a connection and the encryption of data. However, while this can ensure that the two machines are allowed to communicate to each other, it does not authenticate that the applications are allowed to communicate. As a result, if one machine becomes infected with malware, the infection can still be spread over a TLS connection. This is why the Facility Layer needs to support SNMPv3 rather than SNMPv1. The minor gap that is shown is a note to deployers that the ISO 15784-2 standard allows the selection of multiple security mechanisms and the TLS for SNMP needs to be selected.
- Application Entity: This entity defines the semantics of the data to be exchanged and any related functionality of the device, including the use of communication services. In our example, this area shows NTCIP 1202, which defines the data elements for signal controllers.
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.
(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
- Explain system architectures
Provides an overview of the purpose of system architectures and the levels of abstraction used within ITS. - Compare ITS reference architectures
Provides an overview of the major ITS reference architectures and discusses the viewpoints that each of the reference architectures include. - 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. - 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. - 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?
- Deployment architecture
- Planning architecture
- Reference architecture
- Regional architecture
2. Which tool is designed to assist in developing a customized deployment architecture?
- CVRIA
- SET-IT
- RAD-IT
- HARTS
3. Which of the following OSI Layers are not part of the Facility Layer?
- Session Layer
- Application Layer
- Presentation Layer
- Data Link Layer
4. What does a moderately severe issue indicate?
- The issue is expected to be resolved within two years
- The solution is not recommended for be full-scale deployments
- Users should delay their project until the issue is resolved
- The solution does not provide adequate security
5. What types of training are advertised on the ARC-IT website?
- Systems engineering
- Software tools for architecture
- ITS architecture
- All of the above