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.
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:
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 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:
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 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:
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.