Service Monitor System --> Vehicle Application and Service Center:
OBE fault data
Definitions
OBE fault data (Information Flow): OBE fault information that can be used to identify OBEs that require initialization, reconfiguration, repair or replacement. This flow identifies the device, the nature of the fault, and associated error codes and diagnostic data.
Service Monitor System (Source Physical Object): The 'Service Monitor System' represents one or more center-based systems that provide monitoring, management and control services necessary to other applications and/or devices operating within the Connected Vehicle Environment. These support services enable other applications to provide transportation services.
Vehicle Application and Service Center (Destination Physical Object): 'Vehicle Application and Service Center' (VSAC) represents centers that provide telematics services to vehicles using wide-area (e.g. cellular) communications, including traveler information, emergency services, vehicle diagnostics, and provision of service options for these vehicles. See also 'Transportation Information Center' that provides traveler information, trip planning, and routing services and 'Emergency Management Center' that provides call-taking and emergency response services that may also be implemented by a VASC.
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) (43)
-
(None-Data) - OMG DDS (44)
-
(None-Data) - Apache Kafka (44)
-
(None-Data) - Eclipse Zenoh (45)
-
(None-Data) - OASIS MQTT (50)
-
(None-Data) - OASIS AMQP (61)
Selected Solution
(None-Data) - Eclipse ZenohSolution Description
|
ITS Application Entity
 
Development needed  |
Click gap icons for more info.
|
||
|
Mgmt
Eclipse Zenoh |
Facilities
 
Development needed Eclipse Zenoh |
Security
IETF RFC 8446 |
|
|
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 | Regional |
| Acknowledgement | True |
| Cardinality | Unicast |
| Initiator | Source |
| Authenticable | True |
| Encrypt | True |
| Interoperability | Description |
|---|---|
| Regional | Interoperability throughout the geopolitical region is highly desirable, but if implemented differently in different transportation management jurisdictions, significant benefits will still accrue in each jurisdiction. Regardless, this Information Flow Triple should be implemented consistently within a transportation jurisdiction (i.e., the scope of a regional architecture). |
Security
| Information Flow Security | ||||
|---|---|---|---|---|
| Confidentiality | Integrity | Availability | ||
| Rating | Moderate | Moderate | Moderate | |
| Basis | Device status information should not be viewable by third parties, as those with criminal intent may use this information toward their own ends. | If incorrect or changed, could lead to inappropriate maintenance activity, which has a significant cost in itself and contributes negatively to system operational status. Scope is small, but impact significant if this occurs with many instances. | A delay in reporting this may cause a delay in necessary maintenance. Considered higher availability requirement than the source flow (RSE status) because this information aggregates many instances of the source. | |
| Security Characteristics | Value |
|---|---|
| Authenticable | True |
| Encrypt | True |