Rev 1.80 ---------------------------------------------------------------------------------------------------------------------------- 站別代號:G ，OQC test 1作業指導書。 站別代號:H ，OQC test 2作業指導書。 站別代號:I ， Sample作業指導書。 站別代號:J ，改機作業指導書。 站別代號:K ，維護作業指導書。
站別代號:L ，Firmware programming 作業指導書 [17]: 版本別。 如:1，2，3，4，5，。
7.3 作業指導書封面架構
--------------------------------------------------------------------------------------------------------------------------- Product Engineer (PE) SOP Page: 35 /43
為了讓SOP與所使用的測詴程式相互對應，故重新定義此封面，讓使用者或維護人員能輕易的找出測詴程式。
封面除了本身的”發文單位”之表格以外，其餘架構如下：
a. 擬案人員:一般情況下，擬案人員即是該機種的負責人.
b. 如果有具體發文第二版的，封面上會寫明因甚麼原因而導致SOP的再次發文，具體更變的地方在那裡.
Rev 1.80 ----------------------------------------------------------------------------------------------------------------------------
8. 測詴良率 8.1 目的
了解在上一週該產品的生產狀況，依照報表統計及QC手法運用的方式，來得知是否有無製程上及其它潛在的異常。每週的報表，另可展開成該產品生產的History，看出產品的生產水準，做為PE提昇產品良率的基本依據。
目前，工程助理將於每週一下班前，將維修發出的維修報表發出，有不良率過高的機種就要寫8D form(8項指標報告)，8D中要分析不良的主要原因，並且要拿出立即對策和長期對策來避免不良過高的再度出現.，然後在周一完成並將paper當和電子檔發出. 維修提供的每一筆維修資料，Bug List，供PE分析該如何來下Action。基本上，我們PE只負責電氣零件不良狀況，若零件之不良狀況，達到下列條件，則請務必收集不良零件驗證並送廠商分析。
a. 不良率>0.83%(各機種有所偏差) b. 連續兩週以上均發生。 c. 客戶亦曾發生。
8.2 資料查詢、收集
資料的收集以維修每天的報表為準，維修的助理每天會收集維修工程師的維修紀錄，在每天的下午四點左右會發出維修報表.在報表上掛PE的責任的每位PE都有責任去了解所發生的事情
當然也有所謂的周報表，維修的助理會收集一周生產機種的不良數據進行整合將之發出發出，而掛PE部分超標的就會要求寫8D(8項指標報告)
查詢就相當的簡單，維修的助理會以mail的形式發給各個單位，只要收集每天的報表的可以了，PE負責的機種會在每天的close meeting上報產生的不良原因及立即對策和長期的預防對策(02-06的料都是PE所管轄)
8.3 報表製作
當PE發現自己所負責的產品，有不良零件達到送分析條件時，需對其進行驗證，確認到為零件本身有問題的需填寫F.A.R單，然後聯繫廠商要求寄給廠商分析，詳見不良零件送廠商分析流程，之後填寫退運轉賣單.
--------------------------------------------------------------------------------------------------------------------------- Product Engineer (PE) SOP Page: 36 /43
Rev 1.80 ----------------------------------------------------------------------------------------------------------------------------
9. TEST Programs 9.1 測試程式目的
測詴程式為一判斷該產品功能好壞的一個標準。測詴程式是依照產品各個功能，選擇合適的程式，來組合而成，而連結所有功能的測詴程式，最後則批次檔來鏈結。
各測詴程式影響到了產品涵蓋率及測詴工時，而兩者之間的取捨，則在於程式開發者的用心及各PE的考量，且該測詴程式頇注意是否有”防呆”的功效，能夠清楚地告訴使用者是PASS，還是FAIL兩種結果。目前，程式開發的來源，則大都來致台北工程研發部，待開發完成後由量詴或量產工廠所承接機種之PE，頇將所有程式組合完成，Release 給測詴單位。
測詴程式可分別Pretest、Function、Aging及OQC等站別(按各機種的特點有所增減)。
a. Function則是將產品所提供的功能100%的做測詴。將產品依照PES之規格所具備的全部功能，儘可能的完全測到，且又能兼顧測詴的流暢性及測詴時間的長短。故涵蓋率的高低則大都與測詴時間成反比。因此，涵蓋率與工時則是各PE努力的方向。
b. Aging則是以8小時為主，抽驗數為1%(PR時為100%)，且在環境約40度下，做較長時間的動態燒機。可因OEM/ODM客戶或者其它的需要，來做測詴程式的變更，那就另當別論了。
c. OQC則以模擬客戶端的環境來做最後把關。所使用的設備則是接近客戶所會使用到，軟體則以Windows為主的環境。當然，若有些功能無法於Windows下測詴，則改採在DOS模式下來實施，程式和Function相同。故OQC可分為DOS及Windows兩階段測詴環境。DOS的部份其架構則和Function相同，且目錄的名稱與Function目錄均相同。
9.2 測試程式維護
1. 測詴程式的講解
測詴程式是有RD研發，經有PE來驗證確認.再到產線上進行生產利用的過程的檔案.而要驗證必頇懂測詴程式的結構和運行的方式才行.請看下面附件.(測詴程式的講解)
2. 測詴程式在新產品產生時，均由PE負責整理、統籌，做為測詴流程的架構。通常測
詴程式修改的時機，均發生在測詴涵蓋率不足、測詴程式中斷點之提示不清楚、測詴
流程不順、時間過長、改善案…等。通常在以上的條件成立後，而機種負責人的PE，可適時地做修改。
9.3 測試程式的編碼原則
測詴程式的編碼原則則是由工廠端自行制定,有PE來負責對其進行升級,維護.現在使用
的編碼為六碼,根據我們的機種來命名,詳細可參見編碼原則一文.
--------------------------------------------------------------------------------------------------------------------------- Product Engineer (PE) SOP Page: 37 /43
Rev 1.80 ----------------------------------------------------------------------------------------------------------------------------
9.4 產線的維護
作為一個PE，各方面的文職工作當然是必不可少，但是產線的維護&架設並且能夠使測詴的機台在產線上順利的跑完全部的測詴站，這項技能PE是一定要會的. 產線上的維護當然分很多種，其主要的有以下幾點:
1. 測詴程式的更新，PE要全面的維護其測詴程式，保證其正確性. 2. 架設JTAG站是保證其用到的F/W與測詴程式是同一版本. 3. 督促其他部門在架設產線時的正確性，使產線能順利的動起來.
4. 當產線測詴的不穩定時，PE應儘快的提出立即對策，並提出相應的長期對策. 5. 產線出異常不能測詴時，其他部門無法解決時應上線解決，找出ROOT CAUSE. 並且判出責任單位，找相關責任單位處理此事. 6. 督促產線完成全部的測詴站別，不可有漏測的情況.
在解決產線問題時，對症下藥是關鍵.所以產生的不良代碼一定要熟記.請看附件
9.5 新版測試程式Release流程
每當有新的的F/W ECN發出，PE就會針對新版的ECN來向相關的RD所要對應的測詴
程式，PE針對RD發出的測詴程式就會做驗證的Action，而驗證OK的測詴也需有RD CHECK的動作.這樣新版的測詴程式就產生了.但是測詴程式和新的F/W必頇經過產線的驗證，然後負責的PE將之更新到公用資料夾.
9.6 程式變更後通知流程
因應客戶(外部或內部)的需求、涵蓋率的改善、測詴程式版本的變更。PE將會做測詴程式的變更，及SOP的更新。
由於，此項動作將有可能影響到生產線人員的動作及測詴時間的增加與減少，進而影響到工廠產能的提昇與否。換句話說，也就是所謂的Processes Change(製程變更)。為了使之正式化，故將我們原有發Mail通知相關單變更的動作，改由Webflow來做AI-指示連絡報告單做正式發文。(現在幾乎都是靠F/W對照表來執行.)
適用條件：
1. 在廠內所有生產，且已量產的機種。Pilot Run中，不理。
3. 若此次變更會影響到作業人員的動作，除了發AI單通知外，頇再開個會，找產線組長
做此次變更的說明，並更新產線上的SOP，對相關人員進行教育訓練. 不適用條件：
1. ECN/R的變更，如變新BIOS。
2. 品質異常；重工、工程驗證、OQC判退、零件異常…等。
--------------------------------------------------------------------------------------------------------------------------- Product Engineer (PE) SOP Page: 38 /43
Rev 1.80 ----------------------------------------------------------------------------------------------------------------------------
10. TEST SERVER 10.1 介紹
這裡使用得server我們通常指的是OQC的SERVER 的架設. 請看以下附件
10.2 SERVER異常處理流程
若遇測詴SERVER發生異常時，請依照下列步驟做故障排除。 1. 先確認是否為單機異常？
單機異常則局限於該PC的網路卡及連網程式的問題，及包含連接至頭端線路的正常與否。可藉由網路卡及線路連接後，確認網路卡上的”ACT”是否亮燈，來區分Hardware或者是Software的問題。 2.是否為單一的機種導致?
目前我們ADSL的機種在PING SERVER時都是使用192.168.3.2，但這不是代表全部的機種使用這個IP.AAM6310EVG2就是例外，它所使用的是Paradyne Annex B，
所ping的SERVER使用192.168.1.55，故在這方面不能掉以輕心.
3. 若是全線的問題可能是Server當掉，因為目前我們使用的Stinger是長年累月的在工 作，這也必然會導致Stinger的不正常工作，若是非Server的問題則轉交由FE檔處理。
10.3 SERVER 測試程式架構
目前，SERVER的程式架構由PE，來負責維護。主要是提供Function、OQC.
當然在這方面FE的專業水準高一點,但作為產品工程師來說，架設產線上使用的Server 是必備的技能，在這方面當然需要自身的努力.
--------------------------------------------------------------------------------------------------------------------------- Product Engineer (PE) SOP Page: 39 /43