1.6 X-in-the-Loop場景設計

X-in-the-Loop方法可集成仿真模型和真實組件，并充分應用現有工具和方法，可充分考慮駕駛員和外界環境對于需求和開發過程的影響。該方法的核心是當測試中出現部件缺失的情況時，利用模型或代碼替代缺失部件，實現軟硬件結合測試。

構建合適的應用場景是X-in-the-Loop方法的重點之一，因此構建合適且典型的測試場景，確定哪些測試項目可以實現，是應用X-in-the-Loop方法的重要工作。

X-in-the-Loop方法中的Model-in-the-Loop，即模型在環，意指被測對象的存在形式為模型，利用環內其他部件的軟件或硬件形式，對模型進行驗證和標定。模型在環的測試結果是軟件在環的重要參考。Software-in-the-Loop，即軟件在環，意指被測對象的存在形式為代碼，利用實時仿真平臺與環內其他部件的軟硬件進行數據交互，從而對代碼的準確性進行驗證。Hardware-in-the-Loop，即硬件在環，在傳統V模式開發中，指實際控制器與虛擬控制對象組成的仿真系統。在X-in-the-Loop方法中，硬件在環的范圍由狹義的控制器擴展到廣義的硬件，即被測對象的存在形式為硬件，利用環內其他部件的軟硬件對被測硬件進行測試驗證^[98]。

在燃料電池動力系統的測試驗證中，主要涉及的模型包括燃料電池模型、蓄電池模型、DC/DC模型、電機模型、整車模型、控制策略模型、駕駛員模型等，其主要信息見表1.5。

1.6.1 同步性方法設計

由于測試設備包含眾多硬件設備，并且硬件設備的通信協議不同。因此還需對測試設備的同步性進行設計。

首先，基于燃料電池汽車動力系統的測試需求，構建出通信架構及網絡拓撲，如圖1.8所示。該通信架構包括系統協調網絡、業務核心網絡、數據核心網絡、車載兼容網絡和設備控制局域網。其中，系統協調網絡采用以太網通信，業務核心網絡采用MODBUS通信；數據核心網絡用于模型數據的通信和燃料電池發動機測試數據的通信，對數據實時性要求較高，因此采用反射內存的通信方式；車載兼容網絡采用CAN通信；設備控制局域網絡即為測功機和服務器等高速設備與主控系統的通信網絡，采用EtherCat通信。

該系統應用NTP（Network Time Protocol，網絡時間協議）網絡同步技術。NTP是由RFC 1305定義的時間同步協議，用來在分布式時間服務器和客戶端之間進行時間同步。NTP基于UDP報文進行傳輸。使用NTP的目的是對網絡內所有具有時鐘的設備進行時鐘同步，使網絡內所有設備的時鐘保持一致，從而使設備能夠提供基于統一時間的多種應用。對于運行NTP的本地系統，既可以接收來自其他時鐘源的同步，又可以作為時鐘源同步其他的時鐘，并且可以和其他設備互相同步。

設備可以采用多種NTP工作模式進行時間同步，這里選擇“客戶端/服務器模式”（Client/Server，C/S）。在客戶端/服務器模式中，客戶端向服務器發送時鐘同步報文，服務器端收到報文后會自動工作在服務器模式，并發送應答報文，客戶端收到應答報文后，進行時鐘過濾和選擇，并同步到優選的服務器。

接著，進行系統實時性保障與設計。在一般情況下，一個操作系統負責管理計算機的硬件資源和在計算機上運行的應用程序。該操作系統主要部署在實時性保障計算機中，其對于通信數據和系統狀態的判斷最終會產生診斷策略和故障信息，指導協調系統解決當前問題。

其次，實施管理配置層在實時測試中將實時操作系統作為測試系統的一部分。與使用通用操作系統相比，推動實時測試系統最常見的需求是需要實現更高的可靠性和更高的性能。

最后，進行同步授時方法與規則的設計。整個系統授時工作是基礎性設計，涉及諸多關鍵數據同步。授時工作主要包含如下部分業務：網絡授時協議支持、時間標記、同步時鐘（心跳脈沖）。同步授時方法示意圖如圖1.9所示。

主服務器作為網絡通信的服務器和數據庫所在地主要負責服務器搭建和數據存儲的功能。數據以固定格式和寄存器地址傳遞，格式中包含數據校驗和協議固有特征，在應用層每段數據都由時間標簽和有效時間組成。實時性保障計算機校驗每段數據自有效性以及相互校驗，相互校驗過程基于網絡設計的冗余性，同時系統狀態上通過總線回傳心跳脈沖，心跳脈沖是系統同步性和活躍性的重要指標，本系統設計中處于任務狀態的執行主機都要發送心跳信號；凡是接入系統的任務主機也要更新心跳信號和狀態標識。

1.6.2 Model-in-the-Loop

Model-in-the-Loop（模型在環）的測試驗證對象為模型，組成環的其他部分為硬件或軟件。可利用動力系統主要部件模型作為測試驗證對象，模型運行環境為實時仿真器。當燃料電池模型/蓄電池模型作為測試驗證對象時，主控系統將燃料電池模型/蓄電池模型與電源模擬器相連，電源模擬器產生的電能由負載系統（電驅動系統或電子負載）消耗，從而實現燃料電池/蓄電池模型在環。當電驅動系統模型作為被測對象時，電驅動系統需求功率由工況信息決定，該需求功率直接由電源模擬器提供，由負載系統消耗，不受電源模型的電流電壓特性約束。

圖1.10為一種模型在環典型場景，即燃料電池模型測試驗證，該場景利用實時仿真器、電源模擬器和測功機等硬件和蓄電池模型、電驅動模型、整車模型等模型來實現燃料電池模型的驗證。工況信息可由駕駛模擬器采集，或由后臺數據庫提供。主控系統的主要功能為任務調度、運行整車模型與控制策略模型、通信調理等。實時仿真器主要運行動力系統關鍵部件模型，包括燃料電池及輔助系統和蓄電池等。電源模擬器的主要功能為根據模型數據提供電流電壓信號，并向電驅動系統輸出。其中燃料電池模型、蓄電池模型、電驅動模型和主控系統中的整車模塊（實現整車模型功能），構成了一個完整的燃料電池動力系統模型。

主控系統調用數據庫中的工況信息，由主控系統的整車模塊計算行駛阻力。根據行駛阻力，由電驅動模型提出功率要求，并由燃料電池發動機模型給出功率響應，該功率響應發往電源模擬器，該電源模擬器根據燃料電池發動機模型的輸出特性，產生模擬燃料電池發動機的電壓信號，該部分產生的能量由負載系統消耗。若負載系統為電機-測功機系統，則輸出實時轉速信號，由駕駛員模型根據期望車速和實際車速的差值調整電機轉矩。利用此類架構，可實現燃料電池模型的測試驗證，特別是燃料電池汽車動力系統的匹配測試，即在燃料電池缺失的情況下，利用模型與電源模擬器，構成完整動力系統。

與全仿真和純實物測試相比，使用模型在環的測試方法，可完成測試鏈中部分測試設備實體缺失情況下的測試驗證；在測試驗證過程中，可充分利用現有測試設備，將被測模型的輸出信號輸入相關測試設備中，實現模型信號的實時動態檢測。

1.6.3 Software-in-the-Loop

Software-in-the-Loop（軟件在環）的被測對象為代碼，組成環的其他部分為硬件或軟件。當被測對象為系統控制策略時，將系統控制策略生成代碼，利用軟件在環平臺，與動力系統模型連接，實現策略驗證功能，如圖1.11所示。當被測對象為系統控制策略和動力系統模型時，可將系統控制策略與動力系統模型均生成代碼，利用軟件在環平臺驗證。當被測對象為動力系統關鍵部件控制策略時（如電驅動系統），則將該部分控制策略生成代碼，其他部分仍為模型。

軟件在環測試可進一步實現模型的測試驗證，使得被測模型所生成的代碼可應用于硬件。軟件在環測試舉例中，代碼和模型均運行在實時仿真器中，在虛擬實時環境中將生成的C代碼用于控制部件模型，實現軟件在環平臺與Simulink仿真平臺的聯合仿真，借助實時仿真，改進和測試控制策略。

在X-in-the-Loop方法指導下的軟件在環，可將代碼驗證平臺與動力系統測試設備連接，將被測代碼的輸出信號輸入相關測試設備中，實現實時動態檢測。由于實驗條件所限，基于該測試平臺的軟件在環場景局限于包含被測代碼-模型、被測代碼-模型代碼兩類場景。

1.6.4 Hardware-in-the-Loop

Hardware-in-the-Loop（硬件在環）的被測對象為硬件，組成測試環的其他部分為硬件或軟件。由于測試手段的軟硬件組合方式靈活，可完成多種硬件在環測試驗證。

當被測對象為燃料電池發動機或動力蓄電池，即動力源部件時，可調用電源模擬器充當負載，或使用真實的電驅動系統充當負載。當被測對象為電驅動系統時，可利用真實的燃料電池發動機或動力蓄電池，或調用電源模擬器，作為動力源。測試所需其他部件可使用模型或實物。當被測對象為控制器時，該測試場景符合傳統意義上的硬件在環，除控制器為實體，其他部分均為模型。

圖1.12為基于該測試平臺應用的一種硬件在環典型場景，即利用實時仿真器、電源模擬器和測功機等硬件和燃料電池模型/蓄電池模型等模型來實現電驅動系統的匹配與性能測試。

在該類場景下，主控系統從綜合數據管理模塊調用工況信息，并利用系統控制策略模塊和整車模塊求得燃料電池發動機和蓄電池的需求功率，電源模擬器根據燃料電池發動機模型和動力蓄電池模型并聯后的特性產生電流電壓信號，并為電驅動系統提供能量，電驅動系統工作并拖動測功機。利用此類架構可實現在動力源部件缺失的情況下，燃料電池汽車動力系統的電驅動部分的匹配與性能測試。

在X-in-the-Loop方法中，硬件在環的定義由硬件僅指代控制器擴展為硬件指代被測對象，測試鏈中的其他部分可以為真實對象，也可用模型代替。因此利用X-in-the-Loop方法可構建靈活的硬件在環測試系統，實現動力系統關鍵部件的匹配和性能測試。

通過以上場景分析可總結：①模型在環：可利用動力系統主要部件模型作為測試驗證對象，當燃料電池模型/蓄電池模型作為測試驗證對象時，主控系統將燃料電池模型/蓄電池模型與電源模擬器相連，電源模擬器產生的電能由負載系統（電驅動系統或電子負載）消耗，從而實現燃料電池/蓄電池模型在環；②軟件在環：當被測對象為系統控制策略時，將系統控制策略生成代碼，利用軟件在環平臺，與動力系統模型連接，實現策略驗證功能；③硬件在環：當被測對象為燃料電池發動機或動力蓄電池，即動力源部件時，可調用電源模擬器充當負載，或使用真實的電驅動系統充當負載，當被測對象為電驅動系統時，可利用真實的燃料電池發動機或動力蓄電池，或調用電源模擬器，作為動力源。

1.6.5 X-in-the-Loop在分布式系統框架內的場景用例

根據分布式系統的文獻綜述可知，在互聯網上進行遠距離測試驗證是可行的。原則上，X-in-the-Loop的每個組件都可以在不同地理位置分布并與其他組件聯網。但是，根據驗證目標和邊界條件，應對X-in-the-Loop框架內的場景用例進行討論，以便確定應該怎樣結合分布式系統與X-in-the-Loop方法，哪些應用使用網絡驗證是有意義的，以及哪些影響因素對結果產生影響。

文獻[112]提出了在分布式系統架構中應用遠程連接的三種場景：兩系統操作層與操作層的連接，一系統操作層與另一系統業務層的連接，兩系統業務層與業務層的連接。

兩系統操作層與操作層的連接：該類場景中，主機不僅處理操作層本身的業務功能，同時也完成不同系統之間的通信業務。例如運用主機中的MATLAB/Simulink軟件，完成測試與通信業務，MATLAB/Simulink軟件與測試臺控制軟件具有良好的兼容性，可實現建立分布式主機之間的通信，以及實現通信軟件對測試設備數據的訪問。測試設備軟件通常具有與MATLAB/Simulink軟件集成的接口，也可用于在線數據傳輸。大多數情況下不需要額外的硬件和軟件且編程工作量較少。主機可能需要額外的網卡來分離與測試設備的通信以及與其他主機的通信。

一系統操作層與另一系統業務層的連接：該情況下，一臺主機可以控制多個測試設備，節省了主機的成本。所有涉及的測試設備允許訪問中央主機。出于安全等原因，在許多情況下，仍然需要本地主機來監控本地測試設備并在緊急情況下進行本地控制。測試設備的通信發生在中央主機內。因此，必須在主機中實現不同特定測試軟件之間的數據交換。

兩系統業務層與業務層的連接：該類場景中，由于測試設備的數據處理時間總是在一定的時間間隔內得到保證，因此該類場景的連接是三類場景中最快和最穩定的。但是該類場景下必須為測試設備提供用于在線數據傳輸的通信接口。由于測試設備的控制應該同時從操作層開始，因此不得中斷目標與其自己的主機之間的連接。出于安全原因，交換的信號也應操作層可見。

分析三種場景，可知第一種場景最容易實現，只需將兩系統的主機進行連接即可，可實現跨部門和公司使用。第二種場景往往適用于內部使用，第三種場景二者均可使用。

此外，分布式系統應用X-in-the-Loop方法還需考慮以下三個因素：是否需要考慮系統間耦合，將系統整合到本地的成本，以及網絡連接。因此根據以上因素，可用圖1.13度量分布式系統網絡化原則^[113]。