All the policies defined in Section 5.3.1 continue to apply. In addition, the system should comply with the following policies:

• new rules should be distributed electronically prior to (e.g., in an inactive state) or simultaneously with their activation

All the constraints defined in Section 5.3.2 continue to apply. No new constraints have been defined.

This section provides a vision for the operational concept of METR by assigning responsibilities to specific roles and explaining how the various roles interact to achieve the end result. It is expected that this information will eventually be fed into the development of the Architecture Reference for Cooperative and Intelligent Transportation (ARC-IT) where a formal architecture for METR services will be provided, including multiple views, such as enterprise, functional, physical, and communication.

Figure 4 provides an overview of how METR is envisioned to provide users with trustworthy, authoritative information. It should be noted that there may be multiple instances of each role. For example, for a given location, there may be multiple rule-makers, multiple installers, multiple users, etc. The specific number of instances will be specific for each deployment location. 

The lighter coloured boxes in the figure indicate roles that are considered to be a part of the METR network; the gray boxes represent roles that are considered to be a part of the more general METR environment; the black box indicates environmental factors, which are monitored by roles but is not a role itself.

Roles within the METR network are defined in greater detail and are within the system boundary, as further defined in other parts of the ISO 24315 series. Roles that are part of the METR environment but outside the METR boundary provide an overall context of how end user needs are fulfilled. For interoperability, requirements and communication interfaces will need to be standardized at the boundaries between the METR network and the more general METR environment and at any likely physical boundaries that might exist between components of the METR network (e.g., between the disseminator and the receiver).

Each role within the METR environment is responsible for the following:

• non-repudiation of historic transaction status, including rule creation, modification, deletion, publication, transfer, exchange, or provision

• protecting the privacy of METR users

• contributing to the overall trustworthiness of the environment

Each role within the METR network is responsible for the following:

• sharing rules with peer entities, as appropriate, to promote data consistency and accuracy

• performing consistency checks on rules

• Correcting each detected conflict/inconsistency, when possible

• Reporting inconsistencies to appropriate parties, when the component is unable to correct the inconsistency.

The rules defined in Section 5.4.2 are not intended to change in the proposed system, but they are translated into an electronic, machine-readable format for delivery. To minimize translation problems, rule-makers should consider the standardized formats for electronic exchange while developing the rules.

The rule-maker is essentially the same role as defined in 5.4.3 with the additional responsibilities of:

—     making all its pre-announced rules available to appropriate authorized parties (e.g., translators, certifiers); this can be minimally satisfied by making rules available through a written public record (i.e., non-electronic)

—     coordinating with the certifier and translator to resolve any inconsistencies or conflicts

—     publicising the ad-hoc rule categories that the jurisdictional entity claims to support for the area

—     for all ad-hoc rule and supplemental data categories supported within an area, ensuring that appropriate data is available to users in real-time.

—     Coordinating the transition of its ad-hoc rules into pre-announced rules, when necessary.

Rule-makers are responsible for making their rules publicly available. A jurisdictional entity might authorize multiple rule-makers within its jurisdiction; generally, these rule-makers will be assigned responsibility for different rule categories. If multiple rule-makers are assigned the same rule category, they will need to coordinate with each other to avoid conflicts, gaps, and overlaps of rules.

A location will often be subject to multiple jurisdictional entities (e.g., a national and a city government and a private campus owner) with each jurisdictional entity potentially authorising multiple rule-makers. When making rules, lower-level rule-makers are generally responsible for ensuring that their rules do not conflict with the rules established by higher-level rule-makers.

While the rule-maker is responsible for making its rules available, it should be noted that some users might not be interested in all rules. For example, a translator that focuses on motor vehicle rules and would not need all micromobility rules.

Pre-announced rules can be implemented by translators and certified by certifiers with little to no coordination with the rule-maker because they can rely on the public record. However, ad-hoc rules can override these pre-announced rules and users need to be aware of how they might be notified of these ad-hoc rules. The notification of which electronic ad-hoc rules are supported should be provided by the same disseminator that the user accesses for its pre-announced rules. However, the actual ad-hoc rules are likely to be disseminated through a separate distribution system (i.e., translator, collector, and disseminator); for example, ad-hoc rules might be transmitted by a localized roadside radio beacon or emergency vehicle radio beacon. To overcome the various challenges, rule-makers that support electronic ad-hoc rules should inform translators of pre-announced rules of which ad-hoc rules it claims will transmitted electronically.  

In the case of ad-hoc rules, the process should be streamlined to ensure that users become aware of the rules in a timely manner. This would generally be achieved by tightly coupling the distribution system roles. For example, a police officer might activate an ad-hoc rule to close a street. Part of the traffic control device used to do this might include a local beacon that the police officer activates to broadcast this closure. In this case, the police officer acts as the rule-maker while the beacon operates as the translator, collector, and disseminator under direct control of the police officer. Alternatively, the police officer might notify his dispatch of his action and the dispatcher might notify the traffic management centre, which takes responsibility for broadcasting the information through its existing field equipment (e.g., roadside units and/or wide area broadcast capabilities). In this case, the traffic management centre (and its field equipment) would act as the translator, collector, and disseminator that works in close coordination with the rule-maker.

If an ad-hoc rule is expected to last for a period significantly longer than the expiration window associated with pre-announced rules, the rule-maker should consider transforming the rule into a pre-announced rule so that they are made available to a wider geographic scope. This would require coordination with the translator(s) that deal with pre-announced rules to ensure that the rules are made electronically available prior to disabling the ad-hoc rules.

The installer is essentially the same role as defined in 5.4.4 with the additional responsibilities of: 

—     establishing an appropriate temporary ad-hoc rule or ensuring the provision of appropriate supplemental data to announce the rules displayed by newly installed traffic control devices and

—     notifying the translator and/or certifier (based on local policies) of the status of traffic control device installations for associated rules.

Posted rules typically become current when the first associated traffic control device associated with the rule is installed.

NOTE:    Once a rule becomes current, enforcers can provide a grace period prior to the assessment of significant penalties for violating the rule. 

Distributing updates of pre-announced rules requires considerable time (e.g., one week) but users need to become aware of newly installed rules almost instantaneously. The immediate notification can be handled in one of two ways:

1. The installer can provide supplemental data that activates a rule previously advertised by a pre-announced rule disseminator as an inactive rule. 
2. The installer can create a temporary ad-hoc rule to reflect the newly installed device. 

In either case, the information would need to be pushed to users who have a need to be aware of the now-active rule. When using the second method, care must be taken to avoid any unintended consequences of duplicating a rule definition. For example:

1. A new stop sign is installed, and a temporary ad-hoc rule is initiated and activated
2. The pre-announced rule disseminator begins to publicise the new stop sign as a pre-announced rule while the temporary ad-hoc rule is still being publicised
3. The expiration time for prior copies of pre-announced rules expire and the temporary ad-hoc rule can be terminated.

During step two, some user systems will perceive two stop sign rules if the rules are not properly linked. The system design needs to ensure that there are no adverse effects from this anomaly.

Once the traffic control device is installed and the relevant information is being pushed to users, the installer also needs to ensure that the process is initiated to update the pre-announced electronic rule. Depending on local policies this might be achieved by:

1. The installer notifying the translator, who updates the rule and optionally asks the certifier to certify; 
2. The installer notifying the certifier who certifies that the physical rule is consistent with the legal rule. The certifier then notifies the translator (who might also subsequently ask the same or different certifier to certify the electronic version); or 
3. The installer notifying both the translator and certifier. This allows the translator to prepare the electronic rule while the certifier verifies the field installation. The translator submits the electronic rule to the certifier and eventually gets back a fully certified rule.

The translator role is a newly added role within the proposed system. The translator is responsible for: 

—     obtaining relevant rules from rule-makers [RR-46] 

—    translating obtained rules into equivalent trustworthy, authoritative, electronic records ready for provision to collectors, 

—    obtaining installation reports from installers and updating the status of associated rules,

—     making translated rules available to collectors.

A translator can use an entirely manually process to translate written rules or partially automate the process of data entry. For example, a translator might:

—     deploy one or more vehicles equipped with discovery reporters that provide electronic records of rules observed in the field (7.4.16 provides additional details about discovery reporters)

—     coordinate with other translators to obtain a baseline set of rules. For example, a translator in one jurisdiction might use the records of unposted rules from another jurisdiction as a baseline because unposted rules are often similar between jurisdictions. 

Regardless of the process used, the translator is ultimately responsible for the accuracy of the of the rules that they provide to collectors (and ultimately to end users). Any reliance on an automated process should be carefully compared against the rule-makers information to prevent any inconsistencies or conflicts prior to approving the records for distribution.

While translating rules, the translator performs consistency checks to identify any conflicts or inconsistencies among recorded rules.  Inconsistencies generally arise due to poorly translated rules, in which case the translator is responsible for improving the translation. Conflicts generally arise due to problems within the rules from one or more rule-makers; in this case, the translator reports identified conflicts to the respective rule-makers and collaborates with them to resolve the situation.  Likewise, the translator collaborates with collectors to resolve any conflicts or inconsistencies that collectors report. 

For new rules that require traffic control devices to become current, the translator should initially enter the rule once notified of its approval by the rule-maker and update the rule after receiving confirmation of the installation of traffic control devices from the installer.  

The translator provides up-to-date electronic rules to one or more requesting collectors based on their authorised scope and may share rules with other translators to promote data consistency (e.g., among several levels of jurisdictional hierarchy) and accuracy (e.g., among peer translators). The authorised scope of a collector can be limited by a number of factors such as the jurisdictions covered, vehicle categories covered, etc.

The translator maintains an electronic datastore of rules, adding new rules, updating existing rules based on reported discrepancies from the verifier, and removing those that have been rescinded by the rule-maker.  The datastore could be shared among multiple roles if hosted by the same physical entity.

The certifier role is a newly added optional role related to the proposed system. The certifier is responsible for: 

—     verifying the accuracy of the translated rules, 

—     coordinating with others to resolve any interpretation issues identified

The certifier is responsible for verifying that each electronic rule produced by the translator accurately portrays the legal rule. Certification provides additional trustworthiness for the electronic rule but is likely to add costs. It is up to jurisdictional entities to determine when the additional costs are a worthwhile investment; users should be informed of when this investment has been made so that additional confidence can be given to the electronic rule. 

Translating between languages (i.e., in this case, between the legal text of the rule and the electronic representation of the rule in a standardized structure) can be difficult and prone to ambiguities. In many cases, the ambiguities might not be apparent to the translator but only to another party that views the wording from a slightly different perspective. As such, it is likely that certifiers will identify instances where a translation being reviewed is not what they expected. At this point, they will need to coordinate with others to ensure that the translation is revised as needed to reflect the legal intent and official interpretation of the rule as closely as possible.

The certifier might discover that the physical rule had to be installed differently due to field conditions. For example, a parking sign might be installed in a different position due to obstructions on the roadside, the location of a fire hydrant, or other reasons. While the installer should inform the rule-maker of any such variance, it is possible that the anomaly is not reported until the certifier inspects the rule. However, at the end of the process the legal, physical, and electronic rules need to all be in agreement.

Ensuring the rules are in agreement also requires the certifier to perform consistency checks across rules and to identify any cases where inconsistencies or conflicts might exist. 

Finally, the certifier provides evidence to interested parties that the rule has been certified (e.g., an electronic signature that the rule is certified).

The collector role is a newly added role within the proposed system. The collector is responsible for:

—     gathering rules from all relevant translators for its authorised scope and 

—     providing its rules to disseminators and non-METR distributers, as necessary.

The collector maintains an electronic datastore of gathered rules, adding, updating or removing rules as provided by each respective translator. While doing so, it performs consistency checks on the rules and reports inconsistencies or conflicts to the respective translators, and subsequently collaborates to resolve situations.    

The collector provides up-to-date electronic rules to one or more requesting disseminators based on their authorised scope and may share rules with other collectors to promote data consistency and accuracy.

The disseminator role is a newly added role within the proposed system and is responsible for:

—     gathering rules from all relevant collectors for its authorized scope (categories and defined areas) 

—     publicising the categories of data that it has available

—     publicising the rules to all appropriate users (i.e., for pre-announced rules, this is based on a user's request; for ad-hoc rules, this is based on user location)

—     packaging rules into rule sets for easy dissemination and updating

—     publicising the expiry period for each rule or rule set delivered

—     reporting inconsistencies that it detects in its rule set that it is unable to resolve on its own.

—     For mobile disseminators, re-disseminating rules to one or more specific transport users

The disseminator maintains an electronic datastore of gathered rules, adding, updating or removing rules as indicated by its respective collectors.  While doing so, it performs consistency checks on the rules and reports inconsistencies or conflicts to the respective translator(s), and potentially collaborates to resolve the situation.  Because the disseminator represents the centralised source with the most complete view of all rules, it bears the greatest responsibility for detecting any inconsistencies among rules before they are disseminated to users.

The disseminator packages rules into one or more rule sets for efficient transmission and associates each rule set with an expiration period.  The expiration time signifies an agreement that the provided rules will be trustworthy until that time and that any use of the rules beyond the expiration time is at the user's risk.

The disseminator is responsible for publicising the rules as appropriate; details of this are explained in 7.4.9 and 7.4.10 

The pre-announced rule disseminator role is a newly added role within the proposed system and is responsible for:

—     publicising the pre-announced rule categories that it offers for each defined area

—     publicising the ad-hoc rule categories that are provided, and source and technology used for each defined area

—     publicising pre-announced rules based on its database and the requests received

For each defined area that it covers, the pre-announced rule disseminator publicises 

—     the categories of pre-announced rules that it claims to support and 

—     the categories of ad-hoc rules that the jurisdictional entities claim will be provided.

METR receivers need this information to understand which types of rules are available within each defined area and how much reliance to place upon METR as compared to other sources of information. 

Upon request, the pre-announced rule disseminator publicises the receiver with the most recent electronic rules for each rule category and area requested.  The rules can be provided in either a customized package or by using one or more of the pre-packaged category rule sets. The former allows for immediate access to narrow focus of interest requests while the latter allows efficient transfer and updates for more regional requests [RR-11]. The pre-announced rule disseminator confirms successful receipt of requested rules [RR-48].  It may share rules with other pre-announced rule disseminators to promote data consistency and accuracy.  

The ad-hoc rule disseminator role is a newly added role within the proposed system and is responsible for:

—     publicising ad-hoc rules to all users with a potential need within a specified area

The ad-hoc rule disseminator publicises its ad-hoc rules to all users with a potential need for them. For example, this could be achieved by broadcasting the ad-hoc rules over one or more communications media within the geographic area where the rule applies until the rule has been terminated.  

The non-METR distributor role is a newly added optional role that receives rules from the proposed system and is responsible for:

—     distributing data to entities who might be interested in METR data but who do not support a conformant METR interface

A non-METR distributor likely serves a role similar to that of the disseminator but after receiving rules from the collector, would use different standards and protocols to disseminate rules.

The receiver role is a newly added role within the proposed system and is responsible for:

—     contacting an appropriate disseminator and pulling all available relevant rules as necessary to fulfil their operating parameters, including pulling rules when entering a new area and pulling rule refreshes prior to the previous rule sets expiring.

—     ensuring that its rules are sufficiently trustworthy for the intended use (e.g., have not expired)

—     processing the received rules and providing to the interpreter as needed

The receiver maintains a dynamic scope of the rules needed, based on current parameters provided by its interpreter (e.g., rule categories, route information, operating parameters).  It gathers in-scope pre-announced rules, through requests to one or more pre-announced rule disseminators, either before or during the trip. It may attempt to optimize the timing of data collection to favour the use of the user's preferred connectivity options [RR-4].  It also gathers in-scope rules publicised by ad-hoc rule disseminators, typically during the trip. The conformant receiver maintains a datastore of current rules for the interpreter, replacing rules that have expired and removing rules that are no longer in scope.

The interpreter role is a newly added role that interacts with the proposed system and is responsible for:

—     providing the receiver with information that helps determine the needs for rules in the near future

—     obtaining current the supplemental data required to interpret current rules

—     ensuring that supplemental data sources are sufficiently trustworthy for the intended use.

—     ensuring that data are sufficiently trustworthy for the intended use

—     fusing the METR rules with supplemental data to produce interpreted rules that describe the active rule environment

—     reporting any inconsistencies detected (e.g., between physical traffic control devices and electronic rules)

The interpreter combines the METR rules with supplemental data to produce the vehicle's best assessment of the active rule environment. As a part of this task, it works with other on-board systems to provide information to the receiver that will help determine what rules will be needed in the near future. This information might include the current route to the destination (if known) or other more general information, such as current location and direction of travel, that can be used to identify information needs.

The primary responsibility of the interpreter is to combine the rules received via with the real-time data received from supplemental data providers to determine which rules are currently active and relevant. The data providers can be on-board, external, or from a data store (e.g., previously entered vehicle configuration information); the interpreter is responsible for assessing the trustworthiness of each source and weighting the information from the source appropriately. For example, the METR receiver can provide the interpreter with speed limits for the current road for daytime, night-time, and rainy conditions, as publicised by METR. The interpreter is responsible for fusing this information with other sources of data, including:

—     on-board GNSS feed that provides the location and time; the interpreter can use this information to identify which speed limit locations are needed

—     on-board status of the windshield wipers that indicate if it might be precipitating

—     on-board sensors that might report detected speed limit signs 

—     external data source that identifies the times for dawn and dusk for the requested location

—     external data sources that might provide an indication if it is raining

The interpreter considers all these data sources and produces a single output that represents its best interpretation of the current, active speed limit for the current roadway. For example, METR might indicate that the speed limit is currently "80" while the optical character recognition (OCR) of a speed limit sign indicates a speed limit of "30". If the OCR indicates a high confidence level for reading the sign, the interpreter might decide that it is more trustworthy; if the OCR indicates a low confidence level, the interpreter might decide that the "3" was misread and rely upon the METR provided value. 

NOTE: The algorithm is likely to consider other parameters in this situation as well, including, the speed limit that applied to the previous section of road, the default speed limit for this type of road, and other factors.

The interpreter makes the current active rules available to other authorized on-board systems, such as the driving automation system. It also alerts the discrepancy reporter to any discrepancies that it detected, whether those discrepancies were between different two electronic rules or between an electronic rule and a physical rule.

The supplemental data provider role is a newly added role that interacts with the proposed system and may be used for:

—     providing the interpreter with the data needed to determine which rules are currently active

—     supplementing the METR rules with detected physical rules

Supplemental data providers provide the interpreter with information as needed so that the interpreter can properly identify active rules. If an interpreter requires supplemental data that is not supported or not available, the interpreter must make its best judgement of conditions and indicate the lower trustworthiness of the resultant active rule set. Depending on the rules affected and the internal constraints within the vehicle, missing supplemental data could affect the operation of the METR user. 

There are three types of supplemental data providers: external data providers, on-board data providers, and stored data providers

External data providers are supplemental data providers that are external to the METR user's system. These include, but are not limited to:

—     on-board equipment from other vehicles (e.g., emergency vehicle notices)

—     roadside equipment (e.g., signal phase and timing information)

—     central systems (e.g., real-time rules issued from a central source, such as evacuation orders)

—     map providers that provide mapping information to METR user systems. The types of details in the map are likely to vary based on the needs of the METR user. For example, a motor vehicle-based system would download the motor vehicle road network whereas a micromobility vehicle would download details about the micromobility road network, which is likely to include details about the pavement surface and kerb cut-outs so that the vehicle can determine whether it will be able to navigate the particular links.

On-board data providers are supplemental data providers that provide data that is considered an integral part of the secured vehicle network. For example, this includes data configured by the original equipment manufacturer as well as before-market and after-market sensors that are integrated into the vehicle's secure network. On-board data includes:

• static vehicular characteristics (e.g., gross vehicle weight rating, fuel type)
• on-board sensors reporting dynamic vehicular characteristics (e.g., presence of a trailer connection)
• on-board sensors reporting external conditions (e.g., precipitation data, video analytics of posted rules)

The stored data provider is a supplemental data provider that is on-board the vehicle and relays information provided through on-board user interfaces. These interfaces should generally include some level of authentication but will not be as trustworthy as most other data inputs to the interpreter. Example interfaces for this data include:

—     Touchscreen displays (e.g., for manual human input)

—     Bluetooth connections (e.g., for electronic input from handheld devices)

—     QR code, chip readers, and similar devices (e.g., for importing tangible permits)

Due to the varied degree of trustworthiness of these input sources, data from the stored data provider should be associated with an assessment of its trustworthiness (e.g., a manually-entered assertion that the user has a parking permit is not as trustworthy as a permit provided on a smart card's chip with an authenticated signature).

The METR user role is a refinement of the user role from the existing system. In addition to the responsibilities defined in 5.4.x. the METR user is responsible for:

—     determining if the trustworthiness of the active rule environment provided by the interpreter is sufficient for safe operations

Within the existing system, users are assumed to be humans, who are responsible for being aware of rules and conditions and making their own interpretations of the active rule environment and whether it is safe to operate. Within the proposed system, the interpreter performs part of this responsibility, but the METR user, human or otherwise, still bears responsibility to assess the active rule environment and whether it is safe to operate. Within this context, the METR user may supplement the information received from the interpreter with additional information (e.g., a human user might use eyesight to supplement information received from the interpreter).

METR users are classified as either transport-related users or ancillary users.

A transport-related user is a METR user that is involved directly in the transport environment, including:

—     human drivers

—     micromobility users

—     ride sourcing users

—     pedestrians

—     individuals that are sending or receiving packages

—     fleet managers

—     driving automation systems

—     pathway robots

A transport-related user does not have any additional responsibilities from those required for a METR user. 

Users should remain pseudo-anonymous in all situations.

An ancillary user is a METR user that is not have a direct transport need nor does it directly support the need; ancillary users include:

—     lawyers

—     enforcement personnel

—     insurance companies

—     academic institutions

—     automotive repair facilities

—     traffic managers

A transport-related user does not have any additional responsibilities from those required for a METR user. 

NOTE: Some ancillary users can be authorized to access information beyond those shown in Figure 4. For example, a lawyer can be given access to evidence of non-repudiation information for each METR component.

The discovery reporter role is a newly added role that interacts with the proposed system and is assigned the following responsibilities:

—     Identification and geolocation of physical rules based on observed traffic control devices

—     Creation of discovered electronic rules for each identified physical rule 

—     Collection, collation and uploading of discovered electronic rules to the translator

The process and effort to collect, organize, prepare, and convert existing text-based legal rules into electronic rules can be challenging.  This could be simplified and expedited with the use of a field discovery mode, whereby specially equipped vehicles methodically traverse the jurisdictional area identifying, geo-locating and electronically recording all currently installed traffic control devices.  

The discrepancy reporter role is a newly added role that interacts with the proposed system and is assigned the following responsibilities:

—     Receiving discrepancy reports from the interpreter

—     Collection, collation and uploading of identified discrepancies to the discrepancy handler

The discrepancy reporter is a role intended to be performed within the same physical unit as the interpreter (e.g., on-board the vehicle) and is responsible for providing detected discrepancies to a discrepancy handler. The interpreter is responsible for detecting discrepancies and passing these to the discrepancy reporter. The discrepancy reporter is responsible for collecting the reports and providing them to an appropriate handler when appropriate. The handler is intended to be an off-platform, centralized resource.

For example, the discrepancy reporter will need to store the discrepancy report until there is connectivity to an appropriate discrepancy handler. It will also need to manage which discrepancy handler it is to use in reports and determine the appropriate mechanisms to use to ensure privacy and confidentiality of the METR user is maintained.

The discrepancy handler role is a newly added role within the proposed system and is assigned the following responsibilities:

—     Receiving discrepancy reports from the discrepancy reporter

—     Providing the discrepancy verifier with anonymized discrepancy reports

The primary responsibility of the discrepancy handler is to anonymize the source of the discrepancy reports so that the privacy of the reporter can be maintained. The discrepancy handler receives discrepancy reports from multiple discrepancy reporters and removes the source of the report before passing it to the discrepancy verifier. The handler is a part of the METR system to ensure standardization of the data exchange formats used. A discrepancy handler can also duplicate some of the roles of a discrepancy verifier. 

The discrepancy verifier role is a newly added role that interacts with the proposed system and is assigned the following responsibilities:

—     Receiving anonymised discrepancy reports from the discrepancy handler

—     Collection, collation, filtering discrepancy reports

—     Providing the translator with a summarized list of discrepancy reports

It is likely that interpreters will periodically submit spurious reports due to on-board sensors not accurately detecting physical rules (e.g., not seeing a speed limit sign due to an obstructing vehicle). By contrast, an actual discrepancy should be identified by most interpreters that are sufficiently equipped to identify it. The discrepancy verifier potentially receives discrepancy reports from multiple discrepancy handlers, each of which receives reports from multiple discrepancy reporters. For each reported discrepancy, the verifier will use locally determined policies to determine whether the discrepancy needs to be relayed to the translator. For example, the policy might be limited to analysing the number of reports received, or it might require a site visit to visually verify the discrepancy. When the verifier determines that a discrepancy needs to be relayed, it notifies the translator, which is responsible for investigating the report and ensuring that the legal, electronic, and physical rules are properly synchronized. 

This section describes additional roles related to METR that are not explicitly shown in Figure 4.

This section describes the various modes of operation for the proposed system. The mode of operation of the METR environment is viewed from the perspective of each receiver within its area of interest; it is possible for different nearby receivers to be operating in different modes simultaneously.

In the normal mode, a receiver can receive all current, relevant rules from disseminator(s) for those rule categories that the disseminator(s) claim to support. As a part of this operation, pre-announced rule disseminators need to publicise the data categories that are supported for the defined area; this includes publicising which categories of ad-hoc rules and supplemental data will be provided within the defined area, even if they might be provided by different disseminators. 

For example, the pre-announced rule disseminator needs to identify whether there is a commitment for emergency vehicles to publicise their presence and status when they activate their emergency lights. METR interpreters need to be aware whether to expect to receive this information electronically so that they can properly evaluate conditions and interpret rules. Even though the commitment is from the emergency vehicle fleet, the commitment needs to be relayed by the pre-announced rule disseminator. 

It is the responsibility of METR users to determine if the data categories supported by the defined area is sufficient to support its needs.

In the degraded mode, the METR environment is unable to deliver some or all the data that it has otherwise committed to providing within the defined area. This might be due to various issues including:

—     one or more translators being offline

—     one or more collectors being offline

—     one or more disseminators being offline

—     one or more external data providers being offline 

—     the receiver being in an area without connectivity

The degraded mode is only entered if there is a possibility that the degradation reasonably results in a potential for a failure to meet commitments. For example, an emergency vehicle that is unable to broadcast its presence would not cause degraded mode unless the defined area committed to providing the information and the vehicle is in service.

The pre-announced rule disseminator is responsible for notifying METR receivers when the degraded mode exists. 

The fallback mode represents a condition when a METR receiver attempts to contact a disseminator and discovers that the disseminator is unavailable, but the receiver is still able to connect to another disseminator that meets its needs. The METR receiver can discover alternate disseminators via the ITS discovery service that publicises the disseminators for an area.

This mode is only applicable to disseminators that use a request-reply connection method, which is typical of pre-announced rule disseminators.

When in this mode, the receiver is responsible for determining when to revert to normal mode. For example, the receiver might:

—     determine that the alternate disseminator should become its primary disseminator, 

—     periodically poll its primary disseminator to determine when it is available again.

The field discovery mode is active when the translator accepts information from discovery reporters. This is intended to be a mode primarily used during initialization efforts to capture all physical rules within a defined area. A system can be in the field discovery mode for one user (e.g., discovering certain categories of rules), while in another mode for other users (e.g., especially for other rule categories).

The support environment includes the facilities, equipment, and other support services as defined in this section. 

The ITS Disseminator Discovery Service is responsible providing a service to allow transport user systems to discover trustworthy disseminators.

The Cooperative ITS Credential Management System (CCMS) is responsible for enabling trusted communications between system components.

Technology services provide base information technologies that will be used by METR, such as:

—     telecommunications 

—     cloud platforms

The METR Certification Manager is responsible for ensuring that each METR component performs its responsibilities correctly both initially and while in operation. It is envisioned that there will be one certification manager for any given jurisdiction.

Maintenance facilities will be responsible for repairing any issues with METR system components, including both the back-end systems (e.g., disseminators) and the end-user systems (e.g., receivers).

An enforcer is responsible for ensuring that users comply with the defined rules. 

Academic institutions and advocacy groups are responsible for studying METR deployments and associated side effects to suggest enhancements to the system. Entities that perform these tasks often include:

—     automated vehicle experts

—     location perception experts

—     Advocates (e.g., safety, environmental, disability rights)