module ara::sm — State Management

The adaptive cluster State Management controls system-wide operation modes, function group states, and software update phases of an Adaptive Machine in conjunction with Execution Management and UCM EXP SWArchitecture p. 51. It processes transition triggers deterministically via configured tables and action lists, reports intermediate states via StateMachineNotification, and orchestrates suspend-to-RAM using a hub-satellite pattern [SWS_SM_91107], [SWS_SM_81110]. Constraints such as strict verification of update permissions and mandatory ANY error fallbacks safeguard robust platform operation [SWS_SM_91108].

more ›

The functional cluster State Management (SM) acts in the AUTOSAR Adaptive Platform as the central platform daemon for controlling machine and function group states as well as execution modes EXP SWArchitecture p. 51. It strictly decouples vehicle-specific decision logic in control applications (SMControlApplication) from actual process management by Execution Management (EM) EXP PlatformDesign p. 40. In addition to proprietary implementations, AUTOSAR provides a standardized StateMachine approach in which transitions are processed via tabular metamodels and configured action lists SWS StateManagement p. 42.

State transitions are initiated via the RequestTransition method of StateMachineService [SWS_SM_91107] and validated against TransitionRequestTable SWS StateManagement p. 44. During the processing of the associated ActionList, the notification field CurrentState signals the transition value "inTransition" to consuming applications before the target state is published after full acknowledgement [SWS_SM_91109], SWS StateManagement p. 67.

Sequence diagram: Sequence of a regular state transition via StateMachineService and notification via StateMachineNotification. Sources: [SWS_SM_91107], [SWS_SM_91109], SWS StateManagement p. 51

To perform software updates, State Management provides the interface UpdateRequest for Update and Configuration Management (UCM) [SWS_SM_91102], EXP SWArchitecture p. 56. After checking the application field UpdateAllowed, the module coordinates preparation (PrepareUpdate), verification (VerifyUpdate), or rollback steps (PrepareRollback) as well as machine restarts via ResetMachine [SWS_SM_91100], [SWS_SM_91103], [SWS_SM_91108]. For power-saving modes such as Suspend-to-RAM, S2RHub and S2RSatellite synchronize the freezing and resuming of applications and operating system [SWS_SM_81010], [SWS_SM_81110], [SWS_SM_71001].

In case of an error, the SmErrorDomain [SWS_SM_81247] as well as a mandatory ANY fallback entry in the ErrorRecoveryTable ensure that unforeseen execution errors from Execution Management or Platform Health Management are intercepted deterministically and ongoing actions are immediately transferred to defined recovery states SWS StateManagement p. 42.

more ›

Role and Functional System Boundaries within the Platform Network

The functional cluster State Management (SM) serves in the AUTOSAR Adaptive Platform as the central entity for orchestrating system-wide operational modes, function groups, and process lifecycles EXP SWArchitecture p. 51. Executed as an autonomous platform daemon, State Management decouples platform-internal state execution from vehicle- and manufacturer-specific control logic, which is typically encapsulated in an independent control application (SMControlApplication) EXP PlatformDesign p. 40. While State Management makes and validates logical state decisions, it delegates the physical starting, terminating, and switching of processes via the StateClient to Execution Management (EM) SWS StateManagement p. 40.

Architecturally, the module relies on a dual integration philosophy: Integrators can either use the standardized, manifest-based StateMachine approach of the platform stack or implement entirely proprietary state logic, as the interfaces to State Management are kept public SWS StateManagement p. 42. In the standardized approach, State Management responds deterministically to external triggers from control applications, error reports from Platform Health Management (PHM), and network state changes from Network Management (NM) SWS StateManagement p. 45. In addition, State Management forms the authoritative controlling entity for software updates performed by Update and Configuration Management (UCM) EXP SWArchitecture p. 56.

Context diagram: Integration of the functional cluster State Management within the AUTOSAR Adaptive system network. Sources: EXP PlatformDesign p. 40, SWS StateManagement p. 28

State Transitions and Control via the StateMachineService Interface

To initiate state changes, State Management provides the service-based service StateMachineService for each configured instance of a StateMachine SWS StateManagement p. 44. The application requests a transition via the service method RequestTransition [SWS_SM_91107]. State Management checks this request against the current state of the state machine using a TransitionRequestTable statically defined in the manifest SWS StateManagement p. 44. If the transition is defined, execution of the current action list (ActionList) is stopped and the switch to the target state is initiated SWS StateManagement p. 45.

As soon as a state transition starts, State Management sets the value of the service field CurrentState of the StateMachineNotification interface to "inTransition" [SWS_SM_91109], SWS StateManagement p. 67. This transitional state signals to dependent Adaptive Applications via ara::com that a reconfiguration of the system is in progress EXP SWArchitecture p. 52. Within action lists, function groups can be synchronized or executed in parallel via SYNC elements to map dependencies precisely SWS StateManagement p. 56. Only after all ActionListItems have been fully processed and the results collected does CurrentState assume the final name of the new state SWS StateManagement p. 67.

Sequence diagram: Sequence of a regular state transition via StateMachineService and notification via StateMachineNotification. Sources: [SWS_SM_91107], [SWS_SM_91109], SWS StateManagement p. 51, EXP SWArchitecture p. 219

State diagram: Typical lifecycle and transition logic of a StateMachine based on the TransitionRequestTable. Sources: EXP InterfacesGuidelines p. 22, SWS StateManagement p. 44

Orchestration of Software Updates in Interaction with UCM

In the context of software updates, State Management assumes the interface function between Update and Configuration Management (UCM) and the execution states of the machine EXP SWArchitecture p. 142. For this purpose, State Management provides the interface UpdateRequest, which may be instantiated at most once per machine and is bound exclusively to the process that runs the controller state machine SWS StateManagement p. 79. An update is initiated when UCM invokes the method RequestUpdateSession [SWS_SM_91102]. State Management does not make the decision regarding admissibility autonomously, but consults the service field UpdateAllowed of the UpdateAllowedService, which is set by the application control logic [SWS_SM_91108], SWS StateManagement p. 81.

If the session is approved, the controller marks the affected state machines as ImpactedByUpdate SWS StateManagement p. 81. Prior to the actual deployment, UCM invokes PrepareUpdate with the list of affected function groups, whereupon these are transitioned into inactive states [SWS_SM_91103], PlatformDesign p. 58. If the update requires a restart, UCM requests an orderly reset via the fire-and-forget method ResetMachine, prior to which all data must be saved [SWS_SM_91100]. State Management informs UCM about status changes during the reset via the field ResetMachineNotifier [SWS_SM_91106], SWS StateManagement p. 92. After the restart or update, verification follows via VerifyUpdate [SWS_SM_91104], SWS StateManagement p. 87. If the check fails, PrepareRollback prepares the rollback [SWS_SM_91105], SWS StateManagement p. 88. The completion of the entire cycle is acknowledged with StopUpdateSession [SWS_SM_91101], SWS StateManagement p. 79.

Sequence diagram: Interaction sequence of a software update session between UCM, State Management, and control logic. Sources: [SWS_SM_91100], [SWS_SM_91102], [SWS_SM_91103], [SWS_SM_91104], SWS StateManagement p. 78

Energy Management and Suspend-to-RAM in the Hub-Satellite Network

For advanced energy management functions such as Suspend-to-RAM (S2R), State Management implements a hub-satellite architectural pattern EXP SWArchitecture p. 54. The central control entity in the platform daemon uses the class S2RHub [SWS_SM_81103], whereas participating Adaptive Applications incorporate instances of S2RSatellite in their own process space [SWS_SM_81003], [SWS_SM_81014], SWS StateManagement p. 35. Satellites activate their readiness to accept mode changes via Offer [SWS_SM_81012] and deactivate it via StopOffer [SWS_SM_81013]. They implement the pure virtual methods EnterSuspendMode [SWS_SM_81010] and LeaveSuspendMode [SWS_SM_81011] as a callback mechanism for preparing and post-processing the suspend state.

When a suspend operation is initiated, the S2RHub addresses all registered satellites asynchronously via RequestToEnterSuspendMode with a configurable timeout [SWS_SM_81110]. Once all satellites have successfully completed their suspend preparations, the hub triggers the operating system's entry into the RAM retention state via EnterSuspendToRamOs [SWS_SM_81112], SWS StateManagement p. 101. At the hardware-related OS wrapper level, State Management utilizes the apext::sm::PowerStateInterface: It enables setting hardware-related operating states via SetPowerState [SWS_SM_71001] based on the enumeration PowerState [SWS_SM_71002], as well as registering and deregistering autonomous wake-up handlers via RegisterWakeUpHandler [SWS_SM_71003] and UnregisterWakeUpHandler [SWS_SM_71005] with the function type WakeUpHandler [SWS_SM_71004], SWS StateManagement p. 105. After waking up, the hub requests the coordinated resuming of all satellites via RequestToLeaveSuspendMode [SWS_SM_81111].

Sequence diagram: Two-phase sequence for transitioning the system into Suspend-to-RAM and subsequent wake-up. Sources: [SWS_SM_71001], [SWS_SM_81110], [SWS_SM_81112], SWS StateManagement p. 101

Behavior in the event of an error

For its own operational errors, the module defines the SmErrorDomain [SWS_SM_81247], which is retrieved via GetSmDomain [SWS_SM_81251] and bears the identifier "Sm" [SWS_SM_81248]. It provides error descriptions [SWS_SM_81249] and, in the exception case, converts codes via ThrowAsException into an SmException [SWS_SM_81243], [SWS_SM_81250]. Specific causes of failure are typified via the enumeration SmErrc, including kOfferFailed for connection losses to the platform daemon and kCommunicationFailed for failing satellite communication [SWS_SM_81240], creatable by means of MakeErrorCode [SWS_SM_81244].

In the area of logical state machines, State Management enforces seamless error handling via the ErrorRecoveryTable SWS StateManagement p. 69. Each table must mandatorily contain exactly one entry with the value ANY, which serves as a deterministic fallback path for all execution errors not explicitly mapped SWS StateManagement p. 42, SWS StateManagement p. 69. If an error is reported by Platform Health Management or Execution Management and the affected state machine is not marked as ImpactedByUpdate, it sets an internal flag for ongoing error recovery, immediately aborts the current action list, and immediately switches to the parameterized recovery state SWS StateManagement p. 42. For critical errors of Execution Management such as kIntegrityOrAuthenticityCheckFailed, State Management assumes that the platform's trustworthiness is compromised and subsequent requests will fail, which is why corrective measures lie outside the cluster SWS StateManagement p. 40.

Activity diagram: Decision and processing flow for incoming execution errors and evaluation of the ErrorRecoveryTable. Sources: SWS StateManagement p. 42, SWS StateManagement p. 69

Further detailed evidence

The architecture and interaction paths of State Management are supported by the following normative requirements and design specifications:

• System control and transitions: [SWS_SM_91107] defines the service-oriented transition requirement, while [SWS_SM_91109] governs the notification field for decoupling applications. Table-based control is substantiated by SWS StateManagement p. 44.
• Software update integration: The methods for session management [SWS_SM_91102], preparation [SWS_SM_91103], verification [SWS_SM_91104], rollback preparation [SWS_SM_91105], and termination [SWS_SM_91101], as well as machine resets [SWS_SM_91100] and release fields [SWS_SM_91106], [SWS_SM_91108], establish the interaction with UCM according to EXP SWArchitecture p. 56.
• Suspend-to-RAM and power management: The native class and interface hierarchy around S2RHub [SWS_SM_81103], [SWS_SM_81110], S2RSatellite [SWS_SM_81003], [SWS_SM_81010] and the operating system interface [SWS_SM_71001], [SWS_SM_71003] form the normative foundation of energy saving EXP SWArchitecture p. 54.
• Error space: The design of the standardized error domain with exception and ErrorCode generators is based on [SWS_SM_81240], [SWS_SM_81244], and [SWS_SM_81247].