第一篇：一個硬件工程師做完又一個FPGA項目后的感言

一個硬件工程師做完又一個FPGA項目后的感言

做了5年的FPGA了。手中經歷的項目也不在少數。就在此刻又一個FPGA項目宣告結題，好多感受趁著現在還新鮮著，寫出來和大家一起分享。不對之處，希望得到大家的指正。另外1234并沒有絕對順序，都是有感而發，隨性而寫。

1.要和人配合。以我們做硬件的工程師為例，測試的時候一般都需要軟件的配合，一個對硬件來說無比復雜的工作，可能在軟件工程師看來就是幾行簡單的代碼。所以要和人配合，多聽聽別人的意見，這樣必然可以產生新的 know-how 從而加快測試和開發的速度，退一步講，至少沒有壞處。

2.測試還是要別人來做。開發者看待自己的產品有如看待自己，大多是沒有勇氣去發現缺點的。一是源自自尊心，二是為了避免額外的工作。所以就算有問題，如果不嚴重就藏著掖著。但是這對項目來說是不行的，所以測試，verification，一定要旁人來做。

3.多點時間思考。出現問題后，不要急著修改。要思考推測可能的原因，想清楚后把這些可能的原因都用debug pin或者chipscope引出來。

4.注意復用已有的debug pin。很多時候，在測試過程中產生了一大堆測試信號，但是時間一長就忘了復用。實際上，當一個問題產生的時候，通過反復觀察已有的debug-pin或許足以發現問題根源，而無需再引出新的pin，并浪費時間去綜合和PAR。

5.仿真加時序足矣。數字電路在時鐘同步的設計原則下，其功能通過simulation就可以驗證。simulation的結果和PAR后產生的FPGA-image完全等價。當然FPGA也要遵循同樣的設計原則：即時鐘同步。所以對于PAR的結果首先就要確保其時鐘同步的特性。體現為寄存器之間的path必須在一個時鐘周期內完成。（當然有其他約束的例外。）同時要滿足FPGA器件的setup和hold要求。一旦出現timing-error必須通過各種途徑消除error，因為error的存在，意味著時鐘同步的大前提已經被破壞，這時，simulation取得的結果和FPGA是不等價的，繼續測試也毫無意義了。

6.注意不可控的接口部分。FPGA內部的寄存器之間的timing完全可以通過PAR報告來確認是否有問題。但是和外界的接口部分卻充滿了疑問。我們一般通過假定的input-delay和output-delay來對接口部分進行約束。由于從一開始就施加的是假定的delay，所以即使沒有timing-error，其結果也存在諸多疑問。以我正在進行的測試為例，模塊內部loopback測試完全正常，但是一過cable，傳到對方FPGA，則馬上產生很多誤碼。由于simulation沒有問題，所以必然是我們的某個假定出現了問題，尤其是時鐘同步的假定會得不到滿足。這時候，就要想盡一切辦法，使接口也滿足假定的條件，或者調整設計，將不理想的接口adapting成理想的接口。

7.向直接上司匯報情況，尋求各種可能的許可。懶得向直接上司匯報情況時，萬一出現進度或者結果不符，所有責任都需要本人承擔。如果提前向上司匯報情況并取得許可，則一切后果都在可控范圍內。比如，工作繁忙時又被派給新的任務，則不能一味逆來順受。應該向上司說明困難，并提前想好一個可行的解決方案供上司參考。

8.外部接口是最大障礙。如前所述，FPGA內部如果timing沒有問題的話，一般和仿真結果是一致的，問題是外部的接口，包括cable連線等，不在我們確切控制的范圍內，比如其延時特性在40Mhz下仍然正常，但是在80Mhz時可能出現不可預料的情況。所以應該盡量使用經過驗證的“cable--frequency”組合?；蛘咄ㄟ^設備測量并確認外部接口的延時特性。這樣可以進行有針對性的調整。我最近的教訓就是花了整整一個月調整并測試內部的結構，但是仍然失敗。結果發現由于cable的問題，80Mhz的信號（數據+使能+others）無法正常并行傳輸。如果換成40Mhz的信號就通過了。

9.綜合PR后的結果要和代碼等價。前面提到仿真加時序足矣，這里面的前提是PR的結果和原始代碼要等價。為了確認這一點，就要把握syn和pr過程中的所有warning以及error，warning的內容不是完全可以忽略的。要特別關注綜合報表中的以下內容：unused ports, removal of redundant logic, latch inference，simulation mismatch等等。在報表中輸入關鍵字查找即可。

第二篇：一個硬件工程師做完又一個FPGA項目后的感言

做了5年的FPGA了。手中經歷的項目也不在少數。就在此刻又一個FPGA項目宣告結題，好多感受趁著現在還新鮮著，寫出來和大家一起分享。不對之處，希望得到大家的指正。另外1234并沒有絕對順序，都是有感而發，隨性而寫。

1.要和人配合。以我們做硬件的工程師為例，測試的時候一般都需要軟件的配合，一個對硬件來說無比復雜的工作，可能在軟件工程師看來就是幾行簡單的代碼。所以要和人配合，多聽聽別人的意見，這樣必然可以產生新的 know-how 從而加快測試和開發的速度，退一步講，至少沒有壞處。

2.測試還是要別人來做。開發者看待自己的產品有如看待自己，大多是沒有勇氣去發現缺點的。一是源自自尊心，二是為了避免額外的工作。所以就算有問題，如果不嚴重就藏著掖著。但是這對項目來說是不行的，所以測試，verification，一定要旁人來做。

3.多點時間思考。出現問題后，不要急著修改。要思考推測可能的原因，想清楚后把這些可能的原因都用debug pin或者chipscope引出來。4.注意復用已有的debug pin。很多時候，在測試過程中產生了一大堆測試信號，但是時間一長就忘了復用。實際上，當一個問題產生的時候，通過反復觀察已有的debug-pin或許足以發現問題根源，而無需再引出新的pin，并浪費時間去綜合和PAR。

5.仿真加時序足矣。數字電路在時鐘同步的設計原則下，其功能通過simulation就可以驗證。simulation的結果和PAR后產生的FPGA-image完全等價。當然FPGA也要遵循同樣的設計原則：即時鐘同步。所以對于PAR的結果首先就要確保其時鐘同步的特性。體現為寄存器之間的path必須在一個時鐘周期內完成。（當然有其他約束的例外。）同時要滿足FPGA器件的setup和hold要求。一旦出現timing-error必須通過各種途徑消除error，因為error的存在，意味著時鐘同步的大前提已經被破壞，這時，simulation取得的結果和FPGA是不等價的，繼續測試也毫無意義了。6.注意不可控的接口部分。FPGA內部的寄存器之間的timing完全可以通過PAR報告來確認是否有問題。但是和外界的接口部分卻充滿了疑問。我們一般通過假定的input-delay和output-delay來對接口部分進行約束。由于從一開始就施加的是假定的delay，所以即使沒有timing-error，其結果也存在諸多疑問。以我正在進行的測試為例，模塊內部loopback測試完全正常，但是一過cable，傳到對方FPGA，則馬上產生很多誤碼。由于simulation沒有問題，所以必然是我們的某個假定出現了問題，尤其是時鐘同步的假定會得不到滿足。這時候，就要想盡一切辦法，使接口也滿足假定的條件，或者調整設計，將不理想的接口adapting成理想的接口。

7.向直接上司匯報情況，尋求各種可能的許可。懶得向直接上司匯報情況時，萬一出現進度或者結果不符，所有責任都需要本人承擔。如果提前向上司匯報情況并取得許可，則一切后果都在可控范圍內。比如，工作繁忙時又被派給新的任務，則不能一味逆來順受。應該向上司說明困難，并提前想好一個可行的解決方案供上司參考。

8.外部接口是最大障礙。如前所述，FPGA內部如果timing沒有問題的話，一般和仿真結果是一致的，問題是外部的接口，包括cable連線等，不在我們確切控制的范圍內，比如其延時特性在40Mhz下仍然正常，但是在80Mhz時可能出現不可預料的情況。所以應該盡量使用經過驗證的“cable--frequency”組合。或者通過設備測量并確認外部接口的延時特性。這樣可以進行有針對性的調整。我最近的教訓就是花了整整一個月調整并測試內部的結構，但是仍然失敗。結果發現由于cable的問題，80Mhz的信號（數據+使能+others）無法正常并行傳輸。如果換成40Mhz的信號就通過了。9.綜合PR后的結果要和代碼等價。前面提到仿真加時序足矣，這里面的前提是PR的結果和原始代碼要等價。為了確認這一點，就要把握syn和pr過程中的所有warning以及error，warning的內容不是完全可以忽略的。要特別關注綜合報表中的以下內容：unused ports, removal of redundant logic, latch inference，simulation mismatch等等。在報表中輸入關鍵字查找即可。

第三篇：一個ERP項目實施工程師的若干體會

本人在多年的工作中，參與了ERP的研發和實施，對ERP有較深的認識。在這里，根據自已的實施過程中的一些經歷，把自已在實踐中的一些體會貢獻出來和大家共享，由于時間和精力所限，內容難免有不當之處，掛一漏萬，僅供參考。

國外關于ERP實施的階段劃分是有道理的，只有在這每一個階段的工作都做好了，才能保證ERP的實施成功。現在我就結合這個程序來分析一下ERP實施。

1.領導培訓

ERP系統被視為一把手工程，對企業高層的領導的培訓是一項目十分重要的工作。而實際情況是如何做的呢？企業領導一般工作比較繁忙，實施企業也出于成本考慮，相應培訓普遍偏少，對ERP的理念作的導入工作不足，往往影響實施效果。培訓目的是讓他們形成共識，理解為什么ERP系統是管理改造項目，離不開高層領導的支持；另外一個目的就是讓他們對ERP系統有一個正確的預期。如果，不對高層領導進行培訓，他們對系統的認識不清，他們會認為系統不就是一個軟件嗎？沒有必要投入那么多的錢。

2.需求分析

一定要確定好用戶的最終需求。在有的項目，我們認為具體的業務流程我們已經很熟悉了，固然沒有什么具體協商的。但是到了最后使用的時候，我們就發現我們還是對其詳細操作沒有搞清楚，我知道的業務流程僅僅是一個大體上的概念，對于細節的業務我并不清楚，這個問題是我后來在項目延期的主要因素。

確定用戶的最終的需求，根據用戶的需求編制一定的界面，然后根據編制的界面和用戶進行核對，以保證我們表達的和用戶需求的相一致。如果不一致，重新修改我們的界面。

根據和用戶討論關于操作問題，這個階段就是搞清楚用戶的視圖，讓最終用戶直接參與項目的開發，當然他們的作用是提供一些參考改進的意見，這些意見是針對最終用戶的操作，目的是讓操作更加貼近用戶。

3.BPR

在項目的實施過程中，企業管理流程的重組工作往往是最難的。我認為在國企要對企業業務流程作根本性的重組幾乎是不可能的，但一點改進都沒有而要成功地實施ERP同樣幾

乎不可能，實施人員提出過對企業工作流程進行改進的建議，往往泥牛入海，沓無消息。只能根據企業重點控制環節，盡可能多做些改進工作。

4.項目組織

一般要成立了三級項目組織，企業一把手出任領導小組組長，核心小組、各部門項目組也有相應負責人出任組長。業務問題要在項目組織的會上就能解決，切不可流于形式，讓用戶以工作忙為借口，不參加工作。

5.實施計劃

由于ERP涉及面大，計劃的組織工作極為繁重，頭緒極多。項目開始時，不可輕易承諾項目何時完成,一方面，項目剛啟動時，項目的實施范圍通常還比較模糊和抽象、不是很具體。只有等到需求調研以后項目實施范圍才會逐步具體化，即使到這時，項目范圍還存在隨著項目進展發生改變的可能性。

另一方面，如果對客戶承諾了一個固定不變最終期限，如果在調研時客戶發現需求和設想有很大不同，比最初項目評估時要復雜的多，因為完成日期已經無法更改，這樣造成的后果是項目組成員需要投入更多的時間或者匆忙之下只能提交一份不令人滿意的解決方案。

因此，項目經理必須和客戶溝通，使客戶明白，項目完成日期的確定取決于兩個因素：一是需求調研完成以后，雙方共同確認的項目實施范圍；二是要考慮到項目所需資源約束。這樣如果以后項目范圍明顯地超過最初確定的范圍，項目經理就需要和客戶討論，要么讓客戶縮小項目范圍，要么延遲項目完成日期。

在ERP項目實施中，必須制定明確的里程碑，以及每個里程碑應取得的成果。項目經理在項目的開始，就需要讓項目組所有成員知道各個階段的里程碑和目標，以及進度的安排、資源的大體上的分配，就好讓項目組的所有成員參與討論，但項目經理應控制談論的范圍，需要避免在項目初期在實施上的分歧。

大型ERP項目的實施往往時間很長，這樣項目剛開始，項目組成員有一種錯覺，認為時間還很充足。所以必須對里程碑進一步細分，制定短期的實施目標，讓項目組成員時刻保持高效的工作狀態，如果這些小的目標都能按時完成，那么整個項目按期完成就有了保證。

ERP項目實施時間長，對實施者和客戶來說，成功似乎遙遙無期。如果將目標進行分

解，讓實施者和客戶都感覺到一段時間就實現了一個目標，可以激發項目團隊和客戶的積極性。

6.培訓工作

對于用戶，其關鍵用戶和最終用戶的培訓是不同的，但先培訓關鍵用戶，再由關鍵用戶去培訓最終用戶，這樣是有好處的如：

語言上不存在障礙，同樣一個流程或操作，最終用戶一般更容易接受關鍵用戶概念，而我們的概念往往是不能被最終用戶直接接受的，這里面有行業術語上的障礙，在我們表達上基本上是計算機的術語，而用戶所能接受的是他們行業上的術語。

更容易組織，由于我們是外部人事，對于他們我們基本上沒有什么威懾力，如果有也僅僅是在技術上的敬佩，所以對于企業的協調能力或方式，不能見效，其內容也往往流于形式。

(3)自然培養企業內部技術支持路徑，而比直接詢問我們有更好的效果，這樣也會在我們的市場推廣上有較為“陽光”的一面(就是在向其他用戶推廣時采用用戶本身直接介紹的方式)。同時其最終用戶在詢問關鍵用戶問題時，自己也會很好的考慮。(4)鍛煉關鍵用戶，讓關鍵用戶在培訓別人上對本系統有認識上的提高。

7.數據準備

數據準備的重要性無庸贅言，要各種場合反復強調了基礎數據的重要性，并要求企業采取切實的措施來保證這一點。

在準備數據之前，成員要準備一份“數據準備文檔”，在該文檔中要明確如下內容：數據準備時間，范圍。即何時完成，準備何時的數據，準備哪些數據。

明確雙方責任。我們一般要求客戶來準備基礎數據，并保證數據的完整性、正確性(實際也只有客戶自己才能做完后，才知道數據的真確與否，一定要盯牢客戶完成數據的測試)；項目組只提供數據準備的要求、格式。

數據準備的要求。客戶必須按照項目組要求的格式來準備，這一點非常重要，很有好處：

(1)可以保證數據的完整一致。比如說，要準備供應商資料，我們在Excel中準備好空

白如下表格。針對這個信息我們提供的一個更加詳細的說明方式，讓其自由填寫。但以上表格中的數據是必須填寫的。這樣每個準備供應商信息的人，都知道供應商資料應該包括：供應商名稱、編號、地址、稅號/帳號、聯系人等。

(2)方便核對數據。一旦在Excel中準備好數據，并核對無誤后，就需要輸入系統，輸完以后，再用系統生成并打印報表(但我們沒有這樣做，我們自己準備一個數據庫，在瀏覽器的界面，讓客戶自己直接在瀏覽器的界面填寫，然后提交到數據，這樣就減少了打印重新填寫或導入的步驟，比如，對上述供應商資料，我們可以從系統輸出一份報表，去和原始的數據核對，看看在輸入過程中是否出錯即可)。

(3)如果基礎數據量很大，一般就需要開發專門的數據轉換程序，這樣更需要按一定格式準備數據，否則，數據轉換程序不會正常工作。如果企業本身沒有其他系統(現在一般企業都沒有)，即可讓其直接進行輸入。

在實際工作，很多客戶一開始感到不理解，認為沒有必要一定按照某種格式準備，作為成員一定要和客戶溝通，解釋重要性。

8.二次開發

在市場經濟的調節下，組織變動在公司中是司空見怪的，如果在項目過程中發生的話，其項目內容(人員、系統設置和數據)也必須跟隨著變化，這個變化是很糟糕的。如果變化是頻繁的，所以程序結構和維護流程不停的變更，有時會導致系統實施無期限。

ERP設計本身應是靈活的，對于企業結構有一定的適應力，當然在項目中也應該控制企業的變動。這個問題需要分兩方面來看，首先，ERP系統立意要高，要高到和公司組織結構規劃一致(當然對于企業本身也應該考慮企業重組的問題)。其次，就象人在適應社會的變化以前會經歷襁褓期，但我們也該注意在ERP實施的襁褓期減少不必要的震蕩，使項目成功完成。

9.系統正常運行

上述工作均完成后，我們的系統就是要正式運行了。

1.驗證設置是否正確。比如各種基礎數據輸入后，經檢查，均正確無誤，但系統生成結果就是不正確。這種情況下，我們就需要檢查是否是設置問題。諸如此類的問題很多，需要

一一驗證。

2.制訂各種業務規則。上了系統之后，許多新的業務流程和企業原有的業務流程不同，而最終用戶往往習慣了以前的做法，短期內可能不適應。為了確保系統真正用起來，必須做好以下幾點：

(1)做好培訓工作。培訓系統的操作和系統的業務流程。

(2)制訂詳細的業務規則，規定企業各種業務在系統中是如何處理的。并讓每位相關的最終用戶知道、理解。

(3)制訂必要的制度，確保按規定操作，特別是在使用系統初期，完善制度尤為重要。

第四篇：一個老工程師做PLC項目心得體會

一、做一個PLC項目的大體流程如下：

1、熟悉好現場環境和工藝流程

2、設計出安全可靠的控制方案

3、畫出電氣控制原理圖

4、確定好材料，制作材料物資明細表

5、編寫PLC程序，組態監控畫面，設計PLC 機柜接線圖，并同時制作PLC機柜

6、溝通甲方，現場施工

7、現場調試，并完善工藝控制方案。

8、組織甲方驗收項目

9、交接竣工資料。（資料包含：圖紙，調試文檔，PLC程序以及上位機程序）

二、可編程控制器 設計原則

1.最大限度的滿足被控對象提出的各項性能指標

為明確控制任務和控制系統應有的功能，設計人員在進行設計前，就應深入現場進行調查研究，搜集資料，與機械部分的設計人員和實際操作人員密切配合，共同擬定電氣控制方案，以便協同解決在設計過程中出現的各種問題。

2.確保控制系統的安全可靠

電氣控制系統的可靠性就是生命線，不能安全可靠工作的電氣控制系統，是不可能長期投入生產運行的。尤其是在以提高產品數量和質量，保證生產安全為目標的應用場合，必須將可靠性放在首位，甚至構成冗余控制系統

3.力求控制系統簡單

在能夠滿足控制要求和保證可靠工作的前提下，應力求控制系統構成簡單。只有構成簡單的控制系統才具有經濟性、實用性的特點，才能做到使用方便和維護容易。

4.留有適當的裕量

考慮到生產規模的擴大，生產工藝的改進，控制任務的增加，以及維護方便的需要，要充分利用可編程控制器易于擴充的特點，在選擇PLC的容量(包括存儲器的容量、機架插槽數、Ｉ／Ｏ點的數量等)時，應留有適當的裕量。一般工程的冗余量為總點數的20%。

三、PLC設計的基本步驟

在進行可編程控制器控制系統設計，盡管有著不同的被控對象和設計任務，設計內容可能涉及諸多方面，又需要和大量的現場輸入、輸出設備相連接，但是基本內容應包括以下幾個方面：

1.明確設計任務和技術條件

設計任務和技術條件一般以設計任務書的方式給出，在設計任務書中，應明確各項設計要求、約束條件及控制方式。因此，設計任務書是整個系統設計的依據。

2.確定用戶輸入設備和輸出設備

用戶的輸入、輸出設備是構成PLC控制系統中，除了作為控制器的PLC本身以外的硬件設備，是進行機型選擇和軟件設計的依據。因此，要明確輸入設備的類型(如控制按鈕、行程開關、操作開關、檢測元件、保護器件、傳感器等)和數量，輸出設備的類型(如信號燈、接觸器、繼電器等執行元件)和數量，以及由輸出設備驅動的負載(如電動機、電磁閥等)。并進行分類、匯總。

3．選擇可編程控制器的機型

可編程控制器是整個控制系統的核心部件，正確、合理的選擇機型對于保證整個系統的技術經濟性能指標起著重要的作用。

PLC的選型應包括機型的選擇、存儲器容量的選擇、Ｉ／Ｏ模板的選擇等

4．分配Ｉ／Ｏ地址，繪制Ｉ／Ｏ接線圖

通過對用戶輸入、輸出設備的分析、分類和整理，進行相應的Ｉ／Ｏ地址分配，并據此繪制Ｉ／Ｏ接線圖。

至此，基本完成了PLC控制系統的硬件設計

5．設計控制程序

根據控制任務和所選擇的機型以及Ｉ／Ｏ接線圖，一般采用梯形圖語言設計系統的控制程序。設計控制程序就是設計應用軟件，這對于保證整個系統安全可靠的運行至關重要，必須經過反復調試，使之滿足控制要求。

6．必要時設計非標準設備

在進行設備選型時，應盡量選用標準設備。如無標準設備可選，還可能需要設計操作臺、控制柜、模擬顯示屏等非標準設備。

7．編制控制系統的技術文件

在設計任務完成后，要編制系統的技術文件。技術文件一般應包括設計說明書、使用說明書、Ｉ／Ｏ接線圖和控制程序(如梯形圖等)。

四、PLC的選型

選擇適當型號的PLC機是設計中至關重要的一步。目前，國內外PLC生產廠家生產的PLC品種已達數百個，其性能各有特點，價格也不盡相同。所以，在設計時，首先要根據機型統一的原則來考慮，盡可能考慮采用與本企業正在使用的同系列的PLC機，以便于學習、掌握、維護的方便性，備品配件的通用性，且可減少編程器的投資。在此基礎上還要充分考慮下面因素，以便選擇最佳型號的PLC機：

1． I／Ｏ設備的數量和性質

在選擇PLC時，首先應對系統要求的輸入、輸出有詳細的了解，即輸入量有多少，輸出量有多少，哪些是開關(或數字)量，哪些是模擬量，對于數字型輸出量還應了解負載的性質，以選擇合適的輸出形式(繼電器型、晶體管型、雙向可控硅型)。在確定了PLC機的控制規模后，還要考慮一定的余量，以適應工藝流程的變動及系統功能的擴充，一般可按10～15％的余量來考慮。另外，還要考慮PLC的結構，從Ｉ／Ｏ點數的搭配上加以分析，決定選擇整體式還是模塊式的PLC。

在確定了PLC的輸入量和輸出量的點數及性質后，就可以進一步確定各種Ｉ／Ｏ模板的型號和數量。開關量Ｉ／Ｏ模板的規格標準有4、8、16、32、64點，點數多的模板，每點平均價格相對較低。對開關量Ｉ／Ｏ模板的外部接線方式可分為隔離式和匯點式，隔離式的每點平均價格較高。如果信號之間不需要隔離，應選用匯點式的Ｉ／Ｏ模板。在整體式PLC機中，各個Ｉ／Ｏ端子也有隔離式和匯點式之分，以滿足不同電壓等級的輸入／輸出器件的需要。

2．PLC的功能

要根據該系統的控制過程和控制規律，確定PLC機應具有的功能。各個系列不同規格的PLC機所具有的功能并不完全相同。如有些小型PLC只有開關量的邏輯控制功能，而不具備數據處理和模擬量處理功能。當某個系統還要求進行位置控制、溫度控制、PID控制等閉環控制時，應考慮采用模板式PLC，并選擇相應的特殊功能的Ｉ／Ｏ模塊，否則這些算法都用PLC的梯形圖設計，一方面編程困難，另一方面也占用了大量的程序空間。

另外，還應考慮PLC的運算速度，特別是當使用模擬量控制和高速計數器等功能時，應弄清PLC機的最高工作頻率是否滿足要求。

3． 用戶程序存儲器的容量

合理確定PLC的用戶程序存儲器的容量，是PLC應用設計及選型中不可缺少的環節。一般說來，用戶程序存儲器的內存容量與內存利用率、開關量Ｉ／Ｏ總數、模擬量Ｉ／Ｏ點數及設計者的編程水平有關。

簡單的估算公式

內存字數＝(開關量Ｉ／Ｏ總點數＋模擬量Ｉ／Ｏ點數 X 16)X 10

式中：每個模擬量通道(或Ｉ／Ｏ點)相當16個開關量Ｉ／Ｏ點。在此基礎上，可考慮留有20～25％的裕量。對于工藝比較復雜的系統，應適當增加存儲器的容量，否則，當控制較復雜、數據處理量大時，可能出現存儲器容量不夠的問題。

第五篇：一個優秀的項目工程師應具備的能力

一個優秀的項目工程師應具備的能力

一、軟件應用的水平及作用

速成的教學重點并不是軟件怎么使用，是用軟件搞定設計。在速成的每一個學員首先必須精通軟件。很多人都說軟件學習很簡單，只要看看書和視頻就行了，這就大錯特錯了。在書上只是學習命令和零件建模，離實際工廠中的應用相差很多，在書上視頻上學的再好，到工廠的設計模式和軟件應用是不一樣的。因為到工廠后并不是讓你拿個零件畫畫就是設計了，設計首先要根據客戶需求制定設計技術方案，后期就是設計方案和設計3D,沒有接觸過各種類型的設計項目案例，你是做不了設計的。軟件只是工程師用于表達設計的工具而已。但是想精通軟件的使用也不容易，速成將軟件應用分為以下5個層次： 速成軟件應用的5個層次

在產品設計的門檻中，UG等三維 軟件的應用是最難跨越的，因為只要精通三維軟件后，后面的技術經驗，是隨著時間的流逝，自然完成的過程，但是三維設計軟件的水平就差別很大了，在產品開發過程中，首先要完成設計，然后才能進行產品開發，若軟件都不精通，根本無法完成設計，當然軟件是設計師最基本也是最重要的技能之一。速成培訓將三維設計軟件的應用分為以下5個層次，所有學員畢業后必須要掌握的：

1、初級水平-------復雜實體建模和中等復雜曲面產品的設計

2、中級水平---------復雜曲面產品設計

3、高級水平----------具備面的高級處理技巧 和多次處理技巧

4、頂級水平-----------對于上百個步驟的產品設計，可以隨時隨地對任何一個特征做調整，調整產品在設計過程中很重要，往往找問題，解決問題比重新設計更難，它不光要求技術好，更重要的還要心態好。

5、精湛水平----------具備以上技能的同時，可以做數模的非參設計，在產品設計中，尤其在工廠，非參設計很常見，也很難，只會參數設計，往往很難完成產品設計，有的產品是參數設計與非參數設計并用才能完成。

只要具備以上技能，那么在產品設計的過程中，你就不會被軟件的應用而停止不前了。只要對產品做深入的了解后，你就你能很快的成熟起來了。

二、精通軟件離設計還很遠

精通軟件離產品設計和模具設計還很遠，設計需要大量的項目案例訓練，才能讓你在設計過程中全面檢討設計，速成將設計分為10大板塊，每一個大板塊里面包括許多小板塊，具體如下：

檢討產品設計：怎樣查看截面圖和編輯產品顏色，這個在工作中也是經常遇到，主要用于檢查部件之間是否有干涉和間隙大小及內部空間尺寸。開模之前要細心檢討設計數據，速成將檢討內容分為10大塊，分別從定位、公差、裝配、運動、功能、模具、試驗、工藝、實際使用狀態和客戶特殊需求等幾個大板塊全面考慮，以確保產品設計的合理性。這些理論均來自蘭工10年產品設計和模具設計提升出來的理論，不是單純的從書上抄過來，只有在大量實戰經驗中總結出來的經驗，再用

于指導實戰才能成功。

三、設計離開發相差很遠

即使設計成熟了，離開發還有很大距離，因為設計是理想化的，開發是實實在在做出來的，只有經驗豐富的工程師，提前就可以預料到后期產品開發出來后會存在哪些風險，所以經驗豐富的工程師在設計早期就已經有了后期整改的方案了，只有這樣才能確保開發成功。這些都可以直接傳授給學員，無需再經過多年的努力獲得。若沒有豐富經驗的人教，沒有完整典型的課程訓練，一個人光憑自學根本無法跨過設計的門檻。就算你很努力自學3年，也比不上速成學習1個月的學員。

四、學會項目管理和運作

一個工程師是否成熟的標志就是看項目管理和運作的能力如何 這是最健也是最值錢的，這個能力不是兩三年就能獲得的，需要大量項目

開發經驗。它需要很多附帶的能力，才能完整的搞定一個項目的開發。前提需要很好的設計能力（包括軟件應用）、技術經驗、熟悉自己的產品、溝通能力、語言表達能力、談判能力、團隊管理能力、為人處事能力、業務能力、處理客戶需求的能力等相關能力，所以一個優秀的項目工程師和項目經理的成長與一般的崗位相比要求高多了。但是這些誰天生都不會也不是短期內可以培養出來的，是后天慢慢鍛煉的。所以很多企業不愿意花費幾年的時間去培養一個項目工程師，即使培養成功了，很快就被同行挖走了。

以上希望能給想 從事設計的朋友的啟示，讓你們更多了解設計這個崗位以及一個項目工程師應該具備的能力和培養周期。越容易培養的崗位越容易被替代，也就越不值錢，但是開發工程師都企業的寶貝，每一項目工程師的離職都讓企業心痛。