METR Regulation System --> Emergency Vehicle OBE:
METR management information
Definitions
METR management information (Information Flow): If the rule is to be distributed through a specialized vehicle OBE, the METR input device configures and monitors the OBE using the METR management info. While the content of this flow is similar to a combination of the "METR application information" flow and the "METR application status" flow, the mobile nature of the OBE results in different communication characteristics, which results in a different flow.
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.
Emergency Vehicle OBE (Destination Physical Object): The 'Emergency Vehicle On-Board Equipment' (OBE) resides in an emergency vehicle and provides the processing, storage, and communications functions that support public safety-related connected vehicle applications. It represents a range of vehicles including those operated by police, fire, and emergency medical services. In addition, it represents other incident response vehicles including towing and recovery vehicles and freeway service patrols. It includes two-way communications to support coordinated response to emergencies. A separate 'Vehicle OBE' physical object supports the general vehicle safety and driver information capabilities that apply to all vehicles, including emergency vehicles. The Emergency Vehicle OBE supplements these general capabilities with capabilities that are specific to emergency vehicles.
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 - Wireless SNMPv3/TLS (7)
- (None-Data) - Secure Wireless Internet (EU) (32)
- (None-Data) - OASIS MQTT over Wireless (42)
- (None-Data) - OASIS AMQP over Wireless (45)
Selected Solution
Solution Description
ITS Application Entity
NTCIP 1218 |
Click gap icons for more info.
|
||
Mgmt
|
Facilities
|
Security
IETF RFC 6353 |
|
TransNet
|
|||
Access
|
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 |
---|---|
National | This triple should be implemented consistently within the geopolitical region through which movement is essentially free (e.g., the United States, the European Union). |
Security
Information Flow Security | ||||
---|---|---|---|---|
Confidentiality | Integrity | Availability | ||
Rating | Moderate | High | Moderate | |
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 result in incorrect rule-related information distribution, which could in turn cause a safety or other serious issue. | Occasional outages will be inconvenient but in all cases, safe fallbacks should exist. |
Security Characteristics | Value |
---|---|
Authenticable | True |
Encrypt | True |