Suitable Agents

An organisation tries to reach a given goal with the available agents. Since the agents can be created dynamically, the organisation can choose out of all feasible agents. However, depend- ing upon the functional requirements to achieve the goal out of this set of feasible agents, only a subset is capable of contributing towards this goal. This section therefore details the algo- rithm to identify suitable agents with respect to an organisation’s goal and current functional requirements.

Definition 3.2 (Suitable agent). Any feasible agent GA which can support a

Figure 3.12: The performance of feasibility checking for a composite agent depends upon the selection strategy for variable assignment and the available set of interfaces. Note that dif- ferent y-axis ranges are used between the upper and lower plots to achieve a more detailed visualisation.

MoreOrgmodels agents as a collection of resources with a hierarchical dependency structure. The resources that compose an agent are either physical components or virtual components including functionalities. Joining multiple agents into a single composite agent brings together the atomic agents’ resources. A composite agent is assumed to represent a single agent which has access to all comprising resources. This resource access forms the basis for superaddition. The agent-based concept of composition and classification into atomic and composite structure is therefore also applied to functionality. The inference of available functionality is based on the same mechanisms for all agents.

Definition 3.3 (Atomic functionality). A functionalityf of an agent is defined

asatomic when no modelled resource dependencies exist and the function-

ality cannot be further decomposed.

Definition 3.4 (Composite functionality). A functionalityf of an agent is de-

fined ascomposite when it can be decomposed into further resources which

are part of the agent including, but not limited to other functionalities.

Based on the selected abstraction level, functionality can be modelled as atomic functionality without any further dependency and can trivially be related to an agent type. The definition of composite functionalities can be interpreted as inference rules, which can be applied to check

resource collections for so called functionality support.

Functionality Support

To check whether a composite functionality is supported by a composite agent type the follow- ing assumption holds:

Assumption 3.1 (Availability of composite functionality). The availability of a composite functionality f in an agent a only depends on the availability of the required resources of f .

Hence, any composite functionality becomes available, when a particular set of resources is brought together by joining two or more atomic agents. The availability or rathersupport quan-

tifies the availability of functionality. Functionality support is defined for an atomic agent type and a single resource concept c as follows (see also (Roehr and F. Kirchner2016)):

support( ˆa, c, f ) = ⎧ ⎪ ⎪ ⎨ ⎪ ⎪ ⎩ 0 cardmin(c, f ) = 0 cardmax(c, ˆa)

cardmin(c,f ) otherwise

, (3.8)

where cardminand cardmaxreturn the minimum and maximum required cardinality of resource instances (including instances of derived resource concepts), respectively.

Accordingly, support of a functionality f with respect to a resource class c can be categorised as follows: support( ˆa, c, f ) = ⎧ ⎪ ⎪ ⎪ ⎪ ⎨ ⎪ ⎪ ⎪ ⎪ ⎩ 0 no support ≥_{1 full support}

> 0 and < 1 partial support

(3.9)

The categorisation permits to identify useful atomic agents for constructing a composite system that offers a particular functionality: An atomic agent that provide no support do not need to be considered. A single atomic agent that provides full support is sufficient to fulfil the resource requirements. In the case of partial support further analysis is required. The actual support value permits an estimation of the maximum required number of atomic agents to satisfy the resource requirements for the given functionality. While support here is computed for a single resource concept, the categorisation of no, partial and full support has to be likewise applied to a general agent and with respect to multiple functionalities. This is done in the following. The relationship between the existence of the functionality f and the agent type ˆa (here the notation of the agent type ˆa represents the corresponding class in the ontology) is described as

follows:

ˆ

a ⊑ 1.has.f ⇐⇒ ∀c : cardmin(c, f ) = 0 ∨ support( ˆa, c, f ) ≥ 1 (3.10)

The inference of functionality support for a general agent ˆGA relies on a similar definition of

support:

support( ˆGA, c, f ) = cardmax(c, ˆGA) cardmin(c, f )

where the maximum resource cardinalities are computed according to Equation3.1. The sup- port value can again be categorised in no, partial or full support - equivalently to Equation3.9. Support needs to be computed in most cases for a set of functionalities, so that the support for a single functionality can be defined as:

support( ˆGA, f ) = min

c∈C

cardmax(c, ˆGA)

card_min(c, f ) , (3.12)

where C is a set of resource concepts and ∀c ∈ C : cardmin(c, f ) ≥ 1 to account only for rele- vant resource concepts. If there exists a required concept c, such that support( ˆa, c, f ) = 0 then

FSB( ˆa, f ) = ∞.

The computation of support by a general agent type for a set of functionalities F follows:

support( ˆGA, F ) = min

f ∈F support( ˆGA, f ) (3.13)

Example An atomic agent a has at maximum one camera, and one power source. A function- ality StereoCameraProvider requires a minimum of two available resources Camera and at least onePowerSource. The atomic agent provides full support with respect toPowerSource:

support( ˆa,PowerSource,StereoCameraProvider) = cardmax(

PowerSource, ˆa)

cardmin(PowerSource,StereoCameraProvider)

=1 1 The overall support for a stereo camera provider by the atomic agent a is only partial, since only a composite agent type ˆCA = ( ˆa, 2) has a sufficient number of cameras to fulfil the requirement

of aStereoCameraProvider:

support( ˆa,Camera,StereoCameraProvider) = cardmax(

Camera, ˆa)

cardmin(Camera,StereoCameraProvider)

= 1 2

Mapping between Structure and Function

To use the organisation model for planning a mapping between agents and their respective functionalities is required. The mapping function of an organisation always depends upon the available set of atomic agents, and the known functionalities. The available set of atomic agents is represented as agent pool which defines the cardinality for each atomic agent type in the organisation. The corresponding mapping function µ relates functionalities and constructible (general) agent types Θ(A):

µ : PF → PΘ(A) _{, (3.14)}

where PF denotes the powerset of all functionalities and PΘ(A) denotes the powerset of all constructible agent types.

The general reasoning mechanism to identify support for functionality is presented in Sec- tion 3.2. It is the basis to compute the mapping between functionalities and agents. The computation of the mapping function requires the set of functionalities, the known resource concepts and the available set of agents. The organisation model also allows to infer the func- tionality set from a given set of agent types (based on its associated resource structure):

Since the mapping function uses only information about agent types, the organisation model can precompute the mapping between structure and function. However, the approach suffers from the combinatorial challenge, since an exhaustive computation has to account for all agent types Θ(A). The powerset of PAdescribes all combinations of atomic agents in A including the empty set. Since |PA|_{= 2}|A| _{a worst case complexity of O(2}|A|_{) exists. Therefore, an exhaustive} computation is only reasonable for small agent organisations.

According to the summation rules the cardinality of a resource type in a composite agent is monotonic increasing with each addition of an atomic agent. Yet, an agent hasfull support for a

functionality as soon as the minimum resource requirements for this functionality are fulfilled. Composite agents might therefore comprise a high level of resource redundancy with respect to a functionality. So while the total number of agent types supporting some functionality can be large, a subset of Θ(A) exists which has minimal redundancy.

Definition 3.5 (Minimal agent type). A general agent type which supports a set of functionalities F and whose agent type cardinalities cannot be further reduced without loosing support for F is denoted by minimal with respect to F . The set of all minimal agent types for an available pool of agents A and a functionality set F is denoted by θ∗(F , A) or equivalently θ∗(F , ˆA) for the

general agent type which correspondingly represents the agent pool A.

A minimal agent type ˆA′ ∈_θ∗_{(F , A) represents a lower bound to satisfy functionality require-} ments F with a given combination of atomic agent types. Thereby, a minimal agent type rep- resents a so-calledfunctional saturation bound.

Definition 3.6 (Functional Saturation Bound). The minimal number of atomic agents to support a particular functionality (set) is denoted by functional saturation bound.

The functional saturation bound for an atomic agent type ˆa with respect to functionality f can

be computed using the inverse of support (see Definition3.8):

FSB( ˆa, f ) = max

c∈C

1

support( ˆa, c, f ) , (3.16)

where C is a set of resource concepts and ∀c ∈ C : cardmin(c, f ) ≥ 1 to account only for rele- vant resource concepts. If there exists a required concept c, such that support( ˆa, c, f ) = 0 then

FSB( ˆa, f ) = ∞. Similarly, the bound for a set of functions F is defined as: FSB( ˆa, F ) = max

f ∈F FSB( ˆa, f ) (3.17)

The effect of the functional saturation bound can be illustrated with a simple example setup: an atomic agent type ˆa has one resource Camera and one PowerSource. Merging two agents

of type ˆa provides two resources Camera and one PowerSource. The functionality StereoCam-

eraProvider depends upon the availability of two resources Camera and one PowerSource. When the only needed functionality is StereoCameraProvider, any composition of more than two agents of type ˆa adds redundancy.

The functional saturation bound for a general agent type ˆA is also a general agent type, here

denoted by ˆAF:

FSB( ˆA, F ) = ˆAF, where ∀ ˆa ∈ ˆA : γ ˆ

Table 3.6:A heterogeneous reconfigurable multi-robot team.

Atomic agent types Interfaces Instances in scenario # male # female SherpaTT 4 2 5 Base Camp 5 0 3 CoyoteIII 2 0 3 PayloadBattery 1 1 4 PayloadCamera 1 1 4 PayloadSoilSampler 1 1 4

When the number of instances of a general agent type ˆA exceeds the cardinality γ

ˆ

AF( ˆa), the

general agent type is guaranteed to contain redundancies with respect to the functionality set F_{. The bound is not exact in the sense, that redundancies can be completely avoided. Even} if all atomic agent type cardinalities are below a functional saturation bound, redundancies might exist.

A set of 14 different functionalities as illustrated in Figure3.6is part of the default organisation model used in this thesis. Figure3.13ashows the computation of the functionality mapping with and without application of the functional saturation bound for a homogeneous collec- tion of atomic agents of agent type Sherpa. The composition of two or more Sherpa does not provide superadditive effects, so that the functional saturation easily improves the computa- tion of the functionality mapping. Comparing the computing time for a single instance shows, however, that the computation and application of the functional saturation bound come with additional cost. Figure3.13bshows the performance for computing the functionality mapping for a heterogeneous team as listed in Table3.6. It can be seen directly, that the computation time corresponds to the number of agent types to be considered, which remains significantly lower when the functional saturation bound is applied.

The suggested computation of the functional saturation bound is an effective means to reduce redundant computations. However, some atomic agents that are part of a composite agent do not necessarily contribute directly to functionality. These atomic agents might still be re- quired as structural elements, when otherwise the overall composite agent would not be fea- sible. Therefore, an exploration of a neighbourhood Nϵ

ˆ AF

of the initial functional saturation bound is necessary, when the bound ˆAF represents an infeasible agent. The neighbourhood size is bound by the number of additionally considered atomic agents ϵ to enable (structural) feasibility. The selection of the neighbourhood size has a direct influence on the computational efficiency since exponentially more composite agent types have to be considered. Figure3.13c illustrates the influence of the neighbourhood size ϵ on the computation time for the given example team listed in Table3.6.

Property Constraints

The mapping function µ alone enables queries to identify agent types which support a func- tionality. However, some applications might need to constrain the query result. Narrowing the resulting set of agent types further can be based on agent type properties. These properties can

(a)Computation of the functionality mapping for a homoge- neous collection of atomic agents of type Sherpa.

(b)Time to compute the functionality mapping and number of agent types that have to be considered in the functionality mapping (with and without functional saturation bound) for the heterogeneous team listed in Table 3.6 with neighbour- hood size ϵ = 0.

(c) Computation time and relevant composite agent types with respect to the structural neighbourhood size.

detail the characterisation of the functionality. Ridesharing serves here as an example, since it is also used in Chapter4.

An application of ridesharing requires at least one system which is capable to transport other agents. An atomic agent which is mobile and which has interfaces to attach other atomic agents can be used as transport system. The related service is named TransportProvider(see also Figure3.6). The transport service might be limited, e.g., to a maximum number of other agents which can be carried.

To express this type of query an additional property-based query level is also part ofMoreOrg. The goal of this query support is the identification of agent types suited for a set of tasks, whereas each task is attributed with required functionality and agent properties which need to be fulfilled for this task. The combination of functionality and agent property in a query can be understood as a partial template for an agent type. This is similar to agents that fulfil roles in other works (DeLoach2009; Hübner, Sichman, and Boissier2004).

A property constraint is defined as n′ op n for n.R, where op ∈ OP and OP is a relation operator OP = {<, >, <=, >=}, and R is the relation/property for an agent ˆA ⊑ n.R. All functionality re-

quirements can be augmented with property constraints, such that all suitable agents have not only to support the functionality, but in addition also have to fulfil the property constraints. Property restrictions are applied on the set of agents which have been identified to support a requested functionality. Similarly to the summation of resources to identify support for func- tionality, application of property constraints assumes monotonic increasing property values, e.g., such as mass of a composite system. The property restrictions are verified against the inferred agent properties, e.g., using a requirement for < 100.mass (SI units apply) allows to restrict the result to all agents below 100 kg of mass.