Freight Equipment --> Emergency Vehicle OBE:
container manifest
Definitions
container manifest (Information Flow): Official statement of the cargo held in a container.
Freight Equipment (Source Physical Object): 'Freight Equipment' represents a freight container, intermodal chassis, or trailer and provides sensory, processing, storage, and communications functions necessary to support safe, secure and efficient freight operations. It provides equipment safety data and status and can alert the appropriate systems of an incident, breach, or tamper event. It also provides accurate position information to support in-transit visibility of freight equipment.
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:
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) - Local Unicast Wireless (1609.2) (35)
Selected Solution
Solution Description
|
ITS Application Entity
Development needed  |
Click gap icons for more info.
|
||
|
Mgmt
Addressed Elsewhere |
Facilities
Development needed |
Security
|
|
|
TransNet
IEEE 1609.3 |
|||
|
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 | Adjacent |
| Acknowledgement | False |
| Cardinality | Unicast |
| Initiator | Destination |
| 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 | Possibly competetive information. Definitely has value, and if availble to actors with competing interests to the actors legitimately involved with the container, information as to where the container is and is projected to be at different times could be abused to the actor's advantage.For high value containers, this may be HIGH. | Given that this data is likely used only in the case of an incident or other emergency, its accuracy is paramount to the safety of all involved. | Would be nice to make this HIGH considering the safety implications in case of HAZMAT containers, but considering the context of an incident, HIGH is likely impractical for this wireless signal in a vehicular environment. | |
| Security Characteristics | Value |
|---|---|
| Authenticable | True |
| Encrypt | True |