1 Introduction to APP4MC

The goal of the project is the development of a consistent, open, expandable tool platform for embedded software engineering. It is based on the model driven approach as basic engineering methodology. The main focus is the optimization of embedded multi-core systems.

Most functions in a modern car are controlled by embedded systems. Also more and more driver assistance functions are introduced. This implies a continuous increase of computing power accompanied by the request for reduction of energy and costs. To handle these requirements the multi-core technology permeates the control units in cars. This is today one of the biggest challenges for automotive systems. Existing applications can not realize immediate benefit from these multi-core ECUs because they are not designed to run on such architectures. In addition applications and systems have to be migrated into AUTOSAR compatible architectures. Both trends imply the necessity for new development environments which cater for these requirements.

The tool platform shall be capable to support all aspects of the development cycle. This addresses predominantly the automotive domain but is also applicable to telecommunication by extensions which deal with such systems in their native environment and integrated in a car.

Future extensions will add support for visualization tools, graphical editors. But not only design aspects will be supported but also verification and validation of the systems will be taken into account and support tools for optimal multi-core real-time scheduling and validation of timing requirements will be provided. In the course of this project not all of the above aspects will be addressed in the same depth. Some will be defined and some will be implemented on a prototype basis. But the basis platform and the overall architecture will be finalized as much as possible.

The result of the project is an open tool platform in different aspects. On the one hand it is published under the Eclipse Public License (EPL) and on the other hand it is open to be integrated with existing or new tools either on a company individual basis or with commercially available tools.

2 User Guide

2.1 Introduction

APP4MC comes with a predefined perspective available in the Eclipse menu under Window -> Open Perspective -> Other -> APP4MC. This perspective consists of the following elements:

• Project Explorer
• Editor
  • Tree Editor showing the structure of the model content
  • Standard Properties Tab is used to work on elements attributes

The following screenshot is showing this perspective and its contained elements.

2.1.1 Steps to create a new AMALTHEA model

APP4MC provides a standard wizard to create a new AMALTHEA model from scratch.

Step 1: Create a new general project

The scope of an AMALTHEA model is defined by its enclosing container (project or folder).
Therefore a project is required.

Step 2: Create a new folder inside of the created project

It is recommended to create a folder ( although a project is also a possible container ).

Step 3: Create a new AMALTHEA model

In the context menu (right mouse button) an entry for a new AMALTHEA model can be found.

Another starting point is File -> New -> Other

In the dialog you can select the parent folder and the file name.

2.1.2 AMALTHEA Editor

The AMALTHEA Editor shows the entire model that contains sub models.
The next screenshot shows the "New Child" menu with all its possibilities.

The AMALTHEA Editor has additional commands available in the editor toolbar.

Show types of model elements

The Show types of elements button triggers the editor to show the direct type of the element in the tree editor using [element_type]. The following screenshot shows the toggle and the types marked with an underline.

Search for model elements

The editor provides the possibility to search for model elements by using the available name attribute. For example this can be used to find all elements in the model with "ABS" at the beginning of their name. The result are shown in the Eclipse search result view.

A double click on a result selects the element in the editor view.

An additional option is to toggle the search results to show them as a plain list instead of a tree grouped by type.

2.1.3 Handling of multiple files (folder scope)

Amalthea model

• Amalthea files have the extension ".amxmi".
• Amalthea models support references to other model files in the same folder.

When the first Amalthea file in a folder is opened in the Amalthea editor

• all valid model files are loaded
• a common editing environment is established
• files and folder are decorated with markers
  • loaded model files are decorated with a green dot
  • model files that contain older versions are extended with the version
  • the folder is marked as "is in use" and decorated with a construction barrier

When the last Amalthea editor of a folder is closed

• the common editing environment is released
• markers are removed

Warning:
Do not modify the contents of a folder while editors are open.
If you want to add or remove model files then first close all editors.

2.1.4 AMALTHEA Examples

The AMALTHEA tool platform comes with several examples. This section will describe how a new project based on these examples can be created.

Step 1

Click the "new" icon in the top left corner and select "Example..." or use the right mouse button.

Step 2

The "New Example" wizard will pop up and shows several examples.
Select one examples and hit continue.

Step 3

You will see a summary of the example projects that will be created.
Click "Finish" to exit this dialog.

You can now open the editor to inspect the models.

2.2 Concepts

2.2.1 Timing in Amalthea Primer

An Amalthea model per se is a static, structural model of a hardware/software system. The basic structural model consists of software model elements (tasks, runnables), hardware model elements (processing units, memories, connection handlers), stimuli that are used to activate execution, and mappings of software model elements to hardware model elements. Semantics of the model then allows for definite and clear interpretation of the static, structural model regarding its behavior over time.

Different Levels of Model Detail

Amalthea provides a meta-model suitable for many different purposes in the design of hardware/software systems. Consequently, there is not the level of Amalthea model detail – modeling often is purpose driven. Regarding timing analysis, we exemplary discuss three different levels of detail to clarify this aspect of Amalthea. Note that we focus on level of detail of the hardware model and assume other parts of the model (software, mapping, etc.) fixed.

Essential software model elements are runnables, tasks, and data elements (labels and channels). Runnable items of a runnable specifies its runtime behavior. You may specify the runnable items as a directed, acyclic graph (DAG). Amalthea has different categories of runnable items, we focus on the following four:

• Items that branch paths of the DAG (runnable mode switch, runnable probability switch).
• Items that signal or call other parts of the model (custom event trigger, runnable call, etc.).
• Items that specify data access of data elements (channel receive/send, label access).
• Items that specify execution time (ticks, execution needs).

Tasks may call runnables in a activity graph. Note that a runnable can be called by several tasks. We then map tasks to task schedulers in the operating system model, and we map every task scheduler to one or more processing units of the hardware model. Further, we map data elements to memories of the hardware model.

This coarse level of hardware model detail – the hardware model consists only of mapping targets, without routing or timing for data accesses – may already be sufficient for analysis focusing on event-chains or scheduling.

As the second example of model detail, we now add access elements to all processing units of the hardware model, modeling data access latencies or data rates when accessing data in memories – still ignoring routing and contention. This level of detail is sufficient, for example, for optimizing data placement in microcontrollers using static timing analysis.

A more detailed hardware model, our third and last example of model detail, will contain information about data routing and congestion handling. Therefore, we add connection handlers to the hardware model for every possible contention point, we add ports to the hardware elements, and we add connections between ports. For every access element of the processing units, we add an access path, modeling the access route over different connections and connectionHandlers. The combination of all access elements are able to represent the full address space of a processing unit. This level of detail is well suited for dynamic timing simulation considering arbitration effects for data accesses.

In the following, we discuss 'timing' of Amalthea in context of level of detail of the last example and discrete-event simulation.

Discrete-Event Simulation

For dynamic timing analysis, the initial state of the static system model is the starting point, and a series of state changes is subject to model analysis. The state of a model mainly consist of states of HW elements (processing units and connection handlers). During analysis, a state change is then, for example, a processing unit changing from idle to execute.

When we are interested in the timing of a model, a common way is using discrete-event simulation. In discrete-event simulation, a series of events changes the state of the system and a simulated clock. Such a simulation event is, for instance, a stimuli event for a task to execute on a processing unit, what in turn may change the state of this processing unit from idle to execute.

Note that every event occurs at a specified point in simulated time; for instance, think of a new stimuli event that shall activate a task in 10ms from the current value of the simulated clock. Unprocessed (future) events are stored in an event list. The simulator then continuously processes the event occurring next to the current simulated time, and forwards the simulated clock correspondingly, thereby removing the event from the event list. Note that this is a very simplified description. For instance, multiple events at the same point in simulated time are possible. Processing events may lead to generation of new events. For instance, processing an end task execution event may lead to a new stimuli event that shall occur 5ms from the current value of the simulation clock added to the event list.

After sketching the basic idea of discrete-event simulation, we can be more precise with the term Amalthea timing: we call the trace of state changes and events over time the dynamic behavior or simply the timing of the Amalthea model. This timing of the model than may be further analyzed, for instance, regarding timing constraints.

Stimulation of task execution with corresponding stimuli events, and scheduling in general, is not further discussed here. In the following, we focus on timing of execution at processing units and data accesses.

Execution Time

The basic mechanism to specify execution time at a processing unit is the modeling element ticks. Ticks are a generic abstraction of time for software, independent of hardware. Regarding hardware, one may think of ticks as clock ticks or cycles of a processing unit. You can specify ticks at several places in the model, most prominently as a runnable item of a runnable. The ticks value together with a mapping to a specific processing unit that has a defined frequency then allows computation of an execution time. For instance, 100 ticks require 62.5ns simulated time at a processing unit with 1.6GHz, while 100 ticks require 41.6ns at a processing unit with 2.4GHz.

When the discrete-event simulator simulates execution of a runnable at a processing unit, it actually processes runnable items and translates their semantics into simulation events. We already discussed the runnable item ticks: when ticks are processed, we compute a corresponding simulation time value based on the executing processing unit's frequency, and store a simulation event in the list of simulation events for when the execution will finish.

In that sense, ticks translate into a fixed or static timing behavior - when execution starts, it is always clear when this execution will end. Note that the current version of Amalthea (0.9.3) also prepares an additional concept for specification of execution timing besides using ticks: execution needs. Execution needs will allow sophisticated ways of execution time specification, as required for heterogeneous systems. Execution needs define the number of usages of user-defined needs; a later version of Amalthea (> 0.9.3) then will introduce recipes that translate such execution needs into ticks, taking hardware features of the executing processing unit into account. Note that, by definition, a sound model for timing simulation always allows to compute ticks from execution needs. Consequently, for timing analysis using discrete-event simulation as described above, we first translate execution needs into ticks, resulting in a model we call ticks-only model. Thus, we can ignore execution needs for timing analysis.

Data Accesses

For data accesses, in contrast to ticks, the duration in simulation time is not always clear. A single data access may result in series of simulation events. Occurrence of these events in simulation time depends on several other model elements, for example, access paths, mapping of data to memory, and state of connection handlers. Thus, a data access may result in dynamic timing behavior. Note that there are plenty of options in Amalthea for hardware modeling; consequently, options for modeling and simulation of data accesses are manifold (see above Different Levels of Model Detail). In the following, we discuss some modeling patterns for data accesses.

Consider a hardware model consisting of two processing units, a connection handler, and a single memory. We add a read and a write latency to all connections and the connection handler. Additionally, we add an access latency to the memory. There are no read or write latency added to access elements of the processing units. Only access paths specify the routes from the specific processing unit to the memory across the connection handler, see the following screenshot.

As described in the beginning of this section, a single data access may result in a series of events. Expected simulation behavior is as follows: When the discrete-event simulator encounters a runnable item for a data read access at CPU0, we add an event for one tick later to the event queue of the simulator, denoting passing the connection from CPU0 to the connection handler MyConnectionHandler. (For simplicity, we do not use time durations calculated from the CPU0's frequency here, what would be required to determine the correct point in simulated time for the event). After passing the connection, the state of MyConnectionHandler is relevant for the next event: Either MyConnectionHandler is occupied by a data access (from CPU1), a data access arrives at the same time, or MyConnectionHandler is available.

• If MyConnectionHandler is available, we add an event for three ticks later-this is the read latency of the connection handler.

• If a data access from CPU1 arrives at the same time, the connection handler handles this data access based on the selected arbitration mechanism (attribute not shown in the screen shot – we assume priority based with a higher priority for CPU1). We add an event for three ticks later, when MyConnectionHandler is available again. We then check again for data accesses from CPU1 at the same time and set a corresponding event.

• If MyConnectionHandler is occupied, we add an event for whenever the connection handler is not occupied anymore. We then check for data accesses from CPU1 at the same time and set a corresponding event.

Eventually, MyConnectionHandler may handle the read access from CPU0, and when the simulator reacts on the corresponding event, we add an event for one tick later, as this is the read latency for the connection between the connection handler and the memory. The final event for this read data access from CPU0 results from the access latency of the memory (twelve ticks). When the simulator reacts on that final event, the read access from CPU0 is completed and the simulator can handle the next runnable item at CPU0, if available.

Note that in the above example there is only one contention point. We thus could reduce the number of events for an optimized simulation. Further, note that we ignore size of data elements in this example. We could use data rates instead of latencies at connections, the connection handler, and the memory to respect data sizes in timing simulation or work with the bit width of ports. Furthermore beside constant latency values it is also possible to use distributions, in this case the simulator role the dice regarding the distribution. At a last note, adding to the discussion of different detail levels: Depending on use-case, modeling purpose, and timing analysis tool, there may be best practice defined for modeling. For instance, one tool may rely on data rates, while other tools require latencies but only at memories and connection handlers, not connections. Tool specific model transformations and validation rules should handle and define such restrictions.

2.2.2 Hardware

Structural Modeling of Heterogeneous Platforms

To master the rising demands of performance and power efficiency, hardware becomes more and more diverse with a wide spectrum of different cores and hardware accelerators. On the computation front, there is an emergence of specialized processing units that are designed to boost a specific kind of algorithm, like a cryptographic algorithm, or a specific math operation like "multiply and accumulate". As one result, the benefit of a given function from hardware units specialized in different kinds may lead to nonlinear effects between processing units in terms of execution performance of the algorithm: while one function may be processed twice as fast when changing the processing unit, another function may have no benefit at all from the same change. Furthermore the memory hierarchy in modern embedded microprocessor architectures becomes more complex due to multiple levels of caches, cache coherency support, and the extended use of DRAM. In addition to crossbars, modern SoCs connect different clusters of potentially different hardware components via a Network on Chip. Additionally, power and frequency scaling is supported by state of the art SoCs. All these characteristics of modern and performant SoCs (specialized processing units, complex memory hierarchy, network like interconnects and power and frequency scaling) were only partially supported by the former Amalthea hardware model. Therefore, to create models of modern heterogeneous systems, new concepts of representing hardware components in a flexible and easy way are necessary: Our approach supports modeling of manifold hierarchical structures and also domains for power and frequencies. Furthermore, explicit cache modules are available and the possibilities for modeling the whole memory subsystem are extended, the connection between hardware components can be modeled over different abstraction layers. Only with such an extended modeling approach, a more accurate estimation of the system performance of state of the art SoCs becomes feasible.

Our intention is allowing to create a hardware model once at the beginning of a development process. Ideally, the hardware model will be provided by the vendor. All performance relevant attributes regarding the different features of hardware components like a floating point unit or how hardware components are interconnected should be explicitly represented in the model. The main challenge for a hardware/software performance model is then to determine certain costs, e.g. the net execution time of a software functionality mapped to a processing unit. Costs such as execution time, in contrast to the hardware structure, may change during development time – either because the implementation details evolve from initial guess to real-world measurements, the implementation is changed, or the tooling is changed. Therefore, the inherent attributes of the hardware, e.g. latency of an access path, should be decoupled from the mapping or implementation dependent costs of executing functions. We know from experience that it is necessary to refine these costs constantly in the development process to increase accuracy of performance estimation. Refinement denotes incorporation of increasing knowledge about the system. Therefore, such a refinement should be possible in an efficient way and also support re-use of the hardware model. The corresponding concepts are detailed in the following section.

Recipe and Feature concept: An outlook of an upcoming approach

Disclaimer: Please note that the following describes work in progress – what we call "recipes" later is not yet part of the meta-model, and the concept of "features" is not final.

The main driver of the concept described here is separation of implementation dependent details from structural or somehow "solid" information about a hardware/software system. This follows the separation of concerns paradigm, mainly to reduce refinement effort, and foster model re-use: As knowledge about a system grows during development, e.g. by implementing or optimizing functionality as software, the system model should be updated and refined efficiently, while inherent details shall be kept constant and not modified depending on the implementation.

An example should clarify this approach: For timing simulation, we require the net execution time of a software function executed on the processing unit it is mapped onto. This cost of the execution depends on the implementation of the algorithm, for instance, as C++ code, and the tool chain producing the binary code that eventually is executed. In that sense, the execution needs of the algorithm (for instance, a certain number of "multiply and accumulate" operations for a matrix operation) are naturally fixed, as well as the features provided by the processing unit (for instance, a dedicated MAC unit requiring one tick for one operation, and a generic integer unit requiring 0.5 ticks per operation). However is implementation- and tool-chain-dependent how the actual execution needs of the algorithm are served by the execution units. Without changing the algorithm or the hardware, optimization of the implementation may make better use of the hardware, resulting in reduced execution time. The above naturally draws the lines for our modeling approach: Execution needs (on an algorithmic level) are inherent, as well as features of the hardware. Keeping these information constant in the model is the key for re-use; implementation dependent change of costs, such as lower execution time by an optimized implementation in C++ or better compiler options, change during development and are modeled as recipe. A "recipe" thus takes execution needs of software and features of the hardware as input and results in costs, such as the net execution time. Consequently, recipes are the main area of model refinement during development. The concept is illustrated below.

Note that flexibility is part of the design of this approach. Execution needs and features are not limited to a given set, and recipes can be almost arbitrary prescripts of computation. This allows to introduce new execution needs when required to favorable detail an algorithm. For instance, the execution need "convolution-VGG16" can be introduced to model a specific need for a deep learning algorithm. The feature "MAC" of the executing processing unit provides costs in ticks corresponding to perform a MAC operation. The recipe valid for the mapping then uses these two attributes to compute the net execution time of "convolution-VGG16" in ticks, for instance, by multiplying the costs of xyz MAC operations with a penalty factor of 0.8. Note that with this approach execution needs may be translated very differently into costs, using different features.

To further motivate this approach, we give some more benefits and examples of beneficial use of the model:

• Given execution needs of a software function that directly correspond the features of processing units, the optimal execution time may be computed (peak performance).
• While net execution time is the prime example of execution needs, features, and recipes, the concept is not limited to "net execution time recipes", recipes for other performance numbers such as power consumption are possible.
• Recipes can be attached at different "levels" in the model: At a processing unit and at a mapping. If present, the recipe at mapping level has precedence.

General Hardware Model Overview

The design of the new hardware model is focusing on flexibility and variety to cover different kind of designs to cope with future extensions, and also to support different levels of abstraction. To reduce the complexity of the meta model for representing modern hardware architectures, as less elements as possible are introduced. For example, dependent of the abstraction level, a component called ConnectionHandler can express different kind of connection elements, e.g. a crossbar within a SoC or a CAN bus within an E/E-architecture. A simplified overview of the meta model to specify hardware as a model is shown below. The components ConnectionHandler, ProcessingUnit, Memory and Cache are referred in the following as basic components.

Class diagram of the hardware model

The root element of a hardware model is always the HwModel class that contains all domains (power and frequency), definitions, and hardware features of the different component definitions. The hierarchy within the model is represented by the HwStructure class, with the ability to contain further HwStructure elements. Therewith arbitrary levels of hierarchy could be expressed. Red and blue classes in the figure are the definitions and the main components of a system like a memory or a core.

The next figure shows the modeling of a processor. The ProcessingUnitDefiniton, which is created once, specifies a processing unit with general information (which can be a CPU, GPU, DSP or any kind of hardware accelerator). Using a definition that may be re-used supports quick modeling for multiple homogeneous components within a heterogeneous architecture. ProcessingUnits then represent the physical instances in the hardware model, referencing the ProcessingUnitDefiniton for generic information, supplemented only with instance specific information like the FrequencyDomain.

Link between definitions and module instances (physical components)

Yellow represents the power and frequency domains that are always created at the top level of the hardware model. It is possible to model different frequency or voltage values, e.g., when it is possible to set a systems into a power safe mode. All components that reference the domain are then supplied with the corresponding value of the domain.

All the green elements in the figure are related to communication (together with the blue base component ConnectionHandler). Green modeling elements represent ports, static connections, and the access elements for the ProcessingUnits. These ProcessingUnits are the master modules in the hardware model. The following example shows two ProcessingUnits that are connected via a ConnectionHandler to a Memory. There are two different possibilities to specify the access paths for ProcessingUnits like it is shown for ProcessingUnit_2 in the next figure. Every time a HwAccessElement is necessary to assign the destination e.g. a Memory component. This HwAccessElement can contain a latency or a data rate dependent on the use case. The second possibility is to create a HwAccessPath within the HwAccessElement which describes the detailed path to the destination by referencing all the HwConnections and ConnectionHandlers. It is even possible to reference a cache component within the HwAccessPath to express if the access is cached or non-cached. Furthermore it is possible to set addresses for these HwAccessPath to represent the whole address space of a ProcessingUnit. A typical approach would be starting with just latency or data rates for the communication between components and enhance the model over time to by switching to the HwAccessPaths.

Access elements in the hardware model

Current implementation with features and the connection to the SW Model

In the previous chapter the long time goal of the feature and recipe concept is explained. As an intermediate step before introducing the recipes we decided to connect the HwModel and SwModel by referencing to the name of the hardware FeatureCategories from the ExecutionNeed element in a Runnable. The following figure shows this connection between the grey Runnable item block and the white Features block. Due to the mapping (Task or Runnable to ProcessingUnit) the corresponding feature value can be extracted out of the ProcessingUnitDefinition.

An example based on the old hardware model is the "instruction per cycle" value (IPC). To model an IPC with the new approach a HwFeatureCategory is created with the name Instructions. Inside this category multiple IPC values can be created for different ProcessingUnitDefinitions.

Note: In version 0.9.0 to 0.9.2 exists a default ExecutionNeed Instructions together with a the HwFeatre IPC the cycles can be calculated by dividing the Instructions by the IPC value.

Execution needs example

Interpretation of latencies in the model

In the model read and write access latencies are used. An alternative which is usually used in specifications or by measurements are request and response latencies. The following figure shows a typical communication between two components. The interpretation of a read and write latency for example at ConnectionHandlers is the following:

• readLatency = requestLatency + response Latency

• writeLatency = requestLatency

The access latency of a Memory component is always added to the read or write latency from the communication elements, independent if its one latency from an HwAccessElement or multiple latencies from a HwAccessPath.

As example in case of using only read and write latencies:

• totalReadLatency = readLatency (HwAccessElement) + accessLatency (Memory)

• totalWriteLatency = writeLatency (HwAccessElement) + accessLatency (Memory)

An example in case of using an access element with a hardware access path:

n = Number of path elements

• totalReadLatency = Sum 1..n ( readLatency(p) ) + accessLatency (Memory)

• totalWriteLatency = Sum 1..n ( writeLatency(p) ) + accessLatency (Memory)

PathElements could be Caches, ConnectionHandlers and HwConnections. In very special cases also a ProcessingUnit can be a PathElement the ProcessingUnit has no direct effect on the latency. In case the user want to express a latency it has to be annotated as HwFeature.

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

2.2.4 Software (runtime)

During runtime, the dynamic behavior of the software can be observed. The following Gantt chart shows an excerpt of such a dynamic behavior.

To model the observed behavior in the AMALTHEA model there are schedulable units (Processes) that contain the basic software units (Runnables) and stimuli that describe when the processes are executed. Statistical elements like distributions (Gauss, Weibull, ...) are also available in the model. They allow describing the variation of values if there are multiple occurrences.

In the following sections, a high level description of the individual elements of a software description that define the dynamic behavior are presented.

Processes (Tasks or ISRs)

Processes represent executable units that are managed by an operating system scheduler. A process is thus the smallest schedulable unit managed by the operating system. Each process also has its own name space and resources (including memory) protected against use from other processes. In general, two different kinds of processes can be distinguished: task and Interrupt Service Routine (ISR). Latter is a software routine called in case of an interrupt. ISRs have normally higher priority than tasks and can only be suspended by another ISR which presents a higher priority than the one running. In the Gantt chart above, a task called 'TASK_InputProcessing' can be seen. All elements that run within the context of a process are described in the following sections.

Runnables

Runnables are basic software units. In general it can be said that a Runnable is comparable to a function. It runs within the context of a process and is described by a sequence of instructions. Those instructions can again represent different actions that define the dynamic behavior of the software. Following, such possible actions are listed:

• Semaphore Access: request/release of a semaphore
• Label Access: reading/writing a data signal
• Ticks: number of ticks (cycles) to be executed
• ...

In the following sections elements, that can be of concern within a runnable, are described in more detail.

Labels

Labels represent the system's view of data exchange. As a consequence, labels are used to represent communication in a flattened structure, with (at least) one label defined for each data element sent or received by a Runnable instance.

Semaphore

The main functionality of a semaphore is to control simultaneous use of a single resource by several entities, e.g. scheduling of requests, multiple access protection.

Stimulation

Before, we described the dynamic behavior of a specific process instance. In general however, a process is not only activated once but many times. The action of activating a process is called stimulation. The following stimulation patterns are typically used for specification:

• Single: single activation of a process
• Periodic: periodic activation of a process with a specific frequency
• VariableRate: periodic activations based on other events, like rotation speed
• Event: activation triggered by a TriggerEvent
• InterProcess: activations based on an explicit inter-process trigger

2.2.5 General Concepts

Grouping of elements (Tags, Tag groups)

It is possible to use Tags for grouping elements of the model.

Custom Properties

The AMALTHEA model provides Custom Properties to enhance the model in a generic way. These can be used for different kind of purpose:

• Store attributes, which are relevant for your model, but not yet available at the elements
• Processing information of algorithms can be stored in that way, e.g. to mark an element as already processed

Support of Packages

In Amalthea model (from APP4MC 0.9.7 version) there is a feature to support grouping of following model elements listed below in a package:

• Component
• Composite
• MainInterface

Above mentioned classes are implementing interface IComponentStructureMember

ComponentStructure element in Amalthea model represents a package, and this can be referred by above mentioned elements.

Example of using Package

Amalthea model contains a parent ComponentStructure "BC" and two child ComponentStructure's "FC1", "FC2".

• Component element "Comp3" is associated to ComponentStructure "FC1" and the Component element "Comp4" is associated to ComponentStructure "FC2"

This representation demonstrates the grouping of the elements into different packages.

Support of Namespaces

In Amalthea model (from APP4MC 0.9.7 version) there is a feature to have Namespace for the following model elements ( which are implementing interface INamespaceMember ):

• BaseTypeDefinition
• Channel
• Component
• Composite
• DataTypeDefinition
• Label
• MainInterface
• Runnable
• TypeDefinition

Advantage of having Namespace is, there can be multiple elements defined with the same name but with different Namespace (this feature will also be helpful to support c++ source code generation ). If Namspace is specified in Amalthea model for a specific model element, then its unique name is built by considering the "Namespace text + name of the element"

Example of using Namespace

As shown in the below screenshot, there are two Component elements with the name "Comp1" but referring to different Namespace objects, which is making them unique. In this case, display in the UI editor is also updated by showing the Namespace in the prefix for the Amalthea element name.

Below is the text representation of the Amalthea model which shows the ComponentInstance elements referring to different Component elements. As mentioned above, highlighted text shows that unique name of the Component element __ is used all the places where it is referenced __(to make it unique)

Additional Information:

• As soon as Namespace elements are used in Amalthea model, AMXMI file is updated with additional attribute xmi:id for all elements implementing IReferable interface.
• On Amalthea model element implementing INamed interface, in addition to getName() API, getQualifiedName() API is available which returns <namespace string value>.getName()

2.2.6 Scheduling

Scheduler to Core assignment

We distinguish between physical mapping and responsibility

• Executing Core means a scheduler produces algorithmic overhead on a core
• Responsibility means a scheduler controls the scheduling on core(s)

Task to Scheduler assignment

Tasks have a core affinity and are assigned to a scheduler

• Core Affinity Specifies the possible cores the task can run on. If only one core is specified, the task runs on this core. If multiple cores are specified, the task can migrate between the cores.
• Scheduler specifies the unique allocation of the task to a scheduler.

The scheduling parameters are determined by the scheduling algorithm and are only valid for this specific task – scheduler combination. Therefore the parameters are specified in the TaskAllocation object.

Scheduler hierarchies

Schedulers can be arranged in a hierarchy via SchedulerAssociations. If set, the parent scheduler takes the initial decision and delegates to a child-scheduler. If the child-scheduler is a reservation based server, it can only delegate scheduling decisions to its child scheduler. If it is not a server, it can take scheduling decisions.
The scheduling parameters for the parent scheduler are specified in the SchedulerAssociation, just as it would have for task allocations.
If a reservation based server has only one child (this can either be a process or a child scheduler), the scheduling parameters specified in this single child allocation will also be passed to the parent scheduler. The example below shows this for the EDF scheduler on the right hand side.

2.2.7 Communication via channels

Channel

Sender and receiver communicating via a channel by issuing send and receive operations; read policy and transmission policy define communication details.

A channel is specified by three attributes:

• elementType: the type that is sent to or read from the channel.
• defaultElements: number of elements initially in the channel (at start-up).
• maxElements (integer) denoting a buffer limit, that is, the channel depth. In other words, no more than maxElements elements of the given element type may be stored in the channel.

Channel Access

In the basic thinking model, all elements are stored as a sequential collection in the channel.

Sending

A runnable may send elements to a channel by issuing send operations.
The send operation has a single parameter:

• elements (integer): Number of elements that are written.

Receiving

A runnable may receive elements from a channel by issuing receive operations.
The receive operation is specified with a receive policy that defines the main behaviour of the operation:

• LIFO (last-in, first-out) is chosen if processing the last written elements is the primary focus and thereby missing elements is tolerable.
• FIFO (first-in, first-out) is chosen if every written element needs to be handled, that is, loss of elements is not tolerable.
• Read will received elements without modifying the channel
• Take will remove the received elements from the channel

The receive policy defines the direction a receive operation takes effect with LIFO accesses are from top of the sequential collection, while with FIFO accesses are from bottom of the sequential collection-and they define if the receive operation is destructive (take) or non-destructive) read.

Each operation further has two parameters and two attributes specifying the exact behavior. The two parameters are:

• elements (integer): Maximum number n of elements that are received.
• elementIndex (integer): Position (index i) in channel at which the operation is effective. Zero is the default and denotes the oldest (FIFO) or newest element (LIFO) in the channel.

In the following several examples are shown, of how to read or take elements out of a channel with the introduced parameters.

Two attributes further detail the receive operation:

• lowerBound (integer): Specify the minimum number of elements returned by the operation. The value must be in the range [0,n], with n is the value of the parameter elements. Default value is n.
• dataMustBeNew (Boolean): Specify if the operation must only return elements that are not previously read by this Runnable. Default value is false.

Transmission Policy

To further specify how elements are accessed by a runnable in terms of computing time, an optional transmission policy may specify details for each receive and send operation. The intention of the transmission policy is to reflect computing demand (time) depending on data.

The transmission policy consists of the following attributes:

• chunkSize: Size of a part of an element, maximum is the element size.
• chunkProcessingTicks (integer): Number of ticks that will be executed to process one chunk (algorithmic overhead).
• transmitRatio (float): Specify the ratio of each element that is actually transmitted by the runnable in percent. Value must be between [0, 1], default value is 1.0.

Example for using transmission policy to detail the receiving phase of a runnable execution. Two elements are received, leading to transmission time as given in the formula. After the receiving phase, the runnable starts with the computing phase.

2.2.8 Data Dependencies

Overview

It is possible to specify potential data dependencies for written data. More specifically, it is now possible to annotate at write accesses what other data potentially have influenced the written data. A typical "influence" would be usage of data for computing a written value. As such data often comes from parameters when calling a runnable, it is now also possible to specify runnable parameters in Amalthea and their potential influence on written data.

Semantics of the new attributes in Amalthea is described in detail below. In general, these data dependency extensions are considered as a way to explicitly model details that help for visualization or expert reviews. For use cases such as timing simulation the data dependency extensions are of no importance and should be ignored.

Internal Dataflow

In Embedded Systems, external dataflow is specified with reads and writes to labels, which are visible globally. This is sufficient for describing the inter-runnable communication and other use-cases like memory optimization. Nevertheless, for description of signal flows along an event chain, it is also necessary to specify the internal dataflow so that the connection between the read labels and the written labels in made.
Internal dataflow is specified as dependency of label writes to other labels, parameters of the runnable or event return values of called runnables. With this information, the connection of reads to writes of label can be drawn.

The internal dependencies are typically generated through source code analysis. The analysis parses the code and determines all writes to labels. For each of those positions, a backward slicing is made on the abstract syntax tree to derive all reads that influence this write. This collection is then stored as dependency at the write access.
Based upon this data a developer can now track a signal flow along from the sensor over several other runnables to the actuator. Existing event-chains can be automatically validated to contain a valid flow by checking if the segments containing a read label event and write label event within the same runnable are connected by an internal dependency. Without internal dependencies, this would introduce a huge manual effort. Afterwards the event-chains can be simulated and their end-to-end latencies determined with the usual tools.

2.2.9 Memory Sections

Purpose

Memory Sections are used for the division of the memory (RAM/ROM) into different blocks and allocate the "software" memory elements ( e.g. Labels), code accordingly inside them.
Each Memory Section has certain specific properties ( e.g. faster access of the elements, storing constant values). By default compiler vendors provide certain Memory Sections ( e.g. .data, .text) and additional Memory Sections can be created based on the project need by enhancing the linker configuration.

Definition

A "Memory Section" is a region in memory (RAM/ROM) and is addressed with a specific name. There can exist multiple "Memory Sections" inside the same Memory (RAM/ROM) but with different names. Memory Section names should be unique across the Memory (RAM/ROM).

Memory Sections can be of two types:

• Virtual Memory Section
• Physical Memory Section

Virtual Memory Section

"Virtual Memory Sections" are defined as a part of data specification and are associated to the corresponding Memory Elements (e.g. Label's) during the development phase of the software. Intention behind associating "Virtual Memory Sections" to Memory elements like Label's is to control their allocation in specific Memory (e.g. Ram1 or Ram2) by linker.

As a part of linker configuration – It is possible to specify if a "Virtual Memory Section" (e.g. mem.Sec1) can be part of certain Memory (e.g. Ram1/Ram2/SYSRAM but not Ram3).

Example:

Software should be built for ManyCore ECU – containing 3 Cores (Core1, Core2, Core3). Following RAMs are associated to the Cores: Ram1 – Core1, Ram2 – Core2, Ram3 – Core3, and also there is SYSRAM.

Virtual Memory Section : mem.sec1 (is defined as part of data specification) is associated to Label1 and Label2.

In Linker configuration it is specified that mem.sec1 can be allocated only in Ram1 or Ram2.

Below diagram represents the linker configuration content - w.r.t. possibility for physical allocation of mem.sec1 in various memories .

Based on the above configuration – Linker will allocate Label1, Label2 either in Ram1/Ram2/SYSRAM but not in Ram3/Ram4.

Physical Memory Section

"Physical Memory Sections" are generated by linker. The linker allocates various memory elements (e.g. Label's) inside "Physical Memory Sections".

Each "Physical Memory Section" has following properties:

• Name – It will be unique across each Memory
• Start and End address – This represents the size of "Physical Memory Section"
• Associated Physical Memory (e.g. Ram1 or Ram2)

Example: There can exist mem.sec1.py inside Ram1 and also in Ram2. But these are physically two different elements as they are associated to different memories (Ram1 and Ram2) and also they have different "start and end address".

Below diagram represents the information w.r.t. virtual memory sections (defined in data specification and associated to memory elements) and physical memory sections (generated after linker run).

Modeling Memory Section information in AMALTHEA

• As described in the above concept section:
  • Virtual memory sections are used:
    • To specify constraints for creation of Physical memory sections by linker
    • To control allocation of data elements (e.g. Labels) in a specific memory (e.g. Ram1/Ram2/SYSRAM)
  • Physical memory sections are containing the data elements after linker run (representing the software to be flashed into ECU)

Below figure represents the modeling of "Memory Section" (both virtual and physical) information in AMALTHEA model:

Below are equivalent elements of AMALTHEA model used for modeling the Memory Section information:

• Section
  • This element is equivalent to Virtual Memory Section defined during the SW development phase.
  • As a part of data specification defined in the sw-development phase, a Section object (with specific name) is associated to Label and Runnable elements.

• PhysicalSectionConstraint
  • This element is equivalent to the constraint specified in the linker configuration file, which is used to instruct linker for the allocation of Physical Memory Sections in specified Memories.
  • PhysicalSectionContraint is used to specify the combination of Virtual Memory Section and Memories (which can be considered by linker for generation of Physical Memory Sections).

Example: PhysicalSectionConstraint-1 is specifying following relation "Section-1" <--> "Memory-1", "Memory-2". This means that the corresponding Physical Memory Section for "Section-1" can be generated by linker in "Memory-1" or in "Memory-2" or in both.

• PhysicalSectionMapping
  • This element is equivalent to Physical Memory Section generated during the linker run.
    • Each PhysicalSectionMapping element:
      • Contains the Virtual Memory Section (e.g. Section-1) which is the source.
      • is associated to a specific Memory and it contains the start and end memory address (difference of start and end address represents the size of Physical Memory Section).
      • contains the data elements (i.e. Labels, Runnables part of the final software).

Note: There is also a possibility to associate multiple Virtual Memory Section's as linker has a concept of grouping Virtual Memory Sections while generation of Physical Memory Section.

Example: For the same Virtual Memory Section (e.g. Section-1), linker can generate multiple Physical Memory Sections in different Memories (e.g. PhysicalSectionMapping-1, PhysicalSectionMapping-2). Each PhysicalSectionMapping element is an individual entity as it has a separate start and end memory address.

2.3 Examples

2.3.1 Modeling Example 1

General information

Modeling Example 1 describes a simple system consisting of 4 Tasks, which is running on a dual core processor.
The following figure shows the execution footprint in a Gantt chart:

In the following sections, the individual parts of the AMALTHEA model for Modeling Example 1 are presented followed by a short description of its elements.

Hardware Model

The hardware model of Modeling Example 1 consists as already mentioned of a dual core processor.
The following gives a structural overview on the modeled elements.
There, the two cores, 'Core_1' and 'Core_2', have a static processing frequency of 100 MHz each, which is specified by the corresponding quartz oscillator 'Quartz'.

Operating System Model

The operating system (OS) model defines in case of Modeling Example 1 only the needed Scheduler.
Since a dual core processor has to be managed, two schedulers are modeled correspondingly.
In addition to the scheduler definition used by the scheduler, in this case OSEK, a delay of 100 ticks is set, which represents the presumed time the scheduler needs for context switches.

Mapping Model

The mapping model defines allocations between different model parts.
On the one hand, this is the allocation of processes to a scheduler. In case of Example 1, 'Task_1' and 'Task_2' are managed by 'Scheduler_1', while the other tasks are managed by 'Scheduler_2'. Scheduler specific parameters are set here, too. For the OSEK scheduler these are 'priority' and 'taskGroup'. Each task has a priority assigned according its deadline, meaning the one with the shortest deadline, 'Task_1', has the highest priority, and so on.
On the other hand the allocation of cores to a scheduler is set. For Modeling Example 1 two local schedulers were modeled. As a consequence, each scheduler manages one of the processing cores.
A comprehension of the modeled properties can be found in the following tables:

Executable Allocation with Scheduling Parameters

Core Allocation

Software Model

Tasks

As already mentioned above, the software model of Modeling Example 1 consists exactly of four tasks, named 'Task_1' to 'Task_4'. Each task is preemptive and also calls a definitive number of Runnables in a sequential order.
A comprehension of the modeled properties can be found in the following table:

*MTA = Multiple Task Activation Limit

Runnables

In addition to the task, the software model also contains a definition of Runnables.
For Modeling Example 1, ten individual Runnables are defined.
The only function of those in this example is to consume processing resources.
Therefore, for each Runnable a constant number of instruction cycles is stated.
A comprehension of the modeled properties can be found in the following table:

Stimuli Model

The stimulation model defines the activations of tasks.
Since the four tasks of Modeling Example 1 are activated periodically, four stimuli according their recurrence are modeled.
A comprehension of the modeled properties can be found in the following table:

2.3.2 Modeling Example 2

General information

Modeling Example 2 describes a simple system consisting of 4 Tasks, which is running on a single core processor.
The following figure shows the execution footprint in a Gantt chart:

In the following sections, the individual parts of the AMALTHEA model for Modeling Example 2 are presented followed by a short description of its elements.

Hardware Model

The hardware model of Modeling Example 2 consists as already mentioned of a single core processor.
The following gives a structural overview on the modeled elements.
There, the core, 'Core_1' , has a static processing frequency of 600 MHz each, which is specified by the corresponding quartz oscillator 'Quartz_1'.

Operating System Model

The operating system (OS) model defines in case of Modeling Example 2 only the needed Scheduler.
Since only a single core has to be managed, a single scheduler is modeled correspondingly.
In addition to the scheduler definition used by the scheduler, in this case OSEK, a delay of 100 ticks is set, which represents the presumed time the scheduler needs for context switches.

Mapping Model

The mapping model defines allocations between different model parts.
On the one hand, this is the allocation of processes to a scheduler. Since there is only one scheduler available in the system, all four tasks are mapped to 'Scheduler_1'. Scheduler specific parameters are set here, too. For the OSEK scheduler these are 'priority' and 'taskGroup'. All tasks have assigned the same priority (10) to get a cooperative scheduling.
On the other hand the allocation of cores to a scheduler is set. As a consequence, the scheduler manages the only available processing core.
A comprehension of the modeled properties can be found in the following tables:

Executable Allocation with Scheduling Parameters

Core Allocation

Software Model

Tasks

As already mentioned above, the software model of Modeling Example 2 consists exactly of four tasks, named 'Task_1' to 'Task_4'. 'Task_2' to'Task_4' call a definitive number of Runnables in a sequential order. 'Task_1' instead contains a call graph that models two different possible execution sequences. In 70% of the cases the sequence 'Runnable_1_1', 'Runnable_1_2', 'Task_2', 'Runnable_1_4' is called, while in the remaining 30% the sequence 'Runnable_1_1', 'Runnable_1_3', 'Task_3', 'Runnable_1_4' is called. As it can be seen, the call graph of 'Task_1' contains also interprocess activations, which activate other tasks.
A comprehension of the modeled properties can be found in the following table:

*MTA = Multiple Task Activation Limit

Runnables

In addition to the task, the software model also contains a definition of Runnables.
For Modeling Example 2, seven individual Runnables are defined.
The only function of those in this example is to consume processing resources.
Therefore, for each Runnable a number of instruction cycles is stated.
The number of instruction cycles is thereby either constant or defined by a statistical distribution.
A comprehension of the modeled properties can be found in the following table:

Stimulation Model

The stimulation model defines the activations of tasks.
'Task_1' is activated periodically by 'Stimulus_Task_1'
'Stimulus_Task_2' and 'Stimulus_Task_3' represent the inter-process activations for the corresponding tasks.
'Task_4' finally is activated sporadically following a Gauss distribution.
A comprehension of the modeled properties can be found in the following table:

2.3.3 Modeling Example "Purely Periodic without Communication"

This system architecture pattern consists of a task set, where each task is activated periodically and no data accesses are performed. The execution time for each task is determined by the called runnable entities as specified in the table below. All tasks contain just one runnable except of T₇, which calls at first R_7,1 and after that R_7,2.

The table below gives a detailed specification of the tasks and their parameters. The tasks are scheduled according fixed-priority, preemptive scheduling and if not indicated otherwise, all events are active in order to get a detailed insight into the system's behavior.

In order to show the impact of changes to the model, the following consecutive variations are made to the model:

1) Initial Task Set

For this variation, the Tasks T₄, T₅, T₆, and T₇ of the table above are active.

2) Increase of Task Set Size I

For this variation, the Tasks T₃, T₄, T₅, T₆, and T₇ are active. That way the utilization of the system is increased.

3) Increase of Task Set Size II

For this variation, the Tasks T₁, T₃, T₄, T₅, T₆, and T₇ are active. That way the utilization of the system is increased.

4) Increase of Task Set Size III

As from this variation on, all tasks (T₁ - T₇) are active. That way the utilization of the system is increased.

5) Accuracy in Logging

For this variation, just task events are active. That way, only a limited insight into the system's runtime behavior is available.

6) Schedule

As from this variation on, T₇ is set to non-preemptive. That way, the timing behavior is changed, which results in extinct activations (see red mark in the figure below).

7) Activation

As from this variation on, the maximum number of queued activation requests for all tasks is set to 2. That way, the problem with extinct activations resulting from the previous variation is solved.

8) Schedule Point

For this variation, a schedule point is added to T₇ between the calls of R_7,1 and R_7,2. That way, the timing behavior is changed in particular.

9) Scheduling Algorithm

For this variation, the scheduling algorithm is set to Earliest Deadline First. That way, the timing behavior is changed completely.

2.3.4 Modeling Example "Client-Server without Reply"

This system architecture pattern extends the modeling example "Purely Periodic without Communication" by adding an one-way communication between tasks. It consists of two tasks T₁, and T₂. Task T₁ sends a message to Task T₂ before runnable R₁ is called. In 20% of the cases Message 1, in 30% of the cases Message 2, in 20% of the cases Message 3, in 15% of the cases Message 4, and in 15% of the cases any other message than the previously mentioned ones is sent. Task T₂ reacts on the contents of the message by calling different runnables. In case of Message 1 runnable R_2,1, in case of Message 2 runnable R_2,2, in case of Message 3 runnable R_2,3, in case of Message 4 runnable R_2,4, and in case of any other message than the previous mentioned ones runnable R_2,x is called as default.

The table below gives a detailed specification of the tasks and their parameters. The tasks are scheduled according fixed-priority, preemptive scheduling and if not indicated otherwise, all events are active in order to get a detailed insight into the system's behavior.

In order to show the impact of changes to the model, the following consecutive variations are made to the model:

1) Initial Task Set

As defined by the table above.

2) Exclusive Area

For this variation, all data accesses are protected by an exclusive area. Therefore, the data accesses in T₁ as well as all runnables in T₂ (R_2,x, R_2,1, R_2,2, R_2,3, and R_2,4) are protected during their complete time of execution via a mutex and priority ceiling protocol. That way, blocking situations appear.

3) Inter-process Activation

As from this variation on, task T₂ gets activated by an inter-process activation from task T₁ instead of being activated periodically. The interprocess activation is performed right after the message message is written in T₂ and consequently before the runnable R₁ is called. That way, a direct connection between T₁ and T₂ is established.

4) Priority Ordering

As from this variation on, the priority relation between task T₁ and T₂ is reversed. As a consequence, the priority of task T₁ is set to 1 and the priority of task T₂ is set to 2. That way, a switch from asynchronous to synchronous communication is considered.

5) Event Frequency Increase

As from this variation on, the periodicity of T₁ is shortened. For this, the value for the period of task T₁ is cut in half to 50 * 10⁶ time units. That way, the utilization of the system is increased.

6) Execution Time Fluctuation

As from this variation on, the execution time distribution is widened for both tasks. Therefore, the maximum of every uniform distribution is increased by 1 percent so that they vary now by 2 percent. That way, the utilization of the system is increased, which results in extinct activations.

7) Activation

As from this variation on, the maximum number of queued activation requests for both tasks is set to 2. That way, the problem with extinct activations resulting from the previous variation is solved.

8) Accuracy in Logging of Data State I

For this variation, the data accesses in task T₁ and task T₂ are omitted. Instead, the runnable entities R_2,x, R_2,1, R_2,2, R_2,3, and R_2,4, each representing the receipt of a specific message, are executed equally random, meaning each with a probability of 20%. That way, only a limited insight into the system's runtime behavior is available.

9) Accuracy in Logging of Data State II

For this variation, just task events are active. That way, only a limited insight into the system's runtime behavior is available.

2.3.5 Modeling Example "State Machine"

In this system architecture pattern the modeling example "Client Server without Reply" is extended in such a way that now the task that receives messages (T₂) not only varies its dynamic behavior and consequently also its execution time according the transmitted content but also depending on its internal state, meaning the prior transmitted contents. To achieve, this task T₁ sends a message to task T₂ with either 0 or 1 before runnable R₁ is called. The value 0 is used in 75 % of the cases and 1 in the other cases as content of the message. Starting in state 0, T₂ decreases or increases the state its currently in depending on the content of the message, 0 or 1 respectively. The runnable R _2,1, R _2,2, and R _2,3 represent then the three different states that the system can be in.

The table below gives a detailed specification of the tasks and their parameters. The tasks are scheduled according fixed-priority, preemptive scheduling and if not indicated otherwise, all events are active in order to get a detailed insight into the system's behavior.

In order to show the impact of changes to the model, the following consecutive variations are made to the model:

1) Initial Task Set

As defined by the table above.

2) Exclusive Area

For this variation, all data accesses are protected by an exclusive area. Therefore, the data accesses in T₁ as well as all runnables in T₂ (R_2,1, R_2,2, and R_2,3) are protected during their complete time of execution via a mutex and priority ceiling protocol. That way, blocking situations appear.

3) Priority Ordering

As from this variation on, the priority relation between task T₁ and T₂ is reversed. As a consequence, the priority of task T₁ is set to 1 and the priority of task T₂ is set to 2. That way, the timing behavior is changed fully.

4) Inter-process Activation

As from this variation on, task T₂ gets activated by an inter-process activation from task T₁ instead of being activated periodically. The interprocess activation is performed right after the message message is written in T₁ and consequently before the runnable R₁ is called. That way, a direct connection between T₁ and T₂ is established.

5) Event Frequency Increase

As from this variation on, the periodicity of T₁ is shortened. For this, the value for the period of task T₁ is halved to 50 * 10⁶. That way, the utilization of the system is increased, which results in extinct activations.

6) Activation

As from this variation on, the maximum number of queued activation requests for both tasks is set to 2. That way, the problem with extinct activations resulting from the previous variation is solved.

7) Execution Time Fluctuation

As from this variation on, the execution time distribution is widened for both tasks. Therefore, the maximum of the uniform distribution is increased by 1 percent so that the uniform distribution varies now by 2 percent. That way, the utilization of the system is further increased.

8) Accuracy in Logging of Data State I

For this variation, the data write accesses in task T₁ and task T₂ are omitted. Instead, the runnables R_2,1, R_2,2, and R_2,3, each representing the execution of a specific state, are executed with a probability of 60 %, 30 %, and 10 % respectively. That way, only a limited insight into the system's runtime behavior is available.

9) Accuracy in Logging of Data State II

For this variation, just task events are active. That way, only a limited insight into the system's runtime behavior is available.

2.3.6 Modeling Example "Feedback Loop"

The task set of the modeling example "State Machine" is expanded further in this architecture pattern with the result that messages are exchanged in a loop, instead of just in one way. To achieve this, task T₁ sends a message u to task T₂ before runnable R₁ is called. The content of this message is 0, if the content of a previously received message e is 0, or 1 if it was 1. Task T₂ represents then a state machine with three states that increases its state, if message u is 1 and decreases, if it is 0. In each state the messages y and w are set with state specific values and sent to task T₃ and task T₄ respectively. In case of State 0, the messages y and w contain the value 0, in case of State 1 both contain 50 and in case of State 2 the value 100 is sent. These messages are written before runnable R₂ is called. However, in 30 % of the cases task T₄ is activated via an inter-process activation before this runnable call happens. Task T₃ varies its dynamic behavior and consequently also its execution time according the transmitted content of message y. Task T₄ finally prepares again the input for task T₁. If the content received in message w is 0, then in 30% of the cases the content of message e is 0, otherwise 1. In the case that message w is 50, message e is set to 0 with a probability of 50% and to 1 accordingly. Finally, message e is set to 0 in 70% of the cases and to 1 in 30% of the cases, if message w is 100. In addition to this feedback loop, other system architecture patterns are added to be executed concurrently in order to increase the complexity. The tasks T₅ and T₆ represent a client-server without reply and are equal to the tasks T₁ and T₂ respectively as described in the modeling example "Client-Server without Reply". T₇ is a periodically activated task without any communication and identical to task T₇ of modeling example "Purely Periodic without Communication".

The table below gives a detailed specification of the tasks and their parameters. The tasks are scheduled according fixed-priority, preemptive scheduling and if not indicated otherwise, all events are active in order to get a detailed insight into the system's behavior.

In order to show the impact of changes to the model, the following consecutive variations are made to the model:

1) Initial Task Set

For this variation, the tasks T₁, T₂, T₃, and T₄ of the table above are active.

2) Increase of Task Set Size I

For this variation, the Tasks T₁, T₂, T₃, T₄, T₅, and T₆ are active. That way the utilization of the system is increased.

3) Increase of Task Set Size II

As from this variation on, all tasks are active. That way the utilization of the system is increased.

4) Inter-process Activation

As from this variation on, task T₂ gets activated by an inter-process activation from task T₁, task T₃ by an inter-process activation from task T₂, and task T₆ by an inter-process activation from task T₅ instead of being activated periodically. The inter-process activation in task T₁ is performed right after the message u is written in T₂ and consequently before the runnable R₁ is called, in task T₂ respectively right before task T₄ is activated, and in task T₅ task T₆ is called right before runnable R₅. That way, a direct connection between these tasks is established.

5) Event Frequency Increase

As from this variation on, the periodicity of the tasks T₁, T₅, and T₇ are shortened. For task T₁, the value for the period is set to 450 * 10⁶, the task T₅ to 60 * 10⁶, and for task T₇ to 575 * 10⁶. That way, the information density is increased.

6) Execution Time Fluctuation

As from this variation on, the execution time distribution is widened for both tasks. Therefore, the maximum of the uniform distribution is increased by 1 percent so that the uniform distribution varies now by 2 percent. That way, the utilization of the system is increased, which results in extinct activations.

7) Activation

As from this variation on, the maximum number of queued activation requests for both tasks is set to 2. That way, the problem with extinct activations resulting from the previous variation is solved.

8) Accuracy in Logging of Data State I

For this variation, the data accesses in all tasks are omitted. Instead, the runnable entities R_3,0, R_3,1, and R_3,2, are executed with a probability of 50 %, 30 %, and 20 % respectively, and the runnable entities R_6,x, R_6,1, R_6,2, R_6,3, and R_6,4 are executed with a probability of 15 %, 20 %, 30 %, 20 %, and 15 % respectively. That way, only a limited insight into the system's runtime behavior is available.

9) Accuracy in Logging of Data State II

For this variation, just task events are active. That way, only a limited insight into the system's runtime behavior is available.

2.3.7 Modeling Example "State Machine Feedback Loop"

The task set of the modeling example "State Machine" is expanded further in this architecture pattern by combining the ideas behind the modeling example "State Machine" and "Feedback Loop". This means that messages are exchanged in a loop and each sender/receiver is also a state machine. To achieve this, task T₁ has two different internal states 0 and 1, and task T₂ manages three consecutive states 0, 1, and 2. The state task T₁ is currently in is sent via a message to task T₂ before runnable R₁ is called. If the content of the message sent from task T₁ is 1, task T₂ increases its internal state, e.g. from state 0 to 1, and if it is 0, task T₂ decreases its internal state accordingly. Then, depending on the state task T₂ is currently in, the according runnable (R_2,0 for state 0, etc.) is executed. If the maximum or minimum state of task T₂ is reached but the received message from task T₁ tells task T₂ to further increase or respectively decrease its internal state, task T₂ sends a message to task T₁. This message then causes task T₁ to toggle its internal state which consequently results in a switch from increasing to decreasing or vice versa. In addition to this state machine feedback loop, other system architecture patterns are added to be executed concurrently in order to increase the complexity. The tasks T₃ and T₄ represent a client-server without reply and are equal to the tasks T₁ and T₂ respectively as described above in the modeling example "Client-Server without Reply". T₅ is a periodically activated task without any communication and identical to task T₇ in the modeling example "Purely Periodic without Communication".

The table below gives a detailed specification of the tasks and their parameters. The tasks are scheduled according fixed-priority, preemptive scheduling and if not indicated otherwise, all events are active in order to get a detailed insight into the system's behavior.

In order to show the impact of changes to the model, the following consecutive variations are made to the model:

1) Initial Task Set

For this variation, the tasks T₁, and T₂ of the table above are active.

2) Increase of Task Set Size I

For this variation, the tasks T₁, T₂, T₃, and T₄ are active. That way the utilization of the system is increased.

3) Increase of Task Set Size II

As from this variation on, all tasks are active. That way the utilization of the system is increased.

4) Inter-process Activation

As from this variation on, task T₂ gets activated by an inter-process activation from task T₁, and task T₄ by an inter-process activation from task T₃ instead of being activated periodically. The inter-process activation in task T₁ is performed right after the message to task T₂ is written and consequently before the runnable R₁ is called, and in task T₃ task T₄ is called right before runnable R₃. That way, a direct connection between these tasks is established.

5) Event Frequency Increase

As from this variation on, the periodicity of the tasks T₁, T₃, and T₅ are shortened. For task T₁, the value for the period is set to 220 * 10⁶, the task T₃ to 50 * 10⁶, and for task T₅ to 500 * 10⁶. That way, the information density is increased.

6) Execution Time Fluctuation

As from this variation on, the execution time distribution is widened for both tasks. Therefore, the maximum of the uniform distribution is increased by 1 percent so that the uniform distribution varies now by 2 percent. That way, the utilization of the system is increased, which results in extinct activations.

7) Activation

As from this variation on, the maximum number of queued activation requests for both tasks is set to 2. That way, the problem with extinct activations resulting from the previous variation is solved.

8) Accuracy in Logging of Data State I

For this variation, the data accesses in all tasks are omitted. Instead, all runnablea representing a state are executed equally random, meaning the runnables R_2,0, R_2,1, and R_2,2 are each executed with a probability of 33 %, and the runnables R_4,x, R_4,1, R_4,2, R_4,3, and R_4,4 each with a probability of 20 %. That way, only a limited insight into the system's runtime behavior is available.

9) Accuracy in Logging of Data State II

For this variation, just task events are active. That way, only a limited insight into the system's runtime behavior is available.

2.3.8 Democar Example

The so called Democar model presented in the AMALTHEA example files describe a simple engine management system.

Origin

The Democar example is loosely based on the publicly available information taken from

A Timing Model for Real-Time Control-Systems and its Application
on Simulation and Monitoring of AUTOSAR Systems
Author: Patrick Frey

A version of the dissertation can be downloaded from University of Ulm: pdf.

Files

democar.amxmi
contains the complete model, consisting of a hardware model, a model of the operating system, a stimulation model and a model that describes the software system.

trace-example.atdb
is an AMALTHEA Trace Database and it contains a trace that is the result of a simulation of this example.

2.3.9 Hardware Examples

This example contains two simple hardware models:

Example 1: Simple_ECU

The example shows a single structure with two identical cores with such an Instruction per cycle feature. The model includes only one frequency domain and no power domain. Each core is connected to all three different memory units via a HwAccessElement with read and write latencies. The memory components include an access latency. This means the total latency for a read and a write access are calculated in the following way:

TotalReadLatency = readLatency + accessLatency
TotalWriteLatency = writeLatency + accessLatency

This example shows a very simple hardware modeling approach where no interconnects and ports are necessary. Such a model can be used in a very early design phase where only rough estimations or a limited amount of informations about the system are available.

Example 2: Simple_E_E_Architecture

The second example shows a simple E/E-Architecture out of two identical ECUs. Each ECU contains two cores, one interconnect and a memory component. Both ECUs are connected via a CAN-Bus. In this example both possibilities for a HwAccessElement are shown. The local memory is just connected with read and write latencies and the external memory of the other ECU is connected with the help of a HwAccessPath. To use access paths hardware ports and connections between those ports are mandatory. The access paths itself is an ordered list of elements which are used for the connection. As an example for the access path between Core1EC1 and MainMemEC2 following access path elements are referred:

con1 -> internalCan_ECU1 -> con4 -> con9 -> CAN -> con10 -> con8 -> InterconnectEC2 -> con7.

That means the complete access paths includes:

• 3 x ConnectionHandler
• 6 x HwConnections

The latency in this case is the sum of all elements of the path plus the access latency of the memory. However latencies at connections are usually only used to account an offset for a specific component. In case a data rate is used the maximum data rate is limited by the lowest data rate in the path. In case of a ConnectionHandler the data rate is usually shared between different accesses.
The hierarchical ports from both ECUs to connect the CAN Bus with the ECUs as block boxes are not mandatory but recommended. This concept of hierarchical ports increases the number of HwConnections but allows also the structuring of all internal modules within a HwStructure and only connect the hierarchical ports with the rest of the system.

2.3.10 Scheduler Examples

The following elements are used to illustrate the structure of the example schedulers:

Hierarchical Scheduler

In this example the main scheduler realizes a Priority Round Robin strategy. The main scheduler works as a global scheduler that schedules subsystems like virtual machines or hypervisor partitions. Each partition realizes an OSEK scheduling system. In this case the main scheduler is responsible for both cores but only running on one core. Each OSEK subsystem is responsible for exactly one core but only if the main scheduler grants the core usage. The OSEK subsystems then decide on a FPP basis, which task can run. The coreAffinity for the tasks is not needed, since their scheduler is only responsible for one core.

Partitioned_FPP Scheduler

In this example an FPP scheduler acts as a global scheduler. It schedules tasks on a FPP basis but with the additional constraint that its group must have budget left (has similarities to 'adaptive partitioned scheduling' of QNX). The scheduler "CBS" (Constant Bandwith Server) is only there to assign budgets to a logical task group and define no mapping or responsibility at all. Therefore, in the taskAllocation only the priority is specified. The coreAffinity of tasks in the same group can differ, even task migration is possible if a task affinity is CoreA as well as CoreB.

2.3.11 Numeric Modes Example

Dynamic task activations and the execution of different control paths can depend on internal system states, external events and scheduling effects resulting in different execution sequences of tasks. In APP4MC modes can be used to steer different execution paths. The designer can define modes that execute different paths within runnables, tasks, and even control dynamic activation schemes of tasks with multiple dependencies. This page explains the concepts with a simple example. For the description of the basic model elements, we refer the reader to the chapters:

Data Models -> Software Model -> Modes
Data Models -> Software Model -> Runnable Items -> Runnable Mode Switch
Data Models -> Software Model -> The Call Graph -> Mode Switch
Data Models -> Stimuli Model -> Mode Value List and Execution Condition

Example description

In this chapter, we show a small example how to use modes to steer the execution and the activation of tasks with modes. The following picture depicts the example:

In this example, we have three modes, one _Enum__ and two Numeric. The numeric modes are initialized with the value -1:

First, we have two data generators with Task genX and Task genY where each execution increases a numeric mode by 1. They are activated by a relative sporadic stimulus with an occurrence interval between 10ms and 50ms. The runnable counterForX executes this for genX:

On every execution, the generator tasks trigger the CustomEvent check to evaluate the EventStimulus. This event stimulus checks the condition:
executionMode == ModeA && countX > 2 && countY > 4
In this example, we do not describe the change of the executionMode to keep the model simpler. This mode could be changed e.g. from within the system or by an external ISR trigger.

If this condition is true, both counting modes are set to zero and the Task doA is called.

Another way to steer the execution depending can be done via mode switches on task level. In doB the mode check is done at task level as depicted in the following picture:

Only if the condition is true runnable runB is called. Within this runnable the counting modes are decremented by 3.

The last mechanisms is also possible at runnable level by using the runnableModeSwitch.

Beware of where to reset or change the modes. In doB the modes are reseted directly in the beginning. If you by accident put these after the tick element, it could result in an unintended behavior. In the generator tasks be aware of where to put the customEventTrigger. This element activates the stimuli evaluation. If you put a tick element between the increment and the trigger, the evaluation is delayed.

2.3.12 AMALTHEA Trace Database (ATDB) Example

The ATDB provides tables and view definitions to hold trace data and represent it in comprehensive views. In this section we will show a small example BTF trace, convert it to its ATDB equivalent, and enrich it with event chains. The relevant tables and views will given for better understanding.

Source BTF Trace

The source BTF trace has two cores, three stimuli, three tasks, and four runnables.

#version 2.1.5
#timeScale ns
0,ECU_1,-1,SIM,SIM,-1,tag,ECU_INIT
0,Processor_1,-1,SIM,SIM,-1,tag,PROCESSOR_INIT
0,Core_1,-1,SIM,SIM,-1,tag,CORE_INIT
0,Core_2,-1,SIM,SIM,-1,tag,CORE_INIT
0,Core_1,0,C,Core_1,0,set_frequence,10000000
0,Core_2,0,C,Core_2,0,set_frequence,11000000
0,Stimulus_Task_1,0,STI,Stimulus_Task_1,0,trigger
0,Stimulus_Task_1,0,T,Task_1,0,activate
0,Stimulus_Task_2,0,STI,Stimulus_Task_2,0,trigger
0,Stimulus_Task_2,0,T,Task_2,0,activate
100,Core_1,0,T,Task_1,0,start
100,Task_1,0,R,Runnable_1_1,0,start
100,Core_2,0,T,Task_2,0,start
100,Task_2,0,R,Runnable_2_1,0,start
20800,Task_1,0,R,Runnable_1_1,0,terminate
20800,Task_1,0,R,Runnable_1_2,0,start
40900,Task_1,0,R,Runnable_1_2,0,terminate
40900,Core_1,0,T,Task_1,0,terminate
45000,Stimulus_Task_3,0,STI,Stimulus_Task_3,0,trigger
45000,Stimulus_Task_3,0,T,Task_3,0,activate
45100,Task_2,0,R,Runnable_2_1,0,suspend
45100,Core_2,0,T,Task_2,0,preempt
45100,Core_2,0,T,Task_3,0,start
45100,Task_3,0,R,Runnable_3_1,0,start
55800,Task_3,0,R,Runnable_3_1,0,terminate
55800,Core_2,0,T,Task_3,0,terminate
55900,Core_2,0,T,Task_2,0,resume
55900,Task_2,0,R,Runnable_2_1,0,resume
61000,Task_2,0,R,Runnable_2_1,0,terminate
61000,Core_2,0,T,Task_2,0,terminate

There is exacly one instance of each entity in the trace, so the tables in the database do not become to big for a small example. The visualized Gantt chart of the above trace is depicted in the following figure:

Equivalent ATDB Contents

The tables and/or relevant views for the above BTF trace are listed in the following: Note that if the table's header starts with a "v" it is a view for better readability.

Note that in the entityInstance table there are actually two instances of the cores (entityIds 4 and 5). Also note, the event chain properties are already contained in the property table.

The vTraceEvent table view intentionally resembles the original BTF trace. However, some information is omitted since it is extracted and stored in other tables (e.g. the frequency of the cores). All tags (eventType "tag") have been stored in property values.

All runnable instances are completely represented in the trace, as are the task instances. To keep it simple we leave out the vProcessInstanceTraceInfo table since it is too wide (it has more event types).

Adding Event Chains

Thus far, all information contained in the database has been extracted from the original BTF trace. Event chains, however, are not actually visible in the trace. So we insert their specification (which may originate from an AMALTHEA model) manually. Our event chain is specified as follows:

Runnable_1_1:start -> Runnable_1_1:terminate -> Runnable_3_1:start -> Runnable_3_1:terminate

In order to define our event chain for the respective events (which must be present even without a trace), we define them in the event table:

The following two tables then extend the existing ones by the event chains.

In the values of properties, we employ event chain items to represent the segments. As the vPropertyValue view indicates, at this point we refer to the stimulus/response events we created in the event table.

There is the additional view which explicitly combines event chains and their properties:

Each event chain has exactly one instance in the EntityInstance table. So the derived view for event chain instances is as follows:

Metrics on the Trace

There are numerous metrics for entities. The most important ones include the times that each entity instance remains in a specific state (according to their corresponding BTF state automaton). In addition to these metrics, there are also some counting metrics (e.g. how often a specific task instance was preempted). Lastly, there are also metrics for specific entity types and instances, e.g., the latency for a specific event chain instance (either age or reaction). The metrics themselves and these entity instance specific metrics for our example are listed in the following:

As indicated by th id numbering, we omitted some of the metrics. These include the respective Min/Max/Avg/StDev of each metric with dimension "time". Here is the view of the entity instance metric values:

Note that since each event chain instance also is either age, reaction, or both, there are two latency metrics to distinguish between the two. There are also cumulated Min/Max/Avg/StDev values calculated from these entity instance metric values. Since there is only one instance of each entity in the example trace the values are all the same, so we omit the EntityMetricValue table here (it has roughly four times as many entries).

2.3.13 BTF Example (MultipleTaskActivationLimit 3)

To clarify the interpretation of the multipleTaskActivationLimit (MTA) property of tasks, we provide a simple BTF trace example. In this example we focus on one task with an MTA = 3. Here we will show the internal task instance states of each of the three task instances. MTA = 3 means that at any given time only three task instances of the same task shall be active. A fourth activation will just be ignored. So at any given time, according to the BTF process state machine, only three state machines will exist to represent the state of their corresponding task instance.

Consider the following BTF trace:

#version 2.2.1
#timeScale ns
0,ECU_1,-1,SIM,SIM,-1,tag,ECU_INIT
0,Processor_1,-1,SIM,SIM,-1,tag,PROCESSOR_INIT
0,Core_1,-1,SIM,SIM,-1,tag,CORE_INIT
0,Core_1,0,C,Core_1,0,set_frequence,10000000
0,Stimulus_Task,0,STI,Stimulus_Task,0,trigger
0,Stimulus_Task,0,T,Task,0,activate
100,Core_1,0,T,Task,0,start
100,Task,0,R,Runnable_1,0,start
19800,Task,0,R,Runnable_1,0,terminate
19800,Task,0,R,Runnable_2,0,start
20000,Stimulus_Task,1,STI,Stimulus_Task,1,trigger
20000,Stimulus_Task,1,T,Task,1,activate
40000,Stimulus_Task,2,STI,Stimulus_Task,2,trigger
40000,Stimulus_Task,2,T,Task,2,activate
42000,Task,0,R,Runnable_2,0,terminate
42000,Core_1,0,T,Task,0,terminate
42100,Core_1,0,T,Task,1,start
42100,Task,1,R,Runnable_1,1,start

The corresponding states, at specific points in time are shown in the following. We therefore show the composed state of three state machines for Task, indexed with [1..3]. The light blue colored state is the current state the state machine is in. So at the beginning of the trace the three state machines look like this:

State after timestamp 0

After Task has been activated Task[1] is now in the state activated and the state machines look like this:

State after timestamp 100

Once the scheduler decided the task should run, Task starts and, correspondingly, changes its state:

State after timestamp 20000

Here, a second instance of Task is activated while the first has not yet terminated. So Task[2] enters the activated state:

State after timestamp 40000

Again, another instance of Task is activated so Task[3] enters the activated state:

State after timestamp 42000

Task[1] has terminated (displayed in grey):

State after timestamp 42100

Now, there is room for the state machine for the next task instance, we called it Task[4]. Also, the scheduler decided to let Task[2] run:

2.4 Tutorials

2.4.1 BTF -> AMALTHEA Trace Database (ATDB) Import Example

The following section describes how to import an existing Best Trace Format (BTF) file into an AMALTHEA Trace Database (ATDB).

Step 1

Consider the following BTF file (stored on the file system as "test1.btf"):

#version 2.1.5
#timeScale ns
0,ECU_1,-1,SIM,SIM,-1,tag,ECU_INIT
0,Processor_1,-1,SIM,SIM,-1,tag,PROCESSOR_INIT
0,Core_1,-1,SIM,SIM,-1,tag,CORE_INIT
0,Core_2,-1,SIM,SIM,-1,tag,CORE_INIT
0,Core_1,0,C,Core_1,0,set_frequence,10000000
0,Core_2,0,C,Core_2,0,set_frequence,11000000
0,Stimulus_Task_1,0,STI,Stimulus_Task_1,0,trigger
0,Stimulus_Task_1,0,T,Task_1,0,activate
0,Stimulus_Task_2,0,STI,Stimulus_Task_2,0,trigger
0,Stimulus_Task_2,0,T,Task_2,0,activate
100,Core_1,0,T,Task_1,0,start
100,Task_1,0,R,Runnable_1_1,0,start
100,Core_2,0,T,Task_2,0,start
100,Task_2,0,R,Runnable_2_1,0,start
20800,Task_1,0,R,Runnable_1_1,0,terminate
20800,Task_1,0,R,Runnable_1_2,0,start
40900,Task_1,0,R,Runnable_1_2,0,terminate
40900,Core_1,0,T,Task_1,0,terminate
45000,Stimulus_Task_3,0,STI,Stimulus_Task_3,0,trigger
45000,Stimulus_Task_3,0,T,Task_3,0,activate
45100,Task_2,0,R,Runnable_2_1,0,suspend
45100,Core_2,0,T,Task_2,0,preempt
45100,Core_2,0,T,Task_3,0,start
45100,Task_3,0,R,Runnable_3_1,0,start
55800,Task_3,0,R,Runnable_3_1,0,terminate
55800,Core_2,0,T,Task_3,0,terminate
55900,Core_2,0,T,Task_2,0,resume
55900,Task_2,0,R,Runnable_2_1,0,resume
61000,Task_2,0,R,Runnable_2_1,0,terminate
61000,Core_2,0,T,Task_2,0,terminate

Create a new empty Eclipse project that shall be used as a target container for the ATDB to imported from the btf file.

Step 2

Right-click on the project folder (in this example, the name of the project is "Test1"). You will see several possible options. In that menu select and click "Import...".
This will open a dialogue where different available import options are listed.

Step 3

Open the folder called "AMALTHEA Trace DB" by clicking on cross next to the title. This is shown in the following picture:

Select the option "AMALTHEA Trace DB from BTF" and click the "Next" button.

Step 4

You are prompted to enter the location of the BTF file you want to import. Click the upper "Browse..." button to navigate your file system and select the "test1.btf" file. If you want to change the target project the ATDB file will be created in, press the lower "Browse..." button and make your choice. If you want the original trace data from the BTF in the data base file, select the option "Persist trace event table". The figure shows the example input:

Step 5

After you have made all required inputs, click on "Finish". This will start the import of the database. Once the transformation is done the dialogue will close and the newly created ATDB file is opened in the Metric Viewer. For our example, this is shown in the following figure:

2.4.2 AMALTHEA Specification Parts to ATDB Import Example

This section describes how to use the information contained in an AMALTHEA model to enrich an existing ATDB with the specification parts (events and event chains).

Step 1

Consider the following original AMALTHEA model (called "test1model.amxmi") of which we want to import and analyze the events and event chains in the already existing test1.atdb file.

Step 2

Select both files, test1.atdb and test1model.amxmi in the Project Explorer (press and hold Ctrl while clicking on the second file). Right-click on your selection and click "AMALTHEA Specifications -> ATDB" in the contest menu:

Step 3

This will then create and open the enriched ATDB (which is named after the original amxmi file) in the metric viewer.

As can be seen in the picture, there is now metric data about the events and event chains from the test1model.amxmi file.

2.4.3 ATDB to AMALTHEA Model Transformation

Here, we describes how to use the information contained within an AMALTHEA Trace Database (ATDB) to create an initial AMALTHEA model from it.

Step 1

Let us assume there is an ATDB file called "test2.atdb" which contains typical atdb data about a trace and some specification parts (events and event chains):

Step 2

We now want to create an AMALTHEA model to start out on an initial simulateable model from the contained trace data. For this right-click on the "test2.atdb" file in the Project Explorer:

Now, click on "ATDB -> AMALTHEA model".

Step 3

This will create a new AMALTHEA model from the ATDB file (here, called "test2.amxmi". The result will contain all information about the software, hardware, events, and event chains that the original ATDB file provided.

2.5 Editors / Viewers

2.5.1 AMALTHEA Trace Database Metrics Viewer

This is a simple viewer that shows how to access the AMALTHEA trace database.

The ATDB metrics viewer displays metrics in three tabs: "Process Time Metrics", "Runnable Time Metrics", and "EventChain Time Metrics". The table in each tab displays various time metrics (depending on what events were actually in the source trace). The time metrics are aggregated, i.e., Minimum, Maximum, Average, and Standard Deviation values of the entity instances are shown. For better navigability you can collapse the metric value rows per entity. The following figure shows the metric table for processes:

And the next picture shows the same table with the metrics of "Task_1" and "Task_2" collapsed.

2.6 Model Visualization

2.6.1 Usage of AMALTHEA Model Visualization

The AMALTHEA Visualization can be opened via

• Window → Show View → Other... → APP4MC → APP4MC Visualizations,
• or via right click on an element and selecting Open APP4MC Visualization.

Via the context menu it is also possible to open multiple visualization views.

On selecting a model element, the view will render a corresponding visualization. If multiple visualizations are available, the first one will be selected by default, unless the user has selected another visualization before.

The visualization view has 4 entries in the toolbar:

1. Visualization dropdown
   The dropdown contains all available visualizations for the current active selection. A click on the image will reload the visualization.
2. Pin visualization
   The selection handling will be disabled so the visualization gets not updated on model selection changes.
3. Select model element
   Selects the current visualized model element in the model editor. Useful for example if a visualization is pinned and the selection in the model editor changed.
4. View Menu
   Contains entries to customize title and supported visualizations of the current view.

2.6.2 Standard Visualizations

APP4MC comes with a set of default model visualizations to show the options and possibilities the visualization framework provides.

Hardware Model

• HW Model Block Diagram
  
  This visualization is intended to provide an overview of the described and used hardware within the system.
  
  It uses PlantUML and SVG for rendering. Therefore a Graphviz dot.exe needs to be configured via Window – Preferences – PlantUML – Path to the dot executable of Graphviz in order to get the result shown.
  
  

Software Model

• SWModel Statistics Visualization
  
  This is a simple visualization that shows some statistics on the selected Software Model. It is also a simple example to show how to implement a visualization with JavaFX and some animations.
  
  
  
  

• Shared Runnable Label Dependencies
  
  This visualization paints all Runnables and the read/write dependencies on Labels in a Software Model.
  Via the buttons on the left edge you can Zoom in (+) / Zoom out (-) / Filter (F) the currently visible Runnables.
  
  

• Runnable Data Dependencies
  
  The purpose of this small - but hopefully useful - visualization is to lay out a graph of the Runnables in a software model based on there data dependencies. This means, two runnables are connected by a directed edge if the first runnable writes a Label that is read by the second one. Furthermore, some parts of the control flow are expressed by edges. The tool colors the graph in order to make it easier for the user to follow individual edges.

  For the visualization to work properly, the path to Graphviz DOT has to be set up in the PlantUML preferences. You can access them via Window > Preferences... and then opening the PlantUML tab.

  The buttons in the top row are used to configure the visualization.

  • Horizontal Layout: Toggle between horizontal (left to right) and vertical (top to bottom) layout of the graph.
  • Show Labels: Show read and written labels of the runnables.
  • Show R/W Dependencies: Show read/write data dependencies between runnables. This is independent from the labels being shown.
  • Show Control Flow: Show stimuli, inter-process triggers, and OS events. Also show the sequence of runnables within a task.
  • Show Tasks: Group runnables by tasks.
  • Export: Export the visualization as an image, or as Graphiz DOT. Supported image formats are PDF, SVG, and PNG. Output in other formats can be generated by exporting in DOT format and running Graphviz manually.
  • + / -: Zoom in/out.

  For performance reasons, the visualization has been limited to models containing at most 200 runnables. This limitation does not apply to the export of the graph in DOT format.

  

  The table below summarizes which elements are visualized. The following elements are considered:

  • Within a Runnable: LabelAccess
  • Within a Task: Group, RunnableCall, InterProcessTrigger, WaitEvent, SetEvent

  Other activity items (e.g. ProbabilitySwitch) are simply ignored. Using them may lead to incomplete results.

  Runnables
  Stimuli
  Tasks
  Data dependencies	(colored edges)
  Runnable sequence in tasks
  Inter-process stimuli, OS events

Runnable

• LabelAccess View
  
  A simple visualization of a Runnable and its Label read/write access. On the left side the Labels are rendered that are accessed for a read operation. On the right side the Labels are rendered that are accessed for a write operation.
  
  
  
  

• Shared Runnable Label Dependencies
  
  Visualization of all selected Runnables and their relationships based on Labels. This visualization is an example to verify how to implement a visualization on multi-selection.
  Via the buttons on the left edge you can Zoom in (+) / Zoom out (-) / Filter (F) the currently visible Runnables.
  
  
  
  

• Runnable Label Dependencies
  
  This visualization shows the current selected Runnable and the Runnables that have a direct dependency via Labels. On the left side the Runnables are rendered that write to Labels that are read by the selected Runnable. On the right side the Runnables are rendered that read from Labels that were modified by the selected Runnable.
  Via the buttons on the left edge you can Zoom in (+) / Zoom out (-) the currently visible Runnables.
  
  

Deviation

• Probability Density Diagram
  
  This visualization provides probability density diagrams for all subclasses of
  - IContinuousValueDeviation
  - IDiscreteValueDeviation
  - ITimeDeviation
  
  Markers (vertical lines) are shown for lower bound, upper bound and average.
  
  Changed values in the Properties view lead to an update of the diagram.
  
  

Mapping

• Scheduler Mapping Table
  
  This visualization shows a (hierarchical) table of schedulers, processing units and processes.
  
  

Object References

• Object References View
  
  This visualization shows objects that refer to the selected object.
  
  

Specific back-references

The visualizations in this section show a simple list of objects that refer to the selected attribute.

A double click on a list item allows to navigate to the corresponding object.

• Namespace members
  
  

Further visualizations (without screenshot):

• Tag members

Eventchain Map

• Eventchain Map
  
  This visualization shows the (nested) segments of an event chain.
  
  

2.7 Model Validation

2.7.1 Usage of AMALTHEA Model Validation

The AMALTHEA model validation can be triggered by clicking on the "Validate" button of the Amalthea editor.

The dialog shows a list of profiles allowing the selection of specific validations.

The validation is either applied to all elements of the model (default: folder scope) or only to the elements of the current file.

If an error is found, it is shown in the Problems view of Eclipse. A simple double click on the error will lead you to the affected elements in the AMALTHEA model. The validation distinguishes between three error types: errors, warnings and info.

2.7.2 Included Validations

Amalthea Standard Validations

org.eclipse.app4mc.amalthea.validations.standard.AmaltheaProfile

Amalthea Standard Validations
Standard validations for AMALTHEA models to ensure data consistency.

• Profiles:
  • org.eclipse.app4mc.amalthea.validations.standard.BasicProfile
  • org.eclipse.app4mc.amalthea.validations.standard.ConstraintsProfile
  • org.eclipse.app4mc.amalthea.validations.standard.EMFProfile
  • org.eclipse.app4mc.amalthea.validations.standard.HardwareProfile
  • org.eclipse.app4mc.amalthea.validations.standard.MappingProfile
  • org.eclipse.app4mc.amalthea.validations.standard.OSProfile
  • org.eclipse.app4mc.amalthea.validations.standard.SoftwareProfile

org.eclipse.app4mc.amalthea.validations.standard.BasicProfile

Basic Validations

• Validations:
  • AM-Basic-Counter (ERROR – Counter)
    • The offset value of a counter must not be negative
  • AM-Basic-Data-Size (ERROR – DataSize)
    • Some data sizes have to fulfill the condition >0 or >=0
  • AM-Basic-Frequency (ERROR – Frequency)
    • Some frequencies have to fulfill the condition >0
  • AM-Basic-Quantity (ERROR – Quantity)
    • Quantity unit has to be set ( undefined is an error)
  • AM-Basic-Time-Range (ERROR – Time)
    • Some time ranges has to fulfill the condition >0 or >=0
  • AM-Basic-CustomProperty-Key (WARNING – IAnnotatable)
    • Custom property keys have to be unique

org.eclipse.app4mc.amalthea.validations.standard.ConstraintsProfile

Constraints Validations

• Validations:
  • AM-Constraints-EventChain (ERROR – AbstractEventChain)
    • Stimulus and response shall not reference the same event
    • The response of the last segment has to be the same as the response of the event chain
    • The stimulus of other segments have to be equal to the response of the previous segment
    • The stimulus of the first segment has to be the same as the stimulus of the event chain

org.eclipse.app4mc.amalthea.validations.standard.EMFProfile

Amalthea EMF Validations
Standard EMF validations for AMALTHEA models (generated).

• Validations:
  • AM-EMF-INTRINSIC (UNDEFINED – EObject)
    • AMALTHEA invariants (generated)
    • EMF extended metadata constraints (generated)

org.eclipse.app4mc.amalthea.validations.standard.HardwareProfile

Hardware Validations

• Validations:
  • AM-HW-AccessPath (ERROR – HwAccessPath)
    • HwAccessPath elements must be consistent
    • HwAccessPath ranges and memory size must be consistent
  • AM-HW-Connection (ERROR – HwConnection)
    • HwConnections must be linked to HwPorts of the same Interface
    • HwConnections must refer to two HwPorts
  • AM-HW-Definition (ERROR – HwDefinition)
    • Only one feature of a category can be referred
  • AM-HW-Port (ERROR – HwPort)
    • A HwPort can only have one (non internal) HwConnection
  • AM-HW-Structure (ERROR – HwStructure)
    • Connections must only refer to contained HwPorts
    • Delegated connections always connect HwPorts of the same type
    • Inner connections always need one Initiator and one Responder HwPort
  • AM-HW-Module-Definition (WARNING – HwModule)
    • Cache definition must be set
    • ConnectionHandler definition must be set
    • Memory definition must be set
    • ProcessingUnit definition must be set
  • AM-HW-Port-BitWidth (WARNING – HwPort)
    • Bitwidth should be greater than zero
  • AM-HW-Port-Definition (WARNING – HwPort)
    • PortInterface must be set
    • PortType must be set

org.eclipse.app4mc.amalthea.validations.standard.MappingProfile

Mapping Validations

• Validations:
  • AM-Mapping-ISR-Scheduler (WARNING – ISR)
    • An ISR should have an allocation to an interrupt controller
  • AM-Mapping-Scheduler-Allocation-Hierarchy (WARNING – SchedulerAllocation)
    • A child scheduler should only be responsible for a subset of processing units of its ancestors
  • AM-Mapping-Scheduler-Allocation-Top-Level-Responsibility (WARNING – MappingModel)
    • A processing unit should have at most one top level task scheduler and one interrupt controller responsible for it
  • AM-Mapping-Scheduler-ProcessingUnit (WARNING – Scheduler)
    • A top level scheduler should be responsible for at least one processing unit
  • AM-Mapping-Task-Scheduler (WARNING – Task)
    • A task should have an allocation to a task scheduler

org.eclipse.app4mc.amalthea.validations.standard.OSProfile

OS Validations

• Validations:
  • AM-OS-Mandatory-Scheduling-Parameters-Set (ERROR – Scheduler)
    • Mandatory scheduling parameters must be set
  • AM-OS-Scheduling-Parameter-Value-Number-Matches-Defined-Multiplicity (ERROR – Entry)
    • The number of values of the specified scheduling parameter must match the defined multiplicity in the scheduling parameter definition
  • AM-OS-Scheduling-Parameter-Value-Type-Matches-Defined-Type (ERROR – Entry)
    • The type of the specified scheduling parameter must match the type defined in the scheduling parameter definition
  • AM-OS-Semaphore-Properties-Conform-Type (ERROR – Semaphore)
    • Semaphore properties conform to semaphore type
  • AM-OS-Scheduling-Parameter-Empty-Overriden-Value (WARNING – Entry)
    • There should be a value if a default value of a scheduling parameter is overridden
  • AM-OS-Standard-Scheduler-Definition-Conformance (WARNING – SchedulerDefinition)
    • Standard schedulers with their parameters should be modeled as defined by the APP4MC standard scheduler library
  • AM-OS-Standard-Scheduling-Parameter-Definition-Conformance (WARNING – SchedulingParameterDefinition)
    • Scheduling parameter definition that are used in a standard scheduler should conform to the parameters defined by the APP4MC standard scheduler library

org.eclipse.app4mc.amalthea.validations.standard.SoftwareProfile

Software Validations

• Validations:
  • AM-SW-CallArgument (ERROR – CallArgument)
    • The referred runnable must contain the referred parameter
  • AM-SW-DataDependency (ERROR – DataDependency)
    • A data dependency can only be defined for specific types of label accesses, parameters and call arguments
    • A data dependency can only refer to specific types of parameters and call arguments
  • AM-SW-Group (ERROR – Group)
    • The uninterruptible group must not contain nested groups
  • AM-SW-Semaphore-Access (ERROR – SemaphoreAccess)
    • Waiting behaviour must be 'active' for spinlock semaphore access

APP4MC.sim Validations

org.eclipse.app4mc.amalthea.validations.sim.App4mcSimProfile

APP4MC.sim Validations
Validations for AMALTHEA models used in a APP4MC.sim simulation.

• Profiles:
  • org.eclipse.app4mc.amalthea.validations.sim.SimBasicProfile
  • org.eclipse.app4mc.amalthea.validations.sim.SimHardwareProfile
  • org.eclipse.app4mc.amalthea.validations.sim.SimMappingProfile
  • org.eclipse.app4mc.amalthea.validations.sim.SimOsProfile
  • org.eclipse.app4mc.amalthea.validations.sim.SimSoftwareProfile
  • org.eclipse.app4mc.amalthea.validations.standard.AmaltheaProfile

org.eclipse.app4mc.amalthea.validations.sim.SimBasicProfile

Basic Validations (APP4MC.sim)

• Validations:
  • Sim-Basic-Identifiers (ERROR – IReferable)
    • All names of IReferable objects must be valid C++ identifier names
  • TA-Basic-ContinuousValueGaussDistribution-mean (ERROR – ContinuousValueGaussDistribution)
    • Mean must not be greater than the upper bound
    • Mean must not be less than the lower bound
  • TA-Basic-DiscreteValueGaussDistribution-mean (ERROR – DiscreteValueGaussDistribution)
    • Mean must not be greater than the upper bound
    • Mean must not be less than the lower bound
  • TA-Basic-TimeGaussDistribution-mean (ERROR – TimeGaussDistribution)
    • Mean must not be greater than the upper bound
    • Mean must not be less than the lower bound
  • Sim-supported-model-elements (WARNING – EObject)
    • Checks that the model elements are supported in APP4MC.sim

org.eclipse.app4mc.amalthea.validations.sim.SimHardwareProfile

Hardware Validations (APP4MC.sim)

• Validations:
  • Inchron-HWModule-MissingClockReference (ERROR – HwModule)
    • HW Module must have 'Frequency Domain' reference
  • Sim-HW-ProcessingUnit (ERROR – ProcessingUnit)
    • ProcessingUnit definition must be set
  • Sim-HW-AccessElement (WARNING – HwAccessElement)
    • Either hwAccessPath must be set or at least one of read latency and datarate must be set. Either hwAccessPath must be set or at least one of write latency and datarate must be set.
  • Sim-HW-Connection (WARNING – HwConnection)
    • Either read latency or data rate or both must be set. Either write latency or data rate or both must be set.
  • Sim-HW-MemoryDefinition (WARNING – MemoryDefinition)
    • Either access latency or datarate (or both) must be set

org.eclipse.app4mc.amalthea.validations.sim.SimMappingProfile

Mapping Validations (APP4MC.sim)

• Validations:
  • AM-Mapping-ISR-Scheduler (ERROR – ISR)
    • An ISR should have an allocation to an interrupt controller
  • AM-Mapping-Scheduler-Allocation-Hierarchy (ERROR – SchedulerAllocation)
    • A child scheduler should only be responsible for a subset of processing units of its ancestors
  • AM-Mapping-Scheduler-Allocation-Top-Level-Responsibility (ERROR – MappingModel)
    • A processing unit should have at most one top level task scheduler and one interrupt controller responsible for it
  • AM-Mapping-Scheduler-ProcessingUnit (ERROR – Scheduler)
    • A top level scheduler should be responsible for at least one processing unit
  • AM-Mapping-Task-Scheduler (ERROR – Task)
    • A task should have an allocation to a task scheduler
  • Sim-Mapping-SchedulerAllocation (WARNING – SchedulerAllocation)
    • Executing processing unit must be set

org.eclipse.app4mc.amalthea.validations.sim.SimOsProfile

OS model Validations (APP4MC.sim)

• Validations:
  • AM-OS-Mandatory-Scheduling-Parameters-Set (ERROR – Scheduler)
    • Mandatory scheduling parameters must be set
  • AM-OS-Scheduling-Parameter-Value-Number-Matches-Defined-Multiplicity (ERROR – Entry)
    • The number of values of the specified scheduling parameter must match the defined multiplicity in the scheduling parameter definition
  • AM-OS-Scheduling-Parameter-Value-Type-Matches-Defined-Type (ERROR – Entry)
    • The type of the specified scheduling parameter must match the type defined in the scheduling parameter definition
  • AM-OS-Standard-Scheduler-Definition-Conformance (ERROR – SchedulerDefinition)
    • Standard schedulers with their parameters should be modeled as defined by the APP4MC standard scheduler library
  • AM-OS-Standard-Scheduling-Parameter-Definition-Conformance (ERROR – SchedulingParameterDefinition)
    • Scheduling parameter definition that are used in a standard scheduler should conform to the parameters defined by the APP4MC standard scheduler library
  • Inchron-OS-PU-Allocation-MustBeDisjunct (INFO – OperatingSystem)
    • OS Scheduler to core mapping must be distinct

org.eclipse.app4mc.amalthea.validations.sim.SimSoftwareProfile

Software Validations (APP4MC.sim)

• Validations:
  • Sim-Software-AbstractMemoryElementIsMapped (ERROR – Label)
    • Checks if label is mapped to a memory node
  • Sim-Software-AbstractMemoryElementIsMapped (ERROR – LabelAccess)
    • Checks if label access type is set
  • Sim-Software-AbstractMemoryElementIsMapped (ERROR – ModeLabelAccess)
    • Checks if modeLabel access type is valid
  • Sim-Software-AbstractMemoryElementIsMapped (ERROR – Channel)
    • Checks if channel is mapped to a Memory
  • Sim-Software-ChannelAccessFeasibility (ERROR – ChannelAccess)
    • Checks if a channel access can be performed from certain runnable
  • Sim-Software-ChannelElements (ERROR – ChannelAccess)
    • Checks if channel access's property elements is greater 0
  • Sim-Software-LabelAccessFeasibility (ERROR – LabelAccess)
    • Checks if a label access can be performed from certain runnable
  • Sim-Software-Process (ERROR – Process)
    • At least one stimulus must be set
  • Inchron-SW-Task-MustHaveActivityGraph (WARNING – Task)
    • Task must have atleast one ActivityGraph
  • Sim-Software-AbstractMemoryElementIsMapped (WARNING – ModeLabel)
    • Checks if modeLabel is mapped to a Memory
  • Sim-Software-ModeLabelAccessFeasibility (WARNING – ModeLabelAccess)
    • Checks if a modeLabel access can be performed from certain runnable
  • TA-Software-ModeConditionConjunctionAlwaysFalse (WARNING – ConditionConjunction)
  • TA-Software-ModeConditionDisjunctionAlwaysTrue (WARNING – ConditionDisjunction)
  • Inchron-SW-Runnable-MustHaveActivityGraph (INFO – Runnable)
    • Runnable must have at least one ActivityGraph

Timing Architects Validations

org.eclipse.app4mc.amalthea.validations.ta.TimingArchitectsProfile

Timing Architects Validations
Validations for AMALTHEA models used in a Timing Architects Simulation.

• Validations:
  • TA-Misc-Semaphore (ERROR – Semaphore)
    • Initial value must not be negative
    • Max value must be positive
    • Max value must not be smaller than the initial value
• Profiles:
  • org.eclipse.app4mc.amalthea.validations.standard.AmaltheaProfile
  • org.eclipse.app4mc.amalthea.validations.ta.TABasicProfile
  • org.eclipse.app4mc.amalthea.validations.ta.TAConstraintsProfile
  • org.eclipse.app4mc.amalthea.validations.ta.TAHardwareProfile
  • org.eclipse.app4mc.amalthea.validations.ta.TASoftwareProfile
  • org.eclipse.app4mc.amalthea.validations.ta.TAStimuliProfile

org.eclipse.app4mc.amalthea.validations.ta.TABasicProfile

Basic Validations (Timing Architects)

• Validations:
  • TA-Basic-ContinuousValueGaussDistribution-mean (ERROR – ContinuousValueGaussDistribution)
    • Mean must not be greater than the upper bound
    • Mean must not be less than the lower bound
  • TA-Basic-DiscreteValueGaussDistribution-mean (ERROR – DiscreteValueGaussDistribution)
    • Mean must not be greater than the upper bound
    • Mean must not be less than the lower bound
  • TA-Basic-TimeGaussDistribution-mean (ERROR – TimeGaussDistribution)
    • Mean must not be greater than the upper bound
    • Mean must not be less than the lower bound

org.eclipse.app4mc.amalthea.validations.ta.TAConstraintsProfile

Constraints Validations (Timing Architects)

• Validations:
  • TA-Constraints-DataAgeTime (ERROR – DataAgeTime)
    • Maximum time must not be smaller than minimum time
  • TA-Constraints-DelayConstraint (ERROR – DelayConstraint)
    • Upper bound must not be smaller than lower bound
  • TA-Constraints-ECLConstraint (ERROR – EventChainLatencyConstraint)
    • Maximum must not be smaller than minimum
  • TA-Constraints-RTLimitMustBePositive (ERROR – TimeRequirementLimit)
    • Response time must be positive
  • TA-Constraints-RepetitionConstraint (ERROR – RepetitionConstraint)
    • Upper bound must not be smaller than lower bound

org.eclipse.app4mc.amalthea.validations.ta.TAHardwareProfile

Hardware Validations (Timing Architects)

• Validations:
  • TA-Hardware-HWFIPCMustBePositive (ERROR – HwFeature)
    • IPC (instructions per cycle) must be positive
  • TA-Hardware-PUDIPCMissing (INFO – ProcessingUnitDefinition)
    • IPC (instructions per cycle) should be set, otherwise default (1.0) will be assumed
    • Only one IPC HwFeature should be specified for a processing unit definition

org.eclipse.app4mc.amalthea.validations.ta.TASoftwareProfile

Software Validations (Timing Architects)

• Validations:
  • TA-Software-RunnableCall (ERROR – RunnableCall)
  • TA-Software-ServerCall (ERROR – ServerCall)
  • TA-Stimuli-ArrivalCurveStimulus (ERROR – OsEvent)
  • TA-Software-ModeConditionConjunctionAlwaysFalse (WARNING – ConditionConjunction)
  • TA-Software-ModeConditionDisjunctionAlwaysTrue (WARNING – ConditionDisjunction)

org.eclipse.app4mc.amalthea.validations.ta.TAStimuliProfile

Stimuli Validations (Timing Architects)

• Validations:
  • TA-Stimuli-VariableRateStimulusScenario (ERROR – VariableRateStimulus)
    • Scenario must be set

Inchron Validations

org.eclipse.app4mc.amalthea.validations.inchron.InchronProfile

Inchron Validations
Validation for Amalthea models used in Inchron Toolsuite

• Profiles:
  • org.eclipse.app4mc.amalthea.validations.inchron.InchronConstraintsProfile
  • org.eclipse.app4mc.amalthea.validations.inchron.InchronHWProfile
  • org.eclipse.app4mc.amalthea.validations.inchron.InchronOsProfile
  • org.eclipse.app4mc.amalthea.validations.inchron.InchronSoftwareProfile
  • org.eclipse.app4mc.amalthea.validations.inchron.InchronStimuliProfile
  • org.eclipse.app4mc.amalthea.validations.standard.AmaltheaProfile

org.eclipse.app4mc.amalthea.validations.inchron.InchronConstraintsProfile

Constraints Validations (INCHRON)

• Validations:
  • Inchron-Constraints-LoadRequirementMissingResource (ERROR – CPUPercentageRequirementLimit)
    • CPU load requirement must have hardware context

org.eclipse.app4mc.amalthea.validations.inchron.InchronHWProfile

Hardware Validations (INCHRON)

• Validations:
  • AM-HW-Port-BitWidth (ERROR – HwPort)
    • Bitwidth should be greater than zero
  • Inchron-HW-Memory-PortTypeResponder (ERROR – Memory)
    • HW ports of memory should be of type responder
  • Inchron-HW-PU-PortTypeInitiator (ERROR – ProcessingUnit)
    • HW ports of processing Unit should be of type initiator
  • Inchron-HWModule-InconsistentPortWidths (ERROR – HwModule)
    • HW Module cannot have ports with unequal bitwidth
  • Inchron-HWModule-MissingClockReference (ERROR – HwModule)
    • HW Module must have 'Frequency Domain' reference
• Profiles:
  • org.eclipse.app4mc.amalthea.validations.standard.HardwareProfile

org.eclipse.app4mc.amalthea.validations.inchron.InchronOsProfile

Operating Systems Validations (INCHRON)

• Validations:
  • Inchron-OS-PU-Allocation-MustBeDisjunct (ERROR – OperatingSystem)
    • OS Scheduler to core mapping must be distinct
  • Inchron-OS-Scheduler-Allocation-DifferentCPU (ERROR – Scheduler)
    • OS Task scheduler should not be allocated to more than one HwStructure
  • Inchron-OS-UserSpecificSchedulerCheck (ERROR – Amalthea)
    • User specific task scheduler needs at least one task allocation

org.eclipse.app4mc.amalthea.validations.inchron.InchronSoftwareProfile

Software Validations (INCHRON)

• Validations:
  • Inchron-SW-Runnable-MustHaveActivityGraph (ERROR – Runnable)
    • Runnable must have at least one ActivityGraph
  • Inchron-SW-Runnable-NotAllocated-DifferentOS (ERROR – Runnable)
    • Runnable cannot be scheduled by more than one OS
  • Inchron-SW-RunnableAllocation-Present (ERROR – RunnableAllocation)
    • Runnable allocation is not supported
  • Inchron-SW-Task-EnforcedMigrationCheck (ERROR – Task)
    • Invalid Enforced Migration of a task to a task Scheduler
  • Inchron-SW-Task-MustHaveActivityGraph (ERROR – Task)
    • Task must have atleast one ActivityGraph
  • Inchron-SW-Task-NotAllocated-DifferentSchedulers (ERROR – Task)
    • Task cannot be scheduled by more than one OS
• Profiles:
  • org.eclipse.app4mc.amalthea.validations.standard.SoftwareProfile

org.eclipse.app4mc.amalthea.validations.inchron.InchronStimuliProfile

Stimuli Validations (INCHRON)

• Validations:
  • Inchron-Stimuli-TypeCheck (ERROR – Stimulus)
    • Unsupported stimuli types

2.8 Model Migration

2.8.1 AMALTHEA Model Migration

Why model migration is required ?

EMF based models are the instances of ECORE meta model (which is updated for each release).

As there is a tight dependency between model instance and the corresponding meta model, old EMF models can not be loaded with the newer release of meta model.

Example : Due to the change in the namespace of the meta model, loading of model files from prior versions would fail with the latest version

This problem can be solved by explicitly migrating the model files from the prior versions to be compatible to the latest meta model version

AMALTHEA model migration

As described above, same scenario is also applicable for AMALTHEA models as they are instances of EMF based AMALTHEA ECORE meta model.

For each release of AMALTHEA there will be changes in the meta model contents, due to this it is not possible to load models built from previous releases of AMALTHEA into latest tool distribution.

Model Migration functionality is part of this distribution, using this feature it is possible to convert models from previous APP4MC releases to the ones which are compatible to the next versions of AMALTHEA meta model.

Only forward migration of models is supported by Model Migration functionality of AMALTHEA

Warning:
Migration of Amalthea models belonging to legacy versions (ITEA "1.0.3, 1.1.0, 1.1.1") is no longer supported.
If there are Amalthea models belonging to legacy versions, use APP4MC version 0.9.2 (or older) and convert the models into a APP4MC model version. These models can still be used as input for model migration.

2.8.2 Supported versions for model Migration

Model migration functionality provides a possibility to migrate the models ( created from previous releases of AMALTHEA ) to the latest versions.

Only forward migration is supported.

AMALTHEA meta model versions information

• Oldest version to migrate is APP4MC 0.7.0
  
  Beginning with that version, the AMALTHEA meta model is a part of the official Eclipse project APP4MC.

Model migration

As described above, only forward migration is supported by the AMALTHEA model migration utility.

Model migration utility migrates the specified model sequentially to the next versions (step by step) till expected version is reached.

Hint for APP4MC 0.9.3 and newer:
Migration of Amalthea models belonging to legacy versions (ITEA "1.0.3, 1.1.0, 1.1.1") is no longer supported.

Below figure represents the steps involved in the migration of model from 0.7.0 version to APP4MC 0.8.1 version:

2.8.3 Pre-requisites for AMALTHEA model migration

VM arguments

Default max heap memory (Xmx) used by the APP4MC distribution is 2 GB. In case of migrating huge models, it is recommended to increase this memory to 4 GB before invocation of "AMALTHEA Model Migration" feature

Follow the below steps to increase the heap memory setting of APP4MC :

• Open app4mc.ini file ( present in the location where APP4MC is installed) and change the parameter -Xmx from 2g to 4g. ( Note: In case if APP4MC plugins are integrated inside custom eclipse application, then corresponding <application_name>.ini file -Xmx parameter should be updated as specified below )

Linked files in eclipse project (virtual files)

In case you want to have linked files in eclipse project, during the drag and drop of the files select "Link to files" option in File Operation dialog and uncheck create link locations relative to option

2.8.4 How to invoke AMALTHEA model migration

Simple migration

An attempt to open an older model file in the model editor will show the following dialog.

The default button will simply migrate the selected file ...

• provided it doesn't have any references (only allowing single file migration)
• the original file is renamed (the version string is added, e.g. "model_0.9.2.amxmi")
• a log file with the current date is created (e.g. "ModelMigration__2019-07-30_15_43_44.log")

Migration dialog

AMALTHEA model migration utility is developed as a eclipse plugin and it is part of APP4MC distribution

Model migration utility can be invoked by selecting the required models to be migrated in the UI and specifying the target AMALTHEA version to which models should be migrated

Step 1: Selection of AMALTHEA models

Possible selections are:
- a single .amxmi file
- a folder that contains at least one .amxmi file
- a project that contains at least one .amxmi file

Step 2: Opening AMALTHEA Model Migration dialog and configuring migration inputs

On click of AMALTHEA Model Migration action, the following Model Migration dialog is opened:

Model Migration dialog consists of following information:

1. Selected AMALTHEA model files: These are the models which are included in the selection
   Note: The check box "recursive" allows to include the contents of subfolders
2. Input model versions are displayed in the second column of the table
   Note: In case of different AMALTHEA model versions in one folder, a warning will be shown.
3. Output model version : This is the AMALTHEA model version to which the selected models files should be migrated to
4. If the check box "Create backup file" is checked then a backup file with the same name suffix as in "Simple migration" is created before the migration. Otherwise the migration will be executed in place.

Step 3: Model migration

Once the required parameters are configured in the model migration dialog, click on "Migrate Models" button in the dialog to invoke migration.

The result of the migration will be shown in a new dialog:

Additionally a log file with the current date is created next to the migrated files (e.g. "ModelMigration__2019-07-30_15_43_44.log").

2.8.5 Additional details

For details regarding the below topics, refer to the corresponding links:

1. How model elements are migrated across various versions ?
2. How to update max heap memory used by the application ?

3 Data Models

3.1 Model Overview

The AMALTHEA data models are related to the activities in a typical design flow. The focus is on design, implementation and optimization of software for multicore systems. The data exchange between the activities is supported by the two main models of AMALTHEA, the System-Model and the Trace-Model.

Modeling
The behavior of a component or system is often defined in the form of block diagrams or state charts. Dynamical behavior can also be formalized by differential equations that describe how the state of a system changes over time. Modeling tools like Matlab/Simulink, ASCET or Yakindu allow to simulate the model and to generate software descriptions and implementation.

Partitioning
Based on the description of the software behavior (e.g. label accesses, synchronization, ...) this step identifies software units that can be executed in parallel.

System Modeling
The structure of the hardware (e.g. cores, memory sizes, ...) and system constraints are added to the model.
The constraints are limiting the possible results of the next step.

Optimization
The activity of assigning executable software units to the cores and mapping data and instructions to memory sections. This step can be done manually or supported by a tool that optimizes the partitioning based on information about the software behavior (e.g. data dependencies, required synchronization, etc.).

Simulation / Software Execution
In this step model-based simulation tools evaluate the timing behavior of the software.
Typically these types of high level simulations are based on the hardware and software description of the system.
Low level simulators (e.g. instruction set simulators) or real hardware can be used to execute existing software.
The resulting traces provide additional data that is the basis for a more detailed analysis.

A simplified picture shows the main purpose of the models.

The open AMALTHEA models allow custom tooling, interoperability of tools and the combination of different simulation or execution environments.

3.1.1 AMALTHEA System Model

The System Model contains:

Hardware / ECU Description
Hardware abstraction that includes general information about the hardware. Examples are: Number of cores, features of the cores, available memory, access times (from core x to memory y), etc.

SW Description
The description contains information about the static or dynamic behavior the software. This includes: tasks, software components, interfaces, variables, types, etc. It is also possible to describe the characteristics of software functions like the access to variables (read, write, frequency) or the calls to service routines (call tree).

Timing Constraints
Timing Constraints like End-to-End Delay, Latency and Synchronization can be formally written in the "TIMMO Timing Augmented Description Language" (TADL). They are derived from timing requirements or control theory.

Mapping Constraints
The different cores of a typical embedded multicore ECU have different features. For optimal performance it is necessary to restrict the assignment of some software functions to e.g. cores with fastest I/O connections or the maximum clock rate. For safety reasons it is required that some functions are located on specific cores that e.g. can run in lock step mode. Constraints like this are represented in this sub model.

SW Mapping
All information about the assignment of software units (e.g. tasks or runnables) to the cores and about the mapping of data and instructions to memory sections.

3.1.2 AMALTHEA Trace Model

There is no specific EMF data model to describe event traces. The relevant events and their states are represented in the Event Model. In addition special trace formats for multicore have been specified in the AMALTHEA project and a Trace Database has been implemented. This database stores traces in a way that allows fast retrieval of the information (see the Developer Guide for a detailed description of the database structure).

3.1.3 Structure of the model

The definition of the AMALTHEA data model follows some basic principles:

• The model is defined in one package to simplify the handling (e.g. allow opposite references).
• Different aspects are addressed in different logical sub models.
• Existing EMF models from other Eclipse projects are reused and referenced instead of creating own definitions.
• References are based on unique names within the same type of element.

We also try to use ticks wherever possible instead of direct time information. This has advantages in a multi-core environment, as the cores could have different clock frequencies.

The following figure shows the different logical parts of the AMALTHEA data model and how they are referencing each other. The central AMALTHEA model and common model that contains reusable elements are drawn without connections in this diagram.

3.2 Model Basics

The following classes are used all over the Amalthea model to define specific attributes of the model classes.

3.2.1 Custom Properties

The CustomProperty element is used to define own properties that are not (yet) available in AMALTHEA. If there is the need to extend an element or to store tool information related to processing steps, CustomProperties can be used to store this type of information. It also provides the possibility to work with prototypical approaches that later (if established and more stable) can be integrated in the standard model.

The elements are stored in a HashMap. The values can be of different types as shown in the structure picture, like String, Integer, Boolean...
In addition a ReferenceObject is available to store own references to other EObject elements.
The ListObject can be used to store multi-valued custom properties and the MapObject allows nested entries.

3.2.2 Time (and Time Unit)

The AMALTHEA data model includes a common element to describe time ranges in an easy way, the Time element. The Time class in general allows to define negative time values. If only positive values are expected the AMALTHEA validation will show a warning.
The Time element can be contained by any other element for specifying attributes to store time information.
Time units are needed to describe different timing behavior and requirements, like deadlines or offsets of components.
To support different time ranges, especially different time units, AMALTHEA predefines these types like seconds, milli-seconds, micro-seconds, nano-seconds or pico-seconds.

3.2.3 Frequency (and Frequency Unit)

3.2.4 Data Size (and Data Size Unit)

The DataSize (and DataRate) definition contains units and prefixes

• according to the SI Standard
• for binary multiples

The DataSize provides convenience methods to get the size also in bit and byte.
It is internally converted and can be retrieved in both ways.

3.2.5 Data Rate (and Data Rate Unit)

3.2.6 Deviation

Deviations used to model constant values, histograms and statistical distributions within AMALTHEA. There is a wide variety of possible use cases, where such a distribution is needed. For example, the variation in runtime of functions can be imitated. Therefore, AMALTHEA currently supports the following statistical distributions:

The earlier implementation used Generics to support the different use cases. To simplify the usage (via Java API and in the editor) the new implementation provides three different top level interfaces for Time Deviation, Discrete Value Deviation (integer values) and Continuous Value Deviation (float values). They provide specialized methods to handle their values and a common interface to access lower bound, upper bound and average.
The following image shows the detailed hierarchy of time deviations, the other implementations are built accordingly.

Boundaries

With the Boundaries class it is possible to specify commonly used deviations (scenarios). On the one hand, the scenario specified by the minimum and maximum value between which the sampled values vary. On the other hand, the Sampling Type denotes the specific scenario that is covered. These scenarios are actually defined by a Beta Distribution with preconfigured Alpha and Beta parameters. The following sampling types are available (visualized in the figures below):

BestCase

Defines the scenario in which most instances should have runtimes close to the specified minimum runtime, but still should consider some more time-consuming outliers up to the set maximum. Alpha = 0.2; Beta = 1.

WorstCase

Defines the scenario in which most instances should have runtimes close to the specified maximum runtime, but still should consider some less time-consuming outliers down to the set minimum. Alpha = 1; Beta = 0.2.

AverageCase

Defines the scenario in which most instances should have runtimes close to the middle between the specified minimum and maximum, but still should consider some more or less time-consuming outliers down to the set minimum or up to the set maximum respectively. Alpha = 2; Beta = 2.

CornerCase

Defines the scenario in which most instances should have runtimes close to the specified minimum and maximum runtime, but still should consider some other time-consuming outliers between those two. Alpha = 0.2; Beta = 0.2.

Uniform

Defines the scenario in which all instances should have runtimes that are uniformly distributed between the specified minimum and maximum. Alpha = 1; Beta = 1.

Uniform Distribution

The uniform distribution is a statistical distribution where the values between the stated lower and upper bound are equally likely to be observed.

Gaussian/Normal Distribution

The Gaussian/normal distribution is a statistical distribution where the values decrease symmetrically. The maximum value and thus its location is thereby stated by the mean and the rate of decrease is defined by its standard deviation. Since the curves approach zero on either side, an additional upper and lower bound can be added to constraint the values.

Beta Distribution

The Beta distribution is a statistical distribution whose shape is defined by alpha > 0 and beta > 0. That way, the Beta distribution can also be used to model other distributions like for example uniform, normal, or Bernoulli distribution. Since the curves can approach zero or infinity on either side, an additional upper and lower bound can be added to constraint the values.

Weibull Distribution

The Weibull distribution is a statistical distribution whose shape is mathematically defined by kappa > 0 and the scale of the distribution by lambda > 0. In the model, it is parameterized using the mean value, the lower and upper bound, and the probability that a real-valued random variable of that distribution will not take a value less than or equal to a specific value. To calculate the scale and shape parameter for the Weibull distribution from the model parameters, the equation of the mean ( see Weibull distribution – Wikipedia ) is solved for the scale parameter, first. Then, the resulting equation for lambda is plugged into the equation of the cumulative distribution function (CDF) for the Weibull distribution. Finally, the lower and upper bound allow to shift this function and the remaining unknown shape parameter in the equation is numerically approximated until the value of the parameter that constraints the distribution regarding the per mill of remaining values is reached.

Histogram

A histogram represents a distribution containing a limited number of entries (e.g. extracted from a trace). Each entry thereby is an Interval with the extra attribute occurrences which holds the number instances within the interval. The intervals do not have to cover a continuous range nor do they need to have the same interval size. Histograms are useful if there is a limited number of possibilities of valuations, which covers most practical systems. See the following figure for an example of two runnables having a time histogram deviation of their execution times.

3.2.7 Statistic Elements

The contained elements are representing statistical values.
The values can be set either with a min, avg and max representation using the MinAvgMaxStatistic element.
The other possibility is to set a single value using the SingleValueStatistic element.
The minimum and maximum values are set as a normal int value, the average the single value as float.

3.2.8 Ticks

Ticks are used to express execution times in a basic way. The number of ticks characterizes the amount of computation that is necessary to execute e.g. a Runnable. The corresponding execution time can be easily calculated if the frequency of the executing ProcessingUnit (PU) is known.The corresponding execution time can be easily calculated if the frequency of the executing ProcessingUnit (PU) is knownexecution time can be easily calculated if the frequency of the executing ProcessingUnit (PU) is known. Depending on the capabilities of a PU the time to execute such an element will differ. If necessary the fundamentally different numbers for specific types of PUs can be stored as extended values in a map.

In the next picture Ticks are shown in more detail.

3.2.9 Counters

The Counter element describes an activation of a target element that happens only every n^th time.

If for example prescaler is 5 and offset is 2 it is executed on the 2^nd, 7^th, 12^th, … time.

Counters are available at the following elements:

• Activity graph items:
  • ClearEvent
  • EnforcedMigration
  • InterProcessActivation
  • SchedulePoint
  • SetEvent
  • TerminateProcess
  • RunnableCall
  • WaitEvent
• Stimuli:
  • InterProcess
  • EventStimulus

3.2.10 Conditions

Conditions are used to model the conditional execution of high level elements (Runnables, Stimuli) and also the repeated or conditional execution in a detailed activity graph (Switch, WhileLoop). The conditions have a predefined structure of top level disjunction (OR) with conjunctions (AND) or single conditions as contained elements. It is similar to the disjunctive normal form (DNF) of a logical formula.

Use of common conditions:

3.3 Common Elements

The CommonElements model provides a central container for tags and classifiers. These elements are used in many sub models where references to Tags or Classifiers provide a mechanism to annotate objects.

3.3.1 Tags

Tags are a generic possibility to annotate objects in the AMALTHEA model.

3.3.2 Classifiers

Classifiers are used to define specific features or abilities of a core or a memory. They are used in the PropertyConstraintsModel to restrict the allocation to cores or the memory mapping.

3.3.3 Namespaces

Some elements in the data model can refer to a Namespace. A namespace provides a prefix to the name of the element.

3.4 Components Model

The AMALTHEA component model is central accessible through the ComponentsModel element.

It holds the following types:

• Components / Composites
• Systems
• Interfaces
• Structures

3.4.1 Component Interfaces

3.4.2 Architecture of Systems / Composites

The inner architecture of a System or a Composite is defined with the ISystem interface. Both elements contain component instances and connectors. The ports of the instances and the containing architecture can be identified as QualifiedPort.

3.4.3 Components Model Elements

The elements of the Components Model inherit several capabilities from common elements.

Ports, Components, Composites and ComponentInstances are referable by unique names.
A Connector also has a name but the name is optional and does not have to be unique.

Component

The 'Component' class represents a component. Components could be created directly within the 'ComponentModel' and are used as a type for a component instance.

It contains several ports of type 'Port'. A component refers the classes 'OsEvent', 'Label', 'Runnable' and 'AbstractProcess' from the software model and the class 'Semaphore' from the OS model.

System and Composite

Systems are defined as top level elements within a component model. A system contains several Component- and
Connection-instances and is used to define the architecture of a technical system.

A 'Composite' is a special component type to aggregate Component- and Connection-instances compositely.
So it could be used to create hierarchical component architectures.

System and Composite implement the interface 'ISystem'.
The following diagram shows the main elements to represent the hierarchical architecture.

In general each inner port should be connected. If a port is intentionally left unconnected it has to be added to the list of 'groundedPorts'.

ComponentInstance and Connector

The 'ComponentInstance' and the 'Connector' can be created within a 'System' or a 'Composite'. 'ComponentInstances' are used to represent instances of component- or composite-types. The 'Connector' class is used to connect the component instances to each other via their Ports. The connector contains a source and target 'QualifiedPort'.

To specfiy the implementation details of a connection between ports it is possible to specify an interface/channel pair for each connector. This links additional information from the channel implementation like the access behavior to the connector. The connector can contain multiple interface/channel pairs since an interface can contain multiple sub-interfaces realized by multiple data types implemented by multiple channels.

QualifiedPort

A 'qualified' port refers a 'ComponentInstance' and a 'ComponentPort'.
If the 'instance' link is null then the QualifiedPort refers to a port of the enclosing composite.

ComponentPort

The 'ComponentPort' class contains the attribute 'kind' to set the port direction.
The attribute 'interface name' can be used to refer to an external definition, e.g. described in detail with the Franca IDL.

Structures

Structures enables structuring/ordering of components, composites and interfaces. In contrasts to namespaces the structure does not add to the qualified name but supports the design of a hierarchical structure to order the elements in a package/folder like scheme.

3.4.4 Example

Diagram

The diagram of the example shows a composite 'A' that contains two component instances 'X' and 'Y' of type 'B'. The connections between the ports are named 'c1' to 'c4'. The grounded port 'in_3' of instance 'X' (intentionally left unconnected) is marked green. The second unconnected port 'in_2' of instance 'Y' is unspecified. It is marked red and has to be changed, either declared as grounded or connected to another port.

Model Editor

The same example is shown in the standard AMALTHEA editor.

3.5 Configuration Model

The purpose of the configuration model is to provide a common mechanism for configuration purposes. The included configurations can contain elements for further processing or build steps.

The central element is the ConfigModel class.

Currently the only configuration object is EventConfig.

3.5.1 Event Configuration

The event configuration represents target events to trace, either in a simulation or on a target hardware platform. The EventConfig elements are contained in the ConfigModel class as list with the name eventsToTrace. Attributes of EventConfig are:

1. name: (optional) name of the element
2. event: reference to an existing events in the Events model

Sample

An example use case can be to trace all Process activate events. To express this in the configuration, one contained element must be of type EventConfig with the corresponding Event pointing to an already existent element. The Event is of type ProcessEvent and the ProcessEventType is set to activate. The other attributes are left blank to not limit the configuration to one Process with a given name for example.

The consumer of the configuration must then match and filter the relevant elements for further processing.

The following screenshot is showing this minimal configuration.

3.6 Constraints Model

The constraints model contains different kind of constraints. There are the runnable-sequencing-constraints that can be used to define a required order for the runnables of the Software Model, the affinity constraints for defining the constraints for the mapping of runnables, processes and schedulers, and the timing constraints for restricting the time span between events or the duration of event chains. Regarding to that, it is also possible to define event chains in this model.

3.6.1 Requirements

The Requirements are used to specify quality requirements for the dynamic architecture.
Requirements are divided into the following types depending on the entity type for which the requirement is specified:

• Architecture Requirements for components
• Process Chain Requirements for process chains
• Process Requirements for tasks and ISRs
• Runnable Requirements for runnables

The Severity attribute is used to describe the quality impact if the requirement is not fulfilled.
The Limit defines the metric, the value, and whether the value for the metric is an upper or a lower bound.
Depending on the metric unit, the following Limits can be distinguished:

• Count Requirement Limit for metrics that count system actions
• CPU Percentage Requirement Limit for metrics that specify relative CPU characteristics
• Frequency Requirement Limit for metrics that measure the frequency of system actions
• Percentage Requirement Limit for metrics that specify relative system characteristics
• Time Requirement Limit for metrics that describe time intervals

Time Metrics

Time Metrics groups all metrics that describe time intervals of an individual process instance or between two succeeding process instances and are defined here. Note that the colors of the various time slices depicted here, directly correspond to the states and colors from the BTF specification. The metrics for individual process instances include the following:

• CoreExecutionTime : This metric quantifies the amount of time of a process instance between its start and termination in which it is actively executed on a specific processing unit.
  
• GrossExecutionTime : This metric indicates the time interval between the start moment and the termination moment of a process instance.
  
• Lateness : This metric indicates whether a process instance misses its deadline. It quantifies the amount of time between the termination moment of the process instance and its deadline. Thus, the resulting lateness is negative and indicates that no deadline miss occurred if the termination moment of the process instance is before the deadline and vice versa.
  
• MemoryAccessTime : This metric quantifies the amount of time that is required by a process for transferring data from or to the memory.
  
  
• NetExecutionTime : The net execution time indicates the actual execution time of a process instance, i.e., the time it is occupying a processing unit. Thus, it quantifies the time from the start moment of a process instance to its termination moment excluding the time the process instance is interfered.
  
• OsOverhead : This metric indicates the amount of execution time that is consumed by functions that are part of the operating system.
  
  
• ParkingTime : This metric quantifies the amount of time that a process instance spends between its start and termination passively waiting for the access of a resource.
  
• PollingTime : This metric quantifies the amount of time that a process instance spends between its start and termination actively waiting for the access of a resource.
  
• ReadyTime : This metric quantifies the amount of time of a process instance between its start and termination in which it is not actively executed on any processing unit.
  
• ResponseTime : The response time of a task or ISR instance is defined as the time between the moment of its activation and its termination. Thus, it measures the whole life cycle of a process instance.
  
• RunningTime : This metric quantifies the amount of time of a process instance between its start and termination in which it is actively executed on any processing unit.
  
• StartDelay : This metric quantifies the delay of the start time of a process instance which is defined as the time interval between the activation moment of this process instance and its start moment.
  
• WaitingTime : This metric quantifies the amount of time that a process instance spends between its start and termination passively waiting for an OS event.
  

Inter Process Instance Metrics

Inter Process Instance Metrics include the following:

• ActivateToActivate : This metric indicates the distance between two successive activations of a task or isr. The ActivateToActivate metric of process instance n quantifies the time between the activation moment of process instance n and that of instance n+1.
  
• EndToEnd : This metric indicates the time interval between two successive ends of a process. The EndToEnd metric of process instance n quantifies the time between the termination moment of process instance n and that of instance n+1.
  
• EndToStart : This metric indicates the time interval between two successive process instances. The EndToStart metric of process instance n quantifies the time between the termination moment of process instance n and the start moment of instance n+1.
  
• StartToStart : This metric indicates the time interval between two successive starts of a process. The StartToStart metric of process instance n quantifies the time between the start moment of process instance n and that of instance n+1.
  

Count Metrics

Count Metrics groups all metrics that describe absolutely how often system characteristics occur and are defined as follows:

• Activations : This metric quantifies the number of times a process is activated.
• BoundedMigrations : This metric quantifies the number of times a process instance starts executing on a processing unit that is different to the processing unit on which the previous process instance terminated.
• CacheHit : This metric quantifies the amount of times that data requested by a process is found in the cache memory.
• CacheMiss : This metric quantifies the amount of times that data requested by a process is not stored in the cache memory and has to be fetched from somewhere else.
• FullMigrations : This metric quantifies the number of times a process instance migrates from one processing unit to another triggered by a schedule point.
• MtaLimitExceeding : This metric quantifies the number of times a process is not activated during runtime because this would violate the maximum number of concurrently activated processes (MTA).
• Preemptions : This metric quantifies the number of times a process is preempted by another task or ISR.

Frequency Metrics

Frequency Metrics groups all metrics that describe the rate in which system characteristics occur and are defined as follows:

• CacheHitFrequency : This metric quantifies how often per unit of time data requested by a process is found in the cache memory.
• CacheMissFrequency : This metric quantifies how often per unit of time data requested by a process is not found in the cache memory.

CPU Percentage Metrics

CPU Percentage Metrics groups all metrics that describe a ratio between the amount of time a processing unit is in a certain state for a specific process and the maximum capacity of the considered processing unit and are defined as follows:

• CPUBuffering : This metric quantifies the ratio between the amount of time a processing unit is in the state buffering for a specific process and the maximum capacity of the considered processing unit.
• CPULoad : This metric quantifies the ratio of the load of a processing unit caused by a process and the maximum capacity of the considered processing unit.
• CPUParking : This metric quantifies the ratio between the amount of time a processing unit is in the state parking for a specific process and the maximum capacity of the considered processing unit.
• CPUPolling : This metric quantifies the ratio between the amount of time a processing unit is in the state polling for a specific process and the maximum capacity of the considered processing unit.
• CPUReady : This metric quantifies the ratio between the amount of time a processing unit is in the state ready for a specific process and the maximum capacity of the considered processing unit.
• CPURunning : This metric quantifies the ratio between the amount of time a processing unit is in the state running for a specific process and the maximum capacity of the considered processing unit.
• CPUWaiting : This metric quantifies the ratio between the amount of time a processing unit is in the state waiting for a specific process and the maximum capacity of the considered processing unit.

Percentage Metrics

Percentage Metrics groups all metrics that describe a relationship between two system characteristics and are defined as follows:

• CacheHitRatio : This metric quantifies how often data requested by a process is found in the cache memory in comparison to how often it is not found.
• CacheMissRatio : This metric quantifies how often data requested by a process is not found in the cache memory in comparison to how often it is found.
• NormalizedLateness : This metric quantifies the lateness of a process instance in comparison to the process's maximum response time which is defined by its deadline.
• NormalizedResponseTime : This metric quantifies the response time of a process instance in comparison to the process's maximum response time which is defined by its deadline.
• OsOverheadRelative : This metric quantifies the amount of execution time that is consumed by functions that are part of the operating system in comparison to net execution time of the process in whose context the functions are called.

An example for a requirement is the deadline for a task. The deadline is specified by an upper limit for the response time of the respective task.

3.6.2 Runnable Sequencing Constraints

These constraints can be used to define execution orders of runnables or, in other words, the dependencies between runnables. These dependencies can result from data exchange or any functional dependency that is not necessarily visible by other model parameters.

The following requirements can be specified with this constraint:

• Execution sequence of runnables A ->B, meaning A has to be finished before B starts
• Scope on certain process/processes, when a runnable is executed multiple times in different process contexts
• Succession of runnables within a process (strict, loose)
• Position of sequence within a process (start, end, any position)

A RunnableSequencingConstraint contains a list of ProcessRunnableGroup elements and an enumeration RunnableOrderType describing the basic rule for the sequencing. In general, a runnable sequencing constraint is independent of the processes that execute the runnables. Via the attribute "processScope" it is possible to define that a sequencing constraint is only valid for runnables within just one process or a set of processes.

The ProcessRunnableGroups contain references to runnables that should be sequenced. The sequence is defined by the order of the runnable groups within the sequencing constraint. The order of the runnable references within a group is undefined.
To sequence two runnables it is consequently necessary to create a RunnableSequencingConstraint with two ProcessRunnableGroups, each referencing one of the runnables.
To describe that a set of runnables have to be executed before or after another runnable or set of runnables, it is possible to put more than one runnable reference in a group. As already mentioned, the order of the referenced runnables within a ProcessRunnableGroup is unimportant.

The following picture visualises a RunnableSequencingConstraint and multiple possible runtime situations. The constraint has two runnable groups, each depicted by an ellipsis. In this example, there is just one runnable in each group. The runnables in the groups must be executed in the order of the group ("R1" before "R2"). There is no restriction in which process context the runnables are executed. It is important that the order is correct and that the runnable of one group terminates before the runnable of the next group starts. The exemplary runtime situations shown in the lower part of the figure visualise situations that satisfy this constraint (blue) and those who violate the constraint (red).

The RunnableSequencingConstraint in the next figure has two processes set as a scope in its second group. That means that the runnable "R3" is allowed to be executed on the processes "P1" or "P3" (blue). But it is only expected to be executed one time in between (red)!

Each RunnableSequencingConstraint has a RunnableOrderType. It provides the following sequencing modes:

• successor
• immediateSuccessorAnySequence
• immediateSuccessorEndSequence
• immediateSuccessorStartSequence

The meaning of the mode "successor" is that the runnable groups of a sequencing constraint do not have to follow each other directly, i.e., runnables that are not part of the constraint can be executed in between.
In contrast to this, the modes starting with "immediateSuccessor" express that the runnables referenced by the runnable groups must execute in direct order, so without any runnable in between. With "StartSequence", "AnySequence" and "EndSequence" it is further constrained that the runnables of the constraint have to be executed at the beginning, at the end or at any position in a process.
Assuming that all runnables are executed on the same process, the mode "immediateSuccessorStartSequence" means that all runnables of the constraint have to be executed in the correct order at the beginning of the process.
The mode "immediateSuccessorEndSequence" is like "immediateSuccessorStartSequence", but here the runnable sequence must be executed at the end of the process.

3.6.3 Data Age Constraints

Data Age constraints are used to define when the information in a label becomes valid or invalid after its last update. Therefore a runnable and a label has to be set. The information update occurs when the runnable performs a write access on the label. It is possible to define the minimum time after the information of a label update becomes valid. This means that the information shall not be used for further calculations before this time is over. The maximum time on the other hand defines the time after the label update when the information becomes invalid. Beside of time it is possible to define a minimum and maximum cycle. The cycle is related to the activation of the process that executes the runnable.

• DataAgeTime: The Time object in the role of minimumTime must not contain a negative value!
• DataAgeTime: The Time object in the role of maximumTime must not contain a negative value!

3.6.4 Data Coherency Groups

A DataCoherencyGroup is used to define data coherency requirements for a group of labels.
The Direction hereby is used to specify if the labels have to be read or written coherently. Moreover, the scope attribute defines the context of the coherent read or write requirement. Possible scopes are components, processes, and runnables.

3.6.5 Data Stability Groups

A DataStabilityGroup is used to define that the values of labels have to be kept stable within a given execution context.
Currently, the following execution contexts are covered by the scope:

• Component
• Process
• Runnable

This means that it has to be guaranteed that the values of labels are identical either within the runnable, the process, or the component in which the denoted labels are accessed.

3.6.6 Event Chains

The concept for event chains is based on the Timing Augmented Description Language.

The EventChain consists of EventChainItems. These items are classified in two types:

1. EventChainReferences -> EventChain: Used to refer to already defined EvenChains.
2. EventChainContainers -> SubEventChain: Inner anonymous EventChains, which are only available in the context of the current EventChain.

An Event Chain object references always two events, a stimulus event and a response event. To define a simple event chain that just contains two events, one event chain object is enough. In this case it would just be a chain that with its stimulus as first event and the response as second event.
If more events are required it is necessary to add sub event chains. The stimulus is always the first event of an event chain, the response is always the last event. The events that are defined in the sub event chains are the events in between.

When adding EventChainItems there are two properties that decide on the semantics of the SubEventChains:

Simple structural example for sequence

Simple structural example for parallel paths

Structural example how to combine both

The picture below shows a simple example for an event chain of four events in a row.
The top level chain defines the first event (E1) and the last event (E4).
It contains a number of event chains. They describe the way from E1 to E4.
These sub event chains are added as sequence to the parent.
For this some rules has to be considered:
The stimulus of the first child event chain has to be the same as the stimulus of the parent (red in picture).
The stimulus of other child event chains have to be equal to the response of the previous chain (blue in picture).
The response of the last child event chain has to be the same as the response of the parent (green in picture).

As a stimulus or response event it is either possible to use an Entity Event or an Event Set.
An Entity Event is a single event regarding to an entity like a task or a runnable. So it can be e.g. the start of a runnable.
If a set of events is used, then all events of this group must occur fulfill the event chain. The order in which the events occur is not important.

3.6.7 Timing Constraints

Synchronization Constraints

An EventSynchronizationConstraint describes how tightly the occurrences of a group of events follow each other.
There must exist a sequence of time windows of width tolerance, such that every occurrence of every event in events belongs to at least one window, and every window is populated by at least one occurrence of every event.
The parameter multipleOccurrencesAllowed defines, whether for the constraint all occurrences have to be considered or just the subsequent ones.

An EventChainSynchronizationConstraint describes how tightly the occurrences of an event chain follow the occurrences of a different event chain.
The SynchronizationType defines which parts of the event chains have to be in sync, stimulus or response, and the width of a time window sets the allowed tolerance.
The parameter multipleOccurrencesAllowed defines, whether for the constraint all occurrences have to be considered or just the subsequent ones.

• SynchronizationConstraint: The Time object in the role of tolerance must not contain a negative value!

Repetition Constraint

A RepetitionConstraint describes the distribution of the occurrences of a single event, including jitter.
Every sequence of span occurrences of event must have a length of at least lower and at most upper time units.

• RepetitionConstraint: The Time object in the role of lower must not contain a negative value!
• RepetitionConstraint: The Time object in the role of upper must not contain a negative value!
• RepetitionConstraint: The Time object in the role of period must not contain a negative value!
• RepetitionConstraint: The Time object in the role of jitter must not contain a negative value!

Delay Constraint

• DelayConstraint: The Time object in the role of lower must not contain a negative value!
• DelayConstraint: The Time object in the role of upper must not contain a negative value!

A Delay Constraint imposes limits between the occurrences of an event called source and an event called target.
Every instance of source must be matched by an instance of target within a time window starting at lower and ending at upper time units relative to the source occurrence.
A MappingType defines whether there is a strong ( OneToOne ), neutral ( Reaction ), or weak ( UniqueReaction ) delay relation between the events:

• OneToOne : According to page 18f of TIMMO-2-USE Deliverable D11 'Language Syntax, Semantics, Metamodel V2', a constraint with this mapping type is satisfied if and only if source and target have the same number of occurrences and for each index i, if there is an i-th occurrence of source at time x there is also an i-th occurrence of target at time y such that lower ≤ y - x ≤ upper.
  This means that the source event and the target event have the same number of occurrences and no stray target occurrences are accepted.

• Reaction : According to page 17f of TIMMO-2-USE Deliverable D11 'Language Syntax, Semantics, Metamodel V2', a constraint with this mapping type is satisfied if and only if for each occurrence x of source, there is an occurrence y of target such that lower ≤ y - x ≤ upper.
  This means that multiple source event occurrences may be mapped to the same target event and stray target event occurrences are ignored.

• UniqueReaction : This mapping type is a mixture of the previous types by specifying that for every occurrence of the source event exactly one target event must occur within the defined time span. Thus, target events may not be shared between source events and stray target events violate the requirement. In contrast to the OneToOne mapping case, the source event is not mapped to the first source event but is dropped as a violation, if a target event is missed.

Event Chain Latency Constraint

An EventChainLatencyConstraint defines how long before each response a corresponding stimulus must have occurred ( Age ), or how long after a stimulus a corresponding response must occur ( Reaction ).
It always refers to an EventChain.

• EventChainLatencyConstraint: The Time object in the role of minimum must not contain a negative value!
• EventChainLatencyConstraint: The Time object in the role of maximum must not contain a negative value!

3.6.8 Affinity Constraints

Affinity constraints are used to define the mapping of executable objects to each other.
The objects that can be mapped are:

• Runnables
• Processes (Task or ISR)
• Labels

An affinity constraint can either be a pairing or a separation constraint. A pairing constraint contains one amount of objects and a target. The pairing constraints say "All these objects must run together on this target". A separation constraint contains two groups of objects and a target. It says "This group of objects is not allowed to be mapped with the other group of objects on the specific target". So the separation constraint can be used to forbid a combination of objects on a target. It can also be used to say "These objects are not allowed to be mapped on this target". In this case only one group of the separation constraint is used.

Each affinity constraint has one or more targets. The type of the target depends on the type that should be mapped.

Data Affinity Constraints

A DataConstraint is used to define the mapping of label objects to memory units.

Process Affinity Constraints

A ProcessConstraint is used to define the mapping of process (Task or ISR) objects to processing cores or scheduling units.

Runnable Affinity Constraints

A RunnableConstraint is used to define the mapping of runnable objects to processing cores or scheduling units.

3.6.9 Physical Section Constraints

A PhysicalSectionConstraint is used to to define the mapping of Section objects to Memories. This mapping of Section object to Memory objects specifies that corresponding PhysicalSectionMapping associated to this Section element can be allocated only in the mapped Memories.

Example: PhysicalSectionConstraint with the below properties has the following semantic:
	name: Ram1_Ram2_PhysicalSectionConstraint
	Memories : RAM1, RAM2
	Section : .abc.reini
Semantic: PhysicalSectionMapping for .abc.reini section can only be allocated either in RAM1 or RAM2 or in both. But not in other Memories.

3.7 Event Model

The event model provides the classes to describe the BTF-Events that can be used for the tracing configuration, for the modeling of event chains and for some timing constraints.

The top level structure is the following:

There are different event classes for the different entity types that can be traced:

3.7.1 Entity Events

3.7.2 Trigger Events

3.7.3 Process Events

In a running system, each entity can have different states. An event trace consists of the events that are visualizing the state-transitions of the traced entities. To define such an event in the model, each kind of event class contains an event-type-enumeration that provides the event-types for the state-transitions of its entity. The following picture shows the possible states of a process:

So for example the event-type-enumeration for a process event contains the events activate, start, resume, ...

3.7.4 Details

A description of the individual events can be found in the following table:

If it is required to define an event like "start-event of some process" then it is enough to create a object of type ProcessEvent and set the event-type start.

It is also possible to restrict the definition of an event to a special entity. So it can be defined like "start-event of task T_1". Therefore it is possible to reference a process from ProcessEvent. In general, each event class can reference an entity of the corresponding type. In addition to that, each event class provides individual restrictions. So it is possible for ProcessEvent that the event is not only restricted to a special process, it can be also restricted to a core. So that would be like "start-event of task T_1 on core C_2". Another example is the class RunnableEvent, it allows to restrict the event to a runnable, the process that executes the runnable and the core that executes the process.

3.8 Hardware Model

The AMALTHEA hardware model is used to describe hardware systems which usually consist of several hierarchical elements which contain processing units, memories, connections etc. It is accessible through the HWModel element and contains following top level elements:

• Definitions
• Domains
• Features
• Structures

3.8.1 Class Diagrams

Hardware model elements

Hardware definitions and features

Hardware modules and access elements

Hardware paths and destinations

3.8.2 Element description

The following tables describe the different model elements and their attributes in detail. For several elements short examples are attached.

HwModel

The HwModel class is the root element of the hardware model. It always contains one or multiple HwStructures, PowerDomains and FrequencyDomains and optionally different HWFeaturesCategories for the HwModule definitions.

HwDefinition

Additional information about the definition concept in general can be found in the User Guide (see General Hardware Model Overview).

ProcessingUnitDefinition

For specifying a compute resource a ProcessingUnitDefinition is created, which is afterwards referenced by the number of ProcessingUnit instances of this kind. A ProcessingUnitDefinition can reference multiple HwFeatures to express different costs for different operations but only one HwFeature per HwFeatureCategory.

MemoryDefinition

For specifying a memory, a MemoryDefinition is created, which is afterwards referenced by the number of Memory instances of this kind.