Dynamic Aspects of the PRG

Figure 5.10: Dynamics influencing the PRG in the Working Model.

for the application one can change the battery, or influence the energy consumption by working on duty time or power consumption.

Frequency

Frequency:=1/Period

Period:=1/Frequency

Period

Figure 5.11: Example for a circular property realtion.

the system the operation is trivial. Further definitions are required if pis already part of P, i.e. (pT

P 6=∅). Conflicts in definition must be prevented. Conflicts of content will be analyzed separately, which is discussed below.

Adding Relations to the RPG is more complex, since relations work on properties and express the connection to the properties with the modification of the edges of the graph.

To add the Relation r:hpr, Ar, drito the PRGG, we define the operation G⁰ =G+r as:

G⁰=hP⁰, R⁰, E⁰i P⁰=P∪pr∪Ar. R⁰=R∪r.

E⁰=E∪ [

a∈Ar

(r×a)∪ [

p∈p_r

(p×r).

It adds properties and edges required by the relation. Similar to the addition of the properties, the actual challenge after adding the relations is handling the content of the properties.

Content-related dynamics of the PRG

The purpose of the PRG is not only to model the relations between the properties but to derive dependent properties and to identify violations of constraints. Therefore it is required to define and to propagate the content of the properties.

For this propagation several strategies exist.

• start with the newly set property and follow the edges of the graph recursively and update the corresponding properties. The propagation may stop if it does not change the values of the passed properties.

• Identify the relations that depend on the changed property (p×E^∗TR), and update them all repeatedly until the computed values are stable, i.e do not change anymore.

In this propagation and assignment phase non-trivial structure may occur:

Circular assignments is one problem that may occur in the graphs. Figure5.11shows an example for such a circle: Period defines Frequency and Frequency defines Period. Such circles are reasons for an explicit termination of the propagation as expressed in both strategies above.

Figure 5.12: Implicit handling of multiple property definitions: A property can define how it handles multiple definitions. The Size property summarizes the multiple inputs.

The assumed security (Sec) component choses the maximum of the inputs.

A further mechanism to prevent infinite circles is to flag properties that have been passed in the current update run. Such node will not be updated a second time.

Handling ambiguous assignments is a significantly more challenging issue. Properties can be assigned by other Properties, Components, or the user. Therefore, it is likely that some properties are set more than once. For instance data packet size can be defined differently for each service of the system. This behavior causes possible conflicts in the moment a property is driven by more than one source. It can be handled in different ways:

1. Forbid multiple definitions structurally: This would enforce that each property is always driven by exactly one source.

2. Forbid multiple definitions during runtime: The property is able to receive its value from different sources, but will generate a conflict if more than one source delivers actual data.

3. Attach implicit or explicit relations for properties: Instead of writing directly to the property, external sources write to a entry relation of the property. The entry relation contains the rules to decide what should be assigned. Examples are mini-mum or maximini-mum, but also the summation. Figure5.12illustrates two examples:

If for example one system component has the property size:=500 and another com-ponent has the property size:=1000 (both defined as relation), the property contains information to add the multiple definitions.

In case of security the general application requirement may be set to low, but a specific requirement demands high security. Then the multiple re-definition has to be resolved to the higher choice, implementing an implicit MAX operation.

Such definitions require the properties defined properly in the property repository.

Handling undefined values is another issue that has to be addressed with regard to the property propagation. If all inputs are defined, parsing and evaluating the relation terms is straightforward. However, the Property Repository contains many properties that are loaded in the PRG of the WM but do not need to be defined for each application.

It results in undefined Properties whose handling is not obvious. We considered the following strategies to cope with the undefined values:

1. Consider undefined Properties as set to a default value.

2. Define the output as undefined in case one of the inputs is undefined. This is the appropriate handling for pure mathematical terms.

3. Comparisons can be handled strictly logical, i.e. it returns true only if the condition is true. If it is unclear due to undefined values it is false. For example consider the assignment:

Security.Concealment := Application.Type=Military?high:low

It sets the required strength for the concealment property of the security to high if the application type is military and to low otherwise. In case the application type is defined, resolving that relation is trivial. However, even if application type is not defined the term can be resolved considered the equivalence operation returns FALSE if the comparison is not TRUE, which it obviously is not if application type is not defined.

We support option 2 for calculations and option 3 for comparisons. If a default value is given in the description of the Properties it is loaded in advance, so that the value is not undefined. An additional default value for Properties without default settings is not supported.