Reactive Rules

Reactive rules allow CoCo to dynamically respond to changes in items. These rules are defined using the CLIPS language. CoCo generates facts that represent types, items, and their static and dynamic properties. It is then possible to define rules such that when these facts match the conditions specified in the rules, the rules are triggered.

Extending CLIPS in CoCo

CoCo extends the CLIPS language by introducing custom functions that can be invoked from within the rules. These functions control the behavior of the framework, offering advanced capabilities to manage and manipulate data dynamically.

The add_data Function

The add_data function updates an item's dynamic properties with new values. It takes the following parameters:

• Item ID: The ID of the item to which data is being added.
• Multislot of property names: A multislot that holds the names of the dynamic properties being updated.
• Multislot of property values: The new values for the dynamic properties.
• Timestamp (optional): The timestamp of when the update is made.

For example, in the previous rule, when a sensor with ID ?rppg publishes new data like heart rate (?hr), breathing rate (?br), and SpO2 (?spo2), these values are assigned to the corresponding properties HR, BR, SpO2 of a user ?user, provided that the sensor is associated with a user via dynamic properties.

Interacting with the Transformer server

The understand Function

The understand function in CoCo is used to request the language management module to understand a phrase within a particular context. The module identifies the intent of the sentence and extracts entities, returning the result by invoking another CLIPS function called intent.

Structure of the intent Function The intent function is composed of the following parameters:

• Intent name (string): Represents the name of the identified intent.
• Confidence score (float): Indicates how confident the module is about the recognized intent.
• Entities (multifield of symbols): Represents the entities extracted from the input sentence.
• Entity values (multifield): Contains the recognized values of those entities.
• Entity confidence scores (multifield of floats): Represents the confidence levels for each recognized entity.

For example, given the sentence "Nice to meet you, my name is Alice" the language management module might recognize the intent as greetings and extract the entity person with the value "Alice". The intent function could be called with the following parameters:

(intent greetings 0.9 (create$ person) (create$ "Alice") (create$ 1))

By implementing this function within the system's reactive rules, actions based on recognized intents can be executed. CoCo provides an empty default implementation of this function, which must be overridden in the reactive rules for meaningful behaviors.

The trigger_intent Function

The trigger_intent function allows for activating the language management module with a specific intent and its corresponding entities. The parameters include:

• Object ID (symbol): The ID of the object that will be used to communicate actions chosen by the language management module.
• Intent name (symbol): The intent to be triggered.
• Entities (multifield of symbols): The entities associated with the intent.
• Entity values (multifield): The values of the corresponding entities.

The language management module processes the intent and entities, generating a sequence of actions that are then attached to the specified object.

Example:

(trigger_intent alice_id check_status (create$ emotion) (create$ happy))

In this example, the check_status intent is triggered with the entity emotion set to happy. The language module might then respond to the user with a message such as "Hello Alice, how are you? You seem happy!".

The trigger_intent function is useful for initiating conversations and interactions with objects in the environment. The actions generated by the language module are attached to the object with the ID alice_id similar to the add_data function. In particular, the response generated by the language module updates the text dynamic property of the object. Custom output payloads can be defined in the language management module to provide more complex responses. For example, the following response assigns the value true to the open_mic dynamic property of the object with ID alice_id:

responses:
  utter_open_mic:
    - custom:
        open_mic: true

The compute_response Function

The compute_response function is a combination of understand and trigger_intent. It takes an object ID and a sentence to interpret. The language management module processes the input sentence, identifies the intent, and generates a sequence of actions to respond, attaching those actions to the specified object.

Example:

(compute_response alice_id "Hello")

In this case, the system interprets the input string "Hello", identifies the intent (e.g., greetings), and calculates the appropriate actions, which are then sent to the object with ID alice_id.

The compute_response function is a convenient way to handle user input and generate responses based on the identified intent. It streamlines the process of interpreting user commands and providing appropriate feedback. Similar to the trigger_intent function, the actions generated by the language module are attached to the object for further processing.

Creating a Solver: new_solver_rules and new_solver_script

new_solver_rules

This function creates a new solver for solving deliberative tasks and returns the ID of the newly created solver. It takes two parameters:

• Purpose: A symbolic field that indicates the goal of creating the solver.
• Deliberative rule names: A string multifield containing the names of deliberative rules to be used in solving the problem.

As a result, CoCo creates a fact of type solver, with fields such as:

id: The ID of the new solver. purpose: The solver's goal. state: The current state of the solver, which can be one of the following: reasoning, idle, adapting, executing, finished, failed

Reactive rules can respond to this fact based on the current environment's state.

new_solver_script

This function, designed for simpler cases, also creates a new solver and returns the ID of the newly created solver. It takes:

• Purpose: A symbolic field indicating the solver's goal.
• RiDDLe script: A RiDDLe script defining the deliberative problem to solve.

Starting Execution: start_execution

Once a solution is found, the solver moves from the reasoning state to the idle state. At this point, the solution can be executed by invoking the start_execution function with the solver's ID. This can be included in a rule like the following:

(defrule start_execution 
  (solver (id ?id) (state idle)) 
  => 
  (start_execution ?id))

During execution, the solver must dynamically verify the executability and completion of activities. Execution occurs in real-time, and conditions may change between plan generation and activity execution.

Executability: starting and ending Functions

starting

This function checks if an activity can be started. It takes the following parameters:

• Solver ID: The ID of the solver.
• Predicate type: A symbol representing the RiDDLe predicate of the activity type.
• Multifield of symbols: Parameters of the activity.
• Multifield of values: Values of the parameters.

The function returns:

TRUE: If the activity can be started. FALSE: If it cannot. Multifield (optional): The estimated delay for executability if the activity is not immediately executable.

ending

This function checks if an activity can be completed. It takes:

• Solver ID: The ID of the solver.
• Task ID: The ID of the activity to complete.

By default, CoCo provides an empty implementation of these functions, returning TRUE. However, for more complex behavior, these functions should be overridden in reactive rules to tailor the system's response to dynamic conditions.

Task Creation

If the activities are executable, CoCo creates a task fact for each running activity. This fact contains:

• id: The ID of the task.
• task_type: The activity type, corresponding to the RiDDLe predicate.
• pars: A multifield of symbols representing the activity's parameter names.
• vars: A multifield representing the values of the parameters.

Reactive rules can then respond to the introduction of these facts and define the system's behavior. Once activities are completed, these facts are automatically retracted.

Dynamic Adaptation of Activities: delay_task, extend_task, and failure

delay_task and extend_task

During execution, start and end times for activities may need to be modified. The functions delay_task and extend_task achieve this:

• delay_task: Delays the start of an activity.
• extend_task: Extends the end time of an activity.

Both functions take:

• Solver ID: The ID of the solver.
• Task ID: The ID of the task to delay or extend.
• Optional multifield: Defines the delay time.

failure

Some activities may fail during execution. The failure function informs CoCo of failed activities. It takes:

• Solver ID: The ID of the solver.
• Multifield: A multifield of failed task IDs.

CoCo will then generate a new solution excluding the failed activities.

Solver Adaptation: adapt_solver_rules and adapt_solver_script

To introduce new goals, CoCo provides two functions:

• adapt_rules: Requires the solver's ID and a multifield of deliberative rule names.
• adapt_script: Requires the solver's ID and a RiDDLe script.

Destroying a Solver: delete_solver

When a solver is no longer needed or becomes inconsistent, it can be destroyed using the delete_solver function, which requires the solver's ID.