24315-1 METR ConOps
SP: Summary Points

Road vehicles should support short-range wireless; not necessarily true for other transport user systems

Some users might not be connected to METR

All ~mobile~ METR-enabled transport user systems should support mobile wireless internet

Mobile wireless internet is not guaranteed for any location

Mobile wireless internet might not be available (at any time) for some locations

METR should support user systems that might not be mobile. For example, a home PC used for planning a journey and understanding the rules when travelling in other areas

Users have a need to indicate their preferred internet connectivity mechanism, but user systems must always stay up-to-date per agreements with disseminator

User systems might support the ability to download rules in advance of a long journey

METR should support ordinary traffic (i.e., driver support systems)

METR should cover the full scope of surface transport (e.g., ITS)

Need to support rules related to specific types of users (e.g., accessible parking permits/placards) in a manner that allows integration with the user system

Trustworthiness should include non-repudiation under accountability

METR should indicate the level of legal precedence that the electronic rules have (e.g., compared to physical traffic control devices)

Users should have a way to report discrepancies between electronic rules and physically observed rules (and this should be shown on diagram)

We should emphasize that the types of regulators and translators shown in Slide 17 are just examples

Some regions might wish to have a system manager to manage portions of METR

Should provide sample diagrams showing implementations of the role-based architecture; multiple examples will be needed to prevent implying that there is a preferred approach

The role model should add a role between the regulator and the translator that represents the "competent authority". In other words, the regulator might define a regulation, but the "competent authority" is responsible for implementing the regulation where it can then be translated.

The ConOps should provide practical use cases that explain the varied types of rules that might be disseminated and how the process would work

The ConOps needs to identify accountability needs that demonstrate that each METR component is fulfilling its responsibilities (e.g., non-repudiation that its responsibilities were completed at each point in time)

The concept of modes does not seem to apply to our collaborative system of systems

State of rules in force on the transport network needs to be conveyed through the state of each rule (e.g., through real-time data; see Workshop 3, i.e., use of C-ITS data)

State of rule availability should be captured using a catalogue for each provisioning system

The ConOps should reference ISO/IEC/IEEE 15288 and indicate which type of "system of systems" best describes METR

All rules should be defined in a language-neutral format

METR should be based on a centralized pull of static data coupled with dynamic data being provided by a combination of (1) provisioning from a central system and (2) pushing/broadcasting from local source(s)

It should be the responsibility of the user system to pull data when needed (e.g., periodically and when entering new area)

Each METR rule (e.g., give way to emergency vehicles) needs to support being associated with conditional logic such that the rule is only active when the condition is true. The conditional logic might need to reference external variables (e.g., "it is snowing", "workers are present", "children are present", "it is after dusk"), which might be provided by a METR system component or another source (e.g., C-ITS data, vehicle sensor array, etc.).

Withdrawn/rescinded rules need to be publicized in a fashion similar to publicizing new rules (i.e., static when possible, dynamic otherwise)

METR will rely upon existing standards when appropriate

User systems need high confidence that they have all active rules

Development team needs to contact field crew stakeholders to determine if they have concerns about the work flow changes being proposed (e.g., ensuring that electronic rules are activated simultaneously with field deployment of rules)

Use of push should be minimized while still providing a high certainty of delivery for ~all~ vehicles entering the area of applicability (e.g., even those that just turned on and are entering the roadway); otherwise communication channels are easily overloaded.

Push is probably needed for coordination of installation of signs

Hierarchy of rules should support the concept of default speed limits that can be overridden by local speed limits (and similar local override concepts)

Pull process must support filtering

Centralized dynamic rules either need true broadcast (e.g., broadcast over a metropolitan area) or needs to support filtering (e.g., publication/subscription rather than broadcast, or pull at more frequent rates than for static data)

Filtering should include almost all parameters that can be identified, including: vehicle classification, user classification (e.g., driver's license type, police officer), road classification, location, type of rule, temporal constraints, nature of load, possession of a permit (e.g., parking), vehicle characteristics (e.g., mass), etc.

There is a lack of consistent terminology and meanings within rules. What exactly does "stop" mean, what are differences between zones, areas, etc.

The definition of a "regulator" needs to be flexible enough that a regulator can enter data in an electronic format (i.e., also perform the role of translator)

ConOps should explain that all components will need to be certified into the trust domain and jurisdictions might require additional certifications.

The ConOps needs to assign the responsibility to perform consistency checks to one (or more) of the roles. (probably the disseminator and regulator and perhaps supplemented by others). Resolving consistency checks will likely involve coordination of regulators.

The preferred implementation is that the regulator also performs the role of translator during the creation of the rule. This allows the most timely digitization of the rule and the greatest opportunity to publicize the rule prior to its activation.

The preferred implementation is that a user relies on a single disseminator; this will simplify processing and minimize the potential for conflicting rules being received by the user. However, jurisdictions might require use of a specific disseminator for some functions (e.g., freight management operations) while a vehicle uses a different disseminator for more general purposes. Finally, all users will need to be able to supplement their METR data with C-ITS data (e.g., locally broadcast data). The multiple sources of data will require additional consistency checks by the ITS user system to ensure that there are not any real-time rule conflicts.

Peer roles need the ability to coordinate to ensure that they have consistent data.

METR must provide accountability such that the source of any inconsistency can be identified

Disseminators need to be able to share cross-boarder information and allow for discovery via a defined service (e.g., national access point)

A mobile refresh provider should be characterized as a mobile disseminator as it will need to fulfil the responsibilities of a disseminator rather than a user

Need to be able to filter rules based on location (e.g., GIS based distribution services)

The feedback loop needs to include the regulator (and competent authority) in case the physical signage is in error

The ConOps should be written to allow for the use of mainstream data distribution technologies, if they meet user needs.

The ConOps should mention that automated discovery is a likely possibility but explain that there does not appear to be a pressing need to standardize the interface or requirements.

METR should distinguish between "rules" and "C-ITS data" that is used to support rules. METR disseminators are responsible for distributing rules; C-ITS data is provided by a "C-ITS data provider" role.

To the extent that C-ITS data is exchanged electronically; it should be provided in an open manner (e.g., broadcast to all for no charge)

There needs to be a fifth catalogue state, which is a rule that is electronically available but references details that are not electronic. For example, a postal vehicle might be exempted from some parking/stopping rules but the parking rule likely does not specify that exemption directly

Validity should apply to rules; we need another term to describe the required refresh period of downloaded catalogues (e.g., expiry period)

User privacy needs to be protected, especially for the data requests that are submitted

Australia will be issuing a report soon that describes high priority categories of rules

Need examples that can be presented to government managers and used to sell METR; this should probably be documented in a white paper rather than the standard so that it will remain freely available

The disseminator is responsible for ensuring that all rules meeting a user's criteria are delivered to that user

Users need a way to discover disseminators using an ITS service (external to METR)

When showing multiplicity in diagrams other than UML, use "n" rather than "*" to prevent confusion with the concept of "all"

METR filtering needs to accommodate the possibility that some users might qualify as different types of vehicles for different jurisdictions (e.g., a national "moped" and a local "scooter")

Remove the rule types from the state machine diagram; if the diagram needs to show specializations for the different types, break the diagram into a separate diagram for each specialization so that each conforms to UML rules.

When discussing rule types, we need to consider the terminology and perhaps adopt the terminology used by DATEX II (rules issued by 1) competent authorities, 2) ad-hoc, 3) planned dynamic, and 4) authorized actors).  After further review, we propose:
"unposted rules": not posted with traffic control devices and fully publicized in advance of activation
"persistent rules": traffic control devices that are deployed without any expectation of a termination and fully publicized in advance of activation
"temporary rules": traffic control devices that are deployed with an expectation of a future termination and fully publicized in advance of activation
"ad-hoc rules": rules that are implemented prior to the expiration period of previously downloaded rule sets (i.e., not fully publicized in advance of activation); these rules must be distributed via C-ITS. An example is a police officer on scene directing traffic or imposing a road closure
"state-triggers": Events that affect the practical impacts of a rule for a user (e.g., state of a traffic signal, current value of a variable speed limit, rain causing the activation of a slower speed limit rule, etc.) These require either on-board sensors or C-ITS data from outside sources to implement.

Within our definitions we should attempt to capture any synonyms used by different regions of the world for particular terms

When discussing planned rules, indicate that they may require authorization, which might be a period for months, even though the actual implementation of the rule may just be a for a few days

User requests should be confidential and privacy aspects should be disclosed (i.e., allow alternate uses only when disseminator discloses such use and allows user to opt in)

See slide for examples of rule characteristcis that need to be considered

METR should allow rule characteristcis to be stated in both positive and negative fashion (e.g., "only trucks" or "except trucks")

Evacuation plans should be distributed in advance to the extent possible when the threat provides little advance notice and might disable disseminator channels (e.g., an earthquake). However, plans will often need to be updated to reflect real-time conditions (e.g., blocked roadway); so there is a need to support high availability during these events and to support dynamic updates (e.g., C-ITS notice that an update is available and all users need to download)

The disseminator is responsible for publicising the filters/categories of data that it has available and the expiry period for each rule set delivered

The user is responsible for requesting a refresh of all rules that the user needs prior to their expiration

All roles are responsible for 1) identifying conflicts and inconsistencies among rules, 2) correcting the conflict/inconsistency, if the issue is due to an error on its part, and 3) notifying the source(s) of the rules of the identified conflict/inconsistency.

The term "C-ITS data source" should perhaps be revised to be more consistent with other role names. For example, perhaps "C-ITS data provider". We should also be clear that the C-ITS data provider likely supports services external to METR (i.e., it is cooperative)

The ConOps should describe why we are distinguishing between the disseminator and the C-ITS data provider. This is partially due to the fact that we want to emphasize the different roles (e.g., push vs pull) and the fact that some C-ITS data might come from other sources (e.g., on-board clock, rain sensors, weather service, etc)

The ConOps should provide a brief mention that proposed rules can have review periods as a part of the approval process and that new proposals can be initiated to refine existing rules

The ConOps should explain that rules might be deployed for a test user community or a specific testing location. This is likely more of a rule characteristic rather than a unique operational state of a rule.

What is the legal standing of C-ITS data. We should probably have a discussion in the ConOps that discusses the legal aspects and explain that it is likely to vary by jurisdiction and might need the ability for METR to convey whether particular C-ITS data providers are "official"

The ConOps should explain that the rule types have their own aspect of hierarchy. In other words, all rules start with legislative action that enact laws. Some laws will empower road authorities to define persistent traffic rules using traffic control devices. Other rules empower road operators, police, etc to impose temporary rules (e.g., road work rules), ad-hoc rules (e.g., snow chain requirements), and to distribute C-ITS data (e.g., SPaT and variable speed limits) to activate/update state-triggered rules.

The ConOps should include a use case that explains the process for installing and removing a permanent traffic control device (e.g., a parking sign) and explain how the process needs to work in real time to ensure consistency in information, especially when a traffic control device installation does not occur on schedule and the system needs to flag the discrepancy. And also perhaps for what happens with a missing device (e.g., missing speed limit sign as approaching or leaving a town on a rural highway)

The ConOps should also include a use case for emergency response deploying traffic control device to make a crash site safe

The "when" responsibility should apply to all roles, not just users

We need to indicate that each system needs to support non-repudiation to show what it knew when while also documenting the constraints applicable to the component as to how much storage might be available. We need to be able to indicate what sort of time limit the non-repudiation needs to be available for. We also need to determine if the level of non-repudiation needed requires a bi-directional confirmation (i.e., return receipt) or unidirectional (i.e., self reporting that information was received)

Clarify text of responsibilities (as shown on slide) that the users are responsible for requesting and processing the applicable rules that are available from the disseminator (they cannot be held responsible for rules that the disseminator fails to provide)

Some conditions might require dynamic data, such as OBE inputs (e.g., sensor, clock data) or C-ITS data (e.g., SPaT/MAP) and in some cases the data could be from either (e.g., is it raining). Rules might need to indicate the source for official definition of the state of a rule (e.g., "when raining" is based on NWS; "holidays" are based on calendar from X).

The ConOps should describe a process by which agencies can verify their electronic rules against as-built infrastructure, which might be a way to reduce liability.

The ConOps should allow flexibility for a user system to report any conflicts in rules to the trusted source of its choice, who can then forward to the appropriate disseminator. For example, it may report to an OEM, who provides data to the disseminator.

The ConOps should allow any vehicle (that has the ability) to report any discrepancy that they detect. Jurisdictions, OEMs, and/or others might define detection and reporting requirements; but the METR ConOps should be general enough to allow for multiple deployment scenarios (i.e., where some jurisdictions do not have reporting requirements)

A vehicle reporting a conflict should have the option of providing an image, but may choose not to (e.g., due to current data limitations)

A disseminator should not publicize reported conflicts until they have been confirmed; at which point the electronic rule should be corrected (if needed) as quickly as possible. It is possible that in the future there might be a need for a disseminator to publicize conflicts to reduce the number of reports received, but at present it is unlikely that the number of reports will present a problem.

The ConOps should probably stay agnostic about what entity would be involved in the data ownership but recognize that the OEMs might be involved from the analysis (i.e., cameras correctly or incorrectly identifying conflicts) and/or ownership perspectives.

A rule refresh should only provide the changed rules rather than requiring a complete download. At some point, a user might need to download the complete data set.

Each individual rule should have its own "validity" period (i.e., the times at which the rules are enforceable such as the hours for a parking restriction) while every batch of rules should have its own "expiration" time

The ConOps should provide an example of a mixture of types of communications

Unless otherwise indicated, the ConOps should assume that the rules are sent authenticated (signed) but unencrypted.

The ConOps should indicate that we assume that ADS will only work when rules are not expired, but it is up to the manufacturer to determine their precise policies.

The ConOps should provide an example use case of a car starting in an area without any connectivity.

The ConOps should indicate that for the near-future, we assume that ADS-equipped vehicles will allow for a human driver mode. If not, care should be taken to ensure that the rules do not expire while the car is parked.

Any remote refresh would have to be provided by a trusted source; it is still unclear exactly what the requirements would be for such a source.

The ConOps should allow the definition of "user profiles" within its category system. For example a passenger car profile that could be used by a large portion of the user population.

Vehicle types regulated by a jurisdiction need to be defined by the jurisdiction and conveyed via METR

The characteristics used by a jurisdiction to classify a vehicle might include usage characteristics (e.g., delivery or not), emission characteristics, and other characteristics

Road types regulated by a jurisdiction need to be defined by the jurisdiction and conveyed via METR

METR needs to convey the location for every rule (e.g., the location of every stop sign)

METR needs to support rules that characterize vehicles based on various characteristics, including: presence of hazardous materials, the current purpose of the vehicle (e.g., delivery, emergency response), etc.

METR users need to be able to identify which rules they need access (this will allow vehicles to support a change of state as needed, such as switching from a general use private vehicle to a delivery vehicle)

METR does not need to convey the graphics related to rules

The METR ConOps will be written so that METR can distinguish between a planned change to a rule (e.g., changing the speed limit next week) and a plan for a new rule (e.g., implementation of a new parking restriction next week)

METR needs to be able to advertise when new signs are installed in real-time.

Characteristics should include permits, toll tags, type of driver's license (e.g., commercial), driver fatigue state, etc.

All rules should be signed by the translator and the disseminator

Conform to the terminology of ISO 22736 (SAE J3016)

Rules provided by METR should be complete for a defined "domain" (e.g., geographic and functional scope) and accurately represent the laws that the jurisdictions have passed as closely as possible.

When any conflict is discovered, it should be reported and it is left to the user/user system to determine the best real-time response.

We should use the terms "low latency" and "high latency" rather than "short range wireless" and "cloud"

Look at CEN ISO/TS 17426 Contextual speeds

The operational scenarios should provide an example of how a vehicle might have digital commentary to explain its actions. See https://www.bsigroup.com/en-GB/about-bsi/media-centre/press-releases/2021-press-releases/june/digital-commentary-driving-the-new-safety-technique-that-can-help-put-automated-vehicles-on-our-roads/

In order to be trustworthy and relied upon to provide normative information; METR needs to provide all rules for a "domain" (i.e., category of rule coupled with location characteristcis such as motorways within certain city limits)

In order to claim support for any rule domain, a disseminator must also be able to offer all other rules that are required by that domain and indicate that they are required. For example, to support speed limits, the disseminator must be able to provide any default speed limits and to support default speed limits, the disseminator must be able to support the definition of any road types referenced by the default speed limits (e.g., default speed of 90 kph on rural roads)

Users need to be aware of when they should be receiving dynamic data (e.g., signal locations, variable speed limit systems) so that if the data is not being received for any reason, the user system is aware that it is missing. (NOTE: Beacons could advertise the location of other nearby beacons - especially ad hoc)

Regulators might establish rules that require certification of vehicles before they are allowed to operate within certain ODDs and the agencies need to be able to advertise the boundaries where ODD restrictions apply. These ODDs can be very specific (e.g., a particularly complex traffic circle)

Responders and field crews often have needs to implement rules that are not easy to codify on the fly; they have a need to be able to advise users that the normal rules (e.g., static/variable rules) are currently being overridden but the details of the override are not provided electronically. This will notify ADS-equipped vehicles that there is a change in the ODD.

Between METR and the map data, ADS-equipped vehicles need to be aware of locations where they can drive to in order to achieve a "minimal risk condition"when ODD boundaries are encountered (and in some locations to identify alternate routes that avoid crossing the ODD boundary).

METR needs to be able to indicate how complete the METR ruleset is for any point in time and space. (Might be a part of map or a part of METR)

METR providers might need to be certified (some local jurisdictions might require)

Identification and responding to dynamic ODD boundaries is outside the scope of METR

METR cannot rely on just one path for data; there must be redundancies in case of a problem

Identification of the disseminator is outside the scope of METR but will need to be handled by an external ITS service (e.g., national access points, ORDS, offline searches, etc)

The ConOps should structure at least one of its operational scenarios using the terminology of "data" (e.g., sensors), "information" (processed data), and "delivery" (connections) to clearly indicate how it addresses these three key aspects of ITS deployments

The ConOps should indicate the importance of location accuracy (details will be left to the requirements)

The ConOps might include a scenario with a variable speed limit system that has a fixed schedule that can be overridden by events.

Define "static rule", "dynamic rule" and "dynamic data"; "dynamic rule" should be defined to be a type of "dynamic data", while also being a rule defined by a regulator

Distinguish between "governmental" and "private" rules. Private rules are established by campus owners rather than governmental jurisdictional entities

We need an example scenario that describes a graceful fallback when traffic control devices are not consistent with METR information (e.g., a private facility where METR data has not been updated)

Transport user systems need insights into the confidence level of the information (e.g., high res mapping tools vs online selection on map, private property where owner may change rules without updating system, the information was self reported vs being verified by third party, etc.); OEMs and/or jurisdictions might require levels for types of facilities/rules (e.g., stop sign locations are more critical than parking regs)

Need to support (and convey to users) the type of authority that has imposed the rule (e.g., government, private party)

Users need all rules to be digitally signed by the translator, at a minimum

METR needs to be able to accommodate higher authority (e.g., national) roads passing through a lower authority's (e.g., town, campus) jurisdictional area.

METR needs to be able to accommodate roads managed by the lowest level jurisdiction within an area (e.g., town, campus roads in the town/campus).

METR needs to be able to accommodate jurisdictions with non-contiguous areas (sometimes called islands).

METR needs to be able to accommodate enforcement of rules within private facilities by private and/or public entities (according to whatever local rules that might apply)

METR needs to be able to accommodate independent jurisdictional areas that are surrounded by another jurisdiction (e.g., a city-state, an embassy)

It might be worth including an optional deployment date within the rules so that a driver support system could alert the driver to new rules.

Within one of its scenarios, the METR ConOps should indicate support for proxy data entry services

METR rules need to define areas reserved for accessibility purposes such as loading/unloading areas and curb cutouts; this is a detail that might take a while to populate

Within one of its scenarios, the METR ConOps should indicate that the process for entering METR rules might include some type of validation per the requirements of the containing jurisdiction

METR needs to provide a way to link rules to permits (including the permit type and permit issuer). These should include any permit that might affect traffic, including those issued by non-transport related authorities (e.g., a permit for scaffolding on public right of way)

METR needs to provide a way for the vehicle to become aware of permits currently associated with the vehicle.

A METR operational scenario should indicate that a vehicle might be aware of a permit (and apply associated rules) or might not (and provide warnings to the driver)

METR should provide a way for an entity (e.g., an automated gate, an enforcement officer) to query the vehicle for its permits

Process to deploy known rules includes publicizing first (perhaps with expected date) followed by activation of rule (with deployment of traffic control device) and announcement that the rule is active. All planned events should be in METR.

METR needs to support both permits that are vehicle-based (e.g., emergency vehicle) and that are person-based (e.g., accessible parking). Access to road works might use either depending on the specific situation.

METR should include pavement markings, including no passing zones and changes to lane geometry should be a part of METR.

Locally implemented/activated rules might need to be conveyed to the METR distribution system so that they can be transmitted to users at a distance to consider during trip planning.

Locally implemented/activated rules need to be conveyed to METR users in the immediate vicinity through a instant push mechanism. Some ad hoc rules might use a generic message such as "ad hoc rules in effect"

Ad Hoc rules might provide detour information as (1) a simple shift lane, (2) an indication that a turn manouver is prohibited, (3) an indication that a road or lane link is closed, or (4) a complete alternative path. In the first three cases, it is up to the DDT to determine the revised path to follow.

We need to define "regulator"

Road closures (both long-term and short-term) are in the scope of METR

Evacuations are in the scope of METR

Overrides of normal traffic control is a part of METR

METR needs to be resilient as possible in times of major disasters; nonetheless, transport user systems are responsible for safe operations even when METR is not available.

For the foreseeable future, METR should be viewed as a supplement to existing traffic control  devices rather than a replacement of those features. However, it is likely that this will evolve over time and systems need to convey the level of reliability that vehicles should have on METR data. In the near-term, it is expected to assist ADS/ADAS vehicles to discover information in advance and to more clearly disambiguate details (e.g. some text on sign might be hard to read or sign might be partially obstructed), but our assumption is that vehicles must provide for sufficiently safe operations even if conditions are not completely entered within METR when the jurisdiction claims to support METR (e.g., it should be able to detect a lane closure and respond appropriately; it should be able to detect that it is going well above the prevailing speed and slow down as needed). This might imply some operational changes in the way that emergency responders and other field crew perform their jobs.

An ADS-equipped vehicle might need some information enterred by the user; for example, whether snow chains are currently on the wheels. (while sensors might be able to assess this condition, there might be a practical need to receive confirmation from the user as well)

In some cases, authorities might disable communication systems to prevent misuse (e.g., during 7/7 in London, the authorities disabled the cellular system to prevent potential coordination among terrorists). This should receive a small mention in the ConOps somewhere. Conversely, it was mentioned that updates can become critical in some cases, such as an earthquake moving an entire roadway.

In order to provide a more seamless experience for users, a local translator needs to be able to enter information that is passed up to a more regional entity that is responsible for dissemination of rules.

METR should be able to characterize each rule with attributes such as a unique identifier, rule location (including geometry, zone, and direction), applicable targets/exceptions (e.g., affected types of users, vehicles, purposes, rights, permits, status), and conditionality (e.g., time periods in effect). The conditions and targets might vary based on time periods.

In order to implement some rules (e.g., lane locations), high precision 3D maps will be needed.

In order to automatically update systems, especially after a major incident such as an earthquake, METR regulators should be able to coordinate exception reports from the field that indicate anomalies with defined rules (e.g., roadway blocked) and issue new (perhaps temporary) rules as needed. For example, the regulator might receive rules from multiple TICs, OEMs, TMCs, and others that can be synergized into a holistic view and then new rules created.

We should perhaps contact NACTO (https://nacto.org/) to get input from local regulators.

Pedestrians, especially those with disabilities, need electronic access to travel rules, especially any changes to the infrastructure.

VRUs/VRVs need to be aware of the classes of micromobility vehicles that are allowed within each type of pathway/lane. For example, is an e-scooter allowed on the bike lane. The rules need to specify the boundaries of each lane at a level of detail that a user can determine if they are in an appropriate lane or if they need to change lanes.

Motor vehicle systems need to be aware of the location of crosswalks. Even if they have a green indication (are allowed to proceed), they are typically required to yield to pedestrians in the crosswalk (and elsewhere).

A private company (e.g., vehicle share operator) might need to issue their own rules. While they might be able to use a proprietary mechanism to disseminate this information, they might decide using METR as an open standard. The other scenario is that Mobility as a Service apps will likely be used as a primary interface into vehicle sharing and other services in the future and these apps will need access to the proprietary restrictions set up by the vehicle sharing operator.

There should be the ability for regulators to electronically convey warnings (e.g., watch for sidewalk robots) in the same sense as you can have warning signs for slow moving vehicles on motorways.

METR should be designed so that it can be expanded to aerial drones in the future if needed.

METR needs to support public transport rules and rules need to be adequetely specified (e.g., bus lanes need to clearly indicate the types of buses allowed just like bike lanes need to specify what types of micromobility are allowed).

METR should be able to convey information on the potential for obstructions on sidewalks on trash days. This should likely be posted as a "warning" for the sidewalk that coincides with the trash pickup schedule rather than attempting to publicize the rule for trash pickup. The same type of warning can be used for other conditions, such as snow on sidewalk or leaf piles in parking areas.

Should reach out to bicycle groups, especially those that can represent e-bikes and teh developers of "Mobility Data Specification (MDS)".

METR needs to be able to support rules concerning detours for micromobility and pedestrians.

METR needs to support permitting micromobility devices being permitted to operate within specific areas and perhaps constraints on how many devices in an area at one time.

Each METR component needs to be certified to ensure a trustworthy system. The accreditation/certification requirements would be defined on a national level and the oversight of the process to grant and revoke accreditation certificates would be the responsibility of an "In-Service Safety Regulator".

The rule categories should be standardized, at least for release 1, so that we do not have to define a meta-structure for disseminators to define what rules are provided.

User systems need to be able to determine the capabilities of a disseminator, including the conformance options supported and the rule categories supported (i.e., maturity) for each jurisdictional area (or geofenced area).

Users need to be able to determine the specific regulator (e.g., road authority rather than road operator) that issued a rule upon request, but does not necessarily need to be communicated as a part of the definition of every rule if this adds too much overhead.

User systems are responsible for operating safely, even when METR information is inaccurate or missing. This might require the vehicle to obtain a "minimal risk condition" (i.e., safely come to a stop)

Within our scenarios, we should assume that static rules have a one-week expiration time and that normal operation of vehicles result in their receiving an update when they are started (e.g., typically daily). In addition, it should be noted that new rules are often associated with grace periods (although this is not universal).

Users should be able to discover when they are about to enter areas without wide-area wireless coverage to ensure that they have current downloads of all of the rules that might be needed.

Each METR component needs to support non-repudiation.

Some jurisdictional entities might require some METR distribution systems and/or transport user systems to be certified or authorized. This might be a part of certifying an ADS's ODD.

METR data must be reliable and provided in a secure format.

The METR ConOps will only define "what" is needed not "how" it will be provided. Other documents will provide details about how to implement METR - and different regions might adopt different standards for these details.

Transport user systems need to know what capabilities are supported for locations which they plan to travel. These capabilities need to reflect: the types of rules supported, the jurisdictions and geofences where the information is supported, the classification of roads, vehicles, and users for which the information is supported, and whether the information includes both static and dynamic rules.

Transport user systems need to know how legally binding the METR information is; this is likely to vary based on a rule-type basis.

Map information within METR has to be able to accommodate the movement of the Earth's crust. In other words, user systems need to be able to associate map information to the physical world, even when the physical world has shifted. And the map information needs to be certified as well.

The METR ConOps should identify the need for a feedback loop, both for identifying discrepancies and for identifying potential changes in the environment (e.g., after earthquakes). These aspects of the ConOps are perhaps longer-term issues and might not be initially included in the requirements or design details.

The information provided by METR is safety critical and must be secure and trustworthy since its intended use is for controlling vehicle operations. ConOps should mention WG18 work, such as ISO 21177

METR data needs to be available to users other than the traditional transport user. For example, it needs to be available to lawyers, insurance companies, enforcement organizations, and traveller's preparing for a long journey. Different jurisdictions will likely impose different timeframes for retaining data.

Every version of METR needs to be backward compatible and the initial design of METR should plan for enhancements by supporting forward compatibility features (e.g., ability to configure the version being used, the interface standards being used for each type of rule, the encryption algorithms used, etc).

Some jurisdictions might adopt regulations that require the support of METR (and associated inspections) either for sub-jurisdictions to support METR distribution systems or for vehicles to support METR user systems. We should mention that UNECE WP 1 and WP 29 might recommend the adoption of such recommendations.

The project should coordinate with 

EU: DACH

EU: UVARBox

EU: EVARExchange

JP: Efforts with police

NO: NPRA METR project

UK: TRO Project

US: Work Zone Data Exchange

Facilities that support METR need to indicate the legal status of METR information and if the legal status is significant, the facility might need to have signs posted to warn human drivers of the need to support METR.