An agent-based architecture for multi-modal interaction
Agent论文:AgentMulti-Agent-System动态集成框架模型脚本解释策略
Agent论文:Agent Multi-Agent-System 动态集成框架模型脚本解释策略【中文摘要】随着计算机软硬件技术的发展,软件系统的规模越来越庞大,功能也越来越复杂,如何有效的重用已有的软件单元,是目前很多研究的重点。
传统构件化的系统集成方法缺乏多角色,多用户,多层次的灵活的交互,使得集成后的系统缺乏必要的灵活性和柔性。
而人工智能领域的Agent技术,具有主动性,自治性,社会性和智能性等特性,将其应用到系统集成过程中就有可能解决面向多领域的、异构系统之间的、柔性的动态集成问题。
本文将Agent技术应用到软件系统集成领域,在对领域特征集成单元划分规则展开分析的基础上,提出了包装原集成单元的Agent模型,设计并实现了基于多Agent的系统动态集成框架模型。
把脚本语言中脚本的解释控制策略应用到系统集成过程中,提出用脚本定义集成规则、基于脚本解释控制来完成集成单元之间柔性的、动态的集成控制策略。
系统集成框架设计了Agent能力注册中心、Agent管理服务和公共消息黑板等三类管理Agent以及控制协调Agent并分发任务的控制Agent。
在单个Agent 独立求解的基础上,使用集中控制多Agent间交互的策略,柔性、动态的把被集成系统单元集成在一起。
最后将该框架模型应用到某领域仿真系统,在本文设...【英文摘要】With the development of computer software and hardware, software is becoming more hugeness and functional.It is point that how to use the existing software units in effect. The traditional method of component has the disadvantages of low flexibility and non-dynamic in the process of software system integration. With the properties of bounded autonomy, rationality, sociability, reactivity, cooperation, and responsibility, Agent is quite suitable for the software integration.This paper introduces agent t...【关键词】Agent Multi-Agent-System 动态集成框架模型脚本解释策略【采买全文】1.3.9.9.38.8.4.8 1.3.8.1.13.7.2.1同时提供论文写作定制和论文发表服务.保过包发.【说明】本文仅为中国学术文献总库合作提供,无涉版权。
基于Agent的建模方法ppt课件
领域都在借鉴或采用该概念进行本领域的研 究工作。本章主要介绍基于Agent 的建模方法, 以及用于Agent建模和仿真的Swarm平台和应 用实例等。
9.1 Agent的基本概念
基于Agent的建 模方法
▪ 如基于Agent的软件工程(ABSE:Agent-Based Software Engineering)、基于Agent的计算 (Agent-Based Computing)、面向Agent的程 序设计(AOP:Agent-Oriented Programming)
▪ Agent通信语言(ACL:Agent Communication Language)等等。
▪ 基于对Agent英文原意的理解,常被人解释为代理。 但随着Agent广泛应用的不同领域,不再局限于 “代理”。
1.Agent应具有的特性:
▪ 1)Agent是一个具有明确边界和界面的问题 求解实体。
▪ 2)Agent处于特定环境之中,它通过感知器 来观测环境,通过效应器来作用于环境。
▪ 3)自治性。这是一个Agent 最本质的特征。
▪ 9.1.1 Agent的定义
▪ Agent 最初来源于分布式人工智能的研究。目前, 由于Agent 已经渗透到计算机科学技术的许多领域 和许多非计算机领域中,所以从一般意义上很难给 出Agent 严格而清晰的定义,到目前为止,还没有 形成一个统一确定的Agent定义。
▪ 在英文中,“Agent”有三种含义:一是指对其行 为负责任的人;二是指能够产生某种效果的,在物 理、化学或生物意义上活跃的东西;三是指代理, 即接受某人的委托并代表他执行某种功能或任务。
Formation control of networked multi-agent systems
Abstract: In this study, a systematic framework is developed for the consensus control problem, particularly for formation control of networked dynamic agents. In view of the complexity of the framework with switching coupling topology and non-linearity, a new decentralised formation strategy based on artificial potential functions (APF) is proposed. Owing to the existence of local minima in the APF, the formation controller is designed to introduce some special functions to settle that limitation. A new concept of relative-positionbased formation stability is defined, and a Lyapunov approach is used along with an extended linear matrix inequalities (LMI) algorithm to analyse the condition for formation stability. Finally, an example with simulations is provided to demonstrate the effectiveness of the designed formation controller.
The International Journal of Advanced Manufacturing Technology
Ping LouÆZu-de ZhouÆYou-Ping ChenÆWu AiStudy on multi-agent-based agile supply chain management Received:23December2002/Accepted:23December2002/Published online:5December2003ÓSpringer-Verlag London Limited2003Abstract In a worldwide network of suppliers,factories, warehouses,distribution centres and retailers,the supply chain plays a very important role in the acquisition, transformation,and delivery of raw materials and products.One of the most important characteristics of agile supply chain is the ability to reconfigure dynami-cally and quickly according to demand changes in the market.In this paper,concepts and characteristics of an agile supply chain are discussed and the agile supply chain is regarded as one of the pivotal technologies of agile manufacture based on dynamic alliance.Also,the importance of coordination in supply chain is emphas-ised and a general architecture of agile supply chain management is presented based on a multi-agent theory, in which the supply chain is managed by a set of intelli-gent agents for one or more activities.The supply chain management system functions are to coordinate its agents.Agent functionalities and responsibilities are de-fined respectively,and a contract net protocol joint with case-based reasoning for coordination and an algorithm for task allocation is presented.Keywords Agile supply chainÆMulti-agent systemÆCoordinationÆCBRÆContract net protocol1IntroductionAdvanced technology and management are constantly being adopted to improve an enterpriseÕs strength and competitive ability in order to achieve predominance among hot global competition.In a report on21st century manufacturing strategy development,the author suggests that various production resources,including people,funds,technology and facilities should be inte-grated and managed as a whole;thus optimising the utilisation of resources and taking full advantage of advanced manufacturing technology,information tech-nology,network technology and computer[1].Agile manufacture based on dynamic alliance is coming into being so that enterprises can remain competitive in a constantly changing business environment and is becoming a main competitive paradigm in the interna-tional market.Agility,which has basically two mean-ings:flexibility and reconfigurability,has become a very important characteristic of a modern manufacturing enterprise.Flexibility is an enterpriseÕs ability to make adjustments according to customersÕneeds.Reconfigu-rability is the ability to meet changing demands[2,3].The ability to quickly respond to marketÕs changes, called agility,has been recognised as a key element in the success and survival of enterprises in todayÕs market.In order to keep up with rapid change,enterprises need to change traditional management in this hot competition. Through dynamic alliance,enterprises exert predomi-nance themselves,cooperate faithfully with each other, and compete jointly so as to meet the needs of the fluctuating market,andfinally achieve the goal of win-win[2,3].So how to improve agility in the supply chain, namelyflexibility and reconfigurability,is one of the important factors to win against the competition.Supply chain management(SCM)is an approach to satisfy the demands of customers for products and ser-vices via integrated management in the whole business process from raw material procurement to the product or service delivery to customers.In[4],M.S.Fox et al. describe the goals and architecture of integrated supply chain management system(ISCM).In this system,each agent performs one or more supply chain management functions,and coordinates its decisions with other rele-vant agents.ISCM provides an approach to the real timeInt J Adv Manuf Technol(2004)23:197–203 DOI10.1007/s00170-003-1626-xP.Lou(&)ÆZ.ZhouRoom107,D8Engineering Research Center of Numerical Control System,School of Mechanical Science&Engineering, Huazhong University of Science&Technology, 430074Wuhan,Hubei,P.R.ChinaE-mail:louping_98@Y.-P.ChenÆW.AiSchool of Mechanical Science and Engineering, Huazhong University of Science and Technology, 430074Wuhan,Hubei,P.R.Chinaperformance of supply chain function.The integration of multi-agent technology and constraint network for solving the supply chain management problem is pro-posed[6].In[7],Yan et al.develop a multi-agent-based negotiation support system for distributed electric power transmission cost allocation based on the networkflow model and knowledge query&manipulation language (KQML).A KQML based multi-agent coordination language was proposed in[8,9]for distributed and dy-namic supply chain management.However,the coordi-nation mechanisms have not been formally addressed in a multi-agent-based supply chain.In most industries, marketing is becoming more globalised,and the whole business process is being implemented into a complex network of supply chains.Each enterprise or business unit in the SCM represents an independent entity with conflicting and competing product requirements and may possess localised information relevant to their interests.Being aware of this independence,enterprises are regarded as autonomous agents that can decide how to deploy resources under their control to serve their interests.This paperfirst introduces concepts and characteris-tics of agile supply chains and emphasises the impor-tance of coordination in supply chain.Then,it presents an architecture of agile supply chain based on a multi-agent theory and states the agentsÕfunctions and responsibilities.Finally,it presents a CBR contract net protocol for coordination and the correlative algorithm for task allocation in multi-agent-based agile supply chains.2Agile supply chainA supply chain is a network from the topologic structure which is composed of autonomous or semi-autonomous enterprises.The enterprises all work together for pro-curement,production,delivery,and so on[10].There is a main enterprise in the supply chain that is responsible for configuring the supply chain according to the de-mand information and for achieving supply chain value using fundflow,materialflow and informationflow as mediums.There are three discontinuous buffers to make the materialflowfluently and satisfy the change in the demand.On the one hand,as every enterprise manages inventory independently,plenty of funds are wasted.As the demand information moves up-stream,the forecast is inaccurate and the respond to the change in demand is slow[11].Accordingly,the key method for competi-tiveness is improving and optimising supply chain management to achieve integrated,automated,and agile supply chain management and to cut costs in the supply chain.To optimise supply chain management and coordi-nate the processes for materialflow,fundflow and informationflow,it is necessary to make materialflow fluent,quickly fund turnover and keep information integrated.Prompt reconfiguration and coordination is an important characteristic of agile supply chain according to dynamic alliance compositing and de-compositing(enterprise reconfiguration).Agile supply chain management can improve enterprise reconfiguring agility.The agile supply chain breaks through the tra-ditional line-style organizational structure.With net-work technology an enterprise group is formed by a cooperative relationship which includes an enterprise business centre,a production design centre,a supplier,a distribution centre,a bank,a decision-making centre, etc.It reduces the lead time to the market to satisfy customer demand.Agile supply chain without temporal and spatial limits promptly expands the enterprise scale,marketing share and resource by allied enterprise.So,a key factor of the agile supply chain is to integrate heterogeneous information systems adopted in various enterprises.The integration information system can provide marketing information and supplier details.Feasible inventory, quantity and cycle of replenished stock,delivery,etc.is designed using the shared information.It is evident that agile supply chain is a typical distributed system.A multi-agent system(MAS)which is characterised byflexibility and adaptability is suit-able for an open and dynamic environment.Thus MAS is a good method for agile supply chain man-agement.3The concept of agents and MASSome people define an agent as any piece of software or object which can perform a specific given task.Presently the prevailing opinion is that an agent must exhibit three important general characteristics:autonomy,adapta-tion,and cooperation[8,12,13].Autonomy means that agents have their own agenda of goals and exhibit goal-directed behaviour.Agents are not simply reactive,but can be pro-active and take initiatives as they deem appropriate.Adaptation implies that agents are capable of adapting to the environment,which includes other agents and human users,and can learn from the expe-rience in order to improve themselves in a changing environment.Cooperation and coordination between agents are probably the most important feature of MAS. Unlike those stand-alone agents,agents in a MAS col-laborate with each other to achieve common goals.In other words,these agents share information,knowledge, and tasks among themselves.The intelligence of MAS is not only reflected by the expertise of individual agents but also exhibited by the emerged collective behaviour beyond individual agents.Of course various agents have different functions,but some functions are needed for each agent.A generic structure of agents that includes two parts is presented:agent kernel and function mod-ule.Figure1exhibits the generic structure of agents which is a plug-in model.In Fig.1,the generic agent includes the following components:198The mailbox handles communication between one agent and the other agents.The message handler processes incoming message from the mailbox,orders them according to priority level,and dispatches them to the relevant components of the agent.The coordination engine makes decisions concerning the agent Õs goals,e.g.how they should be pursued,when to abandon them,etc.,and sends the accepted tasks to the planner/scheduler.It is also responsible for coordi-nating the agents Õinteractions with other agents using coordination protocols and strategies.The planner and scheduler plans the agent Õs tasks on the basis of decisions made by the coordination engine and on resources and task specifications available to the agent.If not,a message is sent to the coordination en-gine for finding extra resources.The blackboard provides a shared work area for exchanging information,data,and knowledge among function modules.Every function module is an inde-pendent entity.These function modules execute con-currently by the control of planner/scheduler and collaborate through the blackboard.The acquaintance database describes one agent Õs relationships with other agents in the society,and its beliefs about the capabilities of those agents.The coor-dination engine uses information contained in this database when making collaborative arrangements with other agents.The resource database reserves a list of resources (referred to in this paper as facts)that are owned by and available to the agent.The resource database also sup-ports a direct interface to external systems,which allows the interface to dynamically link and utilise a proprie-tary database.The ontology database stores the logical definition of each fact type—its legal attributes,the range of legal values for each attribute,any constraints betweenattribute values,and any relationship between the attributes of that fact and other facts.The task/plan database provides logical descriptions of planning operators (or tasks)known to the agent.4Multi-agent-based agile supply chain management Multi-agent-based agile supply chain management per-forms many functions in a tightly coordinated manner.Agents organise supply chain networks dynamically by coordination according to a changing environment,e.g.exchange rates go up and down unpredictably,customers change or cancel orders,materials do not arrive on time,production facilities fail,etc.[2,14].Each agent performs one or more supply chain functions independently,and each coordinates his action with other agents.Figure 2provides the architecture of multi-agent-based agile supply chains.There are two types of agents:functional agents and mediator agents.Functional agents plan and/or control activities in the supply chain.Mediator agents play a system coordinator role s by promoting coopera-tion among agents and providing message services.Mediator agents dispatch the tasks to the functional agents or other mediator agents,and then those func-tional or mediator agents complete the tasks by coordi-nation.All functional agents coordinate with each other to achieve the goals assigned by mediator agents.The mediator-mediator and mediator-agent communication is asynchronous,and the communication mode can be point-to-point (between two agents),broadcast (one to all agents),or multicast (to a selected group of agents).Messages are formatted in an extended KQML format.The architecture is characterised by organizational hier-archy and team spirit,simplifying the organisational architecture and reducing the time needed to fulfil the task.The rest of this section briefly describes each of the mediator agents underdevelopment.Fig.1Generic structures of agents199–Customer mediator agent:This agent is responsible for acquiring orders from customers,negotiating with customers about prices,due dates,technical advisory,etc.,and handling customer requests for modifying or cancelling respective orders,then sending the order information to a scheduling mediator agent.If a customer request needs to be re-designed,the infor-mation is sent to a design mediator agent,then to a scheduling mediator agent.–Scheduling mediator agent:This agent is responsible for scheduling and re-scheduling activities in the fac-tory,exploring hypothetical ‘‘what-if’’scenarios for potential new orders,and generating schedules that are sent to the production mediator agent and logis-tics mediator agent.The scheduling agent also acts as a coordinator when infeasible situations arise.It has the capability to explore tradeoffs among the various constraints and goals that exit in the plant.–Logistics mediator agent:This agent is responsible for coordinating multi-plans,multiple-supplier,and the multiple-distribution centre domain of the enterprise to achieve the best possible results in terms of supply chain goals,which include on-time delivery,cost minimisation,etc.It manages the movement of products or materials across the supply chain from the supplier of raw materials to the finished product customer.–Production mediator agent:This agent performs the order release and real-time floor control functions as directed by the scheduling mediator agent.It monitors production operation and facilities.If the production operation is abnormal or a machine breaks down,this agent re-arranges the task or re-schedules with the scheduling mediator agent.–Transportation mediator agent:This agent is responsible for the assignment and scheduling of transportation resources in order to satisfy inter-plant movement specified by the logistics mediator agent.It is able to take into account a variety oftransportation assets and transportation routes in the construction of its schedules.The goal is to send the right materials on time to the right location as assigned by the logistics mediator agent.–Inventory mediator agent:There are three invento-ries at the manufacturing site:raw product inven-tory,work-in-process inventory,and finished product inventory.This agent is responsible for managing these inventories to satisfy production requirements.–Supplier mediator agent:This agent is responsible for managing supplier information and choosing suppli-ers based on requests in the production process.–Design mediator agent:This agent is responsible for developing new goods and for sending the relevant information to the scheduling mediator agent for scheduling,as well as to the customer mediator agent for providing technological advice.5Coordination in a multi-agent-based agile supply chainCoordination has been defined as the process of man-aging dependencies between activities [15].One impor-tant characteristic of an agile supply chain is the ability to reconfigure quickly according to change in the envi-ronment.In order to operate efficiently,functional entities in the supply chain must work in a tightly coordinated manner.The supply chain works as a net-work of cooperating agents,in which each performs one or more supply chain functions,and each coordinates its action with that of other agents [5].Correspondingly,a SCMS transforms to a MAS.In this MAS,agents may join the system and leave it according to coordinating processes.With coordination among agents,this MAS achieves the goal of ‘‘the right products in the right quantities (at the right location)at the right moment at minimalcost’’.Fig.2An architecture of multi-agent based agile supply chain management2005.1Contract net protocol combined withcase-based reasoningThe contract net is a negotiation protocol(CNP)pro-posed by Smith[15].In the CNP,every agent is regarded as a node,such as a manager or a contractor.The manager agent(MA)is responsible for decomposing, announcing,and allocating the task and contractor agent(CA)is responsible for performing the task.This protocol has been widely used for multi-agent negotia-tion,but it is inefficient.For this reason,contract net protocol is combined with case-based reasoning(CBR).In case-based reasoning(CBR),the target case is defined as problem or instance which is currently being faced,and the base case is problem or instance in the database.CBR searches the base case in the database under the direction of the target case,and then the base case instructs the target case to solve the problem.This method is efficient.But at the very beginning,it is very difficult to set up a database which includes all problems solving cases.The cases may be depicted as follows:C¼\task;MA;taskÀconstraint;agentÀset> Here,MA is task manager.Task-constraint repre-sents various constraint conditions for performing the task,depicted as a vector{c1,c2,c3,...,c m}.Agent-set is a set of performing the task as defined below:Agent set¼\sub task i;agent id;cost;time;resource>f gtask¼[ni¼1sub task iIn the supply chain,the same process in which a certain product moves from the manufacturer to the customer is performed iteratively.So,case-based rea-soning is very efficient.Consequently,combining con-tract net protocol with CBR could avoid high communicating on load,thus promoting efficiency.The process can be depicted as follows(Fig.3).5.2The algorithm for task allocation baseon CBR contract net protocolThere are two types of agents in the supply chain, cooperative and self-interested agents.Cooperative agents attempt to maximise social welfare,which is the sum of the agents utilities.They are willing to take individual losses in service of the good of the society of agents.For example,function agents come from the same enterprise.In truth,the task allocation among cooperative agents is combinational optimisation prob-lem.Self-interested agents seek to maximise their own profit without caring about the others.In such a case,an agent is willing to do other agentsÕtasks only for com-pensation[16].Function agents,for example,come from different enterprises.In the following section the algorithm for task allo-cation among self-interested agents based on CBR contract net protocol will be addressed.Before describ-ing the algorithm,there are some definitions that must be clarified:Task—A task which is performed by one agent or several agents together:T=<task,reward,con-straints>,where task is the set of tasks(task={t1,t2,..., t m}),reward is the payoffto the agents that perform the task(reward={r1,r2,...,r m}),and constraints refer to the bounded condition for performing the task(con-straints={c1,c2,...,c n}).Agent coalition(AC)—A group of agents that per-form task T,described as a set AC={agent i,i=1,2,...,n}.Efficiency of agent—Efficiency of an agent i is de-scribed as follows:E i¼rewardÀcostðÞ=costð1Þwhere reward is the payoffto the agent performing task T,and cost refers to that spend on performing the task. If agent i is not awarded the task,then E i=0.Efficiency of agent coalition—E coalition¼rewardÀX micost iÀh!,X micost iþh!ð2Þwhere reward is the payoffof the agent coalition per-forming task T;cost i refers to that spend on performing task t i;and h is the expense on forming coalition,which is shared by the members of the coalition.If the coalition is not awarded task T,then E coalition<=0.6Algorithm:1.After MA accepts the task T=<task,reward,constraint>(task is decomposable),then it searches the database.2.If itfinds a corresponding case,it assigns the task orsubtask to the related agents according to the case, and the process is over3.If no case is found,then the task T is announced toall relevant agents(agent i,i=1,2,...n).4.The relevant agents make bids for the task accord-ing to their own states and capabilities.Thebid Fig.3CBR contract net process201from agent i can be described as follows:Bid i =<agentid i ,T i ,price i ,condition i >,where i ex-presses the bidding agent (i =1,2,...,h );agentid i is the exclusive agent identifier;T i is the task set of agent i Õs fulfilment;price i is the recompense of agent i fulfilling the task T i ;and condition i is the constraint conditions for agent i to fulfil the task T i .5.If [1 i h&T i then the task T can not be performed.Otherwise MA makes a complete combination of the agents,namely to form a number of agent coalitions (or agent sets,amounting to N =2h )1).6.First MA deletes those agent coalitions where no agents are able to satisfy the constraint condition.Next the rest of the coalitions are grouped by the number of agents in coalitions and put into set P (P ={P 1,P 2,...,P h })in order of the minimum re-compense increase of the coalitions,where P i is the set of agent coalitions,including i agents.7.MA puts the first coalition from each group P i(i =1,2,...,h )into set L ,and if L is null then it returns to (10),otherwise it calculates the minimum re-compense of each coalition as follows:Min Pm iprice i ÃT is :t :P h i ¼1T i TP m icondition i constraitThen it searches for the minimal agent coalition AC min from the set L .8.MA sends the AC min to the relevant agents,namely MA requests that these agent fulfil the task to-gether.The relevant agents calculate the E coalition and E i according to Eqs.1and 2.IfE coalition !max miE i ,then all agents in the AC minaccept the proposal to form a coalition to perform the task T together.MA assigns the task to the AC min ,and the process is over.Otherwise it deletes the AC min from P i and returns to (7).9.If the relevant agents accept the task or subtask,then MA assigns the task to them.The process is over.If some agents cannot accept the subtask and the stated time is not attained,then it returns to (3),otherwise it returns to (10).10.The process is terminated (namely the task cannotbe performed).After all processes have been completed,case-based maintenance is required to improve the CBR.Thus efficiency is continuously promoted.6.1An example–A simple instantiation of a supply chain simulation is presented here and the negotiating process among agents is shown.In this supply chain instantiation,thetransportation mediator agent (TMA)has a transporttask T ,in which it has to deliver the finished product to the customer within 15units of time and must pay 1500monetary units for it,that is T =<t ,1500,15>.Four transport companies can perform task T .Each company is an autonomous agent,that is four agents,agent A,agent B,agent C and agent D.So the TMA announces the task T to the four agents.Then the four agents make a bid for the task T as shown in Table 1.–So the four agents can form 24)1coalitions (see Fig.4),which are put into set P .Cooperation between agents in the coalition requires expense and the ex-pense for forming the coalition increases with the growth of in coalition size.This means that expanding the coalition may be non-beneficial.The expense of each agent in forming a coalition h is 100.First,the coalitions in which no agents can satisfy the constraint conditions are deleted from the set P .The rest of the coalitions are grouped by the number of agents in the coalition and ordered according to the recompense of each group that was increased due to the coalition,namely P 1={B},P 2={{A,B},{A,C},{B,C},{A,D},{B,D}},P 3={{A,B,C},{A,B,D},{B,C,D}},P 4={{A,B,C,D}}.Then the cost and efficiency of coalition {B},{A,C}and {A,B,C}are calculated as follows:Price f A ;B g ¼Min ð800x 1þ1200x 2Þs :t :20x 1þ12x 2 15x 1þx 2!1x 1!0:x 2!0Price f A ;B ;C g ¼Min ð800y 1þ1200y 2þ2000y 3Þs :t :20y 1þ12y 2þ5y 3 15y 1þy 2þy 3!1y 1!0:y 2!0;y 3!Fig.4Agent coalition graphTable 1The bids of four agents Agent Id Price Conditions Agent A 80020Agent B 120012Agent C 20005AgentD25003202the following result can be obtained:Price{B}=1200; x1=0.3750,x2=0.6250,Price{A,B}=1050;and y1= 0.3750,y2=0.6250,y3=0.The above result shows that agent B does not attend the coalition{A,B,C},that is both agent B and coalition{A,B}can fulfill the task and satisfy the constraint conditions.According to Eqs.1 and2,E A,E B,E{A,B}:E A=0(because TMA does not assign the task to A.),E B=(1500)1200)/1200=0.25, E{A,B}=(1500)1050)2*100)/(1050+2*100)=0.2can be obtained.Because of E{A,B}<max{E A,E B},agent B does not agree to form a coalition.Therefore,the TMA se-lects agent B to fulfil the task.7ConclusionsIn this paper,the concept and characteristics of agile supply chain management are introduced.Dynamic and quick reconfiguration is one of important characteristics of an agile supply chain and agile supply chain man-agement is one of the key technologies of agile manu-facturing based on dynamic alliances.As agile supply chain is a typical distributed system,and MAS is effi-cient for this task.In the architecture of agile supply chain management, the supply chain is managed by a set of intelligent agents that are responsible for one or more activities.In order to realise the agility of supply chains,coordination amongst agents is very important.Therefore,it can be suggested that contract net protocol should be combined with case-based reasoning to coordinate among agents. Acknowledgement The authors would like to acknowledge the funding support from the National Science Fund Committee (NSFC)of China(Grant No.5991076861).References1.Goldman S,Nagel R,Preiss K(1995)Agile competitors andvirtual organization.Van Nostrsand Reinhold,New York, pp23–32,pp158–1662.Yusuf YY,Sarhadi M,Gunasekaran A(1999)Agile manu-facturing:the drivers,concepts and attributes.Int J Prod Eng 62:33–433.Gunasekaran A(1999)Agile manufacturing:A framework forresearch and development.Int J Prod Eng62:87–1054.Fox MS,Chionglo JF,Barbuceanu M(1992)Integrated chainmanagement system.Technical report,Enterprise Integration Laboratory,University of Toronto5.Shen W,Ulieru M,Norrie DH,Kremer R(1999)Implementingthe internet enabled supply chain through a collaborative agent system.In:Proceedings of agentsÔ99workshop on agent-based decision support for managing the internet-enabled supply-chain,Seattle,pp55–626.Sandholm TW,Lesser VR(1995)On automated contracting inmulti-enterprise manufacturing.Advanced Systems and Tools, Edinburgh,Scotland,pp33–427.Beck JC,Fox MS(1994)Supply chain coordination via medi-ated constraint relaxation.In:Proceedings of thefirst Canadian workshop on distributed artificial intelligence,Banff,Alberta, 15May19948.Chen Y,Peng Y,Finin T,Labrou Y,Cost R,Chu B,Sun R,Willhelm R(1999)A negotiation-based multi-agent system for supply chain management.In:Working notes of the ACM autonomous agents workshop on agent-based decision-support for managing the internet-enabled supply-chain,4:1–79.Wooldridge M,Jennings NR(1995)Intelligent agents:theoryand practice.Knowl Eng Rev10(2):115–15210.Barbuceanu M,Fox MS(1997)The design of a coordinationlanguage for multi-agent systems.In:Muller JP,Wooldridge MJ,Jennings NR(eds)Intelligent agent III:agents theories, architecture and languanges(Lecture notes in artificial intelligence),Springer,Berlin Heidelberg New York,pp341–35711.Hal L,Padmanabhan V,Whang S(1997)The Bullwhip effect insupply chains.Sloan Manag Rev38(4):93–10212.Yung S,Yang C(1999)A new approach to solve supply chainmanagement problem by integrating multi-agent technology and constraint network.HICASS-3213.Yan Y,Yen J,Bui T(2000)A multi-agent based negotiationsupport system for distributed transmission cost allocation.HICASS-3314.Nwana H(1996)Software agents:an overview.Knowl Eng Rev11(3):1–4015.Smith RG(1980)Contract net protocol:high-level communi-cation and control in a distributed problem solver.IEEE Trans Comput29(12):1104–111316.Barbuceanu M,Fox MS(1996)Coordinating multiple agentsin the supply chain.In:Proceedings of thefifth workshop on enabling technology for collaborative enterprises(WET ICEÕ96).IEEE Computer Society Press,pp134–14117.Jennings NR,Faratin P,Norman TJ,OÕBrien P,Odgers B(2000)Autonomous agents for business process management.Int J Appl Artif Intell14(2):145–1818.Malone TW,Crowston K(1991)Toward an interdisciplinarytheory of coordination.Center for coordination science tech-nical report120,MIT Sloan School203。
AGENT技术报告
AGENT技术报告Agent软件工程(AOSE:Agent-Oriented Software Engineering)所谓Agent是指驻留在某一环境下能够自主(Autonomous)、灵活(Flexible)地执行动作以满足设计目标的行为实体。
这一概念定义将Agent视为是软件工程化开发所需的一个计算抽象和高层的概念模型。
作为一个计算抽象,Agent能够实施自主的计算行为,这有别于对象、线程、过程和函数等计算单元。
作为一个概念模型,Agent概念既可以用于直观地描述现实世界中一个个具体的事物;也可以用于表示计算机世界中基本的软件运行单元。
将由两个或者更多个相对独立同时又相互作用的Agent所构成的系统称为多Agent系统(MAS:Multi-Agent System),并将由一个或者多个Agent所构成的系统称为面向Agent的系统。
Agent的特点主要体现在以下几个方面:Agent驻留在环境中并需要与环境进行交互Agent是行为实体Agent的行为具有一定的灵活性,主要体现为:反应性(Reactive)、社会性(Social)和自发性(Proactive)。
Agent的概念和技术出现在分布式应用系统的开发之中,并表现出明显的实效性。
以下列举几项人们在分布式应用方面所从事的涉及Agent的研究和开发工作,从中我们可以初步体会到Agent概念和技术的意义。
1. 利用Agent技术改善Internet应用例如,研制"信息找人"的Agent。
它具有"需求"与"服务"的集散能力,它接受信息分布者有关信息要点的注册,以及信息查询者有关信息需求要点的注册。
该Agent根据这些信息,主动通知用户谁能够提供其所需信息,或主动通知信息提供者谁目前需要其所能提供的信息。
2. 利用Agent技术实现并行工程的思想例如,利用Agent技术开发工作流管理者。
MEDIATOR-BASED RECOVERY MECHANISM FOR MULTI-AGENT
专利内容由知识产权出版社提供
专利名称:MEDIATOR-BASED RECOVERY MECHANISM FOR MULTI-AGENT SYSTEM
发明人:LEE, Habin,SHEPHERDSON, John, William 申请号:GB 2004 000903 申请日:2004 0303 公开号:WO04 /086163P 1 公开日:2004 1007
摘要:A method of recovering the status of a collaboration between a plurality of component agents in a multi-agent systems architecture, the method comprising: processing collaboration information forwarded by a mediator agent for each component agent; maintaining a collaboration processing status information record derived from the collaboration information provided by each collaborating agent to the mediator agent; and in the event that a device which affects the collaboration suffers an event which causes one or more component agents to lose its collaboration status,n status using one or more of said collaboration processing status information records.
美国赛博空间作战行动Cyberspace _Operations
CHAPTER II
CYBERSPACE OPERATIONS CORE ACTIVITIES
Introduction................................................................................................................II-1
3.应用
a、本出版物中确立的联合原则适用于联合参谋部、作战司令部指挥官、下属统一司令部、联合特遣部队、这些司令部的下属部门、各军种和作战支持机构。
b、本出版物中的指南具有权威性;因此,除非指挥官认为特殊情况另有规定,否则将遵循这一原则。如果本出版物的内容与出版物的内容发生冲突,则以本出版物为准,除非参谋长联席会议通常与其他参谋长联合会成员协调,提供了更为现行和具体的指导。作为多国(联盟或联盟)军事指挥部一部分的部队指挥官应遵循美国批准的多国原则和程序。对于未经美国批准的条令和程序,指挥官应评估并遵循多国司令部的条令与程序,如果适用并符合美国法律、法规和条令。
•联合职能部门和网络空间运作
第三章权限、角色和职责
•简介III-1
•当局III-2
•角色和职责
•法律考虑因素III-11
第四章规划、协调、执行和评估
•联合规划过程和网络空间运营
•网络空间运营规划考虑因素
•对网络空间的情报和操作分析支持
运营计划IV-6
•针对性IV-8
•网络空间部队的指挥与控制
Lucent Technologies
EXPLORING AGENT-BASED WIRELESS BUSINESS MODELS AND DECISION-SUPPORT APPLICATIONS IN ANAIRPORT ENVIRONMENTY. Wang(1), L. Cuthbert(1), Francis J. Mullany(2), P. Stathopoulos3), V. Tountopoulos(3), M. Senis(4),(1)Department of Electronic Engineering, Queen Mary, University of London,327 Mile End Road, London, UKTel: +44 20 7882 7408, Fax: +44 20 7882 7997Email: yapeng.wang/laurie.cuthbert@(2) Bell Labs ResearchLucent TechnologiesSwindon, UKTel: +44 1793 77 6788Email: mullany@(3)National Technical University of AthensDepartment of Electrical and Computer Engineering, Telecommunications Systems Laboratory9 Heroon Polytecheiou Street, Zographou 15773, Athens, GREECETel: +30 210 772 1495, Fax: +30 210 772 2534,Email: vttounto@telecom.ntua.gr(4)Athens International Airport SAInformation Technology & Telecommunications Department, Business Development Division Spata 19019, ATC & CONTROL Tower Building (32), GREECETel: +30 210 35 36 209, Fax: +30 210 35 37 782Email: msenis@aia.grABSTRACTThis paper describes an intelligent communication and decision support system for providing wireless services in an airport environment. A novel agent-based business model is proposed and the value chain is analysed for wireless applications. This system is studied and developed within the scope of the IST ADAMANT project, where the Athens International Airport (AIA) is used as the trial environment. First of all, a set of advanced, realistic decision-support application scenarios enhancing the airport facilities both for the passengers and for the airport staff is identified. Most of the applications can be summarised as location-based personalised services. They refer both to airport internal users and to passenger users. In order to provide these services, location-sensitive Service Level Agreements (SLAs) and Radio Resource Management (RRM) are introduced. The design of such a system is envisaged based on a generic, multi-agent architecture, which is also presented in this paper.Keywords: wireless application, multi-agent system, wireless business model, wireless SLA, radio resource management1. INTRODUCTIONThe advance in wireless communication market enables users to experience enhanced delivery of personalized services through the integration of various radio technologies. However, the existing management platforms cannot ensure the scalability and reliability for the interworking of different networks. Therefore, the need for research activities in network management by developing and validating flexible architectures for the support of heterogeneous infrastructures is apparent.This paper presents an Intelligent Decision and Management system (IDMS) for providing wireless services in an airport environment. This system is studied and developed within the scope of the IST ADAMANT (A irport D ecision A nd MA nagement N e T work) project, where AIA is used as a trial environment. The envisaged system will be capable of handling crisis situations, as its benefits are clearer under such circumstances. The approach adopted is generic covering any mode of transport; although within this paper it is limited to an airport environment, as the “hot spots” that are naturally generated there provide some of the most difficult challenges.A system, as generic as this, has not been implemented before and it is technically challenging.A set of advanced, realistic application scenarios enhancing the airport facilities both for the passengers and for the airport staff is identified, which make obvious the need for a scalable anticipatory environment able to provide roaming/location-based and personalized services based on Service Level Agreements. These scenarios include the Internal Bus Arrival Time Information Estimation, Flight Information Display on Demand, Mobile Video/Photo Information for Security and Surveillance, Automatic Billing Application for Airport Fuelling Companies, and Passenger Support in the Area of the Main Terminal Building.To meet the requirements imposed by the above scenario, an agent-based architecture is proposed. The multi-agent architecture forms a framework for implementing the interactions between the very different types of entities involved in the proposed scenarios, whether at the service level or at the network transport level. This type of architecture also has the advantage of scalability and robustness of operation in congestion and emergency situations.The SLA management for location-sensitive applications and business models for wireless applications in an airport environment are analysed. A hybrid business model balances the benefits of all business roles, where appropriate value chains ensure the market place will be running smoothly.2. SYSTEM OVERVIEW.This section presents briefly the operational environment for the functionality of the IDMS. More specifically, it describes the airport environment main structure, the airport user groups, and the existing set of services and wireless telecommunication infrastructure.The airport environment consists of the core building which is the main terminal (MTB) and satellite building, the administration buildings and the related building of all the airport providers (such as handlers, police, fire brigade, the Air-Traffic Control Tower), as well as the outdoor environment which includes the access motorway, the new Metro station and the parking spaces. Four different categories of potential users, within this operational environment, can be identified: passengers, meters and greeters, the airport staff and other airport Service & Content Providers (i.e. security companies, airlines, duty-free and facility companies).Different communications services are targeted at the different user categories listed above. For the provision of these services, a telecommunication infrastructure has been developed. GSM/GPRS, WLAN and TETRA are the wireless technologies used. An IP backbone network is provided for Internet services and the PABX network for conventional telephony services. The airport holds the Airport Services and Operations Centre (ASOC), which combines all critical airport operations mechanisms and controls. The Airport Operational Database (AODB) contains real-time information about the arriving and departing flights and other flight related information (gates, stands etc). This information is distributed within the airport community via the Flight Information Display System (FIDS). All the airport data is processed through a central security system, which is called the Universal Flight Information System (UFIS). This provides technical and logical functions for an effective and reliable data processing of operational flight information and holds the central UFIS database of the airport.3. APPLICATION SCENARIOS.In this section, the set of applications that the proposed system supports for enhancing the operational environment of the airport is described.3.1 Internal Bus arrival time informationThis application aims at developing a real-time component that estimates the waiting time of a passenger at the bus stop, prior to the arrival of the internal bus service of the airport. Towards this end, the data transfer functionality of either the airport TETRA system or the GPRS functionality of the GSM system is exploited. Real-time data regarding the location (from on-board GPS units) and the speed of the buses will be sent to the ASOC,where suitable software will estimate their arrival time at the bus stops, within the airport area. From the ASOC centre, this information will be distributed to every bus stop, where a LED Display or a flat screen will be available, or even to individuals’ hand-held devices.3.2 Flight Information Display System (FIDS) on demandThis application will provide on-demand arrival and departure information on portable wireless terminals, based on the existing non-personalized UFIS flight information system of the airport. This service is to be considered as an extension of the existing non-personalized UFIS applications, as far as new interfaces and communication infrastructure are concerned. Target users are the airport staff, ground handlers, airlines, concessionaires and passenger service providers. This service will be fully personalised according to individual customer or group preferences. For example, ground handlers are more interested in the exact time of arrival and the location of the aircraft, whereas concessionaires are more likely to be interested in time delays or predictions of the number of passengers transiting in the next hour.The system interfaces with the network resource management ADAMANT subsystem, providing relevant information to aid the resource management subsystem in its provision of pro-active congestion management mechanisms (e.g. the dropping of less critical user groups). Security issues will also be taken into consideration.3.3 Mobile video/photo information for security and surveillanceThis scenario concerns the development of a mobile photo/video camera system for the real-time transfer of photos or video to the ASOC for security and surveillance purposes and back to the security/emergency staff. Potential users of this system are the airport security personnel, airport police, fire brigade and ambulance services etc. Transmitting real time photographs and/or video of an emergency situation or accident, by the ASOC Intelligent Decision and Management system, will provide instantly the necessary elements for the immediate evaluation of the situation and the rapid activation of the necessary emergency-response teams. The remote monitoring of the crisis event through instant photos or video will result in more effective crisis evaluation and measures. The images and/or video will be directed to the system users by the ASOC, according to their profile, location, the overall situation and the user’s preferences. This application will exploit commercial off-the-shelf equipment enhanced with additional security and authentication mechanisms and the ADAMANT network resource management features, in order to provide connectivity to the security personnel under all network congestion circumstances.GSM/GPRS and W-LAN have the capability to transfer multimedia data in order to provide real-time visual information, according to the users’ location and the overall situation. The user terminal comprises a PDA equipped with a GPRS and IEEE802.11b WLAN PCMCIA cards and a GPS device in order to extract precise location information. The recently deployed Multimedia Messaging Service in GSM/GPRS networks can be an enabling technology for such an application. In the longer term, video streaming may be become possible in areas with W-LAN coverage or over future 3G networks. This service complements existing networks of fixed cameras that provide surveillance information from certain airport areas.3.4 Automatic billing application for Airport Fuelling companiesThe aim of this application is the development of a real time component that will automatically charge the amount of fuel loaded on to an aircraft from the respective fuelling company. The IMDS utilises the SDS functionality of the TETRA system (TETRA 2003). Moreover, it combines the information granted from airport’s existing FIDS system with locally stored information from fuelling trucks and drivers.3.5 Passenger support in the area of the Main Terminal BuildingThis is the core application of the project, aiming at providing passengers with personalised and location-based information related to the airport, as well as broadband Internet access during their stay to the main terminal ers of this service can access the content through their mobile terminals (PDAs or portable computers), or fixed PCs located inside the airport premises.Services depend on passenger preference profiles, as well as the status (e.g. departing, arriving, or delayed) of the user’s flight.The service will be controlled by a session manager platform able to:§Provide the passenger with the necessary flight information and according to his/her profile and flight status, guide him/her through the departure procedure of checking in, clearing security, and reporting to the departure gate.§Allow the airport to track the passenger.§Provide personalised information with respect to other airport commercial facilities such as restaurants, shopping, etc., especially to passengers who get to the gate early, or to business travellers making use of the airport lounges. Flight delays can increase the demand enormously, as travellers can be encouraged to use these commercial facilities. To this end, the IMDS can exploit knowledge about the user preferences and the type of trip (e.g. regular business travellers or travel for leisure).§Inform arriving passengers about means of transport (to and from the airport), accommodation, and local tourist information.This application will help the airport authority to offer a value-added service and increase the passenger satisfaction, and on the other hand allow them to make more efficient use of the time spent at the airport premises and to increase the concessionaires’ incomes. Finally in this system, it is possible to extend the coverage area to other "hotspots" like conference halls, hotels, restaurant and bars, etc.4. THE AGENT APPROACH OF SYSTEM ARCHITECTURE.This section describes the main agent architecture for the IDMS in the airport area. IDMS deals with resource management strategies for GSM/GPRS, WLAN and TETRA and addresses SLA management issues in the context of providing advanced services to the airport users. The IDMS architecture is based on the “one-stop-shop” business concept, which identifies all the processes that should be in place, in order to include a service in the business service portfolio. In that respect, in such a scalable anticipatory environment, the following business entities can be identified: the users, the Service Providers, the Network Providers for GSM/GPRS, WLAN and TETRA infrastructures and the Content Providers.The development of the IDMS is based on Multi-agent systems (MAS) (Walter Brenner et al 1998). This section introduces the components that comprise the main agent architecture and provide the framework for the interaction between the entities identified previously. More specifically, the following generic agent components can be defined:q User Agents (UAs);q User Resource Agents (URA);q Location Agent (LA);q Service Broker Agent (SBA);q Service Provider Agents (SPAs);q Content Provider Agents (CPAs);q Resource Broker Agent (RBA);q Network Provider Agents (NPAs);The rest of this section is dedicated to the analysis of these agents and the description of their role in the IDMS.The UA manages all the information related to the user terminal and behaviour in the airport, such as user preferences, travel information, privacy issues etc. Every user of the IDMS owns a UA, located inside the user terminal. In cases where a terminal cannot support the UA software, a Proxy User Agent located at the SBA can be used. The UA is activated any time the user registers to the IDMS. Its main role is to set and update the user profile. Any time the user wants to make use of a specific service, the UA communicates with the SBA and sends an application request. The UA also performs SLA monitoring functionality by monitoring some crucial SLA parameters, such as the received bit rate.Another important functionality of the UA is to update the user’s location at certain intervals, in order to provide location-based services. In that respect, the UA sends location update messages to a LA via the SBA, in order to inform it about the current position of the corresponding user. The LA holds a database, which keeps records of the current position of all the users registered to the IDMS. It can then maintain information about the geographical location of the user at any time.The SBA plays a key role in the whole architecture, acting as a mediator agent by providing the interface between the UAs and the SP agent components. The SBA performs on behalf of the IDMS, subscription and identity checks for incoming users. Furthermore, the SBA maintains user profiles containing information such as the set of services and applications that the corresponding users are willing to subscribe to and the reference quality level at which a specific service should be provided. The SBA undertakes the responsibility of prioritizing and delivering the incoming messages to the appropriate agents. The prioritization strategies can be based on many parameters, such as the type of the request, the SLA management policies and the preference settings of the UA. According to such information, the IDMS can decide about the priority given to multiple incoming service requests, with the aim of maximising the IDMS’s profit.The SBA can, also, act as a facilitator for SLA negotiation and notification functionality between the UAs and the SPAs. It is responsible for transferring and supporting SLA messages both from and to the SPAs. These messages may involve the SLA proposal of an SPA in response to the service request of a UA, the SLA response of the UA to the SPA and other SLA renegotiation messages.The SPA maps to the existing entities of the airport environment for the provision of the available services. It is mainly responsible for the accomplishment of the role of the Service Provider to the end users. So, the role of the SPA is to respond to the requests from the SBA and offer the requested services to the UA, according to certain criteria and to retrieve pertinent information from local databases. In that respect, it communicates with the CPA, which provides service content information messages regarding the operation of the available services. The SPA can, also, perform SLA management functionality for the negotiation and monitoring of the SLAs with the UAs, through the SBA, and report any violations of the agreed SLA contracts.The RBA is the gateway of the network domain with the other entities. Its main task is to find the best NPA to serve the incoming requests from an SPA. In that respect, the RBA should exploit theinformation gathered from the service domain and report to the most appropriate NPA about the facilitation of the specific service request. The incoming messages may involve the service type and other user related information. The RBA, also, interacts with the LA, in order to receive the user’s location in the system. It, can, then decide the appropriate NPA with resource availability for location-based services.The behaviour of the RBA is more important for the IDMS in cases of lack of resources, due to unexpected events, such as emergency cases and flight delays, which lead to local hot spots. In such cases, the challenge for the RBA is to find reliable solutions from the most appropriate NPA. In that respect, it should monitor the performance of the underlying networks, in order to identify the current congestion levels of the available networks and report any degradation in the system performance. So, at certain intervals, the RBA is informed by the NPA about (or alternatively infers itself) the current network status. Subsequently, the RBA can perform adequate functionality for finding the most appropriate NPA and ask it for resources. This functionality is crucial, especially in cases of high priority service requests, such as in emergency cases.The NPA (network provider agent) is that agent in the system with primary responsibility for provisioning of the transport function for the services supported by the system. Hence, the role of a NPA is twofold:1.Negotiation. NPAs “represent” the networks in the system’s efforts to match the requirednetwork transport capabilities to the services requested by the user. A resource broker agent will contact one or more NPAs and by some mechanism, come to a contracted arrangement whereby one or more NPAs undertake to reserve and allocate network resources to the transport link needed for an agreed price.2.Resource management. A given NPA organises its own internal resources, either in isolationor with the aid of other agents, to supply the agreed transport links with the contracted QoS arising from the first role.In the context of the IDMS, there is one NPA for each of the access networks that are associated with the system, i.e. the WLAN system, the various GSM/GPRS operators, the TETRA network, etc. It should be noted that the NPA functionality may be distributed among a number of sub-agents within the network (SHUFFLE 2001).The URA (user resource agent) is an optional agent in the user terminal, with the role of collaborating with NPAs and/or other URAs, to control the user terminal’s use of resources so as to optimise the operation of the user’s transport link over the radio interface. The resources over which the URA may have influence include the air interface and usage of battery power.Based on the description provided above, Figure 1 summarises the system agent architecture for the accomplishment of the main objectives of the IDMS. As it can be seen, some of the agent components hold interactions with external databases, which then (partially) represent the necessary interface between the agent components of the IDMS and the external world.Figure 1: System Agent Architecture5. SLA MANAGEMENT AND BUSINESS PROCESS MODEL.5.1 SLA Management framework.As users move through an airport, they are roaming through the network, and the SLA management provided should be sensitive to the local conditions, adjusting SLA guarantees according to the roaming and location conditions as well as promptly notifying the user of these changing conditions. Location dependency of SLA is envisaged when users move between locations with different coverage characteristics or with different congestion situations (e.g. different cells of a GSM/GPRS/UMTS network) or when users move between locations served by different network technologies (e.g. UMTS / WLAN / TETRA).In addition, in order to manage congestion and crisis scenarios, a service provider should be able to define policies to prioritise the allocation of resources to the most critical services and customers, to deliver the best possible service levels based on combination of SLA agreed with the customers and current conditions of the network.The SLA management framework defined here is used to develop SLA templates and SLA contracts for service subscribers in which the service level objectives may change as the user travels to or moves through the airport.It includes components to: provide resource management with contracted SLA terms in order to allocate network resources (e.g., bandwidth) accordingly; monitor the service level experienced; notify compliance or non-compliance of the service level objectives; provide reporting functions for the detailed analysis of the service level offered by the network; communicate with service components to adjust the service behaviour based upon the management policies set by the provider.Performing SLA Management also implies coordination and exchanging information between providers in the value-chain and between providers and customers. Such coordination and information exchange is formalized in ADAMANT through the definition of business process models and the corresponding business interactions amongst providers, focusing on service management processes(e.g., service subscription, service assurance, service planning).5.2 Business models and value chain.The business model of the ADAMANT system involves several different market players and can be characterized by multiple relations which, depending on the provided service, might differ.In general, the following players are expected to be involved in the ADAMANT business model:q Customers/Users:In general, we can distinguish between the User of a service and the Customer that subscribes to that service and negotiates a SLA with the Service Provider. In some cases they might coincide,e.g. in the case of passengers, in other cases they might differ, e.g. in the case in which a companysubscribes to a service for a certain number of its employees. In ADAMANT, Customers can be passengers, members of the Athens International Airport (AIA), Ground Handlers, etc.q Service Providers (SP):An SP is a company or organization that provides wireless communication services as a business.SPs may operate networks, or they may simply integrate the services of other providers in order to deliver a total service to their Customers. Providing a wireless communication service to any one end Customer may involve multiple SPs, where one provider may “sub-contract” to other providers to fulfil the Customer’s needs. According to the specific nature of the services provided we can distinguish among Content Providers, Application Service Providers, Service Integrators / Content Brokers, Internet Service Providers etc. In the ADAMANT context, depending on the specific application, Content Providers may be the AIA, e.g. providing flight information, or the Airport Concessionaires, e.g. airlines and travel agencies providing information about flight offers, or shops and duty frees providing information about special offers. The role of Application Service Provider, Service Integrator and Content Broker is typically assumed by AIA (or more precisely, by some of its internal departments, e.g. the ASOC or IT&T departments), who acts as a “One-Stop-Shop” for services offered to the airport community. The role of Internet Service Providers is again covered by AIA, through its IT&T department. Other ISPs may be involved in the ADAMANT application scenarios, such as OTENet, and Panafonet.q Network Providers:These provide wireless communication services on an underlying network infrastructure, where, in this context,the services are basic telecommunication services, such as voice and data channels, IP capacity etc. To be precise, Network Providers are actually a sort of Service Providers, i.e.providers of basic network connectivity services, so they can be considered as Network Service Providers. We can distinguish the following sub-roles for Network Providers, according to the network technology used:•Mobile Operators provide voice and data services on GSM / GPRS (and UMTS).•WLAN Operators operate WiFi (IEEE 802.11) Wireless LAN networks in hot spots such as the airport main terminal. In the ADAMANT context the WLAN is operated accordingto the neutral host model: in this model the location owner, AIA, owns the infrastructure(Access Points, Antennas, Cabling, session management software, firewalls, routers) andoffers it for exploitation to different providers, in this case to OTEnet.•Specialized network operators provide voice and data services on specific network technologies.As stated above, the classification of business roles presented above is useful to clearly separate functional roles within the business model but it might be the case that, in a certain application scenario, the same business entity plays more than one role, or even different business units within the same organization like in the case of AIA departments. It may also happen that the same business entity plays different roles in different application scenarios.For the generic business roles, the Customer (User) subscribes for a service with either a Service Provider or a Network Provider, according to the nature of the service requested and the specific business model used for providing that service. In fact, for the most generic case, it is possible that the customer, beyond having a direct relationship with the Network Provider, would also have a direct business relationship with the service provider. For example, not all services would be billed via the account the user holds with the network provider. Typically, a subscription for a value-added service could be performed with a Service Provider, while a network access / connectivity service could be subscribed to with a Network Provider. CustomerMobile Operator WLANOperator ISP Airport AuthorityASP/ContentBroker Foreign mobile OperatorForeignISPContentProviderISP Figure 2: Business actors and their relationships in the ADAMANT contextThe business relationships between roles in the ADAMANT context are depicted in Figure 2. In the figure, specialized service provider and network provider roles have been added to reflect the actual service and networks typologies that are available in the designed application scenarios.The Customer may have direct relationships with both the Service and Network Providers. Mobile and WLAN operators interact with ISPs for accessing the public Internet, and such ISPs in turn may interact with an ASP/Content Broker, either for providing Internet access to the ASP/Broker, or to buy content from it. Mobile and WLAN operators may have relationships in the cases in which an operator may want to offer its customers services using the other operators’ networks (e.g. a Mobile Operator offers download of video-clips to its customers through a WLAN when the customer is in the airport, which would be much faster). For the case of foreign visitors, foreign mobile operators are also represented, since these would have roaming relations with the local operators.6. CONCLUSIONThis paper has illustrated the on-going work of ADAMANT project, the application scenarios and the IDMS architecture. The paper also introduces the proposed the SLA management framework for location-sensitive wireless applications and business models and value chains. Through the multi-agent architecture, the IDMS can provide management of the communication resources and ensure that the service provisioning of the airport users is in line with their SLAs. The new business model and value chain balance the requirements of all the business roles and ensure the smooth operation of the future wireless marketplace. Within this project, the IDMS system and new business models will be tested and validated through experiments, trials and demonstrations based on the defined application scenarios.。
基于Agent行动图的作战建模方法
基于Agent行动图的作战建模方法蒲玮;李雄【摘要】To solve the problem of agent-based warfare modeling process without military concept model driven architecture during which military personnel plays a leading role, a warfare modeling method based on agent action diagrams (AAD) is proposed.First, the principium of the modeling method based on AAD is introduced.Then, static and dynamic conceptual modeling approaches for the warfare system based on AAD are presented by formal representations of agent action organization diagram, communication network diagram, act attribute diagram, and agent command interaction diagram, state behavior diagram,respectively.Further, an approach of transforming from the AAD conceptual model to the behavior simulation model frame is put forward, and the corresponding modeling tool based on AAD is designed and implemented.Finally, an instance of typical armored troop warfare modeling is used to verify the feasibility and effectiveness of the proposed method.%针对一般的基于Agent作战建模过程中没有实现军事人员主导下的军事概念模型直接驱动的问题,提出一种基于Agent行动图的作战建模方法.在给出基于Agent行动图建模基本原理的基础上,区分Agent行动组织结构图、通信网络图、动作属性图,提出了基于Agent行动图的作战系统静态概念模型建模方法,区分Agent行动指挥交互图、状态行为图,提出了基于Agent行动图的作战系统动态概念模型建模方法;进一步建立了Agent行动图概念模型到行为仿真模型框架转换方法,并设计实现了基于Agent行动图的作战建模工具;最后以装甲分队典型作战行动建模为例,验证了方法的可行性与有效性.【期刊名称】《系统工程与电子技术》【年(卷),期】2017(039)004【总页数】11页(P795-805)【关键词】Agent;作战建模;基于Agent的作战建模;Agent行动图【作者】蒲玮;李雄【作者单位】装甲兵工程学院陆军装备作战仿真重点实验室, 北京 100072;装甲兵工程学院陆军装备作战仿真重点实验室, 北京 100072【正文语种】中文【中图分类】TP391作战建模技术是军事科学研究的一种定量化的现代研究方法,在辅助决策、指挥训练等多个军事领域发挥着重要的作用。
agent-based
M-UML:an extension to UML for the modeling of mobileagent-based software systemsKassem Saleh *,Christo El-MorrDepartment of Computer Science,American University of Sharjah,P.O.Box 26666,Sharjah,United Arab EmiratesReceived 30December 2002;revised 29June 2003;accepted 22July 2003AbstractThe Unified Modeling Language (UML)is a language for the specification,visualization,and documentation of object-oriented software systems [The Unified Modeling Language User Guide,1998].However,UML cannot describe in an explicit manner the mobility requirements needed for modeling mobile agent-based software systems.In this paper,we present M-UML,our proposed extension to UML covering all aspects of mobility at the various views and diagrams of UML.The use of M-UML is illustrated using a simple mobile voting system example.q 2003Elsevier B.V.All rights reserved.Keywords:Language extension;Mobile agents;Mobility requirements;Unified Modeling Language1.IntroductionThe agent mobility paradigm became feasible due to the advances in process migration,remote evaluation,distrib-uted object computing and mobility [2].Mobile agents are mobile objects or programs that carry executable code and data within themselves.They have several features that help them achieving their goals or business functions such as negotiating,and ordering.Intelligent agents deal with new situations for automatic problem solving and learn from past experience.They present several advantages since they are persistent and continuously running.They also reduce traffic on the network significantly since computation,encoded in the mobile agent,is brought to data rather than data to computation.In fact,there are very clear and obvious benefits of mobile agents such as offloading the network communi-cations links,freeing local computing resources,and achieving fault-tolerance by migrating to different network nodes.However,to achieve mobility,there were many important problems to address,such as,among other things,trusting agent software,trusting remote software andenvironment,the degree of autonomy we give them,fault-tolerance vis-a `-vis node failures,agent failures or com-munication failures.In electronic business,the use of modeling tools to describe business processes has a decisive impact on the success of the business implementation.Furthermore,mobile agents are very useful for performing electronic business functionalities [3]making the need for mobile agents modeling tool,like UML,crucial and highly beneficial.Studies on the use of UML in the modeling of mobile agents are rare and limited in extent.Klein et al.[4]proposed an extension to UML for mobile agents.However,their approach is limited to a specific agent platform and to specific class of mobile agent applications.Moreover,they do not provide mobility description for all views and aspects of systems,hence not covering all UML diagrams.Bauer et al.[5]introduce Agent UML for specifying multiagent interactions.In Agent UML,a new diagram type called protocol interaction diagram is developed.However,this agent-based extension did not include aspects of mobility.Also,Baumeister et al.[6]introduce an extension to the Activity Diagram (ACD)to model mobile systems.Their extension includes the introduction of two variants of ACDs for modeling mobility:a responsibility-centered variant that focuses on the actor performing the action,and a location-centered variant that focuses on the topology of locations at0950-5849/$-see front matter q 2003Elsevier B.V.All rights reserved.doi:10.1016/j.infsof.2003.07.004*Corresponding author.Tel.:þ971-6585555;fax:þ971-65858581.E-mail address:ksaleh@aus.ac.ae (K.Saleh).which actions are taking place.In this paper,we present a complete extension of UML1.4standard(M-UML)to deal with all UML diagrams:Use Case,Class,Object,Statechart, Sequence,Collaboration,Activity,Component,and Deployment diagrams.We also use this model to specify a mobile electronic voting system as an example.In this work,we do not describe a methodology for using our proposed extension,however,we only provide a simple example for illustrative purposes.The development of such methodology is the subject of our future research.The rest of the paper is organized as follows.Section2 provides some preliminary background on the Unified Modeling Language(UML),and on mobile software agents and their applications.In Section3,we introduce the Modified UML and we illustrate its use to model a simple mobile agent application.In Section4,we conclude and outline our future work.2.BackgroundIn this section,we provide some background information on the Unified Modeling Language(UML1.4)standardized by the Object Management Group(OMG),and mobile software agents and their applications in various domains.2.1.UML in briefThe UML is a de facto software industry standard modeling language for visualizing,specifying,constructing, and documenting the elements of systems in general,and software systems in particular[1].UML has a well-defined syntax and semantics.It provides a rich set of graphical artifacts to help in the elicitation and top–down refinement of object-oriented software systems from requirements capture to the deployment of software components.In UML,systems can be modeled by considering three aspects,namely,the behavioral,structural and architectural aspects.Each aspect is concerned with both the static and dynamic views of the system.The static view represents a projection onto the static structures of the complete system description.However,the dynamic view represents a projection onto the dynamical behavior of the system. Finally,views are communicated using a number of diagrams containing information emphasizing a particular aspect of the system.In the following,we describe the various aspects,views and diagrams,and their relationships.2.1.1.AspectsThree aspects of systems can be recognized,namely,the behavioral,structural and architectural aspects.The beha-vioral aspects involve the functionalities provided by the system(static behavioral aspects)and their associated interactions,their timings and their orderings(dynamic behavioral aspects).The structural aspects involve the class structures of the object-oriented software and their interrelationships(static structural aspects),and the algo-rithmic details of objects life cycles and their interactions (dynamic structural aspects).Finally,the architectural aspects are related to the deployment and distribution of software and hardware across the various distributed system components.2.1.2.ViewsAspects of systems are covered by various static and/or dynamic views,namely,the use case,design,process, implementation and deployment views.The Use Case view focuses on the behavioral aspects of a system.Primarily,it reflects the user’s concerns and requirements.This view considers the system as a ually,users,testers and requirements analysts are interested in this view.The Design and Process Views are the concern of the development team including the analysts,designers and implementors.They describe both the static and dynamic structural aspects of the system.The Design View is concerned with objects,classes and collaborations,while the Process View is concerned with software architecture issues such as concurrency,multithreading,synchroniza-tion,performance and scalability issues.The Implementation View describes thefiles and components needed to assemble and release the system.Finally,the Deployment View describes the ways to distribute,deliver and install the system components and files across the distributed nodes of the system.2.1.3.DiagramsA diagram contains model elements such as classes, objects,nodes,components,and relationships,described by graphical symbols.Moreover,a diagram can be used to describe certain system aspects at different levels of abstraction.For example,a state diagram can describe system-level input/output interactions,and can also be used to show state changes of a particular system object across multiple use cases.The nine diagrams in the UML are briefly described below.(1)Use Case Diagram(UCD):This diagram describes the functions of a system and its users.It shows a number of external actors and their connection to the use cases representing the services provided by the e cases can be inherited by another use case,allowing reusability of use cases.Also,use cases can be associated using‘use’relationship,allowing the modularization of use cases.Similarly,use cases can be associated with the ‘extend’relationship to deal with certain exceptional or abnormal conditions or situations.This diagram is used to model the static behavioral aspects of the use case view of the system to model.(2)Class Diagram(CLD):This diagram shows the static structure of classes and their possible relationships(i.e. association,inheritance,aggregation and dependency)inK.Saleh,C.El-Morr/Information and Software Technology46(2004)219–227 220the system.This diagram is used to model the static structural aspects of the Design and Process Views of the system to model.(3)Object Diagram(OBD):This diagram is a variant of a CLD and uses almost identical notation.An OBD can be an example of a CLD that shows possible instantiations of classes during system execution.This diagram is used to model the static structural aspects of the Design and Process Views of the system to model.(4)Statechart Diagram(STD):This diagram describes the possible behavior of an object using state changes.It can also be used as a system level diagram showing system state changes during the operation of the system.Therefore,this diagram can be used to model both the dynamic behavioral aspects of the use case view,and the dynamic structural aspects of the Design and Process Views of the system tomodel.(5)Sequence Diagram(SQD):This diagram shows the interactions between number of objects and their time ordering.In other words,this diagram describes a scenario involving various interacting objects.This diagram can be used to model the dynamic behavioral aspects of the use case view if the interacting objects are interface objects or actors.However,if the interacting objects are internal ones, this diagram would be then used to model the dynamic structural aspects of the design view of the system to model.(6)Collaboration Diagram(COD):This diagram shows the objects and the messages they exchange.Messages are numbered to provide a time ordering of the message.Similar to SQDs,a COD can be used to model both the dynamic behavioral aspect of the use case view,in addition to the dynamic structural aspect of the process view of the system to model.It is worthwhile to mention here that one can easily produce a SQD from the COD and vice versa.Both sequence and CODs are also referred to as interaction diagrams.(7)Activity Diagram(ACD):This diagram shows a sequential or concurrentflow from activity to another activity.An ACD consists of action states,activity states and transitions between them,and usually spans more than one use case(or functionality).This diagram uses symbols from petri nets,flowcharts andfinite state machines.Similar to interaction diagrams,an ACD can be used to model both the dynamic behavioral aspect of the use case view,in addition to the dynamic structural aspect of the design view of the system to model.(8)Component Diagram(CPD):This diagram shows the physical structure of the code in terms of code component.A component can be a source code,a binary,or executable component.A component contains information about the logical class or classes it implements,thus creating a mapping from the Design View to the Component View.A component diagram is used to model the static architectural aspects of the implementation view of the system to model.(9)Deployment Diagram(DPD):This diagram shows the physical architecture and distribution of the hardware and software components in the system.A DPD is used to model the static architectural aspects of the deployment view of the system to model.Table1summarizes the aspects,views and their supporting diagrams in UML.For a complete tutorial on UML the reader can refer to Refs.[1,7].2.2.Mobile software agentsSoftware agents and their use in various application areas such as electronic commerce have been studied extensively in the literature[8–10].These agents are personalized, continuously running and semi-autonomous programs to which people or other programs may delegate a task automating part of a business process of varying complex-ities and application domains.Mobile agents possess many characteristics,for example they are autonomous since they can chart their working plans and decide when to leave a given computer and where to go next.They are also persistent or temporarily continuous since their lifetime may extend beyond that of their creator.Intelligent agents are adaptive and able to learn from their past experiences,i.e.from the user demands, choices and tastes.In addition they areflexible,as the user can personalize them to meet his/her own criteria and preferences,therefore their working plans(behaviors and actions)are not scripted(i.e.hardcoded).Also,agents are reactive,in fact they respond in a timely fashion to new conditions,incoming requests or changes in their environ-ment.In addition to being reactive,they are active/proac-tive;they have a mission to accomplish and are task-oriented.Finally they are mobile;they are able to move from one node to another on a network until they fulfill their prescribed mission.Such agents are used in electronic commerce where they play different functions;for instance shopping agents do price comparison between shopping portals,while other agents learn examines consumer behavior and deliver personalized services accordingly,some auction sites use intelligent agents,and some other agents were proposed to Table1Aspects,views and supporting diagrams in UMLAspects/views Static view Dynamic viewBehavioral(functional)aspects:Use Case ViewUse CaseDiagramsSequence Diagrams,Collaboration Diagrams,Statechart Diagrams,Activity Diagrams Structural(design)aspects:Designand Process ViewsClass Diagrams,Object DiagramsSequence Diagrams,Collaboration Diagrams,Statechart Diagrams,Activity Diagrams Architectural aspects:ImplementationView,Deployment ViewComponentDiagrams,DeploymentDiagramsK.Saleh,C.El-Morr/Information and Software Technology46(2004)219–227221assist in bartering[11].In fact,intelligent agents help in the different purchasing decisions in electronic commerce[3,9]: need identification,product brokering,merchant brokering, negotiation,purchase and delivery,and product/service evaluation.In addition,mobile agents are used in network management,load balancing,among other distributed systems applications.The growing use of mobile agents necessitated the introduction of tools for modeling and developing mobile agent applications.Mobility is considered one of the important and advanced elements of the object model,such as the one existing in the Java programming language[12,13].3.Mobile UML by exampleIn this section,we describe the extensions made in each of the UML diagrams to allow the explicit representation of the mobility aspect.Wefirst introduce informally our mobile system we want to model.Then we introduce our modifications to the UML.3.1.Example:a mobile voting systemA mobile voting system(MVS)consists of three interacting agents,the Vote Collector(VC),the Vote Manager(VM)and the Voters.The VC is a mobile agent mandated by a stationary VM agent to collect votes from stationary voting agents(VOs).The system can be expanded to have more VMs and more VCs dealing with one VM. First,VOs have to register themselves with their assigned VM and should instantiate their stationary agent with their voting choice after receiving the list of candidates from the VM.On election time,the VCs will contact their respective VMs to get a list of voters.Each VC will then log this list with a stationary logger agent and then visit the VOs on their list to get their votes.Once done,the VCs will return back to their base station reporting to the VM the results of the vote.For simplicity,we are not dealing here with reliability and security issues.For a reference on issues of security in mobile agent systems,the reader can refer to Ref.[10].Parts of the MVS is specified in the following section to illustrate the use of M-UML.3.2.M-UMLIn this section,we describe M-UML by going through each of the UML diagrams and explaining the modifications and extensions needed to describe the mobility aspects of the example voting system to model;Table2summarizes mobility extensions proposed in this section.e Case DiagramA UCD encapsulates actors and use cases.Actors are external entities interacting with the system to model Table2Summary of M-UML Diagrams(a)K.Saleh,C.El-Morr/Information and Software Technology46(2004)219–227 222through use cases.An actor can be a software agent interacting with the system.A mobile actor is a mobile software agent that may interact with the system while at a platform away from the one at which the agent was created (i.e.the base platform).The functionality of a system or subsystem to model is described by a group of use cases.A Use Case represents a functional requirement that may involve one or more interacting actors.A mobile Use Case represents a functional requirement that involves one or more mobile actors.Therefore,at least one mobile actor is involved in a mobile use case.A mobile agent-based software system contains both mobile and non-mobile use cases.Fig.1shows a UCD of the MVS containing one mobile actor and three mobile use cases.In thisfigure,we have a mobile actor Vote Collector and a non-mobile actor Voting Manager both interacting through the mobile use case GetVotersList.Similarly,the VC is interacting with the VO through the mobile use case GetVote.Also,the VC is interacting with the Logger through the mobile use case LogList.3.2.2.Statechart DiagramAn STD is a UML diagram that consists of states and transitions linking pairs of states.Normally,an STD describes the behavior of an actor in terms of state change. An actor or object can be in a particular state at a given time.A mobile state is a state reachable while the actor or object is away from its base platform.A mobile state carries a box (M).A unidirectional link emanating from one state,the source state,and reaching another state,the sink state,is called a transition.A mobile transition is a transition linking two states that are reachable by an agent while at two different platforms.Therefore,we may have a non-mobile transition linking two mobile states,a mobile transition linking a mobile state to a non-mobile state or vice versa, and a mobile transition linking two mobile states.Mobile transitions carry a box(M).However,if an agent can reach a state while it is either at its base or away,that state will carry a dashed box(M).Similarly,if a mobile agent reaches a state while interacting remotely with another agent,the transition will carry box(R).Finally,a transition is labeled with the stereotype p agentreturn q if it corresponds to the return of the agent to its base while changing its state.Fig.2shows a STD containing both types of states and transitions in different combinations.Thefigure shows a part of the state behavior of the VC mobile agent/actor.At its base platform,the agent receives the message StartVo-tingProcess and moves from the state ReadyToMove(RTM) to the state VotingManagerReached(VMR),at which the agent is already at a different platform.At VMR,the agent sends a remote Log message to the Logger and then sends a GetVotersList message to the VM and moves to the WaitForList(WFL)state.Both VMR and WFM states are mobile states,and the transition from RTM to VMR states is a mobile transition.At WFL,the VC receives from VM the message VotersList and moves to the platform of thefirst Fig.2.Statechart Diagram of the VC.K.Saleh,C.El-Morr/Information and Software Technology46(2004)219–227223VO on the voters list while,changing its state to WaitForVote(WFV).3.2.3.Sequence DiagramAn SQD is one kind of interaction diagrams that shows the interactions among agents while time progresses.Time is represented by a vertical timeline for each agent.An interaction is represented by an arrow starting from the initiating agent directed to the receiving agent.If the initiating agent is interacting while not at its base platform, the timeline from the time this interaction occurs to the timethe agent returns to its platform will befilled with‘M’.An interaction emanating from that agent’s timeline is called a mobile interaction.A mobile interaction that implies two agents located on the same platform is labeled with the stereotype p localized q.However,a mobile interaction that implies a mobile agent and the two interacting agents are not located on the same platform will hold a box(R)at the intersection between the timeline of the initiating agent’s platform and the interaction.A dashed line on the SQD is used to trace the source platform of a mobile agent initiating either a localized or remote interaction.This means that mobile interactions need not be co-located(i.e. labeled with p localized q).For example,a mobile agent may move to a remote platform and starts to interact with other remote agents.Finally,the return of the agent to its base is represented by a directed arrow stereotyped with p agentreturn q.Fig.3shows a SQD involving mobile and both p localized q and remote interactions.The VC sends a local message GetVotersList to the VM.Once VC received the voters list,it sends a remote log message to a remote logger agent.Then the VC moves from the VM platform to a Voter(VO)agent platform on its voters list.The mobile VC sends a local message GetVote and moves on to the next voter after receiving the vote.Finally,after getting the vote from the last VO agent,VC returns to its base platform.3.2.4.Collaboration DiagramA COD is one kind of interaction diagrams that shows the behavior of interacting objects using a sequence of exchanged messages.The static relationship among objectsis well defined.Therefore,a COD shows both structural andbehavioral properties of inter-object interactions.A CODcontains objects(or class instances)and lines connectingpairs of interacting objects or agents.Each interaction islabeled by the message sequence number,the messageidentifier,and an arrow indicating the direction of themessage.Functionally,both collaboration and SQDs areequivalent.Consequently,given a SQD,we can derive theequivalent COD and vice versa.If a mobile objectparticipates in the interaction,a box(M)will be added tothe object.If the interaction is occurring at the sameplatform,the interaction line will carry the stereotypep localized q.However,if the interaction involves two remote agents while one or both are away fromtheir base platform,the interaction line will carry thebox(R).A self-loop interaction line carrying the stereotypep agentreturn q at a mobile object represents the return of the mobile object to its originating platform in the particular order given by the sequence number attached also to the interaction.Fig.4shows a COD involving mobile agents,both inremote and localized interactions.Thefirst and secondinteractions are localized interactions.The third interactionin the diagram shows that at VM’s platform,the VC,amobile object,is remotely interacting with the logger.ThisCOD is equivalent to the SQD in Fig.3.The fourthinteraction shows the VC moving to VO’s platform tointeract locally with a voter VO.Finally,thefifth interactionshows the VC returning to its originating platform.3.2.5.Activity DiagramAn ACD shows the controlflow between actions orcomplex actions called activities.It is basically a blend offinite state machines/statecharts and petri nets syntax andsemantics.However,unlike a statechart,the states repre-senting the activities in an ACD may normally span morethan one object/agent.An ACD is able to model both thesequential and parallelflow among actions and activitiesinvolved in the modeling of a use case.Moreover,an actionis a basic atomic computational step,unlike an activitywhich can be further described by another ACD hencecreating a hierarchy of ACDs.Swimlanes can also be usedto show the agent involved in performing the actionorFig.4.Collaboration Diagram.K.Saleh,C.El-Morr/Information and Software Technology46(2004)219–227224activity.A mobile action or activity involves at least one mobile agent executing at a different platform than its originating platform.A mobile use case involves one or more mobile actions or activities.If the action/activity is executed by an agent outside its originating platform,then this mobile action/activity is represented by an oval with a box (M)attached to its top left corner.Also,if the action is triggered (requested)by a mobile agent,this mobile action will carry a dashed box (M).However,if this mobile action/activity interacts with a remote agent,it will carry the box (R)instead.The return of an agent to its originating platform is represented by a mobile action stereotyped with p agentreturn q .Finally,to explicitly specify the location at which a mobile or remote action performed by a mobile agent is occurring,the action is stereotyped with p location ¼agent q .For example,both the remote action RequestLogList and the mobile action RequestList carry the stereotype p location ¼Manager q .In sum-mary,the diagram will show,in addition to the sequencing of actions/activities,the relative placement of the agents while performing those actions/activities.This extension to the ACD blends both the location-centered and the responsibility-centered extensions proposed in Ref.[6].Fig.5shows the ACD involving mobile actions/activities that are partially or completely performed by mobile agents.For example,The RequestList activity is occurring at VM’s platform and is mobile since it involves one mobile agent (the VC).Similarly,the activity CollectVotes occurring at VO’s platform is also a mobile activity.The LogListRequest activity is a remote activity since it is occurring at the VM’s platform after the VM processes VC’s request.Finally,the activity ProvideVotersList is also a mobile activity since it involves the mobile VC agent who is receiving the voters list and will carry a dashed (M). 3.2.6.Class DiagramA CLD shows the static structure of the system’s software classes and describes all relationships among those classes,including the association,aggregation and generalization relationships.A mobile class is a class from which mobile objects/agents are created.A class inheriting from a mobile class inherits its mobility feature.Classes that are part of another mobile class (in aggregation relationship)are not necessarily mobile classes.Similarly,classes associated with a mobile class are not necessarily mobile classes themselves.Classes from which mobile objects are instantiated are shown with a box (M)at the top left.However,other classes that contain behavior (methods)that is affected (communicating with)by mobile objects are shown with a dashed box (M).Moreover,a class containing behavior affected by a remote mobile agent is shown with a dashed box (R).Therefore,methods invoked by a mobile agent are labeled with either (M)or (R),depending on the location of the calling mobile agent.If a class contains methods of both types,it will carry both dashed boxes (M)and (R).Fig.6shows a CLD involving mobile and non-mobile classes.In this figure,class VM includes the method GetVotersList ðÞwhich is invoked by the mobile agent of class VC,and an object instantiated from VM is not a mobile object.This is also the same for the VO,which instances are not mobile.The class hierarchy shows the association relationships between VO,VC and the VM objects.Finally,the Logger class is associated with the VC class and carries a dashed box (R)since it contains the method logList ðÞinvoked remotely by a mobile object of class VC.This occurs by default when displaying the complete class hierarchy,showing non-mobile classes associated with mobile classes.3.2.7.Object DiagramAn OBD shows objects and links among them.An OBD is derived from a CLD and is based on the static structure of the model,but also shows multiple instances of some objects as illustrations or scenarios of the association relationships Objects made from a mobile class are mobile objects.Those mobile objects a considered themobileFig.5.ActivityDiagram.。
Implementaion of Personalization Service based on Mobile Web Service Platform
Implementaion of Personalization Service based onMobile Web Service PlatformSunghan Kim, Jaehong Min, Jonghwa Lee, Hyeongho Lee1 ETRI(Electronics and Telecommunications Research Institute), Korea{sh-kim,jhmin,jhyiee,holee}@etri.re.krAbstract. In this paper, we try to suggest a candidate personalization servicearchitecture for future mobile services. We tried to design the framework and tofind the required software modules for a mobile personalization service, whichis related with context-aware processing and user-preference information. And,we are implementing and testing the prototype system, and finding better soul-tion to deploy personalization on mobile terminal.1 IntroductionMany kinds of wireless internet service are already popular to mobile user. The system consists of mobile terminal, gateway, web server and network. From current wireless internet service, new kinds of mobile web service are now emerging with intelligent semantic web server as well as web service. To comply with these kind of service, it also demands new service architecture. Semantic and Web service tech-nologies are possible to provide personalized and customized services to mobile users. Fig. 1 shows architecture framework for next generation mobile personalization ser-vices. This framework is our testbed environment.Fig. 1. Proposed Framework for mobile internet personalization service1.1 Considerations of researchTo provide personalization service, we need to review many kinds of technical as-pects. The first, because of movement of user, personalization service needs to con-sider the location based information and user’s context, i.e, mobile terminal or time schedule, etc. The second, we need to have the solution to understanding mechanism for user context. For this, database is needed to allow to access with user information. The third, we need to build to modeling the knowledge having reflected on user re-quirements. The fourth, current system is approached on thin client based terminal capacities which the mobile client has the minimum roles in functions. The last, there are conflicts of integration between server systems and server agents are not yet stan-dardized on market world. Until now, even though many considerations are not re-solved, mobile web service applications are studied for the achieving the goals of service automation, intelligence and personalization. Among them, we now will focus on personalization area.Our personalization approach is based on context-ware based. Context-aware op-timization and modeling is the growing issue for mobile web service[1,2,3]. And research needs context based optimization technology to support intelligent mobile web service. For current web-based services are rapidly working with mobile ser-vices. Both personalized and agile services, especially in mobile-web services, de-mand promptness of service by collaboration of context optimization. Therefore, context-aware optimization research that is based on multiple ontology may be ap-plied for mobile customization.2 Mobile Personalization Service SystemThe Proposal framework for context aware mobile service is shown in Fig. 2. The first two architectures are in similar to the concept of that adopted in standardization body. The last figure is our new architecture and it is now currently implementing at laboratory level, which would be candidate system for the next generation mobile framework supporting with context aware service.As shown in Fig. 2, six levels of layers are traditional architecture on first, second figure. There are application layer, content layer, service layer, platform layer, com-munication layer and operating system layer. From this layer, we can put some new layer to that layer. The additional layer is personalized application, semantic content processing and context-aware service layer. These are new functions for the support-ing the personalized service than that of traditional services.Fig. 2. Comparison for each Framework methods2.1 System FrameworkAs shown in Fig. 3, our framework has five primary components: ontology, web service, mobile optimizing user agent (UA), mobile optimizing task specific agent (TSA) and context-aware multi-agent system (MAS).A customer connects to a server by using a mobile device to access the UA. The UA provides information to the customer from the user ontology, which provides the user’s personal information such as profile and preferences, and sends a request mes-sage to the TSA.The TSA performs a request action to support corresponding service, according to optimization models executed by the Model Base Management System (MBMS). These optimization models are located in the model base, and are created by context-model matching rule base along with the model base.A web service needs three kinds of server systems for the context-aware optimiza-tion: a general web server, a MAS embedded application server, and SOAP protocol-based semantic web servers.Fig. 3. Architecture of proposed SystemThe web server plays an important role in the CAMA-myOpt system. CAMA-my-Opt contains a decision engine in the M-optimization task specific agent (MSA) to pro-vide accurate decision results to the customer. It also connects with MAS subsystems in agent communities. If the UA retrieves the user preferences, the decision-making engine will send the information to a negotiator on behalf of the UA, which is located in the agent community.3 Testbed environmentOur Testbed environment is shown firgure 4. User ontology, product ontology, and service ontology are implemented with DAML + OIL, based on XML. The ontology is accessed and interpreted with Jena API. Agents are implemented with JATLite on top of JDK version 1.4.1. Communication between the UA and the client is ex-pressed with Java Servlet Pages (JSP). Through the agent communication language (ACL), KQML, CAMA-my-Opt implements the negotiator’s communication with both seller agents and the coordinator. The TSA’s active environment is implemented through an Apache SOAP server, a web service communication that exists outside of the server and agent community. Information repositories such as a model base and database are implemented with Microsoft Access® 2000.Fig. 4. Testbed System for mobile personalization service References1. Abowd, G.G., Atkeson, C.G., Hong, J., Long, S., Kooper, R., and Pinkerton, M. (1997).“Cyberguide: a Mobile Context-aware Tour Guide”, ACM Wireless Networks, Vol. 3, pp.421-4332. Lum, W.Y., and Lau, F.C.M. (2002). “A Context-Aware Decision Engine for Content Adap-tation”, Pervasive Computing, Vol. 1, No. 3, pp. 41-49.3. Pascoe, J., Morse, D.R., and Ryan, N.S. (2000). “HCI issues in fieldwork environments”,ACM TOCHI, Vol. 7, No. 3, pp. 417-437.4. /5. /。
部分可观察马尔可夫决策过程研究进展.
0引言部分可观察马尔可夫决策过程 (partially observable Markov decision processes , POMDP 描述的是当前世界模型部分可知的情况下,智能体 Agent Agent 的例如, 足球运动员在球场上踢足球, 每个球员并不完全清楚他周围的所有状态, 当他向前带球的过程中, 他可能知道在他前面人的位置和状态, 但是可能不知道在他后面的其他队友的位置和状态, 此时他观察到的信息是不完整的, 但是一个优秀的足球运动员往往靠着一种感觉传给他身后的最有利的队员, 使其进行最有利的进攻,过程就是部分可观察马尔可夫决策过程。
在部分可感知模型中, 不仅要考虑到状态的不确定性, 同时还要考虑到动作的不确定性,这种世界模型更加能够客观的描述真实世界, 因此应用十分广泛。
本文综述了目前在 POMDP 领域的研究情况, 介绍了 MDP 的数学理论基础和决策模型, 以及一种典型的 POMDP 决策算法-值迭代算法, 介绍了目前现有的几种经典的决策算法, 并分析它们之间的优点和不足, 列举了一些 POMDP 常见的应用领域, 并进行了总结和展望。
1马尔可夫决策过程Agent 每一个时刻都要做一些决策, 做决策时不仅要考虑甚至是其它 Agents (Markov decision process , MDP 的最优解, MDP 可以用一个四元组<, >来描述 [1]::Agent的行为集;, :×:当 Agent在状态 ,可能转移到状态的概率,使用 |:→ 情况下采用动作-2116--2117-, Agent 使 Agent 选择的动作能够获得在 MDP 模型中, Agent在为折扣因子,其目标是让期望值有界(1由于 MDP 决策过程中, 要同时考虑世界模型的不确定性和目标的长远性,需要在策略时刻,状态的情况下,值函数构造如下=,=,*,也就是 Agent 每个时刻都能做到的最优决策, 根据 Bellman最优策略公式可以得到。
Mason-a Java multiagent simulation library
MASON:A JAVA MULTI-AGENT SIMULATION LIBRARYG. C. BALAN, Department of Computer ScienceC. CIOFFI-REVILLA, Center for Social Complexity*S. LUKE, Department of Computer Science∗L. PANAIT, Department of Computer ScienceS. PAUS, Department of Computer ScienceGeorge Mason University, Fairfax, VAABSTRACTAgent-based modeling (ABM) has transformed social science research by allowingresearchers to replicate or generate the emergence of empirically complex socialphenomena from a set of relatively simple agent-based rules at the micro-level.Swarm, RePast, Ascape, and others currently provide simulation environments forABM social science research. After Swarm — arguably the first widely used ABMsimulator employed in the social sciences — subsequent simulators have sought toenhance available simulation tools and computational capabilities by providingadditional functionalities and formal modeling facilities. Here we present MASON(Multi-Agent Simulator Of Neighborhoods), following in a similar tradition that seeksto enhance the power and diversity of the available scientific toolkit in computationalsocial science. MASON is intended to provide a core of facilities useful not only tosocial science but to other agent-based modeling fields such as artificial intelligenceand robotics. We believe this can foster useful “cross-pollination” between suchdiverse disciplines, and further that MASON's additional facilities will becomeincreasing important as social complexity simulation matures and grows into newapproaches. We illustrate the new MASON simulation library with a replication ofHeatBugs and a demonstration of MASON applied to two challenging case studies:ant-like foragers and micro-aerial agents. Other applications are also beingdeveloped. The HeatBugs replication and the two new applications provide an idea ofMASON’s potential for computational social science and artificial societies.Keywords: MASON, agent-based modeling, multi-agent social simulation, ant foraging, aerial-vehicle flightINTRODUCTIONAgent-based modeling (ABM) in the social sciences is a productive and innovative frontier for understanding complex social systems (Berry, Kiel, and Elliott 2002), because object-oriented programming from computer science allows social scientists to model social phenomena directly in terms of social entities and their interactions, in ways that are inaccessible either through statistical or mathematical modeling in closed form (Axelrod 1997; Axtell and Epstein 1996; Gilbert and Troitzsch 1999). The multi-agent simulation environments that have been∗Corresponding authors’ address: Sean Luke, Department of Computer Science, George Mason University, 4400 University Drive MSN 4A5, Fairfax, VA 22030; e-mail: sean@. Claudio Cioffi-Revilla, Center for Social Complexity, George Mason University, 4400 University Drive MSN 3F4, Fairfax, VA 22030; e-mail: ccioffi@. All authors are listed alphabetically.developed in recent years are designed to meet the needs of a particular discipline; for example, simulators such as TeamBots () (Balch 1998) and Player/Stage () (Gerkey, Vaughan, and Howard 2003) emphasize robotics, StarLogo (/starlogo) is geared towards education, breve (Klein 2002) () aims at physics and a-life, and RePast (), Ascape (/dybdocroot/es/dynamics/models/ascape), a n d Swarm () have traditionally emphasized social complexity scenarios with discrete or network-based environments. Social science ABM applications based environments in this final category are well-documented in earlier Proceedings of this conference (Macal and Sallach 2000; Sallach and Wolsko 2001) and have contributed substantial new knowledge in numerous domains of the social sciences, including anthropology (hunter-gatherer societies and prehistory), economics (finance), sociology (organizations and collective behavior), political science (government and conflict), and linguistics (emergence of language) — to name a few examples.In this paper we present MASON, a new “Multi-Agent Simulator Of Neighborhoods”developed at George Mason University as a joint collaborative project between the Department of Computer Science's Evolutionary Computation Laboratory (Luke) and the Center for Social Complexity (Cioffi-Revilla). MASON seeks to continue the tradition of improvements and innovations initiated by Swarm, but as a more general system it can also support core simulation computations outside the human and social domain in a strict sense. More specifically, MASON is a general-purpose, single-process, discrete-event simulation library intended to support diverse multiagent models across the social and other sciences, artificial intelligence, and robotics, ranging from 3D continuous models, to social complexity networks, to discretized foraging algorithms based on evolutionary computation (EC). MASON is of special interest to the social sciences and social insect algorithm community because one of its primary design goals is to support very large numbers of agents efficiently. As such, MASON is faster than scripted systems such as StarLogo or breve, while still remaining portable and producing guaranteed replicable results. Another MASON design goal is to make it easy to build a wide variety of multi-agent simulation environments (for example, to test machine learning and artificial intelligence algorithms, or to cross-implement for validation purposes), rather than provide a domain-specific framework.This paper contains three general sections. The first section describes the new MASON environment in greater detail, including its motivation, main features, and modules. The second section argues for MASON's applicability to social complexity simulation, including a comparison with RePast and a simple case-study replication of HeatBugs (a common Swarm-inspired ABM widely familiar to computational social scientists. The third section presents two further case studies of MASON applied to areas somewhat outside of the computational social science realm, but which point, we think, in directions which will be of interest to the field in the future. We conclude with a brief summary.MASONMotivation: Why MASON? History and JustificationMASON originated as a small library for a very wide range of multi-agent simulation needs ranging from robotics to game agents to social and physical models. The impetus for this stemmed from the needs of the original architects of the system (S. Luke , G. C. Balan, and L.MASON Model Library, Utilities(Optional)MASON GUI Tools(Optional)Domain-Specific Simulation Library,ToolsApplicationsFIGURES 1 and 2 MASON Layers and Checkpointing ArchitecturePanait) being computer scientists specializing in artificial intelligence, machine learning, and multi-agent behaviors. We needed a system in which to apply these methods to a wide variety of multi-agent problems. Previously various robotics and social agent simulators were used for this purpose (notably TeamBots); but domain-specific simulators tend to be complex, and can lead to unexpected bugs if modified for use in domains for which they are not designed.Our approach in MASON is to provide the intersection of features needed for most multiagent problem domains, rather than the union of them, and to make it as easy as possible for the designer to add additional domain functionality. We think this “additive” approach to simulation development is less prone to problems than the “subtractive” method of modifying an existing domain-specific simulation environment. As such, MASON is intentionally simple but highly flexible.Machine learning methods, optimization, and other techniques are also expensive,requiring a large number of simulation runs to achieve good results. Thus we needed a system that ran efficiently on back-end machines (such as beowulf clusters), while the results were visualized, often in the middle of a run, on a front-end workstation. As simulations might take a long time, we further needed built-in checkpointing to disk so we could stop a simulation at any point and restart it later.Last, our needs tended towards parallelism in the form of many simultaneous simulationruns, rather than one large simulation spread across multiple machines. Thus MASON is a single-process library intended to run on one machine at a time.While MASON was not conceived originally for the social agents community, we believe it will prove a useful tool for social agent simulation designers, especially as computational social science matures and grows into new approaches that require functionalities such as those implemented by the MASON environment. MASON's basic functionality has considerable overlap with Ascape and RePast partially to facilitate new applications as well as replications of earlier models in Swarm, Repast or Ascape; indeed we think that developers used to these simulators will find MASON's architecture strikingly familiar. Finally, MASON is motivated by simulation results replicability as an essential tool in advancing computationally-based claims (Cioffi-Revilla 2002), similar to the role of replication in empirical studies (Altman et al. 2001).Visualization Tools Model Running on Back-End PlatformDiskCheckpointedModel Running under Visualization on User's PlatformRecoveredDiskCheckpointedRecoveredFeaturesMASON was conceived as a core library around which one might build a domain-specific custom simulation library, rather than as a full-fledged simulation environment. Such custom simulation library “flavors” might include robotics simulation library tools, graphics and physical modeling tools, or interactive simulator environments. However, MASON provides enough simulation tools that it is quite usable as a basic “vanilla” flavor library in and of itself; indeed, the applications described later in this paper use plain MASON rather than any particular simulator flavor wrapped around it.In order to achieve the flavors concept, MASON is highly modular, with an explicit layered architecture: inner layers have no ties to outer layers whatsoever, and outer layers may be completely removed. In some cases, outer layers can be removed or added to the simulation dynamically during a simulation run. We envision at least five layers: a set of basic utilities, the core model library, provided visualization toolkits, additional custom simulation layers (flavors), and the simulation applications using the library. These layers are shown in Figure 1.Two other MASON design goals are portability and guaranteed replicability. By replicability we mean that for a given initial setting, the system should produce identical results regardless of the platform on which it is running, and whether or not it is being visualized. We believe that replicability and portability are crucial features of a high-quality scientific simulation system because they guarantee the ability to disseminate simulation results not only in publication form but also in repeatable code form. To meet these goals, MASON is written in 100% Java.Java's serialization facilities, and MASON's complete divorcing of model from visualization, permit it to easily perform checkpointing: at any time the model may be serialized to the disk and reloaded later. As shown in Figure 2, models may be checkpointed and loaded with or without visualization. Additionally, serialized data can be reused on any Java platform: for example, one can freely checkpoint a model from a back-end Intel platform running Linux, then load and visualize its current running state on MacOS X.Despite its Java roots, MASON is also intended to be fast, particularly when running without visualization. The core model library encourages direct manipulation of model data, is designed to avoid thread synchronization wherever possible, has carefully tuned visualization facilities, and is built on top of a set of utility classes optimized for modern Java virtual machines.1Additionally, while MASON is a single-process, discrete-event library, it still permits multithreaded execution in certain circumstances, primarily to parallelize expensive operations in a given simulation.1 One efficiency optimization not settled yet is whether to use Java-standard multidimensional arrays or to use so-called ``linearized'' array classes (such as used in RePast). MASON has been implemented with both of them for testing purposes. In tight-loop microbenchmarks. linearized arrays are somewhat faster; but in full MASON simulation applications, Java arrays appear to be significantly faster. This is likely due to a loss in cache and basic-block optimization in real applications as opposed to simple microbenchmarks. We are still investigating this issue.FIGURE 3 MASON Utilities, Model, and Visualization LayersThe Model and Utilities LayersMASON's model layer, shown in Figure 3, consists of two parts: fields and a discrete-event schedule. Fields store arbitrary objects and relate them to locations in some spatial neighborhood. Objects are free to belong to multiple fields or, in some cases, the same field multiple times. The schedule represents time, and permits agents to perform actions in the future.A basic simulation model typically consists of one or more fields, a schedule, and user-defined auxiliary objects. There is some discrepancy in the use of the term agents between the social sciences and computer science fields. When we speak of agents , we refer to entities that can manipulate the world in some way: they are brains rather than bodies. Agents are very often embodied — physically located in fields along with other objects — but are not required to be so.The model layer comes with fields providing the following spatial relationships, butothers can be created easily.•Bounded and toroidal discrete grids in 2D and in 3D for integers, doubles, and arbitrary Objects (one integer/double/Object per grid location)•Bounded and toroidal hexagonal grids in 2D for integers, doubles, and arbitrary Objects (one integer/double/Object per grid location)• Efficient sparse bounded, unbounded, and toroidal discrete grids in 2D and 3D(mapping zero or more Objects to a given grid location)• Efficient sparse bounded, unbounded, and toroidal continuous space in 2D and 3D(mapping zero or more Objects to a real-valued location in space)• Binary directed graphs or networks (a set of Objects plus an arbitrary binary relation)Simulation ModelDiscrete Event Schedule (Representation of Time)Fields(Representations of Space)Holds AgentsAny ObjectHoldUtilitiesVisualization and GUI ToolsControllers(Manipulate the Schedule)2D and 3D Displays2D and 3D Portrayals(Draw Fields and the Objects they hold)DiskHoldThe model layer does not contain any visualization or GUI code at all, and it can be run all by itself, plus certain classes in the utilities layer. The utilities layer consists of Java classes free of simulation-specific function. Such classes include bags (highly optimized Java Collection subclasses designed to permit direct access to int, double, and Object array data), immutable 2D and 3D vectors, and a highly efficient implementation of the Mersenne Twister random number generator.The Visualization LayerAs noted earlier, MASON simulations may operate with or without a GUI, and can switch between the two modes in the middle of a simulation run. To achieve this, the model layer is kept completely separate from the visualization layer. When operated without a GUI the model layer runs in the main Java thread as an ordinary Java application. When run with a GUI, the model layer is kept essentially in its own “sandbox”: it runs in its own thread, with no relationship to the GUI, and can be swapped in and out at any time. Besides the checkpointing advantages described earlier, another important and desirable benefit of MASON's separation of model from visualization is that the same model objects may be visualized in radically different ways at the same time (in both 2D and 3D, for example). The visualization layer, and its relationship to the Model layer, is shown in Figure 3.To perform the feat of separation, the GUI manages its own separate auxiliary schedule tied to the underlying schedule, to queue visualization-agents that update the GUI displays. The schedule and auxiliary schedule are stepped through a controller in charge of the running of the simulation. The GUI also displays and manipulates the model not directly but through portrayals which act as proxies for the objects and fields in the model layer. Objects in the model proper may act as their own portrayals but do not have to.The portrayal architecture is divided into field portrayals, which portray fields in the model, and various simple portrayals stored in a field portrayal and used to portray various objects in the field portrayals' underlying field. Field portrayals are, in turn, attached to a display, which provides a GUI environment for them to draw and manipulate their fields and field objects. Portrayals can also provide auxiliary objects known as inspectors (approximately equivalent to “probes” in RePast and Swarm) that permit the examination and manipulation of basic model data. MASON provides displays and portrayals for both 2D and 3D space, and can display all of its provided fields in 2D and 3D, including displaying certain 2D fields in 3D. 2D portrayals are displayed using AWT and Java2D graphics primitives. 3D portrayals are displayed using the Java3D scene graph library. Examples of these portrayals are shown in Figure 4.APPLICABILITY TO SOCIAL COMPLEXITY ENVIRONMENTS MASON was designed with an eye towards social agent models, and we think that social science experimenters will find it valuable. MASON shares many core features with social agent simulators such as Swarm, Ascape, and RePast. In this section we specify the primary differences between MASON and RePast, followed by a simple example of MASON used to simulate the well-known HeatBugs model.a. b. c.d. e. f.FIGURE 4 Sample Field Portrayals (Applications in Parentheses). a. Discrete 2D Grids (Ant Foraging). b. Hexagonal 2D Grids (Hexagonal HeatBugs). c. Continuous2D Space (“Woims”: Flocking Worms). d. Networks in 2D (A Network Test). e. Continuous 3D Space (3D “Woims”).f. Discrete 2D Grids in 3D Space (HeatBugs)Comparison with RePastHere we provide a brief enumeration of most of the differences between the facilities provided by MASON and those of RePast, the latter of which evolved from Swarm to model situated social agents.Differences•MASON provides a full division between model and visualization. One consequenceof this key difference is that MASON can separate or join the two at any time andprovide cross-platform checkpointing in an easy fashion. Another consequence isthat MASON objects and fields can be portrayed in very different ways at the sametime, and visualization methods may change even during an expensive simulation run.•MASON has facilities for 3D models and other visualization capabilities that remainlargely unexplored in the social science realm, but which are potentially insightful forsocial science ABM simulations.•In our experience, MASON has generally faster models and visualization than RePast,especially on Mac OS X, and has more memory-efficient sparse and continuousfields. MASON's model data structures also have computational complexityadvantages.•MASON has a clean, unified way of handling network and continuous fieldvisualization.•RePast provides many facilities, notably: GIS, Excel import/export, charts and graphs,and SimBuilder and related tools. Due to its design philosophy, MASON does notinclude these facilities. We believe they are better provided as separate packagesrather than bundled. Further, we believe that many of these tools can be easily portedto MASON.Differences in Flux: MASON Will Likely Change These Features in its Final Version •RePast uses linearized array classes for multidimensional arrays. MASON presentlyhas facilities for both linearized arrays and true Java arrays, but may reduce to usingone or the other.•RePast's schedule uses doubles, while MASON's schedule presently uses longs.•RePast allows objects to be selected and moved by the mouse.•RePast allows deep-inspection of objects; MASON's inspection is presently shallow.Replicating HeatBugsHeatBugs is arguably the best known ABM simulation introduced by Swarm, and is a standard demonstration application in RePast as well. It contains basic features common to a great many social agent simulations: for example, a discrete environment defining neighborhood relationships among agents, residual effects (heat) of agents, and interactions among them. We feel that the ability to replicate models like HeatBugs, Sugarscape, Conway’s Game of Life (or other cellular automata), and Schelling’s segregation model in a new computational ABM environment should be as essential as the ability to implement regression, factor analysis, ANOVA, and similar basic data facilities in a statistical analysis environment.Indeed, a 100x100 toroidal world, 100-agent HeatBugs model was MASON's very first application. In addition to this classical HeatBugs model, we have implemented several other HeatBugs examples. Figure 4 includes partial screenshots of two of them: Figure 4B shows HeatBugs on a hexagonal grid (fittingly called “HexaBugs” in RePast), and Figure 4f shows 2D HeatBugs visualized in 3D space, where vertical scale indicates temperature, and HeatBugs onthe same square are shown stacked vertically as well. Whereas the original HeatBugs is based on a 2D grid of interacting square cells (connected by Moore or von Neumann neighborhoods), HexaBugs is more relevant in some areas of computational social science where hexagonal cells are more natural (e.g., computational political science, especially international relations) and four-corner situations are rare or nonexistent (Cioffi-Revilla and Gotts 2003).CASE STUDIESAlthough MASON has existed for only six months, we have already used it in a variety of research and educational contexts. Additionally, we are conducing tests to port RePast, Swarm, and Ascape models to MASON, ported by modelers not immediately familiar with MASON. These ports include a model of warfare among countries, a model of land use in a geographic region, and a model of the spread of anthrax in the human body).In this section we describe the implementation and results of two research projects that used the MASON simulation library. The first case study used MASON to discover new ant-colony foraging and optimization algorithms. The second case study applied MASON to the development of evolved micro-aerial vehicle flight behaviors. These are not computational social science models per se: but they are relevant enough to prove illuminating. The first case study uses a model that is similar to the discrete ABM models presently used, but it is applied to an automated learning method, demonstrating the automated application of large numbers of simulations in parallel. The second case study uses a continuous 2D domain environment and interaction, which we think points to one future area of ABM research. Neither of these more advanced applications is implemented in Swarm, RePast, or Ascape at present, and both take advantage of features special to MASON. In both cases experiments were conducted running MASON on the command-line in several back-end machines, and the progress was analyzed by attaching the simulators to visualization tools on a front-end workstation. Additionally, the second case involves a continuous field that is scalable and both memory- and time-efficient (both O(#agents), rather than O(spatial area)).Both of the projects described below have an evolutionary computation (EC) component: to save repetition, we give a quick explanation of evolutionary computation here. EC is family of stochastic search and optimization techniques for “hard” problems for which there is no known procedural optimization or solution-discovery method. EC is of special interest to certain multiagent fields because it is agent-oriented: it operates not by modifying a single candidate solution, but by testing a “population” of such solutions all at one time. Such candidate solutions are known as “individuals”, and each individual's assessed quality is known as its “fitness”. The general EC algorithm is as follows. First, an initial population of randomly-generated individuals is created and each individual's fitness is assessed. Then a new population of individuals (the next generation) is assembled through an iterative process of stochastically selecting individuals (tending to select the fitter ones), copying them, then breeding the copies (mixing and matching individuals' components and mutating them), and placing the results into the next generation. The new generation replaces the old generation; its individuals' fitnesses are in turn assessed, and the cycle continues. EC ends when a sufficiently fit individual is discovered, or when resources (notably time) expire. The most famous example of EC is the genetic algorithm (GA) (Holland 1975), but other versions exist as well; we will discuss genetic programming (GP) (Koza 1992) as one alternative EC method below.Ant ForagingAnt foraging models attempt to explain how ant colonies discover food sources, then communicate those discoveries to other ants through the use of pheromone trails — leaving proverbial “bread crumbs” to mark the way. This area has become popular not just in biology but curiously in artificial intelligence and machine learning as well, because pheromone-based communication has proven an effective abstract notion for new optimization algorithms (known collectively as ant colony optimization) and for cooperative robotics.Previous ant foraging models have to date relied to some degree on a priori knowledge of the environment, in the form of explicit gradients generated by the nest, by hard-coding the nest location in an easily-discoverable place, or by imbuing the ants with the knowledge of the nest direction. In contrast, the case study presented here solves ant foraging problems using two pheromones, one applied when leaving the nest and one applied when returning to the nest. The resulting algorithm is orthogonal and simple, and biologically plausible, yet ants are able to establish increasingly efficient trails from the nest to the food even in the presence of obstacles.Ants are sensitive to one of the two pheromones at any given time; the sensitivity depends on whether they are foraging or carrying food. While foraging, an ant will stochastically move in the direction of increasing food pheromone concentration, and will deposit some amount of nest pheromone. If there is already more nest pheromone than the desired level, the ant deposits nothing. Otherwise, the ant “tops off” the pheromone value in the area to the desired level. As the ant wanders from the nest, its desired level of nest pheromone drops. This decrease in deposited pheromone establishes an effective gradient. When the ant is instead carrying food, the movement and pheromone-laying procedures use the opposite pheromones than those used during foraging.The model assumes a maximum number of ants per location in space. At each time step, an ant will move to its best choice among non-full, non-obstacle locations; the decision is made stochastically with probabilities correlated to the amounts of pheromones in the nearby locations. Ants move in random order. Ants live for 500 time steps; a new ant is born at the nest each time step unless the total number of ants is at its limit. Pheromones both evaporate and diffuse in the environment.Figure 4a shows a partial screenshot of a small portion of the ant colony foraging environment. The ants have laid down a path from the nest to the food and back again. Part of the ground is colored with pheromones. The large oval regions are obstacles. The MASON implementation was done with two discrete grids of doubles (two pheromone values), discrete grids of obstacles, food sources, and ant nests, and a sparse discrete grid holding the ants proper. Each ant is also an agent (and so is scheduled at each time step to move itself). Additional agents are responsible for the evaporation and diffusion of pheromones in the environment, and also for creating new ants when necessary.In addition to the successful design of hard-coded ant foraging behaviors, we also experimented with letting the computer search for and optimize those behaviors on its own. For this purpose, we connected MASON to the ECJ evolutionary computation system (Luke 2002) (/~eclab). ECJ handled the main evolutionary loop: an individual took the form of a set of ant behaviors that was applied to each ant in the colony. To evaluate an individual, ECJ spawned a MASON simulation with the specified ant behaviors. The simulation was run。
多智能体技术发展及其应用综述
2018,54(9)多智能体技术(multi-agent technology )的应用研究起源于20世纪80年代并在90年代中期获得了广泛的认可,发展至今,已然成为分布式人工智能(Distributed Artificial Intelligence )领域中的一个热点话题,其智能性主要体现在感知、规划、推理、学习以及决策等方面。
多智能体系统(multi-agent system )的目标是让若干个具备简单智能却便于管理控制的系统能通过相互协作实现复杂智能[1],使得在降低系统建模复杂性的同时,提高系统的鲁棒性、可靠性、灵活性。
目前,采用智能体技术的多智能体系统已经广泛应用于交通控制、智能电网、生产制造、无人机控制等众多领域。
1多智能体系统智能体(Agent )是处于某个特定的环境下的计算机系统,该系统可以根据自身对环境的感知,按照已有的知识或者通过自主学习,并与其他智能体进行沟通协作,在其所处的环境自主地完成设定的目标。
通常,单个智能体求解问题的能力通常是十分有限的,但是将多个自治的智能体组合起来协作求解某些问题的能力通常很强大。
多智能体系统就是指可以相互协作的多个简单智能体为完成某些全局或者局部目标使用相关技术组成的分布式智能系统[2],其中,多智能体技术在构建多智能体系统中充当至关重要的作用。
多智能体系统多智能体技术发展及其应用综述李杨,徐峰,谢光强,黄向龙LI Yang,XU Feng,XIE Guangqiang,HUANG Xianglong广东工业大学计算机学院,广州510006School of Computing,Guangdong University of Technology,Guangzhou 510006,ChinaLI Yang,XU Feng,XIE Guangqiang,et al.Survey of development and application of multi-agent -puter Engineering and Applications,2018,54(9):13-21.Abstract :First of all,the definition and characteristics of multi-agent technology is introduced.By analyzing the literature on application of multi-agent technology at home and abroad,the basic research of multi-agent system is analyzed and the technical development of the direction of multi-agent consensus and control are combed.Then,this article chooses the two fields of robot control and wireless sensor networks to focus on the application changes and the latest achievements of multi-agent technology in practical engineering in recent years.Finally,this paper summarizes main problems to be solved in engineering application,and points out the research direction of future multi-agent system application.Key words :distributed artificial intelligence;multi-agent system;cooperative control;consensus摘要:首先阐述了智能体技术的相关定义及特性,通过分析国内外多智能体技术的应用研究文献,对多智能体系统的基础研究进行分析并梳理了多智能体一致性及控制等方向的技术发展。
软考高级架构师技术选型40题
软考高级架构师技术选型40题1. In a large-scale e-commerce project, which of the following cloud computing services is most suitable for handling the peak traffic during the shopping festival?A. IaaSB. PaaSC. SaaSD. Serverless答案:A。
解析:IaaS( 基础设施即服务)提供了最大的灵活性和对底层基础设施的控制,能够根据需求快速扩展资源以应对高峰流量。
PaaS( 平台即服务)侧重于提供平台环境,对于处理突发的大规模流量扩展相对受限。
SaaS(软件即服务)是已经成型的应用服务,难以针对特定的高峰流量需求进行定制化扩展。
Serverless 适用于一些特定的短时间、低资源需求的任务,对于持续的高峰流量处理可能不够稳定。
2. For a financial company that needs to ensure high data security and compliance, which cloud computing model is the best choice?A. Public cloudB. Private cloudC. Hybrid cloudD. Community cloud答案:B。
解析:Private cloud(私有云)提供了最高级别的控制和安全性,能够满足金融公司对数据安全和合规性的严格要求。
Public cloud( 公有云)共享资源,安全性和合规性可能难以完全满足金融公司的特殊需求。
Hybrid cloud( 混合云)结合了公有云和私有云,但在数据安全和合规方面仍不如私有云直接和可控。
Community cloud( 社区云)共享程度较高,安全性和定制化程度不如私有云。
3. When choosing a cloud computing provider for a startup with limited budget and rapid growth expectations, which factor should be given the highest priority?A. CostB. ScalabilityC. SecurityD. Support services答案:B。
协作移动机器人-前因和方向外文文献翻译、中英文翻译、外文翻译
Cooperative Mobile Robotics: Antecedents and DirectionsY. UNY CAOComputer Science Department, University of California, Los Angeles, CA 90024-1596ALEX S. FUKUNAGAJet Propulsion Laboratory, California Institute of Technology, Pasadena, CA 91109-8099ANDREW B. KAHNGComputer Science Department, University of California, Los Angeles, CA 90024-1596Editors: R.C. Arkin and G.A. BekeyAbstract. There has been increased research interest in systems composed of multiple autonomous mobile robots exhibiting cooperative behavior. Groups of mobile robots are constructed, with an aim to studying such issues as group architecture, resource conflict, origin of cooperation, learning, and geometric problems. As yet, few applications of cooperative robotics have been reported, and supporting theory is still in its formative stages. In this paper, we give a critical survey of existing works and discuss open problems in this field, emphasizing the various theoretical issues that arise in the study of cooperative robotics. We describe the intellectual heritages that have guided early research, as well as possible additions to the set of existing motivations.Keywords: cooperative robotics, swarm intelligence, distributed robotics, artificial intelligence, mobile robots, multiagent systems1. PreliminariesThere has been much recent activity toward achieving systems of multiple mobile robots engaged in collective behavior. Such systems are of interest for several reasons:•tasks may be inherently too complex (or im-possible) for a single robot to accomplish, or performance benefits can be gained from using multiple robots;•building and using several simple robots can be easier, cheaper, more flexible and more fault-tolerant than having a single powerful robot foreach separate task; and•the constructive, synthetic approach inherent in cooperative mobile robotics can possibly∗This is an expanded version of a paper which originally appeared in the proceedings of the 1995 IEEE/RSJ IROS conference. yield insights into fundamental problems in the social sciences (organization theory, economics, cognitive psychology), and life sciences (theoretical biology, animal ethology).The study of multiple-robot systems naturally extends research on single-robot systems, butis also a discipline unto itself: multiple-robot systems can accomplish tasks that no single robot can accomplish, since ultimately a single robot, no matter how capable, is spatially limited. Multiple-robot systems are also different from other distributed systems because of their implicit “real-world” environment, which is presumably more difficult to model and reason about than traditional components of distributed system environments (i.e., computers, databases, networks).The term collective behavior generically denotes any behavior of agents in a system having more than one agent. the subject of the present survey, is a subclass of collective behavior that is characterized by cooperation. Webster’s dictionary [118] defines “cooperate” as “to associate with anoth er or others for mutual, often economic, benefit”. Explicit definitions of cooperation in the robotics literature, while surprisingly sparse, include:1. “joint collaborative behavior that is directed toward some goal in which there is a common interest or reward” [22];2. “a form of interaction, usually based on communication” [108]; and3. “[joining] together for doing something that creates a progressive result such as increasing performance or saving time” [137].These definitions show the wide range of possible motivating perspectives. For example, definitions such as (1) typically lead to the study of task decomposition, task allocation, and other dis-tributed artificial intelligence (DAI) issues (e.g., learning, rationality). Definitions along the lines of (2) reflect a concern with requirements for information or other resources, and may be accompanied by studies of related issues such as correctness and fault-tolerance. Finally, definition (3) reflects a concern with quantified measures of cooperation, such as speedup in time to complete a task. Thus, in these definitions we see three fundamental seeds: the task, the mechanism of cooperation, and system performance.We define cooperative behavior as follows: Given some task specified by a designer, a multiple-robot system displays cooperative behavior if, due to some underlying mechanism (i.e., the “mechanism of cooperation”), there is an increase in the total utility of the system. Intuitively, cooperative behavior entails some type of performance gain over naive collective behavior. The mechanism of cooperation may lie in the imposition by the designer of a control or communication structure, in aspects of the task specification, in the interaction dynamics of agent behaviors, etc.In this paper, we survey the intellectual heritage and major research directions of the field of cooperative robotics. For this survey of cooperative robotics to remain tractable, we restrict our discussion to works involving mobile robots or simulations of mobile robots, where a mobile robot is taken to be an autonomous, physically independent, mobile robot. In particular, we concentrated on fundamental theoretical issues that impinge on cooperative robotics. Thus, the following related subjects were outside the scope of this work:•coordination of multiple manipulators, articulated arms, or multi-fingered hands, etc.•human-robot cooperative systems, and user-interface issues that arise with multiple-robot systems [184] [8] [124] [1].•the competitive subclass of coll ective behavior, which includes pursuit-evasion [139], [120] and one-on-one competitive games [12]. Note that a cooperative team strategy for, e.g., work on the robot soccer league recently started in Japan[87] would lie within our present scope.•emerging technologies such as nanotechnology [48] and Micro Electro-Mechanical Systems[117] that are likely to be very important to co-operative robotics are beyond the scope of this paper.Even with these restrictions, we find that over the past 8 years (1987-1995) alone, well over 200papers have been published in this field of cooperative (mobile) robotics, encompassing theories from such diverse disciplines as artificial intelligence, game theory/economics, theoretical biology, distributed computing/control, animal ethology and artificial life.We are aware of two previous works that have surveyed or taxonomized the literature. [13] is abroad, relatively succinct survey whose scope encompasses distributed autonomous robotic systems(i.e., not restricted to mobile robots). [50] focuses on several well-known “swarm” architectures (e.g., SWARM and Mataric’s Behavior-based architecture –see Section 2.1) and proposes a taxonomy to characterize these architectures. The scope and intent of our work differs significantly from these, in that (1) we extensively survey the field of co-operative mobile robotics, and (2) we provide a taxonomical organization of the literature based on problems and solutions that have arisen in the field (as opposed to a selected group of architectures). In addition, we survey much new material that has appeared since these earlier works were published.Towards a Picture of Cooperative RoboticsIn the mid-1940’s Grey Walter, along with Wiener and Shannon, studied turtle-like robots equipped wit h light and touch sensors; these simple robots exhibited “complex social behavior” in responding to each other’s movements [46]. Coordination and interactions of multiple intelligent agents have been actively studied in the field of distributed artificial intelligence (DAI) since the early 1970’s[28], but the DAI field concerned itself mainly with problems involving software agents. In the late 1980’s, the robotics research community be-came very active in cooperative robotics, beginning with projects such as CEBOT [59], SWARM[25], ACTRESS [16], GOFER [35], and the work at Brussels [151]. These early projects were done primarily in simulation, and, while the early work on CEBOT, ACTRESS and GOFER have all had physical implementations (with≤3 robots), in some sense these implementations were presented by way of proving the simulation results. Thus, several more recent works (cf. [91], [111], [131])are significant for establishing an emphasis on the actual physical implementation of cooperative robotic systems. Many of the recent cooperative robotic systems, in contrast to the earlier works, are based on a behavior-based approach (cf. [30]).Various perspectives on autonomy and on the connection between intelligence and environment are strongly associated with the behavior-based approach [31], but are not intrinsic to multiple-robot systems and thus lie beyond our present scope. Also note that a recent incarnation of CEBOT, which has been implemented on physical robots, is based on a behavior-based control architecture[34].The rapid progress of cooperative robotics since the late 1980’s has been an interplay of systems, theories and problems: to solve a given problem, systems are envisioned, simulated and built; theories of cooperation are brought from other fields; and new problems are identified (prompting further systems and theories). Since so much of this progress is recent, it is not easy to discern deep intellectual heritages from within the field. More apparent are the intellectualheritages from other fields, as well as the canonical task domains which have driven research. Three examples of the latter are:•Traffic Control. When multiple agents move within a common environment, they typically attempt to avoid collisions. Fundamentally, this may be viewed as a problem of resource conflict, which may be resolved by introducing, e.g., traffic rules, priorities, or communication architectures. From another perspective, path planning must be performed taking into con-sideration other robots and the global environment; this multiple-robot path planning is an intrinsically geometric problem in configuration space-time. Note that prioritization and communication protocols – as well as the internal modeling of other robots – all reflect possible variants of the group architecture of the robots. For example, traffic rules are commonly used to reduce planning cost for avoiding collision and deadlock in a real-world environment, such as a network of roads. (Interestingly, behavior-based approaches identify collision avoidance as one of the most basic behaviors [30], and achieving a collision-avoidance behavior is the natural solution to collision avoidance among multiple robots. However, in reported experiments that use the behavior-based approach, robots are never restricted to road networks.) •Box-Pushing/Cooperative Manipulation. Many works have addressed the box-pushing (or couch-pushing) problem, for widely varying reasons. The focus in [134] is on task allocation, fault-tolerance and (reinforcement) learning. By contrast, [45] studies two boxpushing protocols in terms of their intrinsic communication and hardware requirements, via the concept of information invariants. Cooperative manipulation of large objects is particularly interesting in that cooperation can be achieved without the robots even knowing of each others’ existence [147], [159]. Other works in the class of box-pushing/object manipulation include [175] [153] [82] [33] [91] [94] [92][114] [145] [72] [146].•Foraging. In foraging, a group of robots must pick up objects scattered in the environment; this is evocative of toxic waste cleanup, harvesting, search and rescue, etc. The foraging task is one of the canonical testbeds for cooperative robotics [32] [151] [10] [67] [102] [49] [108] [9][24]. The task is interesting because (1) it can be performed by each robot independently (i.e., the issue is whether multiple robots achieve a performance gain), and (2) as discussed in Section 3.2, the task is also interesting due to motivations related to the biological inspirations behind cooperative robot systems. There are some conceptual overlaps with the related task of materials handling in a manufacturing work-cell [47]. A wide variety of techniques have been applied, ranging from simple stigmergy (essentially random movements that result in the fortuitous collection of objects [24] to more complex algorithms in which robots form chains along which objects are passed to the goal [49].[24] defines stigmergy as “the production of a certain behaviour in agents as a consequence of the effects produced in the local environment by previous behaviour”. This is actually a form of “cooperation without communication”, which has been the stated object of several for-aging solutions since the corresponding formulations become nearly trivial if communication is used. On the other hand, that stigmergy may not satisfy our definition of cooperation given above, since there is no performance improvement over the “naive algorithm” –in this particular case, the proposed stigmergic algorithm is the naive algorithm. Again, group architecture and learning are major research themes in addressing this problem.Other interesting task domains that have received attention in the literature includemulti-robot security systems [53], landmine detection and clearance [54], robotic structural support systems (i.e., keeping structures stable in case of, say ,an earthquake) [107], map making [149], and assembly of objects using multiple robots [175].Organization of PaperWith respect to our above definition of cooperative behavior, we find that the great majority of the cooperative robotics literature centers on the mechanism of cooperation (i.e., few works study a task without also claiming some novel approach to achieving cooperation). Thus, our study has led to the synthesis of five “Research Axes” which we believe comprise the major themes of investigation to date into the underlying mechanism of cooperation.Section 2 of this paper describes these axes, which are: 2.1 Group Architecture, 2.2 Resource Conflict, 2.3 Origin of Cooperation, 2.4 Learning, and 2.5 Geometric Problems. In Section 3,we present more synthetic reviews of cooperative robotics: Section 3.1 discusses constraints arising from technological limitations; and Section 3.2discusses possible lacunae in existing work (e.g., formalisms for measuring performance of a cooperative robot system), then reviews three fields which we believe must strongly influence future work. We conclude in Section 4 with a list of key research challenges facing the field.2. Research AxesSeeking a mechanism of cooperation may be rephrased as the “cooperative behavior design problem”: Given a group of robots, an environment, and a task, how should cooperative behavior arise? In some sense, every work in cooperative robotics has addressed facets of this problem, and the major research axes of the field follow from elements of this problem. (Note that certain basic robot interactions are not task-performing interactions per se, but are rather basic primitives upon which task-performing interactions can be built, e.g., following ([39], [45] and many others) or flocking [140], [108]. It might be argued that these interactions entail “control and coordination” tasks rather than “cooperation” tasks, but o ur treatment does not make such a distinction).First, the realization of cooperative behavior must rely on some infrastructure, the group architecture. This encompasses such concepts as robot heterogeneity/homogeneity, the ability of a given robot to recognize and model other robots, and communication structure. Second, for multiple robots to inhabit a shared environment, manipulate objects in the environment, and possibly communicate with each other, a mechanism is needed to resolve resource conflicts. The third research axis, origins of cooperation, refers to how cooperative behavior is actually motivated and achieved. Here, we do not discuss instances where cooperation has been “explicitly engineered” into the robots’ behavior since this is the default approach. Instead, we are more interested in biological parallels (e.g., to social insect behavior), game-theoretic justifications for cooperation, and concepts of emergence. Because adaptability and flexibility are essential traits in a task-solving group of robots, we view learning as a fourth key to achieving cooperative behavior. One important mechanism in generating cooperation, namely,task decomposition and allocation, is not considered a research axis since (i) very few works in cooperative robotics have centered on task decomposition and allocation (with the notable exceptions of [126], [106], [134]), (ii) cooperative robot tasks (foraging, box-pushing) in the literature are simple enough that decomposition and allocation are not required in the solution, and (iii) the use of decomposition and allocation depends almost entirely on the group architectures(e.g. whether it is centralized or decentralized).Note that there is also a related, geometric problem of optimizing the allocation of tasks spatially. This has been recently studied in the context of the division of the search of a work area by multiple robots [97]. Whereas the first four axes are related to the generation of cooperative behavior, our fifth and final axis –geometric problems–covers research issues that are tied to the embed-ding of robot tasks in a two- or three-dimensional world. These issues include multi-agent path planning, moving to formation, and pattern generation.2.1. Group ArchitectureThe architecture of a computing sys tem has been defined as “the part of the system that remains unchanged unless an external agent changes it”[165]. The group architecture of a cooperative robotic system provides the infrastructure upon which collective behaviors are implemented, and determines the capabilities and limitations of the system. We now briefly discuss some of the key architectural features of a group architecture for mobile robots: centralization/decentralization, differentiation, communications, and the ability to model other agents. We then describe several representative systems that have addressed these specific problems.Centralization/Decentralization The most fundamental decision that is made when defining a group architecture is whether the system is centralized or decentralized, and if it is decentralized, whether the system is hierarchical or distributed. Centralized architectures are characterized by a single control agent. Decentralized architectures lack such an agent. There are two types of decentralized architectures: distributed architectures in which all agents are equal with respect to control, and hierarchical architectures which are locally centralized. Currently, the dominant paradigm is the decentralized approach.The behavior of decentralized systems is of-ten described using such terms as “emergence” and “self-organization.” It is widely claimed that decentralized architectures (e.g., [24], [10], [152],[108]) have several inherent advantages over centralized architectures, including fault tolerance, natural exploitation of parallelism, reliability, and scalability. However, we are not aware of any published empirical or theoretical comparison that supports these claims directly. Such a comparison would be interesting, particularly in scenarios where the team of robots is relatively small(e.g., two robots pushing a box), and it is not clear whether the scaling properties of decentralization offset the coordinative advantage of centralized systems.In practice, many systems do not conform toa strict centralized/decentralized dichotomy, e.g., many largely decentralized architectures utilize “leader” agents. We are not aware of any in-stances of systems that are completely centralized, although there are some hybrid centralized/decentralized architectures wherein there is a central planner that exerts high-levelcontrol over mostly autonomous agents [126], [106], [3], [36].Differentiation We define a group of robots to be homogeneous if the capabilities of the individual robots are identical, and heterogeneous otherwise. In general, heterogeneity introduces complexity since task allocation becomes more difficult, and agents have a greater need to model other individuals in the group. [134] has introduced the concept of task coverage, which measures the ability of a given team member to achieve a given task. This parameter is an index of the demand for cooperation: when task coverage is high, tasks can be accomplished without much cooperation, but otherwise, cooperation is necessary. Task coverage is maximal in homogeneous groups, and decreases as groups become more heterogeneous (i.e., in the limit only one agent in the group can perform any given task).The literature is currently dominated by works that assume homogeneous groups of robots. How-ever, some notable architectures can handle het-erogeneity, e.g., ACTRESS and ALLIANCE (see Section 2.1 below). In heterogeneous groups, task allocation may be determined by individual capabilities, but in homogeneous systems, agents may need to differentiate into distinct roles that are either known at design-time, or arise dynamically at run-time.Communication Structures The communication structure of a group determines the possible modes of inter-agent interaction. We characterize three major types of interactions that can be sup-ported. ([50] proposes a more detailed taxonomy of communication structures). Interaction via environmentThe simplest, most limited type of interaction occurs when the environment itself is the communication medium (in effect, a shared memory),and there is no explicit communication or interaction between agents. This modality has also been called “cooperation without communication” by some researchers. Systems that depend on this form of interaction include [67], [24], [10], [151],[159], [160], [147].Interaction via sensing Corresponding to arms-length relationships inorganization theory [75], interaction via sensing refers to local interactions that occur between agents as a result of agents sensing one another, but without explicit communication. This type of interaction requires the ability of agents to distinguish between other agents in the group and other objects in the environment, which is called “kin recognition” in some literatures [108]. Interaction via sensing is indispensable for modeling of other agents (see Section 2.1.4 below). Because of hard-ware limitations, interaction via sensing has often been emulated using radio or infrared communications. However, several recent works attempt to implement true interaction via sensing, based on vision [95], [96], [154]. Collective behaviors that can use this kind of interaction include flocking and pattern formation (keeping in formation with nearest neighbors).Interaction via communicationsThe third form of interaction involves explicit communication with other agents, by either directed or broadcast intentional messages (i.e. the recipient(s) of the message may be either known or unknown). Because architectures that enable this form of communication are similar tocommunication networks, many standard issues from the field of networks arise, including the design of network topologies and communications protocols. For ex-ample, in [168] a media access protocol (similar to that of Ethernet) is used for inter-robot communication. In [78], robots with limited communication range communicate to each other using the “hello-call” protocol, by which they establish “chains” in order to extend their effective communication ranges. [61] describes methods for communicating to many (“zillions”) robots, including a variety of schemes ranging from broadcast channels (where a message is sent to all other robots in the system) to modulated retroreflection (where a master sends out a laser signal to slaves and interprets the response by the nature of the re-flection). [174] describes and simulates a wireless SMA/CD ( Carrier Sense Multiple Access with Collision Detection ) protocol for the distributed robotic systems.There are also communication mechanisms designed specially for multiple-robot systems. For example, [171] proposes the “sign-board” as a communication mechanism for distributed robotic systems. [7] gives a communication protocol modeled after diffusion, wherein local communication similar to chemical communication mechanisms in animals is used. The communication is engineered to decay away at a preset rate. Similar communications mechanisms are studied in [102], [49], [67].Additional work on communication can be found in [185], which analyzes optimal group sizes for local communications and communication delays. In a related vein, [186], [187] analyzes optimal local communication ranges in broadcast communication.Modeling of Other Agents Modeling the intentions, beliefs, actions, capabilities, and states of other agents can lead to more effective cooperation between robots. Communications requirements can also be lowered if each agent has the capability to model other agents. Note that the modeling of other agents entails more than implicit communication via the environment or perception: modeling requires that the modeler has some representation of another agent, and that this representation can be used to make inferences about the actions of the other agent.In cooperative robotics, agent modeling has been explored most extensively in the context of manipulating a large object. Many solutions have exploited the fact that the object can serve as a common medium by which the agents can model each other.The second of two box-pushing protocols in[45] can achieve “cooperation without commun ication” since the object being manipulated also functions as a “communication channel” that is shared by the robot agents; other works capitalize on the same concept to derive distributed control laws which rely only on local measures of force, torque, orientation, or distance, i.e., no explicit communication is necessary (cf. [153] [73]).In a two-robot bar carrying task, Fukuda and Sekiyama’s agents [60] each uses a probabilistic model of the other agent. When a risk threshold is exceeded, an agent communicates with its partner to maintain coordination. In [43], [44], the theory of information invariants is used to show that extra hardware capabilities can be added in order to infer the actions of the other agent, thus reducing communication requirements. This is in contrast to [147], where the robots achieve box pushing but are not aware of each other at all. For a more com-plex task involving the placement of five desks in[154], a homogeneous group of four robots share a ceiling camera to get positional information, but do not communicate with each other. Each robot relies on modeling of otheragents to detect conflicts of paths and placements of desks, and to change plans accordingly.Representative Architectures All systems implement some group architecture. We now de-scribe several particularly well-defined representative architectures, along with works done within each of their frameworks. It is interesting to note that these architectures encompass the entire spectrum from traditional AI to highly decentralized approaches.CEBOTCEBOT (Cellular roBOTics System) is a decentralized, hierarchical architecture inspired by the cellular organization of biological entities (cf.[59] [57], [162] [161] [56]). The system is dynamically reconfigurable in tha t basic autonomous “cells” (robots), which can be physically coupled to other cells, dynamically reconfigure their structure to an “optimal” configuration in response to changing environments. In the CEBOT hierarchy there are “master cells” that coordinate subtasks and communicate with other master cells. A solution to the problem of electing these master cells was discussed in [164]. Formation of structured cellular modules from a population of initially separated cells was studied in [162]. Communications requirements have been studied extensively with respect to the CEBOT architecture, and various methods have been proposed that seek to reduce communication requirements by making individual cells more intelligent (e.g., enabling them to model the behavior of other cells). [60] studies the problem of modeling the behavior of other cells, while [85], [86] present a control method that calculates the goal of a cell based on its previous goal and on its master’s goal. [58] gives a means of estimating the amount of information exchanged be-tween cells, and [163] gives a heuristic for finding master cells for a binary communication tree. Anew behavior selection mechanism is introduced in [34], based on two matrices, the priority matrix and the interest relation matrix, with a learning algorithm used to adjust the priority matrix. Recently, a Micro Autonomous Robotic System(MARS) has been built consisting of robots of 20cubic mm and equipped with infrared communications [121].ACTRESSThe ACTRESS (ACTor-based Robot and Equipments Synthetic System) project [16], [80],[15] is inspired by the Universal Modular AC-TOR Formalism [76]. In the ACTRESS system,“robotors”, including 3 robots and 3 workstations(one as interface to human operator, one as im-age processor and one as global environment man-ager), form a heterogeneous group trying to per-form tasks such as object pushing [14] that cannot be accomplished by any of the individual robotors alone [79], [156]. Communication protocols at different abstraction levels [115] provide a means upon which “group cast” and negotiation mechanisms based on Contract Net [150] and multistage negotiation protocols are built [18]. Various is-sues are studied, such as efficient communications between robots and environment managers [17],collision avoidance [19].SWARM。
《人工智能一种现代方法》第四版习题答案
• Model-based agent基于茹苦型的主FifS 体: an agent wbose actioD is derived directly from an internal model ofthe c田rent world state that is updated over time.
ac挝on. 实现了智能函数。有各种基本的智能体程序设计 , 反应出现实表现的 一级用于决策过程的 信息 种类。 设计可能在效率 、 压缩性和灵活性方面有变化 。 适 当 的智能体程序设计取决于环境的本性
• Rationali句; 王军放 : a property of agents that choose actions that maximize tbeir expected u创坷, given the percepts to date. • Autonomy fJ主: a property of agenωwhose bebavior is determined by tbeir own experience rather than solely by their initial programming. .R伪'x agent反射却在FSE体: an agent whose action depends only on the current percept.
Chapter 2
2.1 Defme in yo町 own words the following terms: agent, agent function, agent program , rationality, reflex agent, model-b ased agent, goal-based agent, utility-based agent, learning agent. The following are just some of the many possible defmitions that can be written:
福特网络FortiGate虚拟应用和迁移自动化说明书
1“We needed a solution that would allow us to extend our existing security framework into the cloud, while maintaining full control and visibility across the entire infrastructure. Using the Fortinet Fabric Connector for Azure Cloud Services, together with virtual instances of the FortiGate NGFW, gave us single-pane-of-glass control and visibility over everything.”–Marc Verstraaten, Cloud Architect, Wageningen University & Research CASE STUDYLeading Dutch University for Environmental Research Harnesses the Cloud With FortiGate Virtual Appliances and Migration AutomationWageningen University & Research, located in the town of Wageningen in theNetherlands, is one of the world’s highest-ranking universities in disciplinesspanning environmental science, agriculture, forestry, and ecology.In addition to its renown in education and fundamental research, theestablishment has a strong global position as a supplier of application-orientedand field-based research, collaborating with other educational and researchinstitutes, as well as governments, non-governmental organizations, andbusinesses from around the world.Wageningen University & Research employs over 6,500 staff and currently servesaround 12,500 students from over 100 countries.Securely Harnessing the Potential of Dynamic Cloud ServicesA Fortinet customer since 2014, the university had long leveraged FortiGatenext-generation firewalls (NGFWs) to protect applications and data within theperimeters of its two centrally located data centers.FortiGate NGFWs combine dedicated, purpose-built security processors withthreat-intelligence services from FortiGuard Labs to deliver top-rated security andhigh-performance threat protection.With the addition of FortiManager centralized network management andFortiAnalyzer analytics and automation (collectively known as the FabricManagement Center), network administrators gain powerful network management,automation, and response, with broad visibility and granular device and role-basedadministration across the entire infrastructure.In early 2020, with increasing research collaboration on projects requiring a moreflexible and dynamic infrastructure, the university’s IT team realized that it wouldneed to start moving some of these workloads to the cloud.The team chose Azure Cloud Services from Microsoft as its cloud provider. TheAzure Infrastucture -as-a-Service (I aaS) environment provided the agility, scalability,and control the team needed, but the move to the cloud complicated the process ofmaintaining security. Having witnessed a recent high-profile breach at anotheruniversity in the Netherlands, Wageningen University & Research was takingno chances.“We needed a solution that would allow us to extend our existing securityframework into the cloud, while maintaining full control and visibility across theentire infrastructure,” explains Marc Verstraaten, cloud architect at WageningenUniversity & Research. “Using the Fortinet Fabric Connector for Azure CloudServices, together with virtual instances of the FortiGate NGFW, gave us single-pane-of-glass control and visibility over everything.”Details Customer: Wageningen University & Research Industry: Education Location: The Netherlands Business Impact n n Improved flexibility, scalability, and management of IT resources n n Enhanced security n n Greater control and visibility of global research applications and dataCASE STUDY | Leading Dutch University for Environmental Research Harnesses the Cloud With FortiGate Virtual Appliances and Migration Automation Copyright © 2021 Fortinet, Inc. All rights reserved. Fortinet ®, FortiGate ®, FortiCare ® and FortiGuard ®, and certain other marks are registered trademarks of Fortinet, Inc., and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. Fortinet disclaims in full any covenants, representations, and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.May 5, 2021 3:46 AMD:\Fortinet\2021 Rebranded templates\Case Studies\May\WUR\cs-leading-dutch-university-V1-552021\cs-leading-dutch-university-V1-5520211007903-0-0-EN Solutions n n FortiGate VM n n FortiGate n n FortiManager n n FortiAnalyzer The Fortinet Security Fabric is an architectural approach that enables themultiple security elements of a network to act together as a single, intelligent,responsive entity.Since FortiGate virtual appliances are built on the same FortiOS operatingsystem as their physical counterparts, they enable customers to create theoptimal architecture for their specific environment, balancing the unparalleledperformance of the physical form factor with the flexibility and scalability of thevirtual, to provide seamless visibility and control from the network core right out tothe edge.Through FortiManager and the Fortinet Security Fabric, configuration andpolicy management can then be consolidated across both physical and virtualenvironments through a single pane of glass, simplifying management andreducing the potential for service degradation or bottlenecks.Non-Fortinet components, such as those within the Azure Cloud Servicesenvironment, can then be brought under the protective umbrella of the FortinetSecurity Fabric through prebuilt application programming interfaces (APIs) knownas Fabric Connectors.For complex application development operations such as those of WageningenUniversity & Research, one of the key risks associated with moving workloadsinto the cloud is the potential introduction of vulnerabilities resulting fromconfiguration errors and manual data compilation.“The ability to integrate automated cloud deployment scripts into the already-familiar management interface of FortiManager and FortiAnalyzer was anotherkey advantage for us,” adds Verstraaten. “Our team was well-versed in theimplementation of on-premises security policies but lacked experience with thecloud environment.”Ready for the Future“The ability to integrate automated cloud deployment scripts into the already-familiar management interface of FortiManager and FortiAnalyzer was another key advantage for us. Our team was well-versed in the implementation of on-premises security policies but lacked experience with the cloud environment.”– Marc Verstraaten, Cloud Architect, Wageningen University & ResearchHaving completed the first phase of their new cloud migration, the university is now looking to optimize service delivery through the built-in load-balancing capabilities of the FortiGate virtual appliances.“One of the things we particularly like about the Fortinet solution is the range of functionality you get right out of the box,” comments Verstraaten. “It means we can move at a pace that suits us, deploying additional capabilities as and when we need them.”The university’s stated mission, “To explore the potential of nature to improve the quality of life” is undoubtedly one ofincreasing significance in the face of globally accelerating technological and environmental change. Through the FortinetSecurity Fabric and the continued efforts of Marc Verstraaten and his team, Wageningen University & Research is now able to pursue that mission with a greatly reduced risk of disruption from the ever-evolving specter of cyberattack.。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
An agent-based architecture for multi-modal interactionC ATHOLIJN M. J ONKER, J AN T REUR AND W OUTER C.A. W IJNGAARDS†Department of Artificial Intelligence, Vrije Universiteit Amsterdam,De Boelelaan 1081a, 1081 HV Amsterdam, The NetherlandsURL: http://www.cs.vu.nl /~{jonker,treur,wouterw} Email: {jonker,treur,wouterw}@cs.vu.nl In this paper an executable generic process model is proposed for combined verbal and non-verbal communication processes and their interaction. The agent-based architecture can be used to create multi-modal interaction. The generic process model has been designed, implemented interactively and used to simulate different types of interaction between verbal and non-verbal communication processes: a non-verbal communication process can add and modify content to a verbal communication process, but can also provide a protocol for the (control of the) verbal communication process. With respect to the communication protocol both stimulus-response behaviour and deliberative behaviour have been modelled and simulated. The semantics of the model has been formalised by three-levelled partial temporal models, covering both the material and mental processes and their relations.KEYWORDS: intentional models; agent modelling; non-verbal communication; formalisation; human computer interaction; semantic levels; meta levels1. IntroductionCommunication is often modelled exclusively as a process of information exchange, abstracting from the physical realisation of the communication process. This approach is based on the more general perspective that a strict separation between the mental aspect (symbolic processes) and the material aspect (physical processes) has advantages in modelling. Following this perspective, the communication process is not embedded in the physical environment. In particular, for the case of embodied non-verbal communication, for example on the basis of body language or gestures, a strict separation of communication processes from interaction at the material level can be rather artificial. On the other hand, describing communication processes only in physical terms may be too restrictive as well. In the model of communication presented in this paper both the material level and the level of information, as well as the interaction between the levels are taken into account in one generic process model.At the symbolic level a distinction can be made between information representing the subject matter of the communication, and information that refers to the process of communication, for example, information on the communication protocol that is followed, or the current stage of the communication process within the protocol. Thus, in the model three semantic or representation levels are introduced:•the material level (for the physical world),•the symbolic object level (for symbolic manipulation of content information on the physical world), and •the symbolic meta-level (for symbolic manipulation of the dynamics and reflective aspects of the agents). Each of these three levels uses representations of structures of one of the other levels: the symbolic object level uses representations of the information from the material world, the symbolic meta-level uses representations of the information from the symbolic object level, and the material level uses representations of the information from the symbolic object level. The three levels of representation and the forms of interaction between verbal and non-verbal communication are detailed in Section 2. It is shown how the generic process model can be applied to model both verbal communication and non-verbal communication, as well as different types of interaction between these forms of communication, in one semantic framework. One example application of the model is presented in which the communication protocol of a verbal communication process is modelled as reflex-based non-verbal communication (one gesture triggers steps in the verbal communication and other gestures by stimulus-response behaviour). In a second example model the non-verbal communication in the communication protocol is guided by conscious deliberation. A third model addresses goal directed conscious deliberation.Next, in Section 3 an executable generic process model is introduced in which a number of processes within a communication process are distinguished. This process model is in accordance with the semantics given in Section 2.† Parts of the material of this paper were presented (in preliminary form) in WECC’98 and ACL’99.The generic process model proposed in this paper can be used to create multimodal interactive systems, such that apart from the possiblity of using a verbal language to interact with the system, also non-verbal interaction is possible. By using the components and knowledge types of the architecture, it becomes possible for the system to handle both the user integrating non-verbal cues in his or her communication and to return integrated non-verbal cues to the user as well. This makes for much more intuitive interaction, bringing the machine closer to the user by allowing a broader scope of interaction. The agent-based architecture proposed here can thus be used to easily create a system capable of verbal and non-verbal interaction.An interactive prototype has been built of the example communication process in this paper. It uses icons to display the agents’ situation. The reasoning model used inside the simulated agents can be selected. Also, the user can take on the role of an agent, interacting with the other agent, the interactive demo is presented in Section 4.The behaviour displayed by the model is described in section 5. The reflex-based, conscious deliberative and goal-directed conscious deliberative models are described seperately. In Section 6 the results are evaluated. The three levels are explained in more detail in Section 7; a process semantics is defined by means of multi-levelled traces based on triples of three-valued states, formalised by partial models (Engelfriet and Treur, 1995). Section 8 summarizes and compares this approach with other work. In Appendix A a trace of the process is given in symbolic notation, demonstrating the stimulus-response case. In appendix B the trace using conscious reasoning is given and in Appendix C the trace using goal-directed conscious reasoning is given in symbolic notation.2. Distinguishing and relating verbal and non-verbal aspectsTo create an appropriate model we first need to understand verbal and non-verbal communication and their interactions. In order to do this, in section 2.1 we first put both types of communication on a common ground by giving a semantic model.During real-life communication processes several types of communication play a role, among them are verbal and non-verbal communication. Furthermore, combining verbal and non-verbal communication can sometimes be done in a stimulus-response manner in contrast to consciously. In Section 2.2 different types of interaction between verbal and non-verbal communication are distinguished and explained. Also, an example communication process is introduced, which will be reused later on. Section 2.3 proceeds by relating verbal and non-verbal processes, showing how differences between reflex-based (also called direct stimulus-response) reactions and conscious reactions on non-verbal communication can be modelled.2.1. SEMANTIC LEVELS IN COMMUNICATIONThe semantic model is built by identifying the semantic levels involved, making the representation relations between them explicit, and by determining the state transitions at the different levels during the communication process. Three semantic levels are used in the semantic model of communication presented in this paper. The first is the material level: of the world itself, the physical reality. The second level is the level of symbolic representation of the world state: the symbolic object level. Within the agents, symbols are used to represent information regarding the world state. The third semantic level is the symbolic level where the agent reasons about aspects of its own state, e.g., its own knowledge and actions it intends to perform in the world: the symbolic meta-level. Symbolic expressions at this level do not represent information about world states, but instead are an explicit representation of information about the state of the process, of an agent’s related mental aspects, such as its state of knowledge, its goals, and its intentions.2.2. A SIMPLE EXAMPLE COMMUNICATION PROCESSAll examples in this paper are about a lecture, which is finishing. The chair person, agent A, puts up a slide expressing where to find tea and coffee. A thirsty person in the audience, agent B, interprets this information. However, the communication may be affected by an event in the material world, for example, somebody erroneously standing between the projector and the screen. A trace is shown in Table 1, the expressions used at the symbolic meta-level are explained in Table 2.In the example, agent A has a representation of the world information that pot 2 contains tea, represented at the symbolic object level by the symbolic expression contains(pot2, tea). By upward reflection to the symbolic meta-level it establishes that it has the positive belief that pot 2 contains tea. The agent A reasons at the symbolic meta-level and concludes that this world information should be communicated to agent B. Using knowledge of the meaning that can be associated to certain material configurations, it discovers that if at position p0 in the material world pattern 3 is visible then this world situation represents that pot 2 contains tea (e.g., a written text on a visible place). Moreover, still reasoning at the symbolic meta-level, it finds out that an action ‘put slide 3’exists, which has as an effect that pattern 3 is at position p0. Therefore it concludes at the symbolic meta-level that the action ‘put slide 3’ has to be performed. The action is performed, and the intended effect is realised in the world state at the material level. In the example, the two agents are assumed to have a common ontology on the world including the names of all objects in the world, like pot 2, pattern 3, and the names of the positions. Agent B performs the observation that pattern 3 is at position p0 (which provides information at the symbolic meta-level, namely the meta-fact that this has been observed), and represents the information acquired at the symbolic object level by at_position(pattern3, p0)(the agent B’s world model). Note that agent B cannot observe directly the world information that pot 2 contains tea or that slide 3 is on the projector, but it can observe that pattern 3 is at position p0. Knowing at the symbolic meta-level that to this world situation the interpretation ‘pot 2 contains tea’ can be associated, it now concludes at the symbolic meta-level that it has been communicated that pot 2 contains tea. This information is then stored by B at the symbolic object level in its representation of the world state. Note that after this process, the representation of the world state at the symbolic object level includes information that was acquired by observation (pattern 3 is at position p0), and also information that was not obtainable by observation, but acquired by the communication process (pot 2 contains tea).This example communication process can be described by tracing the states and state transitions at the different levels; see Table 1. In this table each cell describes a state, and state transitions are indicated by a line separating the two states in the transition. Time goes from top to bottom. In the table only the relevant new information elements are represented. The first part of the table gives the state of the external world (first column), and the states of the symbolic object level and meta-level of agent A (second and third column). The second part of the table gives the same for agent B. The first part of the table ‘happens’ before the second part of the table.T ABLE 1Multi-levelled trace of an example communication processE xternal World A gent Am aterial level s ymbolic object level S ymbolic meta-levelp ot 2 contains tea c ontains(pot2,tea)b elief(contains(pot2,tea),pos)h as_verbal_material_rep(contains(pot2,tea),pos,at_position(pattern3,p0), pos)h as_effect(put_slide3, at_position(pattern3,p0),pos)t o_be_observed(I:INFO_ELEMENT)t o_be_communicated(contains(pot2,tea),pos)t o_be_achieved(at_position(pattern3,p0),pos)t o_be_performed(put_slide3)s lide 3 at projectorp attern3 at p0E xternal World A gent Bm aterial level s ymbolic object level s ymbolic meta-levelp ot 2 contains tea s lide 3 at projector p attern3 at p0t o_be_observed(I:INFO_ELEMENT)h as_verbal_material_rep(contains(pot2,tea),pos,at_position(pattern3,p0), pos)o bservation_result(at_position(pattern3,p0), pos)a t_position(pattern3,p0)b elief(at_position(pattern3,p0), pos)h as_been_communicated(contains(pot2, tea), pos) c ontains(pot2, tea)b elief(contains(pot2,tea), pos)T ABLE 2Explanations for the expressions at the symbolic meta-level.Symbol Explanationbelief The beliefs of the agent. Refers to world information and a sign. The sign (pos or neg) indicates if the information is true of false.has_effect Denotes that an action is capable of bringing about some state in the world, given as the state that becomes true or false in the world.to_be_observed The information that the agent focuses on and observes in the world.to_be_communicated The information that is determined to need communication to the other agent. Includes sign. It has been kept simple in this model, but could be extended to include a recipientagent.to_be_achieved A goal to be achieved. The goal is stated as a state of the world that must be brought about. The sign indicates if the state should hold or not.to_be_performed Refers to the action(s) to be performed by the actuators of the agent.has_verbal_material_rep The first information element has the second information element as a verbal material representation. Thus the first is an interpretation of the second.observation_result The information received by the sensors of the agent. Includes sign of the information. has_been_communicated The information that has been received by communication. Includes sign of the information.2.3. TYPES OF INTERACTION BETWEEN VERBAL AND NON-VERBAL COMMUNICATIONThe example communication process in Section 2.1 shows only verbal communication. The verbal type of communication is the type that is normally exclusively considered in research in multi-agent systems in which all agents are software agents. However, in real life situations, often the non-verbal communication is as important as verbal communication. In this section, non-verbal communication is addressed and classified into three different types of interaction with verbal communication. In the classification one of the distinguishing criteria is the nature of the processing of the communication: based on reflex reactions, or on conscious reactions. For each of the types of interaction between verbal and non-verbal communication an example is presented.The following kinds of interaction between non-verbal and verbal communication are distinguished:A.Interaction of non-verbal communication with the content of verbal communication:1.non-verbal communication provides information additional to the content information transferred by theof the verbal communication:•the subject of the non-verbal communication has no connection with the subject of the verbal communication•the subject of the non-verbal communication is related to the subject of the verbal communication2.non-verbal communication affects the interpretation of the contents of the verbal communication;modified interpretationB.Interaction of non-verbal communication with the process of the verbal communication:1.the verbal communication process is affected by reflex-based reactions to the non-verbal communication2.the verbal communication process is affected by conscious reactions to the non-verbal communication Notice that non-verbal communication of type A. will lead to conscious reactions of the recipient; as the interpretation of observations as being communicated information is a conscious process. Combinations of the different types of interaction can occur during one communication process. In the examples it is assumed that the agents share a common ontology for world information. Simple examples of the different types of non-verbal communication are:A.Interaction of non-verbal communication with the content of verbal communication:1. Additional informationa) No connection. Agent A communicates verbally to B that tea can be found in pot 2. Agent B observes that agent A smiles to him and concludes that agent A recognises him. This observation does not influence the communication process concerned with where the tea can be found. Furthermore, agent B does not change his interpretation of the verbal communication on account of noticing that agent A recognises him.b) Related. Agent A communicates verbally to B that tea can be found in pot 2. During the communication Agent A points to position p3. Agent B observes the direction that agent A is pointing in and concludes that agent A is telling it that tea can be found in pot 2 that can be found at position p3.2. Modified interpretationAgent A communicates verbally to B that fresh tea can be found in pot 2. However, agent A makes a face that indicates she is disgusted at the moment the verbal communication process takes place. Agent B combines this non-verbal communication with the verbal one and, therefore, interprets the communication as follows: tea can be found in pot 2, but it is definitely not fresh. Modification of the interpretation of the verbal communication appeared to be necessary, based on the non-verbal part of the communication.B.Interaction of non-verbal communication with the process of verbal communication:Agent A initiates the communication process by walking to position p1. She notices that agent B is looking at her and she starts her communication to agent B that tea can be found in pot 2, by putting the correct slide (slide 3) on the projector. However, after performing this action agent A observes that agent B is looking in another direction; in reaction (either by reflex or consciously) she breaks off the communication process by removing the slide, and (to get attention) starts tapping the microphone. Agent B observes the noise of the microphone and (either by reflex or consciously) reacts by looking at agent A with interest. Agent A waits until she observes that agent B is looking interested, and then resumes the verbal communication process by putting the slide on the projector again. In such a case the information transferred by verbal communication is not affected by the non-verbal communication, but (the control of) the process of communication is.In (Vongkasem & Chaib-draa, 2000) this would correspond to the first level of joint action, the behavior level, where the sender gets the receiver to attend to the message. As well as level 2 of joint action, the signal level. In this level the sender verifies that the communication is well received by the receiver.An example communication process in which a combination of types of interaction occurs is the following:EXAMPLE 1. THE COMPLETE TEA STORY1.Agent A wants to communicate to agent B that non-fresh tea can be found in pot 2 that is located at positionp3.2.Agent A figures out how to perform the communication. She does not have a (verbal) slide that reflects allthat she wants to communicate; she only has a slide that says that fresh tea can be found in pot 2. The rest of the communication will, therefore, have to be non-verbal. She finds the following solution: she will put the slide on the projector, point at position p3 and pull a disgusted face at the same time.3.Agent A attracts the attention of her audience (agent B) by going to position p1.4.Agent B observes this movement and responds by looking interested.5.Agent A observes that agent B is looking interested and performs the prepared actions.6.However, in the mean time, agent B’s attention is distracted by a noise from outside. As a reaction to thenoise from outside agent B looks away from agent A and stops looking interested.7.Agent A notices that agent B no longer is looking in her direction. Therefore, she removes the slide, stopspointing, and reverts her face to a neutral expression. Furthermore, in order to attract agent B’s attention again, she taps the microphone.8.Agent B observes the noise inside the room and towards the front of the room (i.e., in the direction of agentA) and looks interested.9.Agent A waits until agent B looks interested again, and then communicates verbally to agent B that fresh teacan be found in pot 2 (she puts slide 3 on the projector). Agent A makes a face that indicates she is disgusted at the moment the verbal communication takes place. At the same time Agent A points to position p3.10.Agent B observes:a) the pattern on projection screen that is caused by the slideb) that agent A is pointing towards position p3c) that agent A has a disgusted face11.and Agent B concludes:a) tea can be found in pot 2: the interpretation of this part of the verbal communication of the pattern causedby the slide is not affected by any of the non-verbal communication of agent A.b) the tea can be found at position p3: this additional information comes from interpreting the pointinggesture of agent A.c) the tea is definitely not fresh: this interpretation is based on modification of the contents of the verbalcommunication (fresh tea) because of the non-verbal communication (disgusted face ofagent A) and the knowledge that tea has a taste.12.At the same time agent A looks questioningly towards agent B.13.Agent B observes the questioning face of agent A and puts his thumb up.14.Agent A observes that agent B’s thumb is up and walks away from position p1.3. The generic process model for communication3.1. THE PROCESS MODEL FOR COMMUNICATIONWithin a communication process as described in Section 2 a number of more specific symbolic processes can be distinguished:• observation generation• information interpretation• goal generation• action generation• maintenance of world informationTogether with the physical processes in the material world that realise action and observation execution, these processes are used as building blocks to compose an executable generic process model of communication. Within the DESIRE approach each of the processes is modelled by a component (the boxes in Figure 1). Each component processes information as soon as it becomes available. The information is processed by applying knowledge rules to the input information, deriving conclusions that are the output information of the component. Each component conceptually runs in parallel, but on a single processor the component activations are serialized. The interaction is modelled by information links (the arrows in Figure 1). By default information links transfer information from the source to the destination when it becomes available. Agent B is identical in composition to agent A.F IGURE 1. The two highest process abstraction levelsThe component observation_generation contains statements of facts, rules without preconditions. These state what the agent wishes to observe in the world, this is a subset of all possible information elements. The truth value of these elements is of interest to the agent, for example to_be_observed(at_position(agent_A, p1)) means that the agent is interested in knowing if agent A is at p1 or not. Conceptually this set of to_be_observed facts indicates the focus of attention of the agent, i.e. what it is looking at in the world. And although the agent maybe looking at something this does not mean it will receive the requested observation result. In the example, agent B is initiatingobservation of the projection screen en agent A and agent A observes agent B. And although agent B wants to observe the speakers position, at a later moment, when agent B is looking_away, it no longer receives observation results on the speakers position.The information interpretation component interprets facts. It examines the observation results and determines whether these new results should be added to the set of beliefs of the agent. Also it inspects beliefs on the world to check for additional meaning of these world configurations. First the beliefs that have additional meanings are characterized in as being communications by a particular modality, before the communications in the different modalities are combined to finally conclude the communicated information. This information is then added to the agent’s beliefs. Notice that this makes information interpretation a conscious reasoning process. In the example both agents trust their senses, and accordingly store all observed information in their belief set.The agent’s beliefs are the model of the world that the agent currently ascribes to, and it must be stored somewhere. The maintenance_of_world_information component takes care of this. The component takes care of storing the currently believed world model, possibly applying some knowledge rules to augment and extrapolate the world knowledge.The component goal_generation is a component operating at a high level of abstraction. The component takes as input goals on which information should be communicated, the current status of the communication process and the beliefs of the agent, using the available knowledge to generate intentions for changes to the world. In order to select world configurations that will communicate certain information it selects intentions to_be_achieved by first assigning modalities to the information elements, then selecting intentions to bring about representations of these information elements. When reasoning in a goal-directed manner, the necessary intentions are selected by this component. The information elements to be communicated to the other agent are fixed in the example; some other apparatus should generate the content of the communication.The agent needs to be capable of selecting actions to perform in the world. The action_generation component does this. Firstly, it takes the to_be_achieved world situations, the intentions that are transferred from goal_generation, and selects appropriate actions for them. Secondly, it takes the observation_results and applies the stimulus-response rules to them, generating the reflex actions. Thirdly, conscious reasoning takes place in the action_generation component. The to_be_performed facts are transferred to the output of the agent to be executed in the physical, or simulated, world by the external_world component.The component external world takes the observations and the actions initiated by the agents and produces the observation results for the agents. It maintains the state of the world and takes care of the changes to the world state. The physical manifestations of the agents are assumed to be in the external_world component. Thus a robot’s body would reside as an object in the external world, changing state by receiving actions, returning sensor information that is relayed as observation results. A software agent’s screen presence and program code is also part of the external world, the state of the software system being conveyed as observation results. Both these example put the agent body in the external world, and the agent ‘mind’ in the agent_A en agent_B components. For the example communication process the world stores the world situation and has knowledge on the effect of actions, applying it to simulate the effect of the actions. The relevant information elements in the world situation are known completely, i.e. in the simulation nothing is unknown. The observation_results facts are derived from this stored world situation, the requested observations and knowledge on the effect of actions on possible observations. The knowledge used by the external_world component in order to return simulated results is not further detailed in this paper.。