# StateManagement
###### tags: `專題`
* State Management (project specific)
* 
* responsible for all aspects of Operational State Management including handling of incoming events, determining the currentsetofactiveFunction Group States, prioritization of these events/requests setting the corresponding internal States.
* Incoming events ： AUTOSAR Adaptive Platform Application or Adaptive Application will change the value of "Trigger" fields which provided by SM to issued Incoming events
* evaluate these events and decide based on:
* Event type
* Event priority
* Application identifier (is not supported in this release)
* the first two items are project specific
* handling the following states:
* Machine State
* Function Group State
* may contain one or more state machines, which might be more or less loosely coupled depending on project needs.
* for initiating Function Groupand Machine State transitions by requesting them from Execution Management.
* how to get into certain state -> interacts with the Execution Management interface to request Function Groups (might additionally depend on NM state) and the Machine State to enter specific state
* provid access to its internal state via ara::com services. Using certain interface:
* Notifier
* getting current state
* Trigger
* requesting new state
* Adaptive Applications and AUTOSAR Adaptive Platform Applications can register to the events of the "Notifier" fields and can change their internal behavior by writing to the "Trigger" fields (and may provide their own property or event via an ara com interface)
* If an State Managements internal State change is triggered then Execution Management may be requested to set Function Groups or Machine State into new Function Group State. And The state change request for Function Groups can be issued by several AUTOSAR Adaptive Platform Applications:
* Platform Health Management : to trigger error recovery
* Diagnostic Management : to switch the system into different diagnostic states and to issue resets of the system.
* Update and Configuration Management : to switch the system into states where software or configuration can be updated and updates can be verified.
* Network Management : to coordinate required functionality and network state.(This is no active request by NM )
* Dependices to other functional clusters
* don't depend:
* OS interface: no direct interfact to the OS. All OS depndencies are abstracted by the Execution Management
* depend:
* Execution Manager interface:
* is depend on it to start and stop processes(as part of defined Function Groups or Machine States)
* additionally uses the StateClient functionality of Execution Management to inform Execution Management about State Management Process State
* performs the State transitions and controls the actual set of running Modelled Processes, depending on the current States.
* Plarform Health Managemet:
* Plarform Health Managemet supervises configured entites and informs State Management when any of these entites fails.
* shall monitor and supervise SM
* Diagnostic Management:
* Diagnostic Management request different reset types for a Diagnostic Address at SM.
* SM prevenets the system from shutting down during an active diagnostics session
* Update And Configuration Management:
* It coordinates the update sequence with State Management to set a set of Function Groups(affected by the update) to dedicated States.
* Network Management:
* provide:
* multiple NetworkHandle fields
* State Management registers to and reacts on changes of these fields issued by Network Management
* represents a set of (partial) networks
* responsible for en- and disabling (partial) networks.
* ara::com fields (NetworkHandle) where each of the fields represents a set of (partial) networks.
* evaluates the NetworkCurrentState field to set Function Groups to the corresponding Function Group State and set the NetworkRequestedState field in dependency of Function Groups and their Function Group State .
* SM shall prevent network from shutting down during an active update or diagnostic session.
* State :
* Machine State
* goal : In general, Machine States are used to control machine lifecycle (startup/shutdown/restart) and Modelled Processes of platform level Applications
* is a specific type of Function Group State
* are determined and requested by the State Management functional cluster
* The Function Group States, including the Machine State, define the current set of running Modelled Processes.
* Each Application can declare in its Execution Manifests in which Function Group States its Modelled Pro- cesses have to be running.
> Execution Management terminates running Modelled Processes and then starts Modelled Processesactive in the new state before confirming the state change to State Management.
* state :
* introduce:
* State Management will run in every Machine State (this includes Startup, Shutdown and Restart)
* there is always a software entity that can introduce changes in the current state of the Machine
* Execution Management will be controlled by State Management and therefore it should not execute any Function Group State changes on its own.
* start-up:
* If system integrator doesn’t configure State Manage- ment to be started in Startup Machine State, then Machine will never be able transit to any other state and will be stuck forever in it
* Shutdown
* Restart

* Function Group State
* goal : Function Group States individually control Modelled Processes which belong to groups of functionally coherent user level Applications.
* To support this use case ( If more than one group of functionally coherent Applications is installed on the same machine ) , additional Function Groups and Function Group States can be configured
* Execution Management terminates not longer needed Modelled Processes and then starts Modelled Processes active in the new Function Group State before confirming the state change to State Management.

### interact
* State Management should be configured to run in every Machine State (this includes Startup, Shutdown and Restart) other than Off. This expectation is needed to ensure that there is always a software entity that can introduce changes in the current state of the Machine.
#### Interaction between the SM and Adaptive Applications
* State Management provides a service interface TriggerOut with a Notifier field,where **each Adaptive Application** can subscribe to,thus it is informed whenever a State Managements internal State changes.
* In the opposite way each Adaptive Application can influence the behavior of State Management by writing to the Trigger fields provided
* To have the possibility and flexibility to address different groups of Modelled Processes a new communication pattern called CommunicationGroups which defines a kind of compound service with a proxy and a skeleton was introduced.
* it is essential, that a client replies to each server request, independently if the request could be fulfilled by the client or not.
* With this approach a server can:
* broadcast a message to all clients in the group
* send a message to a dedicated client in the group
* can get a list of all clients in the group
* receive the replies from all clients in the group
* Conclusion:
* State Management as a server of (multiple) CommunicationGroups can send a message to all the clients in a group and can check if all clients answered the request with expected answer
#### PowerModes for Adaptive (Platform) Applications
* The PowerModes are intended to influence the internal behavior of all Processes in the system.
* This PowerMode is used to realize the so called "late-wakeup", where a new wakeup reason is found during a proceeding shutdown
* there are three modes supported
* "On" : A Modelled Process that receives this PowerMode behaves normally as it has been spawned by ExecutionManagement. It is used to "undo" the other PowerMode requests. Modelled Processes that are just spawned should behave like an "On" is requested as PowerMode.
* EX : When the new wakeup reason is found an "On" request will be sent to the Modelled Pro- cesses, thus they can immediately continue with their "normal" work without the need to be spawned again
* "Suspend" : This PowerMode is intended to be used as a signal to the Modelled Processes that the system is suspended( e.g. to RAM or to disc). Tt will be project-specific and might depend on the environment.
* "Off" : A Modelled Process that receives this PowerMode behaves like it receives a SIGTERM from Execution Management, beside exiting.
* Modelled Processes that support the PowerModes are expected to behave like they would have received an "On" request when they are entering "Running" state when being spawned by Execution Management to keep compatibility with Modelled Processes which do not support the PowerModes.
#### Diagnostic Reset for Adaptive (Platform) Applications
* The rationale behind this is to change the behavior of Modelled Processes without the need to terminate and restart them. -> This service is intended to influence Modelled Processes that are addressed by Diagnostic Address.
* The reaction to the request itself is project- specific.
#### Interaction with Platform Health Management
* Platform Health Management is responsible for monitoring supervised entities via local supervision(s) and checking the status of health channels.
* Failures in local supervision(s) will be accumulated in a global supervision whose scope is a single Function Group (or a part of it).
* When State Management receives notification from Platform Health Manage- ment it can evaluate the information from the notification and initiate the project-specific actions to recover from the failure
#### Interaction with Diagnostic Management
* Diagnostic Management is responsible for diagnosing, configuring and resetting Diagnostic Addresses.
* Diagnostic Management provides the ara::diag::EcuResetRequest interface to forward ECU Reset service requests to State Management
* State Management has to keep track of reset causes and has to reset the persistent reset cause when it is newly spawned.
* several different reset types have to be carried out to fulfill functionality of Diagnostic Management :
* hardReset
* keyOffOnReset
* may be translated by State Managements internal logic to stop and start the Function Group
* softReset
* may be translated by State Managements internal logic to request Modelled Processes to perform internal functionality without the need to terminate and start them again
* customReset
* All Modelled Processes which should support this feature have to use the ara::com methods
#### Interaction with Update and Configuration Management
* Update and Configuration Management is responsible for installing, removing or updating Software Clusters as smallest updatable entity.
* system integrator has to limit usage of this interface to Update and Configuration Management by configuring Identity and Access Manage- ment.
* Procedure:
1. Update and Configuration Management will ask State Man- agement if it is allowed to perform an update. The decision will depend on current state of the machine (or whole vehicle)
2. As soon as State Management allows updating, it is necessary that State Man- agement denies any further request for a new update session. (multiple update sessions at a time shall be not allowed.)
3. As soon as State Management allows updating, it is necessary that State Man- agement prevents system from shutting down.
4. Update and Configuration Management has to inform State Management when no more operations for the update have to be done, thus State Management can clear now the information about an ongoing update and can continue its regular job.
* if it is necerry to shut down the machine -> Additionally State Management has to persist the information about an ongoing update session, thus, after a machine restart (independently if restart was expected or not), Update and Configuration Management can continue to update.
* During the update there will be up to three different steps, depending if a Software Cluster is installed, removed or updated.
* prepareupdate
* in this step, State Management will at least set all the Function Groups, given as parameter, to Off state. And Update and Configura- tion Management will perform the real update
* prepare verify
* perform a verification of the update
* at least set all the Function Groups, given as parameter, to Verify state.
* These request will be reported to Update and Configuration Management as failed when any of the Function Groups could not be set to the requested Function Group State
* prepare rollback
* When any of these steps fails,Update and Configuration Management can decide to revert previous changes.Therefore Update and Configuration Management uses PrepareRollback function
* PrepareRollback function will at least set all the Function Groups, given as parameter, to Off state.
* ps : When a Software Cluster is removed by Update and Configuration Man- agement, VerifyUpdate will never be called by Update and Configuration Management. Contrary to that PrepareUpdate will never be called, when a new Software Cluster is installed into the Machine.
#### Interaction with Network Management
* To be portable between different ECUs the Adaptive Applications should not have the need to know which networks are needed to fulfill its functionality, because on different ECUs the networks could be configured differently.
* The NetworkHandles are defined in the Machine Manifest and are there assigned to a Function Group State.
* Whenever (partial) networks are activated or deactivated from outside request and this set of (partial) networks is represented by a NetworkHandle in Machine Manifest Network Management will change the value of the corresponding NetworkHandle. And State Management is notified about the change, because it has registered to all availabe NetworkHandle fields.
* State Managements shall change the value of the NetworkHandle when a Function Group has to change its Function Group State. Network Management will recognize this change and will change the state of the (partial) networks accordingly to the NetworkHandle.
* afterrun :
* a Function Group stays longer in its Function Group State when the causing (partial) network set has been switched off
* a (partial) net- work is longer available than the causing Function Group has been switched to Function Group State ’Off’.

#### Interaction with Execution Management
* Execution Management is used to execute the Function Group State changes.
* The decision to change the state might come from inside of State Management based on State Managements States or might be requested at State Management from an external Adaptive Application.
* Execution Management returns the result of the request.
#### State Management in a virtualized/hierarchical environment
* Each of the virtual machines contain State Management and there may have a lot of virtual machines.
* To have coordinated control over the several virtual machines there has to be virtual machine which supervises the whole ECU state. This is not only valid for a virtualized environment, but for a hierarchical environment, too.
* State Management shall be able to register to the "Trigger" fields of a supervising State Management instance to receive information about the whole ECU state.