Papyrus/customizations/robotics/servicedef

Service definition (Tier 2)

A service definition is a tier-2 activity, i.e. an activity that is typically done by a domain expert. The objective is to define common service definitions usable across several projects and service definitions. These service definitions are typically structured in specific robotics domains such as mapping, planning, localization. If ROS is targeted, the ROS message and service definitions that are shipped with a distribution are a de-facto standardization of these service definitions and available in Papyrus for Robotics as a set model libraries. However, it is sometimes necessary to define new service definitions.

Service definitions reference one of the 4 communication patterns identified in RobMoSys. Depending on the communication pattern, a service definition needs to reference one or more communication objects, i.e. the object(s) that are exchanged by an interaction. This is outlined in the following for each pattern.

• Push: a single "message" element
• Send: a single "message" element
• Query: a "request" message and a corresponding "reply" message
• Event: a "message", a "parameter" and a "state" object

For more details, see [communication pattern] (and ROS2 for information related to ROS2 code generation).

You can create a service definition with Papyrus for Robotics in a specific service definition model. Then use the palette to create a new service definition. The tool will prompt you for the different communications objects. These are either already defined in another service definition model or the edited service definition model itself..

Data Type / Communication object definition

Papyrus-for-Robotics allows the user to define his own communication objects and data types. Both have a set of typed attributes. The only difference is that communication objects can directly be referenced from service definitions. In order to avoid duplicates, the palette of the diagram only enables the creation of the different data-type variants. At any moment, a data-type can be converted into a communication object and vice versa, as shown in the following dialog.

How to edit

It is recommended to use a textual editor for editing the data types. This editor is available via the F2 short-cut or inside the property view (the latter is recommended, since the editors directly in the diagram use a constraint area).

As shown below, Papyrus offers an xtext editor provided content assist (control-space) and validation. If the validation does not pass, the editor contents is stored in an annotation awaiting corrections. The user can specify attributes along with their type and a comment which becomes part of the attribute's description. In order to obtain completion assistance, write the prefix of package containing the type (but please note that this only covers models already loaded into the resource set - use the type selection attribute to load additional registered models).

Textual editor for communication objects, data types and enumerations