METR Regulation System --> Connected Vehicle Roadside Equipment:
METR application information
Definitions
METR application information (Information Flow): This flow is used to configure and provision RSE devices to distribute emergent METR rules.
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.
Connected Vehicle Roadside Equipment (Destination Physical Object): 'Connected Vehicle Roadside Equipment' (CV RSE) represents the Connected Vehicle roadside devices that are used to send messages to, and receive messages from, nearby vehicles using Dedicated Short Range Communications (DSRC) or other alternative wireless communications technologies. Communications with adjacent field equipment and back office centers that monitor and control the RSE are also supported. This device operates from a fixed position and may be permanently deployed or a portable device that is located temporarily in the vicinity of a traffic incident, road construction, or a special event. It includes a processor, data storage, and communications capabilities that support secure communications with passing vehicles, other field equipment, and 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
- US: NTCIP Roadside Unit - SNMPv3/TLS (7)
- (None-Data) - Secure Internet (ITS) (32)
- (None-Data) - OASIS MQTT (42)
- (None-Data) - OASIS AMQP (45)
Selected Solution
Solution Description
ITS Application Entity
Development needed |
Click gap icons for more info.
|
||
Mgmt
|
Facilities
Development needed |
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 |
---|---|
Local | In cases where an interface is normally encapsulated by a single stakeholder, interoperability is still desirable, but the motive is vendor independence and the efficiencies and choices that an open standards-based interface provides. |
Security
Information Flow Security | ||||
---|---|---|---|---|
Confidentiality | Integrity | Availability | ||
Rating | Moderate | Moderate | Low | |
Basis | This information could be of interest to a malicious individual who is attempting to determine the best way to accomplish a crime. As such it would be best to not make it easily accessible. | If this is compromised, it could send unnecessary maintenance workers, or cause the appearance of excessive traffic violations, leading to further unnecessary investigation. | A delay in reporting this may cause a delay in necessary maintenance, but (a) this is not time-critical and (b) there are other channels for reporting malfunctioning. Additionally, there is a message received notification, which means that RSE can ensure that all intersection safety issues are delivered. |
Security Characteristics | Value |
---|---|
Authenticable | True |
Encrypt | True |