## OS Model

This part of the AMALTHEA model describes the provided functionality of an operating system. Therefore the concepts of scheduling, buffering, and semaphores are supported, which are described in detail in the following chapter.

### Operating System

The basic element in the OS Model is the operating system. There can be multiple operating systems in one model. The operating system type can be used to describe a generic operating system. It is also possible to use the vendor operating system type to define a vendor specific OS. An operating system contains a number of task schedulers and interrupt controllers. A task scheduler controls the execution of a task on one or multiple processor cores. An interrupt controller is the controller for the execution of ISRs and can be also mapped to multiple cores. The mapping of tasks and ISRs to their controller and the mapping of the controller to the cores can be done in the Mapping Model. An operating system can also contain a description of the overhead it produces. For this there is a more detailed explanation below.

### Scheduler

Interrupt controller and task scheduler have a scheduling algorithm. The picture below shows that both types are inherited of the scheduler type. Each scheduler has computation items. These items (a subset of the runnable items) characterize the runtime behavior (algorithmic overhead) of the scheduler.

#### Scheduling Algorithm

This is an abstract class for the different scheduling algorithms.

Scheduling Algorithm | Description
--- | ---
Grouping | This scheduler is a logical grouping of tasks/child-schedulers, e.g. a partition with attached budget for all tasks. This scheduler does not take any scheduling decisions and a parent scheduler is mandatory.
UserSpecificSchedulingAlgorithm | This class contains a list of algorithm parameters. Each parameter has a key and a value (both Strings). A user can store all information for its own specific scheduling algorithm here.
Fixed Priority
OSEK | OSEK compliant Scheduling
FixedPriorityPreemptive | Fixed Priority Preemptive Scheduling (e.g. AUTOSAR)
FixedPriorityPreemptiveWithBudgetEnforcement | Fixed Priority Preemptive Scheduling (with budget enforcement)
DeadlineMonotonic | Deadline Monotonic Scheduling (DMS): Task with the shortest period gets the lowest priority.
RateMonotonic | Rate Monotonic Scheduling (RMS): Task with the shortest period gets the highest priority.
Dynamic Priority
EarliestDeadlineFirst | Earliest Deadline First (EDF): Task with the earliest deadline gets the highest priority.
LeastLocalRemainingExecutionTimeFirst | Least Local Remaining Execution-time First (LLREF): Task with the smallest local remaining execution time gets the highest priority.
PriorityBasedRoundRobin | Round Robin Scheduling Algorithm with prioritized processes.
Proportionate Fair (Pfair)
PfairPD2 | Proportionate Fair PD2 Scheduling (Pfair-PD2)
PartlyPfairPD2 | Partly Proportionate Fair PD2 Scheduling (PPfair-PD2)
EarlyReleaseFairPD2 | Early Release Fair PD2 Scheduling (ERfair-PD2)
PartlyEarlyReleaseFairPD2 | Partly Early Release Fair PD2 Scheduling (P-ERfair-PD2)
Reservation Based Server
DeferrableServer | Deferrable Server (DS): provides a fixed budget, in which the budget replenishment is done periodically.
PollingPeriodicServer | Polling Server (PS): provides a fixed budget periodically that is only available at pre-defined times.
SporadicServer | Sporadic Server (SS): provides a fixed budget, in which the budget replenishment is performed only if it was consumed.
ConstantBandwidthServer | Constant Bandwidth Server (CBS): provides a fixed utilization for executing jobs, in which the deadline for execution is independent on the execution time of jobs.
ConstantBandwidthServerWithCASH | Constant Bandwidth Server (CBS) with capacity sharing (CASH). Consumes residual slack from other servers (work conserving).

##### Further information

Details regarding proportionate fair ( Pfair) scheduling and the variants of the PD2 Pfair algorithm can be found in the dissertation “Effcient and Flexible Fair Scheduling of Real-time Tasks on Multiprocessors” by Anand Srinivasan (see dissertation at University of North Carolina at Chapel Hill).

An overview regarding Reservation Servers is given in the lecture “Resource Reservation Servers” by Jan Reineke (see lecture at Saarland University).

#### Scheduling Parameters

The class SchedulingParameters contains predefined parameters that are relevant for many scheduling algorithms. If a parameter is not used in a given context the value is null. Additional parameters can be added as key-value pairs of class ParameterExtensions.

Attribute | Description
--- | ---
priority | Specifies the priority for the child-scheduler for priority based scheduling algorithms like FPP.
minBudget | In budget-based scheduling algorithms like sporadic servers the runtime in a periodic time-interval must be given. The budget can be defined via min/max budgets. If no intervals are possible, the maxBudget is the key value.
maxBudget
replenishment | The replenishment time defines period in which the budget is restored.

#### Scheduler Association

A hierarchy of schedulers can be specified with intermediate objects of class SchedulerAssociation. If set, the parent scheduler takes the initial decision who is executing. If the child-scheduler is not a grouping of tasks, it can take scheduling decisions if permission is granted by the parent. The association also contains the relevant parameters of the scheduler in the hierarchical context.

Attribute | Description
--- | ---
parent | Refers to the parent scheduler
child | Derived attribute that is computed based on the containment reference “parentAssociation” from Scheduler to SchedulerAssociation
schedulingParameters | See chapter "Scheduling Parameters"
parameterExtensions

### Os Overhead

It is possible to define the overhead that is produced by an operating system. The defined overhead can be assigned to an operating system definition. Each overhead information is defined as a set of instructions that has to be executed when the corresponding OS function is used. The instructions can be either a constant set or a deviation of instructions. It is possible to define the overhead for the ISR category one and two and for a number of operating system API functions.

#### ISR Overhead

- ISR category 1 & 2: Describes the overhead for ISRs of category one and two by adding a set of instructions that is executed at start and terminate of the ISR

#### API Overhead

There exists also an overhead for API calls. The following API calls are considered:

- API Activate Task: Runtime overhead for the activation of a task or ISR by another task or ISR (inside the activating process)
- API Terminate Task: Runtime for explicit task termination call (inside a task)

- API Schedule: Runtime for task scheduling (on scheduling request)

- API Request Resource: Runtime overhead for requesting a semaphore (inside a runnable)
- API Release Resource: Runtime overhead for releasing a semaphore (inside a runnable)

- API Set Event: Runtime overhead for requesting an OS event (inside a task or ISR)
- API Wait Event: Runtime overhead for waiting for an OS event (inside a task or ISR)
- API Clear Event: Runtime overhead for clearing an OS event (inside a task or ISR)

- API Send Message: Runtime overhead for cross-core process activation or event (inside a task or ISR)
- API Enforced Migration: Runtime overhead for migrating from one scheduler to another scheduler (inside a task or ISR)

- API Suspend OsInterrupts
- API Resume OsInterrupts

- API Request Spinlock
- API Release Spinlock

- API SenderReceiver Read
- API SenderReceiver Write

- API SynchronousServerCallPoint

- API IOC Read
- API IOC Write

### OS Data Consistency

The OsDataConsistency class provides a way to configure an automatic data consistency mechanism of an operating system. It is used to cover the following two use cases:

- Provide a configuration for external tools that perform a data consistency calculation based on the stated information.
- Provide the results of a performed data consistency calculation which then have to be considered by external tools (e.g. by timing simulation).

To distinguish the different use cases and to consequently also indicate the workflow progress for achieving data consistency, OsDataConsistencyMode allows to define the general configuration of the data consistency. The following modes are available:

1. noProtection: data stability and coherency is NOT automatically ensured.
2. automaticProtection: data stability and coherency HAS TO BE ensured according configuration either via custom protection or via model elements.
   1. customProtection: data stability and coherency IS ensured according configuration but not via model elements.
   2. handeldByModelElements: data stability and coherency IS ensured via model elements.

The DataStability class defines for which sequence of runnables data has to be kept stable. Furthermore, it can be stated whether all data is considered for stability or just those accessed multiple times.

DataStabilityLevel:

- period - between consecutive activations
- process - within a Task or ISR
- scheduleSection - between Schedule points (explizit schedule points, begin and end of process)
- runnable - within a Runnable

The NonAtomicDataCoherency class defines for which sequence of runnables data has to be kept coherent. Like for data stability it can be stated whether all data is considered for coherency or just those accessed multiple times.

### Semaphore

With this object, a semaphore can be described which limits the access of several processes to one resource at the same time.

Attribute | Description
--- | ---
name | Name of semaphore (inherited from ReferableBaseObject)
semaphoreType | Defines how the semaphore is implemented
initialValue | Initial number of processes that access the semaphore
maxValue | Maximum number of processes that can concurrently access the semaphore
priorityCeilingPrototcol | Defines if the priority ceiling protocol is activated. If it is activated, a process that accesses the semaphore gets a higher priority as the processes that can also access the same semaphore