Connected Vehicle Roadside Equipment --> Wayside Equipment:
rail crossing blockage notification
Definitions
rail crossing blockage notification (Information Flow): Notification that a highway-rail intersection is obstructed and supporting information.
Connected Vehicle Roadside Equipment (Source 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.
Wayside Equipment (Destination Physical Object): 'Wayside Equipment' represents train interface equipment (usually) maintained and operated by the railroad and (usually) physically located at or near a grade crossing. It is a source and destination for information for, or about, approaching trains and their crews (e.g. the time at which the train will arrive and the time it will take to clear a crossing, crossing status or warnings, etc.). Generally one wayside equipment interface would be associated with one highway rail intersection. However, multiple crossings may be controlled using information based on data from one wayside equipment interface.
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:
This Triple has the following triple relationships:
None |
Communication Solutions
-
(None-Data) - Guaranteed Secure Internet (ITS) (32)
Selected Solution
![](../../images/flags/au.png)
![](../../images/flags/eu.png)
![](../../images/flags/us.png)
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 | Adjacent |
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 | High | High | |
Basis | Contains information that may be predictive of a serious traffic/rail incident. For privacy purposes, this should probably not be advertised. | Data predictive of potentially catastrophic incident needs to be correct so that appropriate actions are taken. | This is a high priority to the vehicle blocking the HRI. Impact is not broad, but very severe. Hard to justify a MODERATE given the consequences. |
Security Characteristics | Value |
---|---|
Authenticable | True |
Encrypt | True |