Communication patterns define how SmartSoft components communicate with each other. They consist of two complementary parts named service requestor and service provider representing a client/server (e.g. PushNewestClient/PushNewestServer), or, master/slave (e.g. StateMaster/StateSlave) relationship. The various communication patterns are described in section 1.1.3.2. To model a service requestor or service provider add a communication port and, where necessary, a handler to the model. To do so, select the element in the tool palette and click on the component. Afterwards, adjust the properties of the port or handler in the properties tab. The following list presents the individual properties:

event:

push timed:

push newest:

query:

send:

Before a communication object can be assigned to a communication port, it needs to be imported (if not already done). Therefore, right click anywhere inside of the component diagram and select "Import Communication/Coordination Objects". In the next dialog, select the required communication objects and press the OK Button. After the communication object was imported, select the communication port and add the communication object (as shown in figure figure 2.17).

In order to assign a handler to a communication port, the corresponding handler has to be modeled in the component model first (using the tool palette). After that, select the handler parameter in the communication port and press the "..."-Button on the right. In the next dialog select the handler (<component name> -> <component name> -> nestedClassifier -> <handler>) and press the OK button (cf. figure 2.18).

The following settings can be made:

The SmartComponentMetadata has to be added to every component. It contains version and dependency information.

Provides a generic port to set configurations of components at runtime. Typically the master part is used within the sequencer, which is in control and coordinating the system. In total one parameter master can send parameter-sets to several Parameter Slaves. There are three different ways to use the parameter to configure other components (which are encoded in the CommParameterRequest):

The slave part of the parameter is used when your component is subject to configuration by other components at run-time. The user needs at most one instance of the parameter slave per component.

The SmartComponentParameter is used to model the parameters. The elements are defined in a parameterDefinition. The parameterDefinition can be modified with the SmartParameterEditor which is to the right of the properties tab. To open the parameterDefinition in the editor click on the SmartParameterEditor tab and then on the SmartComponentParameter.

The parameters are modeled as follows:

	Component <name> {
		<parameter>
	}
						

At first the component of the SmartComponentParameter is defined. The name must match the name of the component in which the SmartComponentParameter is modeled. Inside the component internal parameters, extended parameters, extended trigger and parameter set instantiations are defined.

Internal parameters are modeled as follows:

	InternalParam <name> {
		<name> : <data type> = <value>
	}
						

The keyword 'InternalParam' is used to define an internal parameter. After the keyword the name of the internal parameter is given. This name should start with a capital letter. The attributes of the internal parameter are enclosed by curly braces. They consist of a name and a data type. The attributes must be assigned with a default value. Possible data types are:

Additionally, lists of these data types can be used.

If, for example, the maximum velocity and steering should be defined with parameters, the internal parameter can be defined as follows:

	InternalParam settings{
		max_velocity : Double = 1.0
		max_steering : Double = 1.2
	}
						

Extended parameters are modeled as follows:

	ExtendedParam <name> {
		<name> : <data type> = <value>
	}
						

Extended parameters are defined with the keyword 'ExtendedParam'. After the keyword the name of the extended parameter is given. The name should start with a capital letter. The attributes of the extended parameter are enclosed by curly braces. They consist of a name, a data type and a default value. The possible data types are similar to the data types of internal parameters.

Extended trigger are modeled as follows:

	ExtendedTrigger <name> (active|passive) {
		<name> : <data type>
	}
						

The keyword 'ExtendedTrigger' is used to define extended trigger. After the keyword the name of the extended trigger followed by the keyword 'active' or 'passive' is given. The attributes of the extended trigger are enclosed by curly braces. They consist of a name and a data type. The data types are similar to the data types of internal parameters.

As mentioned before, parameters can be defined outside of the component and can be reused. For that purpose the model of the parameter set has to be imported first:

	ImportUri <path>
						

The parameter set is then instantiated as follows:

	ParamSetInstance <repository>.<param set name> {
		InstantiateTrigger <trigger name> (active|passive)
		InstantiateParam <parameter name> {
			this.<attribute name> = <value>
		}
	}
						

The instantiation of a parameter set is defined with the keyword 'ParamSetInstance' followed by the repository and name of the imported parameter set. The parameters and trigger which should be instantiated are enclosed by curly braces. Trigger are instantiated with the keyword 'InstantiateTrigger' followed by the name of the trigger and either the keyword 'active' or 'passive'. Parameters are instantiated with the keyword 'InstantiateParam' followed by the name of the parameter and the attributes which are enclosed by curly braces. The attributes which should be assigned with a value are selected with the this-operator.

An example of the instantiation of a Parameter set can be found in the component SmartCdlServer:

	ImportUri "platform:/resource/CommNavigationObjects/model/parameter/CommNavigationObjects.pardef"

	Component SmartCdlServer {
		ParamSetInstance CommNavigationObjects.CdlParameter {
	 		InstantiateTrigger SETSTRATEGY passive
			InstantiateParam PATHNAVFREEBEHAVIOR{this.free = enum.DEACTIVATE}
	 	}
	}
						

In this example the passive trigger SETSTRATEGY and the parameter PATHNAVFREEBEHAVIOR are instantiated.

Please refer to the chapter of component implementation and the tutorial to see how these parameters are used from within the component implementation.

In addition attributes of parameters, extended parameters, extended trigger, instantiated parameters and instantiated triggers can be documented. This can be done in the SmartParameterEditor by writing the '@doc' keyword followed by a String on top of the attribute, parameter or trigger. The documentation of the attributes max_velocity and max_steering of the internal parameter settings for example can be added as follows. Use this within the parameter modeling.

	// Parameter within the component
	InternalParam settings{
		@doc"Defines the maximum velocity. This is the velocity [m/s] which will be sent when the joystick axis is at full peak."
		max_velocity : Double = 1.0
		
		@doc"Defines the minimum steering angle. This is the angle [rad] which will be sent as omega when the joystick axis is 
			at full peak."
		max_steering : Double = 1.2
	}