### Software (development)

The AMALTHEA System Model can also be used in early phases of the development process when only limited information about the resulting software is available.

#### Runnables

The Runnable element is the basic software unit that defines the behavior of the software in terms of runtime and communication. It can be described on different levels of abstraction:

1. timing only (activation and runtime)
2. including communication (in general)
3. adding detailed activity graphs

To allow a more detailed simulation a description can also include statistical values like deviations or probabilities. This requires additional information that is typically derived from an already implemented function. The modeling of observed behavior is described in more detail in chapter Software (runtime).

#### Process Prototypes

Process Prototypes are used to define the basic data of a task. This is another possibility to describe that a set of Runnables has a similar characteristic (e.g. they have the same periodic activation).
A prototype can then be processed and checked by different algorithms. Finally a partitioning algorithm generates (one or more) tasks that are the runtime equivalents of the prototype.

This processing can be guided by specifications that are provided by the function developers:

- The Order Specification is a predefined execution order that has to be guaranteed.
- An Access Specification defines exceptions from the standard write-before-read semantics.

#### Constraints

In addition the partitioning and mapping can be restricted by Affinity Constraints that enforce the pairing or separation of software elements and by Property Constraints that connect hardware capabilities and the corresponding software requirements.
The Timing Constraints will typically be used to check if the resulting system fulfills all the requirements.

#### Activations

Activations are used to specify the intended activation behavior of Runnables and ProcessPrototypes. Typically they are defined before the creation of tasks (and the runnable to task mappings). So this is a way to cluster runnables and to document when the runnables should be executed.

The following activation patterns can be distinguished:

- Single: single activation
- Periodic: periodic activation with a specific frequency
- Sporadic: recurring activation without following a specific pattern
- Event: activation triggered by a TriggerEvent
- Custom: custom activation (free textual description)

To describe a specific (observed) behavior at runtime there are Stimuli in the AMALTHEA model. They can be created based on the information of the specified activations.