a hierarchical agent- oriented knowledge model for multi-agent systems liang xiao and des greer...

A Hierarchical Agent-oriented Knowledge

Model for Multi-Agent Systems Liang Xiao and Des Greer

School of Computer Science,Queen's University Belfast,

UK

[email protected] [email protected]

A Hierarchical Agent-oriented Knowledge Model for Multi-Agent Systems – L. Xiao, D.Greer, AOSDM, SEKE 20062

Overview• Research Aims

• Previous Approaches

• Adaptive Agent Model – Knowledge Hierarchy

• Modelling Knowledge in the Hierarchy Layers– Conceptual Model (Business Concepts Layer)

– Fact Model (Business Concepts Layer)

– Policy Rule Model (Business Rules Layer)

– Reaction Rule Model (Business Rules Layer)

– Business Process Rule Model (Business Processes Layer)

• Conclusions


Introduction• Software must change if it is to remain

useful

– but changing software is expensive

• Reduce cost

– Easy for experts to maintain business knowledge

– Better still: agents manage the knowledge

• agents are computational entities that have dynamic behaviour, being situated in a changing environment


agent-oriented approaches

• 2 approaches– object-oriented (OO) approaches

• agents = active objects– agent-oriented programming (AOP) (Shoham)– agent-oriented methodology for enterprise modelling (Kendall

et al)

– knowledge engineering (KE) approaches• agent knowledge is modelled

– CommonKADS (Schreiber et al)– Agent Oriented Abstraction (Maret & Calmet)– DIAMS (Chen et al)

• Adaptive Agent Model – Combines both approaches


Why AAM?

• higher level of abstraction than an OO alone

– knowledge can be externalised for easier management rather than fixed in objects

– OO developers can reuse their skills

• From KE viewpoint - deployment of modelled knowledge is supported by an underpinning object layer

– Extra benefits from proven technology


Case study

• Domains: – Train Running – Infrastructure Management

• Sub domains– Business, Incident, and Execution

• Examples– Infrastructure Management - Incident (IMI)

• Passing faults between the system and contractors

– Infrastructure Management – Execution (IME)• granting of isolations

– Train Running - Incident (TRI), journey refinement/corrections


Case study continued

• External Entities = Train Operators, Contractors

• Other terms– infrastructure asset

– asset faults which cause incidents which can cause track restrictions

• Example Requirements:– IMI-AcceptFaultReport

– IMI-HandleFault

– IME-ImposeSuddenRestrictions

– TRI-RespondToIncident


Hierarchy Overview

Business processes knowledge

Business rules knowledge (reactions and policies)

Business concepts knowledge

< > <> < >

……

agents act and react in collaboration

Inter-agent message exchanges

Rules in individual agents for business tasks

Reaction strategies

Business Policies

used in business rules

vocabularies

Satisfying business goals from requirements


Hierarchy Overview




< > <> < >

……

Business Concepts Knowledge Layer

Conceptual Model

• externalises business concepts from the applications that use them

• Concepts are also used to construct business rules

• Example from railtrack system: “fault”, “incident”, “restriction – These have properties:

• e.g. “fault” has properties indicating its location, impact, and priority

– Register in a Conceptual Model (XML)

- <concept>

<name>fault</name>

- <properties>

<property>type</property>

<property>location</property>

<property>impact</property>

<property>priority</property>



<properties>

</concept>


Model 2: Fact model

• For example, report about an asset fault arrives

• fact established that a fault has occurred in London, type “rail broken”– Create business object with appropriate values in properties

• Fact Manager Agent (FMA) manages all faults

• Policy Rule Manager Agent (PRMA) deduces new facts from existing facts by application of Policy Rules (PR) (later)

• Individual Agents apply Reaction Rules (RR) (later)

• Agent knowledge gets dynamically updated as message exchange continues and facts are added or removed

• lower layer class facility enables the use of an existing OO infrastructure


FM and CM in operation

• At runtime

– established facts mapped to business objects• instantiated from business classes (schemas in CM)

– Methods invoked as required for the manipulation of facts by business rules (later)

– business concepts that comprise the business rules are separate from the classes

• only at the time when they are used that the specific matched class methods are bound.

• Therefore, classes to be invoked at runtime are exchangeable and new behaviour can be achieved by the replacement of classes/ methods


Hierarchy Overview




< > <> < >

……

Business Rules Knowledge Layer


Policy Rule Model

• Policy Rule captures a constraint or invariant

• PR assertions on the logical relationships between entities must always be TRUE

• PR made up of: business objects, attributes, associations, operations

• PR operators: IF, THEN, AND, OR, and so on


Example Policy Rule

If fault is located at the capital citiesThen it has “immediate impact”- <policy> <id>100</id> <condition> fault.location == “London” OR “Edinburgh” OR “Cardiff” OR

“Belfast” </condition> <action> fault.impact = true </action> <priority>5</priority> </policy>

PR for classifying business objects


More Example Policy Rules

If fault has “immediate impact”

Then it has a high priority of 10

If fault has no “immediate impact”

Then IMI-HandleFault does nothing

If fault has “immediate impact”

Then IMI-HandleFault establishes a new incident associated with the fault AND requests IME to place track restrictions

PR deduced from attributes

PR related to triggered behaviour


Reaction Rule Model

• AAM uses an event-driven agent architecture

• Reaction Rules represent reactive processes at individual agents (unlike PR which are run globally by the PRMA)

• Suppose one business domain is delegated to one agent – e.g. Infrastructure Management Incident (IMI) domain

(delegation is a matter for the specification process)

• Agent can play different roles– e.g. IMI-HandleFault for handling faults related to Infrastructure

Management Incident domain


REQUIREMENTS SPECIFICATION….An asset fault is either reported to the system (Requirement: IMI-AcceptFaultReport) or detected directly by the system (Requirement: IMI-NoticeFault). The handling of both cases is the same (Requirement: IMI-HandleFault). If the fault has already been cleared no further action is needed immediately. Otherwise the system notifies the Contractor responsible for the fault and agrees a priority for fixing the fault. The fault may …

Deriving Reaction RulesRECONSTRUCTED SPEC I.E REACTION RULEIMI-HandleFault is informed by IMI-AcceptFaultReport or IMI-NoticeFault about an asset fault, IF the Fault has been cleared THEN DO_NOTHING, ELSEInform the responsible Contractor about the fault with an agreed priority,IF the fault has no immediate impact THEN DO_NOTHING, ELSECreate an incident related with the fault AND Create and put in place track restrictions using IME-ImposeSuddenRestrictions

RR structure{event, processing, {condition, action}n}.

Uses business objects

Source of

event

Target for

action

Can be changed at any time

behaviour adaptivity


Reaction rule in XML- <reaction>

<name>HandleFault</name>

<business-process>Fault Management</business-process>

<owner-agent>IMI</owner-agent>

- <global-variable>

- <var>

<name>asset</name>

<type>Asset</type>

</var>

- <var>

<name>fault</name>

<type>Fault</type>

</var>

</global-variable>


- <event> - <message> <from>IMI.AcceptFaultReport</from> - <content> - <report> - <reporter>Henry</reporter> - <fault> <type>rail_broken</type> <location>London</location> - <asset> <id>10015</id> <type>rail</type> <contractor>Contractor_A</contractor> … </asset> </fault> </report> </content> </message> </event>


<processing>

asset = new Asset (reportMsg) fault = new Fault (reportMsg)

</processing>


<condition> fault.cleared () == false </condition>

- <action> - <message> <to>Contractor.FixFault</to> - <content> - <fault> ... </fault> </content> </message> </action>


<condition> fault.immeImpact () == true</condition>

- <action> - <message> <to>IME.ImposeSuddenRestrictions</to> - <content> - <asset> ... </asset> </content> </message> </action>

<priority>5</priority> </reaction>


Hierarchy Overview




< > <> < >

……

Business Process Knowledge Layer


Business Process Rule Model

• execution of collections of RRs (with sequence and conditions) business processes

• RRs collectively constrain business processes for system goals via Business Process Rules (BPRs)

• RR: how one task is to be performed following a process, a goal internal to one agent

• BPR: how one shared business goal is achieved by a compositional process = whole collection of RRs


BPR “Manage New Fault”

Handle Fault

Notice Fault

Impose Sudden Restrictions

Accept Fault Report

IMI

Track restriction request

IME

Track restrictions and incidents

Train Operator

Amended train journeys

Fix Fault

Fault locations

Respond To Incident

TRI

Accept Timetable Change

Contractor

Initialising agent (IA)

Either RR to initialise this BPR

Final agent (FA)


- <process> <name>Manage New Fault</name> <goal>a new fault is managed</goal> - <IAs> <IA>IMI</IA> </IAs> - <FAs> <FA>Contractor</FA> <FA>Train Operator</FA> </FAs> <cause>a new fault is reported</cause> - <effects> <effect> A Contractor will fix the fault </effect> <effect> Train Operator will re-schedule train services </effect> </effects> </process>


Conclusions

• Business Concepts Layer used by Adaptive Agent Model (AAM)– Conceptual Model (CM) for vocabulary – Fact Model (FM), conforming to the CM constructed at runtime by agents

• Business Knowledge Layer uses these concepts• Reaction Rules - agent chooses a RR to react to after an event in a particular

context, makes a decision, selects collaborators, and requests them to carry on the BPR.

• Policy Rules - while a RR is functioning, PR chains form and assist the RR to make decisions

• Business Process Layer– Business Process Rules dictate series of agents to react via Reaction Rules

• Main Contributions– Framework for building AO business models– Maintainable specification– Adaptivity

A Hierarchical Agent-oriented Knowledge

Model for Multi-Agent Systems Liang Xiao and Des Greer

School of Computer Science,Queen's University Belfast,

UK

[email protected] [email protected]

a hierarchical agent- oriented knowledge model for multi-agent systems liang xiao and des greer...

Documents