An icon shown as a green parallelogram representing the Communications View

The Communications View describes the protocols necessary to provide interoperability between Physical Objects in the Physical View. Each triple from the Physical View has been mapped to a set of standards or published specifications that together can be used to build an interoperable implementation. These standards are typically considered in hierarchical fashion, from those that include the data element, message and dialog definitions at the top, to those providing access facilities, networking, transport and physical data exchange at the bottom. Owing to the necessary hierarchical nature of the relationships between most standards, these protocols are organized in a series of layers. Also considered are those standards providing device management and security, which are typically modeled across all communications–centric layers.

XML Communications Stack

A typical triple solution is illustrated as a pair of communications stacks, as shown to the right.

Some solutions include more stacks as intermediary devices are modeled. An intermediary device is a communications device in between the source and destination. Usually these devices (switches, routers, cell towers etc.) are ignored. An intermediary device is only modeled when an understanding of that device is relevant to an ARC-IT stakeholder concern. An example that is commonly modeled is Connected Vehicle Roadside Equipment, which is expected to be installed in public right of way and likely owned and operated by public agencies in the transportation arena. This equipment commonly appears as a source or destination in the physical view, but sometimes is not in the physical view but is included in the communications view when it is used to provide routing solutions for communications between vehicles and backoffice centers. Such a typical 3-stack configuration is shown below.

RSE Gateway Communications Stack

The ARC-IT Communications Model includes dozens of communications profiles that support all links defined in the physical view. These links are commonly abbreviated as n2m, where n and m are one of C (Center or Support), I or F (Field), V (Vehicle), P (Traveler, or Personal). So V2V names the link between vehicles, while C2F names the link between center and field infrastructure. Similarly, the model includes many more data profiles that accommodate the data needs of all associated triples. When combined, a data profile and communications profile provide a solution.

Details behind the development of the communications view and an explanation of the artifacts a reader may find in a diagram are described in the communications viewpoint specification page.