24315 METR
SP: Summary Points


Last modified on 2022-02-15 12:56
Submit Comment
Traceability Tables:
NOTE: The RSR, DSR, CSR, DHSR, MDR, and ITS-SUR are still in very preliminary draft form
ID Description Discussion Links
SP-2
Road vehicles should support short-range…
SP-3
Some users might not be connected to MET…
SP-4
All ~mobile~ METR-enabled transport user…
SP-5
Mobile wireless internet is not guarante…
SP-6
Mobile wireless internet might not be av…
SP-7
METR should support user systems that mi…
SP-8
Users have a need to indicate their pref…
SP-9
User systems might support the ability t…
SP-10
METR should support ordinary traffic (i.…
SP-11
METR should cover the full scope of surf…
SP-12
Need to support rules related to specifi…
SP-13
Trustworthiness should include non-repud…
SP-14
METR should indicate the level of legal …
SP-15
Users should have a way to report discre…
SP-16
We should emphasize that the types of re…
SP-17
Some regions might wish to have a system…
SP-18
Should provide sample diagrams showing i…
SP-19
The role model should add a role between…
SP-20
The ConOps should provide practical use …
SP-21
The ConOps needs to identify accountabil…
SP-22
The concept of modes does not seem to ap…
SP-23
State of rules in force on the transport…
SP-24
State of rule availability should be cap…
SP-25
The ConOps should reference ISO/IEC/IEEE…
SP-26
All rules should be defined in a languag…
SP-27
METR should be based on a centralized pu…
SP-28
It should be the responsibility of the u…
SP-29
Each METR rule (e.g., give way to emerge…
SP-30
Withdrawn/rescinded rules need to be pub…
SP-31
METR will rely upon existing standards w…
SP-32
User systems need high confidence that t…
SP-33
Development team needs to contact field …
SP-34
Use of push should be minimized while st…
SP-35
Push is probably needed for coordination…
SP-36
Hierarchy of rules should support the co…
SP-37
Pull process must support filtering
SP-38
Centralized dynamic rules either need tr…
SP-39
Filtering should include almost all para…
SP-40
There is a lack of consistent terminolog…
SP-41
The definition of a "regulator" needs to…
SP-42
ConOps should explain that all component…
SP-43
The ConOps needs to assign the responsib…
SP-44
The preferred implementation is that the…
SP-45
The preferred implementation is that a u…
SP-46
Peer roles need the ability to coordinat…
SP-47
METR must provide accountability such th…
SP-48
Disseminators need to be able to share c…
SP-49
A mobile refresh provider should be char…
SP-50
Need to be able to filter rules based on…
SP-51
The feedback loop needs to include the r…
SP-52
The ConOps should be written to allow fo…
SP-53
The ConOps should mention that automated…
SP-54
METR should distinguish between "rules" …
SP-55
To the extent that C-ITS data is exchang…
SP-56
There needs to be a fifth catalogue stat…
SP-57
Validity should apply to rules; we need …
SP-58
User privacy needs to be protected, espe…
SP-59
Australia will be issuing a report soon …
SP-60
Need examples that can be presented to g…
SP-61
The disseminator is responsible for ensu…
SP-62
Users need a way to discover disseminato…
SP-63
When showing multiplicity in diagrams ot…
SP-64
METR filtering needs to accommodate the …
SP-65
Remove the rule types from the state mac…
SP-66
When discussing rule types, we need to c…
SP-67
When discussing planned rules, indicate …
SP-68
User requests should be confidential and…
SP-69
See slide for examples of rule character…
SP-70
METR should allow rule characteristcis t…
SP-71
Evacuation plans should be distributed i…
SP-72
The disseminator is responsible for publ…
SP-73
The user is responsible for requesting a…
SP-74
All roles are responsible for 1) identif…
SP-75
The term "C-ITS data source" should perh…
SP-76
The ConOps should describe why we are di…
SP-77
The ConOps should provide a brief mentio…
SP-78
The ConOps should explain that rules mig…
SP-79
What is the legal standing of C-ITS data…
SP-80
The ConOps should explain that the rule …
SP-81
The ConOps should include a use case tha…
SP-82
The ConOps should also include a use cas…
SP-83
The "when" responsibility should apply t…
SP-84
We need to indicate that each system nee…
SP-85
Clarify text of responsibilities (as sho…
SP-86
Some conditions might require dynamic da…
SP-87
The ConOps should describe a process by …
SP-88
The ConOps should allow flexibility for …
SP-89
The ConOps should allow any vehicle (tha…
SP-90
A vehicle reporting a conflict should ha…
SP-91
A disseminator should not publicize repo…
SP-92
The ConOps should probably stay agnostic…
SP-93
A rule refresh should only provide the c…
SP-94
Each individual rule should have its own…
SP-95
The ConOps should provide an example of …
SP-96
Unless otherwise indicated, the ConOps s…
SP-97
The ConOps should indicate that we assum…
SP-98
The ConOps should provide an example use…
SP-99
The ConOps should indicate that for the …
SP-100
Any remote refresh would have to be prov…
SP-101
The ConOps should allow the definition o…
SP-102
Vehicle types regulated by a jurisdictio…
SP-103
The characteristics used by a jurisdicti…
SP-104
Road types regulated by a jurisdiction n…
SP-105
METR needs to convey the location for ev…
SP-106
METR needs to support rules that charact…
SP-107
METR users need to be able to identify w…
SP-108
METR does not need to convey the graphic…
SP-109
The METR ConOps will be written so that …
SP-110
METR needs to be able to advertise when …
SP-111
Characteristics should include permits, …
SP-112
All rules should be signed by the transl…
SP-113
Conform to the terminology of ISO 22736 …
SP-114
Rules provided by METR should be complet…
SP-115
When any conflict is discovered, it shou…
SP-116
We should use the terms "low latency" an…
SP-117
Look at CEN ISO/TS 17426 Contextual spee…
SP-118
The operational scenarios should provide…
SP-119
In order to be trustworthy and relied up…
SP-120
In order to claim support for any rule d…
SP-121
Users need to be aware of when they shou…
SP-122
Regulators might establish rules that re…
SP-123
Responders and field crews often have ne…
SP-124
Between METR and the map data, ADS-equip…
SP-125
METR needs to be able to indicate how co…
SP-126
METR providers might need to be certifie…
SP-127
Identification and responding to dynamic…
SP-128
METR cannot rely on just one path for da…
SP-129
Identification of the disseminator is ou…
SP-130
The ConOps should structure at least one…
SP-131
The ConOps should indicate the importanc…
SP-132
The ConOps might include a scenario with…
SP-133
Define "static rule", "dynamic rule" and…
SP-134
Distinguish between "governmental" and "…
SP-135
We need an example scenario that describ…
SP-136
Transport user systems need insights int…
SP-137
Need to support (and convey to users) th…
SP-138
Users need all rules to be digitally sig…
SP-139
METR needs to be able to accommodate hig…
SP-140
METR needs to be able to accommodate roa…
SP-141
METR needs to be able to accommodate jur…
SP-142
METR needs to be able to accommodate enf…
SP-143
METR needs to be able to accommodate ind…
SP-144
It might be worth including an optional …
SP-145
Within one of its scenarios, the METR Co…
SP-146
METR rules need to define areas reserved…
SP-147
Within one of its scenarios, the METR Co…
SP-148
METR needs to provide a way to link rule…
SP-149
METR needs to provide a way for the vehi…
SP-150
A METR operational scenario should indic…
SP-151
METR should provide a way for an entity …
SP-152
Process to deploy known rules includes p…
SP-153
METR needs to support both permits that …
SP-154
METR should include pavement markings, i…
SP-155
Locally implemented/activated rules migh…
SP-156
Locally implemented/activated rules need…
SP-157
Ad Hoc rules might provide detour inform…
SP-158
We need to define "regulator"
SP-159
Road closures (both long-term and short-…
SP-160
Evacuations are in the scope of METR
SP-161
Overrides of normal traffic control is a…
SP-162
METR needs to be resilient as possible i…
SP-163
For the foreseeable future, METR should …
SP-164
An ADS-equipped vehicle might need some …
SP-165
In some cases, authorities might disable…
SP-1
In order to provide a more seamless expe…
SP-166
METR should be able to characterize each…
SP-167
In order to implement some rules (e.g., …
SP-168
In order to automatically update systems…
SP-169
We should perhaps contact NACTO (https:/…
SP-170
Pedestrians, especially those with disab…
SP-171
VRUs/VRVs need to be aware of the classe…
SP-172
Motor vehicle systems need to be aware o…
SP-173
A private company (e.g., vehicle share o…
SP-174
There should be the ability for regulato…
SP-175
METR should be designed so that it can b…
SP-176
METR needs to support public transport r…
SP-177
METR should be able to convey informatio…
SP-178
Should reach out to bicycle groups, espe…
SP-179
METR needs to be able to support rules c…
SP-180
METR needs to support permitting micromo…
SP-181
Each METR component needs to be certifie…
SP-182
The rule categories should be standardiz…
SP-183
User systems need to be able to determin…
SP-184
Users need to be able to determine the s…
SP-185
User systems are responsible for operati…
SP-186
Within our scenarios, we should assume t…
SP-187
Users should be able to discover when th…
SP-188
Each METR component needs to support non…
SP-189
Some jurisdictional entities might requi…
SP-190
METR data must be reliable and provided …
SP-191
The METR ConOps will only define "what" …
SP-192
Transport user systems need to know what…
SP-193
Transport user systems need to know how …
SP-194
Map information within METR has to be ab…
SP-195
The METR ConOps should identify the need…
SP-196
The information provided by METR is safe…
SP-197
METR data needs to be available to users…
SP-198
Every version of METR needs to be backwa…
SP-199
Some jurisdictions might adopt regulatio…
SP-200
The project should coordinate with EU: D…
SP-201
Facilities that support METR need to ind…