隨著車載網絡發展，ECU的通訊速率相較以往得到飛速提升?，F今多數OEM在中高速通訊場景中仍采用CANFD進行過渡，但當同時考慮安全和更高帶寬時，CANFD則無法滿足，因此FlexRay成為部分OEM的首要選擇。其中控制各ECU的睡眠喚醒依舊利用耳熟能詳的NM網絡管理實現。

下面跟隨小懌一起了解FlexRay網絡管理及相關測試吧。

01?FlexRay網絡管理簡介

01?報文格式

FlexRay網段通信時為了表示各ECU表示自身是否加入網絡，特意在NM報文中引入Vote投票位，當Vote=1時代表加入網絡，Vote位是否有效取決于FlexRay-NM狀態機。

FlexRay-NM報文格式及內容如下所示：

其中針對CBV字節的BIT信息定義如下：

02??FlexRay-NM狀態機

POC：Protocol Operation Control，協議操作控制，簡稱POC狀態機

PNC：Patiral Network Control，局部網絡控制，簡稱PNC狀態機

SWC：Software Component，應用層軟件組件，負責實現不同功能

WUP：Wakeup Pattern，FlexRay喚醒信號，以低高電平呈現

FlexRay網絡管理設計類同于CAN網絡管理設計，不同的是FlexRay的網絡管理為了更清晰的劃分局部網絡，同一FlexRay網段下根據ECU功能劃分了PNC網關、非PNC網關與不支持PN三種。其中ECU的休眠、喚醒、同步的時機由NM狀態機決定；各ECU狀態由自身POC狀態機控制負責實現；喚醒狀態時，各SWC映射至PNC的相關報文是否發送由PNC狀態機與ComM channel狀態機共同決定。測試時僅關注PNC狀態機即可，也就是PNC網關的網絡管理報文對應PNCID是否置1，這一信息部分OEM也布置了VFC報文進行體現。

再簡而言之，在FlexRay網絡管理與CAN/CANFD網絡管理測試不同點為NM狀態機跳轉與PNC狀態機Map-Frame的一致性。今天我們主要介紹FlexRay-NM狀態機的跳轉機制。

FlexRay-NM狀態機模式有三大三小，后文有關狀態描述采用對應縮寫：

BSM：Bus Sleep Mode，總線睡眠模式

SYM：Synchronize Mode，同步模式

NM：Network Mode，網絡模式

Network Mode模式中包含三個子狀態：

RMS：Repeat Message State，重復消息狀態

NOS：Normal Operation State，正常操作狀態

RSS：Ready Sleep State，準備睡眠狀態

FlexRay-NM狀態機與CAN-NM狀態機唯一不同的是取消了PBM預睡眠模式，并引入同步模式給與全局時基同步時間。各個狀態跳轉的條件基本取決于NM-Timeout-Timer、Repeat-Message-Timer、Wait-Bus-Sleep-Timer及網絡是否釋放。具體的跳轉條件如下：

Condition1：本地喚醒請求

Condition2：接收網絡管理報文成功

Condition3：發送網絡管理報文成功

Condition4：Repeat-Message-Timer超時

Condition5：不進行本地喚醒請求

Condition6：NM-Timeout-Timer超時

Condition7：配置FlexRayNmPnEnabled=False并且網絡請求

Condition8：Wait-Bus-Sleep-Timer超時

Condition9：配置FlexRayNmPnEnabled =True并且重復消息請求

Condition10：POC狀態機完成同步

Action1：初始化

Action2：初始化NM-Timeout-Timer

Action3：開始Repeat-Message-Timer

Action4：開始Wait-Bus-Sleep-Timer

了解了FlexRay網絡管理的基礎知識，下面跟隨小編一起學習下網絡管理中FlexRay不同于CAN的部分測試吧。

02?FlexRay網絡管理測試

01測試環境搭建

基于Vector的基礎測試環境

懌星自研的FlexRay自動測試臺架由上圖Vector基礎測試環境再搭配自研ETS6210、EH6466板卡共同構成，可同時實現FlexRay單節點、系統級、網絡管理以及診斷刷寫測試。基于CDD的診斷實現同樣滿足OEM在FlexRay節點診斷協議的不一致性，常見的診斷協議為DoIP、FlexRay、CAN。測試中為避免CANoe中POC狀態機重啟將影響網絡管理測試，在Network Hardware中配置如下：

當被測件為冷啟動節點時，為保證網絡啟動時被測節點的冷啟動優先級，還需取消CANoe的冷啟動功能：

02Vote投票位測試

測試方法：利用CANoe發送WUP喚醒電平，仿真帶有請求所有PNC的有效網絡管理報文，監測ECU發出網絡管理報文中Vote有效性。

發送喚醒報文后，ECU的NM報文Vote=1

前文所述，Vote有效代表節點自身加入網絡，可以概括為Vote在需要節點通信時總是有效，具體的變化如下：

·?本地喚醒/網絡喚醒進入RMS狀態時Vote=1

·?本地喚醒/網絡喚醒維持進入NOS狀態時Vote=1

·?網絡被釋放且NM-Timeout-Timer超時后Vote=0

·?Wait-Bus-Sleep-Timer超時后Vote不再發送

03?BSM-RMS測試

測試方法：利用CANoe發送WUP喚醒電平，仿真vote=1有效網絡管理報文，監測ECU發出網絡管理報文中Vote的發送次數與PNC信息。

發送喚醒信號后，ECU的NM報文持續10個NM-Cycle

FlexRay采用時隙（時間片）傳輸，因此處于靜態段的網絡管理報文傳輸無法像CAN一樣在RMS狀態設置快發送，但仍然規定了網絡管理報文的發送次數，通常配置為10個NM-Cycle。基于FlexRay的10Mbit/傳輸，網絡管理報文周期相較于CAN仍加速3-4倍，相較于CANFD加速1-2倍，這也取決于NM-RepCycle的設置。BSM-RMS狀態測試正是檢測此項機制。監測實現采用on frframe事件，測試時最好設置同一Cycle中仿真的網絡管理報文時隙ID大于被測的網絡管理報文，大家可以參照Lin協議的調度表運行考慮不這樣做會有什么bug，又有哪種方法可以解決？

04?PNC掩碼測試

測試方法：利用Arxml解析后的PNC-PDU-Signal Group信息，使用CANoe發送WUP喚醒電平，仿真帶有不同PNCID的有效網絡管理報文，監測ECU相關PDU的Signal Group是否更新。

分別發送PNCID=16,17的NM報文

前文所述，FlexRay節點為安全與高速服務，任何節點的通信都必須保證，因此在整車網絡中各冷啟動節點常被配置為PNC網關，那PNC掩碼喚醒/喚醒維持測試就必不可少了。測試中需注意on frpdu事件無法抓取object::name，必須將Arxml文件中的信息提取并根據object::FR_cycle與object::FR_slotID做匹配。Capl提供主要抓取對象如下：

on frpdu事件主要對象

以上，就是本次給大家分享的全部內容啦。小懌相信隨著OEM對于整車功耗標準的不斷提升，FlexRay的優點與管理用戶數據的PNC狀態設計在未來將會有更多運用。限于篇幅，內容不詳之處如果您還有疑問，歡迎下方留言，也可隨時聯系我們呦！

參考資料

1.《FlexRay Protocol Specification_V2.1》

2.《Specification of Communication Manager??AUTOSAR CP Release 4.3.0??》

3.《AUTOSAR SWS CANNetworkManagement-4.3.0》

---

喜歡此篇文章歡迎評論、收藏、分享支持小編~

總結

以上是生活随笔為你收集整理的FlexRay网络管理与测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。