11月29日，德思特2023年度TMTS汽車電子仿真及測試研討會圓滿結束。感謝大家的觀看與支持！

在直播間收到一些觀眾的技術問題，我們匯總了熱點問題并請講師詳細解答，在此整理分享給大家，請查收！

面向汽車T-BOX與域控制器的HIL測試新方案

Q：目前全球一共只有100多顆衛星，為什么你們的模擬器需要模擬那么多的通道？有什么應用嗎？

衛星數量和模擬仿真通道不是等同的，我們一般在GNSS模擬仿真中的搜星通道一般指的是：每個通道代表一顆衛星輸出的一個星座的一個頻點。這樣算下來的話，如果需要同時仿真世界上所有的衛星與頻點，則一共需要上百個通道。此外伴隨著多徑效應模擬、多待測件/多車模擬，以及一些新的應用，需要的通道數就會更多，我們保證了用戶模擬的全面性，以及對于未來的擴展性。此外，這些通道是免費開放給用戶的，無需額外付費。

Q：軟件定義形式有什么優勢呢？我自己也可以搭建？

軟件定義顧名思義，就是以軟件為核心，一方面他帶來了靈活性、擴展性以及經濟效益；此外核心軟件Skydel帶來了大量獨特的功能，他不因為硬件的變化而改變，最大程度上提供了高性能仿真能力。我們也歡迎用戶自己去搭建GNSS模擬器，在Skydel的基礎上，采用自己的硬件，我們有提供豐富的指導文件。

Q：能詳細介紹下軟件定義架構與硬件驅動的區別嗎?

軟件定義架構（Software-Defined Architecture）和硬件驅動之間有幾個主要的區別：

● 抽象層級：軟件定義架構通過在軟件中定義和管理資源，引入了一個抽象層級，使得應用程序可以通過軟件界面來訪問和管理底層資源。而硬件驅動是直接與硬件設備交互的程序。

● 靈活性和可編程性：軟件定義架構通過軟件配置和管理資源，具有更高的靈活性和可編程性，可以根據需求動態改變資源分配和配置。相比之下，硬件驅動的功能和性能通常是固定的，不容易變更。

● 硬件依賴性：軟件定義架構減少對特定硬件的依賴，通過引入抽象層級可以在不同的硬件環境中運行。而硬件驅動通常是為特定硬件設備或芯片定制的，對其他硬件可能不適用。

簡而言之，軟件定義架構通過軟件對資源進行配置和管理，具有靈活性和可編程性，并減少對特定硬件的依賴。而硬件驅動直接與硬件設備交互，是硬件資源的控制和管理。

Q：請問軟件在環與硬件在環的具體操作是？

GNSS模擬器在軟件在環與硬件在環中的使用方法類似，區別在于是否真正地輸出了射頻信號。這里我以硬件在環為例進行介紹。

用戶實時發送真實的車輛軌跡，并生成相應的GNSS射頻信號。圖中描繪了一個閉環，其中真實位置傳輸到系統中，自動駕駛儀應用命令實時影響車輛軌跡。系統中的HIL模擬器和Skydel GNSS模擬器造成的附加延遲必須足夠小，來保障不會對自動駕駛儀和GNSS接收器性能的測試和測量產生負面影響。整體系統框圖如下：

物理連接上：

a) 物理連接上HIL仿真器和GNSS模擬器采用以太網聯接

b) 通信協議采用TCP/IP,真實位置信息傳輸通過UDP協議

c) 提供開放API用于Skydel軟件的開放編程與遠程控制

d) 另外需要借助時鐘裝置對HIL模擬器與GNSS模擬器做同步

此外， 德思特提供了一個Skydel HIL客戶端（Skydel HIL Client），這是一個提供簡單API的庫。強烈建議使用此庫，不要嘗試與Skydel重新實現通信協議。Skydel HIL客戶端需要以太網連接，并且對大多數命令混合使用TCP/IP，對真實位置數據使用UDP。Skydel HIL客戶端增加了延遲，延遲主要由以太網連接定義。

Q：多實例和多輛車是一個概念嗎？

這是一個包含概念，多輛車屬于多實例仿真的一種，我們認為在同一臺設備內進行的多個獨立且實時的仿真場景或軌跡，就是多個實例。因此，多實例可能的情況是：

● 多天線：例如同一輛車或者飛機的多個天線，每根天線獨立使用，具有獨立的信號采集與分析功能，因此是多實例。

● 多車或多無人機：模擬場景下多個實體的交互、運行等，屬于多個獨立信號的運行，因此是多實例。

● RTK：因為同時具有基準站與流動站兩個獨立實體，因此是多實例。

汽車總線物理層測試方案

Q：你們的數字化儀是PCIe什么標準？是不是主機帶有匹配的插槽就可以開始使用？對工控機有什么要求嗎？

我們不同的數字化儀對應的PCIe標準不一樣，低速采集的板卡是4.0的標準， 中高速的采集卡是PCIe8.0或者16.0. 主板帶有對應插槽就可以，并且您有8.0的插槽條，可以兼容4.0的插槽。

Q：這個數字化儀有觸發輸入接口嗎？只能采集模擬信號嗎？

有的，我們有觸發輸入的接口，本身的采集通道也可以作為觸發通道。數字化儀除了模擬信號，我們還有預留的16個數字IO通道，數字IO和模擬IO可以同時采集。當然如果您只是想獲取數字IO，我們也有很多數字IO板卡提供。

汽車大電流注入測試

Q：開環和閉環法怎么選擇？依據是什么？

開環和閉環方法是以測試布置為依據來做區分，不同的方法測試布置要求明顯不同，測試結果也有差異，相對而言，閉環測試法的要求更加嚴苛。一般來說，我們測試標準中會有規定需要用哪種測試方法，如果沒有規定需要自己選擇，那么選擇開環還是閉環法主要取決于你的產品設計和測試要求。如果你的產品設計和測試要求較為嚴格，那么可能需要選擇閉環法。如果你的產品設計和測試要求相對較為寬松，那么開環法可能是一個更好的選擇。總的來說，選擇哪種方法主要取決于你的具體需求和情況。在做出選擇時，你可能需要考慮你的產品設計、測試要求以及你的資源和能力。

Q：你們的報告生成器可以生成的文件有哪些內容呢？

生成報告分為三個步驟。首先，創建或者選擇一個模板文件作為報告的基礎。然后設置所需的報告生成器設置。最后生成并檢查測試報告。

①模板文件可以采用Microsoft Word、Microsoft Excel或文本格式制作。

②選擇模板文件并確定報告內容后即可生成報告，模板文件中包含各個測試的代碼（只列舉了幾項）。

③報告生成器可以生成圖形文件和表格文件，報告生成器已進行擴展，不僅可以更輕松地指定應包含哪些圖表，而且甚至可以在一個圖表中包含多條“線”。可以生成不限于以下內容：

● 組合多條圖表線

● 單頻段多頻段測試中產生的所有數據的記錄，包括像輻射抗擾中生成的磁場圖

● 可定制的AD通道測量表

Q：請問你們的套裝支持什么標準呢？

從上圖可以看出，我們的套裝支持，國際標準，國家標準，除了表格中說到的這一些，由于我們能產生大于200 mA的電平等級且產生的頻率范圍覆蓋我國車企的標準。那么我們還支持絕大部分車企的標準。

汽車傳感器仿真和信號分析

Q：我看直播里面講的傳感器仿真是基于壓阻式的基本傳感器，那對于智能傳感器，比如MEMS這種可以仿真嗎？

這個比較復雜的智能傳感器集成了部分芯片，主控在里面，這個是我們仿真板卡做不到的。不過這種情況，一般是針對于自動駕駛里面應用居多，都是在軟件層上去做仿真模擬。如果您有這種仿真測試的集成需求，也可以找我們，我們背靠研發團隊，是可以給您完全的解決方案的。

Q：如果我想做一套故障注入的測試系統，但是想用網線去控制，可以實現嗎？

這個也是可以做到的，我們有這種LXI機箱，插入PXI板卡，可以通過以太網或者USB去控制。

面向自動駕駛與智慧城市的C-V2X與C-ITS方案

Q：Sdk 支持哪些軟件語言，或者軟件集成開發環境？

支持C和Python的語言。軟件集成開發環境要求如下：

1.操作系統要求：Ubuntu Linux 18.04或更高版本。

2.V2X設備要求：安裝、授權并運行德思特V2X軟件堆棧。

3.Python SDK要求：

- pip3包管理器，用于安裝Python軟件包。

- Python 3.7或更高版本，用于運行Python示例。

4.C SDK要求：

- 開發者環境，例如build-essentials、cmake等，可以從.c源代碼生成可執行文件并運行

Q：你們提供的這個應用程序和高德、百度這些有什么區別？

最大的區別就是它顯示基于V2X的數據，并顯示情境警告。例如前方碰撞警告等一系列的應用場景，可以在車載顯示屏上顯示，也可以與后視鏡集成，相較于直接使用手機會有更大的安全性，不易分散注意力。而且是不需要蜂窩網絡連接就能實現提醒，在沒有信號的情況下或者信號差的情況下也可以使用。

Q：你們的V2X協議棧有指定的硬件？

我們的V2X協議棧沒有指定硬件，它支持國際上目前常用的ETSl、ISO、IEEE、SAE、CAICT、CAICV、CCSA定義的標準和指令，以及C2C-CC、C-Roads、NISSTC的配置文件。

Q：V2X消息接口怎么訪問呢？

我們的V2X堆棧提供了SDK，可以整合車輛數據（例如CAN接口提取的專有車輛數據等）發送來源更加豐富的V2X消息，也可以是發送自定義的V2X消息，同時可以處理接收到的設備消息（包括其他車輛和道路基礎設施、傳感器等）和自定義消息。更多詳細信息可以聯系德思特技術工程師獲取《德思特V2X軟件棧和SDK的使用指南》，其中對于具體案例和訪問方法都有介紹。