理想的系統模擬在元件設計工作流程中是一個完整的驗證步驟，讓工程師可以驗證元件是否符合系統要求，本文將描述一個在典型的敏捷開發工作流程管理和分享Simulink快取檔案的方法。

在敏捷（Agile）開發工作流程中，複雜系統設計仰賴多個大型團隊的共同付出來開發元件、組裝子系統、以及將其整合至系統設計。理想中，系統模擬在元件設計工作流程中是一個完整的驗證步驟，讓工程師可以驗證元件是否符合系統要求。然而，多次模擬一個具複雜模型階層的系統可能會耗費太多的時間。

Simulink提供一種加速大型模型參考階層的模擬的方法，也就是於首次執行模擬時建立一組中間衍生的人造產物（artifacts）。對於大型的團隊而言，共享及重複使用這些包含MEX檔和其他二元檔案的衍生檔案（derived files）可能具有一定程度的挑戰。

因此，團隊成員頻繁花費時間來重新建立和創造其他團隊成員已經建立過的檔案，耗費在這種多餘的功夫和時間，其實可以運用在更有生產力的設計活動上。團隊愈龐大、模型的複雜度愈高，問題也就愈大。

為了處理這樣的問題，Simulink將這些衍生的人造產物封裝，並儲存於Simulink快取（cache）檔案。本文將描述一個在典型的敏捷開發工作流程管理和分享Simulink快取檔案的方法，其中會使用到Git來進行來源管控，以及Jenkins來進行持續整合（continuous integration；CI）。這種方法對系統模擬的加速有相當不錯的效果。

Simulink快取

當在加速器、快速加速器、或模型參考加速模式進行模型模擬時，Simulink會將每一個模型的衍生檔案依照層級打包至對應的Simulink快取檔案（Simulink cache file；SLXC）。團隊成員之間可以共享這些SLXC和對應的Simulink模型檔。當某個團隊成員在機器重新做了模擬，Simulink會從SLXC檔為每一個模型擷取必要的衍生檔。這樣下來，Simulink不用去執行非必要的重建，模擬完成的速度也明顯提升。

實際性能表現的改善仰賴於幾個因素，像是層級之中的模型數量、模型參考重建設定、參考模型當中的模塊數量、為每一個模型建立的衍生檔案的大小和數量。在我們經由內含0-500個參考模型和1-10個階層等級等各種模型的測試，我們看到了從2倍到超過34倍不等的改善程度（圖1）。

圖1 : 透過使用各種系統模型的Simulink快取檔案所達成的性能改善

在包含了Jenkins CI系統的敏捷工作流程內分享和重複使用Simulink快取檔的流程有三個階段（圖2）：

一、將設計變更提交給Git

二、整合設計變更和將SLXC檔案歸檔

-- Jenkins從Git拉出設計變更，並執行模擬來測試這些變更

-- Jenkins將Simulink快取檔儲存至Jenkins建置（build）檔案資料庫

三、進行設計變更與SLXC檔的同步

-- 團隊成員從Git以及從Jenkins建置檔案資料庫同步最新的設計變更

-- 團隊成員使用這些快取檔執行系統模擬

圖2 : 重複使用帶有來源管控和持續整合系統的Simulink快取檔的典型工作流程。陰影區塊描述了工作流程的三個階段。

在更進一步看到這些階段之前，我們先考量使用Simulink快取的要求與最佳實務。

分享和重複使用Simulink快取檔的要求與最佳化實務

Simulink快取所包含的衍生檔案會受到MATLAB版本、作業平台、及在模擬中使用的編譯器的影響。為了要分享和重複使用這些檔案，所有的團隊成員必須使用相同的MATLAB版本、作業平台、和編譯器。本文中使用的分別是MATLAB R2019a版本、Microsoft Windows、和Microsoft Visual C++ 2017。

以下最佳化實務可以透過重複使用共享的快取檔案，讓大型階層模型模擬的加速更為容易：

‧ 依模型選擇適合以元件為基礎的建模準則來遵循（舉例來說，在階層當中的參考模型，通常應該包含超過500個模塊以達成最佳的模擬表現）。

‧ 讓每一個團隊成員負責一個階層的子集—通常會有幾個Simulink模型構成一個元件，像是經過妥善定義的介面的控制器或受控體。這可以在合併設計變更時將問題最小化。

‧ 使用包含啟動和停機程式腳本的專案，以確保所有團隊成員處於一致的工作環境。啟動腳本在專案開啟時將環境初始化，而停機腳本則在專案結束時清除環境。

‧ 在加速器（Accelerator）模式下參考所有模型。在本地機器的參考模型除錯時，則使用正常（Normal）模式。然而，這個模式並不提供和加速器模式相同的模擬表現益處。

‧ 設定每一個模型的重建（Rebuild）參數，以因應在已知的相依性下偵測到任何變動（圖3），以及使用模型相依性（Model dependencies）參數來指定由使用者建立的相依性，這可以改善重建偵測的速度和準確度。

圖3 : 模型配置參數

‧ 如果使用了平行運算工具箱（Parallel Computing Toolbox），選擇Enable parallel model reference builds （圖3）。這個模型參考階層將自動地被平行建立。

‧ 決定是否要在每一次提交的時候執行Jenkins建置，或者在一天的特定時間執行，還是只有在需要的時候執行。所特定的要求將影響最佳運行時機，以及要選擇使用以下哪一種建置：

o Sterile：在這個建置中，Jenkins的工作區域不會有人造產物或從之前的Jenkins建置留下來的檔案。如果團隊頻繁地變更Simulink模型結構，則適合使用Sterile建置。比如在Simulink模型階層需要的乾淨工作區域改變硬體設定。

o Incremental：在這個建置，先前Jenkins建置留下的人造產物都被保留下來。如果團隊僅在個別元件做了些微的增值變更，就適合使用Incremental建置。

Sterile建置視模型階層的大小不同，通常比起incremental建置需要更多的時間。

提交設計變更至Git

團隊成員在這一個步驟當中變更模型、模擬模型階層、執行Model Advisor檢查、和執行單元測試。團隊成員僅提交他們的設計檔到來源管控系統，如Git。Simulink快取檔不應被提交至來源管控系統；他們是衍生的二進位檔案，會佔據大量的空間且不能被比對或合併。在Git儲藏庫，你可以配置一個.gitignore檔案讓Git忽略所有衍生人造產物，包含SLXC檔案。

整合設計變更和SLXC歸檔

透過這篇文章，可以了解Jenkins與Simulink搭配使用的準則和配置技巧。

在以下範例，Jenkins管理者在Jenkins指定了Build指令。該指令開啟MATLAB，為模擬加速的極大化建立快速加速器目標，並執行測試。圖4為開啟Simulink專案的指令，MyJenkinsProject和執行myBuildAndTest程式腳本。

圖4 : Jenkins建置指令的說明，該指令開啟了Simulink專案並執行myBuildAndTest程式腳本。這個程式腳本為系統建立了快速加速器目標，並且執行多次模擬來測試變更。

使用這組程式腳本，Jenkins為模型階層建立了快速加速器目標：

Simulink.BlockDiagram.buildRapidAcceleratorTarget（'model'）;

這個指令建立了SLXC檔，裡面包含快速加速器與階層當中所有模型的模型參考模擬目標。Simulink將這些SLXC檔儲存在模擬快取資料夾。資料的位置是由Project Details 來指定（圖5）。程式腳本接下來會執行多次模擬來測試設計變更。

圖5 : Project Details對話框指定存放了SLXC檔案的快取資料夾位置。默認設定為[project root]。

除此之外，管理者在Jenkins設置一個 Post-build Action 來將SLXC檔歸檔（圖6）。建置之後，Jenkins會從Jenkins工作區域將SLXC檔複製到建置歸檔的位置。如果要指定Jenkins建置歸檔位置，管理者可以在Jenkins的home索引下編輯config.xml檔。

圖6 : 配置Jenkins建置後動作（post-build actions），在建置完成之後，將所有Simulink快取檔從Jenkins工作區域歸檔到建置歸檔區域。

設計變更和SLXC檔的同步

通常Jenkins建置是在晚上執行。團隊中每一位成員接著準備將沙箱（sandbox）依上一次的成功建置來進行同步。團隊成員從Git檢查設計變更，從建置歸檔區域將關聯的Simulink快取檔回收，並在模擬之前將Simulink快取檔放置在他們的模擬快取資料夾。團隊可以設置一個腳本來自動化這些過程。比如，下列腳本概述了同步Simulink快取檔的主要步驟：

圖7 : 同步Simulink快取檔的主要步驟概述

改善工作流程

有幾種方法可以讓工作流程更快、易錯（error-prone）更少發生。例如可以使用資料庫或是存放管理工具，更容易地從多個Jenkins建置管理SLXC檔。若要讓自動執行MATLAB和Simulink測試作為專案工作的一部分，可以使用MATLAB Plugin for Jenkins。最後，可以使用parsim執行多次系統模擬來測試各種輸入參數值來進一步提升模擬的性能表現。

（作者Puneet Khetarpal、Marco Dragic任職於MathWorks公司:本文由鈦思科技提供）