A Component-Definition Metamodel is one of the core composition structures of RobMoSys.

The Component Metamodel (shown in the figure below) combines two complementary concerns namely structure and interaction. Individual blocks define the main entities of a component (including the component root element itself, highlighted with the yellow background color). For specifying structure, the blocks are connected using either the contains or the has-a relation (as defined in block-port-connector). For specifying interaction, the blocks are additionally connected using dedicated ports, connectors and connections (as also defined in block-port-connector). Moreover, two blocks (highlighted with the gray background color and dashed border-line) represent model elements that are defined in a separate metamodel (described in the next pages).

A component contains one Parameter structure, one Lifecycle state automaton and has-a Behavior Interface. The Parameter structure can be a Metamodel (or a DSL) by itself and the Behavior Interface allows run-time coordination and configuration from a higher robotics behavior coordination layer (see JOSER2016¹⁾ for further details on both elements). The Lifecycle state automaton coordinates the different operational modes of a component. Some generic modes are for example Init, Shutdown and Fatal-Error (see TR2011²⁾ for more details).

The next core element of a Component is the Activity which is an abstract representation of a thread. A Component can define several Activities (depending on the component-internal functional needs). An Activity is independent of a certain thread realization and can be later mapped to a certain implementation by the selection of an according target platform. Moreover, an Activity provides a wrapper for the Functions. This is important for gaining control over execution characteristics of a component. This also considerably increases the flexibility (i.e. adjustability) of the component with respect to adapting the component to the different needs of various (at this point even unforeseen) systems.

A Function represents a functional block that can be designed using any preferred engineering methodology. From the component's internal point of view, a Function needs to be integrated into an Activity in order not to prematurely define any computational models that are not really relevant from the local functional point of view but might considerably restrict the compositionality of this component in different systems (see SIMPAR2016³⁾ for an example). In some cases, a Function might need to interact with specific hardware devices (such as e.g. sensors or actuators).

The last element of a Component is a Service. A Component can have several required and/or provided Services. A Service is the only allowed interaction point of a component to interact with other (not yet known) components. The definition of a service is described in a separate metamodel. Moreover, a Function interacts with the component's services over the surrounding Activity only. Again, this is important to gain control over execution characteristics as argued above.

See next:

• System Service Architecture Metamodel
• System Component Architecture Metamodel

See also:

• Service-Definition Metamodel
• Communication-Pattern Metamodel
• Component Development View