外文翻譯---基于plc的自動化系統(tǒng)的遠程診斷的設計

1、<p>　　2013 屆本科畢業(yè)設計(論文)外文</p><p><b>　　文獻翻譯</b></p><p>　　學 院： 電氣與自動化工程學院 </p><p>　　專 業(yè)： 自動化 </p><p>　　姓 名：

2、 張浩 </p><p>　　學 號： YZ0411224 </p><p>　　外文出處: Springer-Verlag London Limited 2012 </p><p>　　附 件： 1.外文資料翻譯譯文；2.外文原文。</p><p>　　附

3、件1：外文資料翻譯譯文</p><p>　　基于PLC的自動化系統(tǒng)的遠程診斷的設計：</p><p>　　遠程診斷性能評價的影響因素</p><p>　　Ramnath Sekar & Sheng-Jen Hsieh & Zhenhua Wu</p><p>　　收稿日期：2010年6月16號 接受日期：2012年5月17號&

4、lt;/p><p>　　施普林格出版社倫敦有限公司2012</p><p><b>　　摘要</b></p><p>　　在故障診斷中的性能故障排除任務通常是在不同工業(yè)領域的應用研究。在以前進行了幾個實驗的研究中了解過程接口的能力，以協(xié)助當?shù)氐墓收显\斷和疑難排解，同??時考慮到接口影響，故障性質(zhì)和專業(yè)知識的疑難解答。雖然有幾個遠程診斷架構已經(jīng)提出和

5、已經(jīng)制定標準遠程診斷的水平，在何種程度上的遠程診斷體系結構的設計，可以幫助在診斷和遠程故障診斷的影響因素性能沒有被頻繁的問題的疑難解答?！氨疚牡哪康氖橇私庥绊戇h程故障診斷的性能的因素，包括遠程診斷架構，故障類型，層次的專業(yè)知識，遠程疑難解答，當?shù)剡\營商和技術水平。實驗是在其中進行故障排除，使用三個層次的遠程診斷體系結構診斷不同類型的故障，在可編程邏輯控制器根據(jù)離散自動化裝配系統(tǒng)，同時加入當?shù)毓こ處熀托率竹{駛員。結果表明，故障是因為測量或

6、監(jiān)測相關的診斷遠程專家故障排除工具的問題，遠程系統(tǒng)變量故障排除性能的提升能增加遠程診斷體系結構的水平。與此相反，新手疑難排解，與這些故障的診斷有顯著差異，在遠程故障診斷性能方面觀察三者之間的架構，對新手疑難排解遇到的一些問題與管理提供更多的信息。專家們展現(xiàn)出更好的信息收集能力，他們花了更多的時間在每個信息源，完成來自較少的轉(zhuǎn)換之間</p><p>　　關鍵詞：遠程診斷 控制架構 遠程維護 故障排除 可編程

7、邏輯控制器 第二階段圖</p><p><b>　　1.引言</b></p><p>　　故障診斷的過程是識別一個系統(tǒng)是否工作在狀態(tài)（通常狀態(tài)）下，或偏離期望的行為的過程，并確定故障類型，位置和這些異常行為的潛在根源。傳統(tǒng)的遠程故障診斷結合了故障診斷的強度和計算機通信技術[1]。它使專家來解決任何設備的問題，從外部通過網(wǎng)絡或制造商的設施與調(diào)制解調(diào)器連接[2]，因此，

8、遠程監(jiān)控系統(tǒng)診斷故障可將設備運用到充分的生產(chǎn)狀態(tài)。遠程診斷技術[3]咨詢可以通過互聯(lián)網(wǎng)、電子郵件、更新、圖紙、圖表等，手冊、視頻、圖像等可互相交換客戶和制造商之間的信息。包括PC經(jīng)由網(wǎng)絡而涉及的遠程訪問的系統(tǒng)控制器或控制站的活躍的信息交流是遠程的一部分診斷。遠程診斷的主要優(yōu)點之一是疑難排解，包括專家，系統(tǒng)集成商，有經(jīng)驗的運營商可以分享他們的知識，經(jīng)驗，突發(fā)情況的工作技能，以提高系統(tǒng)的可用性。這又有助于降低運營成本，減少機器的停機時間，而

9、不必實際訪問系統(tǒng)網(wǎng)站。從而實現(xiàn)巨大的節(jié)省時間和成本。</p><p>　　許多遠程診斷系統(tǒng)已經(jīng)被提出伴隨著診斷算法，包括實施神經(jīng)網(wǎng)絡[4]，模糊邏輯[5]，支持向量機[6]來針對不同的應用，在可編程邏輯控制器（PLC）為基礎的自動化系統(tǒng)診斷故障上。但是，上述的診斷算法可能沒有效率，因為PLC為基礎的自動化系統(tǒng)是典型的離散事件系統(tǒng)（DES）。DES是一個離散狀態(tài)、事件驅(qū)動的系統(tǒng)，隨著時間的推移其狀態(tài)完全取決于異步離

10、散事件的發(fā)生[7]。因此，一個獨特的設計方法所需的診斷要基于PLC的控制系統(tǒng)。這種系統(tǒng)可能影響遠程故障診斷性能，因素包括：體系結構中遠程診斷的復雜程度，已被診斷故障性質(zhì)，操作者的技能水平和專家遠程疑難解答的水平。遠程故障診斷體系結構是指一個遠程的組件的配置診斷系統(tǒng)，包括網(wǎng)絡基礎設施、硬件和軟件。組件的配置以何種方式可以促進診斷遠程位置自動化系統(tǒng)的異常狀態(tài)。在使用遙控器的故障排除診斷架構的差異性能進行研究。對整體性能故障的性質(zhì)的檢查效果，

11、可能使人們有可能確定下一種類型的遠程診斷體系結構的情況，可能適合也可能不是最可行的選項。操作員檢查技巧的水平和專業(yè)知識的疑難排解的能力，將使研究人員能夠確定將允許以有限的技術人員進行技能附加功能架構提供的故障診斷。采用</p><p>　　研究人員已經(jīng)研究人機接口和運營商在當?shù)氐脑\斷性能[8]的效果。然而，有相對較少的設計遠程診斷架構的研究，這是一個復雜的問題[9]，涉及來自不同領域的知識，包括計算機科學和人體工

12、程學。在以前報告工作中，根據(jù)指南從SEMATECH [2]我們實現(xiàn)了三個遠程診斷體系結構，本研究[10]發(fā)表在早先發(fā)出中國先進制造技術的國際報告中。目前研究的目的是分析程度，架構，故障，運營商和技能水平影響遠程故障診斷的性能。了解這些因素的影響，使遠程診斷性能更好地指導系統(tǒng)的設計。</p><p>　　本文其余部分安排如下：第2節(jié)討論了一些現(xiàn)有的遠程診斷體系結構和總結。第3節(jié)討論的自動化實驗中所用的系統(tǒng)，以及實驗

13、變量。第4節(jié)給出的結果和討論。第5節(jié)結論和對未來的工作的展望。</p><p><b>　　2.文獻回顧</b></p><p>　　在討論中不同級別的操作員的人機界面的能力協(xié)助運營商在當?shù)氐墓收显\斷[8]，討論內(nèi)容為自動化系統(tǒng)。實驗開始執(zhí)行，其中運營商通過接口在一個自動化的制造系統(tǒng)的不同的故障使用了三個層次的診斷。測試的目的是憑經(jīng)驗評估三種類型的操作界面和暴露在一些

14、常用的用戶接口低效率方面的弊端，促進人們在故障診斷中的故障排除性能的任務。診斷故障所需要的時間，數(shù)量的信息在屏幕上觀看，執(zhí)行診斷測試的數(shù)量被確定為性能措施?；祀s變量的影響：接口的類型，故障的性質(zhì)和順序也被認為是。</p><p>　　實驗評價的有效性功能在故障診斷中摘錄的信息[11]是以設計為視覺信息顯示過程控制。改善人類解決問題的方法是考慮過程接口的目標在核電廠故障診斷中。抽象的層次能力用以提高故障診斷的性能，

15、通過實施增加三個層次的接口的功能測試。復雜度在診斷問題上的影響也要考慮。它被認為是存在的信息和顯示類型的結合，產(chǎn)生最佳性能。建議有關整合的信息化水平的顯示類型是為了提高給定的顯示效果。</p><p>　　生態(tài)接口測試的能力的實證研究幫助診斷在石油化工流程[12]的故障為了專業(yè)運營商在實際的工廠設置。三種類型的顯示接口：一個當代使用兩個層次的生態(tài)接口（1傳統(tǒng)的和額外的基于任務的另一個增強信息）使用。它被認為是生態(tài)

16、界面與其他基于任務的信息，以在更大程度上方便了操作，排除故障和當代接口的幫助。完成任務所花費的時間，數(shù)量的控制操作，診斷的準確性來確定性能得分。任務完成時間，數(shù)量較少的控制行動，更好地診斷準確率被看作是一個有效的接口所需的特性。</p><p>　　在文獻[13]提出的兼容性的信息類型與診斷策略的實驗研究。有關建設核電廠故障診斷輔助決策系統(tǒng)的應用。實驗采用四種不同類型的信息輔助工具，是代表共同運營支持系統(tǒng)為核電廠

17、，以確定什么樣的信息類型，在診斷過程中，為一個特定的策略是有效的，便于操作的診斷任務。結論作出的適用性的信息有助于運營商策略和艾滋病的信息的有效性取決于采用的策略。</p><p>　　分層顯示對人類解決問題的性能的影響進行了研究，在[14]中引入了計算機模擬邏輯電路的主題有不同程度的技術能力被診斷故障。它被認為能力不足的診斷與主題，分層顯示界面更有助于，作為主管疑難排解同樣發(fā)現(xiàn)了兩種類型的接口兼容。因此，他們建

18、立的接口的能力，以便診斷也依賴于用戶的技能。</p><p>　　SEMATECH [2]訂下的半導體制造業(yè)電子化診斷標準。根據(jù)SEMATECH，電子診斷功能可以描述內(nèi)的前四個等級（0-3），每一級的建設與增加的能力。根據(jù)多種因素綜合作用的混合水平數(shù)量的增加：支持任務的順序進行，實施必要的基礎設施，執(zhí)行診斷任務，降低人的援助，并增加自動化的難易程度。0級開始基本的遠程連接和遠程協(xié)作，0級水平的基礎上，允許遠程控制

19、，監(jiān)測和存儲的操作和異常的數(shù)據(jù)。2級支持自動故障報警和歷史數(shù)據(jù)的處理，同時還包括1級水平的能力。3級是最先進的架構與功能，如自動決策支持，自我診斷預測性維護，等等。</p><p>　　在不同的層面代表能力的標準，多個遠程診斷體系結構提出了建議。在交換電子郵件，文本，音頻，視頻反饋，交換圖像和與當?shù)剡\營商的架構通信有一些共同的特點，它們之間的區(qū)別在他們的遠程診斷方法，如使用虛擬儀器和神經(jīng)網(wǎng)絡的感官數(shù)據(jù)基于網(wǎng)絡的診

20、斷支持系統(tǒng)[4]，自動診斷和報警的診斷結果發(fā)送到手機或PDA設備的疑難解答[15]，協(xié)同診斷，使用一個集中的故障數(shù)據(jù)庫和診斷工具[16]，使用分層過程接口結合Petri網(wǎng)為基礎的系統(tǒng)模型[17]，并通過HTML接口，遠程控制和報警的電子郵件從控制器[18]通過實時過程監(jiān)控狀態(tài)。</p><p>　　2.1 一般資料 - 需求</p><p>　　從文獻回顧，可以看出，很多以前的研究集中在實

21、現(xiàn)遠程故障診斷的各種方法。存在著不同級別的遠程診斷體系結構，支持不同類型的能力，總結了標準的遠程診斷[2]。一些架構將這些不同的自動化系統(tǒng)的能力做了很多工作，以確定離散制造系統(tǒng)中的故障發(fā)生的頻率[19]。實驗評價因素，促進人類在當?shù)氐墓收显\斷任務中解決以前考慮到的不同類型的故障，包括接口類型，疑難排解和技術水平的工作。然而，如何在現(xiàn)有的架構方便故障排除工具，討論在不同類型的故障診斷，自動化系統(tǒng)的遠程診斷環(huán)境是有限的。先進水平架構的能力是

22、否需要進行測試，在失敗的疑難解答，專業(yè)知識和技能的操作者經(jīng)驗的基礎上。</p><p>　　在遠程診斷環(huán)境中，遠程疑難排解在與本地操作員一起工作，以實現(xiàn)故障診斷。在這樣的一個交互式的設置，可能故障處理的性能受到本地操作員的技能的影響。故障診斷人員的能力，使用能力及診斷策略可能會有所不同，這取決于他們的能力水平。遠程診斷體系結構形成界面的自動化系統(tǒng)，遠程疑難解答。任何遠程診斷體系結構的主要目的，是為了方便它的用戶，

23、以確定診斷系統(tǒng)中的故障的根本原因。故障診斷人員的本地系統(tǒng)的操作的技術水平，故障性質(zhì)和疑難解答認為在傳統(tǒng)的故障診斷能力上完全適用，對遠程診斷環(huán)境作出貢獻。</p><p>　　因此，在本文中，使用三個水平的自動化系統(tǒng)的故障診斷不斷提高遠程診斷架構的不同類型的解決能力，強調(diào)由一個人使用這些架構來進行疑難解答。一個嘗試遠程診斷體系結構的能力，以協(xié)助不同的專業(yè)知識水平的人進行疑難排解，通過比較三個不同層次的架構，在另一種

24、情況下的故障和運營商的遠程故障診斷性能與經(jīng)驗評估。其結果是，它是可以了解的因素，會影響遠程故障排除性能。</p><p><b>　　3.實驗</b></p><p><b>　　3.1 診斷系統(tǒng)</b></p><p>　　該系統(tǒng)使用的是可重構的雙機器人裝配系統(tǒng)[20]羅克韋爾自動化實驗室如圖1所示。該裝配線由四個站組成

25、。第一個是用于驗證是否在規(guī)格范圍之內(nèi)的基臺部的檢查站。第二個是站3工作的緩沖站。站3和4是相同的裝配站，氣動，龍門式取放機器人組裝釘入洞的基礎部分。裝配線模仿組件的骨釘同步的插入孔中，在基座部分的載體和其行動是由PLC控制。</p><p>　　圖1 自動化流水線</p><p><b>　　3.2 實驗目標</b></p><p>　　為了

26、確定如何構建遠程診斷體系結構，便于故障診斷人員進行遠程診斷和了解遠程故障診斷性能的因素的影響，建立了以下目標：</p><p>　　1、要建立一個模型，以評估排除故障和其他組合下的性能故障，操作和架構</p><p>　　2、要診斷的故障排除性能、故障的性質(zhì)與遠程診斷體系結構的影響研究</p><p>　　3、與遠程診斷體系結構研究的影響比較，當?shù)剡\營商的技術能力上

27、的表現(xiàn)</p><p>　　4、要比較的專家和新手疑難排解故障排除策略</p><p><b>　　3.3 實驗變量</b></p><p>　　三個輸入（獨立）的變量被確定為：遠程診斷架構（X1），系統(tǒng)運營商（X2），和自動化系統(tǒng)故障（X3）。從屬變量包括診斷失?。ˋ1）的搜索量（A2），診斷測試（A3）的數(shù)目，和質(zhì)量架構（A4）所采取的時間

28、。在本節(jié)將介紹這些變量的詳細描述。</p><p>　　3.3.1 遠程診斷架構</p><p>　　基于分類的電子化診斷能力[2] SEMATECH，三種架構，代表不同層次的遠程診斷功能的實現(xiàn)。架構1采用0級與1級結合的能力。架構2采用1級水平的能力。架構3在1級的基礎上，并結合2級和3級的一定的能力水平。這三個架構可以概括如下：</p><p>　　架構-1 這

29、種結構具有的基本功能，實現(xiàn)遠程連接和疑難解答和運營商之間的合作。它的功能是類似的討論0級型的架構[2]，其中包括視頻，語音傳輸，靜態(tài)圖像，文本通信，安全的文件傳輸。</p><p>　　架構-2 它具有對在[2]中提出的等級1型架構所討論的相似的功能。它包括1級架構的所有功能，同時還通過一個圖形界面的運行狀態(tài)的實時監(jiān)控。</p><p>　　架構-3 這包括架構-1和2的功能，以及一些額外

30、2和3 [2]水平層次的功能，視頻播放，歷史事件記錄，以及遠程桌面監(jiān)控界面。</p><p>　　3.3.2 系統(tǒng)運營商</p><p>　　隨著當?shù)剡\營商的自動化系統(tǒng)，遠程故障診斷基于PLC的系統(tǒng)環(huán)境方面，兩種情況下可以配置：</p><p>　　1、算子的低技術知識（新手）：這里指的情況是，在操作員僅僅是該系統(tǒng)的用戶和沒有技術的背景來理解的操作的系統(tǒng)，電氣，電子

31、，或機械子系統(tǒng)。學生沒有一個PLC和自動化的過程。</p><p>　　2、操作員有足夠的技術知識（工程師）：這是指在運營商的情況下所需的技術背景，了解系統(tǒng)的運行，到網(wǎng)上去找PLC，學生采取了PLC和自動化的過程。</p><p>　　3.3.3 自動系統(tǒng)故障</p><p>　　制造系統(tǒng)的故障可分為硬件故障，產(chǎn)品故障，軟件故障[21]，任務故障[22]和容許誤差2

32、3]。這項研究將包括四個類型的故障：故障較低的機器人臂（硬件故障），故障關閉夾子（產(chǎn)品故障），插入故障（任務失?。?，和失敗的挑選（組合軟件故障和容許誤差）。引入實驗系統(tǒng)的故障的細節(jié)列于表1。</p><p><b>　　附件2：外文原文</b></p><p>　　Remote diagnosis design for a PLC-based automated sy

33、stem:</p><p>　　2-evaluation of factors affecting remote diagnosis performance</p><p>　　Ramnath Sekar & Sheng-Jen Hsieh & Zhenhua Wu</p><p>　　Received: 16 June 2010 / Accepte

34、d: 17 May 2012</p><p>　　# Springer-Verlag London Limited 2012</p><p><b>　　Abstract</b></p><p>　　Troubleshooting performance in fault diagnosis tasks is commonly studied

35、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 o

36、f 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 diagnosi</p>&

37、lt;p>　　Keywords：Remote diagnosis; Control architecture; Tele-maintenance; Troubleshooting; Programmable Logic Controller; Stage diagram</p><p>　　1．Introduction</p><p>　　Fault diagnosis is th

38、e 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 faul

39、t 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 fa

40、cility via network or modem connection [2],</p><p>　　2．Literature review</p><p>　　The ability of different levels of operator machine interface to assist operators in the local fault diagnosis o

41、f 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 automat

42、ed 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 us</p><p>　　Experimental evaluation of th

43、e 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 objecti

44、ve 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

45、with increasing capabilities. T</p><p>　　An empirical study to test the ability of ecological interfaces to help diagnose faults in petrochemical processes was performed in [12] with professional operators i

46、n 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) w

47、ere used. It was seen that the ecological interface with additional task-based information facilitates the operato</p><p>　　In [13] was proposed the experimental investigation of the compatibility of informa

48、tion 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

49、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 f</p><p>　　

50、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 tec

51、hnical competence. It was seen that with subjects less competent in diagnosis, the hierarchical display interface was more helpful where as competent troubleshooters found both</p><p>　　types of interfaces s

52、imilarly compatible. Thus, they established that the ability of an interface to facilitate diagnosis was also dependent on the skill of the user.</p><p>　　SEMATECH [2] laid down standards for e-diagnostics f

53、or 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 i

54、ncrease 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 au

55、tomation</p><p>　　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,

56、 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 instr

57、umentsof and neural network-based diagnosis support system [4], automated</p><p>　　diagnosis and alarming by sending diagnosis results to the phone or PDA device of the troubleshooter [15], collaborative dia

58、gnosis 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 interface

59、s, remote control and alarming by means of e-mail messages from the controller [18].</p><p>　　2.1 Summary - needs</p><p>　　From the literature review, it is seen that a lot of previous research

60、focused on various methods of achieving remote fault diagnosis. Different levels of remote diagnosis architectures exist that support different types of capabilities</p><p>　　summarized in the standards for

61、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 th

62、e 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 diff

63、erent types of failure, type</p><p>　　In a remote diagnosis environment, the remote troubleshooter works in conjunction with a local operator in order to achieve failure diagnosis. In such an interactive set

64、ting, it is possible for the troubleshooting performance to be affected by the skill of the local operator. The ability of troubleshooters to use the capabilities provided and their diagnostic strategies could vary depen

65、ding on their level of competence. A remote diagnosis architecture forms the interface of an automated system t</p><p>　　human troubleshooters, the skill level of the local system operator, nature of failure

66、s, and the competence of the troubleshooter considered in traditional fault diagnosis are perfectly applicable and contribute towards performance in a remote diagnosis environment.</p><p>　　So, in this paper

67、, the diagnosis of different types of failures in an automated system using three increasing levels of remote diagnosis architectures is addressed with emphasis on the use of these architectures by a human troubleshooter

68、. An attempt is made to empirically evaluate the ability of the remote diagnosis architectures to assist troubleshooters of different expertise levels by comparing the remote troubleshooting performance with three differ

69、ent levels of architectures in alternative </p><p>　　3 Experiments</p><p>　　3.1 Description of the diagnosed system</p><p>　　The system used is a reconfigurable dual-robot assembly

70、system [20] in the Rockwell Automation Laboratory shown in Fig. 1. This assembly line consists for four stations. The first is the inspection station for verifying whether the base part is within specifications. The seco

71、nd station works as a buffer station for station 3. Stations 3 and 4 are identical assembly stations, where pneumatically operated, gantry type pick and place robots assemble pegs into the holes on the base part. The ass

72、embl</p><p>　　Fig. 1 Overview of the automated assembly line</p><p>　　3.2 Experimental objective</p><p>　　In order to determine how remote diagnosis architecture facilitates troubl

73、eshooters to perform remote diagnosis and to understand the impact of the factors on remote troubleshooting performance, the following objectives were established:</p><p>　　1. To develop a model for evaluati

74、ng the troubleshooting performance under alternative combinations of failure, operator and architecture</p><p>　　2. To study the effect of the nature of failure diagnosed on the troubleshooting performance w

75、ith a remote diagnosis architecture.</p><p>　　3. To study the effect of the technical skill of the local operator on the performance with a remote diagnosis architecture.</p><p>　　4. To compare

76、the troubleshooting strategies of expert and novice troubleshooters.</p><p>　　3.3 Experimental variables</p><p>　　The three input (independent) variables are identified as:</p><p>　

77、　remote diagnosis architectures (X1), system operators (X2), and automated system failures (X3). Dependent variables include time taken to diagnose the failure (A1), amount of searching (A2), number of diagnosis tests pe

78、rformed (A3), and quality of architecture (A4). A detailed description on these variables will be presented in this section.</p><p>　　3.3.1 Remote diagnosis architectures</p><p>　　Based on the c

79、ategorization of e-diagnostics capabilities [2] by SEMATECH, three architectures representing the capabilities of the different levels of remote diagnosis were implemented. Architecture-1 incorporates the capabilities of

80、 level-0.Architecture-2 incorporates the capabilities of level-1. Architecture-3 builds on level-1 and incorporates certain capabilities from levels-2 and 3. These three architectures can be summarized as follows: </p

81、><p>　　Architecture-1 This architecture has the basic capabilities enabling remote connectivity and collaboration between the troubleshooter and the operator. Its capabilities are similar to the ones discussed

82、on level-0 type architectures presented in [2] which includes video, voice transmission, still images, textual communication, and secure file transfer.</p><p>　　Architecture-2 It has capabilities similar to

83、the ones discussed on level-1 type architectures presented in [2]. It includes all the capabilities of architecture-1 and also additionally Fig. 1 Overview of the automated assembly line involves direct access to the PLC

84、 and near real time monitoring of operational status by means of a graphical interface.</p><p>　　Architecture-3 This includes the capabilities of architectures-1 and 2 along with some additional features of

85、levels-2 and 3 presented in [2] like hierarchical monitoring interface of the process, video playback, historical record events, and remote desktop.</p><p>　　3.3.2 System operators</p><p>　　With

86、 regards to the local operator of the automated system, in the remote fault diagnosis environment for a PLC-based system, two scenarios can be configured:</p><p>　　1. Operator with low technical knowledge (N

87、ovice): This refers to the situation where in the operator is merely a user of the system and has no technical background to understand the operation of the system, electrical, electronic, or mechanical subsystems. Stude

88、nt who had not taken a course on PLCs and automation was selected.</p><p>　　2. Operator with sufficient technical knowledge (Engineer): This refers to the situation where in the operator has the required tec

89、hnical background to understand the system operation and to go online with the PLC. Student who had taken a course on PLCs and automation was selected.</p><p>　　3.3.3 Automated system failures</p><

90、;p>　　The failures in manufacturing systems can be classified as hardware failures, product failures, software failures [21], task faults [22] and tolerance errors [23]. This study will involve four types of failures:

91、failure to lower robot arm (hardware failure), failure to close gripper (product failure), insertion failure or scratch (task failure), and failure to pick part (combination of software failure and tolerance error). The

92、details of the failures introduced into the system for experiments a</p><p><b>　　指導教師評語：</b></p><p>　　簽名： </p><p>　　年 月 日 </p>