METR Regulation System --> METR Verification System:
unverified METR information
Definitions
unverified METR information (Information Flow): This flow requests the verification of an item of METR information by an independent METR Verification Center.
METR Regulation System (Source 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.
METR Verification System (Destination 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.
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
OMG DDS |
Facilities
(None) OMG DDS OMG DDS-RPC OMG DDSI-RTPS |
Security
OMG DDS-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 |