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"

(Domain Expert (Tier 2))
(Replaced content with "= Getting started = = Modular and Role based design = = Modeling behaviour (including Hazard and Risk analysis) = Papyrus/customizations/robotics/hara")
Line 1: Line 1:
The Papyrus for Robotics customizations supports the creations of models that are compliant with the [https://www.robmosys.eu RobMoSys] approach.
 
 
 
= Getting started =
 
= 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''
+
= Modular and Role based design =
 
+
<center>
+
[[Image:Papyrus-customizations-robotics-diy-runexample.gif|950px]]<br/>
+
Run the simple example that comes along with Papyrus for Robotics
+
</center>
+
 
+
===== The Example Explained =====
+
 
+
==== Introduction ====
+
 
+
This example shows how Papyrus4Robotics supports the [https://robmosys.eu/wiki/composition:service-based-composition:start service-based approach for the composition of software components].
+
 
+
[https://robmosys.eu/wiki/general_principles:ecosystem:start Composition in an Ecosystem organized in tiers] is the RobMoSys for system integration.
+
The 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.
+
 
+
Although the process implies multiple tiers and stakeholders, the provided example is stored in a single model to keep things simple. For real projects, the different aspects would be stored in multiple models to facilitate collaboration.
+
The illustration below corresponds to the role descriptions, as taken from the RobMoSys wiki.
+
 
+
<center>
+
[[Image:Papyrus-customizations-robotics-Service-based-composition-approach.png|900px]]<br/>
+
Roles and interactions in a service-based composition of software components, see also [https://robmosys.eu/wiki/start RobMoSys Wiki]
+
</center>
+
 
+
==== 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. [https://robmosys.eu/wiki/general_principles:ecosystem:roles:service_designer 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.
+
 
+
<center>
+
[[Image:Papyrus-customizations-robotics-SimpleExampleDataTypes.png|width=800px]]<br/>
+
Model of data types for the robotic mapping domain
+
</center>
+
 
+
Papyrus4Robotics leverages concepts from [https://robmosys.eu/wiki/https://www.omg.org/spec/MARTE/|OMG's 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.
+
 
+
Not all data types are communication objects. 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.
+
 
+
<center>
+
[[Image:Papyrus-customizations-robotics-ToggleCommunicationObject.png]]<br/>
+
Toggle between data-type and communication object
+
</center>
+
 
+
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.
+
 
+
<center>
+
[[Image:Papyrus-customizations-robotics-SimpleExampleServiceDef.png]]<br/>
+
Model of service definition for the robotic mapping domain}}
+
</center>
+
 
+
==== 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.
+
 
+
<center>
+
[[Image:Papyrus-customizations-robotics-SimpleExampleComponentDef.png]]<br/>
+
Model of mapper that is fully compliant to MappingSdef
+
</center>
+
 
+
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.
+
 
+
<center>
+
[[Image:Papyrus-customizations-robotics-SimpleExampleParameters.png]]<br/>
+
Visualization of parameter set of AcmeMapper
+
</center>
+
 
+
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''.
+
 
+
<center>
+
[[Image:Papyrus-customizations-robotics-SimpleExampleAssembly.png]]<br/>
+
Model of system component architecture
+
</center>
+
 
+
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.
+
 
+
<center>
+
[[Image:Papyrus-customizations-robotics-SimpleExampleParametersInstance.png]]<br/>
+
Re-Configuration of AcmeMapper Instance
+
</center>
+
 
+
==== 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 ==
+
= Modeling behaviour (including Hazard and Risk analysis) =
  
A set of component instances that are ``wired'' together via their ports. At this level, it is also possible to configure component instances.
+
[[Papyrus/customizations/robotics/hara]]

Revision as of 05:59, 11 April 2019

Getting started

Modular and Role based design

Modeling behaviour (including Hazard and Risk analysis)

Papyrus/customizations/robotics/hara

Back to the top