data publication (Information Flow): Data publication includes those dialogs necessary to satisfy the publication portion of a data distribution architecture. The information content varies widely based on available content and the subscription, but it generally includes information on the state of transportation system operations including traffic and road conditions, advisories, incidents, transit service information, weather information, parking information, and other related data.
Other Data Distribution Systems (Source Physical Object): Representing another Data Distribution System, 'Other Data Distribution Systems' is intended to provide a source and destination for information exchange between peer (e.g. inter-regional) data distribution systems. It supports modeling of projects or regions that include multiple interconnected data distribution systems that together manage data distribution in the connected vehicle environment.
Data Distribution System (Destination Physical Object): The 'Data Distribution System' collects, processes, and distributes ITS data, connecting data producers with data consumers and facilitating data exchange.
This Triple is in the following Service Packages:
This Triple is described by the following Functional View Functional Objects:
This Triple is described by the following Functional View Data Flows:
This Triple has the following triple relationships:
- Data for Distribution (TBD) - Apache Kafka (36)
- Data for Distribution (TBD) - OASIS MQTT (42)
- Data for Distribution (TBD) - OASIS AMQP (45)
ITS Application Entity
Click gap icons for more info.
IETF RFC 8446
IETF RFC 9293
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.
|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).
|Information Flow Security
|This value is derived from the specific flows satisfied by this super-flow. HIGH is set because some flows may require it. If the implementation includes flows with only a MODERATE or LOW confidentiality requirement, then this could be MODERATE or LOW, as appropriate.
|This value is derived from the specific flows satisfied by this super-flow. HIGH is set because some flows may require it. If the implementation includes flows with only a MODERATE integrity requirement, then this could be MODERATE.
|This value is derived from the specific flows are satisfied by this super-flow. MODERATE is set because some flows may require it. If the implementation includes flows with only a LOW availability requirement, then this could be LOW. HIGH is not considered; any flow requiring HIGH availability will not use DDS.