功能模型接口FMI（Functional Mock-up Interface）是一個開放且與工具解耦的標準。FMI包含了一個C-API（接口），一個用于描述接口的XML文件以及可交換的功能模型單元FMU（Functional Mock-up Unit），通常會是“zip”文件。FMI實際上是提供了容器化形式的模型，能夠在不同的目標上輕松進行重復使用和部署，實現(xiàn)在不同的自動駕駛仿真工具之間動態(tài)交換仿真模型和聯(lián)合仿真。

一、FMI的使用

1、導入和導出工具

通常來說在使用FMI時會有包含導入和導出工具。

導出工具通常是開發(fā)模型的地方，能夠將模型按照FMI標準打包為FMU；導入工具通常獨立于導出工具，可以在外部設置由C-API定義的一個變量、一個值或是觸發(fā)一個計算步驟，在接收FMU后在，可以在導入工具中與其他模型結合并實現(xiàn)聯(lián)合仿真。

實際上FMI標準只定義了一個FMU的接口，在多個FMU進行耦合并實現(xiàn)聯(lián)合仿真時，F(xiàn)MI標準并不涉及到的聯(lián)合仿真算法或是FMU 的求解器。

2、FMU文件結構

FMU作為模型的容器能夠自由的進行分發(fā)，通常來說是一個以".fmu"結尾的zip文件。

在一個FMU文件中，至少包含了一個模型描述文件，其描述了模型變量、接口、能力以及模型架構擴展限制的元數(shù)據(jù)信息。

還至少包含了一個二進制的模型表示，在Linux系統(tǒng)下是.so文件，在window系統(tǒng)中是dll文件。也可以是C源碼，能夠讓使用者進行重新編譯創(chuàng)建一個新的二進制文件用于新的目標，這一部署機制可以方便的擴展到不同的系統(tǒng)平臺上。

除此以外，可能還包括額外的文件，比如模型文檔和相關的頭文件。

3、FMI 2.0和FMI 3.0

FMI2.0包括：

帶有事件的常微分方程（ODEs），這些方程描述了系統(tǒng)的動態(tài)行為，需要通過數(shù)值求解器來進行求解；

連續(xù)和離散變量，即FMI的模型中，變量可能是隨時間變化，也可以是在特定時間點發(fā)生變化；

時間概念，或可以理解為更廣泛的獨立變量，或是自變量，比如可以是一個角度，從而表述系統(tǒng)的動態(tài)變化。

FMI3.0增加：

不僅限于動態(tài)方程，也支持純代數(shù)方程，可以處理不隨時間變化的靜態(tài)關系；

進一步支持了復雜的離散行為，即通過使用始終和模型分區(qū)來管理模型的順序和同步；

同時不僅僅是基于物理的方程還可以：

vECU模型

機器學習模型

AI模型

......

二、FMI 3.0.1中的聯(lián)合仿真

1、多個仿真程序耦合

聯(lián)合仿真時將多個仿真程序耦合在一起，最終實現(xiàn)由多個子系統(tǒng)組成整理自動駕駛HiL系統(tǒng)的行為。

2、子系統(tǒng)耦合

子系統(tǒng)之間是互相耦合的，也就是每個子系統(tǒng)的行為依賴于其他子系統(tǒng)的行為，所以聯(lián)合仿真必須是以逐步計算的方式進行。

3、示例

每個仿真程序負責計算一個子系統(tǒng)的行為，比如在自動駕駛HiL系統(tǒng)中，aiSim負責場景和傳感器仿真，CarSim負責車輛動力學，兩個仿真程序互相使用對方產生的輸出來進行計算。

CarSim中車輛動力學更新的頻率時1kHz，那么需要同步aiSim中場景更新的頻率也為1kHz，而且只有在收到動力學信息后才會進行下一步的仿真。

4、同步和誤差管理

在聯(lián)合仿真的過程中，可能會產生附加誤差，需要通過合適的聯(lián)合仿真算法或是通信模式來將其限制在可接受的范圍內，比如設置更新步長等。

作者介紹

崔工

康謀科技仿真測試業(yè)務技術主管，擁有超過5年的汽車仿真測試及自動駕駛技術研發(fā)經驗，熟練掌握仿真測試工具和平臺，如aiSim、HEEX等，能有效評估和優(yōu)化自動駕駛系統(tǒng)的性能和安全性。擁有出色的跨文化溝通能力，成功帶領團隊完成多項海外技術合作項目，加速了公司在自動駕駛技術上的國際化進程。作為技術團隊的核心，領導并實施過大規(guī)模的自動駕駛仿真測試項目，對于車輛行為建模、環(huán)境模擬以及故障診斷具有獨到見解。擅長運用大數(shù)據(jù)分析和人工智能技術，優(yōu)化仿真測試流程，提高測試效率和結果的準確性。