The AMALTHEA software model is central accessible through the SWModel element.
Analyzing and mapping the software structure to available memories needs additional information of the included elements. This type of information targets the consumed size of memory of an element, represented by the size attribute of type DataUnit. The element AbstractMemoryElement is a generalized element that provides this data. The following image shows the structure and also the elements of the software model that are extending AbstractMemoryElement (the overview picture is only showing the hierarchy and not possible relationships between the elements):
The label element represents a data element. It is directly located in a defined area of a given memory.
It can be used as a parameter, a temporarily existing variable or representing a constant value.
The following attributes are describing a label:
Name | Description |
---|---|
name | The name represented as String value (derived from AbstractElementMemoryInformation) |
displayName | In addition to the name attribute, which must be unique, a label can also be described by an additional and optional display name. The displayName attribute must not be unique. It can be used for example to represent specification data, which can be different from the unique name (like a symbol) of an available software build. |
dataType | Reference to the data type definition |
constant | Boolean value to represent, if label is representing a constant value |
bVolatile | Boolean value to mark a label as volatile |
dataStability | Enumeration value to represent the data stability needs of the label. If set, it overwrites the global settings stated by the OsDataConsistency, otherwise it inherits them (see OS Data Consistency). |
stabilityLevel | Enumeration value to represent the data stability level of the label. If set, it overwrites the global settings stated by the OsDataConsistency, otherwise it inherits them (see OS Data Stability). |
The channel element has two different characteristics: it represents a data element in memory and also a way how runnables transmit larger amounts of data. A typical applications is the streaming of video data where a continuous sequence of images is sent in smaller chunks.
The following attributes are describing a label:
Name | Description |
---|---|
name | The name represented as String value (derived from AbstractElementMemoryInformation) |
displayName | In addition to the name attribute, which must be unique, a label can also be described by an additional and optional display name. The displayName attribute must not be unique. It can be used for example to represent specification data, which can be different from the unique name (like a symbol) of an available software build. |
elementType | Reference to the data type definition of a single element |
defaultElements | Number of elements initially in the channel (at start-up) |
maxElements | Depth of channel (maximum number of elements that may be stored) |
The AMALTHEA data model supports meta information for data types. Therefore the element TypeDefinition exists in the software part of the model. It consists of the name and size to define a data type. BaseTypeDefinition has the additional possibility to define the representation of these data types in a target environment (e.g. AUTOSAR), represented by the Alias element.
The compound data types are data structures, based on given or defined base types.
In the literature they are also often named composite or derived types
see Wiki.
The result of this type of definition is an own data type, which can be used as base data types.
They can consist of static structures or dynamic ones, like arrays or stacks.
The following compound data type definitions are currently supported:
In the picture below a small sample is modeled containing the following information:
Note: The picture shows the element types for better understanding!
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 if there are no tasks defined, or if the mapping of runnables to tasks is not done, this is a way to document when the runnables should be executed.
Activations are independent of other top level elements in the AMALTHEA model. Single, periodic, sporadic, event or custom (free textual description only, no predefined semantic) activation pattern can be defined. This information can be used in the following development steps to create tasks, stimuli and the mappings to dedicated hardware.
The following figure shows the structure which describes Tasks and Interrupt Service Routines ( ISR) in the AMALTHEA software model. The abstract class Process generalizes ISRs and Tasks and provides the common attributes like the activation that is at runtime level represented by a Stimulus. A Task or ISR contains calls either to other Tasks (via inter process activation) or Runnables. These types of calls are included in the activityGraph attribute.
Name | Description |
---|---|
name | Name of the process |
stimuli | Reference to one or more Stimuli representing the different types of possible activations of this Process |
activityGraph | List of activities (e.g. runnable calls, label accesses). This specifies the behavior of the process. The objects will be executed in the same order they are stored in the list. |
preemption | Defines the preemption of a task by higher priority tasks. |
multipleTaskActivationLimit | Defines the maximum number of existing instances from the same task at any time, which is checked for load limitation reasons when a task is activated. If the multipleTaskActivationLimit is exeeded, the activation is ignored. See the “BTF Example” (User Guide > Examples) for an multipleTaskActivationLimit of 3. |
Both elements, runnables and services, are an abstraction of an executable entity. They are both represented by the
Runnable element and are distinguished by using the service attribute of type boolean.
Unlike tasks, which are activated in the context for the operating system, runnables are called by tasks or other runnables.
Runnables and Services in the AMALTHEA model can have call parameters. It is possible to specify the arguments of a service call and potential data dependencies. Based on these types of information, an additional analysis can be performed.
The next picture shows the general structure of the Runnable element.
Name | Description |
---|---|
callback | True if a runnable is used as a callback |
service | True if Runnable element can be seen in a service or global function manner. In more detail, the Runnable is only called from other Runnables and not directly from a Task context. |
activations | Although runnables in the simulation can only be called by tasks, it is possible to specify activation patterns for a runnable. |
executionCondition | It is possible to specify an execution condition for a runnable (depending on modes). |
activityGraph | Top level object containing ActivityGraphItem objects, representing runtime, label accesses, other Runnable accesses. The possibilities are described below. |
tags | Can be used to annotate or group special kind of Runnables |
A ActivityGraph is the root container of ActivityGraphItems. In addition some of the items can also contain sub items. These items are implementing the interface IActivityGraphItemContainer.
The following picture shows the structure of a Activity Graph. The Activity Graph Items are used to define detailed behavior. With the Switches it is possible to define alternative execution paths. The elements of the graph are executed in the order they are stored in the data model.
The ActivityGraphItems are describing the detailed behavior of a Process or Runnable. This can be either an abstraction of runtime or representing access to other elements like Runnables, Labels, and Semaphores. An overview of the different possibilities is given in the next pictures.
A Group is used to structure the ActivityGraphItems.
Name | Description |
---|---|
ordered | boolean attribute that indicates if the execution order of the contained elements is fixed (default) or random. |
interruptible |
boolean attribute that specifies whether the group
can be interrupted (default). If set to false the group cannot be interrupted (neither by interrupts nor by other higher priority tasks). |
Some hints regarding non-interruptible groups:
A WhileLoop enables to represent repetitions of activity graph items within an activity graph. These repeated items are contained in items (from ActivityGraphItemContainer). They will be repeated as long as the condition is evaluated to be true. In order to enter the while loop at all, the condition must initially be true.
Switches can be used to define different execution paths within an activity graph. A
Switch corresponds to
if-else or
switch-case statements in a programming language. It uses the evaluated
ConditionDisjunction to decide which entry will be executed. The first fulfilled condition determines the path to execute.
A
SwitchEntry object is used to represent an execution path. A condition is defined for each entry (via
ConditionDisjunction).
At the
Switch it is also possible to define a default path, which is executed if none of the conditions of the
SwitchEntries is true.
Each entry (path) of a ProbabilitySwitch has a probability-value. As the name indicates, this is the value that defines the probability that the path is executed. It is computed as a fraction of its value divided by the sum of all ProbabilitySwitchEntries in the surrounding switch.
Ticks allow to specify the required execution “time” in a basic way. They are the equivalent of cycles in the hardware domain and the execution time can easily be calculated if the frequency of the executing
ProcessingUnit (PU) is known.
Detailed definition: see Ticks
ExecutionNeed allows to specify the required execution “time” in a more abstract way. Multiple NeedEntries can be used to specify execution characteristics. There is a map of default entries and (optional) maps of entries for specific hardware types (e.g. FPGA). These extended entries are also implemented as a map with a processing unit definition as the key.
A simple approach (equivalent to the RunnableInstructions in older versions of the AMALTHEA model) is the specification of the “number of generic instructions” that have to be executed. Together with the hardware feature “instructions per cycle (IPC)” and the frequency of a processing unit it permits the calculation of the execution time on a specific processing unit.
With the generic concept of ExecutionNeeds it is also possible to describe more detailed characteristics, e.g. instruction mixes of floating point operations, integer operations, load/store operations, etc., or any other relevant aspect.
Name | Description |
---|---|
RunnableCall | The activation of another Runnable. |
SenderReceiverCommunication | An abstract description for sender-receiver-communication (it can be read or write). |
ServerCall | An abstract description for client/server communication. It refers to a required runnable that describes the called server operation |
SynchronousServerCall | A synchronous server call with defined waiting behaviour. |
AsynchronousServerCall | An asynchronous server call with (optional) specification of result runnable. |
GetResultsServerCall | Get the result of a previous asynchronous server call (with defined blocking behaviour). |
Name | Description |
---|---|
access | The type of access is represented using the values of LabelAccessEnum. |
data | Describes the access to an existent Label (set as reference). |
dataStability | Describes the data stability needs. If set, it overwrites the label settings, otherwise it inherits them (see OS Data Consistency). |
implementation | Describes how a label access is implemented:
|
statistic | Defines the frequency of the label access. |
transmissionPolicy | The following attributes reflect the computing demand (time) depending on data:
|
Common attributes:
Name | Description |
---|---|
data | Describes the access ( ChannelSend or ChannelReceive) to an existent Channel (set as reference). |
elements | Maximum number of elements that are transmitted. |
transmissionPolicy | The following attributes reflect computing demand (time) depending on data:
|
Receive attributes:
Name | Description |
---|---|
receiveOperation | The type of an operation is defined by LIFO or FIFO, Read or Take:
|
elementIndex | Position (index) in channel at which the operation is effective. Zero is the default and denotes the oldest (FIFO) or newest element (LIFO) in the channel. |
lowerBound | Minimum number of elements returned by the operation. The value must be in the range [0,n], with n is the maximum number of elements that are received. Default value is n. |
dataMustBeNew | Specify if the operation must only return elements that are not previously read by the runnable. Default value is false. |
Name | Description |
---|---|
SemaphoreAccess | Represents an access of a Semaphore. The type of access is defined using the SemaphoreAccessEnum values. The Semaphore itself is set as a reference to an existent one. |
access | Defines the type of access (request, exclusive, release). Note that for spinlocks and mutexes, a request access is always exclusive, so request means the same as exclusive in these cases. |
waitingBehaviour | Defines if the process is blocking the core when it waits (active) or not (passive). Note that for spinlock accesses, only active waiting can be used. |
Name | Description |
---|---|
ModeLabelAccess | Describes the access to an existing
ModeLabel (set as reference). The type of access is represented using the values of
ModeLabelAccessEnum:
|
The Custom Event Trigger references an event of type Custom Event. The execution of a Custom Event Trigger entry triggers the corresponding event that can be observed by an Event Stimulus.
Each task is controlled by at least one task scheduler. A task scheduler is the resource owner of one or multiple processor cores (The task scheduler decides on which of its cores the task is executed). The Enforced Migration forces the task to switch to another task scheduler. Therefore the Enforced Migration entry contains a reference to the new task scheduler.
This element is used as a short notation to simplify the simulation of different design possibilities. It should normally be modeled as two separate tasks and an inter process trigger.
The Inter Process Trigger references a stimulus of type Inter Process Stimulus. The execution of an Inter Process Trigger entry triggers the processes that are mapped to this stimulus.
At a Schedule Point, the process calls the scheduler that currently administrates it. This is used for cooperative task scheduling (see OSEK Specification 2.2.3, 2005).
If a Terminate Process is reached during the execution of a Activity Graph, the Task or ISR terminates immediately. It is not required to insert this element at the end of a Activity Graph. It can be used to define an execution path (by using Switches) that terminates a process.
The AMALTHEA Software Model contains a list of OS-Event objects. These can be used for task synchronization. Elements are Wait Event, Clear Event and Set Event.
With Wait Event the process waits for a number of events (defined in the Event Mask) to be set. Here it can be defined if the process waits just for one of the OS-Events (maskType = OR) or for all of them (maskType = AND). The waiting behaviour defines if the process is blocking the core when it waits (active) or not (passive).
Set Event sets/fires a list of OS-Events. Here it is possible to define a context for the OS-Event. If a process is referenced, then the OS-Events are set just for this process.
The execution of a Clear Event entry unsets all referenced OS-Events.
For more information about OS-Events, see the OSEK Specification 2.2.3, 2005.
It is possible to add to different elements (as shown in the picture above) different types of statistical values. These values can be used to describe in more detail the following behaviors:
The next diagram shows the overall picture, the sub chapters describe the details.
The actual state of a Mode is represented by a
ModeLabel or a
LocalModeLabel.
The (global) mode labels are mainly used in
Mode Conditions to describe the conditional execution of a
Runnable or a
Stimulus.
Local mode labels are defined in the context of an executable and can be modified in the activity graph.
Both types of mode labels can be used to determine which path should be executed in a
Switch statement or how often the body of a
WhileLoop should be repeated.
The Mode element denotes the type and the possible values of a specific system state. The subclasses EnumMode and NumericMode describe the values that are allowed for the corresponding ModeLabel. In case of a EnumMode the initialValue has to be the name of one of the contained ModeLiterals. For NumericMode the initialValue has to be the string representation of an integer.
Both Mode Label elements are a concrete representation of a specific Mode. They are described using the following attributes:
Name | Description |
---|---|
name | Name of the mode label |
displayName | In addition to the name attribute, which must be unique, a mode label can also be described by an additional and optional display name. The displayName attribute must not be unique. It can be used for example to represent specification data, which can be different from the unique name (like a symbol) of an available software build. |
mode | Reference to the corresponding Mode definition |
initialValue | String representation of the initial value (of a mode label) |
defaultValue | String representation of the default value (of a local mode label) |
The value of a (global) mode label can be changed using the set-mode-value-list of a Stimulus.
Another possibility is a write access within an Activity Graph via a Mode Label Access or Local Mode Label Assignment.
Mode conditions allow to specify dedicated states of the overall system.
Depending on the condition evaluation switches can be executed or stimuli can be influenced.
The ModeValueMap represents the system state that has to be provided as an external input, e.g. from a simulation or analysis tool.
Local mode labels are defined in the context of an executable (Task, ISR or Runnable).
The class diagram shows the abstract class LocalModeValue that provides the connection between a local mode label and a value source.
Possible value sources:
The subclasses are used for comparison and assignment.
The Local Mode Label Assignment offers a number of possibilities to change the value of a local mode label. Values can be constant, the copied value of another mode label or even the result of an arithmetic expression.
The Mode Label Assignment simply provides a way to copy the content of a local mode label to a global one.
Local mode conditions are available where local mode labels are accessible. That means they can be used in Switch or WhileLoop statements in the activity graph of an executable.
The following example shows a local mode label “loop1” that represents a numeric mode called “Counter”. It is defined in the scope of the runnable “ABSCalculation”. This scope is also seen in all references to the local mode label where the qualified name “ABSCalculation.loop1” has to be used. The value of the local mode label is modified and checked by several items of the activity graph: the value is set, checked in the loop condition of a while loop and decremented in the loop body. The last line shows that it is also possible to store the value of a local mode label in a (global) mode label.
The local mode labels of an executable are available only during the execution. The next part of the example shows how to initialize local mode labels of the called runnable as part of the runnable call. This feature allows to set the context of a specific invocation and the runnable can react accordingly (e.g. by executing different paths of the activity graph).
In addition to the Task elements, the AMALTHEA model contains an element process prototype.
This prototype can be used to define raw data of a task. It can be used to specify access to
labels (read, write) or other runnables/functions as possible with the normal task, but not the
order of the access. These prototypes are then processed by different algorithms. The algorithms are creating the tasks, are filling, verifying or modifying the data based on their different checks. The final result of this processing are tasks, which are corresponding to the data of the prototypes.
These tasks are representing the current state and can be further processed, for example to generate code or further simulation. With the process prototypes available in the model, it is possible to define the structure of the software in an early development phase. The implementation at that moment is open and not yet completed, but the general idea can be verified.
Another issue can be the distribution to a multi-core system, coming from a single-core system. Therefore the activity graph can be analyzed and computed to get the right order and parallelization of the elements and dependencies.
The following figure shows the structure which describes Process Chains in the AMALTHEA software model. A process chain is used to group task and isrs together which are executing after each other and represent an end-to-end data processing path. The processes inside a process chain are connected via Inter Process Activations.
The following attributes are describing a process chain:
Name | Description |
---|---|
name | Name of the process chain |
processes | List of tasks and isrs which are included in the process chain |
The CustomEntity element defines a way to add not yet available elements of the software model in a generic way. The only contained attribute defines the type of the entity by setting it as a String. Additional properties can be set using the CustomAttributes.
Section (Virtual Memory Section) is used to group the memory elements (Labels, Runnables). This is achieved by associating the Section element to Label & Runnable elements
Below are properties of Section element:
With this type of information available, the complexity of mapping software components to memories can be reduced. The next picture gives an overview about the general idea of the mapping with Sections.
The purpose of following model elements is to describe a high level data flow. Parameters of runnables (or services) and specific call arguments allow to model a behavior that depends on the call tree but the detailed computation and the control flow within a runnable are not taken into account. Therefore only “potential” influences are modeled. The following picture shows this data flow with dashed lines.
The data flow is specified with “depends on” references. Elements that can specify a dependency are:
A data dependency defines the elements that can influence a value that is written or transferred. Possible origins are: