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:
- A Triple Solution includes a Data Profile and a Communications Profile. The solution is applicable to a subset of geopolitical regions.
- A Data Profile defines the necessary ITS information and the high-level rules for exchanging this information with a peer entity, but does not define how the information is transferred to the other entity. This includes definitions of data elements, messages, dialogs and message sequencing, encoding, session management, security as used by the ITS application and management of the ITS application. Consequently a data profile includes standards in the ITS Information Layer and may include standards in the Facilities Layer (e.g., ISO ASN.1), Management Plane (e.g., IETF SNMP ) and Security Plane (e.g. IEEE 1609.2).
- A Communications Profile defines the protocols necessary to define how information is transferred between entities. This includes a complete definition of the SubNet and TransNet Layers, any necessary Facilities Layer protocols (e.g. W3C HTTP), and any necessary Management Plane (e.g. SNMP) and Security Plane (e.g. IETF TLS) standards used by these layers.
- A bundle is a group of related standards that jointly fufills the role of one Layer of the HARTS Communications Reference Model. A bundle is given a single bundle name for ease of reference.
- An alternative is a standard or bundle that, for any given information exchange, only one such alternative shall be used at that layer. Consequently when alternatives are listed there are always at least two.
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:
- Standard: A gap is assigned to a standard if the gap affects every triple solution that references the standard. The gap will be associated with the area of the HARTS Communications Reference Model that the standard has been assigned to.
- Profile: A gap is assigned to a profile if the gap affects every triple solution that references the profile. When defining the gap, the user will identify the area of the HARTS Communications Reference Model where the gap exists.
- Solution: A gap is assigned to a solution if the gap affects every triple solution based on the solution. When defining the gap, the user will identify the area of the HARTS Communications Reference Model where the gap exists.
- Triple Solution: A gap is assigned to a specific triple solution level if the gap is specific to that triple-solution, this is exceptionally rare. When defining the gap, the user will identify the area of the HARTS Communications Reference Model where the gap exists.
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.