Communications Viewpoint
The Communications Viewpoint provides a framework for identifying the protocols necessary to implement an information flow between Physical Objects (as defined in the Physical View). These protocols need to meet interoperability, performance, functional, security, and environmental requirements, and address operational challenges and relevant policies (such as an assurance of pseudonymity for mandatory data provision).
Stakeholders that take a user role, application or device developer role, tester, maintainer or standards development role will find many of their concerns addressed by the communications viewpoint. The Communications Viewpoint structure enables the engineer to answer questions such as:
- What is the set of communications protocols that provides a complete interface solution that meets mission needs?
- Are there any issues with using a given protocol for a given triple? How serious are those issues?
- If multiple protocols exist to satisfy an interface, how do we choose between them?
- Are there gaps in data usage and definitions, communications functionality, security, or management?
- What protocols address critical system-wide security issues, such as the provision for protection of data confidentiality, protection of message integrity, defense against in-transit manipulation?
- What organizations are responsible for the maintenance of data, communications, security and management standards and specifications?
The ARC-IT Communications Model is based on previous work in the communications arena. Major sources include the Open System Interconnection (OSI) Model, the ITS Station architecture (from ISO 21217), the NTCIP Framework, and the Internet Protocol Suite. Much like some of these other models, the ARC-IT Communications Model groups OSI model layers together. This is done because certain protocols are nearly always deployed with certain pairings. For example the Transmission Control Protocol (TCP) is seldom implemented without Internet Protocol (IP) at the next lowest layer. This is good: it means we can logically group some of these layers together to reflect what is implemented rather than looking at a logical assemblage of individual layers. It keeps the model a little simpler than in previous iterations, which should make it easier to use.
- ITS Application Entity: ITS Application Entity standards specify the structure, meaning, and exchange patterns of information between two end points. Referred to as 'ITS Application Specifications' in some contexts.
- Facilities Layer: Facilities Layer Protocols define the rules and procedures for exchanging data, for representing the bits and bytes of information content to be transferred (e.g. encoding), and provide mechanisms for opening, closing and managing a dialogue between ITS Applications. Sessions may be asynchronous as in paired requests and responses (information exchanges), asynchronous as in an unsolicited publication of information, and may require acknowledgement of receipt or not.
- TransNet Layer: TransNet layer protocols define the rules and procedures for exchanging application data between endpoints as well as the routing, message disassembly/re-assembly and network management functions.
- Access Layer: Access Layer protocols define the rules and procedures for exchanging data between two adjacent devices over some communications media, as well as the signaling protocols that are typically developed for specific communications media.
- Management: Management standards define the rules and procedures for controlling elements at all layers.
- Security: Security standards define the rules and procedures for providing cybersecurity at all layers.
Elements in models that are not typically depicted but are implied by those models are shown in italics with dashed lines. Mappings not shown on the diagram:
- ARC-IT Management maps to the Management Framework associated with the OSI Model, the Management Framework associated with the IETF Internetwork Protocol Suite, and the Management Entity as defined in the ITS Station reference architecture.
- ARC-IT Security maps to the Security Architecture associated with the OSI Model, the Security Architecture associated with the IETF Internetwork Protocol Suite, and the Security Entity as defined in the ITS Station reference architecture.
In all cases, the ARC-IT communications model is focused on the exchange of information between Physical Objects. Thus, entities at both ends of the data exchange must share a common understanding of the communications solution––the collection of standards and specifications that together satisfy the interface. Implementing a given solution means implementing the protocols noted inside the physical object that provides the ITS Application. In many cases there will be other devices in between the endpoints (routers, gateway etc.) that are not the subject of this model.
For ease of development, the ARC-IT Communications Model defines a communications solution as the combination of a data profile and a communications profile. A data profile includes protocols at the ITS Information, Facilities, Management and/or Security layers. A communications profile includes protocols at the TransNet, Access, Management and/or Security layers. Sometimes both profiles in a solution contribute to Management or Security.
Often, the applicability of a solution to a given triple has an issue. Issues come in two types:
- Gaps: a defined architectural need is not fulfilled by the triple solution
- Overlaps: two or more competing standards or solutions exist to implement the triple
Gaps and overlaps are assessed at many levels: standards, profiles, solutions, and the applicability of those artifacts to particular triples (i.e., sometimes a solution is complete for one triple but only partially so for another). Issues are assigned a severity metric that indicates the seriousness of the gap or overlap.
Collectively, these issues are used to assess the viability of a triple solution. Additionally, a triple solution might include alternatives at some parts of the model; in this case, the ARC-IT model defines a default for this layer (e.g., TCP/IP vs. UDP/IP), and calculates the viability of the triple solution based on the default, though the model identifies all issues and makes them accessible for viewing by the user. Triple solution suitability ratings consider legacy, upgrade and new deployments slightly differently:
| Suitability Rating | Description |
|---|---|
| Highest | Suitable for wide-scale deployment when applied to the triples it supports. |
| High | A small number of minor issues. For existing deployments, consider addressing issues as needed as part of maintenance or upgrade activities. For new deployments, the solution is likely suitable for wide-scale deployment when applied to the triples it supports, though the noted issues should be considered and a path to addressing them developed, if needed, either as part of design or subsequent maintenance or upgrade activities. |
| High-Moderate | One significant or possibly a couple minor issues. For existing deployments, the chosen solution likely has identified security or management issues not addressed by the communications solution. Deployers should consider additional security measures, such as communications link and physical security as part of these solutions. They should also review the management issues to see if they are relevant to their deployment and would require mitigation. For new deployments, the deployment efforts should consider a path to addressing these issues as a part of their design activities. The solution does not by itself provide a fully secure implementation without additional work. |
| Moderate | Two significant or one significant and several minor issues. For existing deployments, the chosen solution is likely deficient in security or management capabilities and the issues should be reviewed and upgrades developed as needed. For new deployments, the solution may be viable for pilots when applied to the triples it supports; such pilot deployments should consider a path to addressing these issues as a part of their design activities. The solution does not provide sufficient interoperability, management, and security to enable proper, full-scale deployment without additional work. |
| Moderate-Low | Multiple significant and minor issues. For existing deployments, the chosen solution is likely deficient in security or management capabilities, and the issues should be reviewed and upgrades developed as needed. Some solutions in this category may also be becoming obsolete from an interoperability perspective and if this is the case, then upgrades should be planned as soon as possible. For new deployments, the solution may be viable for pilots when applied to the triples it supports; such pilot deployments should consider a path to addressing these issues as a part of their design activities. The solution does not provide sufficient interoperability, management, and security to enable proper, full-scale deployment without additional work. |
| Low | One serious or several significant issues. This category often includes proprietary or partial solutions. The communications solution may fail to provide even a base level of interoperability and security. Consider alternative solutions or define specific revisions or upgrades that would provide a level of interoperability or security that are needed for the deployment. |
| Lowest | Many serious issues. This category includes solutions that have not been standardized, or do not have a basic level of interoperability or security. Consider selecting a different communications solution or if this is not possible (e.g., a pilot of a new application that has not been standardized), take additional measures to provide an acceptable level of security or interoperability. |
The communications and data profiles reflect likely implementation choices and have been developed and assigned, where applicable, to triples. Other choices might be made in specific instances, which is why ARC-IT's accompanying SET-IT tool provides the systems architect with flexibility to manually adjust the assignment of solutions to triples.