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 -