# Execution Management
###### tags: `報告` `專題`

* noun explanation:
* Application
* to resolve a set of coherent functional requirements.
* consists:
* executable software units
* additional execution related items (e.g. data or parameter files)
* descriptive information used for integration end execution
* In general, an Application, whether user-level or platform-level, is treated the same by Execution Management and can use all mechanisms and APIs provided by the Operating System and other functional clusters of the AUTOSAR Adaptive Plat- form. -> restricts its portability to other implementations of the AUTOSAR Adaptive Platform.
* Adaptive application
* is a specific type of Application.
* Adaptive Applications are always located above the middleware. To allow portability and reuse, user level Applications should be Adaptive Applications whenever technically possible.
* Executable
* An Executable is a software unit which is part of an Application. It has exactly one entry point (main function) [SWS_OSI_01001]. An Application can be implmented in one or more Executables [TPS_MANI_01010].
* 

* Modelled Process
* is an instance of an Executable and it is realized at run-time as an OS process.
* Execution manifest
* An Execution Manifest is created together with a Service Instance Manifest (not used by Execution Management) at design time and deployed onto a Machine together with the Executable it is attached to.
* The Execution Manifest is bundled with the actual executable code in order to support the deployment of the executable code onto the Machine.
* Each instance of an Executable binary, i.e. each started process, is individually configurable, with the option to use a different configuration set per Machine State or per Function Group State
* Machine manifest
* is also created at integration time for a specific Machine and is deployed like Execution Manifests whenever its contents change.
* holds all configuration information which cannot be assigned to a specific Executable or its instances
* Manifest Format
* TheExecution ManifestsandtheMachine Manifestcanbetransformedfrom the original standardized ARXML into a platform-specific format
* The format transforma- tion can be done either off board at integration time or at deployment time, or on the Machine (by Update and Configuration Management) at installation time.
* About how to start nm:
* double check about em start nm:
* 
* In this picture,
* 
* We can know that, platform moudles are contained in the applications in em's view.
* And next, we need to know more about application. In the previous noun explanation, we know that there has an entry point. So, I think we should write a program with main function.
* Executalbe lifecycle from deployment to execution
* 
* Besides executable, we also need to write execution manifest in order to support the deployment of the executable code onto the Machine.
* A process is a loaded instance of an Executable, which is part of an Application.
* Execution Management ensures that the integrity and authenticity of all Executa- bles and Executable-related data (e.g. manifests) is checked.
* Depending on the Machine State or on any other Function Group State, de- ployed Executables are started during AUTOSAR Adaptive Platform startup or later. -> so we can suppose that nm will start closely after AUTOSAR Adaptive Platform startup because nm do not need to rely on the others module
* Life cycle:
* in Execution State
* 
* Execution States characterizes the internal lifecycle of a process. In other words, they describe it from the point of view of a process that is executed.
* The Execution State of a process is used by Execution Management to construct and maintain the Process State
* Execution State change notifications from a process result in Process State changes managed by Execution Management.
* Execution Management considers process initialization complete when the Process State Running is reached whether this is achieved implicitly (by a Non-re- porting Process) or explicitly through a process reporting its Execution State.
* A process is required (see [SWS_EM_01004]) to report kRunning state using the ara::exec::ExecutionClient::ReportExecutionState [SWS_EM_02003] method of class ara::exec::ExecutionClient
* It would typically report after the completion of its initialization, but before Service Discovery is completed. If the process were to report kRunning only after Service Discovery completion, the non-deterministic delays may impact other processes, due to delays in resolution of Execution Dependencies.
* Conclude in Execution State:
* Execution State is describe states from the point of view of a process that is executed
* When process compleleted its initializtion, it need to report "krunning state" to em its Execution State to let EM know that the process's initialization have done.
* But we can know that, if we don't report krunning state to let em know we finished initializtion, there will be a module named Service Discovery to notify em that the process is finish. The only problem that we didn't report is that the non-deterministic delays may impact other processes, due to delays in resolution of Execution Dependencies. ( but nm don't have dependencies on the others module)
* in Process Stste
* Process States characterize the lifecycle of a process from the point of view of Execution Management. In other words, Process States represent the Exe- cution Management internal tracking of the Execution States (see Section 7.4.1) and hence there is no need for a standardized type
* 
* 
* environment variable:
* Execution Management initializes environment variables for processes. process specific environment variables are configured inits Execution Manifest.
* 
* start up with Arguments
* Execution Management provides argument passing for a process containing one or more StateDependentStartupConfig in the role Process.stateDepen- dentStartupConfig. This permits different processes to be started with different arguments.
* 
* 
* Execution Management supports passing arguments to a process in the same way that a shell passes command line arguments to a POSIX process.
* Machine start up sequence :
* EM -> EM initiates the Machine State : off state > start state (#1) -> EM reports Machine State Startup transition confirmation to State Management (#2)
* (#1) During the transition, Execution Manage- ment requests startup of processes that exist in the Startup Machine State.
* (#2) At that point, EM hands over responsibility for Function Group state management (i.e. initiation of state change requests) to State Management.
* EM is not necessarily the first process launched, Other processes needed by the system may exist,
* Please note that an Application consists of one or more Executables. There- fore to launch an Application, Execution Management starts processes as instances of each Executable.
* 
* 
* 

* How to end nm?
* Execution Management is started as part of the AUTOSAR Adaptive Platform startup phase and is responsible for starting and terminating processes. -> so we can know that em will terminate nm
* Execution Management does not perform standardized termination handling - the response to receipt of a signal, e.g. SIGTERM, by Execution Management is there- fore implementation defined.
* 
* Note that from the perspective of Execution Management, requirement [SWS_EM_01055] only requests the initiation of the steps necessary for grace- ful termination under the control of the process.
* Execution ManagementmaysendSIGTERMatanytime,evenbeforetheprocess has reported kRunning state and thus the process is still in the Initializing Process State. On receipt of SIGTERM, a process simply commences the actual termination.-> we can terminate it any time
* Terminating state target :
* save persistent data
* free all internally used resources
* termination with exit status 0 (EXIT_SUCCESS)
* EM as the parent process can help child process and take the appropriate platform-specific actions such as processing exe- cution dependencies that rely on the Terminated state and thus ensure that there is no overlap between these processes when both are running. -> but I think that we don't need it because nm don't rely on the others module
* Another choice:
* Execution Managementdifferentiatesbetweentwotypesofprocesses:Report- ing Processes and Non-reporting Processes. Reporting Processes are considered to be the normal form of processes and Non-reporting Processes are considered to be an exception.
* Non-reporting Processes can be used to support running Executables which have not been designed with the AUTOSAR Adaptive Platform in mind. For example, if an Executable is available as binary only, if it is not feasible to patch its source code or if the Executable is only used during development time.