Definition

A property is a characteristic or quality that describes an attribute of the system, or of a part of the system. Basically, a property is everything that can be expressed by a value. That concerns all sorts of attributes to describe the system, its components, its requirements, or its environment. It also includes information to describe functional or non-functional characteristics.

Basically a Property is a named value. Beside the value and a name, properties in our model have additional attributes:

Data type: Properties can represent various data types. Currently the following data types are considered:

• Numbers: Properties can be expressed as integers or floating point numbers.

For example number of nodes, available memory, or sending power.

• Strings: Character strings are a means to express names of components. For example the name of a microcontroller or the name of a cryptographic accel-erator.

• Enumerations: Enumerations are a list of options (typically strings) that can be set for the property. Examples are:

– Application.type={Home, Public, Industrial, Medical}

– Radio.band.type={433MHz, 868MHz, 2.4GHz}

– Security.strength={none, low, medium, high}

• Sets: Several properties are expressed as sets. In practice these sets are typ-ically based on strings. For example the propertymeasures, which expresses the types of measurements in the system is such a set.

– Sensor1: measures = Temperature – Sensor2: measures = Pressure

– System(Sensor1+Sensor2): measures ={Temperature, Pressure}

Scale: The scale of a Property is important, particularly with respect to the comparison of properties. The scale type of a property is defined implicitly. Properties defined as strings or sets are nominal, so that only equity can be evaluated. Enumerations are considered as ordinal scale, because an enumeration is defined as ordered set of attributes. Properties defined by numbers are considered as ratio scales.

Unit: if applicable the unit of the property should be provided to prevent ambiguous interpretations of a property. For example the property energy is basically mean-ingless without a unit.

Relations

Properties influence and depend on other system attributes. For example the setting of an application type affects the required security strength. Another example is the required radio sending power that may depend on the distance of the nodes. For this purpose operations on properties are needed. In this thesis operations on properties are generally termed Relations. The semantic of relations is similar to a line of code in a standard imperative programming language. For example the operation a:=b+c, which, in a programming language, assigns the value of the addition of variables b and c to the variable a, is in the configKIT context a relation that expresses the value of the property aas function of the propertiesb andc.

Similar to classic operations, Relations can be Assignments or Constraints.

Assignments define a property as function on other system properties. An assignment is for instance the formula

Cost_of_System:=Cost_of_Nodes * Number_of_Nodes, which assigns the results of the multiplication of Cost_of_Nodes and Number_of_Nodes to the property Cost_of_System.

Figure 5.6: Graphical notation of Properties and Relations: Properties are boxes, Re-lations are Ellipses. The arrow between Properties and ReRe-lations indicates whether the connected Properties are input or output of a Relation. Relations with one output are Assignments, Relations without output are Comparisons.

Constraints are boolean functions on system properties. A comparison is for example Cost_of_System <1500which returns true only ifCost_of_Systemis smaller than 1500. In contrast to assignments, constraints do not assign result of the operation to a property. That is why not all comparisons are constraints. A relation which is an assignment of a comparison (e.g. b := (a == 5)) is an assignment and no constraint. Also conditional assignments such asb:= (a== 5)?x:y, which assigns tobthe value of xifaequals 5, and otherwise the value ofy, are assignments.

While relations are are always connected to at least one property, they are not attached to properties directly. Thus relations are independent data types. They inherently define which property should be written and select the required inputs.

Graphical Notation

Figure 5.6 shows the basic principles of the graphical notation of the PRG structure.

Properties are represented by boxes, whilerelationsare Ellipses. Arrows fromproperties torelationsindicates that the correspondingpropertyis used in the function computed by therelation. Arrows fromrelationsto apropertyshow that the result of the computation in the relation is assigned to the property. The associated relation is an assignment.

Relations without outgoing arrow areconstraints. The graphical structure of properties and relations is the Property-Relation-Graph (PRG).

Example

Figure 5.7shows a small example of a Property-Relation-Graph. In this example Light gray ellipses are constraints, and the dark gray ellipses are assignments. The example illustrates a simple energy assessment model. The assignment uses the properties Time and Power to compute the Energy. The value is assigned to the corresponding system property. That Energy is checked against the Property Battery Power by the constraint

“Battery Power>Power”.

Time

Energy:=Time*Power Power

Energy

Battery_Energy>Energy

Battery_Energy

Figure 5.7: Example for a Property-Relations-Graph: The small energy model computes the needed energy and compares it to the available energy from the battery.

Data Model

Figure 5.8 concludes the introduction of the PRG data types in a data meta-model of properties and relations. It shows:

Relations receive input from any number of Properties. It can be refined to Assignments and Comparisons. Comparisons may be Constraints of the system.

Assignments are relations but additionally define one Property. The definition is based on the inputs of the Relation.

Constraints are relations that compute a function with boolean result.

Property delivers input to any number of Relations. May be defined by any number of Assignments.

PRG is composed of Relations and Properties. Both data types can also be in any number of PRGs. The PRG is the interface for Requirements, Components, and the System Model to access Properties and Relations.

Figure 5.8: Meta-model of the Property-Relations: A Relation receives input from any number of Properties, and can be refined to Assignments, which assign a property, and Comparisons, which may represent system constraints. Properties and Relations may be defined by Requirements, Components and the System Model.

Later we will see that in fact components, requirements as well as property databases and the working model are instances of the PRG.

Discussion and Related Approaches

The idea of representing data dependencies in a graph is not new. For exampleData-Flow Graphsas used in compilers represent operations (analog to relations) and variables (ana-log properties) in a dependency graph, illustrating the (ana-logical dependencies to compute complex operations or algorithms. Data-Flow Graphs just illustrate the data flow and do not actually work on the data. Hence they are also not applied to identify conflicts of the values.

Logic Truth Maintenance Systems [DK86] can be applied to evaluate the truth and thus the conflicts of the system. They are also called constraint solvers or satisfiability (SAT) solvers, since they are means to solve large systems of constraints and dependen-cies very efficiently. Typically they work on boolean values.

Recently integer constraint solving has been discussed [SMDD10], extending the typi-cally boolean constraint models of product lines and feature systems by integer variables, which is a promising approach but still does not cover the variety of types considerable for system properties.

Logical programming languages like PROLOG [CM03] are able to maintain and solve complex truth systems. However, maintaining the logical truth of the PRG is just one aspect in the configKIT configuration tool. It has to interact with the component compo-sition and the requirement definition. That is why we decided to develop the independent PRG structure with the intention to express the complex structure of relations of system properties. It is a rather intuitive tool to assess the system state. At later stage an adaptation or mapping of sophisticated SAT techniques is intended.