nfp-modeling:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
nfp-modeling:start [2020/02/26 20:01]
Timo Blender [The NFCC Model]
nfp-modeling:start [2020/02/27 10:06] (current)
Timo Blender [Modeling and Composing Non-Functional Properties: Further Details]
Line 1: Line 1:
-====== ​NFP Modeling ​fixme ======+====== ​A New Approach for Modeling ​and Composing Non-Functional Properties: Realizing Flexible and Adequate Service Robot Behavior: Further Details ​======
  
-This article ​introduces a methodology ​for modeling ​and composing non-functional properties (NFPs). Describing building blocks regarding their NFPs can become a complex issue because there may be several dependencies that must be taken into account. Hence, static NFP descriptions are not not always a meaningful choice. We propose the //NFCC// approach - a //​Non-Functional Composition Chain// that captures the dependency relations of NFPs. From a general point of view, the NFCC is a dependency graph between different resources linked via special calculation blocks.+This article ​provides additional details ​for the paper //A New Approach for Modeling ​and Composing Non-Functional Properties: Realizing Flexible and Adequate Service Robot Behavior// submitted at IROS 2020. 
 + 
 +Describing building blocks regarding their NFPs can become a complex issue because there may be several dependencies that must be taken into account. Hence, static NFP descriptions are not not always a meaningful choice. We propose the //NFCC// approach - a //​Non-Functional Composition Chain// that captures the dependency relations of NFPs. From a general point of view, the NFCC is a dependency graph between different resources linked via special calculation blocks.
  
 ===== The Meta-Level of the Approach ===== ===== The Meta-Level of the Approach =====
Line 49: Line 51:
 This building block is associated with the functional software component of the used laser hardware. Relevant providers in this example are: This building block is associated with the functional software component of the used laser hardware. Relevant providers in this example are:
  
-  * **Accuracy:​** Is assumed to be a static value in this example ​and refers to the deviation in cm+  * **Accuracy:​** ​Refers to the deviation in mm. Is assumed to be a static value in this example. 
-  * **Frequency:​** The frequency parameter range of the image providing ​task. The maximum value is restricted ​    ​by the hardware.+  * **Frequency:​** The frequency parameter range of the task providing the laser scan data. The maximum value is restricted by the hardware.
   * **Dimension:​** Dimensionality of the provided representation. This is 2D for the laser hardware represented by this building block.   * **Dimension:​** Dimensionality of the provided representation. This is 2D for the laser hardware represented by this building block.
  
Line 57: Line 59:
 This building block is associated with the functional software component of the used camera hardware. Relevant providers in this example are: This building block is associated with the functional software component of the used camera hardware. Relevant providers in this example are:
  
-  * **Accuracy:​** Refers to the deviation in cm. Is assumed to be a static value in this example. +  * **Accuracy:​** Refers to the deviation in mm. Is assumed to be a static value in this example. 
-  * **Frequency:​** The frequency parameter range of the image providing ​task. The maximum value is restricted ​    ​by the hardware.+  * **Frequency:​** The frequency parameter range of the task providing the image data. The maximum value is restricted by the hardware.
   * **Dimension:​** Dimensionality of the provided representation. This is 3D for the camera hardware represented by this building block.   * **Dimension:​** Dimensionality of the provided representation. This is 3D for the camera hardware represented by this building block.
  
Line 104: Line 106:
  
   * **Time:** Refers to the time needed to reach the goal location. We use RM and define a linear relation to Velocity. The higher the velocity, the higher the utility with respect to time.    * **Time:** Refers to the time needed to reach the goal location. We use RM and define a linear relation to Velocity. The higher the velocity, the higher the utility with respect to time. 
-  * **Maximum Braking Distance:** The maximum distance a robot still travels up to standstill after it decided to stop. A safety concern that may lead to undesired collisions in dynamic environments. This property can be composed ​absolutely ​using the given formula and depends on the Velocity, the Response Time of the sensor-actuator loop and the acceleration deceleration of the mobile base.+  * **Maximum Braking Distance:** The maximum distance a robot still travels up to standstill after it decided to stop. A safety concern that may lead to undesired collisions in dynamic environments. This property can be composed ​absolute ​using the given formula and depends on the Velocity, the Response Time of the sensor-actuator loop and the acceleration deceleration of the mobile base.
   * **Spill Risk:** The higher the velocity, the higher the spill risk (the lower the utility w.r.t Spill Risk) but of course only if the robot transports a filled cup.   * **Spill Risk:** The higher the velocity, the higher the spill risk (the lower the utility w.r.t Spill Risk) but of course only if the robot transports a filled cup.
-  * **Energy (MotorEnergy,​ CPUUtilization):​** We modeled two relevant dependencies:​ (i) energy consumption by the motors and (ii) energy consumption by CPU utilization. For the former we use RM(Velocity) and for the latter we have the absolute values. But due to the former relative dependency (modeling energy consumption ​absolutely ​is hard in general but especially for this navigation architecture),​ the superordinate Energy property can not be modeled ​absolutely. Hence, we use the relative WS pattern and adjust the weights to declare the dominating factor (MotorEnergy).+  * **Energy (MotorEnergy,​ CPUUtilization):​** We modeled two relevant dependencies:​ (i) energy consumption by the motors and (ii) energy consumption by CPU utilization. For the former we use RM(Velocity) and for the latter we have the absolute values. But due to the former relative dependency (modeling energy consumption ​absolute ​is hard in general but especially for this navigation architecture),​ the superordinate Energy property can not be modeled ​absolute. Hence, we use the relative WS pattern and adjust the weights to declare the dominating factor (MotorEnergy).
  
-Finally, we model our Conflicts in this container. We use the more abstract normalized braking distance value in each conflict instead of its lower-level dependencies (Velocity and Performance),​ the ones that are actually affected directly by the Variation Points. But since braking distance is composed ​absolutely, its normalized value is able to reflect the partial influences of the Variation Points via the lower-level dependencies. This is also the reason why we model the conflict for the Navigation Strategy Variation Point explicitly here: In the ObstacleAvoidance component the SafetyDistance/​ExecutionTime-conflict is only local and the latter refers to the execution time of the individual strategies - a value that is actually meaningless. However, the value is gaining importance as a partial influence factor to a more abstract property of a more abstract functionality (BrakingDistance/​GOTO). In this sense, the local conflict is taken up from the ObstacleAvoidance component and then mapped to a higher level of abstraction.+Finally, we model our Conflicts in this container. We use the more abstract normalized braking distance value in each conflict instead of its lower-level dependencies (Velocity and Performance),​ the ones that are actually affected directly by the Variation Points. But since braking distance is composed ​absolute, its normalized value is able to reflect the partial influences of the Variation Points via the lower-level dependencies. This is also the reason why we model the conflict for the Navigation Strategy Variation Point explicitly here: In the ObstacleAvoidance component the SafetyDistance/​ExecutionTime-conflict is only local and the latter refers to the execution time of the individual strategies - a value that is actually meaningless. However, the value is gaining importance as a partial influence factor to a more abstract property of a more abstract functionality (BrakingDistance/​GOTO). In this sense, the local conflict is taken up from the ObstacleAvoidance component and then mapped to a higher level of abstraction.
  
 === Requirement Specification === === Requirement Specification ===
nfp-modeling/start.1582743673.txt.gz · Last modified: 2020/02/26 20:01 by Timo Blender