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 base data types. Therefore the element BaseTypeDefinition exists in the software part of the model. It consists of the name and number of bits to define a data type. Additional information to store is the mapping information of these data types for a target platform, represented by the DataPlatformMapping element, like AUTOSAR or any other one.
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 activated 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) 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.
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.
Instead of tasks, which are providing a context for the operating system, runnables and services are including the instructions to perform. They include an abstraction of these instructions using different algorithms, based on performance data.
The difference between runnables and functions is based on their activation and type of calling. While the initial activation of a runnable can only be performed by a task or another runnable, services can only be activated by runnables or other services.
Runnables and Services in the AMALTHEA model currently have no call parameters.
Remark: Under discussion for one of the next releases.
Based on these types of information, an additional analysis can be performed.
The next picture is showing the call graph of task, runnable and services.
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. |
| deadline | Information in Time at which the element must be finished / terminated. |
| runnableItems | List containing RunnableItem objects, representing instructions, label accesses, other Runnable accesses. The possibilities are described below. |
| tags | Can be used to annotate or group special kind of Runnables |
| activation | Although runnables in the simulation can be only activated by tasks, it is possible to specify an activation pattern for a runnable. |
| asilLevel | Possibility to specify the ASIL level (“automotive safety integrity level”). |
The RunnableItems are describing the detailed behavior of a Runnable element. This can be either an abstraction of instructions by representing the used running time or representing access to other elements like Runnables, Labels and Semaphore. An overview of the different possibilities is given in the next pictures.
A Group is used to structure the RunnableItems. The boolean attribute isOrdered indicates if the execution order of the contained elements is fixed or random.
| 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). |
| waitingBehaviour | Defines if the process is blocking the core when it waits (active) or not (passive). |
| Name | Description |
|---|---|
| ModeLabelAccess | Describes the access to an existing
ModeLabel (set as reference). The type of access is represented using the values of
LabelAccessEnum:
write represents the change of a mode label. The defined
ModeLiteral is set.
read indicates that the behavior of the runnable is influenced by the current value of the
ModeLabel.
|
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.
With the
RunnableModeSwitch it is possible to define different execution paths. They can be used like
if-else or
switch-case statements in a programming language. A
RunnableModeSwitch uses the value of a
ModeLabel (with the help of
ModeValueProvider) to decide which path has to be executed.
A
ModeSwitchEntry object is referenced to represent the different paths and each entry defines the value the mode must have to execute the path with the help of the
ModeLiteral values.
At the
RunnableModeSwitch it is also possible to define a default path, which is executed if none of the
ModeSwitchEntries fits to the current set value of the mode.
Each entry (path) of a Runnable Probability Switch 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 Probability Switch Entries in the surrounding switch.
Runnable Instructions allow to specify the default instructions and (optional) the instructions for specific core types (e.g. FPGA). These extended instructions are implemented as a map with the core type as the key.
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 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 priority for priority based scheduling algorithms or the activation represented by the Stimulus. A Task or ISR contains calls either to other Tasks or Runnables. These types of calls are included in the callGraph 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 |
| callGraph | List of task calls. 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 maximal number of existing instances from the same task, which is checked for load limitation reasons when a task is activated. For the case of an exceeded multipleTaskActivationLimit, the activation is ignored. |
The Call Graph is used to define how a Task or ISR behaves during its execution. For that it contains two different kinds of elements, Call Sequences and Switches. The following picture shows the data structure of a Call Graph:
The Call Graph contains a list of elements of type GraphEntryBase. This is the basic, abstract type for the Switch types and for the Call Sequence. With the Switches it is possible to define different execution paths. They can be used like if-else or switch-case statements in a programming language. There are two different kind of Switches, a Mode Switch and a Probability Switch. Each Switch contains a number Switch Entry objects. These are the different possible program paths that can be executed. Also like the Call Graph, the Switch Entry can contain a list of objects that can be Switches or Call Sequences.
A Mode Switch uses the value of a Mode Label to decide which entry has to be executed. Therefore a Mode Label object is referenced (via ModeValueProvider) and each entry defines the values the mode label must have to execute the path.
Each entry (path) of a Probability Switch 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 Probability Switch Entries in the surrounding switch.
A Call Sequence contains a list of elements that are executed by the Process. The following list gives a short overview over these elements:
The following picture shows the structure of a Call Graph. The graph is like a tree of Call Sequences and Switches. The Call Sequences are used to define what the task is actually executing. 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 same goes for the elements within a Call Sequence.
As already explained, the content of a
Call Sequence specifies what a process is actually doing when it is executed.
This section describes the different entry-types of a
Call Sequence.
With the Task Runnable Call the process executes a specific runnable.
Each process is controlled by at least one scheduler. A scheduler is the resource owner of one or multiple processor cores (The scheduler decides on which of its cores the process is executed). The Enforced Migration forces the process to switch to another scheduler. Therefore the Enforced Migration entry contains a reference to the new scheduler.
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 Call Graph, the Task or ISR terminates immediately. It is not required to insert this element at the end of a Call 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. To deal with OS-Events a Call Sequence can execute the elements 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.
The Mode element denotes a specific system state. It is described using the following attributes:
| Name | Description |
|---|---|
| name | Name of the mode |
| literals | Enumeration values of the mode |
Modes are used in Mode Switches inside the Call Graph of Tasks and ISRs using Mode Labels. Moreover, mode labels are used to enable and disable Stimuli.
The Mode Label element represents a value of a specific Mode. Is is 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 of the Mode |
| initialValue | Initial value of the referenced mode |
The value of the mode label can be changed from its initial value using the set-mode-labels-list of a Stimulus.
Another possibility is a write access within a Runnable via Mode Label Access.
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 call 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.
