METR System --> Other METR Systems:
METR coordination
This triple is bi-directional. See also
Other METR Systems --> METR System: METR coordination
Definitions
METR coordination (Information Flow): This flow supports the free form exchange of messages, information or data enabling METR components to raise awareness and foster resolution to overlaps, discrepancies or issues that impact METR's mission to provide trustworthy information to METR users. Also used to resolve interpretation and consistency issues.
METR System (Source Physical Object): The 'METR System' creates and maintains electronic versions of traffic rules, regulations, ordinances and statutes that have official status and must be understood by all motor vehicle operators and intelligent vehicles that operate at higher automation levels. This system represents multiple authorities that operate at local, regional, state, and national levels and represents organizations that establish, manage, and enact the traffic code. Each electronic rule is approved, signed, and traceable to a specific rule-maker. Rules are independently verified. Any identified or reported rule discrepancies are analyzed, investigated, and addressed.
Other METR Systems (Destination Physical Object): The 'Other METR System' represents...
Included In
This Triple is in the following Service Packages:
This triple is associated with the following Functional Objects:
This Triple is described by the following Functional View Data Flows:
- None
This Triple has the following triple relationships:
None |
Communication Solutions
- METR: Regulation Requirements - Secure Internet (ITS) (22)
- (None-Data) - Secure Internet (ITS) (43)
- Data for Distribution (TBD) - Apache Kafka (44)
- Data for Distribution (TBD) - OMG DDS (44)
- Data for Distribution (TBD) - OASIS MQTT (50)
- Data for Distribution (TBD) - OASIS AMQP (61)
Selected Solution
Solution Description
ITS Application Entity
ISO 24315-4 ISO 24315-8 |
Click gap icons for more info.
|
||
Mgmt
OASIS MQTT DMP |
Facilities
(None) OASIS MQTT |
Security
|
|
TransNet
|
|||
Access
Internet Subnet Alternatives |
Note that some layers might have alternatives, in which case all of the gap icons associated with every alternative may be shown on the diagram, but the solution severity calculations (and resulting ordering of solutions) includes only the issues associated with the default (i.e., best, least severe) alternative.
Characteristics
Characteristic | Value |
---|---|
Time Context | Recent |
Spatial Context | Regional |
Acknowledgement | True |
Cardinality | Unicast |
Initiator | Source |
Authenticable | True |
Encrypt | True |
Interoperability | Description |
---|---|
Regional | Interoperability throughout the geopolitical region is highly desirable, but if implemented differently in different transportation management jurisdictions, significant benefits will still accrue in each jurisdiction. Regardless, this Information Flow Triple should be implemented consistently within a transportation jurisdiction (i.e., the scope of a regional architecture). |
Security
Information Flow Security | ||||
---|---|---|---|---|
Confidentiality | Integrity | Availability | ||
Rating | Moderate | High | Moderate | |
Basis | The scope of coordination could expose some of the inner workings that imply policy or technical workings that could be used negatively against METR subsystems. While it would be ideal if METR operations were completely transparent, at least in early phases it is likely that coordination activies are in flux and could be taken out of context. There is no legitimate reason to observe this information regardless. | This information may eventually (once it is reconciled throughout the METR system) be used to guide driver and AV behavior; incorrect or manipulated information could result in a vehicle performing a traffic movement that is not permitted, which in some cases (e.g., right turn on red) could be quite dangerous. | Discrepancy management should ideally always be functioning, but especially early on as METR deployments evolve, it is unreasonable to expect, and would have minimal impact, if discrepancy related flows were reasonably available. HIGH may be viable in the future, and may be necessary if automated vehicles depend on METR information to be consistently correct at all times. |
Security Characteristics | Value |
---|---|
Authenticable | True |
Encrypt | True |