基于PLC的立體車庫控制系統(tǒng)設(shè)計(jì)

基于PLC的立體車庫控制系統(tǒng)設(shè)計(jì),基于,PLC,立體車庫,控制系統(tǒng),設(shè)計(jì) 屆本科畢業(yè)設(shè)計(jì)(論文)外文 文獻(xiàn)翻譯 學(xué) 院： 電氣與自動化工程學(xué)院 專 業(yè)： 姓 名： 學(xué) 號： (用外文寫) 外文出處: Springer-Verlag London Limited 2012 附 件： 1.外文資料翻譯譯文；2.外文原文。 附件1：外文資料翻譯譯文 基于PLC的自動化系統(tǒng)的遠(yuǎn)程診斷的設(shè)計(jì)： 遠(yuǎn)程診斷性能評價的影響因素 摘要 在故障診斷中的性能故障排除任務(wù)通常是在不同工業(yè)領(lǐng)域的應(yīng)用研究。在以前進(jìn)行了幾個實(shí)驗(yàn)的研究中了解過程接口的能力，以協(xié)助當(dāng)?shù)氐墓收显\斷和疑難排解，同??時考慮到接口影響，故障性質(zhì)和專業(yè)知識的疑難解答。雖然有幾個遠(yuǎn)程診斷架構(gòu)已經(jīng)提出和已經(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è)知識，遠(yuǎn)程疑難解答，當(dāng)?shù)剡\(yùn)營商和技術(shù)水平。實(shí)驗(yàn)是在其中進(jìn)行故障排除，使用三個層次的遠(yuǎn)程診斷體系結(jié)構(gòu)診斷不同類型的故障，在可編程邏輯控制器根據(jù)離散自動化裝配系統(tǒng)，同時加入當(dāng)?shù)毓こ處熀托率竹{駛員。結(jié)果表明，故障是因?yàn)闇y量或監(jiān)測相關(guān)的診斷遠(yuǎn)程專家故障排除工具的問題，遠(yuǎn)程系統(tǒng)變量故障排除性能的提升能增加遠(yuǎn)程診斷體系結(jié)構(gòu)的水平。與此相反，新手疑難排解，與這些故障的診斷有顯著差異，在遠(yuǎn)程故障診斷性能方面觀察三者之間的架構(gòu)，對新手疑難排解遇到的一些問題與管理提供更多的信息。專家們展現(xiàn)出更好的信息收集能力，他們花了更多的時間在每個信息源，完成來自較少的轉(zhuǎn)換之間的信息故障診斷。監(jiān)控系統(tǒng)參數(shù)無關(guān)故障導(dǎo)致顯著減少了遠(yuǎn)程故障診斷性能，與所有三個架構(gòu)比較，相關(guān)的監(jiān)控系統(tǒng)參數(shù)故障為專家和新手排解疑難問題。工程師和新手之間的性能故障排除的遠(yuǎn)程整體差異運(yùn)營商并沒有明顯發(fā)現(xiàn)。 關(guān)鍵詞：遠(yuǎn)程診斷 控制架構(gòu) 遠(yuǎn)程維護(hù) 故障排除 可編程邏輯控制器 第二階段圖 1.引言 故障診斷的過程是識別一個系統(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]，因此，遠(yuǎn)程監(jiān)控系統(tǒng)診斷故障可將設(shè)備運(yùn)用到充分的生產(chǎn)狀態(tài)。遠(yuǎn)程診斷技術(shù)[3]咨詢可以通過互聯(lián)網(wǎng)、電子郵件、更新、圖紙、圖表等，手冊、視頻、圖像等可互相交換客戶和制造商之間的信息。包括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)營商可以分享他們的知識，經(jīng)驗(yàn)，突發(fā)情況的工作技能，以提高系統(tǒng)的可用性。這又有助于降低運(yùn)營成本，減少機(jī)器的停機(jī)時間，而不必實(shí)際訪問系統(tǒng)網(wǎng)站。從而實(shí)現(xiàn)巨大的節(jié)省時間和成本。 許多遠(yuǎn)程診斷系統(tǒng)已經(jīng)被提出伴隨著診斷算法，包括實(shí)施神經(jīng)網(wǎng)絡(luò)[4]，模糊邏輯[5]，支持向量機(jī)[6]來針對不同的應(yīng)用，在可編程邏輯控制器（PLC）為基礎(chǔ)的自動化系統(tǒng)診斷故障上。但是，上述的診斷算法可能沒有效率，因?yàn)镻LC為基礎(chǔ)的自動化系統(tǒng)是典型的離散事件系統(tǒng)（DES）。DES是一個離散狀態(tài)、事件驅(qū)動的系統(tǒng)，隨著時間的推移其狀態(tài)完全取決于異步離散事件的發(fā)生[7]。因此，一個獨(dú)特的設(shè)計(jì)方法所需的診斷要基于PLC的控制系統(tǒng)。這種系統(tǒng)可能影響遠(yuǎn)程故障診斷性能，因素包括：體系結(jié)構(gòu)中遠(yuǎn)程診斷的復(fù)雜程度，已被診斷故障性質(zhì)，操作者的技能水平和專家遠(yuǎn)程疑難解答的水平。遠(yuǎn)程故障診斷體系結(jié)構(gòu)是指一個遠(yuǎn)程的組件的配置診斷系統(tǒng)，包括網(wǎng)絡(luò)基礎(chǔ)設(shè)施、硬件和軟件。組件的配置以何種方式可以促進(jìn)診斷遠(yuǎn)程位置自動化系統(tǒng)的異常狀態(tài)。在使用遙控器的故障排除診斷架構(gòu)的差異性能進(jìn)行研究。對整體性能故障的性質(zhì)的檢查效果，可能使人們有可能確定下一種類型的遠(yuǎn)程診斷體系結(jié)構(gòu)的情況，可能適合也可能不是最可行的選項(xiàng)。操作員檢查技巧的水平和專業(yè)知識的疑難排解的能力，將使研究人員能夠確定將允許以有限的技術(shù)人員進(jìn)行技能附加功能架構(gòu)提供的故障診斷。采用有限的技術(shù)能力的操作員，這可能是經(jīng)濟(jì)的，但是這會增加該架構(gòu)成本。 研究人員已經(jīng)研究人機(jī)接口和運(yùn)營商在當(dāng)?shù)氐脑\斷性能[8]的效果。然而，有相對較少的設(shè)計(jì)遠(yuǎn)程診斷架構(gòu)的研究，這是一個復(fù)雜的問題[9]，涉及來自不同領(lǐng)域的知識，包括計(jì)算機(jī)科學(xué)和人體工程學(xué)。在以前報(bào)告工作中，根據(jù)指南從SEMATECH [2]我們實(shí)現(xiàn)了三個遠(yuǎn)程診斷體系結(jié)構(gòu)，本研究[10]發(fā)表在早先發(fā)出中國先進(jìn)制造技術(shù)的國際報(bào)告中。目前研究的目的是分析程度，架構(gòu)，故障，運(yùn)營商和技能水平影響遠(yuǎn)程故障診斷的性能。了解這些因素的影響，使遠(yuǎn)程診斷性能更好地指導(dǎo)系統(tǒng)的設(shè)計(jì)。 本文其余部分安排如下：第2節(jié)討論了一些現(xiàn)有的遠(yuǎn)程診斷體系結(jié)構(gòu)和總結(jié)。第3節(jié)討論的自動化實(shí)驗(yàn)中所用的系統(tǒng)，以及實(shí)驗(yàn)變量。第4節(jié)給出的結(jié)果和討論。第5節(jié)結(jié)論和對未來的工作的展望。 2.文獻(xiàn)回顧 在討論中不同級別的操作員的人機(jī)界面的能力協(xié)助運(yùn)營商在當(dāng)?shù)氐墓收显\斷[8]，討論內(nèi)容為自動化系統(tǒng)。實(shí)驗(yàn)開始執(zhí)行，其中運(yùn)營商通過接口在一個自動化的制造系統(tǒng)的不同的故障使用了三個層次的診斷。測試的目的是憑經(jīng)驗(yàn)評估三種類型的操作界面和暴露在一些常用的用戶接口低效率方面的弊端，促進(jìn)人們在故障診斷中的故障排除性能的任務(wù)。診斷故障所需要的時間，數(shù)量的信息在屏幕上觀看，執(zhí)行診斷測試的數(shù)量被確定為性能措施?；祀s變量的影響：接口的類型，故障的性質(zhì)和順序也被認(rèn)為是。 實(shí)驗(yàn)評價的有效性功能在故障診斷中摘錄的信息[11]是以設(shè)計(jì)為視覺信息顯示過程控制。改善人類解決問題的方法是考慮過程接口的目標(biāo)在核電廠故障診斷中。抽象的層次能力用以提高故障診斷的性能，通過實(shí)施增加三個層次的接口的功能測試。復(fù)雜度在診斷問題上的影響也要考慮。它被認(rèn)為是存在的信息和顯示類型的結(jié)合，產(chǎn)生最佳性能。建議有關(guān)整合的信息化水平的顯示類型是為了提高給定的顯示效果。 生態(tài)接口測試的能力的實(shí)證研究幫助診斷在石油化工流程[12]的故障為了專業(yè)運(yùn)營商在實(shí)際的工廠設(shè)置。三種類型的顯示接口：一個當(dāng)代使用兩個層次的生態(tài)接口（1傳統(tǒng)的和額外的基于任務(wù)的另一個增強(qiáng)信息）使用。它被認(rèn)為是生態(tài)界面與其他基于任務(wù)的信息，以在更大程度上方便了操作，排除故障和當(dāng)代接口的幫助。完成任務(wù)所花費(fèi)的時間，數(shù)量的控制操作，診斷的準(zhǔn)確性來確定性能得分。任務(wù)完成時間，數(shù)量較少的控制行動，更好地診斷準(zhǔn)確率被看作是一個有效的接口所需的特性。 在文獻(xiàn)[13]提出的兼容性的信息類型與診斷策略的實(shí)驗(yàn)研究。有關(guān)建設(shè)核電廠故障診斷輔助決策系統(tǒng)的應(yīng)用。實(shí)驗(yàn)采用四種不同類型的信息輔助工具，是代表共同運(yùn)營支持系統(tǒng)為核電廠，以確定什么樣的信息類型，在診斷過程中，為一個特定的策略是有效的，便于操作的診斷任務(wù)。結(jié)論作出的適用性的信息有助于運(yùn)營商策略和艾滋病的信息的有效性取決于采用的策略。 分層顯示對人類解決問題的性能的影響進(jìn)行了研究，在[14]中引入了計(jì)算機(jī)模擬邏輯電路的主題有不同程度的技術(shù)能力被診斷故障。它被認(rèn)為能力不足的診斷與主題，分層顯示界面更有助于，作為主管疑難排解同樣發(fā)現(xiàn)了兩種類型的接口兼容。因此，他們建立的接口的能力，以便診斷也依賴于用戶的技能。 SEMATECH [2]訂下的半導(dǎo)體制造業(yè)電子化診斷標(biāo)準(zhǔn)。根據(jù)SEMATECH，電子診斷功能可以描述內(nèi)的前四個等級（0-3），每一級的建設(shè)與增加的能力。根據(jù)多種因素綜合作用的混合水平數(shù)量的增加：支持任務(wù)的順序進(jìn)行，實(shí)施必要的基礎(chǔ)設(shè)施，執(zhí)行診斷任務(wù)，降低人的援助，并增加自動化的難易程度。0級開始基本的遠(yuǎn)程連接和遠(yuǎn)程協(xié)作，0級水平的基礎(chǔ)上，允許遠(yuǎn)程控制，監(jiān)測和存儲的操作和異常的數(shù)據(jù)。2級支持自動故障報(bào)警和歷史數(shù)據(jù)的處理，同時還包括1級水平的能力。3級是最先進(jìn)的架構(gòu)與功能，如自動決策支持，自我診斷預(yù)測性維護(hù)，等等。 在不同的層面代表能力的標(biāo)準(zhǔn)，多個遠(yuǎn)程診斷體系結(jié)構(gòu)提出了建議。在交換電子郵件，文本，音頻，視頻反饋，交換圖像和與當(dāng)?shù)剡\(yùn)營商的架構(gòu)通信有一些共同的特點(diǎn)，它們之間的區(qū)別在他們的遠(yuǎn)程診斷方法，如使用虛擬儀器和神經(jīng)網(wǎng)絡(luò)的感官數(shù)據(jù)基于網(wǎng)絡(luò)的診斷支持系統(tǒng)[4]，自動診斷和報(bào)警的診斷結(jié)果發(fā)送到手機(jī)或PDA設(shè)備的疑難解答[15]，協(xié)同診斷，使用一個集中的故障數(shù)據(jù)庫和診斷工具[16]，使用分層過程接口結(jié)合Petri網(wǎng)為基礎(chǔ)的系統(tǒng)模型[17]，并通過HTML接口，遠(yuǎn)程控制和報(bào)警的電子郵件從控制器[18]通過實(shí)時過程監(jiān)控狀態(tài)。 2.1 一般資料 - 需求 從文獻(xiàn)回顧，可以看出，很多以前的研究集中在實(shí)現(xiàn)遠(yuǎn)程故障診斷的各種方法。存在著不同級別的遠(yuǎn)程診斷體系結(jié)構(gòu)，支持不同類型的能力，總結(jié)了標(biāo)準(zhǔn)的遠(yuǎn)程診斷[2]。一些架構(gòu)將這些不同的自動化系統(tǒng)的能力做了很多工作，以確定離散制造系統(tǒng)中的故障發(fā)生的頻率[19]。實(shí)驗(yàn)評價因素，促進(jìn)人類在當(dāng)?shù)氐墓收显\斷任務(wù)中解決以前考慮到的不同類型的故障，包括接口類型，疑難排解和技術(shù)水平的工作。然而，如何在現(xiàn)有的架構(gòu)方便故障排除工具，討論在不同類型的故障診斷，自動化系統(tǒng)的遠(yuǎn)程診斷環(huán)境是有限的。先進(jìn)水平架構(gòu)的能力是否需要進(jìn)行測試，在失敗的疑難解答，專業(yè)知識和技能的操作者經(jīng)驗(yàn)的基礎(chǔ)上。 在遠(yuǎn)程診斷環(huán)境中，遠(yuǎn)程疑難排解在與本地操作員一起工作，以實(shí)現(xiàn)故障診斷。在這樣的一個交互式的設(shè)置，可能故障處理的性能受到本地操作員的技能的影響。故障診斷人員的能力，使用能力及診斷策略可能會有所不同，這取決于他們的能力水平。遠(yuǎn)程診斷體系結(jié)構(gòu)形成界面的自動化系統(tǒng)，遠(yuǎn)程疑難解答。任何遠(yuǎn)程診斷體系結(jié)構(gòu)的主要目的，是為了方便它的用戶，以確定診斷系統(tǒng)中的故障的根本原因。故障診斷人員的本地系統(tǒng)的操作的技術(shù)水平，故障性質(zhì)和疑難解答認(rèn)為在傳統(tǒng)的故障診斷能力上完全適用，對遠(yuǎn)程診斷環(huán)境作出貢獻(xiàn)。 因此，在本文中，使用三個水平的自動化系統(tǒng)的故障診斷不斷提高遠(yuǎn)程診斷架構(gòu)的不同類型的解決能力，強(qiáng)調(diào)由一個人使用這些架構(gòu)來進(jìn)行疑難解答。一個嘗試遠(yuǎn)程診斷體系結(jié)構(gòu)的能力，以協(xié)助不同的專業(yè)知識水平的人進(jìn)行疑難排解，通過比較三個不同層次的架構(gòu)，在另一種情況下的故障和運(yùn)營商的遠(yuǎn)程故障診斷性能與經(jīng)驗(yàn)評估。其結(jié)果是，它是可以了解的因素，會影響遠(yuǎn)程故障排除性能。 3.實(shí)驗(yàn) 3.1 診斷系統(tǒng) 該系統(tǒng)使用的是可重構(gòu)的雙機(jī)器人裝配系統(tǒng)[20]羅克韋爾自動化實(shí)驗(yàn)室如圖1所示。該裝配線由四個站組成。第一個是用于驗(yàn)證是否在規(guī)格范圍之內(nèi)的基臺部的檢查站。第二個是站3工作的緩沖站。站3和4是相同的裝配站，氣動，龍門式取放機(jī)器人組裝釘入洞的基礎(chǔ)部分。裝配線模仿組件的骨釘同步的插入孔中，在基座部分的載體和其行動是由PLC控制。 圖1 自動化流水線 3.2 實(shí)驗(yàn)?zāi)繕?biāo) 為了確定如何構(gòu)建遠(yuǎn)程診斷體系結(jié)構(gòu)，便于故障診斷人員進(jìn)行遠(yuǎn)程診斷和了解遠(yuǎn)程故障診斷性能的因素的影響，建立了以下目標(biāo)： 1、要建立一個模型，以評估排除故障和其他組合下的性能故障，操作和架構(gòu) 2、要診斷的故障排除性能、故障的性質(zhì)與遠(yuǎn)程診斷體系結(jié)構(gòu)的影響研究 3、與遠(yuǎn)程診斷體系結(jié)構(gòu)研究的影響比較，當(dāng)?shù)剡\(yùn)營商的技術(shù)能力上的表現(xiàn) 4、要比較的專家和新手疑難排解故障排除策略 3.3 實(shí)驗(yàn)變量 三個輸入（獨(dú)立）的變量被確定為：遠(yuǎn)程診斷架構(gòu)（X1），系統(tǒng)運(yùn)營商（X2），和自動化系統(tǒng)故障（X3）。從屬變量包括診斷失敗（A1）的搜索量（A2），診斷測試（A3）的數(shù)目，和質(zhì)量架構(gòu)（A4）所采取的時間。在本節(jié)將介紹這些變量的詳細(xì)描述。 3.3.1 遠(yuǎn)程診斷架構(gòu) 基于分類的電子化診斷能力[2] SEMATECH，三種架構(gòu)，代表不同層次的遠(yuǎn)程診斷功能的實(shí)現(xiàn)。架構(gòu)1采用0級與1級結(jié)合的能力。架構(gòu)2采用1級水平的能力。架構(gòu)3在1級的基礎(chǔ)上，并結(jié)合2級和3級的一定的能力水平。這三個架構(gòu)可以概括如下： 架構(gòu)-1 這種結(jié)構(gòu)具有的基本功能，實(shí)現(xiàn)遠(yuǎn)程連接和疑難解答和運(yùn)營商之間的合作。它的功能是類似的討論0級型的架構(gòu)[2]，其中包括視頻，語音傳輸，靜態(tài)圖像，文本通信，安全的文件傳輸。 架構(gòu)-2 它具有對在[2]中提出的等級1型架構(gòu)所討論的相似的功能。它包括1級架構(gòu)的所有功能，同時還通過一個圖形界面的運(yùn)行狀態(tài)的實(shí)時監(jiān)控。 架構(gòu)-3 這包括架構(gòu)-1和2的功能，以及一些額外2和3 [2]水平層次的功能，視頻播放，歷史事件記錄，以及遠(yuǎn)程桌面監(jiān)控界面。 3.3.2 系統(tǒng)運(yùn)營商 隨著當(dāng)?shù)剡\(yùn)營商的自動化系統(tǒng)，遠(yuǎn)程故障診斷基于PLC的系統(tǒng)環(huán)境方面，兩種情況下可以配置： 1、算子的低技術(shù)知識（新手）：這里指的情況是，在操作員僅僅是該系統(tǒng)的用戶和沒有技術(shù)的背景來理解的操作的系統(tǒng)，電氣，電子，或機(jī)械子系統(tǒng)。學(xué)生沒有一個PLC和自動化的過程。 2、操作員有足夠的技術(shù)知識（工程師）：這是指在運(yùn)營商的情況下所需的技術(shù)背景，了解系統(tǒng)的運(yùn)行，到網(wǎng)上去找PLC，學(xué)生采取了PLC和自動化的過程。 3.3.3 自動系統(tǒng)故障 制造系統(tǒng)的故障可分為硬件故障，產(chǎn)品故障，軟件故障[21]，任務(wù)故障[22]和容許誤差23]。這項(xiàng)研究將包括四個類型的故障：故障較低的機(jī)器人臂（硬件故障），故障關(guān)閉夾子（產(chǎn)品故障），插入故障（任務(wù)失?。?，和失敗的挑選（組合軟件故障和容許誤差）。引入實(shí)驗(yàn)系統(tǒng)的故障的細(xì)節(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