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.

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.