baseline:environment_tools:smartsoft:smartmdsd-toolchain:cause-effect-chain:start

Support for Managing Cause-Effect Chains in Component Composition

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.

Example Use-Case for Managing Cause-Effect Chains

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 component development view

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.

The system-configuration view

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.

The performance view

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 Analysis based on SymTA/S

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:

Video

Tooling Support and Roadmap

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:

Feature Migration Status in stable release
Textual Grammar migrated
Graphical Notation under migration
Deployment Integration migrated
Model Generation for SymTA/S under migration

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.

Acknowledgement

baseline:environment_tools:smartsoft:smartmdsd-toolchain:cause-effect-chain:start · Last modified: 2019/05/20 10:52
http://www.robmosys.eu/wiki/baseline:environment_tools:smartsoft:smartmdsd-toolchain:cause-effect-chain:start