基于PLC的立體車庫控制系統(tǒng)設計
基于PLC的立體車庫控制系統(tǒng)設計,基于,PLC,立體車庫,控制系統(tǒng),設計
屆本科畢業(yè)設計(論文)外文
文獻翻譯
學 院： 電氣與自動化工程學院
專 業(yè)：
姓 名：
學 號：
(用外文寫)
外文出處: Springer-Verlag London Limited 2012
附 件： 1.外文資料翻譯譯文；2.外文原文。
附件1：外文資料翻譯譯文
基于PLC的自動化系統(tǒng)的遠程診斷的設計：
遠程診斷性能評價的影響因素
摘要
在故障診斷中的性能故障排除任務通常是在不同工業(yè)領域的應用研究。在以前進行了幾個實驗的研究中了解過程接口的能力，以協(xié)助當地的故障診斷和疑難排解，同??時考慮到接口影響，故障性質和專業(yè)知識的疑難解答。雖然有幾個遠程診斷架構已經提出和已經制定標準遠程診斷的水平，在何種程度上的遠程診斷體系結構的設計，可以幫助在診斷和遠程故障診斷的影響因素性能沒有被頻繁的問題的疑難解答。“本文的目的是了解影響遠程故障診斷的性能的因素，包括遠程診斷架構，故障類型，層次的專業(yè)知識，遠程疑難解答，當地運營商和技術水平。實驗是在其中進行故障排除，使用三個層次的遠程診斷體系結構診斷不同類型的故障，在可編程邏輯控制器根據離散自動化裝配系統(tǒng)，同時加入當地工程師和新手駕駛員。結果表明，故障是因為測量或監(jiān)測相關的診斷遠程專家故障排除工具的問題，遠程系統(tǒng)變量故障排除性能的提升能增加遠程診斷體系結構的水平。與此相反，新手疑難排解，與這些故障的診斷有顯著差異，在遠程故障診斷性能方面觀察三者之間的架構，對新手疑難排解遇到的一些問題與管理提供更多的信息。專家們展現(xiàn)出更好的信息收集能力，他們花了更多的時間在每個信息源，完成來自較少的轉換之間的信息故障診斷。監(jiān)控系統(tǒng)參數無關故障導致顯著減少了遠程故障診斷性能，與所有三個架構比較，相關的監(jiān)控系統(tǒng)參數故障為專家和新手排解疑難問題。工程師和新手之間的性能故障排除的遠程整體差異運營商并沒有明顯發(fā)現(xiàn)。
關鍵詞：遠程診斷 控制架構 遠程維護 故障排除 可編程邏輯控制器 第二階段圖
1.引言
故障診斷的過程是識別一個系統(tǒng)是否工作在狀態(tài)（通常狀態(tài)）下，或偏離期望的行為的過程，并確定故障類型，位置和這些異常行為的潛在根源。傳統(tǒng)的遠程故障診斷結合了故障診斷的強度和計算機通信技術[1]。它使專家來解決任何設備的問題，從外部通過網絡或制造商的設施與調制解調器連接[2]，因此，遠程監(jiān)控系統(tǒng)診斷故障可將設備運用到充分的生產狀態(tài)。遠程診斷技術[3]咨詢可以通過互聯(lián)網、電子郵件、更新、圖紙、圖表等，手冊、視頻、圖像等可互相交換客戶和制造商之間的信息。包括PC經由網絡而涉及的遠程訪問的系統(tǒng)控制器或控制站的活躍的信息交流是遠程的一部分診斷。遠程診斷的主要優(yōu)點之一是疑難排解，包括專家，系統(tǒng)集成商，有經驗的運營商可以分享他們的知識，經驗，突發(fā)情況的工作技能，以提高系統(tǒng)的可用性。這又有助于降低運營成本，減少機器的停機時間，而不必實際訪問系統(tǒng)網站。從而實現(xiàn)巨大的節(jié)省時間和成本。
許多遠程診斷系統(tǒng)已經被提出伴隨著診斷算法，包括實施神經網絡[4]，模糊邏輯[5]，支持向量機[6]來針對不同的應用，在可編程邏輯控制器（PLC）為基礎的自動化系統(tǒng)診斷故障上。但是，上述的診斷算法可能沒有效率，因為PLC為基礎的自動化系統(tǒng)是典型的離散事件系統(tǒng)（DES）。DES是一個離散狀態(tài)、事件驅動的系統(tǒng)，隨著時間的推移其狀態(tài)完全取決于異步離散事件的發(fā)生[7]。因此，一個獨特的設計方法所需的診斷要基于PLC的控制系統(tǒng)。這種系統(tǒng)可能影響遠程故障診斷性能，因素包括：體系結構中遠程診斷的復雜程度，已被診斷故障性質，操作者的技能水平和專家遠程疑難解答的水平。遠程故障診斷體系結構是指一個遠程的組件的配置診斷系統(tǒng)，包括網絡基礎設施、硬件和軟件。組件的配置以何種方式可以促進診斷遠程位置自動化系統(tǒng)的異常狀態(tài)。在使用遙控器的故障排除診斷架構的差異性能進行研究。對整體性能故障的性質的檢查效果，可能使人們有可能確定下一種類型的遠程診斷體系結構的情況，可能適合也可能不是最可行的選項。操作員檢查技巧的水平和專業(yè)知識的疑難排解的能力，將使研究人員能夠確定將允許以有限的技術人員進行技能附加功能架構提供的故障診斷。采用有限的技術能力的操作員，這可能是經濟的，但是這會增加該架構成本。
研究人員已經研究人機接口和運營商在當地的診斷性能[8]的效果。然而，有相對較少的設計遠程診斷架構的研究，這是一個復雜的問題[9]，涉及來自不同領域的知識，包括計算機科學和人體工程學。在以前報告工作中，根據指南從SEMATECH [2]我們實現(xiàn)了三個遠程診斷體系結構，本研究[10]發(fā)表在早先發(fā)出中國先進制造技術的國際報告中。目前研究的目的是分析程度，架構，故障，運營商和技能水平影響遠程故障診斷的性能。了解這些因素的影響，使遠程診斷性能更好地指導系統(tǒng)的設計。
本文其余部分安排如下：第2節(jié)討論了一些現(xiàn)有的遠程診斷體系結構和總結。第3節(jié)討論的自動化實驗中所用的系統(tǒng)，以及實驗變量。第4節(jié)給出的結果和討論。第5節(jié)結論和對未來的工作的展望。
2.文獻回顧
在討論中不同級別的操作員的人機界面的能力協(xié)助運營商在當地的故障診斷[8]，討論內容為自動化系統(tǒng)。實驗開始執(zhí)行，其中運營商通過接口在一個自動化的制造系統(tǒng)的不同的故障使用了三個層次的診斷。測試的目的是憑經驗評估三種類型的操作界面和暴露在一些常用的用戶接口低效率方面的弊端，促進人們在故障診斷中的故障排除性能的任務。診斷故障所需要的時間，數量的信息在屏幕上觀看，執(zhí)行診斷測試的數量被確定為性能措施。混雜變量的影響：接口的類型，故障的性質和順序也被認為是。
實驗評價的有效性功能在故障診斷中摘錄的信息[11]是以設計為視覺信息顯示過程控制。改善人類解決問題的方法是考慮過程接口的目標在核電廠故障診斷中。抽象的層次能力用以提高故障診斷的性能，通過實施增加三個層次的接口的功能測試。復雜度在診斷問題上的影響也要考慮。它被認為是存在的信息和顯示類型的結合，產生最佳性能。建議有關整合的信息化水平的顯示類型是為了提高給定的顯示效果。
生態(tài)接口測試的能力的實證研究幫助診斷在石油化工流程[12]的故障為了專業(yè)運營商在實際的工廠設置。三種類型的顯示接口：一個當代使用兩個層次的生態(tài)接口（1傳統(tǒng)的和額外的基于任務的另一個增強信息）使用。它被認為是生態(tài)界面與其他基于任務的信息，以在更大程度上方便了操作，排除故障和當代接口的幫助。完成任務所花費的時間，數量的控制操作，診斷的準確性來確定性能得分。任務完成時間，數量較少的控制行動，更好地診斷準確率被看作是一個有效的接口所需的特性。
在文獻[13]提出的兼容性的信息類型與診斷策略的實驗研究。有關建設核電廠故障診斷輔助決策系統(tǒng)的應用。實驗采用四種不同類型的信息輔助工具，是代表共同運營支持系統(tǒng)為核電廠，以確定什么樣的信息類型，在診斷過程中，為一個特定的策略是有效的，便于操作的診斷任務。結論作出的適用性的信息有助于運營商策略和艾滋病的信息的有效性取決于采用的策略。
分層顯示對人類解決問題的性能的影響進行了研究，在[14]中引入了計算機模擬邏輯電路的主題有不同程度的技術能力被診斷故障。它被認為能力不足的診斷與主題，分層顯示界面更有助于，作為主管疑難排解同樣發(fā)現(xiàn)了兩種類型的接口兼容。因此，他們建立的接口的能力，以便診斷也依賴于用戶的技能。
SEMATECH [2]訂下的半導體制造業(yè)電子化診斷標準。根據SEMATECH，電子診斷功能可以描述內的前四個等級（0-3），每一級的建設與增加的能力。根據多種因素綜合作用的混合水平數量的增加：支持任務的順序進行，實施必要的基礎設施，執(zhí)行診斷任務，降低人的援助，并增加自動化的難易程度。0級開始基本的遠程連接和遠程協(xié)作，0級水平的基礎上，允許遠程控制，監(jiān)測和存儲的操作和異常的數據。2級支持自動故障報警和歷史數據的處理，同時還包括1級水平的能力。3級是最先進的架構與功能，如自動決策支持，自我診斷預測性維護，等等。
在不同的層面代表能力的標準，多個遠程診斷體系結構提出了建議。在交換電子郵件，文本，音頻，視頻反饋，交換圖像和與當地運營商的架構通信有一些共同的特點，它們之間的區(qū)別在他們的遠程診斷方法，如使用虛擬儀器和神經網絡的感官數據基于網絡的診斷支持系統(tǒng)[4]，自動診斷和報警的診斷結果發(fā)送到手機或PDA設備的疑難解答[15]，協(xié)同診斷，使用一個集中的故障數據庫和診斷工具[16]，使用分層過程接口結合Petri網為基礎的系統(tǒng)模型[17]，并通過HTML接口，遠程控制和報警的電子郵件從控制器[18]通過實時過程監(jiān)控狀態(tài)。
2.1 一般資料 - 需求
從文獻回顧，可以看出，很多以前的研究集中在實現(xiàn)遠程故障診斷的各種方法。存在著不同級別的遠程診斷體系結構，支持不同類型的能力，總結了標準的遠程診斷[2]。一些架構將這些不同的自動化系統(tǒng)的能力做了很多工作，以確定離散制造系統(tǒng)中的故障發(fā)生的頻率[19]。實驗評價因素，促進人類在當地的故障診斷任務中解決以前考慮到的不同類型的故障，包括接口類型，疑難排解和技術水平的工作。然而，如何在現(xiàn)有的架構方便故障排除工具，討論在不同類型的故障診斷，自動化系統(tǒng)的遠程診斷環(huán)境是有限的。先進水平架構的能力是否需要進行測試，在失敗的疑難解答，專業(yè)知識和技能的操作者經驗的基礎上。
在遠程診斷環(huán)境中，遠程疑難排解在與本地操作員一起工作，以實現(xiàn)故障診斷。在這樣的一個交互式的設置，可能故障處理的性能受到本地操作員的技能的影響。故障診斷人員的能力，使用能力及診斷策略可能會有所不同，這取決于他們的能力水平。遠程診斷體系結構形成界面的自動化系統(tǒng)，遠程疑難解答。任何遠程診斷體系結構的主要目的，是為了方便它的用戶，以確定診斷系統(tǒng)中的故障的根本原因。故障診斷人員的本地系統(tǒng)的操作的技術水平，故障性質和疑難解答認為在傳統(tǒng)的故障診斷能力上完全適用，對遠程診斷環(huán)境作出貢獻。
因此，在本文中，使用三個水平的自動化系統(tǒng)的故障診斷不斷提高遠程診斷架構的不同類型的解決能力，強調由一個人使用這些架構來進行疑難解答。一個嘗試遠程診斷體系結構的能力，以協(xié)助不同的專業(yè)知識水平的人進行疑難排解，通過比較三個不同層次的架構，在另一種情況下的故障和運營商的遠程故障診斷性能與經驗評估。其結果是，它是可以了解的因素，會影響遠程故障排除性能。
3.實驗
3.1 診斷系統(tǒng)
該系統(tǒng)使用的是可重構的雙機器人裝配系統(tǒng)[20]羅克韋爾自動化實驗室如圖1所示。該裝配線由四個站組成。第一個是用于驗證是否在規(guī)格范圍之內的基臺部的檢查站。第二個是站3工作的緩沖站。站3和4是相同的裝配站，氣動，龍門式取放機器人組裝釘入洞的基礎部分。裝配線模仿組件的骨釘同步的插入孔中，在基座部分的載體和其行動是由PLC控制。
圖1 自動化流水線
3.2 實驗目標
為了確定如何構建遠程診斷體系結構，便于故障診斷人員進行遠程診斷和了解遠程故障診斷性能的因素的影響，建立了以下目標：
1、要建立一個模型，以評估排除故障和其他組合下的性能故障，操作和架構
2、要診斷的故障排除性能、故障的性質與遠程診斷體系結構的影響研究
3、與遠程診斷體系結構研究的影響比較，當地運營商的技術能力上的表現(xiàn)
4、要比較的專家和新手疑難排解故障排除策略
3.3 實驗變量
三個輸入（獨立）的變量被確定為：遠程診斷架構（X1），系統(tǒng)運營商（X2），和自動化系統(tǒng)故障（X3）。從屬變量包括診斷失?。ˋ1）的搜索量（A2），診斷測試（A3）的數目，和質量架構（A4）所采取的時間。在本節(jié)將介紹這些變量的詳細描述。
3.3.1 遠程診斷架構
基于分類的電子化診斷能力[2] SEMATECH，三種架構，代表不同層次的遠程診斷功能的實現(xiàn)。架構1采用0級與1級結合的能力。架構2采用1級水平的能力。架構3在1級的基礎上，并結合2級和3級的一定的能力水平。這三個架構可以概括如下：
架構-1 這種結構具有的基本功能，實現(xiàn)遠程連接和疑難解答和運營商之間的合作。它的功能是類似的討論0級型的架構[2]，其中包括視頻，語音傳輸，靜態(tài)圖像，文本通信，安全的文件傳輸。
架構-2 它具有對在[2]中提出的等級1型架構所討論的相似的功能。它包括1級架構的所有功能，同時還通過一個圖形界面的運行狀態(tài)的實時監(jiān)控。
架構-3 這包括架構-1和2的功能，以及一些額外2和3 [2]水平層次的功能，視頻播放，歷史事件記錄，以及遠程桌面監(jiān)控界面。
3.3.2 系統(tǒng)運營商
隨著當地運營商的自動化系統(tǒng)，遠程故障診斷基于PLC的系統(tǒng)環(huán)境方面，兩種情況下可以配置：
1、算子的低技術知識（新手）：這里指的情況是，在操作員僅僅是該系統(tǒng)的用戶和沒有技術的背景來理解的操作的系統(tǒng)，電氣，電子，或機械子系統(tǒng)。學生沒有一個PLC和自動化的過程。
2、操作員有足夠的技術知識（工程師）：這是指在運營商的情況下所需的技術背景，了解系統(tǒng)的運行，到網上去找PLC，學生采取了PLC和自動化的過程。
3.3.3 自動系統(tǒng)故障
制造系統(tǒng)的故障可分為硬件故障，產品故障，軟件故障[21]，任務故障[22]和容許誤差23]。這項研究將包括四個類型的故障：故障較低的機器人臂（硬件故障），故障關閉夾子（產品故障），插入故障（任務失?。?，和失敗的挑選（組合軟件故障和容許誤差）。引入實驗系統(tǒng)的故障的細節(jié)列于表1。
附件2：外文原文
Remote diagnosis design for a PLC-based automated system:
2-evaluation of factors affecting remote diagnosis performance
Abstract
Troubleshooting 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 diagram
1．Introduction
Fault 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 manufacturer's 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.
2．Literature review
The 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 both
types 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 (0–3), 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 type of architectures with features such as automated decision support, self diagnostics predictive maintenance, etc.
Representative of the capabilities of the different levels across the standards, several remote diagnosis architectures were proposed. While exchanging e-mails, text, audio, video feedback, exchanging images and communication with the local operator are some of the common features of the proposed architectures, they differ in their remote diagnosis methodology such as use of sensory data with virtual instrumentsof and neural network-based diagnosis support system [4], automated
diagnosis and alarming by sending diagnosis results to the phone or PDA device of the troubleshooter [15], collaborative diagnosis using a centralized failure database and diagnosis tools [16], use of hierarchical process interfaces combined with petri-net-based system models [17], and monitoring of real time process status via HTML interfaces, remote control and alarming by means of e-mail messages from the controller [18].
2.1 Summary - needs
From the literature review, it is seen that a lot of previous research focused on various methods of achieving remote fault diagnosis. Different levels of remote diagnosis architectures exist that support different types of capabilities
summarized in the standards for remote diagnosis [2]. Several proposed architectures incorporate these capabilities for different automated systems. A lot of work has been done to identify the failures occurring in discrete manufacturing systems and the frequency of occurrence of the failures [19]. Experimental evaluation of factors facilitating human troubleshooting performance in local fault diagnosis tasks has been addressed in work done previously considering different types of failure, type of interface, and skill level of the troubleshooter. However, there is limited discussion on how the existing architectures facilitate troubleshooters in diagnosing different types of failures in automated systems in a remote diagnosis environment. Whether the capabilities on the advanced levels of architectures are required needs to be tested empirically based on the nature of the failure, expertise of the troubleshooter, and the skil
收藏