Other PIDs --> Personal Information Device:
emergency acknowledge

This triple is bi-directional. See also Personal Information Device --> Other PIDs: emergency acknowledge

Definitions

emergency acknowledge (Information Flow): Acknowledge request for emergency assistance and provide additional details regarding actions and verification requirements.

Other PIDs (Source Physical Object): 'Other PIDs' represents other personal information devices (PIDs) that are communicating with the device. This includes all connected personal information devices that support wireless short-range communications, including those used by pedestrians, cyclists, and other vulnerable road users (VRUs). This object provides a source and destination for information transfers between connected personal devices. The host device, represented by the Personal Information Device physical object, sends information to, and receives information from the Other PIDs to model all connected personal-to-personal (P2P) communications in ARC-IT.

Personal Information Device (Destination Physical Object): The 'Personal Information Device' provides the capability for travelers to receive formatted traveler information wherever they are. Capabilities include traveler information, trip planning, and route guidance. Frequently a smart phone, the Personal Information Device provides travelers with the capability to receive route planning and other personally focused transportation services from the infrastructure in the field, at home, at work, or while en-route. Personal Information Devices may operate independently or may be linked with vehicle on-board equipment. This subsystem also supports safety related services with the capability to broadcast safety messages and initiate a distress signal or request for help.

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

Solutions are sorted in ascending Gap Severity order. The Gap Severity is the parenthetical number at the end of the solution.

Selected Solution

Data for Distribution (TBD) - OASIS AMQP over Wireless

Solution Description

This solution is used within the E.U. and the U.S.. It combines standards associated with Data for Distribution (TBD) with those for OASIS AMQP over Wireless. The Data for Distribution (TBD) standards include a placeholder for upper-layer standards necessary to define the data (elements and structures) necessary to complete a solution for the information flow based on data distribution technologies. The data standard will need to include a specific customization for the desired data distribution technology used (e.g., Kafka, DDS, etc.).. The OASIS AMQP over Wireless standards include lower-layer standards that support data distribution of specific types of data over wireless links.

ITS Application Entity
Mind the gap

Development needed
Click gap icons for more info.
Mgmt
Mind the gap

Development needed
Facilities
Mind the gapMind the gap

OASIS AMQP
Security
Mind the gapMind the gap
TransNet
Access
Mind the gapMind the gapMind the gap
TransNet TransNet

TempBCL2 TempSTDL2

TempBCL3 TempSTDL3

TempBCL4 TempSTDL4

TempBCL5 TempSTDL5

Access Access

TempBCL2 TempSTDL2

TempBCL3 TempSTDL3

TempBCL4 TempSTDL4

TempBCL5 TempSTDL5

ITS Application ITS Application

TempBCL2 TempSTDL2

TempBCL3 TempSTDL3

TempBCL4 TempSTDL4

TempBCL5 TempSTDL5

Mgmt Mgmt

TempBCL2 TempSTDL2

TempBCL3 TempSTDL3

TempBCL4 TempSTDL4

TempBCL5 TempSTDL5

Facility Facility

TempBCL2 TempSTDL2

TempBCL3 TempSTDL3

TempBCL4 TempSTDL4

TempBCL5 TempSTDL5

Security Security

TempBCL2 TempSTDL2

TempBCL3 TempSTDL3

TempBCL4 TempSTDL4

TempBCL5 TempSTDL5

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 False


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 Low Moderate Low
Basis As the request for emergency assistance is by definition going to be a broadcast, the response can be reasonably assumed as not containing any personal information. An incorrect message may mislead the originator of the emergency request, which could affect his behavior If this flow is not delivered the worst case is probably that the originator of the emergency request keeps asking for emergency assistance. There may be some channel loading issues, but unlikely to require anything beyond LOW.


Security Characteristics Value
Authenticable True
Encrypt False