Connectivity Framework Annex A: Assessment Template: DDS
A. 6.5 Implementation Viewpoint A. 6.5.1 System Architecture Considerations
Peer-to-Peer vs. Broker:
( Section 4.2.1.1)
Data-Centric vs. Device / App-Centric:( Section 4.2.1.2)
Explicit vs. Implicit Governance:( Section 4.2.1.3)
A. 6.5.2 Data Considerations
Content-Based Selection( Section 4.2.2.1)
Time-Based Selection( Section 4.2.2.2)
A. 6.5.3 Performance Considerations
Real-Time( Section 4.2.3.1)
Latency and Jitter vs. Throughput( Section 4.2.3.2)
Does the connectivity framework require running a special process or broker?
This is implementation specific. There are DDS implementations that do not require running a separate process or broker. An application, by linking to a DDS library becomes an active participant in the data exchange. There are no other process dependencies.
Does the application code( or business logic) have to be aware of the other endpoints in order to participate in information exchange?
No, the application code( or business logic) does not have to be aware of other endpoints to participate in a data exchange. Applications interact directly with the databus( data objects organized into DDS-Topics) and never directly with each other. Is the governance explicit and shareable?
DDS does not require the governance to be implicit, and allows system architects to choose the style of governance. The data types are always explicitly defined, the data flows and the quality of service configuration may be defined implicitly or explicitly, and the data security configuration is always explicitly defined.
Can a content-filter specify the data subset of interest?
Yes, a DDS-ContentFiteredTopic can be used to subscribe to only a subset of data from a DDS-Topic. Can sub-sampling specify the data subset of interest?
Yes, a TIMEBASEDFILTER QoS policy can be used to subscribe to a subsampled subset of the data.
Does the connectivity technology support real-time data distribution? Is the latency deterministic( smaller jitter is better)?
This is dependent on the underlying hardware transport. Within the transport limits, DDS supports real-time data distribution. It was specifically designed to support the needs of real-time distributed systems and includes several QoS policies real-time data distribution. DDS also can notify applications of delays, allowing the application to adapt to the situation.
Several DDS implementations have been documented have very low latency(< 1ms) and very low jitter(ยต s). How does the latency and jitter change with throughput? What limits the throughput?
The variation of latency and jitter with throughput will be implementation specific, based on the design trade-offs made by that implementation. Leading DDS implementations have been documented to have minimal change in jitter as throughput increases. Implementations can achieve throughput as high as 95 % of the theoretical network bandwidth.
IIC: PUB: G5: V1.0: PB: 20170228- 69-