Border Inspection System --> Commercial Vehicle Check Equipment:
inspection results
Definitions
inspection results (Information Flow): Report of results of border inspection on a particular load.
Border Inspection System (Source Physical Object): 'Border Inspection System' represents data systems used at the border for the inspection of people or goods. It supports immigration, customs (trade), agricultural, and FDA inspections as applicable. It includes sensors and surveillance systems to identify and classify drivers and their cargo as they approach a border crossing, the systems used to interface with the back-office administration systems and provide information on status of the crossing or events.
Commercial Vehicle Check Equipment (Destination Physical Object): 'Commercial Vehicle Check Equipment' supports automated vehicle identification at mainline speeds for credential checking, roadside safety inspections, and weigh-in-motion using two-way data exchange. These capabilities include providing warnings to the commercial vehicle drivers, their fleet managers, and proper authorities of any safety problems that have been identified, accessing and examining historical safety data, and automatically deciding whether to allow the vehicle to pass or require it to stop with operator manual override. Commercial Vehicle Check Equipment also provides supplemental inspection services such as expedited brake inspections, the use of operator hand-held devices, mobile screening sites, on-board safety database access, and the enrollment of vehicles and carriers in the electronic clearance program.
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) - Secure Internet (ITS) (32)
- (None-Data) - Apache Kafka (36)
- (None-Data) - OMG DDS (36)
- (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 | Adjacent |
Acknowledgement | True |
Cardinality | Unicast |
Initiator | Destination |
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 could contain information on what is in a particular load. As such it could be used by a malicious individual to determine which vehicles are a greater target then the rest. | Some minimal guarantee of data integrity is necessary for all C-ITS flows. This is an informational message and as such any errors in it should not affect anything. If this has higher integrity though then it will be more likely to be useful. DISC: Original V2I analysis classified this as LOW. | This information requires an acknowledgment of receipt, but if a message is missed it could be sent again at a later time without any impact on the rest of the system. |
Security Characteristics | Value |
---|---|
Authenticable | True |
Encrypt | True |