caskade-automation / caskade-planner Goto Github PK

For some capabilites, properties that are relevant for other properties are irrelevant. Nevertheless, the properties of a product must be retained across the application of capabilities, as they may be relevant again for a later capability and the information should not be lost. Currently, when modeling the ontology, it is always necessary to model all properties for each capability.

Currently we set the initial state to all properties. Logically, we should set the initial state only for the inputs. If we do not set the initial state on the output, these are free variables and fulfill all requirements from the beginning and no capability has to be executed. Here we need to consider how to avoid this problem.

Currently, we only set explicitly defined values in the init stage. There should be default initilization:

• all bools that are not set -> false
• all reals that are not set -> 0

Currently, all SMT encodings are created again for each happening. Presumably, only the next happening can be created and supplemented.

Propagation of desired values from input information prevent repeated execution of the corresponding capability. A solution must be found here: For example, all desired values of input information, i.e. instance descriptions with no expression goal, could remain free and not be propagated across events and happenings.

For planning, we cannot look at a capability without looking at the resources providing this capability.
Event if two resources A and B provide the same capability, resource properties influence the planning solution. For example, one resource could have enough material while the others stock is empty.
We need to take the combination of resource and capability into account for planning.

Example: Resources A and B offer Drilling. Instead of a variable Drilling, we need two variables A_Drilling and B_Drilling.

The capabilities lack a concrete reference to a resource. If resource X grabs a package, resource Y cannot transport the package. Current preconditions are not sufficient to prevent such a solution.

We need to check if all the queries are necessary. Don't we already have the necessary information in the classes or do we have queries that query very similar content?

We can assume that there is no change to the ontology once planning is started. Thus, every query should be fired only once overall. NOT once per happening as we do now.

Revise the use of resource ID as a constant. Currently for all happenings + events variables. However, only necessary once. Problem is, parser openmath, which uses argName and extends it by happening + event. A distinction must be made here.