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.

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:

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:

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:

Inter Process Instance Metrics

Inter Process Instance Metrics include the following:

Count Metrics

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

Frequency Metrics

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

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:

Percentage Metrics

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

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.

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:

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:

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.

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.

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.

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:

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.

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:

Name Description
EventChainItemType This property defines how to interpret the subEventChain. There exist two possibilities: sequence and parallel. Sequence means that all the subEventChains are evaluated in the defined order of the list. Parallel path can be alterantive paths or joins.
minItemsCompleted Defines how the parallel execution is interpetated. The designer specifies how many elements of the subEventChains must be completed to go to the next step. 1 represents alternative paths of the EventChain. If the number equals the number of elements in the EventChainItems list all paths must be triggered to continue the event-chain tracking and represents a complete join of all 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.

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.

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.

Delay Constraint

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:

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.

Affinity Constraints

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

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.

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.