当前位置： 首页 > ops >正文

【FastDDS】 Entity Policy 之 标准Qos策略

ops 2025/9/7 14:12:20

服务质量（QoS）用于指定服务的行为，允许用户定义每个实体的运作方式。为提高系统的灵活性，QoS被分解为多个可独立配置的QoS策略。不过，在某些情况下，多个策略可能会产生冲突。这些冲突会通过QoS设置函数返回的返回码通知用户。

每个QoS策略在QosPolicyId_t枚举器中都有一个唯一的ID。该ID在某些状态实例中用于标识状态所涉及的特定QoS策略。

有些QoS策略是不可变的，这意味着它们只能在实体创建时或调用启用操作之前进行指定。

每个DDS实体都有一组特定的QoS策略，这些策略可以是标准QoS策略、XTypes扩展策略和eProsima扩展策略的组合。

3.1.2.1. 标准QoS策略

本节将详细介绍每个DDS标准QoS策略：

3.1.2.1.1. DeadlineQosPolicy（截止时间QoS策略）

当新样本的生成频率低于特定阈值时，此QoS策略会发出警报。它适用于需要定期更新数据的场景（参见DeadlineQosPolicy）。

在发布端，截止时间定义了应用程序应提供新样本的最大周期。在订阅端，它定义了应接收新样本的最大周期。

对于带键的主题，此QoS按键应用。假设需要定期发布某些车辆的位置，在这种情况下，可以将车辆ID设置为数据类型的键，并将截止时间QoS设置为期望的发布周期。

QoS策略数据成员列表：

数据成员名称类型默认值
periodDuration_tc_TimeInfinite

注意
此QoS策略适用于Topic、DataReader和DataWriter实体。它可以在已启用的实体上进行修改。

警告
要使DataWriter和DataReader匹配，它们必须遵循兼容性规则。有关详细信息，请参见兼容性规则。

兼容性规则

为了保持DataReader和DataWriter中DeadlineQosPolicy的兼容性，提供的截止周期（在DataWriter上配置）必须小于或等于请求的截止周期（在DataReader上配置），否则，这些实体将被视为不兼容。

DeadlineQosPolicy必须与TimeBasedFilterQosPolicy保持一致，这意味着截止周期必须大于或等于最小间隔。

示例

C++

// 此示例使用DataWriter，但它也可应用于DataReader和Topic实体DataWriterQos writer_qos;// DeadlineQosPolicy默认构造为无限周期
// 将周期更改为1秒
writer_qos.deadline().period.seconds = 1;
writer_qos.deadline().period.nanosec = 0;// 在创建相应实体时使用修改后的QoS
writer_ = publisher_->create_datawriter(topic_, writer_qos);

XML

<data_writer profile_name="writer_xml_conf_deadline_profile"><qos><deadline><period><sec>1</sec></period></deadline></qos>
</data_writer><data_reader profile_name="reader_xml_conf_deadline_profile"><qos><deadline><period><sec>1</sec></period></deadline></qos>
</data_reader>

3.1.2.1.2. DestinationOrderQosPolicy（目标顺序QoS策略）

警告
此QoS策略将在未来版本中实现。

多个DataWriter可以使用相同的键向同一个主题发送消息，而在DataReader端，所有这些消息都存储在同一个数据实例中（参见DestinationOrderQosPolicy）。此QoS策略控制用于确定这些消息逻辑顺序的标准。系统的行为取决于DestinationOrderQosPolicyKind的值。

QoS策略数据成员列表：

数据成员名称类型默认值
kindDestinationOrderQosPolicyKindBY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS

注意
此QoS策略适用于Topic、DataReader和DataWriter实体。它不能在已启用的实体上进行修改。

警告
要使DataWriter和DataReader匹配，它们必须遵循兼容性规则。有关详细信息，请参见兼容性规则。

DestinationOrderQosPolicyKind

有两个可能的值（参见DestinationOrderQosPolicyKind）：

  • BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS：表示数据根据每个DataReader的接收时间排序，这意味着应保留最后接收的值。此选项可能导致每个DataReader最终得到不同的最终值，因为DataReader可能在不同时间接收数据。
  • BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS：表示数据根据消息发送时的DataWriter时间戳排序。此选项保证最终值的一致性。

这两个选项都取决于OwnershipQosPolicy和OwnershipStrengthQosPolicy的值，这意味着如果Ownership设置为EXCLUSIVE，且最后一个值来自具有低所有权强度的DataWriter，它将被丢弃。

兼容性规则

当DataReader和DataWriter的DestinationOrderQosPolicy具有不同的kind值时，为了保持兼容性，DataWriter的kind必须大于或等于DataReader的kind。不同kind之间的顺序为：
BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS < BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS

可能的组合表：

DataWriter kindDataReader kind兼容性
BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOSBY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS是
BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOSBY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS否
BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOSBY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS是
BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOSBY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS是

3.1.2.1.3. DurabilityQosPolicy（持久性QoS策略）

即使网络上没有DataReader，DataWriter也可以通过主题发送消息。此外，在某些数据已被写入后才加入主题的DataReader可能有兴趣访问该信息（参见DurabilityQosPolicy）。

DurabilityQoSPolicy定义了系统对于DataReader加入之前主题上存在的样本的行为。系统的行为取决于DurabilityQosPolicyKind的值。

QoS策略数据成员列表：

数据成员名称类型默认值
kindDurabilityQosPolicyKindDataReader为VOLATILE_DURABILITY_QOS；DataWriter为TRANSIENT_LOCAL_DURABILITY_QOS

注意
此QoS策略适用于Topic、DataReader和DataWriter实体。它不能在已启用的实体上进行修改。

重要
为了在DataReader中接收过去的样本，除了设置此QoS策略外，还要求将ReliabilityQosPolicy设置为RELIABLE_RELIABILITY_QOS。

警告
要使DataWriter和DataReader匹配，它们必须遵循兼容性规则。有关详细信息，请参见兼容性规则。

DurabilityQosPolicyKind

有四个可能的值（参见DurabilityQosPolicyKind）：

  • VOLATILE_DURABILITY_QOS：忽略过去的样本，加入的DataReader接收在其匹配之后生成的样本。
  • TRANSIENT_LOCAL_DURABILITY_QOS：当新的DataReader加入时，其历史记录中会填充过去的样本。
  • TRANSIENT_DURABILITY_QOS：当新的DataReader加入时，其历史记录中会填充过去的样本，这些样本存储在持久存储中（参见持久化服务）。
  • PERSISTENT_DURABILITY_QOS：当新的DataReader加入时，其历史记录中会填充过去的样本，这些样本存储在持久存储中（参见持久化服务）。

兼容性规则

当DataReader和DataWriter的DurabilityQosPolicy具有不同的kind值时，为了保持兼容性，DataWriter的kind必须大于或等于DataReader的kind。不同kind之间的顺序为：
VOLATILE_DURABILITY_QOS < TRANSIENT_LOCAL_DURABILITY_QOS < TRANSIENT_DURABILITY_QOS < PERSISTENT_DURABILITY_QOS

可能的组合表：

DataWriter kindDataReader kind兼容性
VOLATILE_DURABILITY_QOSVOLATILE_DURABILITY_QOS是
VOLATILE_DURABILITY_QOSTRANSIENT_LOCAL_DURABILITY_QOS否
VOLATILE_DURABILITY_QOSTRANSIENT_DURABILITY_QOS否
TRANSIENT_LOCAL_DURABILITY_QOSVOLATILE_DURABILITY_QOS是
TRANSIENT_LOCAL_DURABILITY_QOSTRANSIENT_LOCAL_DURABILITY_QOS是
TRANSIENT_LOCAL_DURABILITY_QOSTRANSIENT_DURABILITY_QOS否
TRANSIENT_DURABILITY_QOSVOLATILE_DURABILITY_QOS是
TRANSIENT_DURABILITY_QOSTRANSIENT_LOCAL_DURABILITY_QOS是
TRANSIENT_DURABILITY_QOSTRANSIENT_DURABILITY_QOS是

示例

C++

// 此示例使用DataWriter，但它也可应用于DataReader和Topic实体DataWriterQos writer_qos;// DurabilityQosPolicy默认构造为kind = VOLATILE_DURABILITY_QOS
// 将kind更改为TRANSIENT_LOCAL_DURABILITY_QOS
writer_qos.durability().kind = TRANSIENT_LOCAL_DURABILITY_QOS;// 在创建相应实体时使用修改后的QoS
writer_ = publisher_->create_datawriter(topic_, writer_qos);

XML

<data_writer profile_name="writer_xml_conf_durability_profile"><qos><durability><kind>TRANSIENT_LOCAL</kind></durability></qos>
</data_writer><data_reader profile_name="reader_xml_conf_durability_profile"><qos><durability><kind>VOLATILE</kind></durability></qos>
</data_reader>

3.1.2.1.4. DurabilityServiceQosPolicy（持久化服务QoS策略）

警告
此QoS策略将在未来版本中实现。

当DurabilityQosPolicy的kind设置为TRANSIENT_DURABILITY_QOS或PERSISTENT_DURABILITY_QOS时，此QoS策略用于配置虚构的DataReader和DataWriter的HistoryQosPolicy和ResourceLimitsQosPolicy（参见DurabilityServiceQosPolicy）。

这些实体用于模拟持久存储。虚构的DataReader读取写入到主题的数据并存储它，因此如果用户DataWriter没有用户DataReader请求的信息，虚构的DataWriter会负责发送该信息。

QoS策略数据成员列表：

数据成员名称类型默认值
service_cleanup_delayDuration_tc_TimeZero
history_kindHistoryQosPolicyKindKEEP_LAST_HISTORY_QOS
history_depthint32_t1
max_samplesint32_t-1（长度无限制）
max_instancesint32_t-1（长度无限制）
max_samples_per_instanceint32_t-1（长度无限制）
  • service_cleanup_delay：控制服务何时可以删除关于数据实例的所有信息。该信息将保留，直到满足以下所有条件：
    • 实例已被明确释放，其InstanceState变为NOT_ALIVE_DISPOSED_INSTANCE_STATE。
    • 没有任何活跃的DataWriter在写入该实例，这意味着所有现有写入器要么注销该实例，要么失去其活跃度。
    • 自服务检测到满足前两个条件的时刻起，已经过了比service_cleanup_delay所设定的时间间隔更长的时间。
  • history_kind：控制与持久化服务虚构实体相关联的HistoryQosPolicy的类型。
  • history_depth：控制与持久化服务虚构实体相关联的HistoryQosPolicy的深度。
  • max_samples：控制与持久化服务虚构实体相关联的ResourceLimitsQosPolicy的最大样本数。此值必须大于每个实例的最大样本数。
  • max_instances：控制与持久化服务虚构实体相关联的ResourceLimitsQosPolicy的最大实例数。
  • max_samples_per_instance：控制与持久化服务虚构实体相关联的ResourceLimitsQosPolicy中一个实例内的最大样本数。此值必须小于最大样本数。

注意
此QoS策略适用于Topic和DataWriter实体。它不能在已启用的实体上进行修改。

3.1.2.1.5. EntityFactoryQosPolicy（实体工厂QoS策略）

此QoS策略控制实体作为其他实体的工厂时的行为。默认情况下，所有实体都是创建时启用的，但如果将autoenable_created_entities的值更改为false，新实体将创建为禁用状态（参见EntityFactoryQosPolicy）。

QoS策略数据成员列表：

数据成员名称类型默认值
autoenable_created_entitiesbooltrue

注意
此QoS策略适用于DomainParticipantFactory（作为DomainParticipant的工厂）、DomainParticipant（作为Publisher、Subscriber和Topic的工厂）、Publisher（作为DataWriter的工厂）和Subscriber（作为DataReader的工厂）。它可以在已启用的实体上进行修改，但仅影响在修改后创建的实体。

示例

C++

// 此示例使用Participant，但它也可应用于
// DomainParticipantFactory、Publisher和Subscriber实体DomainParticipantQos participant_qos;// EntityFactoryQosPolicy默认构造为autoenable_created_entities = true
// 将其更改为false
participant_qos.entity_factory().autoenable_created_entities = false;// 在创建相应实体时使用修改后的QoS
participant_ = factory_->create_participant(domain, participant_qos);

XML
目前，此QoS策略无法使用XML进行配置。

3.1.2.1.6. GroupDataQosPolicy（组数据QoS策略）

允许应用程序将附加信息附加到创建的Publishers或Subscribers。此数据对于属于Publisher/Subscriber的所有DataWriters/DataReaders都是通用的，并通过内置主题传播（参见GroupDataQosPolicy）。

此QoS策略可以与DataWriter和DataReader监听器结合使用，以实现类似于PartitionQosPolicy的匹配策略。

QoS策略数据成员列表：

数据成员名称类型默认值
collectionstd::vector<octet>空向量

注意
此QoS策略适用于Publisher和Subscriber实体。它可以在已启用的实体上进行修改。

示例

C++

// 此示例使用Publisher，但它也可应用于Subscriber实体PublisherQos publisher_qos;// GroupDataQosPolicy默认构造为一个空集合
// 集合是私有成员，因此需要使用getter和setter来访问// 在初始化时向集合添加数据
std::vector<eprosima::fastdds::rtps::octet> vec;// 向组数据向量添加两个新的octet
eprosima::fastdds::rtps::octet val = 3;
vec.push_back(val);
val = 10;
vec.push_back(val);publisher_qos.group_data().data_vec(vec); // Setter函数// 在创建相应实体时使用修改后的QoS
publisher_ = participant_->create_publisher(publisher_qos);// 在运行时向集合添加数据
vec = publisher_qos.group_data().data_vec(); // 获取器以保留旧值
val = 31;
vec.push_back(val);
publisher_qos.group_data().data_vec(vec); // Setter函数// 更新相应实体中的QoS
publisher_->set_qos(publisher_qos);

XML

<data_writer profile_name="writer_xml_conf_groupdata_profile"><qos><groupData><value>3.a</value></groupData></qos>
</data_writer><data_reader profile_name="reader_xml_conf_groupdata_profile"><qos><groupData><value>3.a</value></groupData></qos>
</data_reader>

3.1.2.1.7. HistoryQosPolicy（历史记录QoS策略）

当实例的值在能够成功传递给现有DataReader实体之前更改一次或多次时，此QoS策略控制系统的行为。

QoS策略数据成员列表：

数据成员名称类型默认值
kindHistoryQosPolicyKindKEEP_LAST_HISTORY_QOS
depthint32_t1
  • kind：控制服务是否应仅传递最新值、所有中间值或介于两者之间的内容。有关更多详细信息，请参见HistoryQosPolicyKind。
  • depth：确定必须在历史记录中保留的最大样本数。仅当kind设置为KEEP_LAST_HISTORY_QOS时有效。

注意
此QoS策略适用于Topic、DataReader和DataWriter实体。它不能在已启用的实体上进行修改。

重要
此QoS策略必须与ResourceLimitsQosPolicy保持一致，即depth的值必须小于或等于max_samples_per_instance的值。

警告
要使DataWriter和DataReader匹配，它们必须遵循兼容性规则。有关详细信息，请参见兼容性规则。

HistoryQosPolicyKind

有两个可能的值（参见HistoryQosPolicyKind）：

  • KEEP_LAST_HISTORY_QOS：仅保留实例的最新值，旧值被丢弃。保留的样本数量由depth确定。
  • KEEP_ALL_HISTORY_QOS：保留实例的所有值，直到它们被所有DataReader接收或达到资源限制。

兼容性规则

为了保持DataReader和DataWriter中HistoryQosPolicy的兼容性，以下条件必须满足：

  • 如果DataReader的kind为KEEP_ALL_HISTORY_QOS，则DataWriter的kind也必须为KEEP_ALL_HISTORY_QOS。
  • 如果DataReader的kind为KEEP_LAST_HISTORY_QOS，则DataWriter的kind可以是KEEP_LAST_HISTORY_QOS或KEEP_ALL_HISTORY_QOS。在后一种情况下，DataWriter会发送所有样本，但DataReader仅保留最新的depth个样本。
  • 如果DataReader的kind为KEEP_LAST_HISTORY_QOS且DataWriter的kind也为KEEP_LAST_HISTORY_QOS，则DataWriter的depth必须大于或等于DataReader的depth。

可能的组合表：

DataWriter kindDataWriter depthDataReader kindDataReader depth兼容性
KEEP_LAST_HISTORY_QOS5KEEP_LAST_HISTORY_QOS3是
KEEP_LAST_HISTORY_QOS3KEEP_LAST_HISTORY_QOS5否
KEEP_LAST_HISTORY_QOS5KEEP_ALL_HISTORY_QOS-否
KEEP_ALL_HISTORY_QOS-KEEP_LAST_HISTORY_QOS5是
KEEP_ALL_HISTORY_QOS-KEEP_ALL_HISTORY_QOS-是

示例

C++

// 此示例使用DataWriter，但它也可应用于DataReader和Topic实体DataWriterQos writer_qos;// HistoryQosPolicy默认构造为kind = KEEP_LAST_HISTORY_QOS，depth = 1
// 将kind更改为KEEP_LAST_HISTORY_QOS，depth更改为5
writer_qos.history().kind = KEEP_LAST_HISTORY_QOS;
writer_qos.history().depth = 5;// 在创建相应实体时使用修改后的QoS
writer_ = publisher_->create_datawriter(topic_, writer_qos);

XML

<data_writer profile_name="writer_xml_conf_history_profile"><qos><history><kind>KEEP_LAST</kind><depth>5</depth></history></qos>
</data_writer><data_reader profile_name="reader_xml_conf_history_profile"><qos><history><kind>KEEP_LAST</kind><depth>3</depth></history></qos>
</data_reader>

3.1.2.1.8. LatencyBudgetQosPolicy（延迟预算QoS策略）

此QoS策略指定了从DataWriter发送数据到DataReader接收数据所允许的最大延迟时间（参见LatencyBudgetQosPolicy）。它可以用于优化某些传输的行为，例如在实时系统中选择路径。

QoS策略数据成员列表：

数据成员名称类型默认值
durationDuration_tc_TimeZero

注意
此QoS策略适用于Topic、DataReader和DataWriter实体。它可以在已启用的实体上进行修改。

警告
目前，Fast DDS尚未实现基于此QoS策略的传输优化。

示例

C++

// 此示例使用DataWriter，但它也可应用于DataReader和Topic实体DataWriterQos writer_qos;// LatencyBudgetQosPolicy默认构造为duration = c_TimeZero
// 将duration更改为100毫秒
writer_qos.latency_budget().duration.seconds = 0;
writer_qos.latency_budget().duration.nanosec = 100000000;// 在创建相应实体时使用修改后的QoS
writer_ = publisher_->create_datawriter(topic_, writer_qos);

XML

<data_writer profile_name="writer_xml_conf_latency_profile"><qos><latencyBudget><duration><sec>0</sec><nanosec>100000000</nanosec></duration></latencyBudget></qos>
</data_writer><data_reader profile_name="reader_xml_conf_latency_profile"><qos><latencyBudget><duration><sec>0</sec><nanosec>100000000</nanosec></duration></latencyBudget></qos>
</data_reader>

3.1.2.1.9. LifespanQosPolicy（生存周期QoS策略）

此QoS策略指定数据样本在系统中有效的最长时间（参见LifespanQosPolicy）。一旦样本的生存周期到期，它将被视为无效，并从系统中清除。

QoS策略数据成员列表：

数据成员名称类型默认值
durationDuration_tc_TimeInfinite

注意
此QoS策略适用于Topic、DataReader和DataWriter实体。它可以在已启用的实体上进行修改。

警告
要使DataWriter和DataReader匹配，它们必须遵循兼容性规则。有关详细信息，请参见兼容性规则。

兼容性规则

为了保持DataReader和DataWriter中LifespanQosPolicy的兼容性，DataWriter的duration必须小于或等于DataReader的duration。这确保了DataReader有足够的时间接收和处理DataWriter发送的样本。

示例

C++

// 此示例使用DataWriter，但它也可应用于DataReader和Topic实体DataWriterQos writer_qos;// LifespanQosPolicy默认构造为duration = c_TimeInfinite
// 将duration更改为5秒
writer_qos.lifespan().duration.seconds = 5;
writer_qos.lifespan().duration.nanosec = 0;// 在创建相应实体时使用修改后的QoS
writer_ = publisher_->create_datawriter(topic_, writer_qos);

XML

<data_writer profile_name="writer_xml_conf_lifespan_profile"><qos><lifespan><duration><sec>5</sec></duration></lifespan></qos>
</data_writer><data_reader profile_name="reader_xml_conf_lifespan_profile"><qos><lifespan><duration><sec>10</sec></duration></lifespan></qos>
</data_reader>

3.1.2.1.10. LivelinessQosPolicy（活跃度QoS策略）

此QoS策略指定DataWriter实体声明其活跃度的机制和频率（参见LivelinessQosPolicy）。DataReader可以使用此信息来检测DataWriter是否仍然活跃。

QoS策略数据成员列表：

数据成员名称类型默认值
kindLivelinessQosPolicyKindAUTOMATIC_LIVELINESS_QOS
lease_durationDuration_tc_TimeInfinite
announcement_periodDuration_tc_TimeInfinite
  • kind：定义DataWriter声明活跃度的方式。有关更多详细信息，请参见LivelinessQosPolicyKind。
  • lease_duration：DataReader期望接收活跃度声明的最大间隔时间。如果在此时间内没有收到活跃度声明，DataReader将认为DataWriter不再活跃。
  • announcement_period：DataWriter发送活跃度声明的间隔时间。此值必须小于lease_duration。

注意
此QoS策略适用于Topic、DataReader和DataWriter实体。它可以在已启用的实体上进行修改。

警告
要使DataWriter和DataReader匹配，它们必须遵循兼容性规则。有关详细信息，请参见兼容性规则。

LivelinessQosPolicyKind

有三个可能的值（参见LivelinessQosPolicyKind）：

  • AUTOMATIC_LIVELINESS_QOS：Fast DDS自动管理活跃度声明，无需应用程序干预。
  • MANUAL_BY_PARTICIPANT_LIVELINESS_QOS：应用程序负责通过调用assert_liveliness()方法在DomainParticipant级别声明活跃度。此调用将为该参与者创建的所有DataWriter声明活跃度。
  • MANUAL_BY_TOPIC_LIVELINESS_QOS：应用程序负责通过调用assert_liveliness()方法在DataWriter级别声明活跃度。此调用仅为特定的DataWriter声明活跃度。

兼容性规则

为了保持DataReader和DataWriter中LivelinessQosPolicy的兼容性，以下条件必须满足：

  • DataWriter的kind必须与DataReader的kind兼容。兼容性规则如下：
    • AUTOMATIC_LIVELINESS_QOS 与所有kind兼容。
    • MANUAL_BY_PARTICIPANT_LIVELINESS_QOS 仅与AUTOMATIC_LIVELINESS_QOS和MANUAL_BY_PARTICIPANT_LIVELINESS_QOS兼容。
    • MANUAL_BY_TOPIC_LIVELINESS_QOS 仅与AUTOMATIC_LIVELINESS_QOS和MANUAL_BY_TOPIC_LIVELINESS_QOS兼容。
  • DataWriter的lease_duration必须小于或等于DataReader的lease_duration。这确保了DataReader有足够的时间检测到DataWriter的活跃度声明。

可能的组合表（kind兼容性）：

DataWriter kindDataReader kind兼容性
AUTOMATIC_LIVELINESS_QOSAUTOMATIC_LIVELINESS_QOS是
AUTOMATIC_LIVELINESS_QOSMANUAL_BY_PARTICIPANT_LIVELINESS_QOS是
AUTOMATIC_LIVELINESS_QOSMANUAL_BY_TOPIC_LIVELINESS_QOS是
MANUAL_BY_PARTICIPANT_LIVELINESS_QOSAUTOMATIC_LIVELINESS_QOS是
MANUAL_BY_PARTICIPANT_LIVELINESS_QOSMANUAL_BY_PARTICIPANT_LIVELINESS_QOS是
MANUAL_BY_PARTICIPANT_LIVELINESS_QOSMANUAL_BY_TOPIC_LIVELINESS_QOS否
MANUAL_BY_TOPIC_LIVELINESS_QOSAUTOMATIC_LIVELINESS_QOS是
MANUAL_BY_TOPIC_LIVELINESS_QOSMANUAL_BY_PARTICIPANT_LIVELINESS_QOS否
MANUAL_BY_TOPIC_LIVELINESS_QOSMANUAL_BY_TOPIC_LIVELINESS_QOS是

示例

C++

// 此示例使用DataWriter，但它也可应用于DataReader和Topic实体DataWriterQos writer_qos;// LivelinessQosPolicy默认构造为kind = AUTOMATIC_LIVELINESS_QOS，
// lease_duration = c_TimeInfinite，announcement_period = c_TimeInfinite
// 将kind更改为MANUAL_BY_PARTICIPANT_LIVELINESS_QOS，
// lease_duration更改为10秒，announcement_period更改为2秒
writer_qos.liveliness().kind = MANUAL_BY_PARTICIPANT_LIVELINESS_QOS;
writer_qos.liveliness().lease_duration.seconds = 10;
writer_qos.liveliness().lease_duration.nanosec = 0;
writer_qos.liveliness().announcement_period.seconds = 2;
writer_qos.liveliness().announcement_period.nanosec = 0;// 在创建相应实体时使用修改后的QoS
writer_ = publisher_->create_datawriter(topic_, writer_qos);// 应用程序负责定期调用assert_liveliness()以声明活跃度
participant_->assert_liveliness();

XML

<data_writer profile_name="writer_xml_conf_liveliness_profile"><qos><liveliness><kind>MANUAL_BY_PARTICIPANT</kind><lease_duration><sec>10</sec></lease_duration><announcement_period><sec>2</sec></announcement_period></liveliness></qos>
</data_writer><data_reader profile_name="reader_xml_conf_liveliness_profile"><qos><liveliness><kind>MANUAL_BY_PARTICIPANT</kind><lease_duration><sec>10</sec></lease_duration></liveliness></qos>
</data_reader>

3.1.2.1.11. OwnershipQosPolicy（所有权QoS策略）

此QoS策略指定当多个DataWriter向同一主题（带键）写入数据时，哪个DataWriter的数据应被DataReader接受（参见OwnershipQosPolicy）。系统行为取决于OwnershipQosPolicyKind的值。

QoS策略数据成员列表：

数据成员名称类型默认值
kindOwnershipQosPolicyKindSHARED_OWNERSHIP_QOS

注意
此QoS策略适用于Topic、DataReader和DataWriter实体。它不能在已启用的实体上修改。

警告
要使DataWriter和DataReader匹配，它们必须遵循兼容性规则。有关详细信息，请参见兼容性规则。

OwnershipQosPolicyKind

有两个可能的值（参见OwnershipQosPolicyKind）：

  • SHARED_OWNERSHIP_QOS：多个DataWriter可以同时写入同一实例，DataReader将接收所有DataWriter发送的值。
  • EXCLUSIVE_OWNERSHIP_QOS：在任何给定时间，只有一个DataWriter（具有最高所有权强度的那个）的写入被DataReader接受。如果多个DataWriter具有相同的最高所有权强度，则最新的那个（由时间戳确定）将成为所有者。

兼容性规则

为了保持DataReader和DataWriter中OwnershipQosPolicy的兼容性，DataWriter的kind必须与DataReader的kind相同。

可能的组合表：

DataWriter kindDataReader kind兼容性
SHARED_OWNERSHIP_QOSSHARED_OWNERSHIP_QOS是
SHARED_OWNERSHIP_QOSEXCLUSIVE_OWNERSHIP_QOS否
EXCLUSIVE_OWNERSHIP_QOSSHARED_OWNERSHIP_QOS否
EXCLUSIVE_OWNERSHIP_QOSEXCLUSIVE_OWNERSHIP_QOS是

示例

C++

// 此示例使用DataWriter，但它也可应用于DataReader和Topic实体DataWriterQos writer_qos;// OwnershipQosPolicy默认构造为kind = SHARED_OWNERSHIP_QOS
// 将kind更改为EXCLUSIVE_OWNERSHIP_QOS
writer_qos.ownership().kind = EXCLUSIVE_OWNERSHIP_QOS;// 在创建相应实体时使用修改后的QoS
writer_ = publisher_->create_datawriter(topic_, writer_qos);

XML

<data_writer profile_name="writer_xml_conf_ownership_profile"><qos><ownership><kind>EXCLUSIVE</kind></ownership></qos>
</data_writer><data_reader profile_name="reader_xml_conf_ownership_profile"><qos><ownership><kind>EXCLUSIVE</kind></ownership></qos>
</data_reader>

3.1.2.1.12. OwnershipStrengthQosPolicy（所有权强度QoS策略）

当OwnershipQosPolicy设置为EXCLUSIVE_OWNERSHIP_QOS时，此QoS策略用于确定哪个DataWriter成为实例的所有者（参见OwnershipStrengthQosPolicy）。值越高，优先级越高。

QoS策略数据成员列表：

数据成员名称类型默认值
valueint32_t0

注意
此QoS策略适用于DataWriter实体。它可以在已启用的实体上修改。

示例

C++

// 此示例仅适用于DataWriter实体DataWriterQos writer_qos;// OwnershipStrengthQosPolicy默认构造为value = 0
// 将value更改为100
writer_qos.ownership_strength().value = 100;// 在创建相应实体时使用修改后的QoS
writer_ = publisher_->create_datawriter(topic_, writer_qos);

XML

<data_writer profile_name="writer_xml_conf_ownership_strength_profile"><qos><ownershipStrength><value>100</value></ownershipStrength></qos>
</data_writer>

3.1.2.1.13. PartitionQosPolicy（分区QoS策略）

此QoS策略允许将DataWriter和DataReader组织到“分区”中，以便控制它们之间的通信（参见PartitionQosPolicy）。只有属于至少一个共同分区的DataWriter和DataReader才能匹配。

QoS策略数据成员列表：

数据成员名称类型默认值
namesstd::vectorstd::string空向量

注意
此QoS策略适用于Publisher、Subscriber、DataWriter和DataReader实体。它可以在已启用的实体上修改。

重要
DataWriter继承其所属Publisher的分区名称（如果有），DataReader继承其所属Subscriber的分区名称（如果有）。DataWriter/Reader自己的分区名称与继承的名称合并。

示例

C++

// 此示例使用Publisher，但它也可应用于Subscriber、DataWriter和DataReader实体PublisherQos publisher_qos;// PartitionQosPolicy默认构造为一个空的名称向量
// 向名称向量添加两个新分区
publisher_qos.partition().names.push_back("Partition1");
publisher_qos.partition().names.push_back("Partition2");// 在创建相应实体时使用修改后的QoS
publisher_ = participant_->create_publisher(publisher_qos);// 在运行时向名称向量添加另一个分区
publisher_qos.partition().names.push_back("Partition3");// 更新相应实体中的QoS
publisher_->set_qos(publisher_qos);

XML

<publisher profile_name="publisher_xml_conf_partition_profile"><qos><partition><names><name>Partition1</name><name>Partition2</name></names></partition></qos>
</publisher><subscriber profile_name="subscriber_xml_conf_partition_profile"><qos><partition><names><name>Partition2</name><name>Partition3</name></names></partition></qos>
</subscriber>

3.1.2.1.14. PresentationQosPolicy（呈现QoS策略）

此QoS策略控制数据实例的呈现方式和时间（参见PresentationQosPolicy）。它允许指定数据应按实例、按主题还是按发布者进行分组，并确定这些分组是否应按发送顺序呈现。

QoS策略数据成员列表：

数据成员名称类型默认值
access_scopePresentationQosPolicyAccessScopeKindINSTANCE_PRESENTATION_QOS
coherent_accessboolfalse
ordered_accessboolfalse
  • access_scope：定义数据分组的范围。有关更多详细信息，请参见PresentationQosPolicyAccessScopeKind。
  • coherent_access：指定是否保证数据的连贯访问。如果为true，则属于同一组的数据将作为一个单元呈现。
  • ordered_access：指定是否保证数据的顺序访问。如果为true，则属于同一组的数据将按发送顺序呈现。

注意
此QoS策略适用于Publisher和Subscriber实体。它不能在已启用的实体上修改。

警告
目前，Fast DDS仅实现了INSTANCE_PRESENTATION_QOS访问范围。

PresentationQosPolicyAccessScopeKind

有三个可能的值（参见PresentationQosPolicyAccessScopeKind）：

  • INSTANCE_PRESENTATION_QOS：数据按实例分组。这是唯一被Fast DDS实现的范围。
  • TOPIC_PRESENTATION_QOS：数据按主题分组。
  • GROUP_PRESENTATION_QOS：数据按发布者/订阅者分组。

示例

C++

// 此示例使用Publisher，但它也可应用于Subscriber实体PublisherQos publisher_qos;// PresentationQosPolicy默认构造为access_scope = INSTANCE_PRESENTATION_QOS，
// coherent_access = false，ordered_access = false
// 将coherent_access和ordered_access更改为true
publisher_qos.presentation().coherent_access = true;
publisher_qos.presentation().ordered_access = true;// 在创建相应实体时使用修改后的QoS
publisher_ = participant_->create_publisher(publisher_qos);

XML

<publisher profile_name="publisher_xml_conf_presentation_profile"><qos><presentation><access_scope>INSTANCE</access_scope><coherent_access>true</coherent_access><ordered_access>true</ordered_access></presentation></qos>
</publisher><subscriber profile_name="subscriber_xml_conf_presentation_profile"><qos><presentation><access_scope>INSTANCE</access_scope><coherent_access>true</coherent_access><ordered_access>true</ordered_access></presentation></qos>
</subscriber>

3.1.2.1.15. ReliabilityQosPolicy（可靠性QoS策略）

此QoS策略指定DataReader接收DataWriter发送的数据的可靠性保证级别（参见ReliabilityQosPolicy）。系统行为取决于ReliabilityQosPolicyKind的值。

QoS策略数据成员列表：

数据成员名称类型默认值
kindReliabilityQosPolicyKindDataReader为BEST_EFFORT_RELIABILITY_QOS；DataWriter为RELIABLE_RELIABILITY_QOS
max_blocking_timeDuration_t100毫秒
  • kind：定义可靠性保证级别。有关更多详细信息，请参见ReliabilityQosPolicyKind。
  • max_blocking_time：当使用可靠可靠性时，此值指定DataWriter在阻塞等待确认或资源可用之前可以等待的最长时间。

注意
此QoS策略适用于Topic、DataReader和DataWriter实体。它不能在已启用的实体上修改。

警告
要使DataWriter和DataReader匹配，它们必须遵循兼容性规则。有关详细信息，请参见兼容性规则。

ReliabilityQosPolicyKind

有两个可能的值（参见ReliabilityQosPolicyKind）：

  • BEST_EFFORT_RELIABILITY_QOS：不保证数据的传递。数据可能会丢失，尤其是在网络拥塞的情况下。
  • RELIABLE_RELIABILITY_QOS：保证数据的最终传递。如果数据丢失，会重新发送，直到DataReader确认接收。

兼容性规则

为了保持DataReader和DataWriter中ReliabilityQosPolicy的兼容性，DataWriter的kind必须大于或等于DataReader的kind。不同kind之间的顺序为：
BEST_EFFORT_RELIABILITY_QOS < RELIABLE_RELIABILITY_QOS

可能的组合表：

DataWriter kindDataReader kind兼容性
BEST_EFFORT_RELIABILITY_QOSBEST_EFFORT_RELIABILITY_QOS是
BEST_EFFORT_RELIABILITY_QOSRELIABLE_RELIABILITY_QOS否
RELIABLE_RELIABILITY_QOSBEST_EFFORT_RELIABILITY_QOS是
RELIABLE_RELIABILITY_QOSRELIABLE_RELIABILITY_QOS是

示例

C++

// 此示例使用DataWriter，但它也可应用于DataReader和Topic实体DataWriterQos writer_qos;// ReliabilityQosPolicy默认构造为kind = RELIABLE_RELIABILITY_QOS，
// max_blocking_time = 100毫秒
// 将kind更改为RELIABLE_RELIABILITY_QOS，max_blocking_time更改为500毫秒
writer_qos.reliability().kind = RELIABLE_RELIABILITY_QOS;
writer_qos.reliability().max_blocking_time.seconds = 0;
writer_qos.reliability().max_blocking_time.nanosec = 500000000;// 在创建相应实体时使用修改后的QoS
writer_ = publisher_->create_datawriter(topic_, writer_qos);

XML

<data_writer profile_name="writer_xml_conf_reliability_profile"><qos><reliability><kind>RELIABLE</kind><max_blocking_time><sec>0</sec><nanosec>500000000</nanosec></max_blocking_time></reliability></qos>
</data_writer><data_reader profile_name="reader_xml_conf_reliability_profile"><qos><reliability><kind>BEST_EFFORT</kind></reliability></qos>
</data_reader>

3.1.2.1.16. ResourceLimitsQosPolicy（资源限制QoS策略）

此QoS策略控制Fast DDS为满足应用程序和其他QoS设置所施加的要求而可以使用的资源（参见ResourceLimitsQosPolicy）。

QoS策略数据成员列表：

数据成员名称类型默认值
max_samplesint32_t5000
max_instancesint32_t10
max_samples_per_instanceint32_t400
allocated_samplesint32_t100
extra_samplesint32_t1
  • max_samples：可以存储的最大样本总数。此值必须大于或等于max_samples_per_instance。
  • max_instances：可以存储的最大实例数。
  • max_samples_per_instance：每个实例可以存储的最大样本数。此值必须小于或等于max_samples，并且大于或等于HistoryQosPolicy的depth（如果HistoryQosPolicy的kind为KEEP_LAST_HISTORY_QOS）。
  • allocated_samples：初始分配的样本数。如果需要，可以动态分配更多样本，直到达到max_samples。
  • extra_samples：在达到max_samples后可以临时分配的额外样本数，以应对突发流量。

注意
此QoS策略适用于Topic、DataReader和DataWriter实体。它不能在已启用的实体上修改。

重要
这些值必须满足以下约束：

  • max_samples >= max_samples_per_instance
  • 如果HistoryQosPolicy的kind为KEEP_LAST_HISTORY_QOS，则max_samples_per_instance >= HistoryQosPolicy的depth

示例

C++

// 此示例使用DataWriter，但它也可应用于DataReader和Topic实体DataWriterQos writer_qos;// ResourceLimitsQosPolicy默认构造为max_samples = 5000，max_instances = 10，
// max_samples_per_instance = 400，allocated_samples = 100，extra_samples = 1
// 修改这些值
writer_qos.resource_limits().max_samples = 10000;
writer_qos.resource_limits().max_instances = 20;
writer_qos.resource_limits().max_samples_per_instance = 500;
writer_qos.resource_limits().allocated_samples = 200;
writer_qos.resource_limits().extra_samples = 5;// 在创建相应实体时使用修改后的QoS
writer_ = publisher_->create_datawriter(topic_, writer_qos);

XML

<data_writer profile_name="writer_xml_conf_resource_limits_profile"><qos><resourceLimits><max_samples>10000</max_samples><max_instances>20</max_instances><max_samples_per_instance>500</max_samples_per_instance><allocated_samples>200</allocated_samples><extra_samples>5</extra_samples></resourceLimits></qos>
</data_writer><data_reader profile_name="reader_xml_conf_resource_limits_profile"><qos><resourceLimits><max_samples>10000</max_samples><max_instances>20</max_instances><max_samples_per_instance>500</max_samples_per_instance></resourceLimits></qos>
</data_reader>

3.1.2.1.17. TimeBasedFilterQosPolicy（基于时间的过滤器QoS策略）

此QoS策略允许DataReader指定它希望接收数据的最小间隔时间（参见TimeBasedFilterQosPolicy）。即使DataWriter发送数据的频率更高，DataReader也只会接收间隔大于或等于指定最小间隔的样本。

QoS策略数据成员列表：

数据成员名称类型默认值
minimum_separationDuration_tc_TimeZero

注意
此QoS策略适用于DataReader实体。它可以在已启用的实体上修改。

重要
此QoS策略必须与DeadlineQosPolicy保持一致，即minimum_separation的值必须小于或等于DeadlineQosPolicy的period。

示例

C++

// 此示例仅适用于DataReader实体DataReaderQos reader_qos;// TimeBasedFilterQosPolicy默认构造为minimum_separation = c_TimeZero
// 将minimum_separation更改为500毫秒
reader_qos.time_based_filter().minimum_separation.seconds = 0;
reader_qos.time_based_filter().minimum_separation.nanosec = 500000000;// 在创建相应实体时使用修改后的QoS
reader_ = subscriber_->create_datareader(topic_, reader_qos);

XML

<data_reader profile_name="reader_xml_conf_time_based_filter_profile"><qos><timeBasedFilter><minimum_separation><sec>0</sec><nanosec>500000000</nanosec></minimum_separation></timeBasedFilter></qos>
</data_reader>

3.1.2.1.18. TopicDataQosPolicy（主题数据QoS策略）

允许应用程序将附加信息与Topic关联。此数据通过内置主题传播，并可被其他实体用于识别或过滤主题（参见TopicDataQosPolicy）。

QoS策略数据成员列表：

数据成员名称类型默认值
valuestd::vector<octet>空向量

注意
此QoS策略适用于Topic实体。它可以在已启用的实体上修改。

示例

C++

// 此示例仅适用于Topic实体TopicQos topic_qos;// TopicDataQosPolicy默认构造为一个空向量
// 向向量添加数据
std::vector<eprosima::fastdds::rtps::octet> vec;
eprosima::fastdds::rtps::octet val = 1;
vec.push_back(val);
val = 2;
vec.push_back(val);topic_qos.topic_data().value = vec;// 在创建相应实体时使用修改后的QoS
topic_ = participant_->create_topic("topic_name", "topic_type", topic_qos);

XML

<topic profile_name="topic_xml_conf_topic_data_profile"><qos><topicData><value>topic_specific_data</value></topicData></qos>
</topic>

3.1.2.1.19. UserDataQosPolicy（用户数据QoS策略）

允许应用程序将附加信息与DomainParticipant关联。此数据通过内置主题传播，并可被其他实体用于识别或过滤参与者（参见UserDataQosPolicy）。

QoS策略数据成员列表：

数据成员名称类型默认值
valuestd::vector<octet>空向量

注意
此QoS策略适用于DomainParticipant实体。它可以在已启用的实体上修改。

示例

C++

// 此示例仅适用于DomainParticipant实体DomainParticipantQos participant_qos;// UserDataQosPolicy默认构造为一个空向量
// 向向量添加数据
std::vector<eprosima::fastdds::rtps::octet> vec;
eprosima::fastdds::rtps::octet val = 5;
vec.push_back(val);
val = 6;
vec.push_back(val);participant_qos.user_data().value = vec;// 在创建相应实体时使用修改后的QoS
participant_ = factory_->create_participant(domain, participant_qos);

XML

<participant profile_name="participant_xml_conf_user_data_profile"><rtps><userData><value>participant_specific_data</value></userData></rtps>
</participant>

3.1.2.1.20. WriterDataLifecycleQosPolicy（写入器数据生命周期QoS策略）

此QoS策略控制DataWriter在删除实例或关闭时的行为（参见WriterDataLifecycleQosPolicy）。

QoS策略数据成员列表：

数据成员名称类型默认值
autopurge_disposed_samples_delayDuration_tc_TimeZero
autopurge_nowriter_samples_delayDuration_tc_TimeInfinite
  • autopurge_disposed_samples_delay：指定在发送处置消息后，DataWriter应保留已处置样本的时间。
  • autopurge_nowriter_samples_delay：指定在最后一个DataWriter停止写入实例后，DataReader应保留样本的时间。

注意
此QoS策略适用于Topic、DataWriter和DataReader实体。它可以在已启用的实体上修改。

示例

C++

// 此示例使用DataWriter，但它也可应用于DataReader和Topic实体DataWriterQos writer_qos;// WriterDataLifecycleQosPolicy默认构造为
// autopurge_disposed_samples_delay = c_TimeZero，
// autopurge_nowriter_samples_delay = c_TimeInfinite
// 修改这些值
writer_qos.writer_data_lifecycle().autopurge_disposed_samples_delay.seconds = 10;
writer_qos.writer_data_lifecycle().autopurge_nowriter_samples_delay.seconds = 30;// 在创建相应实体时使用修改后的QoS
writer_ = publisher_->create_datawriter(topic_, writer_qos);

XML

<data_writer profile_name="writer_xml_conf_writer_data_lifecycle_profile"><qos><writerDataLifecycle><autopurge_disposed_samples_delay><sec>10</sec></autopurge_disposed_samples_delay><autopurge_nowriter_samples_delay><sec>30</sec></autopurge_nowriter_samples_delay></writerDataLifecycle></qos>
</data_writer><data_reader profile_name="reader_xml_conf_writer_data_lifecycle_profile"><qos><writerDataLifecycle><autopurge_disposed_samples_delay><sec>10</sec></autopurge_disposed_samples_delay></writerDataLifecycle></qos>
</data_reader>
http://www.xdnf.cn/news/20260.html

相关文章：

  • OpenHarmony之USB Manager 架构深度解析
  • 【视网膜分割】AFMIP-Net：一种新型的自适应特征调制和隐式提示网络
  • AI、人工智能础: 实体命名!
  • 郭平《常变与长青》读书笔记（第一章）
  • QT之实现点击按钮启动另一个桌面应用程序
  • 【开题答辩全过程】以 停车场管理系统的设计与实现为例，包含答辩的问题和答案
  • 点晴模切ERP与MES系统整合：模切工厂数字化转型关键
  • 内网后渗透攻击--linux系统（横向移动）
  • Python趣味入门：打印与计算初体验
  • 垃圾收集器分类
  • 「数据获取」《中国电力统计年鉴》（1993-2024）(含中国电力年鉴）
  • 分布式数据库的历史演变与核心原理
  • SpringBoot配置文件
  • 【CSP-S】数据结构 ST 表详解
  • 植物大战僵尸融合版安装包，下载安装教程
  • PCDN工作原理的详细步骤
  • Netty从0到1系列之EventLoopGroup
  • Kafka面试精讲 Day 10：事务机制与幂等性保证
  • CUDA默认流的同步行为
  • 项目升级--kafka消息队列的应用
  • 状压 dp --- 数据范围小
  • 雪球科技Java开发工程师笔试题
  • happen-before原则
  • WSL Ubuntu Docker 代理自动配置教程
  • LeetCode 139. 单词拆分 - 动态规划解法详解
  • 【软考架构】第二章 计算机系统基础知识：计算机网络
  • 主数据系统是否对于企业是必需的？
  • 最大似然估计：损失函数的底层数学原理
  • 基本数据类型和包装类的区别?
  • 2025年大数据专业人士认证发展路径分析