外文翻譯---基于plc的自動(dòng)化系統(tǒng)的遠(yuǎn)程診斷的設(shè)計(jì)

1、<p>　　2013 屆本科畢業(yè)設(shè)計(jì)(論文)外文</p><p><b>　　文獻(xiàn)翻譯</b></p><p>　　學(xué) 院： 電氣與自動(dòng)化工程學(xué)院 </p><p>　　專 業(yè)： 自動(dòng)化 </p><p>　　姓 名：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

32、3]。這項(xiàng)研究將包括四個(gè)類型的故障：故障較低的機(jī)器人臂（硬件故障），故障關(guān)閉夾子（產(chǎn)品故障），插入故障（任務(wù)失敗），和失敗的挑選（組合軟件故障和容許誤差）。引入實(shí)驗(yàn)系統(tǒng)的故障的細(xì)節(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>　　指導(dǎo)教師評(píng)語：</b></p><p>　　簽名： </p><p>　　年 月 日 </p>