Transition from component error to normal

[estherag]

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

[chcorbato]

I prefer option A), and actually I'd prefer to maintain also the link with the objective that was active when the fd_error_log entry was created.
The rationale for fd_error_log was to store a history of the execution of the FD. As you point out, that information could be used "to change the estimated QA values of a FD if they differ from the ones measured in the linked FG"
To make sense of each entry in the `fd_error_log, we need to store the context in which it was created. Currently, I limited that context to the objective. But we could add more information.

I propose to keep the current information structure but add the type of error, as you suggest:
fd_error_log(FD, CONTEXT, ERROR_TYPE)
owl does not allow tripplets, but this can be solved with an intermediate Class FD_Error
fd_error_log(FD, FD_Error), or something like that.

What do you think?

[estherag]

I'm not sure if I completely understand the use of the class FD_Error. Do you mean using this class for store the error_type of the FD? I mean, when a FG is in error, its FD should be instantiated as FD_error and change a ERROR_TYPE property to COMP_ERROR or NFR_ERROR? and the fd_error_log(FD, OBJECTIVE) would remain right?

[chcorbato]

No, my suggestion is to store, as entry in the fd_error_log for the FD1, the following info:

• context
• error_type

but that would require a triplet fd_error_log(FD=fd1, context=objective, error_type="QA_ERROR"), and OWL only allows tuples.
So we need some individual to hold the values (context=CONTEXT, error_type=ERROR_TYPE)
I propose to create the class FDerror for this.
So and individual fderror1 of type FDError will be created with context(fderor1, objective), error_type(fderror1, "QA_ERROR")
and then fd_error_log(fd1, fderror1)

[estherag]

Ok, I see it now. I will implement it. Thanks!

[estherag]

@chcorbato, @marioney and I had a meeting today. For the restore case of a component, we have decided it is easier just coordinate with fd_realisability rather than fd_error_log. We are treating them differently as NFR case is an objective's error and component case is a component error. So, if you agree, we are going to stick to your previous fd_error_log (FD, objective)` as the error type stored will be always IN_ERROR_NFR.

@marioney has a more explanatory diagram for this, but the idea is to have as objective status values: {"IN_ERROR_COMPONENT" , "IN_ERROR_NFR" , "IN_PROGRESS" , "UNGROUNDED" , "UNREACHABLE" , "UPDATABLE"}

Possible contingencies:

A) Laser failure

When we receive c_status(laser_resender, "FALSE") the objective and the FG statuses are set as IN_ERROR_COMPONENT. Required FD are set with `fd_realisablility(FD, false).

The metacontrol reconfigures the system to a new FG. When the laser is restored, its status changes to c_status(laser_resender, "RECOVERED"). Then related FD are set with `fd_realisablility(FD, true). Also, as the objective can go to a more optimal mode, we mark it with the objective's status UPDATABLE. To trigger a reconfiguration with a better performance FG.

B) NFR failure

When we don't reach objective's NFR, we set the objective to IN_ERROR_NFR and store the FD in fd_error_log (FD, objective)` and search for a suitable FD.

The rest of objective's status are managed by the metacontroller.

• When we start the system, the objective is UNGROUNDED.
• When we have a functioning FG, the objective is IN_PROGRESS.
• When no FD are found, metacontrol sets the objective status as UNREACHABLE and a new objective should be defined.

What do you think?

[chcorbato]

@chcorbato, @marioney and I had a meeting today. For the restore case of a component, we have decided it is easier just coordinate with fd_realisability rather than fd_error_log. We are treating them differently as NFR case is an objective's error and component case is a component error. So, if you agree, we are going to stick to your previous fd_error_log (FD, objective)` as the error type stored will be always IN_ERROR_NFR.

I agree. Most of my questions below are clarifications to include in the MROS Final Report:

@marioney has a more explanatory diagram for this, but the idea is to have as objective status values: {"IN_ERROR_COMPONENT" , "IN_ERROR_NFR" , "IN_PROGRESS" , "UNGROUNDED" , "UNREACHABLE" , "UPDATABLE"}

Possible contingencies:

A) Laser failure

When we receive c_status(laser_resender, "FALSE") the objective and the FG statuses are set as IN_ERROR_COMPONENT. Required FD are set with `fd_realisablility(FD, false).

Who sets the fg and the obj in IN_ERROR_COMPONENT? Some rules? Which ones specifically?

The metacontrol reconfigures the system to a new FG.

As a result of this, are there any additional changes in the ABox to those of the fg and obj

When the laser is restored, its status changes to c_status(laser_resender, "RECOVERED"). Then related FD are set with `fd_realisablility(FD, true). Also, as the objective can go to a more optimal mode, we mark it with the objective's status UPDATABLE. To trigger a reconfiguration with a better performance FG.

B) NFR failure

When we don't reach objective's NFR, we set the objective to IN_ERROR_NFR and store the FD in fd_error_log (FD, objective)` and search for a suitable FD.

Again, are this chagnes ni the ABox performed by SWRL rules? Which ones?

The rest of objective's status are managed by the metacontroller.

• When we start the system, the objective is UNGROUNDED.
• When we have a functioning FG, the objective is IN_PROGRESS.
• When no FD are found, metacontrol sets the objective status as UNREACHABLE and a new objective should be defined.

I assume this 3 ABox changes above are done by the reasoner code, NOT by SWRL rules, right?

What do you think?

LGTM!

[estherag]

@chcorbato, @marioney and I had a meeting today. For the restore case of a component, we have decided it is easier just coordinate with fd_realisability rather than fd_error_log. We are treating them differently as NFR case is an objective's error and component case is a component error. So, if you agree, we are going to stick to your previous fd_error_log (FD, objective)` as the error type stored will be always IN_ERROR_NFR.

I agree. Most of my questions below are clarifications to include in the MROS Final Report:

@marioney has a more explanatory diagram for this, but the idea is to have as objective status values: {"IN_ERROR_COMPONENT" , "IN_ERROR_NFR" , "IN_PROGRESS" , "UNGROUNDED" , "UNREACHABLE" , "UPDATABLE"}
Possible contingencies:
A) Laser failure
When we receive c_status(laser_resender, "FALSE") the objective and the FG statuses are set as IN_ERROR_COMPONENT. Required FD are set with `fd_realisablility(FD, false).

Who sets the fg and the obj in IN_ERROR_COMPONENT? Some rules? Which ones specifically?

Yes, two rules one in the MROS ontology (FG in error) and other in TOMASys (Obj in error)

• CompErrorFG: if component in error required by FG, FG in error
• CompError: if component required for FD not working, FD not available
• S1a: fg in error component-> objective in error component

The metacontrol reconfigures the system to a new FG.

As a result of this, are there any additional changes in the ABox to those of the fg and obj

After configuration, a new FG is selected. Therefore, the metacontroller delete the fg in error individual and creates a new one. Also, the metacontroller sets objective status to IN_PROGRESS once the new fg is grounded. If there are not available fd to ground, the objective status is set to UNREACHABLE.

When the laser is restored, its status changes to c_status(laser_resender, "RECOVERED"). Then related FD are set with `fd_realisablility(FD, true). Also, as the objective can go to a more optimal mode, we mark it with the objective's status UPDATABLE. To trigger a reconfiguration with a better performance FG.

Rules in MROS in charge of this:

• compRecov: if component recovery, objective updatable
• compRecovRealis: if component required for FD working, FD available

B) NFR failure
When we don't reach objective's NFR, we set the objective to IN_ERROR_NFR and store the FD in fd_error_log (FD, objective)` and search for a suitable FD.

Again, are this chagnes ni the ABox performed by SWRL rules? Which ones?

Three TOMASys rules are in charge of this:

• QAsafety: if objective has NFR safety and FG has QAvalue higher, objective in nfr error
• QAenergy: if objective has NFR energy and FG has QAvalue higher, objective in nfr error
• S9: objective in error NFR -> objective added to the fd_error_log of the FD

The rest of objective's status are managed by the metacontroller.

• When we start the system, the objective is UNGROUNDED.
• When we have a functioning FG, the objective is IN_PROGRESS.
• When no FD are found, metacontrol sets the objective status as UNREACHABLE and a new objective should be defined.

I assume this 3 ABox changes above are done by the reasoner code, NOT by SWRL rules, right?

Yes.

What do you think?

LGTM!

I will extend today this information in the MROS Final Report.

[chcorbato]

Shall we close this issue or we keep it to track the implementation of this model for the objective status in the pilots? @marioney @estherag

[marioney]

Keep it open. To check the implementation on the reasoner side

[estherag]

In the MROS doc we've been discussing about the current ontological reasoning limitations:

Esther Aguado
OK, regarding this functional comparison yesterday @[email protected], @[email protected] and I founded a limitation in our ontological implementation. As we use SWRL to change the status of individuals, the previous status asserted are kept, so there is a conflict. We are going to delete previous status as a code-trick on the metacontroller, but in future applications, @[email protected] said that this could be better solved using non-monotonic reasoning.

@chcorbato
Agreed, I discussed something related in the UNEXMIN paper. In mros reasoning a locally closed-world is assumed for monotonic reasoning, with the reset (rather than belief update) of some individuals based on perceptual information before every reasoning cycle. In this case, this is the reset of objective statuses on every reasoning cycle. Could you please include your discussion of this issue in the document?

In MROS implementation, the manifestation of this problem are conflicting data property values. To keep track of the current solution, I'm going to specify what are the code-tricks we are using to solve this problem:

1. Any time a new FG is settled, the objective status is deleted. In the .owl side, the objective will only take as status IN_ERROR_NFR, IN_ERROR_COMPONENT, UPDATABLE and it will last until a new FG is set. So most of the time the objective won't be on a specific status (so an absence of status indicates implicitly a IN_PROGRESS status). Already implemented by @marioney

2. (Probably not implemented but to be taken into account) When the laser is recovered some data properties should change:

a. Component status switch from FALSE to RECOVERED -> delete FALSE status in laser component so a RECOVERED value can be added by metacontroller.
b. FD realisability switch from FALSE (laser broken) to TRUE (laser working) -> delete fd_realisability(fd, FALSE) so a true value can be added by SWRL rules.

[chcorbato]

b. FD realisability switch from FALSE (laser broken) to TRUE (laser working) -> delete fd_realisability(fd, FALSE) so a true value can be added by SWRL rules.

So there are rules to assign a status of an FD for all situations, and the only "manual" action from the python code is to delete the previous status assigned when needed?

[estherag]

So there are rules to assign a status of an FD for all situations, and the only "manual" action from the python code is to delete the previous status assigned when needed?

Yes, thats it.