Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Objective status and desired reasoner behaviour #119

Open
chcorbato opened this issue Nov 24, 2020 · 1 comment
Open

Objective status and desired reasoner behaviour #119

chcorbato opened this issue Nov 24, 2020 · 1 comment
Assignees

Comments

@chcorbato
Copy link
Contributor

Maybe we can have more status for the objective: IN_PROGRESS, IN_ERROR_NFR, IN_ERROR_COMPONENT, UNREACHABLE.

IN_ERROR_NFR may be set when the current FG doesn't meet objectives NFRs so a new FG should be selected
IN_ERROR_COMPONENT would be set when the current FG uses an unavailable component so a new FG should be selected
When there isn't a FD reachable, we could set the objective at UNREACHABLE, then we can delete this objective and switch to another one (i.e. switch from navigating to go to recharge). In this case, maybe we can miss NFR because is an emergency action and navigate to the deck with fewer restrictions so FD with IN_ERROR_NFR property on the log can be selected.

What do you think? @marioney @chcorbato @rsanz

Originally posted by @estherag in #111 (comment)

@chcorbato
Copy link
Contributor Author

chcorbato commented Nov 24, 2020

We need to identify what needs for new states we have. This can be clarified with the State Machine for an Objective status, that is define for each status:

  • What events could happen in the reasoner when the objective is in that status, i.e. adaptation triggered, update something in the ontology...
  • what transitions to other status should happen depending on which event happened

Can you complete/correct it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants