Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Papyrus/customizations/robotics"

(System Builder (Tier 3))
Line 91: Line 91:
  
 
<center>
 
<center>
[[Papyrus-customizations-robotics-SimpleExampleParametersInstance.png]]<br/>
+
[[Image:Papyrus-customizations-robotics-SimpleExampleParametersInstance.png]]<br/>
 
Re-Configuration of AcmeMapper Instance
 
Re-Configuration of AcmeMapper Instance
 
</center>
 
</center>

Revision as of 12:05, 1 February 2019

The Papyrus for Robotics customizations supports the creations of models that are compliant with the RobMoSys approach.

Getting started

Papyrus for Robotics comes with installed examples to get you started. To run the example, just click New->Example and accept the default propositions in the wizard. The examples are called Robotic examples in the category Papyrus example

width=1024px
Run the simple example that comes along with Papyrus for Robotics

The Example Explained

Introduction

This example shows how Papyrus4Robotics supports the service-based approach for the composition of software components.

Composition in an Ecosystem organized in tiers is the approach adopted by RobMoSys to system integration. Next sections discuss how tier 2 and tier 3 participants use Papyrus4Robotics to model a simple service-based composition of a mapper component and a planner component.

The illustration below corresponds to the role descriptions, as taken from the RobMoSys wiki.

width=900px
Roles and interactions in a service-based composition of software components

Domain Expert (Tier 2)

Tier 2 are robotics experts who define a //complete// characterization of services in robotics domains, e.g., mapping, planning, localization, etc. Tier 2 structures each robotics domain by creating domain-models that cover a number of aspects, including data structures and communication semantics. Service designers are the domain experts on Tier 2 that design individual service definitions for use by Tier 3.

The picture below shows a portion of data structures defined for the mapping domain in this example.

width=800px
Model of data types for the robotic mapping domain

Papyrus4Robotics leverages concepts from MARTE] NFP and VSL profiles to comply with RobMoSys' specifications on digital data representation. Built-in type definitions can be imported from the BasicNFP_Types MARTE library and specialized for a specific domain by using a dedicated palette (right side of the picture). Leveraging on MARTE, **Papyrus4Robotics supports physical units descriptions** to formally define unambiguous semantics of units of measurements in data types.

Once the communicated data structures (Communication Objects, identified with the CO icon on the top left corner) are defined, the communication pattern usage can be formalized. The next picture shows the model that describes the MappingSdef service. In this example, MappingSdef uses the Push pattern and selects the Map data type as communicated data structure. Please note that it is possible to toggle between ``normal data types and communication objects via the context menu.

Papyrus-customizations-robotics-SimpleExampleServiceDef.png
Model of service definition for the robotic mapping domain}}

Component Suppliers (Tier 3)

Component suppliers at Tier 3 provide models of software component definitions.

AcmeMapper

The model below shows a mapper component developed by a company called AcmeCorp (hence AcmeMapper), which provides a fully compliant implementation of the MappingSdef service definition above.

Papyrus-customizations-robotics-SimpleExampleComponentDef.png
Model of mapper that is fully compliant to MappingSdef

The example focuses on the modeling of a single component port (pMap) providing the mapping service. Aligned with the standard UML rules of interface realization, this is achieved by assigning the port a ComponentService item as a type (AcmeMapCS) that realizes MappingSdef.

AcmeMapper contains one Parameter structure, that represents a set of parameters that make the component configurable for reuse in different scenarios by the system builder or even at run-time. The Parameter structure content is visualized in the model editor by selecting the Paramter icon and the Parameters Settings tab in the property view (see below). The selected parameter block has been moved in the screenshot below to keep image dimensions relatively small.

Papyrus-customizations-robotics-SimpleExampleParameters.png
Visualization of parameter set of AcmeMapper

In this simple example, AcmeMapper has 2 configurable parameters with built-in types. However composite value specifications (collection, tuple, choice, etc.) can be specified as well, using the MARTE VSL syntax.

AcmeMapper defines one activity (it could define more), which is a OS-agnostic representation of a thread. Activities provide wrappers for functions (algorithms). Activities do have set of parameters for configuration (e.g., inter-arrival range, that is max and min activation frequencies). Similarly to component parameters, activity paramters can be viewed and set through the Parameters Settings tab in the property view.

EmcaPlanner

The model has a planner component developed by a company called EmcaInc (hence EmcaPlanner), not shown here.

The example focuses on the definition of two component ports. pPlan **provides** a implementation of PlanningSdef (a planning service definition model not discussed in this document). rMap **requires** a fully compliant implementation of MappingSdef. To model the service requirement, in agreement with the standard UML rules, the usage item is used to create a dependency between the EmcaMapCS and MappingSdef.

System Builder (Tier 3)

System builders instantiate component definitions to provide a platform-independent specification of a software system. The model below shows the instantiation and connection of one instance of AcmeMapper and one instance of EmcaPlanner.

Papyrus-customizations-robotics-SimpleExampleAssembly.png
Model of system component architecture

It is now assumed that the mapper component instance must work outdoor. The default configuration of AcmeMapper component definition was indoor, so the component instance m must be re-configured by the system builder.

For a component instance the parameter set is accessible by clicking on the instance itself and selecting the Parameters Settings tab in the property view. The next picture shows the value of indoor parameter is set to false. Yellow highlighting visually enforces the message that the parameter value is now different from the default one.

Papyrus-customizations-robotics-SimpleExampleParametersInstance.png
Re-Configuration of AcmeMapper Instance

Conclusions

This example shows a structural model in the context of composition of software components. It shows how different tiers contribute models to achieve composition of software components, using service-definitions as central architectural element for it. Then it focuses on one instance of the mapper component and shows a simple reconfiguration of one of its parameters.

Do It Yourself

This section is in progress. More content will be added shortly.

Connect ComponentInstance Items

Connections between component instances can be drawn by using the connects item from the system component architecture palette, see previous diagram (Model of system component architecture).

First, select connects from the palette. Then point and click the source and target component ports to be connected. Note that the connection is only possible if

 * both source and target elements are component ports
 * both ports provide/require compatible services. In other words, for 2 connected (component) ports, the type represented by a component service must be //instance-of// the same service definition.

Supported diagrams

Supported diagrams have been shown in the previous section by example. In general

Component definition diagram

A component definition diagram models the internal structure and external interface of a component. The former includes parameters, activities and functions, the latter ports that provide or require services

Service definition

A service definition binds a communication pattern to concrete communication objects, for instance the formal parameter ``Message of a Push pattern is bound to a concrete data type definition.

Datatype definition diagram

This diagram is used to define data types, including potential variability

System assembly

A set of component instances that are ``wired together via their ports. At this level, it is also possible to configure component instances.

Back to the top