Communications

The Communications Viewpoint defines the layered sets of communications protocols that are required to support communications among the Physical Objects that participate in C-ITS. These protocols need to meet the requirements on performance and the constraints imposed by physical connectivity, environmental and operational challenges, and relevant policies (such as the assurance of anonymity for mandatory data provision).

Additionally, protocols used to support management of Physical Object entities and those required to secure communications between objects are also noted. Since the communictions view is centric to HARTS’ mission, this viewpoint is significantly extended from its heritage.

Clicking on an information flow in an ITS service package will bring up a communications diagram like the one shown below, with all fields populated. This is a window into the HARTS communications model, allowing the user to explore the standards (and gaps) associated with satisfying a given flow. This diagram is extensively clickable: all of the standards have various information associated with them, as do the gap icons. As documented under the methodology section, HARTS follows a model consistent with OSI, CALM and CVRIA, though there are obviously parallels to the Internet model.

The HARTS Reference Model is depicted in the figure above. Formal definitions of each component of the HARTS Reference Model are contained in the HARTS Terminology table.

The following list provides a more descriptive mapping of each component to other communication models:

The table below contains a list of symbols used in the Communications View, along with their respective definitions.

ShorthandGap IconDefinition
Overlap Overlap Gap Overlap Gap Overlap Gap The identified information triple has multiple, competing solutions within the region(s). This issue may not prevent a pilot deployment but there is unlikely to be sufficient interoperability to enable proper, full-scale deployment. Implementers will likely need to coordinate with each other to identify how the overlap should be addressed in their pilot deployments.
Ultra Ultra Gap No standard exists.
High High Gap The standard(s) fail to provide even a base level of interoperability and security as recommended for pilot deployments; i.e., the solution either fails to provide:
  • Interoperable data exchange for the triple for typical occurrences of the triple
  • Minimally secure communications as required by the triple
A reasonably secure, interoperable deployment is not possible using only the documents identified by the solution even as a pilot project thus necessitating joint development of additional specifications by implementers.
Medium Medium Gap The identified triple solution may be sufficient for pilot deployments but fails to provide sufficient interoperability, management, and security to enable proper, full-scale deployment. For example, wide-scale interoperable deployment is hindered due to:
  • Competing standards
  • A limited ability to manage remote equipment,
  • Inadequate security for a full-scale deployment,
  • Inability to handle special cases of the information flow,
  • Etc.
Implementers will likely need to coordinate with each other to identify how the issues should be addressed in their deployments and/or to ensure all parties are aware of the limitations of the deployment.
Low Low Gap The identified triple solution may be sufficient for wide-scale deployment, but known issues exist that deployments should consider.
No issues No Issues The identified triple solution is believed to be technically ready for full-scale deployment without any known issues, but complete test suites may not yet exist for the triple solution.