外文翻译---基于PLC的自动化系统的远程诊断的设计.doc

2013 届本科毕业设计(论文)外文文献翻译学 院： 电气与自动化工程学院 专 业： 自动化 姓 名： 张浩 学 号： YZ0411224 (用外文写)外文出处: Springer-Verlag London Limited 2012 附 件： 1.外文资料翻译译文；2.外文原文。附件1：外文资料翻译译文基于PLC的自动化系统的远程诊断的设计：远程诊断性能评价的影响因素Ramnath Sekar & Sheng-Jen Hsieh & Zhenhua Wu收稿日期：2010年6月16号 接受日期：2012年5月17号施普林格出版社伦敦有限公司2012摘要在故障诊断中的性能故障排除任务通常是在不同工业领域的应用研究。在以前进行了几个实验的研究中了解过程接口的能力，以协助当地的故障诊断和疑难排解，同时考虑到接口影响，故障性质和专业知识的疑难解答。虽然有几个远程诊断架构已经提出和已经制定标准远程诊断的水平，在何种程度上的远程诊断体系结构的设计，可以帮助在诊断和远程故障诊断的影响因素性能没有被频繁的问题的疑难解答。“本文的目的是了解影响远程故障诊断的性能的因素，包括远程诊断架构，故障类型，层次的专业知识，远程疑难解答，当地运营商和技术水平。实验是在其中进行故障排除，使用三个层次的远程诊断体系结构诊断不同类型的故障，在可编程逻辑控制器根据离散自动化装配系统，同时加入当地工程师和新手驾驶员。结果表明，故障是因为测量或监测相关的诊断远程专家故障排除工具的问题，远程系统变量故障排除性能的提升能增加远程诊断体系结构的水平。与此相反，新手疑难排解，与这些故障的诊断有显著差异，在远程故障诊断性能方面观察三者之间的架构，对新手疑难排解遇到的一些问题与管理提供更多的信息。专家们展现出更好的信息收集能力，他们花了更多的时间在每个信息源，完成来自较少的转换之间的信息故障诊断。监控系统参数无关故障导致显著减少了远程故障诊断性能，与所有三个架构比较，相关的监控系统参数故障为专家和新手排解疑难问题。工程师和新手之间的性能故障排除的远程整体差异运营商并没有明显发现。关键词：远程诊断 控制架构 远程维护 故障排除 可编程逻辑控制器 第二阶段图1.引言故障诊断的过程是识别一个系统是否工作在状态（通常状态）下，或偏离期望的行为的过程，并确定故障类型，位置和这些异常行为的潜在根源。传统的远程故障诊断结合了故障诊断的强度和计算机通信技术1。它使专家来解决任何设备的问题，从外部通过网络或制造商的设施与调制解调器连接2，因此，远程监控系统诊断故障可将设备运用到充分的生产状态。远程诊断技术3咨询可以通过互联网、电子邮件、更新、图纸、图表等，手册、视频、图像等可互相交换客户和制造商之间的信息。包括PC经由网络而涉及的远程访问的系统控制器或控制站的活跃的信息交流是远程的一部分诊断。远程诊断的主要优点之一是疑难排解，包括专家，系统集成商，有经验的运营商可以分享他们的知识，经验，突发情况的工作技能，以提高系统的可用性。这又有助于降低运营成本，减少机器的停机时间，而不必实际访问系统网站。从而实现巨大的节省时间和成本。许多远程诊断系统已经被提出伴随着诊断算法，包括实施神经网络4，模糊逻辑5，支持向量机6来针对不同的应用，在可编程逻辑控制器（PLC）为基础的自动化系统诊断故障上。但是，上述的诊断算法可能没有效率，因为PLC为基础的自动化系统是典型的离散事件系统（DES）。DES是一个离散状态、事件驱动的系统，随着时间的推移其状态完全取决于异步离散事件的发生7。因此，一个独特的设计方法所需的诊断要基于PLC的控制系统。这种系统可能影响远程故障诊断性能，因素包括：体系结构中远程诊断的复杂程度，已被诊断故障性质，操作者的技能水平和专家远程疑难解答的水平。远程故障诊断体系结构是指一个远程的组件的配置诊断系统，包括网络基础设施、硬件和软件。组件的配置以何种方式可以促进诊断远程位置自动化系统的异常状态。在使用遥控器的故障排除诊断架构的差异性能进行研究。对整体性能故障的性质的检查效果，可能使人们有可能确定下一种类型的远程诊断体系结构的情况，可能适合也可能不是最可行的选项。操作员检查技巧的水平和专业知识的疑难排解的能力，将使研究人员能够确定将允许以有限的技术人员进行技能附加功能架构提供的故障诊断。采用有限的技术能力的操作员，这可能是经济的，但是这会增加该架构成本。研究人员已经研究人机接口和运营商在当地的诊断性能8的效果。然而，有相对较少的设计远程诊断架构的研究，这是一个复杂的问题9，涉及来自不同领域的知识，包括计算机科学和人体工程学。在以前报告工作中，根据指南从SEMATECH 2我们实现了三个远程诊断体系结构，本研究10发表在早先发出中国先进制造技术的国际报告中。目前研究的目的是分析程度，架构，故障，运营商和技能水平影响远程故障诊断的性能。了解这些因素的影响，使远程诊断性能更好地指导系统的设计。本文其余部分安排如下：第2节讨论了一些现有的远程诊断体系结构和总结。第3节讨论的自动化实验中所用的系统，以及实验变量。第4节给出的结果和讨论。第5节结论和对未来的工作的展望。2.文献回顾在讨论中不同级别的操作员的人机界面的能力协助运营商在当地的故障诊断8，讨论内容为自动化系统。实验开始执行，其中运营商通过接口在一个自动化的制造系统的不同的故障使用了三个层次的诊断。测试的目的是凭经验评估三种类型的操作界面和暴露在一些常用的用户接口低效率方面的弊端，促进人们在故障诊断中的故障排除性能的任务。诊断故障所需要的时间，数量的信息在屏幕上观看，执行诊断测试的数量被确定为性能措施。混杂变量的影响：接口的类型，故障的性质和顺序也被认为是。实验评价的有效性功能在故障诊断中摘录的信息11是以设计为视觉信息显示过程控制。改善人类解决问题的方法是考虑过程接口的目标在核电厂故障诊断中。抽象的层次能力用以提高故障诊断的性能，通过实施增加三个层次的接口的功能测试。复杂度在诊断问题上的影响也要考虑。它被认为是存在的信息和显示类型的结合，产生最佳性能。建议有关整合的信息化水平的显示类型是为了提高给定的显示效果。生态接口测试的能力的实证研究帮助诊断在石油化工流程12的故障为了专业运营商在实际的工厂设置。三种类型的显示接口：一个当代使用两个层次的生态接口（1传统的和额外的基于任务的另一个增强信息）使用。它被认为是生态界面与其他基于任务的信息，以在更大程度上方便了操作，排除故障和当代接口的帮助。完成任务所花费的时间，数量的控制操作，诊断的准确性来确定性能得分。任务完成时间，数量较少的控制行动，更好地诊断准确率被看作是一个有效的接口所需的特性。在文献13提出的兼容性的信息类型与诊断策略的实验研究。有关建设核电厂故障诊断辅助决策系统的应用。实验采用四种不同类型的信息辅助工具，是代表共同运营支持系统为核电厂，以确定什么样的信息类型，在诊断过程中，为一个特定的策略是有效的，便于操作的诊断任务。结论作出的适用性的信息有助于运营商策略和艾滋病的信息的有效性取决于采用的策略。分层显示对人类解决问题的性能的影响进行了研究，在14中引入了计算机模拟逻辑电路的主题有不同程度的技术能力被诊断故障。它被认为能力不足的诊断与主题，分层显示界面更有助于，作为主管疑难排解同样发现了两种类型的接口兼容。因此，他们建立的接口的能力，以便诊断也依赖于用户的技能。SEMATECH 2订下的半导体制造业电子化诊断标准。根据SEMATECH，电子诊断功能可以描述内的前四个等级（0-3），每一级的建设与增加的能力。根据多种因素综合作用的混合水平数量的增加：支持任务的顺序进行，实施必要的基础设施，执行诊断任务，降低人的援助，并增加自动化的难易程度。0级开始基本的远程连接和远程协作，0级水平的基础上，允许远程控制，监测和存储的操作和异常的数据。2级支持自动故障报警和历史数据的处理，同时还包括1级水平的能力。3级是最先进的架构与功能，如自动决策支持，自我诊断预测性维护，等等。在不同的层面代表能力的标准，多个远程诊断体系结构提出了建议。在交换电子邮件，文本，音频，视频反馈，交换图像和与当地运营商的架构通信有一些共同的特点，它们之间的区别在他们的远程诊断方法，如使用虚拟仪器和神经网络的感官数据基于网络的诊断支持系统4，自动诊断和报警的诊断结果发送到手机或PDA设备的疑难解答15，协同诊断，使用一个集中的故障数据库和诊断工具16，使用分层过程接口结合Petri网为基础的系统模型17，并通过HTML接口，远程控制和报警的电子邮件从控制器18通过实时过程监控状态。2.1 一般资料 - 需求从文献回顾，可以看出，很多以前的研究集中在实现远程故障诊断的各种方法。存在着不同级别的远程诊断体系结构，支持不同类型的能力，总结了标准的远程诊断2。一些架构将这些不同的自动化系统的能力做了很多工作，以确定离散制造系统中的故障发生的频率19。实验评价因素，促进人类在当地的故障诊断任务中解决以前考虑到的不同类型的故障，包括接口类型，疑难排解和技术水平的工作。然而，如何在现有的架构方便故障排除工具，讨论在不同类型的故障诊断，自动化系统的远程诊断环境是有限的。先进水平架构的能力是否需要进行测试，在失败的疑难解答，专业知识和技能的操作者经验的基础上。在远程诊断环境中，远程疑难排解在与本地操作员一起工作，以实现故障诊断。在这样的一个交互式的设置，可能故障处理的性能受到本地操作员的技能的影响。故障诊断人员的能力，使用能力及诊断策略可能会有所不同，这取决于他们的能力水平。远程诊断体系结构形成界面的自动化系统，远程疑难解答。任何远程诊断体系结构的主要目的，是为了方便它的用户，以确定诊断系统中的故障的根本原因。故障诊断人员的本地系统的操作的技术水平，故障性质和疑难解答认为在传统的故障诊断能力上完全适用，对远程诊断环境作出贡献。因此，在本文中，使用三个水平的自动化系统的故障诊断不断提高远程诊断架构的不同类型的解决能力，强调由一个人使用这些架构来进行疑难解答。一个尝试远程诊断体系结构的能力，以协助不同的专业知识水平的人进行疑难排解，通过比较三个不同层次的架构，在另一种情况下的故障和运营商的远程故障诊断性能与经验评估。其结果是，它是可以了解的因素，会影响远程故障排除性能。3.实验3.1 诊断系统该系统使用的是可重构的双机器人装配系统20罗克韦尔自动化实验室如图1所示。该装配线由四个站组成。第一个是用于验证是否在规格范围之内的基台部的检查站。第二个是站3工作的缓冲站。站3和4是相同的装配站，气动，龙门式取放机器人组装钉入洞的基础部分。装配线模仿组件的骨钉同步的插入孔中，在基座部分的载体和其行动是由PLC控制。图1 自动化流水线3.2 实验目标为了确定如何构建远程诊断体系结构，便于故障诊断人员进行远程诊断和了解远程故障诊断性能的因素的影响，建立了以下目标：1、要建立一个模型，以评估排除故障和其他组合下的性能故障，操作和架构2、要诊断的故障排除性能、故障的性质与远程诊断体系结构的影响研究3、与远程诊断体系结构研究的影响比较，当地运营商的技术能力上的表现4、要比较的专家和新手疑难排解故障排除策略3.3 实验变量三个输入（独立）的变量被确定为：远程诊断架构（X1），系统运营商（X2），和自动化系统故障（X3）。从属变量包括诊断失败（A1）的搜索量（A2），诊断测试（A3）的数目，和质量架构（A4）所采取的时间。在本节将介绍这些变量的详细描述。3.3.1 远程诊断架构基于分类的电子化诊断能力2 SEMATECH，三种架构，代表不同层次的远程诊断功能的实现。架构1采用0级与1级结合的能力。架构2采用1级水平的能力。架构3在1级的基础上，并结合2级和3级的一定的能力水平。这三个架构可以概括如下：架构-1 这种结构具有的基本功能，实现远程连接和疑难解答和运营商之间的合作。它的功能是类似的讨论0级型的架构2，其中包括视频，语音传输，静态图像，文本通信，安全的文件传输。架构-2 它具有对在2中提出的等级1型架构所讨论的相似的功能。它包括1级架构的所有功能，同时还通过一个图形界面的运行状态的实时监控。架构-3 这包括架构-1和2的功能，以及一些额外2和3 2水平层次的功能，视频播放，历史事件记录，以及远程桌面监控界面。3.3.2 系统运营商随着当地运营商的自动化系统，远程故障诊断基于PLC的系统环境方面，两种情况下可以配置：1、算子的低技术知识（新手）：这里指的情况是，在操作员仅仅是该系统的用户和没有技术的背景来理解的操作的系统，电气，电子，或机械子系统。学生没有一个PLC和自动化的过程。2、操作员有足够的技术知识（工程师）：这是指在运营商的情况下所需的技术背景，了解系统的运行，到网上去找PLC，学生采取了PLC和自动化的过程。3.3.3 自动系统故障制造系统的故障可分为硬件故障，产品故障，软件故障21，任务故障22和容许误差23。这项研究将包括四个类型的故障：故障较低的机器人臂（硬件故障），故障关闭夹子（产品故障），插入故障（任务失败），和失败的挑选（组合软件故障和容许误差）。引入实验系统的故障的细节列于表1。附件2：外文原文Remote diagnosis design for a PLC-based automated system:2-evaluation of factors affecting remote diagnosis performanceRamnath Sekar & Sheng-Jen Hsieh & Zhenhua WuReceived: 16 June 2010 / Accepted: 17 May 2012# Springer-Verlag London Limited 2012AbstractTroubleshooting performance in fault diagnosis tasks is commonly studied in various industrial applications. Several experiments were performed in previous studies to understand the ability of process interfaces to assist troubleshooters in local fault diagnosis while considering the effect of interface, nature of the failure, and the expertise of the troubleshooter. Although several remote diagnosis architectures have been proposed and standards have been developed for levels of remote diagnosis, the extent to which the design of a remote diagnosis architecture can assist a troubleshooter in diagnosis and the factors affecting remote troubleshooting performance have not been frequently addressed. The objective of this paper is to understand the factors that impact remote troubleshooting performance, including remote diagnosis architecture, type of failure, level of expertise of the remote troubleshooter, and skill level of the local operator. Experiments were performed in which troubleshooters used three levels of remote diagnosis architectures to diagnose different types of failures in a programmable logic controller based discrete automated assembly system while working with local engineer and novice operators. The results suggest that for diagnosis of failures related to measured or monitored system variables by remote expert troubleshooters, remote troubleshooting performance improved with the increase in the levels of the remote diagnosis architectures. In contrast, in diagnosis of these failures by novice troubleshooters, no significant difference was observed between the three architectures in terms of remote troubleshooting performance, and the novice troubleshooters experienced problems with managing the increased information available. The experts exhibited better information gathering capabilities in that they spent more time per information source and made fewer transitions between information sources while diagnosing failures. Failures unrelated to monitored system parameters resulted in significantly reduced remote troubleshooting performance with all three architectures in comparison to the failures related to monitored system parameters for both expert and novice troubleshooters. The difference in terms of overall remote troubleshooting performance between engineer and novice operators was not found to be significant.Keywords：Remote diagnosis; Control architecture; Tele-maintenance; Troubleshooting; Programmable Logic Controller; Stage diagram1IntroductionFault diagnosis is the process of identifying whether a system is working under normal condition or deviating from the desired behavior and determining fault type, location, and potential root causes for those abnormal behaviors. Remote fault diagnosis combines the strength of traditional fault diagnosis and computer communication technology 1. It enables equipment experts to troubleshoot any key production equipment from outside the manufacturers facility via network or modem connection 2, thus remotely monitor systems, diagnose faults, and bring the equipment into full productive state. With remote diagnosis technology 3, technical consulting is done via internet such that e-mails, updates, drawings, diagrams, manuals, video, images, etc. can be exchanged among customers and manufacturers. Active information exchange, involving remote access to the controller of the system or the control station PC of the plant via the network is part of remote diagnosis. One of the major advantages of remote diagnosis is that troubleshooters including experts, system integrators, and experienced operators can share their knowledge, experience, and skills in working with unexpected situations to enhance system availability. This in turn helps reduce operation cost by reducing machine down time without having to physically visit the system site. Huge time and cost savings are thus achieved. Many remote diagnosis systems have been proposed and implemented along with diagnostics algorithms including neural network 4, fuzzy logic 5, and support vector machine 6 for different applications. For diagnosing faults in programmable logic controller (PLC)-based automated systems, however, the aforementioned diagnosis algorithms may not be efficient, because PLC-based automated systems are typically discrete event systems (DES). A DES is a discrete-state, event-driven system; its state depends entirely on the occurrence of asynchronous discrete events over time 7. Thus, a unique design approach is needed for diagnosing PLC-based control systems. Factors that could potentially affect remote troubleshooting performance of such systems include: the level of sophistication of the remote diagnosis architecture, the nature of the failure to be diagnosed, the skill level of the operator, and the level of expertise of the remote troubleshooter. Remote fault diagnosis architecture refers to the configuration of the components of a remote diagnosis system including network infrastructure, hardware and software. The manner in which components are configured can facilitate diagnosis of abnormal status of automated systems from remote locations. The differences in troubleshooting performance when using various levels of remote diagnosis architecture could be studied. Examining the effect of the nature of the failure on the overall performance may make it possible to identify cases where a type of remote diagnosis architecture could be suitable or may not be the most viable option. Examining the effects of the skill level of the operator and the expertise of the troubleshooter will allow researchers to determine if the additional capabilities provided by the architectures would allow remote diagnosis to be performed by personnel with limited technical skills. It may be economical to employ an operator with limited technical skills but this would increase the cost of the architecture. Researchers have studied the effect of human machine interfaces and operators on local diagnosis performance 8. However, there has been relatively little research on design of remote diagnosis architectures, which is a complicated problem 9 involving knowledge from diverse fields such as computer science and ergonomics. In previously reported work, we implemented three remote diagnosis architectures based on the guidelines from SEMATECH 2; this research 10 was published in an earlier issue of the International Journal of Advanced Manufacturing Technology. The purpose of the current study is to analyze the extent to which architectures, faults, and skill level of operators influence remote troubleshooting performance. Understanding of these factors effect on remote diagnosis performance can better direct the system design. The rest of this paper is organized as follows: Section 2 discusses some existing remote diagnosis architectures and summarizes the needs. Section 3 discusses about the automated system used in the experiments and the experimental variables. Section 4 presents the results and discussion. Section 5 ends with conclusion and future work.2Literature reviewThe ability of different levels of operator machine interface to assist operators in the local fault diagnosis of discrete automated systems was discussed in 8. Experiments were performed wherein operators used three hierarchical levels of interfaces with increasing capabilities to diagnose three different failures in an automated manufacturing system. The purpose of the tests was to empirically evaluate the three types of operator interfaces and expose the drawbacks in some of the commonly used user interfaces in terms of their inefficiency to facilitate human troubleshooting performance in fault diagnosis tasks. The time taken to diagnose the fault, the number of information screens viewed, and the number of diagnostic tests performed were identified as the measures of performance. The impact of confounding variables: type of interface, nature of failure, and the order of experiments were also considered. Experimental evaluation of the effectiveness of functionally abstracted information in fault diagnosis was done in 11 in order to design for visual information display for process control. Improving human problem solving performance is the objective of the process interface considered for fault diagnosis in nuclear power plants. The ability of the hierarchical abstraction to improve troubleshooting performance was tested by implementing three levels of interface with increasing capabilities. The impact of the complexity of the diagnosis problem on the performance was also considered. It was seen that certain combinations of level of information and type of display exist that generate optimum performance. Recommendations regarding the integration of information level with display type were made to improve the effectiveness of any given display.An empirical study to test the ability of ecological interfaces to help diagnose faults in petrochemical processes was performed in 12 with professional operators in realistic plant settings. Three types of display interfaces: one contemporarily used and two hierarchical levels of ecological interfaces (one traditional and another augmented with additional task-based information) were used. It was seen that the ecological interface with additional task-based information facilitates the operator to a greater extent to troubleshoot failures and the contemporary interface was least helpful. The time taken to complete the task, the number of control actions, and the diagnosis accuracy were used to determine the performance score. Lower task completion time, lower number of control actions, and better diagnosis accuracy were seen as the desired characteristics of an effective interface.In 13 was proposed the experimental investigation of the compatibility of information types with diagnostic strategy. The application was related to building decision-aiding systems for fault diagnosis in nuclear power plants. Experiments were performed using four different types of information aids that are representative of common operator support systems for diagnosis tasks in nuclear power plants in order to determine what information type would be effective for a particular strategy and facilitate the operator during diagnosis. Conclusions were made regarding the suitability of information aids for operator strategy and that the effectiveness of information aids was dependent on the strategy employed. The effects of hierarchical display on human problem solving performance was studied in 14. Faults were introduced in computer simulations of logic circuits which were diagnosed by subjects with different levels of technical competence. It was seen that with subjects less competent in diagnosis, the hierarchical display interface was more helpful where as competent troubleshooters found bothtypes of interfaces similarly compatible. Thus, they established that the ability of an interface to facilitate diagnosis was also dependent on the skill of the user.SEMATECH 2 laid down standards for e-diagnostics for the semiconductor manufacturing industry. According to SEMATECH, e-diagnostics capabilities can be described within four levels (03), each level building on the previous with increased capability. The level numbers increase according to a blend of many factors: the sequence of support tasks performed, the ease of implementing the necessary infrastructure to execute the diagnostic tasks, decreasing human assistance, and increasing automation. While level-0 begins with basic remote connectivity and remote collaboration, level-1 builds on level-0 and allows remote control and monitoring and storage of operational and exceptions data. Level-2 supports automated failure alarms and processing of historical data while including the capabilities from level-1. Level-3 is the most advanced ty