24315-1 METR ConOps
N: Notes

Every role is implemented as a system or within a system that serves multiple roles

Each system needs a system manager

Explain that the regulator role includes the duties of a competent authority where they exist

The concept of modes does not really apply to our type of system of systems; identify where we define the rule states and catalogue of rules

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

The preferred implementation is that the regulator also performs the role of translator because 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.

The use of mainstream data distribution technologies should be allowed as long as they meet all defined user needs.

Automated discovery is a likely possibility but there is not a pressing need to standardize the interface or requirements.

The preferred implementation is that real-time data is exchanged in an open manner.

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

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 planned rules, indicate that they may require authorization, which might be a period of months, even though the actual implementation of the rule may just be a for a few days

Change "C-ITS data source" to "dynamic data provider"

ConOps should explain that the disseminator is distinguished from the dynamic data provider due the additional responsibilities for a disseminator (whereas a dynamic data provider has virtualy no formal responsibilities).

The ConOps should explain 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; however, the details of this process is outside the scope of METR as it occurs separate from the electronification process.

The ConOps should discuss the legal aspects of rules referring to dynamic data directly versus requiring the vehicle to make determinations. The approaches for this will likely vary by jurisdiction and METR needs to convey whether indicated providers of dynamic data accept any liability

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 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 include a scenario that discusses a vehicle detecting a discrepancy and indicate that the ownership of the discrepancy data might be subject to OEM copyright depending on jurisdiction.

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/

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

METR will result in some operational changes in the way that emergency responders and other field crew perform their jobs.

Jurisdictional entities might require sub-jurisdictions to support some aspects of METR (e.g., provision of some types of rules). This might become a topic for UNECE WP.1. 

Jurisdictional entities might require transport user systems to support some aspects of METR. This might become a topic for UNECE WP.29.

A ConOps document only defines "what" is needed not "how" it will be provided. Other documents provide details about how to implement the information contained in a ConOps, and multiple implementations can exist for the same ConOps.

The ConOps should mention the relevance of some WG18 work, such as ISO 21177.