类 ara::diag::Condition

类 ara::diag::Condition 提供接口 DiagnosticConditionInterface，自适应应用程序通过该接口向 Diagnostic Management 报告环境条件和使能条件（[SWS_DM_00712]）。Diagnostic Server 评估这些状态，以有针对性地控制车辆中标准化诊断功能或清除操作的执行（AUTOSAR_AP_SWS_Diagnostics §7.3.2.5.5 “Condition checks”）。实例严格绑定到端口原型，既不可复制也不可移动。在并发使用时，查询和设置操作需要外部同步，因为它们不是线程安全的。

更多 ›

上下文

类 ara::diag::Condition 代表 AUTOSAR Adaptive Platform 中用于诊断条件（DiagnosticConditionInterface）的编程接口（[SWS_DM_00712]）。在车辆诊断系统中，仅当车辆处于定义的环境状态时（例如，在车速为零的车辆静止状态下），才允许执行某些诊断功能或 UDS 服务（AUTOSAR_AP_SWS_Diagnostics §7.3.2.5.5 “Condition checks”）。根据 [SWS_DM_00111]，如果 ISO 14229-1 规定了特定于服务的条件检查，Diagnostic Server 将执行相应的环境检查，并在不满足时以配置的 Negative Response Code (NRC) 进行响应。

在应用程序架构中，ara::diag::Condition 充当自适应应用程序与 Diagnostic Management (DM) 之间的连接纽带。应用程序通过一个端口实例化条件对象，该端口在模型中通过 DiagnosticEnableConditionPortMapping 或 DiagnosticClearConditionPortMapping 关联（[SWS_DM_00712]）。解释：通过此端口分配来确定所报告的状态是用作常规诊断流程的使能条件，还是用作清除诊断数据的准则。 问题 (未决)因此，该对象封装了向 Diagnostic Server 的状态传输，该服务器评估传入诊断请求的条件（[SWS_DM_00111]）。

上下文图：ara::diag::Condition 在应用程序软件与 Diagnostic Management 之间的集成。来源：[SWS_DM_00712]，[SWS_DM_00111]，AUTOSAR_AP_SWS_Diagnostics §7.3.2.5.5 “Condition checks”

生命周期

ara::diag::Condition 对象的创建通过向构造函数传递 ara::core::InstanceSpecifier 显式进行（[SWS_DM_00712]）。该标识符指向应用程序的建模端口原型。构造函数声明为 noexcept，并保证异常安全性以及线程安全性（[SWS_DM_00712]）。

在所有权方面，该类被设计为严格的单实例：复制构造函数（[SWS_DM_01625]）和复制赋值运算符（[SWS_DM_01623]）均已被删除（=delete）。同样，移动构造函数（[SWS_DM_01626]）和移动赋值运算符（[SWS_DM_01624]）也被删除。条件对象既不能复制也不能移动，这确保了与相应端口的固定 1:1 分配。

在运行过程中，方法 SetCondition（[SWS_DM_00715]）和 GetCondition（[SWS_DM_00714]）被指定为非线程安全。在来自多个线程的并发访问时，调用方应用程序必须确保外部同步。生命周期以析构函数 ~Condition()（[SWS_DM_00713]）结束，该析构函数为 noexcept 且异常安全，但同样不是线程安全的。

使用路径

典型使用路径包括初始化、状态的定期更新以及条件的查询：

1. 初始化：应用程序在指定匹配的 ara::core::InstanceSpecifier（[SWS_DM_00712]）的情况下实例化 ara::diag::Condition，以连接到模型配置。
2. 设置状态：如果相关的车辆或系统状态发生变化，应用程序通过 SetCondition(condition)（[SWS_DM_00715]）更新条件。该调用通过 ara::core::Result<void> 确认采纳。
3. 查询状态：为了检查当前状态，应用程序调用 GetCondition()（[SWS_DM_00714]）。结果通过 ara::core::Future<ConditionType> 异步提供。
4. 服务器处理：解释：Diagnostic Server 在内部访问存储的状态，以检查待处理的诊断请求（[SWS_DM_00111]）。 问题 Q-bbf48f735ef80e33 (未决)
5. 终止：在组件终止时，该对象通过析构函数释放（[SWS_DM_00713]）。

时序图：用于初始化、更新和查询诊断条件的典型调用顺序。来源：[SWS_DM_00712]，[SWS_DM_00715]，[SWS_DM_00714]，[SWS_DM_00713]

错误场景

错误状态可能在对象实例化期间以及运行期间发生：

• 构造函数违规：在创建（[SWS_DM_00712]）时，框架会根据软件模型验证配置。可能的违规包括：
  • InstanceSpecifierMappingIntegrityViolation：标识符无法在模型中解析，或者未引用 PortPrototype（[SWS_DM_00712]）。
  • PortInterfaceMappingViolation：虽然 PortPrototype 由 DiagnosticConditionInterface 定型，但既未被 DiagnosticEnableConditionPortMapping 引用，也未被 DiagnosticClearConditionPortMapping 引用（[SWS_DM_00712]）。
  • ProcessMappingViolation：对于实例引用，运行时不存在匹配的建模进程（[SWS_DM_00712]）。
  • InstanceSpecifierAlreadyInUseViolation：标识符在同一进程中已被另一个实例使用（[SWS_DM_00712]）。
• 诊断基础服务故障：如果 Diagnostic Management 的基本功能暂时不可用，GetCondition()（[SWS_DM_00714]）可能会通过返回的 ara::core::Future 失败并带有错误 DiagErrc::kServiceNotAvailable。
• 无错误状态保存：对于 SetCondition()（[SWS_DM_00715]），未定义标准化的错误代码；该函数直接通过空的 ara::core::Result<void> 报告成功。