meta-control / mros_ontology

MROS T3 Metacontrol Ontologies

The purpose of MROS Task 3 is the development of an ontology to support metacontrol system modeling and run-time reasoning. These ontologies are used by the metacontroller implementation available here, note that the MROS reasoner used is in the branch foxy-devel.

Overall view

The MROS objective is to use TOMASys concepts to implement a model-driven metacontroller for a ROS2 navigation system in two pilot robotic applications inside the RobMoSys framework.

The metacontroller will use a runtime reasoner that will exploit a system model to generate new runtime system configurations to overcome difficulties. This model and reasoner uses concepts that are reified in the form of an ontology captured in Web Ontology Language v2 (OWL 2).

The general ontology under development has been divided in two main parts: one dedicated to the navigation task — the focus of activity of both pilots— and another dedicated to the concepts related to system adaptation using the metacontrol approach. These two are known as Metacontrol Ontology (MO), and Navigation Ontology (NO).

Formal ontologies contain terms that capture the concepts in the domain of analysis. Ontologies attempt a formal naming and definition of the categories, properties and relations between the concepts, data and entities that populate a specifc domain of analysis.

The Ontologies

The folder ontologies contains OWL2 files for the ontologies using OWL2 Functional Syntax. These files can be edited with any text editor or managed using a GUI-based tool like Protégé. The current structure is:

• TOMASys: General systems ontology for component organization to reach objectives through functions. Here is defined the terminological components (TBox) through classes, properties and general rules. This is equivalent to the previous Metacontrol Ontology. This ontology is available in mc_mdl_tomasys repository.
• MROS ontology: TOMASys adaptation for MROS project ontology. TOMASys terminological components are extended with general error propagation rules and an object property to link components and function designs. Therefore, this ontology is the TBox that supports the specific pilot ontology. This is equivalent to the previous RobMoSys Ontology.
• Navigation-domain ontology: Basic application-specific knowledge regarding navigation concepts. Assertion components (ABox) have been generated for usual navigation applications based on ROS2. This is equivalent to the previous Navigation Ontology.
• URJC Pilot ontology: Ontology to capture application-specific knowledge, this is the assertion component (ABox). Here we define individuals and specific rules to transform the general knowledge of TOMASys into precise information for the pilot.

Additionally two test ontologies have been added for testing in Protege the ontology coherence. The test pilot nfr ontology tests a failure for not accomplishing the non-functional requirements of the objective and the test pilot laser ontology tests a failure propagation when the laser is disabled.

mros_ontology's Issues

Transition from component error to normal

Currently when a component is in error, fd_realisability is set as false.
When an objective is in error (because of QA or component), the FD linked to the current FG is stored in the fd_error_log.

Two approaches can be taken:

• A) If we expand the objective status as proposed on this issue, we could change the fd_error_log structure. Currently the fd_error_log is an object property that links FDs and objectives. This property indicates that a FD is not suitable anymore to solve a certain objective, for instance: fd_error_log(f_normal_mode, o_navigateA).
  I propose using it as a value property so we can have: fd_error_log(f_normal_mode, "COMP_ERROR").
  If the error is due to non reaching QA objective's requirements, we would have fd_error_log(f_normal_mode, "NFR_ERROR")
  When a new objective is set, we could erase all NFR_ERRORs whereas when a component is repaired, we could erase al COMP_ERRORs. This way we avoid trying deprecated functions in both (component and NFR) restoration cases.
  With this approach, we lose that link between FD and objective, but as we only have one objective at a time when we remove an objective and the errors linked to its QA, we are implicitly using that information.

• B) Another approach could be forget about error logs and add a new realisability property. Currently we have a fd_realisability that links components required by FD. If we rename that with fd_comp_realisability and add a fd_qa_realisability, we could also capture runtime which FDs are not available because of not meeting objective's NFR. When a component_statusis set true, fd_comp_realisability will change to true. When an objective_status is set to UNREACHABLE before being removed, fd_qa_realisabilitywill change to true.

Any of this approaches are intended to:

1. After a new objective definition, have all available FDs for that objective without the previous information of QA of past objectives.
   However, this information may be used. We could use it to change the estimated QA values of a FD if they differ from the ones measured in the linked FG (I don't know if it that would be useful as I guess it depends a lot on the concrete objective and environment).

2. After a component restoration, re-set all required FDs to available.

What do you think? @marioney @chcorbato