Modelling Languages

During the development stages sketched by Pahl and Beitz [Pah+07], models play a central role to exchange and express ideas and information. Vajna et al. [Vaj+09] outline which classes of models exist in the development of a computational model, which is necessary for numeric evaluation. The original schematic has been taken from [DA95] and was redrawn in figure 3.1.

The model languages that were used in this thesis are mentioned below and arranged according to Vajna et al.’s model classes.

• Phenomena models – Verbal descriptions

3.3. Modelling Languages – Sketches

• Information models

– Mathematical models – Transfer functions

– Domain specific languages for information exchange, e.g. SysML

• Computer models and tools – Source code

– Executable code

– Domain specific languages with execution environment, e.g. Matlab/Simulink

3.3.1. About SysML

SysML is a modelling language which was developed to support the development of complex systems. According to its designers (see [FMS15]: it also contains a good overview of the modeling capabilities of SysML) it aims to serve for system engineers as does the UML (Unified Modeling Language) serve for software engineers, which is also expressed by the close relation between these two languages - SysML was developed on the foundation of UML version 2.

SysML was designed to be able to capture every aspect of a system. To do so, it features a series of diagram types which allow to model different aspects of technical systems. The diagram types are:

• The package diagram type is used to create an overview of large projects by grouping diagrams belonging to one e.g. project team, business area, or subsystem etc.

• A requirement diagram links requirements to a system, and expresses how they are trans-lated from the overall system to component levels.

• Activity, sequence, state machine and use case diagrams serve to describe the behaviour of systems and subsystems.

• Theblock definitiondiagrams specify which block types [similar to classes in object-oriented programming (OOP)] are used in the project. Internal block diagrams detail, what certain blocks (comparable to class instances in OOP) consist of. Examples of block definition diagrams are given in figures 3.3 and 3.4 using two different open source SysML modeling suites.

• Finally, the parametric diagram allows to capture parametric constraints and relations be-tween blocks, as well as bebe-tween their properties.

Many UML modeling tools offer support for SysML, amongst them the open source Modelio and Papyrus software suites. As a benchmark to test the two suites, a portal or gantry robot, which is commonly used in pick-and-place applications, was modelled. The system sketched in figure 3.2 consists of a moveable structure B, the tool support, which is mounted on a moveable beam A, the portal or gantry. For the benchmark it was assumed, that A and B can be actuated by either a small, medium or big drive with different masses and maximum powers.

Figure 3.2.: Sketch of a Portal Robot Modelio

Modelio [Mod17] is a modeler for UML with plugin support for SysML. It is developed by Mod-eliosoft in France. Modelio itself is free and open source, but documentation is scarce. Mode-liosoft’s business model is to offer training and consulting services.

After studying the available documentation for about a week, it was possible to parse SysML diagrams with a Java environment. The extension mechanisms are documented well enough to develop new functionalities. Testing and debugging gets painful soon, as Modelio uses its own runtime. This means, that plugins need to be compiled in Java, loaded into the Modelio runtime and executed there. This results in cumbersome testing (which has to be executed often during software development). Moreover, support for debugging is limited, as the only way to check variable values during execution is in log files and prompts.

The representation of the gantry robot is given in figure 3.3. In the top line, the portal robot is modeled as a SysML block (the small square in the top right corner), and in addition, as a

“design problem” (the letters DP next to the square). The stereotype (the little icons represent existing SysML datatypes, or extensions created by me using stereotypes) of a design problem was introduced, to distinct the block containing the overall evaluation description from the remaining systems. The “portal robot” contains two properties subject to optimisation. Both the measured overshoot when moving the gantry following a step trajectory, as well as the energy necessary to run the trajectory, should be kept as small as possible. This was captured by the stereotype

“min” in the diagram.

The four lines with the black diamonds indicate, that a portal robot consists of four subsystems:

two rigid bodies for the movable arms and two drives. The meaning of the 1’s (called multiplici-ties or cardinalimultiplici-ties) on both ends of these lines is that one portal robot owns e.g. one drive for axis 1 and the drive of axis 1 belongs to one portal robot. The meaning of the lines with the empty triangles is, that both the drives of axis one and two are of the type “Drive” with the properties that are stored there. The bottom line contains three possible realisations of “Drive”, a small, medium and big drive with concrete and distinct values for each of their properties. This is captured by the bullet list icon in the top right corner, linked to a “Selection” stereotype.

Note that any system containing simulation code (Body and Drive) are marked with the type of simulation tool. In the example, “S” was used for Simulink.

Properties not depending on the drive selection, like the movement damping due to friction in bearings, and the transmission ratios from rotational to linear movement for each axis, were stored in the top level block.

Papyrus

Papyrus [Fou17] is part of the Eclipse runtime environment. It is driven by the Papyrus Interna-tional Consortium and Polarsys, the industrial working group of Eclipse.

3.3. Modelling Languages

Figure 3.3.: The Portal Robot in Modelio

Figure 3.4.: The Portal Robot in Papyrus

The documentation can be considered worse than Modelio’s in the way that Papyrus reuses al-ready existing software available in the Eclipse framework, most important the Eclipse Modeling Framework. Because of this, only the modeling capabilities are part of Papyrus’ documentation.

The knowledge on extracting data from the models has to be extracted from the documentation on EMF and Ecore, and the information on building custom functionality for the Eclipse runtime has to be taken from the Eclipse platform documentation.

The representation of the gantry robot in Papyrus SysML is given in figure 3.4. One can see that the differences are mostly graphical, because the SysML language itself is standardized. The model rendering is similar to UML, where blocks are replaced by classes. Hence, the compart-ments “properties” and “operations” are always displayed, as they exist on practically every class.

The tight integration with the Eclipse Modeling Framework (EMF) also comes with advantages, namely access to SysML diagrams with all applied stereotypes in a class structure that can be pregenerated and used throughout coding. This allowed to introduce a stereotype on generalisa-tions (“Implementation of”) to make modeling of selecgeneralisa-tions more natural.

Nevertheless, after two weeks of searching I was able to parse Papyrus diagrams. At this point the Papyrus environment shows its strengths, as the integration with the Eclipse development environment allows a wide range of debugging options, most important, the opportunity to in-terrupt program execution at any time with breakpoints. Then, every variable at these specified points can be accessed.

Overall, the bulkier representation and the additional time spent on learning how to access the models in Papyrus diminish next to the pay off of extensive debug tools when it comes to the development of a serious application.