第一篇：控制器市場分析

控制器市場分析

控制器作為電動車的主要的關鍵零部件，他們之間是完全互補品的關系，電動車控制器的需求不僅僅來自于新增產能的零配件市場，同時也有來自與維修市場，根據慣例，電動車控制器在維修市場的需求大概為存量的5%-10%。因此總的市場需求量考慮到電動車的使用壽命，進入維修市場的電動車的存量應該為前五年市場銷量之和5%-10%。基于以下幾點我國的自動控制器的裝配自行車年均增長10%。

1、根據我國2010年的產業政策規劃，本年度將出臺相關的行業政策和行業標準，政策逐步明朗。

2、我國在2010年將電動自行車列為了家電鄉下的補貼電器之一。因此此舉將大幅促進我國電動自行車在農村市場的消費。

3、國內電動車控制器呈兩極分化發展趨勢，以高標科技為首的品牌化發展之路，面向中高端市場，推出高質量、高科技、高水準的產品，在市場經濟中性價比極高；以一些雜牌為主，價格低廉，產品質量沒有固定標準，生產成本極低，以低價格的優勢在市場上占據一定份額。

3、我國2010年上半年的數據顯示我國在上半年電動自行車產量同比增長

8.9%。

4、今后三年內電動車由于產品升級也逐步進入更新換代期，同時產業升級主要關鍵部件的升級如控制器、動力電源、電機的升級，解決產業困局，控制器等關鍵技術的升級至關重要。

第二篇：電動車控制器設計方案

電動自行車控制器設計

電動自行車控制器方案

2012/11/5

電動自行車控制器設計

目錄

第一章 概述-------------3

第二章 系統需求分析-------4

第三章 控制器分析---------6

一、電動車控制器框圖------6

二、控制器關鍵功能分析-----7

第四章 控制器設計----------9

一、硬件設計---------9

二、軟件設計----------12

電動自行車控制器設計

第一章 概述

近年來，隨著改革開放和經濟發展日益深刻，人民生活水平日漸提高，出行交通工具也發生前所未有的變化。老百姓出行不僅考慮快捷、方便，還追求時尚環保，因此近年來電動自動自行車日益受老百姓喜愛。作為電動自行車，其核心控制器則是電動自行車的關鍵，控制的好壞決定車子的平穩、安全、舒適，因此一個功能全面、可靠性強、符合要求的控制器決定了電動自行車的質量。為了使得電動自行車有良好的體驗和可靠的質量保證，因此本文介紹一種控制器的設計方案。

電動自行車控制器設計

第二章 系統需求分析

1、具有安全檢測功能，檢測電池電壓，電流

需要檢測電池中電流，電池電流不能過大，防止損傷電池；

需要檢查電機中的電流，并且識別是否是電機堵轉還是車子上坡或者負載過大，并且限制電機電流17A以下，在15～17A間切換，防止大電流長時間燒壞電機；

檢測電池電壓，電池電壓大于電機額定電壓120%時，發出報警鈴聲，提醒電壓過大，不能驅動電機；

2、顯示速度和里程數

利用三位數碼管顯示里程數，范圍0～999Km，保證每分鐘更新一次；

用5個發光二極管顯示速度，表示5個檔位，每個檔位間隔速度為10Km/h，即表示的速度為10Km/h、20Km/h、30Km/h、40Km/h、50Km/h，速度在哪個檔位，對應發光二極管閃亮。

3、具有轉向燈控制電路

當打開轉向燈開關時，對應的轉向燈每隔0.5秒閃一次，每次持續0.5秒

電動自行車控制器設計

4、照明燈控制電路

當打開照明燈時，在儀表盤上顯示照明打開，用一個發光二極管。

5、具有報警功能

當鑰匙開關不再車上時，若輪子速度有變化，即發出報警聲音。

電動自行車控制器設計

第三章 系統分析

一、電動車控制器框圖

上圖是整車的控制系統框圖，主要有電源、電機、控制器等，其中控制器位于核心地位，是整個控制系統的關鍵，也是負責組織各個部分協調工作的中心。其具體的控制框圖如下圖所示：

電動自行車控制器設計

電源降壓模塊燈管驅動電路照控速盤電壓信號剎車信號信號轉換電路WM燈P向、轉明燈轉向燈、照明燈信號信號轉換電路PIC芯片信號轉換電路MOS驅動電路電機電源輸出電路電機電路電流、電機電壓蜂鳴器P信號轉換電路WM三極管驅動電路電機霍爾信號電壓、里程顯示輸出數碼管顯示電路電源

從圖中可以看出，控制器由單片機及其外圍電路構成，包括輸入信號處理電路、輸出信號處理電路、電源電路等。

二、控制器關鍵功能分析 控制器功能：

1、改變電機速度

即調速功能，檢測車把電壓，根據車把設定速度來進行速度設定。同時檢測霍爾傳感器計數值，作為當前速度，通過PID調節來計算應該輸出的PWM波。

2、剎車功能

檢測剎車信號，當剎車有效時，將速度設定值強制變為零，輸出PWM也變為零。

電動自行車控制器設計

3、有防過壓、過流檢測電路

檢測電源電壓，低壓報警，防止損傷電池； 檢測電源電流，當電流過大時適當降速，限制電流在合理區間，防止燒壞電機、電源。

4、顯示電池電壓、車速、里程數

將車子的速度用數碼管顯示在儀表盤上，將電池電壓通過發光二極管顯示在儀表盤上。

5、防盜

當車子鎖上時，車輪子有轉動則報警。

6、照明燈控制開關、轉向燈控制開關

可以采用雙刀雙擲開關，一個可控制強電信號，另一個給單片機進行檢測。

電動自行車控制器設計

第四章 控制器設計

控制器是電動自行車的核心，要實現的功能有：

1、可以改變電機速度

2、可以剎車

3、有防過壓、過流檢測電路

4、顯示電池電壓、車速、里程數

5、防盜

控制器不僅要具有所有功能并且引出相關信號線，而且要有合適的外觀尺寸，并且可以對內部電路進行保護。

一、硬件設計

1、電機驅動電路設計

由V1～V6六只功率管構成的驅動全橋可以控制繞組的通電狀態。按照功率管的通電方式，可以分為兩兩導通和三三導通兩種控制方式。由于兩兩導通方式提 供了更大的電磁轉矩而被廣泛采用。在兩兩導通方式下，每一瞬間有兩個功率管導通，每隔1／6周期即60°電角度換相一次，每只功率管持續導通 120°電角度，對應每相繞組持續導通120°，在此期間相電流方向保持不變。

電動自行車控制器設計

為保證產生最大的電磁轉矩，通常需要使繞組合成磁場與轉子 磁場保持垂直。由于采用換相控制方式，其定子繞組產生的是跳變的磁場，使得該磁場與轉子磁場的位置保持在60°～120°相對垂直的范圍 區間。

2、照明燈、轉向燈、速度顯示儀表

單片機檢測到照明燈亮暗，轉向燈亮暗及方向，將其顯示在儀表盤上，燈的亮暗是通過三個發光二極管來顯示的。由于一般的發光二極管20mA的電流就可以驅動，因此可以用單片機I/O引腳直接驅動。

至于速度顯示，可以通過數碼管顯示，數碼管可以用三個，顯示范圍是0.0 ～99.9KM/h，可以用三極管控制選擇端，每次選擇一個數碼管，進行給值，單片機輸出的是四位信號，可以顯示0～9的BCD碼，通過數碼管顯示驅動芯片轉換為數碼管的7段碼，則選中的數碼管顯示對應的數字，通過不斷給數碼管寫值則可以達到看起來連續的效果。

電動自行車控制器設計

或者要節省成本，其實速度顯示可以僅顯示檔位，比如0～5km/h、5～10km/h、10～15km/h、15～20km/h、20～25km/h 分為5檔，每檔對應一個發光二極管，當速度在對應的檔位時，對應的發光二極管亮，其他的不亮。

3、電池電壓檢測電路

檢測電池電壓需要對電池電壓進行采樣，采樣電路的作用是強弱分離，對單片機引腳進行保護，同時對電池電壓進行變換，變到適合單片機A/D引腳采樣的范圍。

采樣電路可以先用電容進行濾波，然后接上一個輸入電阻很大的變換電路，可以通過741等放大器實現，然后對比較后的電壓進行電阻分壓轉換，轉換到0～3.3V，適合單片機采樣。

4、電機電流檢測、電池電流檢測、漏電檢測

在待檢測的電路中串入阻值很小的電阻（注意大電流電路中電阻必須要有較大的功率），然后對電阻兩側的電壓取樣，經過后級差值比較電路得出壓差。差值轉換可以采用741，然后在進行放大縮小變化，轉換成0～3.3V的范圍，可以接入單片機A/D引腳進行電壓檢測，然后除以電阻及變比等即可得到對應線路的電流。通過和每個線路設定電流閾值及車狀態檢測，即可得到是否過流、是否漏電等信息。

電動自行車控制器設計

5、報警電路

單片機通過I/O引腳輸出報警信號開關，然后通過三極管驅動蜂鳴喇叭來提示是否有緊急情況。通過不同頻率的信號分辨不同的報警信息。

6、防盜電路

防盜檢測其實是檢測輪子是否轉動來實現的，即利用霍爾器件檢測速度，若速度大于某個去掉干擾后的閾值就認為有被盜的可能，就驅動蜂鳴喇叭報警。

二、軟件設計

1、軟件流程圖設計

電動自行車控制器設計

上電檢查進入主循環檢測速度輸入，設定速度輸入，剎車信號輸入，電源電壓檢測輸入速度PID計算，將PWM控制信號輸出儀表盤顯示速度

程序流程圖 1，主要流程圖，包括初始化、主循環。

電動自行車控制器設計

檢測速度設定值，用單片機A/D轉換功能將模擬電壓轉換為數字信號，低通濾波讀出單片機光碼盤計數器值，低通濾波增量式PID計算輸出值，并且進行限速處理PWM輸出設定

程序流程圖 2，速度調整程序流程圖

電動自行車控制器設計

已經檢測到實際速度值，并且進行低通濾波處理將速度信號分成三位，分別是十位，個位，小數位計算三位數字轉換成數碼管設定值，并且進行輸出時序設置調用顯示子函數

程序流程圖 3，顯示子函數程序流程圖

電動自行車控制器設計

速度PID計算剎車信號是否有效否進行增量式PID計算，設定是將設定速度設為零，進行PID計算，輸出PWM設定子函數

程序流程圖 4，速度調控流程圖

電動自行車控制器設計

安全檢測子函數電源電流是否過大是否否進行正常處理，顯示電壓是電流過大，進行漏電判斷或者速度限制下一程序

程序流程圖 5，安全檢測程序流程圖

2、軟件功能設計

速度PID設計：

1）可以采用增量式PID，在不同電壓、不同速度下比例積分微分系數有所不同；

2）帶剎車檢測，剎車時將設定速度設為0，電機PWM輸出為零；

3）超速限制，當速度超過20Km/h時，進行適當減速，限制在20Km/h以下；

電動自行車控制器設計

4）起步限速，開始時速度慢慢上升，防止突然啟動。

安全檢測設計：

1）檢測電壓電流，當電壓較低時報警，以免損壞電池； 2）電流檢測，防止超過限制電流燒壞電機、電源或者電線，當電流大于最大電流時，減速是電流在最大電流值以下附近一個區間內波動；

3）上電檢測，當電機未開動時，若有較大電流則可能漏電進行報警；

4）當車鑰匙拔出來，并且開啟報警功能后，若車輪子光碼盤有讀數說明車子可能被盜，要進行報警。

顯示設計：

1）速度顯示設計，用三段數碼管顯示速度的十位、個位和小數位，采用共陰極數碼管，LM373鎖存數字，三個IO口選通數碼管，一次顯示一位，每個循環周期控制一次； 2）照明燈顯示，主控電路用開關實現，單片機僅檢測開關是否開啟，并用一個IO口來控制三極管電路驅動發光二極管來顯示是否開啟照明燈，左右的轉向燈采用相同的設計； 3）電源電壓顯示，將檢測到的電壓用多個發光二極管顯示，亮的越多電壓越高，當電壓低于報警電壓時，所有二極管熄滅，驅動電路采用三極管驅動，每個循環周期進行一次顯示。

第三篇：KDS控制器報告

申請報告

設備動力部：

本部一臺全自動地面清洗機瑞捷X8型在正常清洗地面時，突然發生不能運行，經廠家專業維修人員檢查后，確認為此機的控制器已壞。型號為KDS控制器，需請貴部幫助解決！

生產技術部 2014-4-16

第四篇：struts2_控制器介紹

struts2 控制器介紹

核心控制器FilterDispatcher

核心控制器FilterDispatcher是Struts 2框架的基礎，包含了框架內部的控制流程和處理機制。業務控制器Action和業務邏輯組件是需要用戶來自己實現的。用戶在開發Action和業務邏輯組件的同時，還需要編寫相關的配置文件，供核心控制器FilterDispatcher來使用。

Struts 2的工作流程相對于Struts 1要簡單，與WebWork框架基本相同，所以說Struts 2是WebWork的升級版本。Struts 2框架按照模塊來劃分，可以分為Servlet Filters、Struts核心模塊、攔截器和用戶實現部分。Struts 2框架結構圖如圖3.1所示。

圖3.1 Struts 2框架結構圖

一個請求在Struts 2框架中的處理大概分為以下幾個步驟。

客戶端提交一個（HttpServletRequest）請求，如上文在瀏覽器中輸入

http://localhost: 8080/bookcode/ch2/Reg.action就是提交一個（HttpServletRequest）請求。

請求被提交到一系列（主要是3層）的過濾器（Filter），如（ActionContextCleanUp、其他過濾器（SiteMesh等）、FilterDispatcher）。注意：這里是有順序的，先ActionContext CleanUp，再其他過濾器（Othter Filters、SiteMesh等），最后到FilterDispatcher。

FilterDispatcher是控制器的核心，就是MVC的Struts 2實現中控制層（Controller）的核心。

FilterDispatcher詢問ActionMapper是否需要調用某個Action來處理這個（HttpServlet Request）請求，如果ActionMapper決定需要調用某個Action，FilterDispatcher則把請求的處理交給ActionProxy。

ActionProxy通過Configuration Manager（struts.xml）詢問框架的配置文件，找到需要調用的Action類。例如，用戶注冊示例將找到UserReg類。

ActionProxy創建一個ActionInvocation實例，同時ActionInvocation通過代理模式調用Action。但在調用之前，ActionInvocation會根據配置加載Action相關的所有Interceptor（攔截器）。

一旦Action執行完畢，ActionInvocation負責根據struts.xml中的配置找到對應的返回結果result。Struts 2的核心控制器是FilterDispatcher，有3個重要的方法：destroy()、doFilter()和Init()，可以在Struts 2的下載文件夾中找到源代碼，如代碼3.1所示。

代碼3.1 核心控制器FilterDispatcher

public class FilterDispatcher implements StrutsStatics, Filter {

/**

* 定義一個Log實例

*/

private static final Log LOG = LogFactory.getLog(FilterDispatcher.class);

/**

* 存放屬性文件中的.STRUTS_I18N_ENCODING值

*/

private static String encoding;

/**

* 定義ActionMapper實例

*/

private static ActionMapper actionMapper;

/**

* 定義FilterConfig實例

*/

private FilterConfig filterConfig;

protected Dispatcher dispatcher;

/**

* 創建一個默認的dispatcher，初始化filter

* 設置默認的packages

*

*/

public void init(FilterConfig filterConfig)throws ServletException {

this.filterConfig = filterConfig;

dispatcher = createDispatcher(filterConfig);

dispatcher.init();

String param = filterConfig.getInitParameter(“packages”);

String packages = “org.apache.struts2.static template org.apache.struts2.interceptor.debugging”;

if(param!= null){

packages = param + “ ” + packages;

}

this.pathPrefixes = parse(packages);

}

//銷毀filter方法

public void destroy(){

if(dispatcher == null){

LOG.warn(“something is seriously wrong, Dispatcher is not initialized(null)”);

} else {

dispatcher.cleanup();

}

}

/**

* 處理一個Action或者資源請求

*

* filter嘗試將請求同action mapping相匹配

* 如果找到，將執行dispatcher的serviceAction方法

* 如果Action處理失敗, doFilter將建立一個異常

*

* 如果請求靜態資源

* 資源將被直接復制給 response

*

* 如果找不到匹配Action 或者靜態資源，則直接跳出

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)throws IOException, ServletException {

HttpServletRequest request =(HttpServletRequest)req;

HttpServletResponse response =(HttpServletResponse)res;

ServletContext servletContext = getServletContext();

String timerKey = “FilterDispatcher_doFilter: ”;

try {

UtilTimerStack.push(timerKey);

request = prepareDispatcherAndWrapRequest(request, response);

ActionMapping mapping;

try {

mapping=actionMapper.getMapping(request, dispatcher.getConfigurationManager());

} catch(Exception ex){

LOG.error(“error getting ActionMapping”, ex);

dispatcher.sendError(request, response, servletContext, HttpServletResponse.SC_INTERNAL_SERVER_ERROR, ex);

return;

}

if(mapping == null){

String resourcePath = RequestUtils.getServletPath(request);

if(“".equals(resourcePath)&& null!= request.getPathInfo()){

resourcePath = request.getPathInfo();

}

if(serveStatic && resourcePath.startsWith(”/struts“)){

String name = resourcePath.substring(”/struts“.length());

findStaticResource(name, request, response);

} else {

//為一個普通的request, 則通過

chain.doFilter(request, response);

}

return;

} /**

*這個方法詢問ActionMapper是否需要調用某個Action來處理這個（request）請求，*如果ActionMapper決定需要調用某個Action，*FilterDispatcher則把請求的處理交給ActionProxy

dispatcher.serviceAction(request, response, servletContext, mapping);

} finally {

try {

ActionContextCleanUp.cleanUp(req);

} finally {

UtilTimerStack.pop(timerKey);

}

} }

… …

}

在doFilter()方法中，將調用dispatcher.serviceAction，該方法如果找到相應的Action，將把用戶請求交給ActionProxy。serviceAction()代碼在Dispatcher.java中，如代碼3.2所示。

代碼3.2 Dispatcher類

public class Dispatcher {.../**

* 為mapping加載類，并調用相應的方法或者直接返回result

*

* 根據用戶請求的參數，建立Action上下文

* 根據指定的Action’名稱和包空間名稱，加載一個Action代理 ActionProxy

* 然后Action的相應方法將被執行，*/

public void serviceAction(HttpServletRequest request, HttpServletResponse response, ServletContext context, ActionMapping mapping)throws ServletException {

Map extraContext = createContextMap(request, response, mapping, context);

//如果存在一個值棧，則建立一個新的并復制以備Action使用

ValueStack stack =(ValueStack)request.getAttribute(ServletActionContext.STRUTS_VALUESTACK_KEY);

if(stack!= null){

extraContext.put(ActionContext.VALUE_STACK, ValueStackFactory.getFactory().createValueStack(stack));

}

String timerKey = ”Handling request from Dispatcher“;

try {

UtilTimerStack.push(timerKey);

String namespace = mapping.getNamespace();

String name = mapping.getName();

String method = mapping.getMethod();

Configuration config = configurationManager.getConfiguration();

//FilterDispatcher把請求的處理交給ActionProxy

ActionProxy proxy = config.getContainer().getInstance(ActionProxyFactory.class).createActionProxy(namespace, name, extraContext, true, false);

proxy.setMethod(method);

request.setAttribute(ServletActionContext.STRUTS_VALUESTACK_KEY, proxy.getInvocation().getStack());

//ActionMapping 直接返回一個result

if(mapping.getResult()!= null){

Result result = mapping.getResult();

result.execute(proxy.getInvocation());

} else {

proxy.execute();

}

if(stack!= null){

request.setAttribute(ServletActionContext.STRUTS_VALUESTACK_KEY, stack);

}

} catch(ConfigurationException e){

LOG.error(”Could not find action or result", e);

sendError(request, response, context, HttpServletResponse.SC_NOT_FOUND, e);

} catch(Exception e){

throw new ServletException(e);

} finally {

UtilTimerStack.pop(timerKey);

}

} …

｝

從上面代碼中可以看出來，Struts 2用于處理用戶請求的Action實例，并不是用戶實現的業務控制器，而是Action代理。關于Action代理相關內容，讀者可以參考攔截器章節的介紹。

★ 提示 ★

前面一直在說Action可以是一個普通的Java類，與Servlet API完全分離，但是為了實現業務邏輯，Action需要使用HttpServletRequest內容。

Struts 2設計的精巧之處就是使用了Action代理，Action代理可以根據系統的配置，加載一系列的攔截器，由攔截器將HttpServletRequest參數解析出來，傳入Action。同樣，Action處理的結果也是通過攔截器傳入HttpServletResponse，然后由HttpServletRequest傳給用戶。

其實，該處理過程是典型的AOP（面向切面編程）的方式，讀者可以在后面詳細了解到。Struts 2處理過程模型如圖3.2所示。

圖3.2 Struts 2處理過程模型

★ 說明 ★

攔截器是Struts 2框架的核心，通過攔截器，實現了AOP（面向切面編程）。使用攔截器，可以簡化Web開發中的某些應用，例如，權限攔截器可以簡化Web應用中的權限檢查。

3.1.2

業務控制器Action

業務控制器Action是由開發者自己編寫實現的，Action類可以是一個簡單的Java類，與Servlet API完全分離。Action一般都有一個execute()方法，也可以定義其他業務控制方法，詳細內容將在后面介紹。

Action的execute()返回一個String類型值，這與Struts 1返回的ActionForward相比，簡單易懂。Struts 2提供了一個ActionSupport工具類，該類實現了Action接口和validate()方法，一般開發者編寫Action可以直接繼承ActionSupport類。編寫Action類后，開發者還必須在配置文件中配置Action。一個Action的配置應該包含下面幾個元素：

1、該Action的name，即用戶請求所指向的URL。

2、Action所對應的class元素，對應Action類的位置。

3、指定result邏輯名稱和實際資源的定位。

Action是業務控制器，筆者建議在編寫Action的時候，盡量避免將業務邏輯放到其中，盡量減少Action與業務邏輯模塊或者組件的耦合程度。

3.1.3

業務模型組件

業務模型組件可以是實現業務邏輯的模塊，可以是EJB、POJO或者JavaBean，在實際開發中，對業務模型組件的區分和定義也是比較模糊的，實際上也超出了Struts 2框架的范圍。不同的開發者或者團隊，都有自己的方式來實現業務邏輯模塊，Struts 2框架的目的就是使用Action來調用業務邏輯模塊。例如一個銀行存款的業務邏輯模塊，如代碼3.3所示。

代碼3.3 模擬一個銀行業務的實現模塊

package ch3;

public class Bank {

//定義銀行賬戶

private String accounts;

//定義操作金額

private double money;

//屬性的getter和setter方法

public String getAccounts(){

return accounts;

}

public void setAccounts(String accounts){

this.accounts = accounts;

}

public double getMoney(){

return money;

}

public void setMoney(double money){

this.money = money;

}

//模擬銀行存款方法

public boolean saving(String accounts, double money){

//調用DAO等模塊讀寫數據庫

return dosomeing();

}

}

上面實例在實際開發中沒有任何意義，這里只是作為業務邏輯模塊來說明，在執行saving(String accounts,double money)方法時，可以調用相應的數據庫訪問其他組件，來實現存款操作。使用Action調用該業務邏輯組件可以在execute()方法中實現，如代碼3.4所示。

代碼3.4 業務控制器Bank_Saving_Action

package ch3;

import java.util.Map;

import com.opensymphony.xwork2.ActionContext;

import com.opensymphony.xwork2.ActionSupport;

public class Bank_Saving_Action extends ActionSupport {

//定義銀行賬戶

private String accounts;

//定義操作金額

private double money;

public String execute()throws Exception {

//創建Bank實例

Bank bk=new Bank();

//調用存款方法

if(bk.saving(accounts, money)){

return SUCCESS;

}else{

return ERROR;

} }

//屬性的getter和setter方法

public String getAccounts(){

return accounts;

}

public void setAccounts(String accounts){

this.accounts = accounts;

}

public double getMoney(){

return money;

}

public void setMoney(double money){

this.money = money;

}

Bank_Saving_Action演示了對銀行存款業務邏輯組件的調用，這里是通過在Action中創建業務邏輯組件實例的方式實現的。在實際開發中，可以使用靜態工廠獲得業務邏輯組件的實例或者使用IoC容器來管理。Action中不實現任何業務邏輯，只是負責組織調度業務邏輯組件。調用關系如圖3.3所示。

圖3.3 調用業務邏輯組件

★ 說明 ★

業務控制器Action一般情況下不是直接創建業務邏輯組件實例，而是使用工廠模式或者是從Spring容器中獲得業務邏輯組件實例，這樣可以提高系統的性能。

3.1.4

視圖組件

Struts 1只能支持JSP作為視圖資源，而Struts 2的進步之處就是可以使用其他視圖技術，如FreeMarker、Velocity等。通過前面的學習和示例，讀者會知道Action的返回結果只是一個簡單的字符串，也就是一個邏輯上的視圖名稱，要與實際視圖資源對應，必須通過配置文件來實現。

在struts.xml配置文件中，每一個Aciton定義都有name和class屬性，同時還要指定result元素。result元素指定了邏輯視圖名稱和實際視圖的對應關系。每個result都有一個type屬性，前面介紹的struts.xml中并沒有顯式指定type值，即使用了默認的type類型：dispatcher，該結果類型支持JSP所謂視圖資源。

對于Struts 2的視圖技術和result返回類型，后面將詳細介紹。

第五篇：控制器產品檢驗標準

1.0

目的為使本公司生產的控制器及驅動器產品之半成品制作、成品入庫、出貨檢驗作業有所依據，特定此檢驗規范。

2.0

適用范圍

本規范適用于控制器及驅動器產品生產的制程中檢驗、QA成品抽檢、出貨檢驗過程。

3.0

抽樣計劃（針對抽檢工序）：

依《數字抽樣計劃使用規范》

3.1

抽樣水準

參考標準MIL-STD-105E

單次正常檢查水準Ⅱ級

3.2

允許水準（AQL）：2/1000

3.3

到45CM

3.4

目視角度：與被測物成30度到45度角范圍

4.0

外觀表面分級標準：

4.1

一級表面:在使用過程中能被用戶首先看到的部份，即產品正面；

4.2

二級表面：用戶偶爾才看到的表面，此處的瑕疵不會對品質造成危害，即產品側面以及背面；

5.0

檢驗標準及方法：

檢驗項目

標準

檢驗方式

AQL

CR

MAJ

MIN

半成品檢驗（未裝外殼）

元器件

PCB板上元器件無破損、斷引腳、浮高、錯件、少件、二極管無插反；散熱片鎖緊并與三管極良好接觸

目視,核對標準樣品或派工單

√

焊點

焊點飽滿，無漏焊、虛焊、連錫、少焊、多錫等不良，PCB板插件面無多余錫珠，PCB背面加錫位置錫厚1.5-3.0mm

目視

√

導線

有連接信號線的控制器，各顏色導線插接位置應正確,無交叉、漏插現象

目視

√

功能測試

各功能按鍵應能有效工作，按鍵順暢

根據控制器使用說明連接好電源及測試模組

√

正常工作時LED閃爍正常，無順序錯亂及不亮

√

調節各功能按鍵時液晶顯示屏亮度不變，無閃屏

√

負載指示燈與負載要求同步

√

信號輸出有效，調節各按鍵時，液晶顯示屏上對應值會做相應變化，各模式對應效果要求一致，模式變化參考使用說明書

√

成品檢驗

表面外觀

一級表面及可正視A面（正面）：表面完整平滑，無刮傷、油污、臟污、噴涂均勻無色差，無刮手批鋒。

二級表面及可正視B面（側面）：表面裂縫可接受大小為≤0.3MM，表面有感刮傷≤0.1MM（深度），長度為≤2MM。無感刮傷≤0.1MM（深度），長度≤2MM。表面有感雜物可接受面積≤0.1MM，無感雜物可接受面積≤0.2MM。

目視

√

絲印

絲印清晰完整各按鍵上面需要標注名字，內容正確，每路信號輸出品絲印清晰正確，無正負極標反現象

目視

√

裝配

外殼螺絲釘完整且外殼無松動和銜接不吻合現象，間隙可接受范圍0.3MM

目視

√

外殼上裝有防水圈，防水圈應接直繃緊，PG7防水接頭與外殼要求擰緊，防水帽與RVV線螺絲鎖緊，RVV線在殼體內應伸出1-2cm（KC1P500GV1產品檢驗適用）

目視

√

功能測試

各功能按鍵應能有效工作，按鍵順暢

根據控制器使用說明連接好電源及測試模組

√

正常工作時LED閃爍正常，無順序錯亂及不亮

√

調節各功能按鍵時液晶顯示屏亮不變，顯示屏也不抖動

√

負載批示燈與負載要求同步

√

信號輸出有效，調節各按鍵時，液晶顯示屏上對應值會做相應變化，各模式對應效果要求一致，模式變化參考使用說明書

√

讀卡SD應能正常讀卡（針對點控控制器，KC1P500G）

√

包裝

包裝應符合派工單或客戶特殊要求配相應說明書、合格證，包裝標識正確、包裝無破損

目視

√

5.1

遙控器尺寸和模式

亮度加

亮度減

關閉

打開

靜態紅色

靜態綠色

靜態藍色

靜態白色

靜態

玫瑰紅色

靜態

草綠色

靜態

寶石藍色

七色跳變

靜態橙色

靜態

靑藍色

靜態

紫灰色

七色漸明漸暗

靜態鵝黃色

靜態

天空藍

靜態

醬紫色

三色漸明漸暗

靜態

黃色

靜態

青色

靜態

紫色

三色跳變

5.2控制器尺寸.