近年來，日益廣泛而複雜的整合式IC設計與設計時間的壓縮，任何在整合軟、硬體時所發生的問題，都可能成為整個研發計劃失敗的致命傷。為了跳脫舊有窠臼，許多公司不得不重新思考其傳統的軟體設計流程，新的研發流程必須把從觀念到軟、硬體整合測試(System Integration Test)各個面向都納入考量。在新的設計環境下，任何階段的研發工具不能只針對特殊設計領域，必須能夠應用於整個設計流程當中與其他工具互相整合。

有效率的研發團隊必須揚棄過去的做法，選擇以系統層級設計(System Level Design)為主軸的共同設計媒介。讓各領域的工程師們能夠在相同的環境下，用各自熟悉的技術語言來表達想法，同時又能夠與其他領域、不同設計階段的工程師共享。本文主旨即在介紹這樣一個能夠「一以貫之」的控制系統設計、發展平台。

Model-Based概念

Mathworks公司搭配了眾多工具箱的Matlab與採用視覺化圖形區塊(Visual block-diagram)設計概念的Simulink等相關工具軟體，長久以來一直被廣泛的應用在控制系統演算法(Algorithm)的設計、模擬與分析上。Simulink的圖形區塊介面不但可以用來設計演算法，同時也可以用來模擬實際受控系統的動態反應特性。以(圖一)為例，Fuel rate controller為演算法模型，而engine gas dynamics則為受控體動態模型(Plant Dynamic Model)。

《圖一　引擎燃油控制系統模型》

在Matlab/Simulink的環境下，每一個模型皆可分別建立、單獨執行，而各個模型由於都是在相同的環境下發展出來的，所以整合的問題幾乎不存在。這種把將控制系統演算法、受控體動態模型模組化的發展環境統稱為Model-Based 技術平台。

近年來Stateflow的推出，更是大幅提升了Model-Based環境在演算法開發上的時效，也因此Maltab/Simulink/Stateflow環境已成為控制系統演算法開發的標準軟體。基本上，Stateflow彌補了傳統上Matlab/ Simulink在事件驅動(event driven)與諸如：if、while及狀態邏輯判斷等功能之不足。以下舉一例介紹Stateflow如何在Simulink環境底下進行系統開/關電源的處理模擬程序。

(圖二)的範例由正弦訊號源(Sine Source Block)、Switch與Stateflow chart所構成。其中正弦訊號模擬感測器訊號輸入，而當Switch由0切換到1時，會產生一個正緣觸發(rising edge trigger)訊號，我們可以把這個正緣觸發訊號定義成Switch_On事件，當然Switch由1切換到0時的負緣觸發(falling edge trigger)訊號，便定義成Switch_Off。不過Simulink中正弦訊號、開關與示波器在這個範例裡只是當成驗證控制策略的工具，Stateflow chart才是範例中整個演算法的核心。首先可以看到在Stateflow chart裡定義了以下兩個事件驅動型態的控制指令：

《圖二　StateFlow模型》

On Switch_On:Go_PowerOn；(Switch_On，執行Go_PowerOn)

On Switch_Off:Go_PowerOff；(Switch_Off，執行Go_PowerOff)

起初系統處於電源關閉狀態(PoweOffState)，電源開啟瞬間，系統偵測到Switch_On後，演算法開始執行Go_PowerOn的動作，如果此時輸入訊號(data_In)小於或等於0.5，則系統進入PowerOn_2狀態，並執行此狀態下所定義的程序(data_Out=data_In*5)。而如果輸入訊號大於0.5的話則進入PowerOn_1狀態，並處理相關程序。一旦有Switch_Off動作產生，系統會自動從Power On狀態回到PowerOffState。

當然這個範例本身沒有太大的用途，不過我們卻可以由此了解結合Simulink視覺化圖形區塊與Stateflow描述式語言的環境，是一個極佳的演算法設計與發展平台。工程師可以使用系統層級設計(System level design)的概念，利用視覺化圖形區塊組合與高階描述語言，快速而有效的設計並驗證遠較過去複雜的控制策略與演算法。

快速原型化(Rapid Prototyping)與HIL( Hardware in the loop)

雖然在Matlab/Simulink的環境下可以用不同的訊號模擬區塊，進行演算法的設計與驗證，不過它不是一個即時(Real Time)的環境。如果能夠把在Simulink環境下建立的模型以即時的方式執行的話，演算法可以更精確的被驗證。在Window的環境底下，演算法(尤其是複雜的演算法)的執行很難做到真正的即時。可是如果可以把演算法轉換成C-程式碼，經過編譯後放到計算功能較強且有自己即時核心作業系統(Real Time Kernel OS)的硬體上，同時透過適當的I/O與時序規劃，便有可能在執行演算法模型運算時做到真正的即時。在這種作業環境下工程師可以將設計完成的演算法以即時的方式對實際受控體進行模擬測試，這種方式即稱為快速原型化測試(Rapid Prototyping Test)(圖三)。

《圖三　快速原型化作業平台示意圖》

Real Time Workshop(RTW)與Stateflow Coder便是植基於這種思維邏輯下的兩種工具。RTW與Stateflow Cdoer能夠分別把Simulink的圖形區塊與Stateflow描述語言轉換成ANSI C-程式碼，工程師可以把所得到的C-程式碼經過編譯後放到特定的硬體(即時系統)裡面，以即時方式進行控制器的快速原型化測試。

如果放到即時系統裡面的是模擬實際受控系統的動態反應模型，則該即時系統便可以即時的方式模擬受控體反應，這種概念可以被用來執行控制系統軟、硬體之整合測試，這種測試方式便稱為Hardware in the loop(HIL)(圖四)。

《圖四　HIL作業平台示意圖》

不管是測試軟體演算法所使用的快速原型化或者是HIL技術，所使用的工具(即時系統)與作業環境幾乎完全相同，這種特性可以有效的省去以往許多整合上的問題。在Model-Based技術平台領域裡，較著名的即時系統(環境)有：Mathworks的Real Time Window Target與xPC Target、加拿大LSP的SignalMaster、德國的dSPACE與美國Applied Dynamics的RTS。

Model To Chip

能夠利用Matlab/Simulink/Stateflow的整合式環境來設計演算法，並使用即時系統驗證演算法，對於演算法設計團隊而言是的確一個好消息。不過隨之而來的問題是：雖然演算法開發工程師可以在很短的時間內，發展出許多複雜的控制策略，然而這些複雜演算法，往往會因為種種障礙或限制而沒有辦法完全的實現在最後的產品上。

傳統的控制系統開發是由一連串分離的設計階段所組成的，其中包括：客戶需求分析、規格定義、演算法設計與發展(Algorithm Design)、制訂程式流程圖(flow chart)、程式編碼(Coding)、軟體測試以及最後的軟硬體整合測試與驗證。對於大部分的大型專案而言，前述設計程序通常是由不同的工程團隊各自進行的，當設計週期拉的很長時，各領域、各階段的設計工程師當然想暫時拋卻整合性與測試的問題，只想在自己的領域裡作獨立、最佳化的設計。因此，無論是演算法、系統流程圖、程式編碼語言的選用，工程師們都會選擇在特定設計領域裡，能夠達成最佳化結果的工具。而這種工具的特定性，形成了工作團隊間的溝通障礙。不但工程師們鮮少彼此分享其概念，各階段不同工具間轉譯所造成的錯誤更是不勝其擾，就算是研發團隊完成符合各自規格的設計，也無法確保整合時的正確性與相容性，整合各團隊設計所耗費的時間可能高達整個設計流程的70%以上，減少了創新智慧財產的時間。當然，專案規模越大控制策略越複雜，工程團隊間所面臨的整合困難度也越大。

以PID控制器的程式編碼為例，演算法是否能夠在專案規定的執行期限內完全實現？與軟體編碼工程師所選擇的編碼語言有極大的關連。如果只講求程式執行效率，選擇用組合語言進行控制器程式的軟體編碼，除了對編碼工程師是個挑戰之外，流程圖的制訂、編碼、測試、除錯及後續維護，都必須消耗一定的專案資源，即使選擇以C語言編碼，工程規模都不算小。

因此有許多產品開發專案，縱使已經發展出較佳的控制演算法，但在編碼能力與上市日期的壓力下，往往不敢將這些較先進的控制策略，應用在其產品上，致使失去達成產品最佳化的寶貴契機，導致市場競爭力減弱。

於是大家開始思索一個問題，是不是能夠把在Model-Based環境下發展完成之演算法模型，直接放到微控制器(MCU)晶片(chip)或者是DSP裡面？這樣就可以省去制訂流程圖、程式編碼及程式除錯等耗費人力與時間資源等工作。而這其中的關鍵便在於RTW自動編碼的程式碼效率。過去的這種由模型轉換成程式碼的自動編碼效率，在程式的大小與執行速度均不若人工編碼。不過隨著RTW與Stateflow Coder的不斷改良，這種情況已經全然改觀，現在的編碼效率不但已經可以和人工編碼互相比擬，未來在整體效率方面甚至將超過人工編碼(圖五)。

《圖五　RTW自動編碼效率發展趨勢圖》

事實上，在國外已經有許多公司已經將自動編碼技術導入其量產控制器的開發專案裡，以日本TOYOTA為例，其在 1998 年在市場上推出的複合動力車(Hybrid Vehicle)Prius所使用的控制器即是採用自動編碼所產生的C程式碼。

鈦思公司也已經開始將此技術應用在：8051、AMD 188與DSP等不同領域晶片的嵌入式程式碼(Embedded code)開發，相信在未來日益廣泛而複雜的整合式IC設計與上市時間的壓縮下，這套開發技術在控制器開發領域上勢必扮演主導地位。

結語

使用「一以貫之」的平台已是控制系統開發的共通趨勢，而Matlab/Simulink/Stateflow所提供的Model-Based環境已成為此種平台的代表。Model-Based作業平台為控制系統軟體的開發帶來了新的概念，在這種平台下，控制系統軟體的開發流程可以簡化成(圖六)的四個步驟，除了有效的節省開演算法發時間外，更減少了制訂流程圖、程式編碼及程式除錯等耗費人力資源的工作。這種作業平台在未來日益廣泛而複雜的整合式IC設計與上市時間縮短的壓力下勢必扮演主導地位。

《圖六　Model-Based技術平台控制系統軟體的開發流程》