| 作者 Clemens Friedl，盧森寶亞集團(tuán)

當(dāng)飛機(jī)上或跑道附近發(fā)生意外事故時，急救人員需要快速進(jìn)入機(jī)艙。在這種情況下，快速架設(shè)救援梯有助于快速疏散乘客或機(jī)組人員，或讓醫(yī)護(hù)人員能夠為他們提供及時的醫(yī)療救助。 最近，盧森寶亞重新設(shè)計了飛機(jī)內(nèi)部通道車（更通俗的說法是“救援梯”），旨在最大程度減少安裝時間，同時保持高安全標(biāo)準(zhǔn)并提高易用性（圖 1）。在開始這項工作時，我們還籍此機(jī)會重建了現(xiàn)有的控制軟件開發(fā)流程，該流程之前一直基于手寫編碼和大量的車載測試。我們不再使用這種過時的方法，而是采用我們原本以為只對更大型 OEM 具有經(jīng)濟(jì)可行性的方法。具體來說，我們在 MATLAB 和 Simulink 中使用了基于模型的設(shè)計，通過仿真驗證我們的早期控制設(shè)計，使內(nèi)外部開發(fā)團(tuán)隊能夠運行硬件在環(huán)測試，生成產(chǎn)品級代碼，并將項目開發(fā)時間縮短一半。

控制設(shè)計面臨的機(jī)遇和挑戰(zhàn)

在我們?yōu)樯弦淮仍菰O(shè)計控制系統(tǒng)時，當(dāng)時可用的控制硬件較為有限。因此，我們需要將控制軟件分布到六個 ECU 上。為了滿足安全要求，我們還需要布線和其他組件應(yīng)有大量冗余。 對于當(dāng)前的設(shè)計，新的硬件讓我們能夠大大簡化架構(gòu)，并且只需使用兩個 ECU。一個 ECU 通過了安全認(rèn)證，可以處理所有安全功能，其軟件由我們的供應(yīng)商 TTControl 的工程師團(tuán)隊開發(fā)。另一個 ECU 負(fù)責(zé)運行控制應(yīng)用軟件，該軟件則由我在盧森寶亞的團(tuán)隊開發(fā)。

雖然控制系統(tǒng)的架構(gòu)較為簡單，但我們在實現(xiàn)該系統(tǒng)時仍面臨諸多挑戰(zhàn)。首先，我們需要在獲得救援梯的硬件（包括液壓和機(jī)械組件）之前就著手開發(fā)工作。其次，控制器有一項關(guān)鍵設(shè)計限制，禁止樓梯在升降時隨意停在任何位置。控制器必須從 2,500 個預(yù)定義鎖定位置中找到最近的位置。在此位置，機(jī)械閂鎖和齒條在重量滿載的情況下應(yīng)該能夠支撐樓梯（圖 2）。隨著這種復(fù)雜性的增加，手工編寫代碼和直接在車輛上進(jìn)行測試變得不切實際。此類方法實施起來往往很難，而我們的特定需求也使得該過程更具挑戰(zhàn)性。最后，考慮到車輛的尺寸以及在測試過程中需要運行柴油發(fā)動機(jī)，所有車載測試都必須在室外進(jìn)行。過去，我們經(jīng)常需要在惡劣的天氣或夜晚黑暗中運行測試，以滿足截止期限要求。

開發(fā)被控對象和基本控制器模型

隨著項目的推進(jìn)，我們開始在 Simulink 中開發(fā)救援梯的被控對象模型。該模型包括用于作動器位置、液壓、電流和 CAN 信號的傳感器。它還包括液壓系統(tǒng)的元件，如閥門和液壓缸。這些元件視制造商數(shù)據(jù)表中的信息而定。 除了被控對象模型，我們還使用 Simulink 和 Stateflow 開發(fā)了一個簡單的控制器模型。這個初始模型并未實現(xiàn)我們針對控制軟件提出的所有需求。不過，其功能足以讓我們了解機(jī)器將如何運轉(zhuǎn)，以及我們可能需要對硬件設(shè)計進(jìn)行哪些改進(jìn)（如果有的話）。

通過將控制器和被控對象模型相結(jié)合，我們創(chuàng)建了一個用于運行閉環(huán)仿真的系統(tǒng)級模型（圖 3）。仿真結(jié)果的分析影響了我們在以下方面的決定：將哪種液壓升降機(jī)用于救援梯，以及實施哪種類型的傳感器。例如，我們最初計劃在液壓缸上使用電流傳感器，但當(dāng)仿真顯示這些傳感器缺乏足夠的精度時，我們決定改用 CAN 傳感器。過去，這類設(shè)計問題只有等到開發(fā)過程的后期（即實車測試階段）才被發(fā)現(xiàn)。

圖 3. 包含被控對象和控制器子模型的系統(tǒng)級模型。

▼ 代碼生成和 HIL 測試

通過桌面仿真驗證了我們的早期控制設(shè)計后，我們很快便轉(zhuǎn)向了 HIL 測試。我們使用 Embedded Coder 從我們的被控對象模型生成了代碼，并將其部署到了一個 TTControl 的 TTC 580 ECU。我們還遵循同樣的流程從控制器模型生成了代碼，并將其部署到了另一個 TTControl 的 ECU。以實際控制器連接到救援梯的方式將這兩個 ECU 連在一起后，我們運行了 HIL 測試來確認(rèn)控制設(shè)計的實時性能，并驗證救援梯觸摸屏控制面板的操作（圖 4）。 我們還為 TTControl 公司從事安全軟件工作的同行提供了相同的 HIL 測試設(shè)置。這樣，該團(tuán)隊便能與我們同時工作，對他們正在開發(fā)的軟件進(jìn)行自己的測試，而無需登上實際的救援梯。這種 HIL 測試設(shè)置不僅使 TTControl 團(tuán)隊能夠加速他們的軟件開發(fā)，而且還能夠幫助他們開始在實際的救援梯上進(jìn)行測試之前便發(fā)現(xiàn)并解決一些問題。

▼ 車載測試和調(diào)試

當(dāng) TTControl 團(tuán)隊完成安全軟件開發(fā)時，我們繼續(xù)開發(fā)并完善控制應(yīng)用軟件。在這個過程中，我們使用代碼繼承工具 (https://ww2.mathworks.cn/help/simulink/sfg/integrating-existing-c-functions-into-simulink-models-with-the-legacy-code-tool.html) 將 TTControl 工程師手寫的電流和位置控制 C++ 代碼導(dǎo)入我們的 Simulink 模型。然后，我們繼續(xù)運行仿真和 HIL 測試，這不僅是為了驗證我們添加到控制應(yīng)用的新功能，而且是為了驗證另一個團(tuán)隊開發(fā)并交付的 C++ 代碼。 此時，我們已經(jīng)準(zhǔn)備好要在實際的救援梯上測試我們的控制器。我們再次使用 Embedded Coder 從 Simulink 模型生成了代碼，并將其部署到了 TTControl 的 ECU。但這次，我們不是將 ECU 連接到 HIL 設(shè)置，而是將其連接到了實際的救援梯，并運行了一系列車載測試。 我們通過仿真驗證的所有測試用例，也都在實際的救援梯上順利執(zhí)行。不過，我們確實發(fā)現(xiàn)了一些我們事先沒有考慮到的邊角情況，包括觸摸屏顯示器上的奇怪按鈕組合。通過在 Stateflow 的狀態(tài)機(jī)中插入額外的狀態(tài)和轉(zhuǎn)移，我們解決了這些問題（圖 5）。然后，我們運行了仿真來驗證所做的更改，重新生成了代碼，并在實際的救援梯上再次進(jìn)行了測試，以確保各方面都正常工作。以前，在我們手寫控制代碼時，凡是涉及添加狀態(tài)和轉(zhuǎn)移的更改，都需要相當(dāng)長的時間來實現(xiàn)和調(diào)試。

圖 5. 使用 Stateflow 設(shè)計的狀態(tài)機(jī)概覽。

▼ 在當(dāng)前項目中使用基于模型的設(shè)計

隨著救援梯現(xiàn)已投產(chǎn)，我們對所取得的成果做個總結(jié)。在性能方面，這些救援梯可以快速延伸到最高位置，其速度比我們之前的設(shè)計要快 20% 左右，這提高了緊急情況下的實際救援速度。從開發(fā)角度看，基于模型的設(shè)計幫助我們實現(xiàn)了更可靠的控制系統(tǒng)，而用時大約是以前方法的一半。 使用 Embedded Coder 從 Simulink 模型生成代碼，是我們提高開發(fā)速度的關(guān)鍵因素之一。為了更好地了解如何利用代碼生成，我們專門花時間學(xué)習(xí)了 Embedded Coder 的相關(guān)培訓(xùn)課程。除了幫助我們充分利用這款工具之外，這門課程還讓我們對于將代碼生成融入我們工作流的便捷程度大開眼界。以前，我們曾經(jīng)花費大量時間調(diào)試和維護(hù)手寫代碼。那時，我們并未意識到有那么多汽車行業(yè)的大型公司都在利用代碼生成實現(xiàn)生產(chǎn)控制軟件。憑借這一認(rèn)識，再加上我們自己在救援梯方面的第一手經(jīng)驗，我們的團(tuán)隊已將基于模型的設(shè)計推廣應(yīng)用到了其他幾個項目，包括目前正在開發(fā)的電動消防車的控制設(shè)計。

編輯：黃飛