This page uses the SmartMDSD Toolchain to illustrate the Management of Cause-Effect Chains in Component Composition. Therefore, the Gazebo/TIAGo/SmartSoft Scenario is used as an example.

The figure below shows a schematic illustration of the Gazebo/TIAGo/SmartSoft Scenario consisting of navigation components altogether providing collision-avoidance and path-planning navigation functionality. This example is used in the following to discuss different aspects related to managing cause-effect chains which are again related to managing performance-related system aspects.

The example system in the figure above consists of five navigation components, from which two are related to hardware devices (i.e., the Pioneer Base and the SICK Laser) and the other three components respectively implementing collision-avoidance (i.e., the CDL component), mapping and path-planning. As an example, two performance-related design questions are introduced in the following with the focus on discussing the architectural choices and the relevant modeling options:

1. How fast can a robot react to sudden obstacles taking the current components into account?
2. How often does the robot need to recalculate the path to its current destination (thus reacting to major map changes)?

The design and management of performance-related system aspects can be approached from two different viewpoints. On the one hand, individual components can specify implementation-specific configuration boundaries (as shown in the example below). On the other hand, a system that instantiates relevant navigation components can refine their configurations (within the predefined configuration boundaries) to meet application-specific performance requirements (see next section).

The figure above shows the model of the “SmartPlannerBreadthFirstSearch” component as a representative example for demonstrating the role of the Component Supplier. The responsibility of this role is to define and to implement a component so that it can be (re-)used in different systems. Among other things, the component supplier also is responsible to define component-specific, performance-related constraints (if the internal business logic of this component requires specific execution characteristics). For example, the planner component (in the figure above) specifies that the “PlannerTask” should be executed with an update frequency within the boundaries from 2.0 to 10.0 Hertz and that the actual update frequency can be configured within these boundaries during a later system configuration phase.

• Component Development View
• Component Supplier Role
• Component Definition Metamodel

The figure below shows an example model of the navigation scenario. This model enables System Builders to instantiate and compose components to a system and to specify initial wiring as well as initial configurations of these components.

• System Configuration View
• System Builder Role
• System Component Architecture Metamodel

A given system (as e.g. shown in the previous section) can be refined so that performance-related configurations are designed in combination, which is the main responsibility of the Performance Designer (as discussed next).

A performance designer refines the configurations of activity models from the selected components of the system configuration view (see preceding section). Therefore, several activities are considered in combination and the component shells are blended out (as they are not relevant for this performance view). The figure above illustrates the transformation from a system-configuration model to an activity-net.

The transformation of a system-configuration model of the navigation scenario into an activity-net results in the model shown in the above figure. In this model individual activity nodes (orange blocks in the figure) can be refined by selecting reasonable activation semantics (i.e., selecting a DataTrigger or a PeriodicTimer as an activation-source for an activity node). Overall, an activity-net forms a directed graph with several paths sometimes crossing the same activity nodes.

In order to specify end-to-end delays, individual (acyclic) paths of the overall activity-net need to be selected. Such paths are called cause-effect chains and are visualized by the three rectangles in the above figure on the right. For each of these cause-effect chains individual end-to-end delay requirements can be specified. These end-to-end delay specifications can be now easily verified by triggering an automated performance analysis (see next).

• Performance View
• Performance Designer Role
• Cause-Effect-Chain and its Analysis Metamodels

Based on the performance model (from the preceding section) a compositional performance analysis can be automatically triggered which simulates different run-time conditions including scheduling and sampling effects. This analysis allows verifying the specified end-to-end delays and based on the results to refine the performance model.

As an example, the figure above shows the results of the compositional performance analysis which is calculated using the SymTA/S timing analysis tool from Luxoft (formerly Symtavision). The results show for the cause-effect chain called “FastReactiveNavigationLoop” that the distribution of the overall end-to-end delays is within the specified requirements defined in the performance model.

See also:

• Managing Cause-Effect Chains in Component Composition
• Architectural Pattern for Stepwise Management of Extra-Functional Properties
• Cause-Effect-Chain and its Analysis Metamodels
• Tutorial on Cause-Effect-Chains and Activity Architecture

Tutorial on Cause-Effect-Chains and Activity Architecture

The above described example is developed with the SmartMDSD Toolchain V3 (Technology Preview) whose implementation (together with the presented example) can be found on SourceForge. Please note that the features from the Technology Preview are currently under migration into the newest stable SmartMDSD Toolchain release (see SmartMDSD Toolchain Vendor Website and in the RobMoSys Wiki).

The following features from the Technology Preview have already been migrated into the latest stable SmartMDSD Toolchain release:

If you are interested in understanding all the details of the cause-effect chain approach or to exactly reproduce the presented example, then please use the technology preview. If you are interested in the development of new systems using stable tooling, then please use our latest stable SmartMDSD Toolchain release, where you can already now develop the cause-effect models textually (which serves as a basis also for the graphical notations that will be added in one of the upcoming releases). Moreover, we are currently exploring different options for open-source model analysis tools that we can use in the same way as SymTA/S. If you have questions, ask them at Discourse Forum.

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.