METR Verification System --> METR Regulation System:
verified METR information
Definitions
verified METR information (Information Flow): This flow supports the affirmation of, or reporting issues with, METR information that has been subjected to independent verification. When the METR Verification Center successfully completes its verification process, it will notify the requesting METR Regulation Center with a signed transmission.
METR Verification System (Source Physical Object): The 'METR Verification System' is responsible for providing independent verification of the rules defined by a METR Regulation System. It is represented as a distinct physical object since the verification is intended to be independently performed.
METR Regulation System (Destination Physical Object): The 'METR Regulation System' creates and maintains electronic versions of traffic regulations for eventual consumption by traveler systems and other interested parties. Once approved, each rule is signed and traceable to a specific Rule-Maker. Depending on local policies and division of labor, the METR Regulation Center might need to coordinate with a METR Verification Center, a Maintenance and Construction Management System, and METR Discrepancy Handling Centers.
Included In
This Triple is in the following Service Packages:
- None
This triple is associated with the following Functional Objects:
- None
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) (14)
- (None-Data) - Secure Internet (ITS) (32)
- (None-Data) - OASIS MQTT (42)
- (None-Data) - OASIS AMQP (45)
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 | May have some PII for internal actors in the METR system, which should not be observed as they could be used as part of phishing or related attacks. | Rules could be used to guide vehicle behavior, and if incorrect could lead to vehicles breaking actual rules with potentially highly damaging consequences. | Updates are probably infrequent so often this flow can be a less than HIGH availability. In cases of high update (e.g., work zones, incidents), it could be HIGH. |
Security Characteristics | Value |
---|---|
Authenticable | True |
Encrypt | True |