Create tomasys-based ontology for the use case

[Rezenders]

Example launchfile:

 tomasys_files_array = [os.path.join(tomasys_ontology_bringup_dir, 'owl', 'tomasys.owl'),
                        os.path.join(mros_ontology_bringup_dir, 'owl', 'mros.owl'),
                        os.path.join(mros_ontology_bringup_dir, 'owl', 'navigation_domain.owl')]

   declare_working_ontology_cmd = DeclareLaunchArgument(
        'model_file',
        default_value=os.path.join(mros_ontology_bringup_dir, 'owl', 'urjc_pilot.owl'),
        description='File name for the Working ontology file')

bringup_reasoner_cmd = Node(
        package='mros2_reasoner',
        executable='mros2_reasoner_node',
        name='mros2_reasoner_node',
        output='screen',
        parameters=[{
            'tomasys_file': tomasys_files_array,
            'model_file': working_ontology_file,
            }],
    )

[Rezenders]

Initial version: https://github.com/kas-lab/pipeline_inspection/blob/owl/config/pipeline_inspection.owl Still missing to add SWRL rule for the specific QAs, and missing fd for function inspect_pipeline

[Rezenders]

[Rezenders]

My idea for the analyze SWRL rule for the water visibility QA:

Measured Water Visibility QA < Expected Water visibility QA associated with the grounded FD -> Function Grounding status is IN_ERROR_NFR AND FD reasibility is False

For planning we can then just use the regular utility function from MROS

I am also assigning this to @JulianePa and @chcorbato so they can follow the discussion

[Rezenders]

In SWRL syntax the rule would be:

tomasys:FunctionGrounding(?fg) ^ tomasys:QAvalue(?mqa) ^ tomasys:hasQAvalue(?fg, ?mqa) ^ tomasys:isQAtype(?mqa, pipeline_inspection:water_visibility) ^ tomasys:FunctionDesign(?fd) ^ tomasys:QAvalue(?eqa) ^ tomasys:typeFD(?fg, ?fd) ^ tomasys:hasQAestimation(?fd, ?eqa) ^ tomasys:isQAtype(?eqa, pipeline_inspection:water_visibility) ^ swrlb:lessThan(?mqa, ?eqa) -> tomasys:fg_status(?fg, "IN_ERROR_NFR") ^ tomasys:fd_realisability(?fd, false)

[Rezenders]

This rule is not working, not sure what is wrong.

[Rezenders]

It was missing tomasys:hasValue to get the qa values.

The rule now is:

tomasys:FunctionGrounding(?fg) ^ tomasys:QAvalue(?mqa) ^ tomasys:hasQAvalue(?fg, ?mqa) ^ tomasys:isQAtype(?mqa, pipeline_inspection:water_visibility) ^ tomasys:FunctionDesign(?fd) ^ tomasys:QAvalue(?eqa) ^ tomasys:typeFD(?fg, ?fd) ^ tomasys:hasQAestimation(?fd, ?eqa) ^ tomasys:isQAtype(?eqa, pipeline_inspection:water_visibility) ^ tomasys:hasValue(?mqa, ?mqav) ^ tomasys:hasValue(?eqa, ?eqav) ^ swrlb:lessThan(?mqav, ?eqav) -> tomasys:fg_status(?fg, "IN_ERROR_NFR") ^ tomasys:fd_realisability(?fd, false)

[Rezenders]

The problem now is that even when the measured QA is greater than the expected values, the fds are not set to be realisable again. I don't know how to get the measured QA without any FGs, and I am not sure if with swrl rules the status is updated or a new value is added.

[Rezenders]

I don't know how to get the measured QA without any FGs

I don't think this is possible. It seems that the measured QA is attached to Fgs and that is it.

def update_qa_value(fg, qa_type, value, tbox, abox):
    qas = fg.hasQAvalue

    if qas == []:  # for the first qa value received
        qav = tbox.QAvalue(
            "obs_{}".format(
                qa_type.name),
            namespace=abox,
            isQAtype=qa_type,
            hasValue=value)
        fg.hasQAvalue.append(qav)
    else:
        for qa in qas:
            if qa.isQAtype == qa_type:
                qa.hasValue = value
                return
        # case it is a new QA type value
        qav = tbox.QAvalue(
            "obs_{}".format(
                qa_type.name),
            isQAtype=qa_type,
            namespace=abox,
            hasValue=value)
        fg.hasQAvalue.append(qav)

# update the QA value for an FG with the value received
def update_qa_value(fg, qa_type, value, tbox, abox):
    qas = fg.hasQAvalue

    if qas == []:  # for the first qa value received
        qav = tbox.QAvalue(
            "obs_{}".format(
                qa_type.name),
            namespace=abox,
            isQAtype=qa_type,
            hasValue=value)
        fg.hasQAvalue.append(qav)
    else:
        for qa in qas:
            if qa.isQAtype == qa_type:
                qa.hasValue = value
                return
        # case it is a new QA type value
        qav = tbox.QAvalue(
            "obs_{}".format(
                qa_type.name),
            isQAtype=qa_type,
            namespace=abox,
            hasValue=value)
        fg.hasQAvalue.append(qav)

[Rezenders]

I don't think this is possible. It seems that the measured QA is attached to Fgs and that is it.

This is not true, they are saved with the prefix obs_. Like: obs_mockiness.

[Rezenders]

It was missing tomasys:hasValue to get the qa values.

The rule now is:

tomasys:FunctionGrounding(?fg) ^ tomasys:QAvalue(?mqa) ^ tomasys:hasQAvalue(?fg, ?mqa) ^ tomasys:isQAtype(?mqa, pipeline_inspection:water_visibility) ^ tomasys:FunctionDesign(?fd) ^ tomasys:QAvalue(?eqa) ^ tomasys:typeFD(?fg, ?fd) ^ tomasys:hasQAestimation(?fd, ?eqa) ^ tomasys:isQAtype(?eqa, pipeline_inspection:water_visibility) ^ tomasys:hasValue(?mqa, ?mqav) ^ tomasys:hasValue(?eqa, ?eqav) ^ swrlb:lessThan(?mqav, ?eqav) -> tomasys:fg_status(?fg, "IN_ERROR_NFR") ^ tomasys:fd_realisability(?fd, false)

I removed the realisable part from the rule, the rule is now:

tomasys:FunctionGrounding(?fg) ^ tomasys:QAvalue(?mqa) ^ tomasys:hasQAvalue(?fg, ?mqa) ^ tomasys:isQAtype(?mqa, pipeline_inspection:water_visibility) ^ tomasys:FunctionDesign(?fd) ^ tomasys:QAvalue(?eqa) ^ tomasys:typeFD(?fg, ?fd) ^ tomasys:hasQAestimation(?fd, ?eqa) ^ tomasys:isQAtype(?eqa, pipeline_inspection:water_visibility) ^ tomasys:hasValue(?mqa, ?mqav) ^ tomasys:hasValue(?eqa, ?eqav) ^ swrlb:lessThan(?mqav, ?eqav) -> tomasys:fg_status(?fg, "IN_ERROR_NFR")

I was planning to add 2 rules to indicate that the FD is realisable or not, but this won't work since SWRL is monotonic. I find this a big limitation of using OWL + SWRL. I will be forced to add ad-hoc code to the reasoner to solve this. With this, I don't think it is possible to say that MROS is general and reusable, unless we provide an easier/more general way to add custom code, instead of actually having to alter the reasoner code.

Not related to the exemplar, but this might be an argument for using different reasoning methods, like prolog or Jason BDI agents.

[Rezenders]

I will be forced to add ad-hoc code to the reasoner to solve this.

Done at 1d04558

However, it is still not working since observed QAs are not being update due to bug reported in https://github.com/meta-control/mc_mros_reasoner/issues/156

[Rezenders]

Issue https://github.com/meta-control/mc_mros_reasoner/issues/156 is solved. The analyze and planning part are working for the function f_generate_search_path.

[Rezenders]

Added requireby relation to components in ca86b19.

I removed the search_efficiency and motion_efficiency QA in a66a7d5. I am using performance instead. This might be important for the formal model @JulianePa

The ontology is finalized now. I will close this issue.