meta-control / mros_ontology Goto Github PK

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