命名空间 apext::sm

命名空间 apext::sm 提供了规范化的平台扩展接口，以在 AUTOSAR Adaptive State Management 与宿主操作系统之间协调电源状态 SWS StateManagement §C.1 “Header: apext/sm/power_state_interface.h”。通过枚举 apext::sm::PowerState 对 Linux 特定的节能模式进行类型化映射 [SWS_SM_71002]。此外，回调 apext::sm::WakeUpHandler 允许操作系统触发 State Management 中自主退出休眠状态，而无需上游控制应用程序的参与 [SWS_SM_71004]，且该调用未设计为线程安全。

更多 ›

上下文

命名空间 apext::sm 为 AUTOSAR Adaptive Platform 内的 Functional Cluster State Management 提供了规范性平台扩展接口（Platform Extension Interfaces）SWS StateManagement §C.1 “Header: apext/sm/power_state_interface.h”。虽然 State Management 的标准接口主要用于跨模型边界协调应用状态、功能组和执行模式，但 apext::sm 侧重于近硬件耦合。扩展接口设计用于由 OEM 或集成商使用或提供，以扩展平台功能，并实现与底层操作系统 (OS) 的协调交互 SWS StateManagement §C.1 “Header: apext/sm/power_state_interface.h”。

该命名空间的核心组件是类 PowerStateInterface，用于与操作系统协调电源状态。作为辅助，头文件 apext/sm/power_state_interface.h 定义了类型化枚举和回调别名，它们充当操作系统驱动程序、外部唤醒源与内部状态管理之间的纽带。除操作系统外，这些接口在概念上还与 State Management 的 Controller 以及诸如 SMControlApplication 或 Update and Configuration Management (UCM) 等上层实例相关联，这些实例同样可以对状态转换产生影响 SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”。

上下文图：操作系统、apext::sm 接口与 State Management 之间的交互。来源：SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”、SWS StateManagement §C.1 “Header: apext/sm/power_state_interface.h”。

生命周期

apext::sm 框架内的生命周期以离散的电源状态为特征，这些状态在枚举 apext::sm::PowerState 中基于 std::uint32_t 建模 [SWS_SM_71002]。这些状态直接源自 Linux 操作系统的内核视角：

• kPmSuspendToIdle (= 1)：派生自状态 PM_SUSPEND_TO_IDLE [SWS_SM_71002]。
• kPmSuspendToRam (= 2)：派生自状态 PM_SUSPEND_TO_RAM [SWS_SM_71002]。
• kPmHibernation (= 3)：派生自状态 PM_HIBERNATION（挂起到磁盘，Suspend-to-Disk）[SWS_SM_71002]。
• kPmOff (= 4)：派生自状态 PM_OFF（完全关机）[SWS_SM_71002]。

解释：类 PowerStateInterface 可能用作主要的针脚锚点，集成商通过它查询这些目标状态或将其传输到宿主操作系统。 问题 Q-800acae699828764 (未决)在停留在诸如 kPmSuspendToRam 等节能状态期间，正常处理处于静止状态，直到唤醒事件触发返回活动运行模式的转换。

使用路径

该命名空间的一个核心用例是整个系统从休眠状态自主唤醒（Autonomous wake-up from suspend state）SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”。虽然 SMControlApplication 可以显式请求退出 Suspend-to-RAM 模式，但 State Management 此外还能够对唤醒信号做出自主反应。

若操作系统通过接口 apext::sm::WakeUpHandler 指示唤醒事件（如果该接口已实现），State Management 将自主启动唤醒序列 SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”。apext::sm::WakeUpHandler 是 std::function<void(void)> 类型的函数别名 [SWS_SM_71004]。通过调用此处理程序，State Management 将 Controller 状态机从其挂起状态转换为专门为此建模的状态 LeaveSuspend [SWS_SM_CONSTR_00036]。在此状态下，控制器必须执行操作元素 LeaveSuspendToRam，从而在无需控制应用程序事先干预的情况下恢复常规平台活动 [SWS_SM_CONSTR_00037]、SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”。

时序图：通过 WakeUpHandler 自主唤醒的流程。来源：SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”、[SWS_SM_71004]、[SWS_SM_CONSTR_00036]、[SWS_SM_CONSTR_00037]。

错误场景

在使用和集成 apext::sm 时，必须注意系统特定的边界条件和并发风险：

• 缺乏线程安全性：根据规范，调用类型 apext::sm::WakeUpHandler 明确为非线程安全（not thread-safe）[SWS_SM_71004]。如果操作系统或中断上下文触发多次或并行信号，集成商必须提供适当的同步机制，以防止 State Management 中出现数据争用和不一致的状态转换。
• 未实现的处理程序：如果 WakeUpHandler 在目标系统中未实现，则无法通过操作系统进行自主唤醒；在这种情况下，系统将保持在休眠状态，直到收到外部请求（例如由 UCM 通过 RequestUpdateSession 发起）或显式的应用程序请求 SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”。
• Manifest 中的建模错误：如果部署清单中缺少针对 Controller 的状态 LeaveSuspend [SWS_SM_CONSTR_00036]，或者该状态未包含强制性元素 LeaveSuspendToRam [SWS_SM_CONSTR_00037]，则自动转换将失败，且平台在休眠状态后无法按规范恢复运行。