SmartMDSD Toolchain User's Manual

This section is under preparation.

This is the SmartMDSD Toolchain User's Manual. The info page on the SmartMDSD Toolchain lists tutorials, How-To's, installation instructions and further material.

If you have specific questions on how to use the toolchain, please write your question in the RobMoSys Community Forum or contact us.

We assume you have set up the SmartMDSD Toolchain using the installer.

For trying out, install the SmartMDSD Toolchain as described, then:

1. Select a new (empty) workspace with an arbitrary location of your choice
2. Close the “Welcome” page that pops up the first time you launch the toolchain.
3. Now you can start creating your own domain models and components or import existing such as the Navigation domain models and components. To do so, you first need to checkout the github repositories (see next section) and then select the Eclipse menu: “File” → “Import…” → “General” → “Existing Projects into Workspace” and click on the “Next” button
4. in the next menu, click onto the “Browse” button to select the folder of your githib checkout and then click on the “Finish” button to import all projects into your workspace

Now you can investigate all the Models of the NavigationStack. There are three types of Projects:

• Projects starting with “Comm…” and “Domain…”: these are Service-related Models (i.e. CommunicationObjects, ServcieDefinitions, ParameterDefinitions and StateDefinitions). (The naming convention is to have the prefix “Domain” instead of “Comm”, the existing projects will be renamed in future releases)
• Projects starting with “Smart…” and “Component…”: these are individual component definitions. (The naming convention is to have the prefix “Component” instead of “Smart”, the existing projects will be renamed in future releases)
• Projects starting with “System…”: these are projects clustering System-related models such as SystemComponentArchitecture, TargetPlatformDefinition and Deployment

Each project contains a folder named “model”. This folder contains the textual representation of the according models. This textual representation always exists for all supported model-types and is used to make the models persistent. Some project-types such as the Component- and the Systemprojects also provide a graphical representation of the models which is indicated by the file “representations.aird”. Double-click on the representations.aird file in order to see the provided graphical model diagrams as shown in the following screenshot:

Double-click onto the according diagram-type to open the Model-diagram. Some models only have a textual representation while other have both, textual and graphical representations. Both representations are automatically synchronized as soon as you save the model (either from within the diagram editor or the textual editor). In this way, you can define and modify the models with your preferred way (i.e. graphically or textually).

The projects that you will find by default include models for flexible Navigation components that are used (among others) for the RobMoSys Intralogistics Industry 4.0 Robot Fleet Pilot (see https://robmosys.eu/wiki/pilots:intralogistics).

The SmartMDSD Toolchain v3 supports service-based composition of software components (see https://robmosys.eu/wiki/composition:service-based-composition:start) and fosters separation of roles for a flexible Ecosystem with component suppliers and users (see https://robmosys.eu/wiki/general_principles:ecosystem:roles). Therefore, the toolchain structures the project types according to the overall ecosystem organization (as described in detail here https://robmosys.eu/wiki/general_principles:ecosystem:start). The overall ecosystem can be organized into three main tiers (see figure below).

Tier 1 structures the ecosystem in general for robotics and corresponds to the internal specification of meta-models within the SmartMDSD Toochain v3.

For the Tier 2, the SmartMDSD Toolchain provides the “DomainModels project” type. This project type provides DSLs for the definition of general communication structures (also called Communication-Objects or Digital-Data-Representation), see the two model-files with the file extension “*.types”. One of such Types is for example:

In this way, Domain Experts on Tier 2 can specify general communication structures for robotics that can be used by e.g. component developers on Tier 3 to specify and realize components that will fit together (i.e. are then composable). However, data structures alone are not sufficient to fully ensure composition. Therefore, the “DomainModels project”, most notably, enables the definition of services (see the models with the file extension “*.services”) as stand-alone entities that can be realized by various components. One of such services is for example:

A service-definition specifies the used data-type (i.e. Communication-Object) and selects one of the commonly defined communication semantics (i.e. Communication-Pattern). See also https://robmosys.eu/wiki/modeling:metamodels:commpattern for further details on the available communication-patterns. These service-definitions serve as high level interface-specifications that can be realized or required by different components.

For the Tier 3, the SmartMDSD Toolchain provides the “Component project” type. As example, all the navigation projects starting with the prefix “Smart*” and “Component*” are individual component projects. The main model of a component project is a Component-Definition model (see the models with file extension “*.component”). A Component-Definition model specifies the component’s internal structures and in particular the component’s communication ports (input, output, request-response).

Components represent stand-alone building blocks that can be used to build different systems.

For specifying systems and deployments, the SmartMDSD Toolchain provides the “System project” type. A system project collects several system-related models, like the “SystemComponentArchitecture” (see models with the file extension “*.componentArch”), the “TargetPlatform” definition (see the models with the file extension “*.target”) and the “Deployment” specification (see the models with the file extension “*.deployment”).

The SystemComponentArchitecture model allows the instantiation, wiring and configuration of several components for a specific system. The TargetPlatform model allows the definition of the computation platform (i.e. the platform to which the component artefacts can be later deployed to). The Deployment model connects the two previous models by specifying which component artefacts from the component-architecture are deployed to which target platforms.

It is worth mentioning that the SmartMDSD Toolchain is not only a “drawing tool”. Instead, various code generators can be flexibly used to generate working code for robotics frameworks such as SmartSoft, ROS and others. At the moment, the ACE/SmartSoft code generator is shipped by default.