This is an old revision of the document!
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 NFCC at the meta-level is a valid composition of different composition elements. A composition element is a valid triple relation between three abstract basic entities: provider, dependency and operator.
A provider can have dependencies and an operator. A provider provides a resource in a specific representation and the assigned operator manipulates the result of the resource to be provided based on the dependencies. There are several subtypes of a provider and an operator. A provider subtype has special dependency constraints to other provider subtypes. A valid provider-dependency subtype combination has specific assignment constraints of operator subtypes. The current set of subtypes, their relations and constraints are shown in the following meta-model:
We use the well-known Block-Port-Connector modeling scheme to cope with separation of roles and responsibilities:
The functionality of the presented use-case is a flexible navigation stack (https://robmosys.eu/wiki/domain_models:navigation-stack:start) to realize a GOTO(Start, Goal) capability. We assume that this system offers 4 variation points that do not change the functionality but impact the NFPs of the system:
The following figure shows the graphical NFCC model created with Sirius/Eclipse. We introduced different building blocks: (i) There are building blocks for each software component of the functional view that provide relevant non-functional information: ObstacleAvoidance, MobileBase, Laser, Camera, CameraToLaser. (ii) We defined the building block GOTO to represent the more abstract, overall behavior of the composite skill and its non-functional properties. (iii) We also defined building blocks to envelope and group together certain non-functional concerns that can be addressed in isolation by a corresponding role/expert to reduce the overall complexity such as requirements specification, performance analysis and provision of relevant context data. These are rather steps of the development workflow than building blocks in the sense of (i) and (ii). Nevertheless, we currently treat them as building blocks as well with the advantage of having all relevant aspects collected in one model. (iv) Finally, we use special fork building blocks to represent a Fork Variation Point.
This building block is associated with the functional software component of the used mobile base hardware. Relevant NFP that this building block offers are the maximum velocity and the acceleration deceleration property of the hardware.
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 camera hardware. Relevant providers in this example are:
Maps the camera data to 2D laser data, but keeps some information a 2D laser would not be able to see. It can therefore be treated as a kind of 2.5D representation of the local environment.
The functional counterpart is responsible for selecting local curvatures to avoid obstacles and to approach the next waypoint on the route to the final goal. It has the Velocity and the Navigation Strategy Variation Points. The two navigation strategy variants are modeled as inner building blocks and are associated with the conflicting properties of execution time and safety distance. We assume that Strategy_B considers an additional safety distance metric next to velocity (tries to approximate the Velocity Parameter as good as possible) and heading (tries to approximate the orientation to the next waypoint as good as possible) when evaluating curvatures. The safety distance metric at time t is defined by the minimum lateral distance to the obstacles along the whole curvature at time t. This requires additional calculations each time increasing the performance of this execution variant in contrast to Strategy_A that only considers the velocity and heading criteria. Note, that the problem of selecting curvatures regarding different criteria is a conflict of objectives per se, but the availability of two different implementations adds a next level of conflict. The quantification of both properties is not trivial and is thus argued as follows:
The local conflict here is the chance for more safety distance at the expense of a higher execution time. Since the local execution time here is not very meaningful, the conflict is modeled at a higher level of abstraction (see later section about GOTO building block).
The mentioned discrete Sensor variation point is modeled by a Fork Building Block. The two alternative execution paths are (i) Laser and (ii) Camera + CameraToLaser before they merge in the ObstacleAvoidance. The special CA (Collect-Aggregate) entities of a fork building block allow us to collect alternative results for a specific property that are modeled in separate building blocks and aggregate them to a single output that provides a variability vector that can be traced back to the different variants. This way, we can summarize all relevant NFPs affected by this Variation Point and provide conflicting values. In this example and for that Variation Point, we expect multiple values regarding the following NFPs:
These building blocks actually envelope a separate activity for a compositional performance analysis that is of big complexity. In general it is the provider of the end-to-end performance (worst case response time + cpu utilization) of the sensor-actuator loop for the Laser and the Camera variant respectively. The dependencies are among others the execution times of the involved tasks of the components along the sensor-actuator loop, and their individual activation sources that are also Variation Points (e.g. the frequency of a periodic timer is a Parameter that can be configured within a specific scope, see Camera and Laser). All the dependencies can have an impact to the resulting performance values and the composition function is represented by a SymTA/S analysis. For more information see https://robmosys.eu/wiki/baseline:environment_tools:smartsoft:smartmdsd-toolchain:cause-effect-chain:start?s=symta. At the moment, all those relevant aspects are explicated in separate meta-models and the concrete models must be specified manually using an own DSL. Hence, this building block represents a placeholder at the moment. We need domain-specific extensions in the future to generate models for performance analysis from all the relevant dependencies and to execute them automatically as part of the global NFCC resolution process. Nevertheless, we can again explicate absolute values here and make them consistent with an appropriate precondition. For example: A user of this system with the same CPU can rely on the values when using a specific configuration setting for which the values were determined and must not perform a separate analysis. Note, that the output ports of both properties (response time/cpu utilization) will provide vectors (two values) because they depend on the execution times of the two available navigation strategies in the ObstacleAvoidance.
This is the place where we model the max cpu load variation point. We define the CPU Utilization property as the relevant dependency and simply set the variation point to this value (they have the same unit). It is not a problem that CPU Utilization is actually a vector of values because the generation and resolution process will take care that the assignment always refers to the current instance under evaluation. This leads to the advantage that the robot will adapt its CPU load to exactly the value that is necessary to fulfill the requirements of the current selected execution variant. Hence, the robot will save resources automatically that are not required in certain situations. Note, that this is a special Variation Point in contrast to the others, because it depends directly on the outcome of another non-functional resource and has no independent evaluation path for its scope.
This building block is responsible to provide relevant context data for the NFCC or at least to link to the providing source. The following context data are relevant for our example:
Domain-specific context information and their properties needs to be investigated and can then be standardized within an ecosystem. For example, there may be standardized definitions and models that describe all relevant information about the assembly of the robot. From that we can finally retrieve the mentioned laser mount height.
This building block represents the overall functionality of driving from one start location to a goal location at the process level. It is a more abstract building block because it is a composite realization of the functional components. It follows, that the non-functional aspects modeled in this non-functional building block container are equally more abstract. We consider the following non-functional poperties:
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.
We assume that non-functional requirements can be specified by the designer at design-time and can later be adapted by the the enduser at run-time within allowed limits. Safety constraints defined at design-time will typically have priority. The possible definable constraints depend on the properties that are represented as absolute values in our model. In this example, the designer specifies a maximum constraint value for the property BrakingDistance that depends on the current daytime. He also specifies initial preferences for the conflicts but they can be changed dynamically at run-time according to individual requirements of endusers. An enduser is either a person that directly specifies the requirements or a higher-level planning system that determines local requirements from global requirements and the current execution context. For example: Assume, we have a prediction model for the time property of this skill (i.e. it is represented in an absolute form). The GOTO skill is part of a task (e.g. Get object) to which an end-to-end (global) constraint was formulated (e.g. finish task within x minutes).