Meta-Level Control in Multi-Agent Systems
Anita Raja and Victor Lesser
Department of Computer Science,
University of Massachusetts,
Amherst,MA01003-4610,USA
araja,lesser@https://www.doczj.com/doc/462882127.html,
Ph:413-545-3444Fax:413-545-1249
Abstract
Sophisticated agents operating in open environments
must make complex real-time control decisions on
scheduling and coordination of domain actions.These
decisions are made in the context of limited resources
and uncertainty about outcomes of actions.The ques-
tion of how to sequence domain and control actions
without consuming too many resources in the process,is
the meta-level control problem for a resource-bounded
rational agent.Our approach is to design and build a
meta-level control framework with bounded computa-
tional overhead.This framework will support decisions
on when to accept,delay or reject a new task,when it is
appropriate to negotiate with another agent,whether to
renegotiate when a negotiation task fails and how much
effort to put into scheduling when reasoning about a
new task.
Introduction
Sophisticated agents operating in complex environments
must reason about their local problem solving actions,in-
teract with other agents,plan a course of action and carry
it out.All these have to be done in the face of limited re-
sources and uncertainty about action outcomes in real-time.
Furthermore,new tasks can be generated by existing or new
agents at any time,thus an agent’s deliberation must be inter-
leaved with execution.The planning,scheduling and coor-
dination of tasks are non-trivial,requiring either exponential
work,or in practice,a sophisticated scheme that controls the
complexity.In this paper,we describe a framework which
will provide effective allocation of computation resulting in
improved performance of individual agents in a cooperative
multi-agent system.
In this framework,agent actions are broadly classi?ed
into three categories-domain,control,and meta-level con-
trol actions.Domain actions are executable primitive ac-
tions which achieve the various high-level tasks.Control ac-
tions are of two types,scheduling actions which choose the
high level tasks,set constraints on how to achieve them and
sequence the detailed domain level actions which achieve
the selected tasks;and coordination actions which facilitate
ate amount of processor and other resources at appropriate times.To do this an agent would have to know the effect of all combinations of actions ahead of time,which is in-tractable for any reasonably sized problem.The question of how to approximate this ideal of sequencing domain and control actions without consuming too many resources in the process,is the meta-level control problem for a resource bounded rational agent.
Our solution to this problem is to construct a MDP-based meta-level controller which uses reinforcement learn-ing(RL)to learn the utility of control actions and decision strategies in resource-bounded contexts.In order to con-struct such a controller,it is necessary to identify the fea-tures which affect the decisions.The paper is structured as follows:we?rst enumerate the assumptions made in our ap-proach and describe the agent architecture which will pro-vide meta-level control.We then present and evaluate a case-base of hand-generated heuristics for meta-level con-trol.These heuristics will determine the features necessary for the RL meta-level controller to make accurate decisions. Preliminary experimental results illustrating the strength of meta-level control in agent reasoning and the effectiveness of the heuristics are provided.
Assumptions
The following assumptions are made in the framework de-scribed in this paper:The agents are cooperative and will prefer alternatives which increase social utility even if it is at the cost of decreasing local utility.Since the environment is cooperative,we can safely assume that the cumulative of meta-level control decisions at the individual agent level rep-resent the meta-level control reasoning process for a multi-agent system.An agent may concurrently pursue multiple high-level goals and the completion of a goal derives util-ity for the system or agent.The overall goal of the system or agent is to maximize the utility generated over some?-nite time horizon.The high-level goals are generated by ei-ther internal or external events being sensed and/or requests by other agents for assistance.These goals must often be completed by a certain time in order to achieve any utility. It is not necessary for all high-level goals to be completed in order for an agent to derive utility from its actions.The partial satisfaction of a high-level goal is sometimes permis-sible while trading-off the amount of utility derived for de-crease in resource usage.The agent’s scheduling decisions involve choosing which of these high-level goals to pursue and how to go about achieving them.There can be non-local and local dependencies between tasks and methods. Local dependencies are inter-agent while non-local depen-dencies are intra-agent.These dependencies can be hard or soft precedence relationships.Coordination decisions in-volve choosing the tasks which require coordination and also which agent to coordinate with and how much effort must be spent on coordination.Scheduling and coordination actions do not have to be done immediately after there are requests for them and in some cases may not be done at all.There are alternative ways of completing scheduling and coordination activities which trade-off the likelihood of these activities re-sulting in optimal decisions versus the amount of resources used.We also make the simplifying assumption that negoti-ation results are binding and we assume that the agents will not decommit from their contract at later stages.
Agent Architecture
In this section,we provide an overview of our architecture which provides effective meta-level control for bounded ra-tional agents.Figure1describes the control?ow within this proposed architecture.The number sequences describe the steps in a single?ow of control.At the heart of the system is the Domain Problem Solver(DPS).It receives tasks and other external requests from the environment(Step1).When an exogenous event such as arrival of a new task occurs,the DPS sends the corresponding task set,resource constraints as well constraints of other tasks which are being executed, and performance criteria to the meta-level controller(Step 2).The controller computes the corresponding state and de-termines the best action prescribed by the hand-generated heuristic policy for that particular task environment.The best action can be one of the following:to call one of the two domain schedulers on a subset of tasks;to gather more information to support the decision process;to drop the new task or to do nothing.The meta-level controller then sends the prescribed best action back to the DPS(Step2a).
The DPS,based on the exact nature of the prescribed ac-tion,can invoke the complex scheduler,simple scheduler or coordination component(Step3)and receives the appro-priate output(Step3a).If the action is to invoke the complex scheduler,the scheduler component receives the task struc-ture and objective criteria as input and outputs the best satis-?cing schedule as a sequence of primitive actions.The com-plex scheduler can also be called to determine the constraints on which a coordination commitment is established.If the meta-level or the domain scheduler prescribe an action that requires establishing a commitment with a non-local agent, then the coordination component is invoked.The coordina-tion component receives a vector of commitments that have to be established and outputs the status of the commitments after coordination completes.The simple scheduler is in-voked by the DPS and receives the task structure and goal criteria.It uses pre-computed abstract information of the task to select the appropriate schedule which?ts the criteria. The DPS can invoke the execution component either to execute a single action prescribed by the meta-level con-troller or a schedule prescribed by the domain-level sched-uler(Step4).The execution results are sent back to the DPS(Step4a)where they are evaluated and if the execu-tion performance deviates from expected performance,the necessary measures are taken by the DPS.
This work accounts for the cost at all three levels of the decision hierarchy-domain,control and meta-level con-trol activities.The cost of domain activities is modeled di-rectly in the task structures which describe the tasks.They are reasoned about by control activities like negotiation and scheduling.
The cost of control activities are reasoned about by the meta-level control activities.Negotiation costs are reasoned about explicitly in this framework since they can be mod-eled as part of the domain activities needed to complete a
Figure1:Control-?ow in a bounded rational agent high-level goal.The negotiation tasks are split into an in-formation gathering phase and a negotiating phase,with the outcome of the former enabling the latter.The negotiation phase can be achieved by choosing a member from a fam-ily of negotiation protocols(7).The information gathering phase is modeled as a MetaNeg method in the task structure and the negotiation methods are modeled as individual prim-itive actions.Thus,reasoning about the costs of negotiation is done explicitly,just as it is done for regular domain-level activities.The MetaNeg method belongs to a special class of domain actions which request an external agent for a cer-tain set of information and it does not use local processor time.It queries the other agent and returns information on the agent’s expected utility from its tasks,expected comple-tion time of its tasks and?exibility of its schedule.This in-formation is used by the meta-level controller to determine the relevant control actions.
However,reasoning about the cost associated with scheduling activities is implicit.A?xed cost is associated with each of the two schedulers and these costs affect the subsequent choice of domain activities made by the control activities.The earliest start time of domain activities are determined by the latest?nish times of their corresponding control activities.
Meta-level control activities in this framework are mod-eled as inexpensive activities.The cost for meta-level con-trol in this framework are incurred by the computation of state features which facilitate the heuristic decision-making process.The state features and their functionality are de-scribed in greater detail later on in this section.
The domain level scheduler depicted in the architecture will be an extended version of the Design-to-Criteria(DTC) scheduler(6).Design-to-Criteria(DTC)scheduling is the soft real-time process of?nding an execution path through a hierarchical task network such that the resultant sched-ule meets certain design criteria,such as real-time dead-lines,cost limits,and utility preferences.It is the heart of agent control in agent-based systems such as the resource-Bounded Information Gathering agent BIG(2).Casting the language into an action-selecting-sequencing problem,the process is to select a subset of primitive actions from a set of candidate actions,and sequence them,so that the end result is an end-to-end schedule of an agent’s activities that meets situation speci?c design criteria.
We also introduce a simple scheduler based on the use of abstractions of agent task structures.This will support reac-tive control for highly constrained situations.Abstraction is an of?ine process where potential schedules and their associ-ated performance characteristics for achieving the high level tasks are discovered for varying objective criteria.This is achieved by systematically searching over the space of ob-jective criteria.Also multiple schedules could potentially be represented by the same abstraction.The abstraction hides the details of these potential schedules and provides only the high level information necessary to make meta-level choices.When an agent has to schedule a task but doesn’t have the resources or time to call the complex domain-level scheduler,the generic abstraction information of the task structure can be used to provide the approximate schedule. Taxonomy of meta-level control decisions
We now describe a taxonomy of the meta-level decisions in a multi-agent system using a simple example scenario. Consider a multi-agent system consisting of2agents A and B.The discussion will focus only on the various meta-level questions that will have to be addressed by agent A.T0and T1are the top-level tasks performed by agent A.Each top-level task is decomposed into two executable primitive ac-tions.In order to achieve the task,agent A can execute one or both of its primitive actions within the task deadline and the utility accrued for the task will be cumulative(de-noted by the sum function).Methods are primitive actions which can be scheduled and executed and are characterized by their expected utility,cost and duration distributions.For instance,the utility distribution of method M2described as
,indicates that it achieves utility value of10 with probability0.9and utility of12with probability0.1. Utility is a deliberately abstract domain-dependent concept that describes the contribution of a particular action to over-all problem solving.There exists an enables relationship from task NX belonging to agent B to method M2belonging to agent A’s task T1.This implies that successful execution of NX by agent B is a precondition for agent A to execute method M2.
In the remainder of this section,we enumerate the fea-tures computed when the meta-level control component is invoked.The cost of computing and reasoning about these state features re?ect the cost of meta-level control reasoning. We then enumerate the various meta-level control decisions and the case-base of heuristics used to make the decisions. The following are some simple state features which are used in the heuristic decision making process of the meta-level controller.We use qualitative values such as high,
medium and low,to represent the various factors which af-fect the heuristic features.The quantitative values such as quality of80versus quality of60were classi?ed into qual-itative buckets(high versus medium quality)initially based on intuitions on the expected and preferred behavior of the system.They are veri?ed by multiple simulation runs of the system on various test cases.
F0:Current status of system This feature is represented as a3-tuple representing the NewItems Stack,Agenda and ScheduleStack where each entry in the tuple contains the number of items on the corresponding stack.The new items are the tasks which have just arrived at the agent from the environment.The agenda stack is the set of tasks which have arrived at the agent but whose reasoning has been delayed and they have not been scheduled yet.The schedule stack is the set of tasks currently being scheduled.Eg.
means there are two new items which have arrived from the environment and there is one task being scheduled.
F1:Relation of utility gain per unit time of a par-ticular task to that of currently scheduled task set: The of a task is the ratio of
to of that task.This feature compares the utility of a particular task to that of the existing task set and helps determine whether the new task is very valuable,moderately valuable or not valuable in terms of utility to the local agent.
F2:Relation of deadline of a particular task to that of currently scheduled task set:This feature compares the deadline of a particular task to that of the existing task set and helps determine whether the new task’s deadline is very close,moderately close or far in the future.
F3:Relation of priority of items on agenda to that of currently scheduled task set:This feature compares the average priority of the existing task set to the priority of the new task and helps determine whether the new task is very valuable,moderately valuable or not valuable in terms of utility to the local agent.Priority is a function of the utility and deadlines of the https://www.doczj.com/doc/462882127.html,puting the average priority of a task set is a more complicated function than computing the priority of a single tasks since it involves recognizing dominance of individual tasks.
The experiments described in this paper use the above four features.There are other features,simple and complex, which are enumerated below but yet to be implemented..
F4:Percent of slack in local schedule:This feature is used to make a quick evaluation of the?exibility in the local schedule.The amount of slack in the local schedule allows the agent to accept new tasks and schedule them in the free slots as well as deal with unexpected meta-level control ac-tivities.
F5:Percent of slack in other agent’s schedule:This feature is used to make a quick evaluation of the?exibility on the other agent’s schedule.The computation of feature F5is inexpensive since it is done after an information gather-ing phase,represented by a primitive action called MetaNeg which when executed will gather information on non-local agents which are potential coordination partners for the local agent.
F6:Relation of utility gain per unit time of non-local task to non-local agent’s current task set:This feature compares the utility of a particular task to that of the existing task set of a non-local agent and helps determine whether the new task is very valuable,moderately valuable or not valuable with respect to the utility of the other agent.The computation of feature F6is inexpensive since it too is done after the information gathering phase.
F7:Expected utility of current schedule item at cur-rent time:This is the expected utility of the current schedule item at time t as determined by the domain-level scheduler which uses expected value computations.
F8:Actual utility of current schedule item at current time:This is the actual quality of the current schedule item at run time t.This feature is compared to F7in order to determine whether schedule execution is proceeding as ex-pected.If it is not proceeding as expected,a reschedule is initiated to prevent the agent from reaching a failure point from which recovery is not possible.Features F7and F8 will be computed at speci?ed monitoring points.
F9:Expected Rescheduling Cost with respect to a task set:This feature estimates the cost of rescheduling a task set and it depends on the size and quality accumulation factor of the task structure.It also depends on the horizon and effort parameters speci?ed to the domain-level scheduler.
F10:Expected DeCommitment Cost with respect to a particular task:This is a complex feature which estimates the cost of decommiting from a method/task by consider-ing the local and non-local down-stream effects of such a decommit.The domain-level scheduler could be invoked a number of times to compute this feature making it expensive to compute.
F11:Relation of slack fragmentation in local schedule to new task:This is a complex feature which determines the feasibility of?tting a new task given the detailed fragmen-tation of slack in a particular schedule.It involves resolving detailed timing and placement issues.
F12:Relation of slack fragments in non-local agent to non-local task:This is a complex feature which deter-mines the feasibility of?tting a new task given the detailed fragmentation of slack in a particular non-local schedule.It involves resolving detailed timing and placement issues.
The following are some of the speci?c meta-level deci-sions that will be addressed by any individual agent.We describe how the heuristics determine the best action when certain exogenous events occur.The description is limited to reasoning about features F0-F4.Current work allows for reasoning about all12features.
1.Arrival of a new task from the environment:When a new
task arrives at the agent,the meta-level control compo-nent has to decide whether to reason about it later;drop the task completely;or to do scheduling-related reason-ing about an incoming task at arrival time and if so,what type of scheduling-complex or simple.The decision tree describing the various action choices named A1-A9is shown in Figure2.Each of the meta-level decisions have an associated decision tree.As each exogenous event oc-curs for a particular environment,its corresponding de-cision tree is added incrementally to the parent MDP for
[A7]
[A8]
[A9] Figure2:Decision tree when a new task arrives
that environment and the optimal policy will be computed of?ine.Heuristic Rule:If the new task has very low or negligible priority and high opportunity cost with respect to taking resources away from future higher priority tasks, then it should be discarded.If the incoming task has very high priority,in other words,the expected utility is very high and it has a relatively close deadline,then the agent should override its current schedule and schedule the new task immediately.If the deadline is very tight the agent will uses the abstraction-based simple scheduler;else,it will use the more complex scheduler.If the current sched-ule has average utility that is signi?cantly higher than the new task and the average deadline of the current schedule is signi?cantly closer than that of the new task,then rea-soning about the new task should be postponed till later.
If the new task is scheduled immediately,the scheduling action costs time,and there are associated costs of drop-ping established commitments if the previous schedule is signi?cantly revised or completely dropped.These costs are diminished or avoided completely if the task reason-ing is postponed to later or completely avoided if the task is dropped.
2.Decision on whether to negotiate:The meta level con-
troller will decide to negotiate based on the information returned by the MetaNeg action.It queries the other agent and returns information on the agent’s expected utility from its tasks,expected completion time of its tasks and ?exibility of its schedule.We know that method M2in agent A is enabled by task NX belonging to agent B.The bene?t from including method M2in agent A’s schedule is that it increases its total utility.However,it also re-quires agent A and B to negotiate over the completion time of task NX by agent B and this negotiation has an associated cost as well as there is a resource cost to the
agent which agrees to the contract.Heuristic Rule:If the other agent’s current expected utility is much lower than the results of the negotiation,then the local agent will ini-tiate negotiation.Negotiation is also initiated if the other agent’s tasks have high utility but the deadlines are far enough in the future to permit the other agent to execute the enabling task.If the other agent’s tasks have higher priority than the local task,then the negotiation option is dropped.
3.Choice of negotiation protocol:When an agent decides
to negotiate,it should also decide whether to negotiate by means of a single step or a multi-step protocol that may require a number of negotiation cycles to?nd an ac-ceptable solution or even a more expensive search for a near-optimal solution.The single shot protocol is quick but has a higher chance of failure where as a more com-plex protocol takes more time and has a higher chance of success Heuristic Rule:If the agent receives high utility from the results of the negotiation,then the agent should choose the more effective albeit more expensive protocol.
The protocol which has a higher guarantee of success re-quire more resources,more cycles and more end-to-end time in case of multi-step negotiation and higher compu-tation power and time in case of near-optimal solutions.
(The end-to-end time is proportional to the delay in be-ing able to start task executions).If the agent does not have too much resources to expend on the negotiation or if there is a very slight probability that the other agent will accept the contract,then the local agent should choose the single shot protocol.
4.Failure of a negotiation to reach a commitment:If the
negotiation between two agents using a particular nego-tiation protocol fails,the initiating agent should decide whether to retry the negotiation;whether to use the same protocol or an alternate protocol with the same agent or alternate agents and how many such retries should take place?Heuristic Rule:If negotiation is preferred(the agent will receive high utility as a result of the negotia-tion),then a more complex negotiation protocol is chosen since it has a higher probability of succeeding.Since re-sources have already been spent on?guring out a solution to the negotiation,it may be pro?table to put in a little more effort and achieve a solution.If there is a very slight or no probability of?nding an acceptable commitment, then resources which can be pro?tably spent on other so-lution paths are being wasted and the agent might?nd itself in a dead-end situation with no resources left for an alternate solution.So the negotiation option should be dropped.
Two other meta-level decisions which are being devel-oped determine the parameters for invoking the domain scheduler including scheduler horizon,scheduler effort and slack amount in overall schedule and also determine whether to invoke the domain level scheduler for a reschedule since the performance of the agent is not going as expected.
C ontrol Activity is the?xed control action used by the agent
Experimental Results
For the purposes of this paper,we used the environment in-troduced in the previous section with randomly generated which adheres to the above mentioned characteristics.The maximum possible utility from task T0is23.0and mini-mum is17.0;the maximum from task T1is56.0and mini-mum utility is12.0;NX has a deterministic utility of10.00. We make the simplifying assumption that task NX arrives at agent B only as a result of a successful negotiation with agent A.There are four possible meta-decisions upon arrival of a new task:NTCS,New Task Complex Scheduling in-vokes the complex DTC scheduler on the new task only and has a time cost of2;Drop,this causes the agent to drop the new task and not reason about it ever again has a time cost of0;ATCS,All Task Complex Scheduling invokes the complex DTC scheduler on the new task as well as all other tasks which are on the agenda or in partial execution and has a time cost of3;and SS,Simple Scheduling invokes the sim-ple abstraction based analysis on the new task only and has a time cost of1.There are two possible options for Nego-tiation:NM1,Negotiation Mechanism1which is the sim-ple single-shot protocol and NM2,Negotiation Mechanism 2which is the more complex multi-shot protocol.
The design criteria in these experiments is to maximize overall utility over a?nite horizon.Individual tasks have hard deadlines associated with them.It is assumed that if a task has not accrued utility by its deadline,it receives a utility of zero.This simple design criteria setting is one that lends itself to meta-level control as the existence of a hard deadlines(in contrast to a soft preference,e.g.,soft dead-line or no deadlines)make processor and other resources valuable commodities requiring a the non-myopic reasoning provided by the meta-level control component.
The results for the experiments on agents which have meta-reasoning capabilities are shown in Table1and the results on agents which have no meta-level reasoning capa-bilities are shown in Table2.The above described scenario is used in both cases.All domain,control and meta-level actions have a time cost associated with them which are re-?ected in the results.
Consider Table1where each row represents a speci?c task arriving at the speci?ed agent at the associated arrival time with a deadline.The task names are augmented with the arrival count to differentiate between various instances of the same task.For eg.Row4describes task TO arriving at agent A as its fourth task at time55with a deadline of80.
Column5,titled Control Action describes the various deci-sions made by the meta-level controller upon arrival of the new task.Columns6-12describe the utility accumulated by each of the tasks for seven different runs.
In Row1,task T0
2arrives at time11while the previous task is still in execution and a meta-level decision to drop task T01 has the exact same characteristics as the current task and has a tight deadline.The task also has a tight deadline and inter-rupting the already executing tasks might result in missing the deadlines on both Task T02.
In Row3,Agent A decides to do a complete reschedule of all tasks and chooses to negotiate with agent B over task NX using negotiation mechanism NM1.In this case,it is will-ing to reschedule task T0
2 although it was unaware of the arrival of a highly preferred task in the near-future works to agent A’s advantage since it has more time to perform the higher valued task.In?ve out of six runs,the agent’s decision to drop the previous task T03with the negotiation option re-sults in very high utility values.In Run6,task T1
3because of its tight deadline. Consider Table2.Here the agent does not reason about the characteristics of the tasks at the meta-level.This re-sults in the agent choosing the same control action,namely ATCS for all tasks independent of the status of other tasks in execution.This results in the most expensive control action being invoked independent of the current state of the system. This results the choice of domain activities with shorter du-rations and lower utilities as re?ected by the utility values in columns6-12.The total utilities accumulated by?ve of the six runs in Table2is signi?cantly lower than the corre-sponding run in Table1.This supports our hypothesis that meta-level control is generally advantageous.
Conclusions and Future Work
In this paper we present a novel meta-level control agent framework for sophisticated multi-agent environments.The meta-level control has limited and bounded computational overhead and will support reasoning about scheduling and coordination costs as?rst-class objects.
We have shown,using a simple example,that meta-level control is bene?cial.The heuristics described in this pa-per,although very simple,enable the meta-level controller to make accurate decisions in simple scenarios.We plan to introduce more complex features which will make the rea-soning process more robust.Some such features include re-lation of slack fragments in local schedule to new task.This would enable an agent to?t a new task in its current sched-ule if it is possible and avoid a reschedule.Another feature would be to estimate the decommitment cost for a particular task.This will enable us to consider environments in which agents can decommit from tasks which they have previously agreed to complete.
We will extend the detailed domain level scheduler(DTC) to handle scheduling effort,slack and horizon as?rst-class objects.The extended DTC will accept parameters which constrain the effort spent on scheduling which in turn will af-fect the overhead of the scheduler.It will also be extended to deal with slack as a schedulable element which can be quan-ti?ed and valued as any other primitive action.We hope that augmenting the domain level scheduler will make the meta-level controller more versatile by providing more options. Finally,we will use the insight gathered from the heuris-tic approach to construct the state features,reward functions and algorithms to apply a reinforcement learning approach to this problem.We expect this analysis to provide valuable experience about applying RL techniques to complex real-world problems.
References
[1]Craig Boutlier.Sequential Optimality and Coordina-
tion in Multiagent Systems.In Proceedings of the Six-teenth International Joint Conference on Arti?cial Intel-ligence,1999.
[2]Victor Lesser,Bryan Horling,Frank Klassner,Anita
Raja,Thomas Wagner,and Shelley XQ.Zhang.BIG:an agent for resource-bounded information gathering and decision making.In Arti?cial Intelligence Journal,Spe-cial Issue on INternet Applications,1999.
[3]David J.Musliner.Plan Execution in Mission-Critical
Domains.In Working Notes of the AAAI Fall Symposium on Plan Execution-Problems and Issues,1996.
[4]Anita Raja,Victor Lesser,and Thomas Wagner.Toward
Robust Agent Control in Open Environments.In Pro-ceedings of the Fourth International Conference on Au-tonomous Agents,pages84–91,Barcelona,Catalonia, Spain,July,.ACM Press.
[5]H.Simon.From substantive to procedural rationality,
1976.
[6]Thomas Wagner,Alan Garvey,and Victor Lesser.
Criteria-Directed Heuristic Task Scheduling.Interna-tional Journal of Approximate Reasoning,Special Issue on Scheduling,19(1-2):91–118,1998.A version also available as UMASS CS TR-97-59.
[7]XiaoQin Zhang,Rodion Podorozhny,and Victor
Lesser.Cooperative,multistep negotiation over a multi-dimensional utility function.In IASTED Inter-national Conference,Arti?cial Intelligence and Soft Computing(ASC2000),Banff,Canada,pages136–142.
IASTED/ACTA Press,July2000.
企业技术开发２０１２年１１月摘 要：文章通过研究ControlNet 网络传输信号的特点，根据发生故障时，接收方信号保持不变的特征，开发一段故障检 测程序，用于判断ControlNet 网络运行是否正常，并在发生故障时能及时报警提示、自动停机，确保加香加料精度在工艺 标准允许的范围内，把故障影响程度降到最低，避免发生质量事故。关键词：ControlNet ；PLC ；网络故障中图分类号：TQ172文献标识码：A 文章编号：1006-8937（2012）31-0006-02 The development and application of ControlNet network fault detection program ＷＡＮＧＪｉａｎ－ｓｈｅｎｇ，ＨＵＡＮＧＦｕ－ｊｉａｎ，ＷＵＹｏｎｇ （ＣｈｉｎａＴｏｂａｃｃｏＧｕａｎｇｘｉＩｎｄｕｓｔｒｉａｌＣＯ．，Ｌｔｄ．，ＬｉｕｚｈｏｕＣｉｇａｒｅｔｔｅＦａｃｔｏｒｙ，Ｌｉｕｚｈｏｕ，Ｇｕａｎｇｘｉ５４５００６，Ｃｈｉｎａ ）Abstract:ＴｈｒｏｕｇｈｔｈｅｓｔｕｄｙｏｆＣｏｎｔｒｏｌＮｅｔｎｅｔｗｏｒｋｔｒａｎｓｍｉｓｓｉｏｎｓｉｇｎａｌｃｈａｒａｃｔｅｒｉｓｔｉｃ，ｔｈｉｓｐａｐｅｒｄｅｖｅｌｏｐｓｏｎｅｆａｕｌｔｄｅｔｅｃｔｉｏｎｐｒｏｇｒａｍａｃ－ｃｏｒｄｉｎｇｔｏｔｈｅｆｅａｔｕｒｅｔｈａｔｔｈｅｓｉｇｎａｌｒｅｍａｉｎｓｔｈｅｓａｍｅｄｕｒｉｎｇｆａｉｌｕｒｅ，ｕｓｅｄｔｏｊｕｄｇｅｔｈｅＣｏｎｔｒｏｌＮｅｔＮｅｔｗｏｒｋｒｕｎｎｉｎｇｗｈｅｔｈｅｒｎｏｒｍａｌｌｏｒｆａｕｌｔ，ａｆａｕｌｔｏｃｃｕｒｓｃａｎｂｅｔｉｍｅｌｙａｌａｒｍ，ａｕｔｏｍａｔｉｃｓｔｏｐ，ｅｎｓｕｒｅａｃｃｕｒａｃｙｉｎｔｈｅｐｒｏｃｅｓｓｏｆｆｌａｖｏｒｉｎｇｓｔａｎｄａｒｄｓａｌｌｏｗｅｄｒａｎｇｅ，ｔｈｅｆａｕｌｔｉｎ－ｆｌｕｅｎｃｅｄｅｇｒｅｅｄｒｏｐｔｏａｍｉｎｉｍｕｍ，ａｖｏｉｄｔｈｅｏｃｃｕｒｒｅｎｃｅｏｆｑｕａｌｉｔｙａｃｃｉｄｅｎｔｓ．Keywords ：ＣｏｎｔｒｏｌＮｅｔ；ＰＬＣ；ｎｅｔｗｏｒｋｆａｕｌｔ ControlNet 网络故障检测程序开发及应用 王建生，黄富建，巫勇 （广西中烟工业有限责任公司柳州卷烟厂，广西柳州545006） 收稿日期：2012-09-22 作者简介：王建生（１９７１—），男，广西柳州人，大学本科，工程师，主要 从事制丝设备电气维修、设备管理、设备技改相关工作。 企业技术开发TECHNOLOGICAL DEVELOPMENT OF ENTERPRISE 第３１卷第３１期Ｖｏｌ．３１Ｎｏ．３１ ２０１２年１１月 Ｎｏｖ．２０１２ 制丝线各控制段采用A-B 公司ControlLogix5555处理器为主控制器，各控制段PLC 与香料厨房PLC 的信息交换，各控制段PLC 间的运行连锁关系全部是通过ControlNet 进行传输，生产过程中一旦出现ControlNet 网络故障（如某一电柜意外停电造成网络不通），PLC 间的连锁信号将失去有效控制，接收方收到的信号会保持网络故障前一时刻的状态，造成香料厨房PLC 按固定流量继续施加料液（因接收到电子秤流量信号保持不变），因系统本身无网络状态检测、 无故障报警、无自动停机功能，若操作人员发现不及时或者采取措施不果断、有效，很容易导致加香、加料精度超标，甚至出现整批烟质量事故的严重后果。为此，有必要编制一段故障检测程序来表征ControlNet 网络运行状态，时刻侦测网络运行状态，一旦发生故障时，能准确判断、及时停机，保证加香加料精度在工艺标准允许的范围内，把故障影响程度降到最低，避免发生质量事故。 1 ControlNet 网络概述 1.1 ControlNet 网络的通信模式 ControlNet 是一种高速确定性网络， 用于对时间有苛刻要求的应用场合的信息传输，网络总线速率为5Mbps ，同一链路上允许有多个控制器同时存在，网络上节点居于对等地位，可以从任意节点实现网络存取。采用生产 者/消费者通信模式，允许网络上的所有节点同时从同一个数据源存取相同的数据，数据一旦产生，便与客户的数量无关，从而使网络通信效率更高。生产者/消费者模式还采用广播式信息发送方式，各个节点客户可以在同一时间接收到生产者所发送的数据，节点之间接收信息精确同步。总线拓扑结构可以是星型、树型、总线型或是它们之间的任意组合，使用中继器可延长网络的传输距离，中继器数量只受到系统延迟时间的限制，整个网络支持冗余结构。1.2 制丝线网络结构 系统中PLC 采用美国A-B 公司的ControlLogix 系列产品，主要配置有：1756-L55M24、1756-PA75、1756-A13、1756-CNBR 、1756-DNB 、1756-IB32、1756-OB32等。 为了保证系统的可靠性，ControlNet 网络采用了双冗余模式，网络总长度超过1000m ，采用了中继器进行扩展。上位监控机一方面通过1784-PCIC 卡直接与底层PLC 通讯，另一方面通过以太网卡与管理系统进行数据交换。制丝线网络结构图，如图1所示。1.3 故障检测原理 为保证传输时间准确，采用生产者/消费者模式进行信号传输，根据ControlNet 网发生故障时，接收端收到信号保持不变的特性（保持网络中断前接收的信号），我们在发送端定时发送变化有规律且一个周期内不会有重复的特定信号，在接收端对本次收到的信号和上次收到的信号进行比较，若两者不一致，则网络正常；反之，网络故障。网络故障检测原理图，如图2所示。
实验二ControlNet网络上ControlLogix与 PanelView的通信 在完成了1771 I/O到打包机的集成之后，你被告知需要升级操作员面板。操作员面板是一块带有大量按钮和指示灯的面板。指示灯总是烧坏，面板也难于保持清洁。而且，面板与经理办公室离得很近，它看起来又旧又破。你觉得这是采用新型PanelView终端的理想场合。触摸屏式的PanelView易于保持清洁，也可以免去指示灯烧坏的问题。并且，比起现有的操作员面板来说，PanelView能够组态，可以方便地连接到ControlNet网络。 维护经理表达了对于网络性能的一些担心。他说，ControlNet网络上有很多信息传送活动，而他需要在点动一个特定电动机的时候有更好的精度。你说没问题，我们可以将电动机点动信息放在预定带宽（Scheduled Bandwidth）中。 在本实验中，我们将使用PanelBuilder32软件为PanelView创建一个项目，将它能够与ControlNet网络上的ControlLogix系统进行通信。 本实验的主题： ●使用PanelBuilder32软件创建PanelView应用程序 ●组态PanelView在ControlNet网络上使用非预定信息（Unscheduled Messages） ●组态PanelView在ControlNet网络上使用预定信息（Scheduled Messages） 我们将利用以下实验设备进行工作：
组态PanelView的第一步是直接在PanelView上设置通信组态（Communication Configuration）。 1.在PanelView上，选择Communication Setup，按回车。 2.设定节点地址为12，Interscan Delay为100ms（触摸当前节点地址，调出一个按键窗 口，改变地址）。 3.按触摸屏的“Restart Terminal”区域。 4.在终端重新启动之后，通过RSLinx的RSWho窗口，检查你是否正在通过ControlNet 网络与PanelView进行通信。 5.通过选择Start → Programs → PanelBuilder32 → PanelBuilder32启动PanelBuilder32软 件。 6.选中“Create New Application”，并按OK，创建一个新的应用程序。 7.将应用程序的名字设为“Boxing Machine”。 8.按照下图，设定PanelView终端类型为PV1000 Color、Touch，通信协议为ControlNet 1.5。 9.点击“Catalog & Revision Numbers”按钮，选择FRN 3.30-3.xx。 10.按OK，接受组态情况，出现PanelView屏幕与相匹配的空白屏幕。 11.从主菜单选择“Application”，打开Terminal Setup对话框，然后从下拉菜单选择 “Settings”。 12.点击“Comms Setup”按钮，打开通信设置画面。 13.设定PanelView的节点地址为12，Interscan Delay为100ms。 14.在Node Name这一列选择“End of Node List”，然后右击鼠标，选择“Insert Node”， 按如下画面设置参数。
网络系统结构 在一个开放式自动化系统结构中，通常包含有三个网络层：即设备层、控制层以及信息层。 设备层：将低层的设备直接联接到车间控制器上这种联接无需通过I/O模块。即用方便而快速的链路采集各种各样的、来自不同厂家、距离远近不同的现场设备（如传感器、驱动器）的数据，对其进行配置和监视 控制网：各个PLC之间及其与各智能化控制设备之间，进行控制数据的交换、控制的协调、网上编程和程序维护、远程设备配置和查、排错误，也可以联接各种人机界面产品进行监控。 信息网：提供上层计算机系统，以便通过以太网访问车间级的数据，主要为了全厂范围控制系统的数据汇集和监视。数据量大而实用性要求不高，它的开放性协议使各种主计算机和不同厂家的PLC可以互连。在必要时也可以进行一些控制和协调。这一层采用符合公共标准TCP/IP协议的以太网。 DEVICENET与 CONTROLNET区别 DeviceNet是由Allen-Bradley公司(Rockwell自动化)发的一种基于CAN的开放的现场总线标准。DeviceNet作为一种高性能的协议，DeviceNet协议设计简单，实现成本较为低廉，但对于采用最底层的现场总线的系统（例如，由传感器、制动器以及相应的控制器构成的网络）来说，却是性能极高的。
DeviceNet设备涉及的范围从简单的光电开关一直到复杂的半导体制造业中的用到的 真空泵。就像其他的协议一样，DeviceNet协议最基本的功能是在设备及其 相应的控制器之间进行数据交换。因此，这种通信是基于 面向连接的（点对点或多点传送）通讯模型建 立的。这样，DeviceNet既可以工作在主从模式，也可以工作在多主模式。一 个DeviceNet网络工作在125k、250k和500k的波特率下最多可以支持64个节点。设备可以使用自身的电源，也可以通过DeviceNet总线供电。和CANopen协议相比较后可以看出，两种协议可以实现相类似的功能，但DeviceNet更强调不同的优先权。例如，在DeviceNet 网络中，网络管理功能存在于每一个独立的节点之中，这样，个节点都可以监控其他节点。而在CANopen网络中，则采用了中心授权机制，通过一个NMT-Master对网络进行管理。CANopen的通信机制更加简单，从而可以降低设备的复杂程度。使用DeviceNet可以提供更高的安全性，。 ControlNet是于生产者/消费者模式(Producer／Consumer Model)的网络。ControlNet 允许在同一链路上有多个控制器共存，支持输入数据或端到端的多路发送，这就大大的减少了网络上的交通量，提高了网络效率和网络性能。ControlNet是高度确定性、可重复性的网络。ControlNet能预见数据何时能够可靠传输到目标的能力，同时数据的传输时间不受网络节点添加/删除情况或网络繁忙状况而保持恒定的能力。在实际应用中，通过网络组态时选择性设定有计划I/O分组或互锁时间，这些要求能得到更进一步的保证。生产者/消费者模式允许网络中所有的节点同时获取来自同一数据源的数 据。最终，该模式提高了效率，因 为数据只发送一次，而与数据使用 者(Consumer)的数量无关，并且具有精确的同步性。因为数据将同时到达每一个节点。生产者－消费者模式的优点在于：多个节点可以同时消费(Consume，即读取)来自同一个生产省(Producer，即数据源)所提供的数据。节点间易于同步，可以获得更为精确的系统性能，设备可以实现自主通信，无需系统主站。ControlNet提供了简单、高度确定而且灵活的传输数据方式。ControlNet在执行操作、数据实时监控时不会影响到I／O控制的性能。因此，ControlNet非常适用于一些控制关系有复杂关联、要求控制控制信息同步、协调实时控制、数据传输速度要求较高的应用场合。 ControlNet的明显优点是：同一链路上满足I/O数据、实时互锁、端到端报文传输和 编程/组态等信息应用的多样要求；是确定性、可重复性的控制网络，适合离散控制和过程控制；同一链路上允许有多个控制器同时共存；输入数据和端到端信息的多路发送支持；可选的介质冗余和本征安全；安装和维护的简单性；网络上节点居于对等地位，可以从任意节点实现网络存取；灵活的拓扑结构（总线型、树型、星型等）和介质选择（同轴电缆、光纤和其它）。 区别 1.Controlnet 和Devicenet 组网方式不同，需要rsnetworx for contronet & rsnetworx for devicenet，C网比较好组，D网有些难度。
4.2 ControlNet 网络组态 1．作为当今最先进的网络，ControlNet具备诸多特点。实时I/O、控制器互锁、对等报文传输（Peer-to-Peer Messsaging）以及编程操作都可以在同一条ControlNet链路上实现。ControlNet本质的确定性可以确保数据何时发送，其可重复的性能确保网络传输时间不会随网络设备的添加或删除而改变。 2．Controlnet的主要技术特点： 网络功能：统一链路支持控制信息、I/O数据、编程数据 网络拓补：线形、星形、树形、以及以上的任何拓扑结构的混合 网络速度：5Mbits/s(最大) 单段网长度：（同轴电缆）1000m带个2节点，250m带48个节点。（光纤）3000m 中继器数目：（串行）最大支持5个中继器，连接6个网段。（并行）最大支持48个中继器，连接48个网段。 中继器类型：AC&DC高压型和DC低压型 设备供电：设备采用外部供电 网络模型：生产者/客户模式 连接器：标准同轴电缆BNC 物理层介质：RG6同轴电缆、光纤 网络节点数：99个最大可变址节点，不带中继器的网段最多48个节点 带中继器最大拓扑结构：（同轴电缆）5000m，（光纤）30Km 应用层界面：面向对象层设计，包括设备对象模型，类/实例/属性，设备规范(Profile) 网络刷新时间：可组态2-100ms 数据分组大小：可变长0～510个字节 网络和系统属性：可带电插拔，确定性和可重复性，可选本质安全，网络重复节点检测，报文分段传送（块传送） 4.2.1 ControlNet用于I/O实时控制 本实验中，Logix5555控制器通过ControlNet网络控制由1794-ACNR15适配器连接的远程I/O模块。 实验步骤： 1. 打开RSLinx软件，添加Ethernet驱动，通过ControlLogix背板网关功能，访问ControlNet网络，如图4-18所示；也可以直接添加1784-PCICS ControlNet网卡的驱动。 图4-18 访问ControlNet网络
DEVICENET与CONTROLNET的区别 DeviceNet是由Allen-Bradley公司(Rockwell自动化)开发的一种基于CAN的开放的现场总线标准。DeviceNet作为一种高性能的协议，目前在美国和亚洲的市场上处于领导地位，其系统解决方案在欧洲也取得了显著的业绩增长。ODVA( DeviceNet用户组织)负责发布DeviceNet规范以及对DeviceNet标准进行维护，另外，ODVA也负责DeviceNet在世界范围内的推广。现在，最新版本的DeviceNet 2.0标准提供了更多的功能并修正了旧版本中的一些错误。 DeviceNet是一个开放性的协议，每个 ODVA成员都有资格发行基于 DeviceNet标准开发的后续产品。除了加入ODVA组织须交纳的会员费以及实际购买规范的费用外，使用DeviceNet是免版税的。现在已经有超过300家的公司注册成为ODVA的成员。全世界共有超过500家的公司提供DeviceNet产品。 DeviceNet协议设计简单，实现成本较为低廉，但对于采用最底层的现场总线的系统（例如，由传感器、制动器以及相应的控制器构成的网络）来说，却是性能极高的。DeviceNet 设备涉及的范围从简单的光电开关一直到复杂的半导体制造业中的用到的真空泵。就像其他的协议一样，DeviceNet 协议最基本的功能是在设备及其相应的控制器之间进行数据交换。因此，这种通信是基于面向连接的（点对点或多点传送）通讯模型建立的。这样，DeviceNet 既可以工作在主从模式，也可以工作在多主模式。 DeviceNet的报文主要分为高优先级的进程报文（I/O报文）和低优先级的管理报文(直接报文)。两种类型的报文都可以通过分段模式来传输不限长度的数据。 所谓的"预定义主/从连接集"适用于简单的DeviceNet从站设备。作为DeviceNet协议的子集，它支持从主站到从站传送的直接报文，轮询I/O报文，位选通I/O报文以及由从站向主站传送的状态变化/循环I/O报文。 "非连接报文管理端口（UCMM）"以及动态生成"直接及I/O连接"则适用于从站比较复杂的情况，这些从站可支持多个主站并能与其他设备维持点到点互联。设备启动报文和设备关闭报文是特别为安全相关系统设计的"离线连接设置"则简化了对非常规组件的配置工作。 DeviceNet的通信和应用都是基于对象模型的。预先定义好的对象简化了不同厂商的不同设备间的数据交换。通过建立不同设备的子集，用户可以从进一步的规范化中获益。
PLC知识 一、概述 ControlNet是近年来推出的面向控制层的实时性现场总线络，在同一物理层介质链路上提供时间关键性I／O数据和报文数据，包括程序的上载／下载，组态数据和端到端的报文传递等通讯支持，是具有高度确定性、可重复的高速控制和数据采集络，I／O性能和端到端通讯性能都较传统络有较大的提高。 二、ControlNet系统原理 ControlNet是基于生产者/消费者模式(Producer／Consumer Model)的络。ControlNet允许在同一链路上有多个控制器共存，支持输入数据或端到端的多路发送，这就大大的减少了络上的交通量，提高了络效率和络性能。 ControlNet是高度确定性、可重复性的络。ControlNet能预见数据何时能够可靠传输到目标的能力，同时数据的传输时间不受络节点添加/删除情况或络繁忙状况而保持恒定的能力。在实际应用中，通过络组态时选择性设定有计划I/O分组或互锁时间，这些要求能得到更进一步的保证。 生产者/消费者模式允许络中所有的节点同时获取来自同一数据源的数据。最终，该模式提高了效率，因为数据只发送一次，而与数据使用者(Consumer)的数量无关，并且具有精确的同步性。因为数据将同时到达每一个节点。生产者－消费者模式的优点在于：多个节点可以同时消费(Consume，即读取)来自同一个生产省(Producer，即数据源)所提供的数据。节点间易于同步，可以获得更为精确的系统性能，设备可以实现自主通信，无需系统主站。ControlNet提供了简单、高度确定而且灵活的传输数据方式。ControlNet在执行操作、数据实时监控时不会影响到I／O控制的性能。因此，ControlNet非常适用于一些控制关
C ontrolNet技术及其在冷站控制系统中的应用 朱春花 周齐国 (重庆大学 400045) 摘 要 探讨了基于生产者/消费者通信模式的C ontrolNet总线技术,包括其技术特点、通信模式、信息交换方式和网络集成,并对该总线在冷站控制系统中的应用作了具体的分析,包括网络系统构成和软件组态。 关键词 C ontrolNet控制网 生产者/消费者模式 信息交换 时间片算法 网络刷新时间 现场总线技术自20世纪90年代以来有了长足的进步。目前,由于种类繁多的控制设备和过程监控装置在工业领域的应用,对现场总线控制系统信息交换的实时性、确定性以及系统的运行效率提出了越来越高的要求〔1〕 。在这一领域,北美自动化供应商罗克韦尔自动化公司,推出了基于开放网络技术的新型通讯模式———生产者/消费者模式的C ontrol2 Net现场总线。 1 基于生产者/消费者的通讯模式 目前,工业自动化控制网络采用的网络模型主要有两种:源/目的地模型(S ource/Destination)和生 产者/消费者(Producer/C onsumer)模型。绝大多数控制网络通讯都是采用源/目的地的通讯模式,如FF、Lonw orks、Profibus等。源/目的地网络模型(S ource/Destination)采用应/答式通讯,如果网络要向多个设备传送数据,则需要对这些设备分别进行“呼”“应”通信,即使是同一个数据,也需要制造多个数据包,消耗过多的带宽,并且数据到达每个设备的时间还是不同的。这样,不仅增大了网络的通信量,网络响应速度受到限制,容易发生信息瓶颈问题,而且当系统对时间有苛求的实时控制信息要求传送时,还需要采用其它不同的网络。 在现行设计中,一般将基础钢筋作为自然接地体,用40×4的镀锌扁钢将其连通,并施行总等电位联结。这样进行处理,接地电阻很小,一般容易达到设计要求。在设计中应当注意,应在室外合适位置预留接地连接板,做法可以参考国家标准图集《接地装置安装》(03D501Ο4)。这样,当接地电阻值达不到要求时,施工单位可以方便地连接人工接地体和测试接地电阻值,这一点应当在设计图纸中有所体现。 另外,在设计图纸中,不能泛泛而谈“利用建筑物基础钢筋做自然接地体”。前面已经提到,轻钢结构建筑物在基础施工时需预埋地脚螺栓,加垫片后才能和钢柱相连。须知:预埋的接地螺栓本身和基础钢筋是没有电气连接的!所以,土建施工时可用不小于<10钢筋或圆钢将基础钢筋和接地螺栓可靠焊接,具体做法参见国家标准图集《利用建筑物金属体做防雷及接地装置安装》(03D501Ο3)的17页。这样,从接闪器到引下线,再到接地装置,雷电流才具备完整的泄放通道。这样做还不够,还应该用短钢筋和基础钢筋可靠焊接,并引出基础外,供联结接地环网,方有利于降低自然接地体的接地电阻值和实施有效的等电位联结。这一点对于设置独立基础的轻钢结构建筑尤其重要,所以有必要在设计图纸中交待清楚。 如果忽视了轻钢结构建筑物接地装置的特殊性,即基础钢筋和接地螺栓本身并没有电气连接这一事实,造成的后果则是整个建筑物没有可靠的接地网。采取的补救措施是用40×4的镀锌扁钢做等电位环网,镀锌扁钢过钢柱时应和柱底脚板下侧可靠焊接。这样,镀锌扁钢充当了接地极和接地线的双重角色。 除了等电位接地环网沿建筑物外围敷设一周外,在建筑物内还应该按跨度设置均压网格,不但可降低跨步电压,保护人身安全,而且有利于工业厂房生产设备就地实施等电位联结,缩短等电位联结线的长度。
实验四创建ControlLogix项目和梯形图控制 变频器的频率 在本实验中，我们将利用RSLogix5000编程软件在ControlLogix处理器中创建一个项目。我们将添加PowerFlex70变频器和简单的梯形图阶梯，来演示实际的控制过程。 本实验的主题： ●创建一个ControlLogix项目 ●添加PowerFlex70变频器 ●观察RsLogix5000自动生成的对象数据模型 ●添加控制调节频率的阶梯 ●通过RsNetWorx组态ControlNet网络 ●PLC控制调节变频器频率 上午的第一件事情，电气工程主管找到你，说他需要你在工厂的整体控制程序中添加一些PLC梯形图逻辑。他只懂梯形图，因此他不希望你用功能块图来编程。 他说，工厂新添置了一台变频器并带ControlNet接口，他希望通过网络控制变频器，并不希望有任何的电气接线。你知道这非常简单，并答应主管在午饭前完成。这也使你下午有充分的时间尽情休息。 1.双击RSLogix5000图标。出现如下画面： 2.点击File(文件)New(新建)。你将会看到 New Controller (新建控制器)画面。起 始槽号为0。看一下框架，你会发现共有10槽，既然起始槽号为0，那么5555控制器（带有钥匙的模块）位于第四槽，即3号槽。因此，填写画面，与下图一致，然后按OK。
确认你在此输入了 数字3。5555控制 器位于3号槽。 现在我们已经创建了一个ControlLogix项目。此时我们还没有与项目相关的任何I/O 模块，项目中也没有可执行的代码（如梯形图）。你正在离线工作。所作的任何改变都只限于软件中，并存储在计算机的硬驱中。在进入到在线操作以前，这些变化并不能反映到5555控制器中。 下一件事情是要辨认我们想用在这个项目中的、插在本地背板上的I/O模块。由于不能在线添加输入/输出模块，因此，现在（处于离线状态）正好可以添加模块（如下所述，暂时我们只添加两块模块）。根据主管的要求，你需要添加模拟量输入模块和模拟量输出模块。在机架中，有如下设备： 0号槽： DO — 1756-OB16D/A (诊断型、16点、一半输出已经接线) 1号槽： CNET 2号槽： DI — 1756-IB16D/A (诊断型、16点、输入点0-15都已接线) 3号槽： 5555处理器 4号槽： DO — 1756-OB16D/A (诊断型、16点、一半输出已经接线) 5号槽： 5555处理器 6号槽： AI — 1756-IF6I/A (隔离型电压/电流输入、6通道、0-5、两个通道已接线) 7号槽： AO — 1756-OF6VI/A (隔离型电压输出、6通道、0-5、两个通道已接线) 8号槽： 1756- MO8SE 9号槽： 1756- ENBT 以太网通讯模块
Lab8. ControlNet网络组态 情景模拟：工厂某工段新添置了一台设备，其控制和反馈信号接入该工段的从控制站上的IO模块；电气工程主管找到你，说他需要你在该工段所属工艺区的主控制器中添加一些程序，通过ControlNet网络控制该设备。 在本实验中，我们假设该设备为一台风机，我们将利用RSLogix5000编程软件在ControlLogix处理器中创建一个项目，配置从站IO模块和ControlNet网络通讯模块，组态ControlNet网络，并编辑简单的梯形图阶梯，来演示实际的启停控制过程。 实验主题： z创建一个ControlLogix项目 z组态ControlNet网络通讯模块 z配置从站IO模块 z观察RSLogix5000自动生成的对象数据模型 z添加控制启停的梯形图逻辑 z通过RSNetWorx For ControlNet软件组态ControlNet网络 z PLC控制设备启停 请按步骤： 一、创建工程 1.打开RSLogix5000编程软件，点击File（文件）? New（新建），打开New Controller （新 建控制器）画面。如下图所示填写控制器的名称、描述（可选），选择控制器类型、版本和所在槽位（起始槽号从0开始），指定框架类型、工程保存目录等相关信息，然后按OK。
现在我们已经创建了一个ControlLogix项目。此时我们还没有与项目相关的任何I/O模块，项目中也没有可执行的代码（如梯形图），你正在离线工作。所作的任何改变都只限于软件中，并存储在计算机的硬盘驱动中。在进入到在线操作以前，这些变化并不能反映到控制器中。 接下来是要辨认我们想用在这个项目中的、插在本地背板上和远程框架上的I/O模块。在本地4槽的框架中，有如下设备： 0号槽： 1756- L1 Logix5550处理器模块 1号槽： 1756- ENET 以太网通讯模块，IP地址为192.168.1.108 2号槽： 1756- CNB ControlNet网络通讯模块，站点地址为4 在远程的7槽框架中，有如下设备： 0号槽： 1756- CNB ControlNet网络通讯模块，站点地址为5 1号槽： 1756- IB32/A 32点DI模块 2号槽： 1756-OB16D/A 16点诊断型DO模块 注意：所有模块都可带电插拔，如有需要可以另行配置其他模块。 2.添加本机架CNB通讯模块。鼠标右键点击I/O Configuration（I/O组态，位于左边窗口 的底部），并选择New Module(新模块)。
ControlNet总线 许可09机电2班 1.ControlNet总线协议概述 ControlNet是IEC61158现场总线标准的子集。ControlNet是由美国罗克韦尔公司于1997年推出的面向控制层的实时性现场总线。1997年7月，Rockwell等22家企业联合发起成立了ControlNet International (CI)组织。CI主要负责全世界范围内推广发展ControlNet技术，提供测试软件及独立的合格性测试。出版发行ControlNet技术说明书和产品目录以及组织设计和使用ControlNet的培训等工作。 2 ControlNet概貌 2.1 应用领域 随着国际自动化系统网络技术的不断进步，ControlNet International 到目前为止，成员公司已扩展到50多个，其中不乏世界知名的大公司，如ABB Roboties、Honeywell Inc、Toshiba International。ControlNet可广泛应用于交通运输、汽车制造、冶金、矿山、电力、食品、造纸、水泥、石油化工、娱乐及其它各个领域的工厂自动化和过程自动化。 2.2 技术特点 （1）CtrolNet是高速的控制和I/O网络，具有增强的I/O性能和点对点通讯能力，支持多主方式，可以从任何一个节点访问整个网络。 （2）对于离散和连续过程控制应用场合，均具有确定性和可重复性。 （3）先进的生产者/消费者网络模型，最大限度的优化了带宽的利用率，并可构成多主、主/从、对等的通讯结构；媒体访问算法确保了控制信息传送时间的准确性。 （4）具有灵活的安装选择，可使用各种标准的低价同轴电缆，也可使用具有强抗干扰性和本征安全性的光纤，并支持媒体冗余方式。 2.3 通信模式 ControlNet在单根电缆上支持两种信息传输：一种是对时间有苛刻要求的控制信息和I/O数据，ControlNet授予他们最高优先权，保证其不受其他信息的干扰，二是无时间苛求的信息和程序上/下载，他们被授予较低的优先权，在保证第一种信息传输的条件下进行传递。 用户具有对这种信息的控制能力，可选择控制和I/O数据的刷新速率，并确知数据的传输时刻。 ControlNet技术采用了一种通信模式，以生产者/消费者模式取代了传统的源/目的模式。他不仅支持传统的点对点通信，而且允许同时向多个设备传递信息。生产者/消费者模式使用时间片算法保证各节点实现同步，从而提高了带宽利用率。 用一种形象的方式来描述两者的区别，一个班有30同学，现在需要把当前的确切时间告知某些同学，在源/目的模式中时间被告知每个人,其中有的同学可选择听，另一些则选择不听，在信息传输过程中，时间已发生变化，因此时间在告知第一个同学以后就变得不准确了。而在生产者/客户模式中，时间被同时告知室内所有的同学，有的同学可选择听，其他的可选择不听。这样就不会出现信息是真的现象，室内人数的增减也不会影响通信时间和效率。因而保证了高效率和高确定性。 ControlNet使用的同轴电缆全部距离能够长达6Km，可寻址节点最多为99个，两节点间最长距离最长可达1000m，48个节点距离可达250m;采用光纤和中继器后,通信距离可达几十公里，支持大多数介质结构，网络结构可采用总线、树型、星型等结构或组合结构。使用时，用户可根据需要扩展物理长度，增加节点数量，提高安全性能。
CONTROLNET 双光纤冗余中继器 YRN2 概述： YRN2系列产品是易控达科技专门为CONTROLNET 现场总线远距离数据通讯而设计的工业级光纤通讯中继产品。该设备成对使用，支持光纤冗余以提升总线可靠性，为需要高安全性能的总线段提供光纤冗余保护，当某路光纤出现故障时，自动切换为另一路光纤工作，当故障光纤恢复后，设备将自动切换回来。实现了总线段间的信号光电隔离、完全隔离了总线段之间的电气干扰，同时具有总线信号再生、延长传输距离、增加节点数的功能。 YRN2系列产品支持一路电缆数据接口，两路光纤数据接口，适用于点对点光纤冗余通讯结构；具有易控达独创的总线故障智能切断功能，当某段总线段出现故障时，不会影响另外总线段。 该系列产品采用易控达独创的专有技术，数据全透明传输，自动切换数据方向，无须任何设置，支持CONTROLNET 全部总线速率，速率自适应，完全解决了高速率远距离传输问题，多模光纤可传输2KM，单模光纤可传输20KM。该产品可靠的完成了通过光纤传输总线数据，继承并保留了CONTROLNET 总线的全部优点,实现了高速率远距离传输、电气及地线隔离、降低干扰等性能，该设备解决了电磁干扰、地环干扰和雷电破坏的难题，同时还具有如下优点：工业设计、低功耗、隔离保护、总线故障智能切断、继电器告警输出、IP30防护等级、波浪纹铝制加强机壳、35mmDIN 导轨安装、宽电源（DC10-36V）输入、双电源冗余等优点。特点： ? 支持CONTROLNET 总线速率5Mbit/s，数据全透明传输，极低的纳秒级信号延时；? 多模光纤/单模光纤可选，多模可传输2KM，单模可传输20KM，ST/SC/FC 接口可选；? 该设备成对使用，支持点对点光纤冗余网络结构；? 电接口采用独立电源模块供电，完全隔离了总线与设备间的地线回路；同时采用光电隔离技术，隔离内部通讯与总线数据信号，有效保护了通信设备免受电源地线回路和浪涌的干扰破坏；? 电接口提供每线1500W 的防雷防浪涌保护、15KV 静电保护及防止共地干扰、具有自恢复过流保护功能；? 具有独创的总线故障智能切断功能，光纤链路状态智能监测，电源监测，继电器自动报警功能；? 丰富的LED 状态指示灯，全方位显示总线和光纤运行状态；? 独立双电源冗余，DC10-36V 宽电源供电，DC1500V 电源隔离,具有1A 反接保护功能；? 工业级设计，无风扇、低功耗、超强防磁场、防辐射及抗干扰功能；?波纹式高强度金属外壳，IP30防护等级,35mm 工业卡轨安装方式； 网络拓扑结构： 本设备须成对使用，适用于点对点光纤冗余网络。可以实现通过光纤连接两个CONTROLNET 总线网段；当光口1链路出现故障时，设备自动切换为光口2链路工作；当光口1链路恢复正常后，自动恢复为光口1链路工作。该系列产品即插即用，不需配置，最大程度的使用户安装和调试过程简单化。 该设备为光纤中继器，光纤连接方式为交叉连接，即A 设备的光口TX 端连接到B 设备的RX 端，A 设备的RX 端连接到B 设备的TX 端。典型应用方案如下：