namespace apext::sm

The namespace apext::sm provides normative platform extension interfaces to coordinate power states between AUTOSAR Adaptive State Management and the host operating system SWS StateManagement §C.1 “Header: apext/sm/power_state_interface.h”. Linux-specific low-power modes are mapped in a typed manner via the enumeration apext::sm::PowerState [SWS_SM_71002]. In addition, the callback apext::sm::WakeUpHandler enables the operating system to trigger an autonomous exit from sleep states in State Management without an upstream control application [SWS_SM_71004], whereby this call is not designed to be thread-safe.

more ›

Context

The namespace apext::sm provides normative platform extension interfaces (Platform Extension Interfaces) for the functional cluster State Management within the AUTOSAR Adaptive Platform SWS StateManagement §C.1 “Header: apext/sm/power_state_interface.h”. While standard interfaces of State Management primarily serve to coordinate application states, function groups, and execution modes across model boundaries, apext::sm addresses hardware-level coupling. The extension interfaces are designed to be used or provided by OEMs or integrators to extend the platform's functionality and to realize a coordinated interaction with the underlying operating system (OS) SWS StateManagement §C.1 “Header: apext/sm/power_state_interface.h”.

A central component of the namespace is the class PowerStateInterface, which serves to coordinate power states with the operating system. Concurrently, the header apext/sm/power_state_interface.h defines typed enumerations and callback aliases that act as a link between operating system drivers, external wake-up sources, and internal state management. In addition to the operating system, these interfaces are conceptually related to the Controller of State Management as well as to higher-level entities such as SMControlApplication or Update and Configuration Management (UCM), which can also influence state transitions SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”.

Context diagram: Interaction of operating system, apext::sm interfaces, and State Management. Sources: SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”, SWS StateManagement §C.1 “Header: apext/sm/power_state_interface.h”.

Lifecycle

The lifecycle in the context of apext::sm is characterized by the discrete power states modeled in the enumeration apext::sm::PowerState based on std::uint32_t [SWS_SM_71002]. These states are derived directly from the kernel perspective of Linux operating systems:

• kPmSuspendToIdle (= 1): Derived from state PM_SUSPEND_TO_IDLE [SWS_SM_71002].
• kPmSuspendToRam (= 2): Derived from state PM_SUSPEND_TO_RAM [SWS_SM_71002].
• kPmHibernation (= 3): Derived from state PM_HIBERNATION (suspend-to-disk) [SWS_SM_71002].
• kPmOff (= 4): Derived from state PM_OFF (complete shutdown) [SWS_SM_71002].

Interpretation: The class PowerStateInterface is likely to serve as the primary anchor point through which the integrator queries these target states or transmits them to the host operating system. Question Q-800acae699828764 (open) During the dwell time in a low-power state such as kPmSuspendToRam, normal processing is suspended until a wake-up event initiates the transition back to the active operating mode.

Usage Path

A central use case of the namespace is the autonomous wake-up of the overall system from a sleep state (Autonomous wake-up from suspend state) SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”. While a SMControlApplication can explicitly request exiting the suspend-to-RAM mode, State Management is additionally capable of reacting autonomously to wake-up signals.

If the operating system signals a wake-up event via the interface apext::sm::WakeUpHandler—provided it is implemented—State Management independently initiates a wake-up sequence SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”. apext::sm::WakeUpHandler is a function alias of type std::function<void(void)> [SWS_SM_71004]. By invoking this handler, State Management transitions the Controller state machine from its suspend state to the state LeaveSuspend modeled specifically for this purpose [SWS_SM_CONSTR_00036]. In this state, the controller mandatorily executes the action item LeaveSuspendToRam, whereby regular platform activity is resumed without prior intervention of a control application [SWS_SM_CONSTR_00037], SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”.

Sequence diagram: Process of autonomous wake-up via the WakeUpHandler. Sources: SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”, [SWS_SM_71004], [SWS_SM_CONSTR_00036], [SWS_SM_CONSTR_00037].

Error Scenarios

When using and integrating apext::sm, system-specific constraints and concurrency risks must be considered:

• Missing thread safety: According to the specification, the invocation type apext::sm::WakeUpHandler is explicitly not thread-safe (not thread-safe) [SWS_SM_71004]. If the operating system or an interrupt context triggers multiple or parallel signals, the integrator must provide suitable synchronization mechanisms to prevent data races and inconsistent state transitions in State Management.
• Unimplemented handler: If the WakeUpHandler is not implemented in the target system, no autonomous wake-up via the operating system can take place; in this case, the system remains in the sleep state until external requests (e.g. by UCM via RequestUpdateSession) or explicit application requests arrive SWS StateManagement §7.7.15.1 “Autonomous wake-up from suspend state”.
• Modeling error in the manifest: If state LeaveSuspend for Controller is missing in the deployment manifest [SWS_SM_CONSTR_00036] or does not contain the mandatory element LeaveSuspendToRam [SWS_SM_CONSTR_00037], the automated transition fails and the platform cannot properly resume operation after the sleep state.