Using the System Activity Architecture and Cause-Effect Chains

This HowTo describes the creation and usage of the “ActivityArchitecture” model and a “Cause-Effect-Chains” model in a System project within the SmartMDSD Toolchain v3. Further background information for the overall Cause-Effect-Chains ideas can be found here in the RobMoSys Wiki page on Cause-Effect-Chains.

The latest SmartMDSD Toolchain release supports the modeling of performance-realted attributes at two levels:

1. During component definition, performace-related attributes, like for instance periodic timers as default activation source for activities, can be directly modeled as part of the component model itself.
2. During system composition, two new (experimental) DSLs allow the adjustment of performace-related attributes for all defined and instantiated components of a SystemComponentArchitecture. This section hereafter describes how to get started with modeling the system-related performance attributes.

The SystemActivityArchitecture DSL is an experimental language that can already be used to specify and modify performance-related properties for all components of a SystemComponentArchitecture. In the current SmartMDSD Toolchain release, only a textual model editor is provided and the new model type is not automatically geenrated by default (but can be easily created manually, as shown below). If no SystemActivityArchitecture model is defined for the current system, then the system uses the default values from the component models, so the system can also be used without further refinements (if the default values are sufficient).

In this HowTo we will use the existing System for TiagoNavigation that can be downloaded online from here:

https://github.com/Servicerobotics-Ulm/SystemRepository/tree/master/SystemTiagoNavigation

In this example we will provide a custom configuration of performance attributes for the two components SmartGazeboBaseServer and SmartCdlServer. The first step is to create a SystemActivityArchitecture model for an existing system as follows:

1. Select the model folder of your system project in the Model Explorer view
2. Use the Eclipse menu: File → New → File
3. Provide the model file name, e.g.: SystemTiagoNavigation.activityArch (use your system name, but keep the file extension)

The new SystemTiagoNavigation.activityArch model is emtpy at the beginning and you can start specifying the activity configurations independently of the SystemComponentArchitecture. This has the advantage that you can specify your performance attributes upfront and then link it to a specific system afterwards.

The model for our SystemTiagoNavigation.componentArch can look as follows:

SystemTiagoNavigation.activityArch

ActivityArchitectureModel SystemTiagoNavigation {
	CPUCore CPU1 {
		coreNumber 1
	}
 
	ActivityNode BaseOdom {
		activationSource PeriodicTimer {
			periodicActFreq 10.0 Hz
		}
		cpuAffinity CPU1
		executionTime {
			maxTime 150 us
			minTime 100 us
		}
		scheduler {
			priority 1
			type DEFAULT
		}
	}
 
	InputHandlerNode NavVel {
		input TriggerInputNode nv
		prescale 1
	}
 
	ActivityNode Laser {
		inputs {
			RegisterInputNode Odom 
		}
		activationSource Sporadic {
			minActFreq 37.5 Hz
		}
	}
 
	ActivityNode CDL {
		inputs {
			TriggerInputNode Laser
		}
		activationSource DataTriggered Laser {
			prescale 1
		}
	}
 
	ActivityNode Mapper {
		inputs {
			TriggerInputNode Laser
		}
		activationSource DataTriggered Laser {
			prescale 10
		}
	}
 
	ActivityNode PathPlanner {
		inputs {
			TriggerInputNode Map
			TriggerInputNode Odom
		}
		activationSource DataTriggered Map { prescale 1}
	}
 
	DataFlow {
		source BaseOdom destination Laser.Odom
	}
	DataFlow {
		source Laser destination CDL.Laser
	}
	DataFlow {
		source CDL destination NavVel.nv
	}
 
	DataFlow {
		source Laser destination Mapper.Laser
	}
	DataFlow {
		source Mapper destination PathPlanner.Map
	}
	DataFlow {
		source BaseOdom destination PathPlanner.Odom
	}
}

Here we specify several activity-nodes with data-flows in between, and provide respective configuration options. At this point these configurations are virtual and not yet connected to our system. The mapping of the virtual configurations to the actual component elements is done within the SystemTiagoNavigation.componentArch (please note the different file ending). The SystemTiagoNavigation.componentArch can now be modified such that the component's actual activities are mapped to the above provided configurations as follows:

	ComponentInstance SmartCdlServer instantiates SmartCdlServer
	{
		RequiredService LaserClient
		RequiredService PlannerClient
		RequiredService BaseStateClient

		RequiredService NavVelSendClient

		ParameterStructInstance SystemTiagoNavigation.SmartCdlServer

		// map the component's activity named CdlTask to a performance configuration named CDL
		Activity CdlTask configuration CDL;

	}
	ComponentInstance SmartGazeboBaseServer instantiates SmartGazeboBaseServer
	{
		ProvidedService BaseStateServiceOut
		ProvidedService LaserServiceOut
		ProvidedService NavVelServiceIn

		InputHandler VelocityInpuHandler configuration NavVel

		// map the component's activity named LaserTask to a performance configuration named Laser
		Activity LaserTask configuration Laser
	}

Please note the new tags in the model named Activity which specify the mapping from a component's activitsy to a performance configuration (which is an ActivityNode in our previous model). The provided custom performance configurations are considered by the system deploment generator that respectivelly generates the component ini files and start-scripts.

The Cause-Effect-Chain model is an another system model type that allows to specify overall end-to-end latency requirements such as e.g. the overall system's reaction time from when a new laser scan is recodered, over the calculation of a reasonable obstacle avoidance movement, down to the actual commanding of this avoidance movement to the robot's wheels. This overall reaction time can be specified within as an overall system requirement within the Cause-Effect-Chains model, which by itself is used as source to trigger a Compositional Performance Analysis (CPA) using an external tool sich as e.g. SymTA/S.

The Cause-Effect-Chain model can be manually created within a system project as follows:

1. Select the model folder of your system project in the Model Explorer view
2. Use the Eclipse menu: File → New → File
3. Provide the model file name, e.g.: SystemTiagoNavigation.causeEffectChain (use your system name, but keep the file extension)

Here we use the SystemTiagoNavigation system example complementary to the SystemActivityArchitecture as described in the preceding section. The respective model can look as foolws:

SystemTiagoNavigation.causeEffectChain

CuaseEffectChainModel SystemTiagoNavigation refinesActivityArch SystemTiagoNavigation {
	ActivityChain FastReactiveNavigationLoop {
		chainLinks { 
			act.SystemTiagoNavigation.BaseOdom 
			-> act.SystemTiagoNavigation.Laser 
			-> act.SystemTiagoNavigation.CDL
			-> hnd.SystemTiagoNavigation.NavVel
		}
		desiredMaxResponse 500 ms;
		desiredMinResponse 300 ms;
	}
}

Please note, that the Cause-Effect-Chain DSL is a technology demonstration in the current stable SmartMDSD Toolchain release. The connection to the SymTA/S analysis tool is not yet included in the current stable SmartMDSD Toolchain release. If you are interested in a fully fledged demonstration of the future capabilities that will be available in upcoming releases, you can already now have a look into our recent SmartMDSD Toolchain v3 (Technology Preview) that can be downloaded along with a full example from 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 latest migration status of the Cause-Effect-Chain functionality is provieded here: Cause-Effect-Chains in RobMoSys Wiki