“Modelling” is at the core of the RobMoSys ambition and approach, and the project has identified these five complementary levels in model formality:

• 1. Models for human discussions: such models must provide guidance to discussions between humand developers, and hence result in more and more harmonized interpretations of the relevant entities and relations.

• 2. Models for human software documentation: only when the mentioned “level 1.” harmonization has matured in a community, one can expect software to be developed whose meaning and behaviour are well understood by all developers in that community.

• 3. Models for software tools and standards: the harmonization has reached a level of maturity where the explanation in a standards document, and the availability of a reference implementation that conforms to the standard document, suffice to let everyone use software artefacts based on the standard with unambiguous interpretations. Hence, support from software tools becomes realistic, or even mandatory as the major pragmatic way of software development in a broader community.

• 4. Models for verification and validation: the standardisation has been formalized so far that the meaning and behaviour of software artefacts can be checked automatically.

• 5. Models for run-time dialogues between machines: the formalization and its automatic checking has become (1) efficient enough to be used at runtime by the robots themselves, and (2) rich enough so that the machines can set up added-value cooperations themselves via dialogues, or can configure, adapt and explain their own behaviour, with only minor human interaction.

The project's pragmatic focus is on levels 2. and 3., but it does keep 4. and 5. in mind in every discussion and decision about how and what to put in a model. Note that levels can overlap to some extend.

The aim of RobMoSys is to cover the modeling levels with functional tooling. This include adequate code-grounding (where applicable) to actually use the models in real-systems (e.g. code-generation towards frameworks, executable components, analysis tools, etc.).

There is a subtle relationship between the (meta-)models, the actual modeling languages and the concrete models. This relationship is depicted in the figure below.

A modeller (i.e. a modeling-tool user who creates models) always works with a concrete syntax. This syntax can be textual, graphical, tabular or any combination thereof. The concrete syntax (sometimes also called notation) is defined by (i.e. it conforms to) the modeling language. The concrete syntax of a modeling language is independent of the abstract syntax of an actual meta-model. However, the structure of the modeling language must adhere to the structures defined in a meta-model. In most cases, it makes sense to first specify the meta-model, then to generate a modeling language out of the meta-model and then to adjust only the syntax of the modeling language (without affecting the structure). A model created by the modeller is typically only a representation for the in-memory model that uses the abstract syntax. The abstract syntax is also used to serialize the models in order to make them persistent.

Finally, the model itself is an abstract representation of the actual system (which can be either software, hardware or any combination thereof). Often, it makes sense to package the model with the related software/hardware parts and to ship them together as a so called modeling twin.

Are you new to model-driven engineering? Find introduction literature in the Frequently Asked Questions.

There is a relation between meta-models and ontologies that can be bridged as described here.

This image is borrowed from twouse.blogspot.de

The strength of ontologies is the representation of knowledge with extensible structures. Moreover, ontologies allow reasoning on knowledge and the inference of further knowledge. The strength of meta-models is the definition of clear and unambiguous structures. This is particularly useful to represent physical entities and physical properties of the real-world. There are robotics use-cases where in some cases ontologies and in other cases meta-models can be preferred. Therefore it is reasonable to allow using both of them in combination, rather than restricting the usage of only one of them in isolation.