當飛機上或跑道周圍有意外事故發生，第一時間的反應人員會需要可以快速進入艙內的途徑。在這種情況下，迅速部署救援梯可以做為一個快速疏散的裝置，或者協助醫護人員提供乘客或機組成員及時的醫療援助。

我們在Rosenbauer公司的團隊近期重新設計了飛機內部通道車（Aircraft Interior Access Vehicle），或者更通俗的說法為「救援梯」，在維持高安全標準並改善使用便利性的同時，盡可能縮短設置時間（圖1）。

圖1 : Rosenbauer救援梯

當我們開始這項工作時，也藉此機會重塑既有的控制軟體開發流程，該流程是以手寫的程式碼與大量的實車測試為基礎。我們將這套過時的方法以一種原本認為只對更大型OEM專案具備經濟可行性的方式取代。

特別是使用MATAB與Simulink提供的以模型為基礎的設計流程（Model-Based Design），透過模擬來驗證我們的早期控制設計，讓內部與外部的開發團隊能夠執行硬體迴圈（hardware-in-the-loop）測試、產生產品程式碼，並且將專案開發時間縮減了一半。

控制設計的機會與挑戰

在設計前一代救援梯的控制系統時，能夠選擇的控制硬體比起現在相當有限。因此，我們需要將控制軟體分配給六組ECUs，同時也需要在線路和其他元件加入大量的冗餘（redundancy）以符合安全要求。

而至於現在的設計，新的硬體讓我們能夠將架構大幅簡化，只需要使用到兩組ECUs。一組經過安全性驗證的ECU處理所有的安全性功能，其軟體是由我們的供應商TTControl的工程團隊所開發；第二組ECU執行控制應用軟體，該軟體由Rosenbauer團隊自行開發。

雖然新版的架構較為簡單，我們在實現控制系統時還是遇到了幾項挑戰。首先，我們必須在取得救援梯硬體（包含液壓和機械元件）之前，就開始開發工作。第二，有一項控制器的關鍵設計限制是禁止救援梯在上升或下降時隨意停止在任何位置。控制器必須從2,500個預先設好的鎖定位置找出最接近的定位。在這個位置上，會有機械拴扣和齒在重量滿載時支撐著救援梯（圖2）。

圖2 : 救援梯上的鎖定機械裝置

隨著複雜度提高，手動編寫程式碼以及直接進行車載測試變得不切實際。這種方法通常已經相當困難，而我們特殊的要求又讓流程更具挑戰性。最後，鑒於車輛的尺寸以及在測試時需要啟動柴油引擎，所有的車載測試都必須在戶外執行。以前，我們經常需要在惡劣的天氣或夜間黑暗中進行測試來滿足截止期限。

開發受控體和基礎控制器模型

隨著專案展開，我們開始在Simulink開發一個救援梯的受控體模型。這個模型包括致動器的位置、液壓、電流及CAN訊號，它也包括液壓系統的要件，例如閥門和液壓缸，我們依據製造廠商提供的資料工作表上的資訊來加入這些元件。

伴隨著受控體模型，我們還使用Simulink和StateflowR開發一個簡易的控制器模型。這個初始的模型並未實現對於控制軟體的每一項要求，然而它包含足夠的功能，幫助我們得知機器會如何運作，以及是否需要在硬體設計上做出任何改變。

我們組合控制器與受控體模型來建立一個使用來執行封閉迴圈模擬的系統層級模型（圖3）。模擬結果的分析會影響我們決定要在救援梯上使用哪一種液壓升降機，以及要實現哪些種類的感測器。舉例來說，我們一開始是計劃要在液壓缸上使用電流感測器，但是看到模擬結果並發覺它們的精確度不足時，就決定改為使用CAN感測器。以前，這類的設計問題會在開發流程較後面的實車測試階段才被發現。

圖3 : 包含受控體和控制器子模型的系統層級模型

程式碼生成與HIL測試

經由桌上模擬驗證過早期控制設計之後，我們很快地進入到HIL測試。在使用Embedded CoderR從受控體模型產生程式碼，並且將程式碼部署在一個TTControl提供的TTC 580 ECU。再依循同樣的流程從控制器產生程式碼，並且部署到第二個TTControl ECU。在完全按照真正控制器接在救援梯的方式將這兩個ECUs銜接一起之後，我們執行HIL測試來檢驗控制器設計的即時效能，並且驗證控制器與救援梯觸控面板之間的運作（圖4）。

圖4 : 用來控制救援梯的10吋觸控螢幕顯示器

我們也為在TTControl負責安全軟體的同事提供一個相同的HIL測試設置。該團隊接下來的工作就可以與我們同時進行，他們可以執行自己測試來檢驗其開發的軟體，而不用要求進入真正救援梯。這個HIL測試設置不只是幫助TTControl團隊加快軟體的開發，也幫助他們在開始到真正的救援梯執行測試之前，就發現並解決了幾個問題。

實機測試與投產

當TTControl團隊完成安全軟體的開發，我們這邊則持續開發並精進控制應用軟體。作為流程的一部分，我們使用Legacy Code Tool將TTControl工程師手動編寫的電流和位置控制C++程式碼匯入至Simulink模型。接下來，繼續執行模擬和HIL測試，不只是為了驗證我們在控制應用加入的新功能，也驗證了由其他團隊開發及發佈的C++程式碼。

這個時候，我們已經準備好要在真正的救援梯上面測試控制器。我們再一次使用Embedded Coder從Simulink模型產生程式碼，並且將程式碼部署到一個TTControl ECU。不過這一次我們不是把ECU寫進HIL設置，而是連接到真正的救援梯來執行一系列的實機測試。

所有藉由模擬驗證的測試情境在真實的救援梯，也都可以順利運行。不過我們確實發現有幾個之前沒有考慮到的邊角案例，包含在觸控螢幕上按下奇怪的按鈕組合。我們透過將幾個額外的狀態和轉換插入至Stateflow的狀態機來解決這些問題（圖5）。接著，執行模擬來驗證變更、重新產生的程式碼，並且再一次實際的救援梯測試以確保每一個環節都正確運作。以前在手動編寫控制程式碼的時候，牽涉加入狀態和轉換的任何形式變更，都需要花上更長的時間來實現和除錯。

圖5 : 使用Stateflow進行狀態機設計

以模型為基礎的設計用於專案

當救援梯現在已投入生產，我們來為已達成的成就做個總結。就性能表現來說，該救援梯延伸到其最頂端的位置所花的時間比我們先前的設計快了20%－提高了緊急情況下的真實救援速度。從開發的觀點來看，以模型為基礎的設計幫助我們實現一個更可靠的控制系統，而且耗費的時間還不到採取原本方式的一半。

使用Embedded Coder從Simulink模型產生程式碼是提高研發速度其中的關鍵因素之一。我們在Embedded Coder的訓練課程投入一些時間，用來更透徹地了解程式碼生成的利用。除了幫助我們發揮這套工具的最大價值，這門課程也讓我們對於將程式碼生成納入工作流程的便利程度大開眼界。

我們從前曾經花費大量時間在除錯及維護手寫程式碼，而且未察覺已經有那麼多車輛產業的大型公司採用程式碼生成於產品階段的控制軟體。這項認知，再加上在救援車的第一手經驗，促使我們的團隊在幾項其他專案擴大使用以模型為基礎的設計流程，包括目前正在開發的電動消防車的控制設計。

（本文由鈦思科技提供；作者Clemens Friedl任職於Rosenbauer Group）