2.3.2. Component Modeling

The Component model is part of a SmartSoft Component project and is located in the model-folder.

2.3.2.1. Component Hull

The component hull is modeled graphically. The model consists of a component which provides and requires services in order to interact with other components and contains tasks, timers and parameters to implement a specific functionality. The various elements of the component are displayed in the tool palette of the SmartMDSD Toolchain. In order to add an element to the component, the element has to be selected in the tool palette and then to be added to the component-diagram by clicking into it. The properties of the various elements can be adjusted in the properties tab if the element is selected in the model. To delete a model element right click on the element and choose "Delete Selected Element". Do not use the delete key on your keyboard to delete model elements. Due to a double assignment of the delete key the elements may be hidden instead of deleted. Figure 2.16 illustrates the modeling of the component hull with the SmartMDSD Toolchain.

Modeling Component Hull

Figure 2.16. Modeling Component Hull


2.3.2.1.1. Communication Patterns

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:

  • SmartEventServer:

    • eventState: Defines the communication object of the event state, which is used by the SmartEventTestHandler (see below) to check the event parameter.

    • smartEventTestHandler: Defines the SmartEventTestHandler which is used to check wether an event fires according to the client-specific eventParameter (see next).

    • eventParameter: A client registers to an EventServer with an event activation parameter. The eventParameter defines the communication object of this event activation parameter to be used within the SmartEventTestHandler (above). The communication object must match the communication object of the eventParameter of the SmartEventClient (see below).

    • eventResult: Specifies the communication object of the event result, which is the actually communicated event with according data-payload.

  • SmartEventClient:

    • smartEventHandler: Defines the SmartEventHandler which is used as a callback-handler to receive the event results.

    • serverName: Specifies the name of the component that provides the event result. (This value is refined during system configuration (see section 2.4.2) and can therefore be left blank.)

    • wireable: Defines whether or not the port can be wired dynamically (using the Wiring pattern).

    • serviceName: Specifies the name of the SmartEventServer. (This value is also refined during system configuration (see section 2.4.2) and can therefore be left blank.)

    • eventParameter: Defines the communication object of the event parameter. The client registers with an event parameter to the SmartEventServer in order to parametrise the server-side event-filter (implemented inside of the according SmartEventTestHandler in the server). This allows to specify events of interest and reduces unnecessary communication overhead.

    • eventResult: Specifies the communication object of the event result.

push timed:

  • SmartPushTimedHandler: is a call-back handler used by SmartPushTimedServer to periodically publish updates.

    • isActive: Specifies whether the SmartPushTimedHandler is active or passive. If the handler is set passive, the processing of incoming requests is driven by the upcalling thread of the SmartPushTimedServer. A passive handler should avoid using blocking system-calls (such as e.g. sleeps, waits, smeaphores, condition variables, etc.).

  • SmartPushTimedServer:

    • timeUnit: Specifies the time unit of the cycle decorator (s, ms, us or ns).

    • cycle: Specifes the time interval at which new data is provided.

    • smartPushTimedHandler: Specifies the SmartPushTimedHandler which is used to periodically send data.

    • commObject: Specifies the communication object which is send to a client.

  • SmartPushTimedClient:

    • interval: It is possible to get every n-th update to reduce unnecessary communication overhead. The prescaler of the server cycle is specified with this parameter.

    • serverName: Specifies the name of the component which provides the data. (This value is refined during system configuration (see section 2.4.2) and can therefore be left blank.)

    • wireable: Defines whether or not the port can be wired dynamically (using the wiring pattern).

    • serviceName:Specifies the name of the SmartPushTimedServer. (This value is also refined during system configuration (see section 2.4.2) and can therefore be left blank.)

    • commObject: Specifies the received Communication Object. The communication object must match the communication object which is send via the SmartPushTimedServer.

push newest:

  • SmartPushNewestServer:

    • commObject: Specifies the communication object which is published to all subscribed clients.

  • SmartPushNewestClient:

    • serverName: Specifies the name of the component which provides the data. (This value is refined during System Configuration (see section 2.4.2) and can therefore be left blank.)

    • wireable: Defines whether or not the port can be wired dynamically (using the Wiring pattern).

    • serviceName: Specifies the name of the SmartPushNewestServer. (This value is also refined during system configuration (see section 2.4.2) and can therefore be left blank.)

    • commObject: Specifies the received communication object. The communication object must match the communication object which is published from the SmartPushNewestServer.

query:

  • SmartQueryHandler: is a callback handler used by SmartQueryServer to process incomming queries.

    • isActive:Specifies whether the SmartQueryHandler is active or passive. If the handler is set passive, the processing of incoming requests is driven by the upcalling thread of the SmartQueryServer and thus should avoid any blocking calls.

  • SmartQueryServer:

    • smartQueryHandler: Specifies the upcall-handler reference (SmartQueryHandler, see above) to process incomming query requests.

    • commRequestObject: Specifies the request communication object.

    • commAnswerObject: Specifies the response communication object.

  • SmartQueryClient:

    • serverName: Specifies the name of the component which provides the according QueryServer. (This value is refined during system configuration (see section 2.4.2) and can therefore be left blank.)

    • wireable: Defines whether or not the port can be wired dynamically (using the Wiring pattern).

    • serviceName: Specifies the name of the SmartQueryServer. (This value is also refined during System Configuration (see section 2.4.2) and can therefore be left blank.)

    • commRequestObject: Specifies the communication object of the request.

    • commAnswerObject: Specifies the communication object of the response.

send:

  • SmartSendHandler: is a callback handler used by SmartSendServer to process incomming sends.

    • isActive: Specifies whether the SmartSendHandler is active or passive. If the handler is set passive, the processing of incoming requests is driven by the upcalling thread of the SmartSendServer and thus should avoid any blocking calls.

  • SmartSendServer:

    • smartSendHandler: Specifies the smartSendHandler which is implements the callback to receive and to process incoming data.

    • commObject: Specifies the communication object of the received data.

  • SmartSendClient:

    • serverName: Specifies the name of the component which receives the send data. (This value is refined during system configuration (see section 2.4.2) and can therefore be left blank.)

    • wireable: Defines whether or not the port can be wired dynamically (using the Wiring pattern).

    • serviceName: Specifies the name of the SmartSendServer. (This value is also refined during system configuration (see section 2.4.2) and can therefore be left blank.)

    • commObject: Specifies the communication object which is 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).

Select Communication object

Figure 2.17. Select Communication object


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).

Select handler

Figure 2.18. Select handler


2.3.2.1.2. SmartTask

The following settings can be made:

  • timeUnit: Specifies the time unit of the period decorator (s, ms, us or ns).

  • isPeriodic: Specifies whether or not the Task is called periodic in a specified time interval.

  • period: Specifies the time interval at which the task is called.

2.3.2.1.3. SmartComponentMetadata

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

2.3.2.2. Component Parameters

There are two main types of parameters. There are parameters to configure a component initially at system-configuration / deployment time but not during runtime. Then there are parameters that can be used to configure a component intially and at run-time.

Parameters can be defined within the component (component internal) and outside of the component (component external) for reusing the definitions in multiple components. Parameters that can be set at run-time can be defined with the keyword ExtendedParam within the component or reuse existing definitions with the keyword ParamSetInstance. Parameters that can only be set initially can be defined within the component using the keyword InternalParam. They cannot be defined outside of the component.

A component that can be configured at run-time needs a SmartParameterSlave service. A component configuring other components does this via the SmartParameterMaster.

2.3.2.2.1. SmartParameterMaster

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):

  • Simple parameters such as SETPOSE(x,y) CHANGEMAP("MapName"), ... - these are name-value configurations

  • Triggers - used to trigger/start actions or activities

  • COMMIT - a special kind of trigger that tells a component that a sequence of configurations is complete and the component can from now on use the consistent set of new parameters.

2.3.2.2.2. SmartParameterSlave

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.

2.3.2.2.3. SmartComponentParameter

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.

Model Component parameter

Figure 2.19. Model Component parameter


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:

  • Boolean

  • Double

  • Enum

  • Float

  • Int8, Int16, Int32, Int64

  • String

  • UInt8, UInt16, UInt32, UInt64

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.

2.3.2.2.4. Parameter Documentation

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
	}
					

WordPress Appliance - Powered by TurnKey Linux