This part of the AMALTHEA model describes the provided functionality of an operating system. It mainly provides a way to specify how access is given to certain system resources. Therefore the concepts of scheduling, buffering, and semaphores are supported, which are described in detail in the following chapter.
The basic element in the OS Model is the operating system. There can 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.
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 a scheduling unit. The scheduling unit can be either a hardware scheduling unit or a software scheduling unit.
This class is used when scheduling is done by a hardware unit. The only attribute of this class
is the delay attribute. It represents the amount of time that is required to execute scheduling.
This class is used when scheduling is done by software unit.
This is an abstract class for the different scheduling algorithms.
| Scheduling Algorithm | Description |
|---|---|
| OSEK | OSEK compliant Scheduling Algorithm |
| PfairPD2 | Proportionate Fair PD 2 Scheduling Algorithm |
| PartlyPFairPD2 | PPfair-PD 2 (Partly Proportionate Fair PD 2 Scheduling Algorithm) |
| PartlyEarlyReleaseFairPD2 | P-ERfair-PD 2 (Partly Early Release Fair PD 2 Scheduling Algorithm) |
| EarlyReleaseFairPD2 | ERfair-PD 2 (Early Release Fair PD 2 Scheduling Algorithm) |
| LeastLocalRemainingExecutionTimeFirst | Task with the smallest local remaining execution time gets the highest priority |
| EarliestDeadlineFirst | EDF (Earliest Deadline First Scheduling Algorithm): Task with the earliest deadline gets the highest priority |
| DeadlineMonotonic | DMS (Deadline Monotonic Scheduling Algorithm): Task with the shortest period gets the lowest priority |
| RateMonotonic | RMS (Rate Monotonic Scheduling Algorithm): Task with the shortest period gets the highest priority |
| PriorityBasedRoundRobin | Round Robin Scheduling Algorithm with prioritized processes |
| UserSpecificSchedulingAlgorithm | This class contains a list of algorithm parameter. Each parameter has a key and a value (both Strings). A user can store all information for its own specific scheduling algorithm here |
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.
There exists also an overhead for API calls. The following API calls are considered:
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:
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:
The DataStability class defines for which sequence of runnables data has to be kept stable. This can either be stability within a process meaning over all its runnables, within each runnable or within each schedule section. Furthermore, it can be stated whether all data is considered for stability or just those accessed multiple times.
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.
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) |
| maxValue | Maximum number of processes that can concurrently access the semaphore |
| initialValue | Initial number of processes that 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 |