JACK——TeamsManual5 Team Belief Connections

来源：http://aosgrp.com/

 

5 Team Belief Connections

 

The notion of team belief connections focuses on how beliefsets of teams and sub-teams may be connected through role relationships. Team Belief Connections are either directed 'upwards', synthesizing beliefs of sub-teams into a containing team, or 'downwards', allowing sub-teams to inherit beliefs from a containing team. In both instances, the connection is between sub-teams that fill specified roles in the containing team's Role Obligation Structure and the containing team.

The propagation dynamics of a belief connection, both synthesizing and inheriting, are asynchronous, and allow for source-end filtering to avoid or delay propagation, as well as target end synthesizing. Default plans for source-end filtering are provided – these plans can be overridden by the user if desired. Target end synthesis is implemented using the teamdata construct.

 

5.1 Source Data Definition

A generic capability for propagating changes is provided as part of the beliefset infrastructure. This propagation includes filtering when the #propagates changes declaration is used with an optional event type as described below.

Beliefset types to be connected must include declaration statements of the following form:

    #propagates changes;

or

    #propagates changes  EventType;

in their definition.

A #propagates changes statement marks that the beliefset may be a source beliefset in a team belief connection, and it provides an implementation of the connection dynamics, so that changes to the beliefset are propagated correctly.

If an event type is specified in a #propagates changes statement, it will be sub-tasked to allow the team to block propagation selectively. Event types used for propagation in this way must implement the PropagationEvent interface:

    public interface PropagationEvent {

        public Event propagate(

               String team,

               Tuple newTuple,

               Tuple keyDiscard,

               Tuple negateDiscard,

               BeliefState truthValue,

               boolean wasAssert

        );

    }

The parameters are described below:

Parameter	Description
team	The name of the sub-team whose change is propagated.
wasAssert	Whether the tuple concerned was asserted or retracted.
truthValue	The resulting BeliefState.
newTuple	The tuple concerned.
keyDiscard	The opposing tuple retracted by virtue of the key constraint, if any.
negateDiscard	The contradictory tuple being retracted, if it was believed.

Table 5-1: Parameters for the propagate method

Note that propagate returns an event – this will typically be achieved by defining a suitable posting method in the usual way and then invoking the posting method from within propagate. An example of how to construct such an event is provided in the synthesizing belief connection example presented later in this chapter.

If changes to a belief type are to be propagated through the team hierarchy, the fields must be transportable. This means that either the fields must be declared as JACOB objects in an api file (refer to the JACOB Manual for more details) or they must be defined as a Java class that implements java.io.Serializable.

---

Note: If a propagated belief type is instantiated in a capability rather than at the agent level, then the capability must declare that it posts the propagation event. If the user has not defined the propagation event, then the event to be posted is aos.team.ChangePropagation.

---

 

5.2 Target Data Definition

The teamdata construct is provided to encapsulate the behaviour and data associated with the target end of a team belief connection. Each teamdata is defined as a type level entity using the keyword teamdata, and it has the following form:

    teamdata Type ... {

        ... // declarations

    }

A teamdata is usually an extension of a normal JACK beliefset, which provides the declarations of fields and queries. The extension part defines the behaviours associated with the receipt of change propagations from the sources involved in the connection.

A teamdata definition includes two reasoning methods:

• a #connection method which defines the behaviour when teams are added to or removed from the connection, and
• a #synthesis method which defines the computation to be performed on receipt of a propagated belief. This method is invoked regardless of whether the connection is synthesizing or inheriting.

The #synthesis method is invoked to receive a propagated belief. It has the following prototype:

    #synthesis method(

            String team,

            boolean wasAssert,

            BeliefState truthValue,

            XXXX__Tuple newTuple,

            XXXX__Tuple keyDiscard,

            XXXX__Tuple negateDiscard

    )

XXXX__Tuple is a placeholder for the type of the incoming tuple; it must be replaced with the actual type. The parameters are described in the following table:

Parameter	Description
team	The name of the sub-team whose change is propagated.
wasAssert	Whether the tuple concerned was asserted or retracted.
truthValue	The resulting BeliefState.
newTuple	The tuple concerned.
keyDiscard	The opposing tuple retracted by virtue of the key constraint, if any.
negateDiscard	The contradictory tuple being retracted, if it was believed.

Table 5-2: Parameters for the #synthesis method

The typical behaviour is for the synthesis method to add (selectively) the propagated tuple to the beliefset part of the teamdata. This beliefset can be of a different type to that of the propagated beliefset. However, if multiple sources are involved in a connection, those sources must all be of the same type.

The synthesis method should be written for optimal performance. If a change propagation update requires any lengthy computation, then the synthesis method should defer that computation and instead post an asynchronous event for that purpose.

The #connection method is a reasoning method which is invoked asynchronously when a sub-team is added to or removed from a role, and when this results in a change to whether or not there is a belief connection for that team. If the team belief is connected through multiple roles, then only the first addition or the last remove will result in a belief connection change and an associated #connection method invocation. It has the following prototype:

    #connection method(boolean added, String team)

The parameters are described below:

Parameter	Description
added	Whether the sub-team has been added to or removed from the role.
team	The name of the sub-team that has been added to or removed from the role.

Table 5-3: Parameters for the #connection method

#connection method and #synthesis method invocations are synchronized, ensuring that a team performs only one such method at a time.

5.3 Belief Connection Dynamics

The computation flow in a team belief connection is as follows:

1. The starting point is that a beliefset which propagates change is updated. This defines the belief detail to be propagated.
2. The beliefset involved needs to include a #propagates changes statement in its definition. That statement results in a moddb() callback that posts a kernel event, named ChangePropagation, for propagating the change.
   • The kernel event is a BDIGoalEvent, so as to allow user code to override the whole propagation procedure at the source end.
   • The kernel plans for handling ChangePropapagtion have a rank of 4 or less, to allow a user's plan at the default plan rank, which is 5, to have precedence. If the user plan fails, the default handler will be invoked.
3. The change propagation runs as a parallel task for the source beliefset team. The default handler reviews the role relationship and determines the set of teams to which the belief detail should be propagated. It then spawns a new, parallel task for each target team to deal with per-target-team filtering and the actual inter-team transfer.
4. The #propagates changes statement may nominate an event type for the kernel to use so as to perform a per-target-team source end propagation filtering. When an event type is nominated, the default handler will @subtask that event as a means of deciding whether or not to propagate the change to a given team, and when this propagation is to occur. The former is decided by the event succeeding or failing, and the latter is decided by means of delaying success.
5. The per-team change propagation task next transfers the belief detail to the target team. This is achieved by sending a PropagationMessage event to the target team. The standard way of handling this event uses the teamdata elements as described in points 6 and 7 that follow. However, it is possible for a user to provide a team with special purpose plans to handle PropagationMessage events in other ways. Such special purpose plans should be of higher precedence rank than the standard plan which has a precedence rank of 5. The fields of the PropagationMessage event are described in the following table.

Parameter	Description
from	The name of the sub-team whose change is propagated.
source	The reference name of the source beliefset.
wasAssert	Whether the tuple concerned was asserted or retracted.
truthValue	The resulting BeliefState.
newTuple	The tuple concerned.
keyDiscard	The opposing tuple retracted by virtue of the key constraint, if any.
negateDiscard	The contradictory tuple being retracted, if it was believed.

Table 5-4: Fields of the PropagationMessage event

1. Upon receiving a change propagation notification, the target team first ensures change propagation sequencing by waiting on a semaphore. This semaphore is also used by connection method calls, to ensure that a team only performs one #connection method or #synthesis method at a time.
2. In turn, the target team propagation task completes the propagation by invoking the synthesis method of the teamdata involved, one at a time, followed by a signal to the sequencing semaphore.

All distribution filtering is done at the source end of a change propagation, and all synthesizing computation is done at the target end. Further, at the target end, the change propagations are sequential, allowing only one change propagation at a time to occur.

 

5.4 Synthesizing Belief Connection Definition

A synthesizing team belief connection maps sub-teams' beliefs into corresponding beliefs at the containing team level. This is achieved by propagating information from the sub-team beliefsets to the containing team(s). In order to create a synthesizing team belief connection, appropriate declarations must be included in the

• role that provides the sub-team/team linkage
• the sub-teams that are the source for the connection
• the team that is the target for the connection.

In addition

• a teamdata definition must be provided for the target team
• the source beliefsets must include #propagate changes statements.

 

5.4.1 Role Declarations

To associate a synthesizing belief connection with a role, the following statement form is used:

    #synthesizes teamdata stype sref;

stype and sref identify a source beliefset that will be involved in a synthesizing belief connection – the target for the connection is not specified. Multiple declarations are allowed within a role definition.

Recall that a role defines a team/sub-team interface. Within a role type definition, the #synthesizes teamdata declaration declares that any sub-team that performs this role must provide a data item named sref of type stype. Likewise, any team that requires this role should have a target data declaration that involves this particular data item or it will be unable to receive the propagated beliefs.

 

5.4.2 Source Declarations

A sub-team becomes a source in a synthesizing belief connection by filling a role that contains a #synthesizes teamdata declaration. Thus the sub-team must include an appropriate #performs role declaration and fill the role in the containing team's Role Obligation Structure. Also a data item with the type and the reference specified within the role must be defined either directly within the sub-team definition, or indirectly through the sub-team's capability structure. The data item can be defined either through a #private data declaration, a #exports data declaration in a capability, a #synthesizes teamdata or through a #inherits teamdata declaration. The latter two cases require that the sub-team is the target for another belief connection.

 

5.4.3 Target Declarations

A team becomes a target in a synthesizing belief connection by requiring a role that contains a #synthesizes teamdata declaration. Thus the team must include an appropriate #requires role declaration and a #synthesizes teamdata declaration that binds the data item specified in the role with the role container that contains the sub-teams that fill the role.

A #synthesizes teamdata declaration has the following form in the team definition:

    #synthesizes teamdata ttype tref(rcref1.sref1,rcref2.sref2,...);

where

ttype is the type of the target teamdata
tref is the name of the target teamdata reference
rcrefi is the name of the ith role container reference
srefi is the name of the ith source data item reference which is to be synthesized.

As indicated above, teamdata can be synthesized from beliefs specified in more than one role. In this case, multiple #requires role statements will be required in the team and the types of the source beliefs must be the same. Note that ttype refers to the type of the target teamdata, not the type of the source data.

Recall that the teamdata type is typically achieved by extending a beliefset type. Depending on the application, that beliefset type may be the same as the source data type or it may be different.

The above declaration results in the creation of a teamdata instance. The intention is that the data to be contained in this instance will be provided solely from the data sources for the connection – hence there is no mechanism to populate the instance at construction time. This teamdata instance is then accessible to the target team and through the #uses data declaration, to the target team's capabilities and plans as though it had been declared as #private data. In particular, a teamdata instance can be used as a source belief for another belief connection.

The #synthesizes teamdata statement results in code that ensures that when role fillers are added to or removed from any of the indicated role containers the corresponding beliefset change propagation path is added or removed. The actual synthesizing computation is defined separately (via the #synthesis method of the teamdata definition). Although a connection is defined in terms of role filling, it is maintained on a sub-team basis. Thus if a connection involves multiple roles and one sub-team fills more than one of the roles, a change to that sub-team's beliefset is propagated only once to the teamdata, and not once for each role container that contains the sub-team.

 

5.4.4 An Example

Suppose that a Section team requires a Soldier role and a Private team performs the Soldier role. Furthermore, suppose that the Private team maintains its current location and ammunition level in beliefsets of type Location and Ammunition respectively. A synthesizing team belief connection that will enable the Section team to monitor the location and ammunition levels of its members is to be established. This data will be stored in teamdata of type SectionLocation and SectionAmmunition respectively.

1. Source data definition

The Location and Ammunition beliefsets could be defined as follows:

    beliefset Location extends OpenWorld {

        #value field double x;

        #value field double y;

        #linear query get(logical double x,logical double y);

        #propagates changes;

    }

    beliefset Ammunition extends OpenWorld {

        #key field String type;

        #value field int count;

        #indexed query get(logical String t,logical int c);

        #indexed query get(String t,logical int c);

        #propagates changes AmmoChangePropagation;

    }

Note that the latter beliefset, Ammunition, propagates changes through the AmmoChangePropagation filter event. When a change occurs, the kernel will sub-task an instance of this event, for deciding whether and when the change propagation is to occur. The AmmoChangePropagation event will be similar to the following:

    event AmmoChangePropagation extends BDIGoalEvent

        implements PropagationEvent {

        ...

        #posted as

        report( ... )

        {

           ...

        }

        public Event propagate(String team,

                               Tuple newTuple,

                               Tuple keyDiscard,

                               Tuple negateDiscard,

                               BeliefState truthValue,

                               boolean wasAssert )

       {

          // just call the posting method ...

          return report( ... );

       }

    }

The application can then include a plan to handle this AmmoChangePropagation event. The change propagation will then occur only if and when the plan succeeds.

---

Note: The #propagates changes declaration results in a moddb() method associated with the beliefset. This means that the programmer must not include their own moddb() method within the beliefset.

---

1. Target data definition

The SectionAmmunition beliefset is teamdata that accumulates the count of sub-team's Ammunition beliefsets. A possible definition for this is outlined below:

    teamdata SectionAmmunition extends Ammunition {

        #connection method(boolean added, String team)

        {

        }

        #synthesis method

                   (String team,

                    boolean asserted,

                    BeliefState tv,

                    Ammunition__Tuple is,

                    Ammunition__Tuple was,

                    Ammunition__Tuple lost )

        {

            logical int current;

            if (get(is.type,current)) {

                // binds current

            } else {

                current.unify(0);

            }

            if (is != null) {

                int delta = is.count;

                if (lost != null)

                    delta -= lost.count;

                add(is.type, current.getValue() + delta);

            }

        }

    }

SectionLocation makes use of explicit replication as follows:

    teamdata SectionLocation extends Location {

        Hashtable locations = new Hashtable();

        Location location(String team)

        {

           return (Location) locations.get(team);

        }

        #connection method(boolean added, String team)

        {

           if (added) {

              if (locations.get(team) == null ) {

                  Location location = new Location();

                  location.attach(handler);

                  locations.put(team, location);

              }

           } else {

             locations.remove(team);

           }

        }

     #synthesis method

                 (String team,

                  boolean asserted,

                  BeliefState tv,

                  Location__Tuple is,

                  Location__Tuple was,

                  Location__Tuple lost)

     {

        Location location = (Location) locations.get(team);

        if (asserted)

           location.add(is, tv);

        else

           location.remove(is, tv);

        double sum_x = 0;

        double sum_y = 0;

        int n = locations.size();

        for (Enumeration e = locations.elements();

             e.hasMoreElements(); ) {

          Location location = (Location) e.nextElement();

          logical double x;

          logical double y;

          location.get(x,y);

          sum_x += x.getValue();

          sum_y += y.getValue();

        }

        sum_x /= n ;

        sum_y /= n ;

        add(sum_x,sum_y);

     }

   }

---

Note: The code in the above example also invokes the attach() method when a belief replication beliefset is created, providing the local handler as the argument. This statement is a JACK detail that is hidden in the generated code for beliefsets, but which must be dealt with explicitly for belief replication. The purpose is to attach the new beliefset object to the correct EventRecipient (i.e. the entity that is to handle any event being posted by the beliefset), which in practice is the enclosing team.

In the example, the local handler is inherited from the ultimate base class, BeliefSet, via the explicit base class, Location. The local handler is thus available since the synthesized belief extends a beliefset. In the general case, the synthesized belief may need to capture the EventRecipient explicitly by implementing the EventSource interface, which in fact is the attach() method.

---

1. Role declarations

The Soldier role could contain the following declarations:

    role Soldier extends Role {

        #synthesizes teamdata Location location;

        #synthesizes teamdata Ammunition ammo;

        ...

    }

1. Source declarations

The Private team needs to perform the Soldier role and to define the data sources specified within that role:

    team Private extends Team {

        #performs role Soldier;

        #private data Location location();

        #private data Ammunition ammo();

        ...

    }

1. Target declarations

The Section team could incorporate declarations similar to the following:

    team Section extends Team {

        #requires role Soldier left(3,3);

        #requires role Soldier right(3,3);

        #requires role Soldier depth(3,3);

        #synthesizes teamdata SectionLocation location

            (left.location, right.location, depth.location);

        #synthesizes teamdata SectionAmmunition ammo

            (left.ammo, right.ammo, depth.ammo);

        ...

    }

5.5 Inheriting Belief Connection Definition

An inheriting team belief connection maps a team belief into separate sub-team beliefs. Conceptually this is done by means of a distribution computation that translates the team belief individually for each sub-team, followed by a (virtual) replication of the translated belief into the corresponding sub-team's belief. Often a sub-team will perform a role for one team only, but in the general case the sub-team may fill the same role for many teams and the inherited belief connection will combine belief updates from all the teams in the same way as a synthesizing belief connection.

In order to create an inheriting team belief connection, appropriate declarations must be included in the

• role that provides the team/sub-team linkage
• the teams that are the source for the connection
• the sub-teams that are the target for the connection.

In addition

• a teamdata definition must be provided for the target sub-teams
• the source beliefsets must include #propagates changes statements.

 

5.5.1 Role Declarations

To associate an inheriting belief connection with a role, the following statement form is used:

    #inherits teamdata stype sref ;

stype and sref identify a source beliefset that will be involved in an inheriting belief connection – the target for the connection is not specified. Multiple declarations are allowed within a role definition.

Recall that a role defines a team/sub-team interface. Within a role type definition, a #inherits teamdata declaration declares that any team that requires this role must provide a data item named sref of type stype. Likewise any team that performs this role should have a target data declaration that involves this particular data item or it will be unable to receive the propagated beliefs.

 

5.5.2 Source Declarations

A team becomes a source in an inheriting belief connection by requiring a role that contains a #inherits teamdata declaration. The team must therefore include an appropriate #requires role declaration. Also, a data item with the type and the reference specified within the role must be defined either directly within the team definition, or indirectly through the team's capability structure. The data item can be defined either through a #private data declaration, a #exports data declaration in a capability, a #synthesizes teamdata declaration or through a #inherits teamdata declaration. The latter two cases require that the team is the target for another belief connection.

 

5.5.3 Target Declarations

A sub-team becomes a target in an inheriting belief connection by filling a role that contains a #inherits teamdata declaration. Thus the sub-team must include an appropriate #performs role declaration and fill the role in the containing team's Role Obligation Structure. The sub-team must also include a #inherits teamdata declaration that binds the data item specified in the role with the role type. Note that this binding differs to that in a synthesizing belief connection, as a role performer does not have access to the role container.

A #inherits teamdata declaration has the following form in the sub-team definition:

    #inherits teamdata ttype tref (rtype1.sref1, rtype2.sref2, ... );

where

ttype is the type of the target teamdata,
tref is the name of the target teamdata reference,
rtypei is the type of the performed role, and
srefi is the name source data item in the performed role that is to be inherited.

As indicated above, teamdata can be inherited from beliefs contained in more than one role. In this case, multiple #performs role statements will be required in the sub-team and the types of the source beliefs must be the same. Note that ttype refers to the type of the target teamdata, not the type of the source data.

Recall that the teamdata type is typically achieved by extending a beliefset type; depending on the application, that beliefset type may be the same as the source data type or it may be different.

The above declaration results in the creation of a teamdata instance. The intention is that the data to be contained in this instance will be provided solely from the data sources for the connection – hence there is no mechanism to populate the instance at construction time. This teamdata instance is then accessible to the sub-team, and its capabilities and plans as though it had been declared as #private data – in particular, it can be used as the source belief of another belief connection.

The #inherits teamdata statement results in code that ensures that when role fillers are added to or removed from any of the indicated role containers the corresponding beliefset change propagation path is added or removed. The actual synthesizing computation is defined separately (via the #synthesis method of the teamdata definition). Although a connection is defined in terms of role filling, it is maintained on a sub-team basis. Thus, if a connection involves multiple roles and one sub-team fills more than one of the roles, a change to the containing team's beliefset is propagated only once to the sub-team's teamdata, and not once for each role container that contains the sub-team.

5.5.4 An Example

Suppose that a Company team requires a FireSupport role and a Platoon team can perform the FireSupport role. Furthermore, suppose that the Company team maintains the current enemy location in a beliefset of type Location. An inheriting team belief connection that will enable the Platoon team to monitor the enemy location is to be established. This data will be stored in teamdata of type EnemyLocation.

1. Source data definition

The Location beliefset definition developed for the synthesizing belief connection example can be used:

    beliefset Location extends OpenWorld {

        #value field double x;

        #value field double y;

        #linear query get(logical double x,logical double y);

        #propagates changes;

    }

1. Target data definition

The EnemyLocation beliefset is teamdata that mirrors the enemy location maintained by the Company team. A possible definition for this is outlined below:

    teamdata EnemyLocation extends Location {

        #connection method(boolean added, String team)

        {

        }

        #synthesis method

                   (String team,

                    boolean asserted,

                    BeliefState tv,

                    Location__Tuple is,

                    Location__Tuple was,

                    Location__Tuple lost )

        {

            if (is != null) {

              add(is.x, is.y);

            }

        }

    }

1. Role declarations

The FireSupport role could contain the following declaration:

    role FireSupport extends Role {

       #inherits teamdata Location enemyLocation;

       ...

    }

1. Source declarations

The Company team requires a team to perform the FireSupport role and it must define the data sources specified within that role:

    team Company extends Team {

        #requires role FireSupport fireSupport;

        ...

        #private data Location enemyLocation();

        ...

    }

1. Target declarations

The Platoon team needs to perform the FireSupport role and to create the teamdata instance to receive the enemy location:

    team Platoon extends Team {

        #performs role FireSupport;

         ...

        #inherits teamdata EnemyLocation reportedEnemyLocation

            (FireSupport.enemyLocation);

        ...

    }