Requirements

Definitions

Definition: Application		status: valid security: NO safety: QM
status: valid security: NO safety: QM reqtype: Functional satisfies: STKH_REQ__282
An application consists of one or more activities. An application consists of one or more operating system processes. In particular it consists of the primary process which handles the lifecycle, configuration and execution management. It may optionally consist of one or more Secondary processes. The purpose of secondary processes is to run code in separate address spaces (Freedom From Interference) for safety reasons. Each process (primary and secondary) belongs to exactly one application. Each process contains one ore more operating system threads.
FEAT_REQ__feo__application		Feature Requirement

Definition: Activity		status: valid security: NO safety: QM
status: valid security: NO safety: QM reqtype: Functional satisfies: STKH_REQ__282
Activities are mapped to threads within primary or secondary processes. Each activity is mapped to exactly one thread and provides the following functions: init: Initialization of the activity. step: Execution of the activity. shutdown: Shutdown of the activity. The mapping is done in a configuration file and cannot be changed at runtime.
FEAT_REQ__feo__activity		Feature Requirement

Definition: Task Chain		status: valid security: NO safety: QM
status: valid security: NO safety: QM reqtype: Functional satisfies: STKH_REQ__282
All activities within an application are arranged within a Task Chain. There is exactly one task chain per application. The task chain configuration defines the execution order of the activities. In particular it defines when the task chain is activated (typically in a cyclic manner) and in which order the activities will run. Every task chain has exactly one receiver activity which will run in the beginning. The purpose of the receiver activity is to collect external input signals and provide them to the other activities during task chain execution. Every task chain has exactly one sender activity which will run in the end. The purpose of the sender activity is to collect signals produced by activities within the task chain and send them to external entities.
FEAT_REQ__feo__task_chain		Feature Requirement

Dynamic Architecture

The lifecycle of an `Application` consists of 3 phases: Init, Run and Shutdown.		status: valid security: NO safety: QM
status: valid security: NO safety: QM reqtype: Functional satisfies: STKH_REQ__282
The Application Lifecycle consists of 3 phases: Init, Run and Shutdown.
FEAT_REQ__application_lifecycle		Feature Requirement

Initialization of activities		status: valid security: NO safety: QM
status: valid security: NO safety: QM reqtype: Functional satisfies: STKH_REQ__282
Initialization of activities is done during application initialization. Each activity is initialized by a call to its init function. The init function will be invoked in the thread to which the activity is mapped. Note that init, step and shutdown functions will be run in the same thread.
FEAT_REQ__feo__activity_init		Feature Requirement

Stepping of activities		status: valid security: NO safety: QM
status: valid security: NO safety: QM reqtype: Functional satisfies: STKH_REQ__282
Each activity is stepped once within each execution of the task chain they belong to. Stepping is done by a call to an activity’s step function.
FEAT_REQ__feo__activitiy_step		Feature Requirement

Shutdown of activities		status: valid security: NO safety: QM
status: valid security: NO safety: QM reqtype: Functional satisfies: STKH_REQ__282
Shutdown of activities is done during application shutdown. Each activity is shut down by a call to its shutdown function. The shutdown function will be invoked in the thread to which the activity is mapped.
FEAT_REQ__feo__activity_shutdown		Feature Requirement

Supervision

Alive supervision		status: valid security: NO safety: ASIL_D
status: valid security: NO safety: ASIL_D reqtype: Functional satisfies: STKH_REQ__282
The framework shall provide the functionality to enable the reporting of alive supervision checkpoint to an external health management system (e.g. watchdog)
FEAT_REQ__feo__alive_supervision		Feature Requirement

Support of deadline supervision checkpoints		status: valid security: NO safety: ASIL_D
status: valid security: NO safety: ASIL_D reqtype: Functional satisfies: STKH_REQ__282
The framework shall provide the functionality to enable the reporting of deadline supervision checkpoints to an external health management system (e.g. watchdog)
FEAT_REQ__feo__deadline_supervision		Feature Requirement

Support of logical supervision		status: valid security: NO safety: ASIL_D
status: valid security: NO safety: ASIL_D reqtype: Functional satisfies: STKH_REQ__282
The framework shall provide the functionality to enable the reporting of logical supervision checkpoints to an external health management system (e.g. watchdog)
FEAT_REQ__feo__logical_supervision		Feature Requirement

Trustable computation		status: valid security: NO safety: QM
status: valid security: NO safety: QM reqtype: Functional satisfies: STKH_REQ__282
The framework shall provide mechanisms to check after the computation of an Activity if the result is trustable. This can be done e.g. via evaluation of floating point exceptions, checking of hardware registers or status information of the software platform.
FEAT_REQ__feo__trustable_computation		Feature Requirement