本申请要求于2007年4月13日提交的标题为“Online FaultDetection and Avoidance Framework for Distributed Systems(用于分布式系统的在线故障检测和避免框架)”的待审美国临时专利申请(序号60/911,530)的优先权,其全部内容通过引用结合于此。
背景技术
可靠系统的特征是其容错等级、安全性和可靠性等等。尽管这些术语经常在文献中可互换地被使用,但是这些术语之间存在着深远的区别。例如,可靠性处理部件故障以及部件故障对系统可用性的影响。发生故障的部件可能可以想象地导致不安全的系统状况,这不一定是由于该故障本身,而是因为对围绕由该故障导致的状况缺乏足够的约束。
另一方面,安全性是与控制和/或数据有关的问题。之所以发生不安全的状况是由于在系统内缺乏足够的控制。不足的或者无效的数据也能够引起不安全的状况。
如何处理不安全的状况或者故障状况的问题取决于应用以及故障的类型。在一些控制应用中,通过在发生关键性故障时关闭系统或者系统的一部分来实现故障安全的状态。确定该问题的根原因可能不是要实现的首要目的,因为只要系统在发生故障状况以后安全地关闭,则这对故障安全的运行而言可能就足够了。在其它的应用中,关闭系统不一定是可行的解决方案。相反,需要一组动作,所述动作确保到安全运行状况的过渡。
容错通常与为系统部件定义冗余等级和/或定义这些部件之间的连通性相关联。尽管已经证明这对安全性关键的系统而言是必要的,但是这是一种主要适于克服可靠性问题、以及在一些情况下适于克服与数据有关的问题的解决方案。冗余可以应用在硬件层次和软件层次二者上。示例性的软件故障安全技术包括补充数据的读/写、校验和比较、冗余编码和正交编码。对由于缺乏对系统运转的足够控制而产生的问题的冗余的解决方案的效果是存在很大争议的。这是因为在初级系统和次级系统二者中必定同样地缺乏适当的控制规则。此外,冗余的解决方案只能针对那些预先已知的问题根源来制定。
在设计与系统测试阶段的故障分析
开发容错或者安全系统的常用方式是使设计团队在控制系统设计阶段花费大量的时间和精力,然后在系统建立之后进行大量的测试和验证。存在可以有助于上述的分析的多种半正式的技术,这些技术主要从可靠性工程中借鉴而来。示例包括:FTA(Fault Tree Analysis,故障树分析)和FEMA(Fault modes and effect analysis,故障模式及影响分析)。FTA是一种用于识别潜在的不希望的状况的特定原因的演绎技术。该树中的顶事件(top event)是先前已知的潜在状况。原则上,这类似于反向诊断(backward diagnosis),反向诊断利用反向链逻辑来确定导致给定的故障的事件和状况的序列。这样的技术例如在如下文献中被说明:“String Stability of InterconnectedSystems”(D.Swaroop,博士论文,加利福尼亚大学伯克利分校,1994年)、“Computer-aided Synthesis of Fault Trees”(S.Lapp和G.Powers,“IEEE Transaction of Reliability Engineering”,第26卷,No.1,第2-13页,1977年四月)、“Sensor-Based Diagnosisof Dynamical Systems”(A.Misra,博士论文,范德比尔特大学,1994年)、“An Automated Methodology for Generating A Fault Tree”(R.De Vries,“IEEE Transaction of Reliability”,第39卷,第76-86页,1990年)、以及“A Discrete Event Systems Approach toFailure Diagnosis”(M.Sampath,博士论文,密歇根大学,1995年)。
FEMA是一种归纳分析技术,其用于识别并评估潜在的不希望的状况以及确定控制动作以便消除或者减小这些状况的风险。另一方式是前向诊断(forward diagnosis)方式,其中在模型中进行状态假设并且在作出结论以前一直根据当前的事件和传感器读数来更新状态假设。该方式由如下文献说明:“Probabilistic fault diagnosis incommunication systems through incremental hypothesis updating”(M.Steinder和A.S.Sethi,Computer Networks 45,2004年)、“Sensor-Based Diagnosis of Dynamical Systems”(A.Misra,博士论文,范德比尔特大学,1994年)、以及“A Failure/Fault DiagnoserModel for Autonomous Agents under Presence of Disturbances”(P.Zhao,A.Amini,M.A.Jafari,“IEEE Internat ional Conference onSystems,Man,and Cybernetics”,2006年)。
在过去的十年中已经存在数量可观的关于建立更正式的安全性、故障和危险分析的方式的研发工作,但是这些分析方式是从控制角度的。一个示例是由MIT团队执行的工作,该工作例如被记载在“ASystem-Theoretic Approach to Safety in Software-IntensiveSystems”(N.Leveson,“IEEE Trans.on Dependable and SecureComputing”(2005年))。该工作的主旨是通过在实施前形式化软件需求、模拟并分析该设计来在设计阶段使软件故障和危险最小化。在该团队开发的STAMP(System-Theoretic Accident Modeling andProcessing,系统理论的事故建模与处理)方法中,不根据一系列的故障事件来理解事故的原因,而是认为事故的原因是缺乏施加给系统设计和运行的约束条件所导致的结果。STAMP使用基础过程(underlying processes)的具体模型。所假设的是:任何控制器、无论是人类控制器还是自动控制器必须包含所控制系统的模型。无论该模型是嵌入在自动控制器的控制逻辑中还是人类控制器的心理模型中,该模型必须包含相同类型的信息:系统变量间的所需关系(控制规则)、当前状态(系统变量的当前值)、以及该过程能够改变状态的方式。事故、尤其是系统事故则被认为是由所述控制器(人类控制器和自动控制器二者)使用的过程的模型与实际过程状态之间的不一致。以上的方法现在使用在一些应用领域中,比如航天领域以及航空领域中。
类似的范例已经被不同的研究团体促进,所述研究团体致力于对事件驱动的系统(比如Petri网、NCES、时序逻辑以及其它的状态/过渡系统)的建模。总的来说,使用该系统的受控闭环行为的单个模型,该单个模型包括基础过程和控制动作二者。通过对该模型的分析和评估可以先验地识别该系统潜在可到达的不希望的状态。例如,使用Petri网理论可以数学上建立这样的状况例如无界性(un-boundedness)、不同活性等级、一些死锁状况等。对这些方法的综述在L.E.Pinzon,H.M.Hanisch,M.A.Jafari和T.O.Boucher的“AComparative Study of Synthesis Methods for Discrete EventControllers”(“Journal of Formal Methods in System Design”,第15卷,No.2,1999年)中呈现。
尽管更简单的是设计和控制每个独立代理体(agent)(或者系统部件或者控制器),但是由于信息和控制的分布式性质,开发一种安全和可靠的分布式多代理体系统比其集中的类似系统更具挑战性。对于分布式故障分析,必须处理多个主要问题:a)哪个代理体应该发起故障检测/诊断?b)应该交换哪些信息?该交换如何进行?应该涉及到哪些代理体?c)未来应该如何避免相同的故障?d)为了在未来进行避免、预防或者恢复而应该保存哪些信息?
在文献中已经通过两种方式来将故障分析扩展成分布式系统。首先,集中控制被直接扩展成分布式系统,从而每个代理体具有其自己的局部分析引擎,同时也存在全局协调器,所述全局协调器在需要时与局部协调器通信。给每个代理体分配有一组可观测到的事件,并且每个代理体局部地处理其自己的观测并且产生其诊断信息。然后,所述信息中的一些根据需要被传递给全局协调器。所传递的信息的类型由代理体所使用的通信规则来确定。协调器的任务是处理从每个代理体接收到的消息,并且根据一些所规定的决策规则对故障的出现作出适当的推断。第一方式的示例在R.Debouk的博士论文“FailureDiagnosis of Decentralized Discrete-Event Systems”(密歇根大学,2000年)中被提出。
在第二方式中,每个代理体从其邻居接收并局部地处理。该方式更适于分布式系统,但是该方式几乎不能胜过集中的方式,因为没有代理体比第一方式中的协调器具有更多的信息。该方式的示例包括:“Decentralized diagnoser approach:Application totelecommunication network”(Y.Pencole,Proc.of DX2000,EleventhInternational Workshop on Principles of Diagnosis,第185-193页,2000年六月)、以及“Diagnosis and Communication in DistributedSystems”(R.Sengupta,Proc.WODES 1998,International Workshopon Discrete Event Systems,第144-151页,IEE出版,伦敦,英国,1998年八月)。
在线运行时间故障分析
上述方式,虽然是预先主动的,但是所假设的是:故障或者不希望的状况被预先确定,要么在设计阶段要么在测试阶段被确定。问题是:在实际中,经济性与安全性或者容错之间的平衡经常变得重要。因此,设计和预编程几乎必然地在结束时未包括所有可能的故障状况。可论证地,真实情况是:对于合理地复杂的系统而言,识别所有的故障状况的问题是“不可判定的”。此外,在许多真实的应用中并且尤其是复杂的分布式系统中,故障的出现通常取决于时间,其中故障出现的可能性随着系统的运转进度而改变。此外,故障之所以出现可能是由于不同的控制器或者决策者间的协调不足、包括决策的不希望的副作用或者冲突的控制动作。通信缺陷和无效数据同样可以对故障的出现起重要作用,其中这些情况中的许多都非常难以预先预测。
上面的方式的最新替代方案是:在故障出现时在“在线”基础上来解决安全性问题。该工作在该范围中的大部分是关于计算和计算机联网。示例包括:IBM的自主计算(autonomic computing)思想以及由伯克利/斯坦福面向恢复的计算实验室(Berkeley/Stanford RecoveryOriented Computing(ROC)Laboratory)的研究者所完成的工作。该工作中的一般性的基础假设是:没有办法阻止不清楚的和意外故障的发生,并且不是所有这些故障都可以在设计阶段被识别。自主计算涉及建立如下的计算机硬件/软件和网络:所述计算机硬件/软件和网络能够适于在它们的环境中的变化;争取改善它们的性能;受到损坏时恢复;抵御攻击者;预期用户的动作,等等。ROC实验室的工作以类似的思想为中心,但是通过使系统更适于其环境是为了分布式系统的,从而可以迅速地检测故障、有效地包含故障并且在不需要关闭整个系统的情况下从故障中恢复。
所述在线方式通过将高等级的智能嵌入到系统控制中来改善系统可靠性。然而,可论证地,潜在的非决定论在响应时间和结果方面使这些方式对安全性关键的应用不可行。另一方面,如许多真实的事件在过去所显示的那样,仅仅依靠在设计或者测试阶段确定了一些容错等级的情况下的预编程的自动化,将不能使系统免受意外的故障和危险。因此,本发明者相信,为了使系统安全性和可靠性最大化,必须采取混合方式:i)预先主动地尝试在设计阶段和系统测试阶段识别尽可能多的故障和不希望的状况;和ii)将一些合理的智能等级嵌入到控制系统中,从而当发生故障时在运行时间时有效地检测出故障并作出合适的补救措施。
还有一个理由证明该在线方式是有效的。假定技术上能够建立对基础的“车间”规范的动态行为和破坏性的动态行为的模拟(在预先已知的范围内)。在所假设的分布式系统中,该车间模型将是单独代理体模型的网络。现在假定该模拟包括初始控制设计(称其为“第一级逼近”)并且使该初始控制设计与所模拟的车间模型一起工作在闭环中。假设该模拟运行足够量的时间,则能够观测一些未知的故障状况。现在,如果在控制器中已经嵌入了由本发明者在此提出的智能,则能够检测、诊断和避免所观测到的故障状况。利用每个新近发现的主要故障状况来将该控制系统升级到更高等级的逼近。
因此,目前需要为多控制器工业控制系统中的故障检测和故障避免提供高度有效的框架。据本发明者所知,目前还没有这样的技术可用。
具体实施方式
本说明集中在与工厂控制有关的问题,并且具体而言讨论了制造运行中的死锁状况的示例。为在控制系统中的嵌入智能提出一种框架,从而以前未知的(未被预编程到工厂系统控制中的)状况在运行时间被检测并且在以后被避免。所假设的是:故障的性质为已知,但是未知的是:该故障如何和何时可能发生、将涉及谁、以及如何在未来避免该故障。尽管本发明是参照因素控制环境中的死锁的示例来说明的,但是该基础思想也适于其它类型的故障。
本发明是模块化的框架和方法,并且以作为有形地体现在一个或多个程序存储设备上的应用程序的软件被部署。该应用程序可以存在于工业控制系统中的多个互联的工业控制器的每个中。所述工业控制器控制该系统中的基础过程。用户可以通过图形用户界面(GUI)来访问该框架。用于执行的应用程序代码可以存在于本领域的技术人员知道的多个不同类型的计算机可读介质上。
框架
本发明讨论了工业过程控制器的分布式系统
每个过程控制器包括足够的处理能力以便充当分布式工厂控制环境中的代理体。控制器被假设为具有其自己的基本功能组、局部规则组,并且同样必须遵守全局规则组。下面的算法被提出以便被嵌入在工厂控制系统中的一个或多个控制器中。
算法:
开始循环
识别症状:
-运行方法(Identify_Symptoms(识别_症状))。
-运行方法(Measure_persistance_of_Symptom(测
量_症状_的_持续性))。
-如果Measure_persistance_of_Symptom返回的值
太高,则进行下一步骤,否则什么也不做。
根原因分析:
-运行方法(Find_Other_controllers_involved(找
出_其它_涉及的_控制器))。
-运行方法(Identify_Fault_Condition(识别_故障
_状况))。
-如果Identify_Fault_Condition返回故障状况,则
进行下一步骤,否则什么也不做-等待直到症状消
失。
重新配置控制规则:
-运行方法(Reconfigure_Control_Laws(重新配置
_控制_规则))。
结束循环
上面的框架在原则上是概括性的,但是上述每个方法的细节以及复杂度因应用而变化。在此,为出现在该算法中的每个方法概括一种解决方式,但是注意这些方式可能仅适用于特定的应用。处理制造应用中的死锁状况的说明性示例被呈现。
方法(Identify_symptoms(识别_症状))
所假设的是:由面临“症状”的过程控制器来发起在线故障分析。术语“症状”在此被宽松地使用,并且指的是由控制器在任意给定时间所经历的非规范状况。例如,当期望从另一控制器获得响应的控制器在预先规定的时间窗内未接收到该响应时,该控制器被认为是正在经历症状。类似地,过程的实际状态与由过程控制器所保存的状态之间的任何偏差可以被认为是症状。这两种情况都需要控制器具有关于它们的基础过程的一些知识(模型)。图1中示出了由Petri网(或者“PN”)100表示的这样的模型的示例。针对该说明性的示例,标记为A
1的控制器110是机器控制器,其控制机器
,标记为
的控制器130是机器人控制器,其控制机器人
同样说明了控制器120(标记为
)和控制器140(标记为
)。该图示出了控制器之间的通信链路。例如,地点q
1与转变t
1之间的连接115表示来自
的
的服务请求。
考虑超时或者“看门狗”监测场景。在文献中已经针对集中系统大篇幅地研究了该问题。这些结果中的一些同样可以被扩展到分布式系统。例如,如同由V.S.Srinivasan和M.Jafari在“FaultDetecting/Monitoring Using Time Petri Nets”(IEEE Transactionon System,Man and Cybernetics,第23卷,No.41993年七月/八月)中提出的那样,可以由时间Petri网(TPN)来对基础过程建模。在此,用转变来表达事件,并且用地点来表达状况。为转变t
i定义时间窗(
),其中那些时间是相对于t
i被使能(enable)的时间而测量的。该系统在其状态方面和时间窗方面的动态特性在齐次不等性(homogeneous non-equalities)的系统中被捕获,其中所述动态特性由“回火”(backfiring)转变产生。到回火转变的时间用θ
i参数表示,并且根据在同一时间使能的转变的时间窗或者被回火并导致使能t
i的转变的时间窗而被定义。任何来自基础过程的所观测的状态(通过传感设备获得)和控制器状态的漂移都通过该不等式系统的解决方案而被分析。Srinivasan和Jafari还提出了一种为地点计算最大令牌持有时间的技术。接下来要概述的是:将他们的方法扩展到分布式系统。
假定该方法从初始状态s
0∈S
p开始,其中S
p是地点p被标记的所有Petri网标记(marking)组,并且使转变的有序序列
回火以到达状态s,其中p不再被标记。令Ψ为在该点火序列(firing sequence)中被访问的状态组。可以定义:
其中
应当注意:转变t
i由于回火另一转变(如即t)被使能了。因此,转变t
i被使能的时间
与转变t被回火的时间θ
t相同。因此,在上述等式中,每个θ都可以被看成是转变的回火时间。规定
和
仅是给定的常数,我们可以重写上述等式:
上述关系的重要性是:该组不等式在回火的序列中的任意给定状态处可以根据该序列中的转变的回火时间的组{θ1,θ2,...,θn)和开始时间θ0来描述。上面那组约束条件可以用于计算任意给定的地点中的最大令牌持有时间:
其中
是在Ω
s上计算的。如图2中的状态和转变的序列200所示,最大令牌持有时间从如下转变回火序列产生:该序列从标记为s
0∈S
p的开始状态234开始,并且在标记为s的状态235结束。类似地,可以计算THT
min(p)。如果序列
导致具有来自另一控制器(在此为
)的输入状况的转变(见图1中的控制器
的t
1),则控制器
必须给
传递如下之一:馈送给(feed to)t
1的所有地点的最大和最小令牌持有时间、或者馈送给
中的具有至
中的转变t
1的输出连接的地点的所有转变的有效时间窗(effective time windows)。同时,如果Ψ包括如下状态:在该状态处,地点p(例如图1中的p5)被标记有来自另一控制器(在此为控制器
)的(多个)输入转变,则控制器
必须给
传递所有这些转变的有效时间窗。应当注意:有效时间窗可由于冲突解决或者调度方案而比原始分配的时间窗短。所假设的是:控制器之间的这样的通信是可能的,并且所传递的数据是可靠的。在这样的通信不可能或者数据不是完全可靠的情况下,每个控制器必须通过估计这些参数来制定出自己对其它控制器的认知。这就引起了估计这些参数的风险和错误的问题。关于对该主题的更多讨论,参见P.Zhao,A.Amini,M.A.Jafari的“A Failure/Fault Diagnoser Modelfor Autonomous Agents under Presence of Disturbances”(IEEEInternational Conference on Systems,Man,and Cybernetics,2006年)。
方法(Measure_persistance_of_Symptom(测量_症状_的_持续性)
症状的持续性将导致由正经历症状的控制器发起根原因分析。持续性是取决于应用的度量,其必须根据该症状的时间窗、发生频率、模式、严重性或者复杂性被量化。如果发现给定故障的持续性低于预定义的阈值,则该故障可以被本发明的方法忽略。
方法(Find_Other_controllers_involved(找出_其它_涉及的_控制器)
找出潜在可能对识别出的症状负责的控制器的问题的解决方案依赖于:(i)由每个控制器进行的状况监测的范围,以及(ii)控制器所具有的关于其自己的基础过程和其它控制器的基础过程的细节等级。例如,考虑如下情况:控制器
仅仅监测其内部状况中的一些,但是该控制器的基础过程的模型是完整的。对该示例而言,这意味着机器
控制器保存与
相关联的所有状态和事件。现在假设地点p
1已超时;即其具有令牌的时间比其最大持有时间长。对该说明性的示例而言,这意味着机器
已经等待从机器人
接收服务太长时间。
产生搜索树300,该搜索树300从状态305开始,在状态305处,地点p
1在一定量时间
内被标记(如图3所示)。考虑与过程控制器
相关联的树311。如果该树中的叶节点最后全部都是被监测的地点,并且这些地点中没有地点超过了它们的maximum_token_holding_time(最大令牌持有时间),则
只能归因于外部状况(即其它控制器)。可能的是:一个或多个分支在不曾命中被监测的地点的情况下继续进行,并且返回开始地点。这样的循环(此后称为“空循环”)的存在表示不能作出明确的结论。
本示例中的控制器
和
现在将被更严密地检查。存在至少两种可能性:(i)控制器
已经偏离其规范运行,并且还未将其传递给
,以及(ii)存在状况,即
中的q已经在一定量时间γ≥THT
max(q)内被标记。前一种情况立即表明调度策略的改变,而不是故障。在后一种情况下,如果q表示被监测的状况,则上述搜索继续进行,只是这次是在
中。如果q是不被监测的,则在
中最终将存在maximum_token_holding_time会被超过的地点,并且因此上面的搜索在该时间继续进行。这意味着:可能存在不同控制器之间的搜索并识别故障的时间滞后。当
实施其搜索时,其可能遇到一个或多个需要参与该搜索的控制器。
上面的搜索最终将产生至少一个控制器链、比如图4中所示的链400。下面的必要条件成立:
(i)该链具有至少一个具有如下控制器的节点:在该控制器处观测到原始症状。
(ii)如果在控制器
内的搜索指向被监测的、最大令牌持有时间被超过的地点,并且该地点从控制器
中的至少一个转变来接收输入,则在该链中存在从
到
的路径。
(iii)如果如下的一个或多个条件为真,则控制器成为该链中的最后一个节点:
a:未获得对maximum_token_holding_time状况的违背。
b:在该控制器中没有违背了maximum_token_holding_time的地点位于具有连接到其它控制器的地点或者转变的任何路径中。
c:如果在该控制器内部的该搜索树仅包括空循环。
可以容易地将上面的方法扩展到范围在(minimun_token_holding_time(最小令牌持有时间),maximum_token_holding_time)之间的监测。
对该说明性的示例而言,上面的链可以为:机器
请求
将其完成的工件传送给另一机器、即
。然而
未能响应,因为其正在等待来自
的许可。机器
没有响应因为其正在等待机器人
响应,等等。
方法(Identify_Fault_Condition(识别_故障_状况))
应当注意:上面的搜索不仅寻找那些潜在地对所观测的症状负责的控制器,而且间接地尝试识别根原因。通过查找链中的那些Maximum_token_holding_time状况已经被违背的控制器中的地点来实现此目标。该链中的具有对该状况的违背的最后一个控制器可能是该症状的潜在原因。对该控制器的搜索树的详细分析可以揭示发生了潜在故障的确切状况或者事件(转变)。
总体来说,从控制器的角度来确定所观测的症状是由于故障还是某些计划行为,是非常取决于应用的。工业控制器环境中的死锁的示例是说明性的。
总的来说,之所以发生死锁是因为两个或两个以上控制器在特定的时间段期间以循环的方式需要相同的(多个)资源或者服务。考虑该情况:机器
忙于工件类型
,机器
忙于工件类型
。根据
和
的过程计划,
中的工件必须被
(机器人)传送给
,并且
中的工件必须被
传送给
。显然这是一个死锁情况,因为我们假设
是
和
的唯一的服务提供者控制器。现在考虑图10所示的另一场景:机器
忙于工件类型
,机器
忙于工件类型
,等等。
是机器
的提供者,而
是机器
的提供者。机器
当前为空闲的。根据过程计划,
中的工件必须被传送给
并然后被传送给
,并且
中的工件必须传送给
并然后被传送给
。因为机器
当前为空闲,所以当前不存在死锁情况,但是只要这些机器人的任意之一将该工件移动到
,该系统就死锁。这种类型的死锁被称为即将发生的工件流死锁(Impending Part Flow deadlock)(或者第二级死锁),意味着该死锁将在下两个步骤中发生。当具有n个机器和n-1个机器人(所述机器的提供者)时,该示例可以扩展到第(
)级死锁。
为了识别故障状况,潜在地对所观测的症状负责的控制器列表被复制给该链中的所有控制器。然后使用本领域中公知的称为Mitchell-Merritt算法的算法。该算法基于任务等待图(Task-Wait-For graph(TWFG))而工作,所述任务等待图是一种如下的图:在该图中,顶点表示任务,而从T1到T2的有向边(directed edge)表示任务T1由于资源冲突而在等待另一任务T2。每个顶点都具有一个私有标记(private label)和一个公共标记(public label)。私有标记(由节点下半部中的指标表示)是唯一的变量并且随着时间对该顶点非减。公用标记(由节点上半部中的指标表示)对每个任务可用并且不一定是唯一的。最初,公用标记与私有标记相同。TWFG中的边意味着一个任务在等待另一任务。
在Mitchell-Merritt算法中使用四类状态转变:
(1)当控制器开始等待另一资源时,该控制器变成被阻塞的控制器。该被阻塞的控制器的标记变得比其原始值更大,并且也大于正在被等待(wait on)的控制器的、对该节点同样唯一的公共标记。在TWFG中,将边从被阻塞的控制器画向所需的资源。
(2)当控制器获得必需的资源时,该控制器变为激活的。将从等待顶点中除去该边。
(3)当被阻塞的控制器发现其公共标记小于其正在等待的资源的公共标记时,发生传递步骤(transmit step)。在这种情况下,该等待控制器将用刚刚读取的标记来替换其公共标记。这导致更大的标记沿TWFG的边迁移。
(4)当控制器接收回其自己的公共标记时,发生(死锁)检测步骤。
所假设的是:TWFG的构建是由最先经历了症状的控制器发起的。此外,为了该控制器构建TWFG,其它控制器必须将该方法所需的状态信息传递给该控制器。
为了说明对死锁故障状况的识别,对图5中所示的子系统500进行详述。该子系统是更大的系统(未示出)的一部分。所假设的是:与机器510(标记为
)相关联的控制器是最先观测到症状的控制器;即该控制器从机器人520(标记为
)接收响应发生超时。同样假定:方法(Find_Other_controllers_involved)揭示了潜在的控制器组{
}。此外,该示例中的控制器链是以
开始并结束于
的循环。对该潜在的控制器组的进一步分析可以揭示:
和
是被动涉及的,而其它是主动涉及的。
因为机器530(标记为M2)忙于工件类型PP2,所以如图6的TWFG所示,TWFG最初将创建两个节点:为M1和M2各一个。该图将被扩展,因为M2必须等待机器550(标记为M3)。如果公共标记3最初被分配给节点M3,则M1和M2的公共标记将根据图6中所示的TWFG的步骤而改变。最终,M3将等待M1,这将产生循环。因为两个公共标记针对M1和M3都相同,所以将检测到死锁。
方法(Reconfigure_Control_Laws(重新配置_控制_规则))
所假设的是:上面检测到的状况可以仅仅使用一些类型的人工干预来决定。然而,根据本发明可以在未来自动避免该相同的状况。下面是用于建立将保证其发生的控制规则的方法。术语“状态”将宽松地用于指PN中的地点或者地点集。需要注意:每个有限的PN都可以总是被转变为有限状态机。
每当故障状况被检测到并且被控制器识别时,与该故障相关联的所有激活的控制器的、“坏的(bad)”或者“要避免的”状态组将被该控制器记录并且将对所有其它控制器可用。控制器的特定的坏状态在特定故障的背景内并且相对于所涉及的其它控制器的状态而被定义。在不同的情况下,同样的状态可能不一定是坏状态。三控制器的系统700(图7)包括两个已经被检测到的故障710、720(分别标记为故障1、故障2)。故障1由状态{(
),(
),(
)}定义,而故障2由状态{(
),(
)}来定义。这些状态组定义了最新的要避免的状态列表。如所述的,术语“状态”被宽松地使用。
考虑上面的故障1。每当控制器
尝试转变到状态
时,并且在发生以前,
必须与控制器
和
通信。现在如果
和
都分别处于故障1状态、即
和
中,则
必须停止到状态
的转变。如图7所示,在每个控制器控制范围之内的、在这些故障状况下必须被禁止的转变被表达为虚线。
在参照图5的上述示例中,说明了三个激活的控制器
和
的死锁状态。图8中说明了在所述三个控制器间共享的、“要避免的(to-avoid)”状态810、820、830的列表。应当注意:
(a)每个机器的状态包括正在被处理的对象的状态。“*”表示由该控制器本身保存的状态元素,但是不需要在各种控制器之间被分享。例如,机器的可用性不影响死锁情况;因此这些被认为是不关心的(“*”)。
(b)所假设的是:所述工件的当前阶段数目由r、s和t来表达。
现在假定:该系统处于图9所述的状态。假设类型PP
1的工件的状态是E(PP
1,r),类型PP
2的工件的状态是E(PP
2,s-1),而类型PP
3的工件的状态是E(PP
3,t)。假设:PP
2必须必须被从其当前位置(即该图中未示出的控制器
)取出,并被传送给
(根据给定的过程计划)。机器人
将向
发送请求并且将等待其响应。
将预测其下一状态,该状态是(
):(*,I,E(PP
2,*,s),*)。
将把其要避免的列表与所预测的状态相比较。因为存在匹配,所以
将把询问发送给
和
和
将通过将它们的当前状态发送给
来响应这些询问。因为
和
的当前状态与
的要避免列表中的状态匹配,所以
将得出结论:如果
作出该移动则该系统将死锁。因此,
将不接受
的请求,并且该机器人在
和
改变它们的状态以前将不会从
中取出工件。
进一步的工作
本发明者调查研究了上述在线框架在工业自动控制系统中的应用。例如,在线分布式系统曾在使用Siemens PLC的情况下被实施于基于代理体的工厂控制中。在该情况下,过程控制器被集成在分布式工作流中,其中不同类型的工件在同一工场被制造。每种类型的工件的制造过程包括不同的加工程序,并且每个程序可以由多个机器执行。机器人用于在机器之间传送工件。对于工件处理的每个步骤,可用的机器投标(bid for)该工作流。投标算法在使用分布式过程控制器中的PLC编程的情况下被成功演示。尽管未实施在此所述的特定故障检测算法,但是该工作演示了PLC处理复杂在线框架的能力。
此外,本发明者还使用了Siemens Win AC(一种基于软件的PLC)来实施复杂的代理体算法、比如建模、推理和故障检测。例如,使用Win AC将基于模型的故障检测实施在基于代理体的淡水冷却系统中。在该演示中,如果观测结果与模型预测不一致,则该系统确定故障已经发生。基于模型的推理引擎被用于执行系统诊断。进一步的工作被构思以改善同时发生的故障检测,并且在单个故障有多个原因的情况下的改善性能。
结论
描述了一种正式的用于分布式工业控制系统的在线故障检测和避免的方法。该系统的表达形式提供用于认出故障传播的通用解决方法。该系统的表达形式特别适于制造应用中的未知的死锁状况。
该通用方法是与应用非常有关的。在死锁应用中,所作的假设是:控制器的环境是确定性的,并且是完全可观测的,而且代理体未遭受故障。
应该理解前述详细的描述在各个方面都是说明性和示例性的,而不是限制性的,并且在此公开的本发明的范围并不由本发明的说明书来决定,而是从根据专利法所允许的最大宽度来解释的权利要求书中确定。例如,尽管该技术主要是在与工厂过程控制系统结合使用的情况下被说明,但是本领域的技术人员能够理解,该技术同样可以结合其它类型的控制系统而使用。例如,可以料想的是,本发明方法将在分布式发电系统和热电联产(cogeneration)系统中表现良好,因为需要广泛的协调以使这样的系统保持运行。应当理解,在此所述和所示的实施例仅仅是为了说明本发明的原理,并且本领域技术人员可以在不偏离本发明的范围和精神的情况下实施各种改变。