Analysis Methodology

HARTS will allow users to identify the required C-ITS standards to implement information flows that are in the public interest. As such, the standards gap analysis is focused on those open-vendor interfaces that promote safety, mobility, and/or sustainability. Data flows that occur internal to a single physical component are not considered to be in the public interest and are not analysed.

To this end, the standards gap analysis focuses on the physical and communication views of the harmonised architecture. The physical view identifies the likely physical components (called subsystems) of C-ITS as well as the information flows that must occur between physical objects to implement ITS services. Each unique combination of a source subsystem, an information flow, and a destination subsystem is a unique "triple". The communication view illustrates the communication protocol stacks used by each triple.

The HARTS Communications Reference Model (right) groups together those layers for which protocols are typically chosen in concert. For example, when one uses Ethernet as the physical medium, this restricts the protocols immediately ‘above’ Ethernet to those that support it. For a more detailed explanation, view the mappings between HARTS and other well known communications models.


The collection of protocols that can be used to implement a given triple is called a solution. A solution may fully satisfy a triple’s requirements, or it may only partially satisfy a triple’s requirements. A partial solution thus has a gap. This gap may be associated with the solution as a whole, with an individual communications protocol layer, ITS information layer, security or management plane, or any combination of these.

A given solution may apply to more than one triple, but may have gaps in one triple but not another, if the triple requirements (such as for data elements, or security concerns) are different. Solutions are also categorized by the geopolitical region in which the solution applies (currently UE, EU, AU and any combination of those regions)

The list of protocols necessary to implement a solution can be lengthy, and include many options, bundles of standards at layers, and alternatives. Consequently the analysis team groups protocols in ways to minimize the number of combinations needed to refer to a given solution. This leads to several constructs that simplify organization and presentation of material:

For further details on how these solutions are organized and displayed, see the solutions page.

In the ideal scenario, the entire world will use a single set of triple solutions for each defined information flow, and these solutions would meet all requirements placed on the flow. In practice, this seldom occurs. There are two broad categories of issues that are documented in HARTS: gaps and overlaps.


If a solution does not meet all requirements of the information flow, it is said to have a gap. For example, if a data profile that is assigned to an information flow fails to include all information required by that information flow, a gap should be identified. Likewise, if a solution fails to provide adequate security, a gap should be identified. The HTG7 Team assigns each gap a severity level of “low”, “moderate”, or “severe”.

Within HARTS, gaps can be assigned to any of the following, as appropriate:

While gaps are associated at these levels within the HARTS database, it should be noted that this is only to ensure consistency in reporting the gap information. One should not infer that a gap associated with a standard must be resolved by an update to that standard; a gap reported at the standard level could be resolved by a separate standard or the emergence of solutions based on new technologies and their associated standards. Recommendations on how to resolve gaps will be made at a future date.

Luckily, many gaps within the C-ITS standards have already been identified by previous gap analyses. The HTG7 Team reviewed each of the identified analyses when reviewing the information flows and attempted to capture all previously identified gaps – while also updating the information to reflect more recent standardisation activities as well as new gaps that the industry has identified since these previous reports have been produced.


In some cases, there are multiple standards that provide different solutions to the same technical problem. When these solutions exist to accommodate different environments, they can be seen as deployment alternatives. For example, there are various communications technologies available for centre-to-field communications; as long as the system designer ensures that the central system and the field device both support the same technology, interoperability is achieved and the various alternatives allow for the best solution to be accommodated.

However, when the system is not centrally designed, either all implementation options must be supported (by at least one side of an exchange) or rules need to be established if full interoperability is to be achieved. For example, a vehicle that only supports an ETSI G5 based solution won’t be able to interoperate in an environment that only supports the ISO CALM M5 standards.

Where undesirable overlaps are identified, HARTS will identify the industry’s current practice for resolving the multiple designs to achieve interoperability (e.g., it will show that BSMs are used in America, while CAM is used in Europe and Australia.  The HARTS website will include this information to assist deployments in design.