Besides of “pure” functions, realistic systems also need to specify and to manage extra-functional properties that might involve different system parts at different levels of abstraction. Extra-functional system properties specify how well a system performs given a certain system configuration.

There are two main developer roles that are involved in the specification of extra-functional properties:

• Component Supplier specifies functional constraints of individual building blocks (i.e. components)
• System Builder defines extra-functional properties within the predefined boundaries by the involved components

Extra-functional properties are cross-cutting in nature (i.e. combining communication, computation and coordination) and relate to several levels of abstraction:

• Task Plot (level) provides the run-time context for the extra-functional properties
• Service (level) link components and is mainly related to the communication concern of extra-functional properties
• Function (level) is related to the computation concern of extra-functional properties
• Execution Container (level) relates to the coordination concern of extra-functional properties
• Hardware (level) finally does both, computation and communication of extra-functional properties

• Extra-functional system properties such as e.g. end-to-end response times are cross-cutting in nature and typically involve knowledge and contributions from different developer roles (e.g. component developers and system builders) who are often working independently in different places and at different points in time. This easily leads to inconsistencies in the system. Resolving inconsistencies typically requires expert knowledge and deep insights into all the distributed system parts
• Extra-functional properties bridge between functional constraints in individual building blocks and application-specific system requirements
• Extra-functional properties might be grounded in several system parts that are distributed over several components
• Tracing and assuring extra-functional properties might involve additional (dedicated) analysis tools

• The specification of functional aspects of individual building blocks must be linked with the definition of application-specific, extra-functional system aspects on model level
• Individual building blocks specify functional constraints that restrict the remaining design space to be exploited for a later system design
• System-specification allows only those design options that do not conflict with the individual building-block constraints
• Dedicated analysis tools simulate run-time conditions and predict extra-functional system behavior (i.e. the run-time performance quality of a system)
• Optionally: a run-time monitoring mechanism can assure compliance with specified extra-functional properties

End-to-end response time from sensing until acting in a service robot can be considered as one particular extra-functional property

• this end-to-end response time typically involves several interconnected components forming a data-flow chain of components
• each component in a chain contributes with a certain delay to the overall end-to-end time
• the component’s internal delay might be the result of the internally used device driver with certain execution characteristics or otherwise result from the internally configured activities (i.e. tasks/threads)
• individual components should leave as much configuration freedom as possible and only specify really needed functional constraints (such as an unchangeable device driver behavior)
• a specified system-level end-to-end response time needs to be checked with respect to predefined functional constraints in individual components and the overall end-to-end run-time behavior of the entire chain of components
  • for analysing the run-time behavior of the entire chain of components at design-time, dedicated, matured and powerful analysis tools such as SymTA/S can be used
  • run-time behavior can also be directly monitored in an executed robotic system using a dedicated monitoring infrastructure

This example is described with more details in a dedicated wiki page: Managing Cause-Effect Chains in Component Composition.

Data privacy requirements can be considered as another example of an extra-functional property:

• the navigation system of a hospital robot requires an onboard camera
• the overall robot is composed out of several interconnected components forming different data flows
• the raw camera images make their way through different components
  • all services along a data flow that provide camera images (such as labeled images) are critical with respect to privacy
  • however, camera images can also be used to read door plates. The robot thus can report the room where it is. This does not contain any camera images anymore but just the name of the room. Thus, this service is not critical with respect to privacy
• a system-level privacy requirement might be given as follows:
  • the raw images of a camera must not leave the robot system
• thus, the system builder needs to do the following checks:
  • there must be no data flow from the camera via different components to services accessible from outside that still contain data that is critical with respect to privacy
  • there must be only such services reachable from outside the robot where all the data flows do not come from services considered as critical with respect to privacy
  • all the components that convert “critical data” (consume) into “uncritical data” (provide services) need to be trustworthy (as these connect different criticality regions). Of course, this holds true for any component having at least one (or all) ports dealing with critical data.

This example is described with more details in a dedicated wiki page: Dependency Graphs for System Level Properties.

This document contains material from:

• Lotz2018 Alex Lotz, "Managing Non-Functional Communication Aspects in the Entire Life-Cycle of a Component-Based Robotic Software System", Dissertation, Technische Universität München, München 2018.
• Lutz2017 Matthias Lutz, “Model-Driven Behavior Development for Service Robotic Systems: Bridging the Gap between Software- and Behavior-Models,” 2017. (unpublished work)
• Stampfer2018 Dennis Stampfer, "Contributions to System Composition using a System Design Process driven by Service Definitions for Service Robotics". Dissertation, Technische Universität München, München, Germany, 2018.