精品国产人成在线_亚洲高清无码在线观看_国产在线视频国产永久2021_国产AV综合第一页一个的一区免费影院黑人_最近中文字幕MV高清在线视频

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

AUTOSAR UDP網絡管理策略

智能汽車電子與軟件 ? 來源:汽車通信技術 ? 2023-09-27 16:51 ? 次閱讀

什么是UdpNm

UdpNm,AUTOSAR UDP Network Management,基于TCP/IP協議棧,主要目的是協調網絡在normal operation和bus-sleep mode之間的轉換。除了核心功能以外,還提供了可選功能,例如,實現一個服務來檢測所有當前節點或檢測所有其他節點是否準備好休眠。UDP網絡管理(UdpNm)功能提供網絡管理接口(Nm)和TCP/IP協議棧(TCP/IP)之間的適配

12a56eb2-5d11-11ee-939d-92fbcf53809c.png

擴展AUTOSAR的通信協議棧

從上圖可以看出:

UDP網絡管理(UdpNm)使用TCP/IP協議棧的服務(SoAd)并向通用網絡管理接口(Nm)提供服務

有幾個注意點:

一個UdpNm實例只與一個網絡中的一個NM簇相關聯,一個NM簇在一個節點中只能有一個UdpNm實例

一個UdpNm實例僅與同一ECU內的一個網絡相關聯

UdpNm僅適用于基于TCP/IP的系統

UdpNm實例表示udp網絡管理在ECU中的實現,它是NM簇在ECU中的實例化。所以NM簇,又叫網絡管理集群,是UdpNm實例的集合。NM集群和UdpNm實例,可以看成是面向對象編程中的類與實例化

UdpNm中需要注意兩個代碼文件:

UdpNm_Lcfg.c

配置link時間參數

UdpNm_PBcfg.c

配置后期構建時間參數

UDP網絡管理策略

AUTOSAR UdpNm基于分散的網絡管理策略,這意味著每個網絡節點僅根據通信系統內接收和/或傳輸的UDP數據包執行自給自足的活動

AUTOSAR UdpNm的協調算法基于周期性的網絡管理數據包,由集群中的所有節點通過廣播傳輸的方式接收。接收到網絡管理數據包表明發送節點希望保持NM集群處于喚醒狀態。如果任何節點準備好進入Bus-Sleep模式,它就會停止發送NM數據包,但只要收到來自其他節點的NM數據包,它就會推遲轉換到Bus-Sleep模式。如果在專用計時器內沒有收到NM數據包,則每個節點都會啟動Bus-Sleep模式的轉換。如果NM集群中的任何節點需要總線通信,它可以通過發送NM數據包來讓NM集群保持清醒

AUTOSAR UdpNm協調算法的主要概念可以通過以下兩個關鍵要求來定義:

只要需要總線通信,每個網絡節點都應發送周期性的網絡管理數據包;否則不應該發送網絡管理數據包

如果UdpNmStayInPbsEnabled被禁用,并且UdpNm集群中的總線通信被釋放,并且總線上沒有網絡管理PDU(數據包),則應執行由UdpNmTimeoutTime + UdpNmWaitBusSleepTime(兩個配置參數)確定的可配置時間值轉換到Bus-Sleep模式

AUTOSAR UdpNm協調算法的整體狀態機定義如下:

從NM集群中單個節點的角度來看,AUTOSAR UdpNm狀態機應包含AUTOSAR UdpNm協調算法所需的狀態、轉換和觸發器

操作模式

AUTOSAR UdpNm包含三種操作模式:

Network mode

網絡模式

Prepare Bus-Sleep mode

總線預休眠模式

Bus-Sleep mode

總線休眠模式

AUTOSAR UdpNm操作模式的變化應通過回調函數通知上層

Network Mode

網絡模式包含三個內部狀態:

Repeat Message State

Normal Operation State

Ready Sleep State

當從Bus-Sleep Mode或Prepare Bus-Sleep Mode進入Network Mode時,默認進入Repeat Message State

當進入網絡模式時,應啟動NM-Timeout定時器

當進入網絡模式時,UdpNm將通過調用Nm_NetworkMode通知上層

在網絡模式下成功接收到NM PDU(調用UdpNm_SoAdIfRxIndication)后,應重新啟動NM-Timeout定時器

在網絡模式下傳輸NM PDU(使用E_OK調用UdpNm_SoAdIfTxConfirmation)時,應重新啟動NM-Timeout定時器

NM-Timeout定時器每次啟動或重新啟動時都應重置

- Repeat Message State

對于不處于被動模式的節點,Repeat Message狀態確保從Bus-Sleep或Prepare Bus-Sleep到網絡模式的任何轉換對于網絡上的其他節點都是可見的

當從Bus-Sleep模式、Prepare-Bus-Sleep模式、Normal Operation State或Ready Sleep State進入Repeat Message State時,應(重新)開始NM數據包的傳輸,除非啟用被動模式

當NM-Timeout定時器在Repeat Message狀態超時時,NM-Timeout定時器應重新啟動

網絡管理應在由UdpNmRepeatMessageTime(配置參數)確定的可配置時間內保持在Repeat Message狀態;在那之后,會離開Repeat Message狀態

當離開Repeat Message狀態時,如果網絡已被請求,則應進入Normal Operation狀態

當離開Repeat Message狀態時,如果網絡已被釋放,則應進入Ready Sleep狀態

如果UdpNmNodeDetectionEnabled設置為TRUE,UdpNm將在離開Repeat Message狀態時清除Repeat Message Bit

- Normal Operation State

Normal Operation狀態確保只要需要網絡功能,任何節點都可以讓NM集群處于喚醒狀態

當從Ready Sleep狀態進入Normal Operation狀態時,應開始傳輸NM PDU,除非啟用被動模式或禁用NM消息傳輸能力

當NM-Timeout定時器在Normal Operation狀態到期時,NM-Timeout定時器應重新啟動

當網絡被釋放且當前狀態為Normal Operation狀態時,應離開Normal Operation狀態,進入Ready Sleep狀態

如果UdpNmNodeDetectionEnabled設置為TRUE并且在Normal Operation狀態下接收到Repeat Message Request bit,則UdpNm應進入Repeat Message狀態

如果UdpNmNodeDetectionEnabled設置為TRUE,并且在Normal Operation狀態下調用函數UdpNm_RepeatMessageRequest,則UdpNm應進入Repeat Message狀態

如果UdpNmNodeDetectionEnabled設置為TRUE 并且在Normal Operation狀態下調用函數UdpNm_RepeatMessageRequest,UdpNm應設置Repeat Message Bit

- Ready Sleep State

Ready Sleep狀態確保NM集群中的任何節點等待轉換到Prepare Bus-Sleep模式,而其他節點保持NM集群清醒

當從Repeat Message狀態或Normal Operation狀態進入Ready Sleep State時,應停止NM PDU的傳輸

如果啟用被動模式,則不傳輸任何NM PDU,則不需要任何操作。如果禁用被動模式,在某些情況下,必須在Ready Sleep狀態下傳輸NM PDU才能在網絡中同步關閉,例如重新傳輸PN關閉消息

當NM-Timeout定時器在Ready Sleep狀態下到期時,應離開Ready Sleep狀態并進入Prepare Bus Sleep模式

當請求網絡且當前狀態為Ready Sleep狀態時,應離開Ready Sleep狀態并進入Normal Operation狀態

如果UdpNmNodeDetectionEnabled設置為TRUE,并且在Ready Sleep狀態下接收到Repeat Message Request bit,則UdpNm應進入Repeat Message狀態

如果UdpNmNodeDetectionEnabled設置為TRUE并且函數UdpNm_RepeatMessageRequest在Ready Sleep狀態中被調用,UdpNm將進入Repeat Message狀態

如果UdpNmNodeDetectionEnabled設置為TRUE并且函數UdpNm_RepeatMessageRequest在Ready Sleep狀態中被調用,UdpNm應設置Repeat Message Bit

Prepare Bus-Sleep Mode

Prepare Bus Sleep狀態的目的是確保所有節點在進入Bus Sleep狀態之前都有時間停止其網絡活動。總線活動平靜下來(即傳輸排隊的消息以清空所有Tx緩沖區),最后在Prepare Bus Sleep模式下總線上沒有活動

當進入Prepare Bus-Sleep Mode時,UdpNm應通過調用Nm_PrepareBusSleepMode通知上層

如果UdpNmStayInPbsEnabled被禁用,則UdpNm應在UdpNmWaitBusSleepTime(配置參數)確定的可配置時間內保持在Prepare Bus-Sleep模式;然后,應離開Prepare Bus-Sleep模式并進入Bus-Sleep模式

上面這段話隱含地要求,如果啟用UdpNmStayInPbsEnabled,UdpNm將永遠不會由于超時而離開,即UdpNm將保持在Prepare Bus-Sleep模式,直到ECU進入電源關閉或任何重新啟動原因被滿足

在Prepare Bus-Sleep模式下成功接收到NM PDU后,應離開Prepare Bus-Sleep模式,進入Network Mode;默認情況下,進入Repeat Message狀態

當在Prepare Bus-Sleep模式下請求網絡時,應離開Prepare Bus-Sleep Mode,進入Network Mode;默認情況下,進入Repeat Message狀態

當在Prepare Bus-Sleep模式下請求網絡并且UdpNm模塊已進入網絡模式并且如果UdpNmImmediateRestartEnabled(配置參數)為TRUE,則UdpNm模塊應發送NM PDU

Bus-Sleep Mode

Bus-Sleep狀態的目的是在沒有消息交換時降低節點中的功耗

通信控制器切換到睡眠模式,激活相應的喚醒機制,最后在總線睡眠模式下將功耗降低到足夠的水平

如果禁用UdpNmStayInPbsEnabled并且由UdpNmTimeoutTime + UdpNmWaitBusSleepTime(兩個配置參數)確定的可配置時間量同樣配置給網絡管理集群中的所有節點,則網絡管理集群中使用AUTOSAR NM算法協調的所有節點幾乎同時轉換到總線睡眠模式

參數UdpNmTimeoutTime和UdpNmWaitBusSleepTime在NM 集群的所有網絡節點內應該具有相同的值。取決于具體的實現,轉換到Bus-Sleep模式大約同時發生。此轉換所經歷的時間抖動取決于以下因素:

內部時鐘精度(振蕩器漂移)

NM-task循環時間(如果任務與全局時間不同步)

NM PDU在Tx隊列中的等待時間(如果在發送請求后立即進行發送確認)

按照最好情況估計,在可配置的時間量內應僅考慮振蕩器漂移,該可配置時間量由值UdpNmTimeoutTime + UdpNmWaitBusSleepTime(兩個配置參數)確定。另外兩個因素可以忽略

當進入Bus-Sleep Mode時,UdpNm應通過調用Nm_BusSleepMode通知上層;如果在初始化時默認進入總線睡眠模式,則不會出現這種情況

當UdpNm模塊在Bus-Sleep模式下成功接收到網絡管理PDU(調用UdpNm_SoAdIfRxIndication)時,UdpNm模塊將通過調用回調函數Nm_NetworkStartIndication通知上層

為了避免網絡和模式管理之間的競爭條件和狀態不一致,UdpNm 不會自動執行從總線睡眠模式到網絡模式的轉換。UdpNm只會通知必須做出喚醒決定的上層。Bus-Sleep模式下的NM數據包接收必須根據ECU關閉或啟動過程的當前狀態進行處理

如果在Bus-Sleep Mode或Prepare Bus Sleep Mode中調用 UdpNm_PassiveStartUp,則UdpNm模塊應進入Network Mode;默認情況下,進入Repeat Message狀態

當在Bus-Sleep模式下請求網絡時,UdpNm模塊應進入網絡模式;默認情況下,UdpNm模塊應進入Repeat Message狀態

網絡狀態

網絡狀態(即“請求”和“釋放”)是AUTOSAR UdpNm狀態機的兩個附加狀態,與狀態機并行存在。網絡狀態表示軟件組件是否需要在總線上進行通信(然后網絡狀態被“請求”);或者軟件組件是否不必在總線上通信(然后總線網絡狀態被“釋放”);請注意,如果網絡被釋放,一個ECU仍然可以通信,因為其他一些ECU仍然請求網絡

調用函數UdpNm_NetworkRequest將請求網絡。UdpNm模塊應將網絡狀態更改為“已請求”

調用函數UdpNm_NetworkRelease應釋放網絡。UdpNm模塊應將網絡狀態更改為“已釋放”

初始化

成功初始化后,網絡管理狀態應設置為Bus-Sleep模式

UdpNm模塊應該在SoAd初始化之后并且在調用任何其他網絡管理服務之前進行初始化

初始化時,默認情況下,UdpNm模塊應將網絡狀態設置為“已釋放”

初始化時,默認情況下,UdpNm模塊應進入Bus-Sleep模式

如果AUTOSAR UdpNm未初始化,不應禁止總線通信

初始化后,應停止網絡管理消息的傳輸

初始化后,用戶數據字節的每個字節都應設置為0xFF

初始化后,Control Bit Vector應設置為0x00

在初始化期間,如果UdpNmPnEnabled為TRUE,UdpNm模塊應將 PNC bit vector的每個字節設置為0x00

一個NM集群中不同ECU上的所有UDP NM實例應使用相同的UDP接收端口

執行

處理器架構

AUTOSAR UdpNm協調算法應獨立于處理器,這意味著它不應依賴于任何處理器特定的硬件支持,因此可以在AUTOSAR范圍內的任何處理器架構上實現

時間參數

配置參數UdpNmTimeoutTime是AUTOSAR UdpNm定時參數NM-Timeout的時間

配置參數UdpNmRepeatMessageTime是AUTOSAR UdpNm定時參數Repeat Message的時間

配置參數UdpNmWaitBusSleepTime是AUTOSAR UdpNm定時參數Wait Bus-Sleep的時間

可選配置參數UdpNmRemoteSleepIndTime是AUTOSAR UdpNm 定時參數Remote Sleep Indication的時間

通信調度

網絡管理消息傳輸

NM消息的傳輸可以通過UdpNmPassiveModeEnabled進行配置

被動節點不發送NM消息,即它們不能主動影響關閉決策,但它們確實接收NM消息以便能夠同步關閉

上面這段話的意思是:被動節點不發送NM消息,這樣別的節點就不會因為收到它的網絡管理消息而從休眠中喚醒,這就是為什么說被動節點不能主動影響其他節點的關閉決策;但它們可以接收其他節點的NM消息,這樣就可以和其他節點同步休眠和喚醒

UdpNm模塊應提供周期性傳輸模式。在這種傳輸模式下,UdpNm模塊將定期發送網絡管理PDU

在“Repeat Message State”和“Normal Operation State”中使用周期性傳輸模式

如果不是通過UdpNm_NetworkRequest或UdpNmImmediateNmTransmissions進入Repeat Message狀態,則在進入Repeat Message狀態后,NM PDU的傳輸應延遲UdpNmMsgCycleOffset。這種機制可以防止NM消息的突發

當由于UdpNm_NetworkRequest()(主動喚醒)從Bus-Sleep模式或Prepare Bus-Sleep模式進入Repeat Message狀態時,如果UdpNmImmediateNmTransmissions大于零,則應使用UdpNmImmediateNmCycleTime作為周期時間來傳輸NM PDU。應盡快觸發第一個NM PDU的傳輸。傳輸后,消息周期計時器應重新加載UdpNmImmediateNmCycleTime。在這種情況下不應使用UdpNmMsgCycleOffset

如果從Ready Sleep狀態進入Normal Operation狀態,則應立即開始NM PDU的傳輸

如果UdpNmPnHandleMultipleNetworkRequests設置為TRUE,UdpNm_NetworkRequest將觸發從網絡模式到Repeat Message狀態的狀態轉換。如果啟用了PDU傳輸能力,則應使用UdpNmImmediateNmCycleTime作為循環時間來傳輸NM PDU。應盡快觸發第一個NM PDU的傳輸。傳輸后,消息周期計時器應重新加載UdpNmImmediateNmCycleTime。在這種情況下不應使用UdpNmMsgCycleOffset

如果NM PDU使用UdpNmImmediateNmCycleTime傳輸,UdpNm 應確保成功請求具有此時間的UdpNmImmediateNmTransmissions(包括第一次立即傳輸)。如果對SoAd的傳輸請求失敗(返回 E_NOT_OK),UdpNm將在下一個主函數中重試傳輸請求。之后UdpNm將繼續使用UdpNmMsgCycleTime發送NM PDU

在使用UdpNmImmediateNmCycleTime傳輸NM PDU時,不得傳輸其他Nm PDU(即停止UdpNmMsgCycleTime傳輸周期)

如果NM PDU的傳輸已經開始,UdpNm消息循環計時器到期,并且當UdpNmSynchronizedPncShutdownEnabled設置為FALSE 或設置為TRUE時,并且沒有同步PNC關閉的請求,則UdpNm模塊應通過調用SoAd_IfTransmit發送NM PDU

PNC,Partial Network Cluster,局部網絡集

如果UdpNm消息循環計時器到期,則應使用UdpNmMsgCycleTime重新啟動

如果NM PDU的傳輸已停止,則應取消UdpNm消息循環計時器

如果參數UdpNmRetryFirstMessageRequest為TRUE,并且如果從Bus-Sleep到Repeat Message狀態轉換后的第一個傳輸請求未被SoAd接受,則應在下一個主函數中重復該消息請求,直到SoAd接受一個傳輸請求

如果用結果E_NOT_OK調用UdpNm_SoAdIfTxConfirmation,則UdpNm應調用函數Nm_TxTimeoutException

網絡管理消息接收

如果成功接收到NM消息,SoAd將調用UdpNm_SoAdIfRxIndication

在調用UdpNm_SoAdIfRxIndication時,UdpNm模塊應將函數參數中引用的網絡管理PDU的數據復制到內部緩沖區

當接收到NM PDU時,如果UdpNmPduRXIndicationEnabled(配置參數)為TRUE,則應調用Nm函數Nm_PduRxIndication

附加功能

“遠程睡眠指示”檢測(可選)

“遠程睡眠指示”表示這樣一種情況:處于Normal Operation狀態的節點發現集群中的所有其他節點都準備好進入睡眠狀態。仍處于Normal Operation狀態的節點仍將保持總線喚醒

“遠程睡眠指示”的檢測應使用UdpNmRemoteSleepIndEnabled開關(配置參數)進行靜態配置

如果在由UdpNmRemoteSleepIndTime(配置參數)確定的可配置時間內,在Normal Operation狀態下沒有接收到NM PDU,NM應通過調用Nm_RemoteSleepIndication通知通用網絡管理接口集群中的所有其他節點都準備好進入睡眠狀態(“遠程睡眠指示”)

如果先前已檢測到“遠程睡眠指示”并且如果再次在Normal Operation狀態或Ready Sleep狀態中接收到NM PDU,則NM應通過調用Nm_RemoteSleepCancellation通知通用網絡管理接口集群中的某些節點不再準備好睡眠(“遠程睡眠取消”)

如果先前已檢測到“遠程睡眠指示”,并且如果從Normal Operation狀態或Ready Sleep狀態進入Repeat Message狀態,則UdpNm應通過調用Nm_RemoteSleepCancellation通知通用網絡管理接口集群中的某些節點不再準備睡眠('遠程睡眠取消')

NM應拒絕在Bus-Sleep模式、Prepare Bus-Sleep模式和Repeat Message狀態下對"遠程睡眠指示"的檢查;服務不被執行,返回E_NOT_OK

用戶數據(可選)

NM用戶數據的支持應使用UdpNmUserDataEnabled開關(配置參數)進行靜態配置

調用UdpNm_SetUserData時,在總線上設置下一個發送的NM包的NM用戶數據;設置NM用戶數據的操作要保證數據的一致性

調用UdpNm_GetUserData時,應提供最近接收到的NM PDU的ppayload中包含的NM用戶數據;提供NM用戶數據的操作應保證數據的一致性

如果配置了NM用戶數據,它肯定會在Repeat Message狀態下發送。在Ready Sleep狀態下,不會發送用戶數據

如果啟用了UdpNmComUserDataSupport,則接口UdpNm_SetUserData將不可用

如果啟用了UdpNmComUserDataSupport并且NM-PDU未配置為在SoAd中觸發傳輸(SoAdBswModules/SoAdIfTriggerTransmit = FALSE),則UdpNm應通過調用PduR_UdpNmTriggerTransmit從引用的NM I-PDU中收集NM用戶數據,并在每次請求傳輸相應的NM消息之前,將用戶數據與進一步的NM字節組合

在觸發傳輸的情況下,傳輸請求不需要數據,只需要長度。數據將在UdpNm_SoAdIfTriggerTransmit中收集

如果啟用了UdpNmComUserDataSupport,并且如果UdpNm處于 Repeat Message狀態或NormalOperation狀態,并且如果調用了UdpNm_Transmit,則UdpNm將請求使用當前數據額外傳NM PDU

調用UdpNm_Transmit請求在與當前數據的周期性傳輸之間(例如系統字節、用戶數據和PNC位向量)傳輸NM PDU

被動模式(可選)

在被動模式下,節點只接收NM消息,但不發送任何NM消息

被動模式應可使用UdpNmPassiveModeEnabled開關(配置參數)進行靜態配置

被動模式應針對一個ECU內的所有實例進行一致的靜態配置

如果使用被動模式(配置參數UdpNmPassiveModeEnabled),則不得使用以下選項:

總線同步

配置參數UdpNmBusSynchronizationEnabled

遠程睡眠指示

配置參數UdpNmRemoteSleepIndEnabled

節點檢測

配置參數UdpNmNodeDetectionEnabled

狀態變化通知(可選)

如果啟用了回調Nm_StateChangeNotification,AUTOSAR UdpNm狀態的所有變化都應通過調用Nm_StateChangeNotification通知上層

通訊控制(可選)

通信控制應可使用UdpNmComControlEnabled開關(配置參數)進行靜態配置

可選服務UdpNm_DisableCommunication應禁用NM PDU傳輸能力

如果禁用NM PDU傳輸能力,NM協調算法將無法正常工作。因此,必須確保只要NM PDU傳輸能力被禁用,ECU就不會關閉

如果調用了UdpNm_NetworkRelease并且NM PDU傳輸能力已被禁用,則ECU將關閉。這確保了ECU也可以在競爭條件(例如,在啟用通信之前不久留下診斷會話)或錯誤使用通信控制的情況下關閉

如果當前模式不是網絡模式,可選服務UdpNm_DisableCommunication應返回E_NOT_OK

當網絡管理PDU傳輸能力被禁用時,UdpNm模塊應停止UdpNm消息周期定時器以停止網絡管理PDU的傳輸

當禁用NM PDU傳輸能力時,應停止NM-Timeout定時器

當NM PDU傳輸能力被禁用時,“遠程睡眠指示”定時器的檢測將被暫停

當啟用網絡管理PDU傳輸能力時,NM PDU的傳輸最晚應在下一個NM主函數中開始

當啟用NM PDU傳輸能力時,應重新啟動NM-Timeout定時器

當啟用NM PDU傳輸能力時,應恢復“遠程睡眠指示”定時器的檢測

如果NM PDU傳輸能力被禁用,可選服務UdpNm_RequestBusSynchronization應返回E_NOT_OK

NM協調器同步支持(可選)

當有多個協調器連接到同一總線時,CBV中有一個特殊位,NmCoordinatorSleepReady bit用于指示主協調器請求啟動關閉序列。該算法的主要功能在Nm模塊中進行了描述

如果UdpNm調用NM_CoordReadyToSleepIndication并且仍處于網絡模式,它應在第一次接收到帶有NmCoordinatorSleepReady bit的NM消息時通過調用Nm_CoordReadyToSleepCancellation通知Nm

如果UdpNm已進入網絡模式或調用Nm_CoordReadyToSleepCancellation,則它應在第一次接收到帶有NmCoordinatorSleepReady bit的NM消息時調用Nm_CoordReadyToSleepIndication通知NM

如果UdpNmCoodinatorSyncSupport設置為TRUE并且接口UdpNm_SetSleepReadyBit被調用,UdpNm應將“NM協調器Sleep Ready Bit”位設置為傳遞值并觸發單個網絡管理PDU

僅當UdpNmCoordinatorSyncSupport設置為TRUE時,接口UdpNm_SetSleepReadyBit()和“協調總線關閉”功能才可用

局部網絡Partial Networking

NM PDUs的Rx處理

如果UdpNmPnEnabled為FALSE,則UdpNm應執行正常的Rx指示處理,并且應禁用局部網絡擴展

如果UdpNmPnEnabled為TRUE,接收到的NM-PDU中的PNI bit為0,并且UdpNmAllNmMessagesKeepAwake為TRUE,則UdpNm模塊應執行正常的Rx指示處理并省略局部網絡的擴展

如果UdpNmPnEnabled為TRUE,接收到的NM-PDU中的PNI位為 0,并且UdpNmAllNmMessagesKeepAwake為FALSE,UdpNm模塊應忽略接收到的NM-PDU

如果將UdpNmPnEnabled設置為TRUE,則接收的NM-PDU中的PNI bit被設置為1,并且PNSR bit設置為0,根據局部網絡配置,UdpNm模塊應從接收的NM-PDU中提取PNC位向量(對應NM-channel的NmPncBitVectorOffset和NmPncBitVectorLength)并通過調用Nm_PncBitVectorRxIndication來轉發PNC位矢量

如果UdpNmPnEnabled設置為TRUE并且調用了Nm_PncBitVectorRxIndication,則接收到的NM PDU僅在以下條件下考慮進行進一步處理:

UdpNmAllNmMessagesKeepAwake設置為TRUE,或者

RelevantPncRequestDetectedPtr的輸出值設置為TRUE

需要UdpNmAllNmMessagesKeepAwake才能使網關在任何類型的NM-PDU上保持喚醒

如果UdpNmSynchronizedPncShutdownEnabled為TRUE,則接收到的NM-PDU中的PNI bit為1,接收到的NM-PDU中的PNSR bit為1,并且通過UdpNmComMNetworkHandleRef配置的相應 ComMChannel在接收到此NM-PDU的位置被主動協調 (ComMPncGatewayType設置為COMM_GATEWAY_TYPE_ACTIVE),則UdpNm模塊應忽略接收到的NM-PDU。此外,UdpNm模塊應:

向默認錯誤跟蹤器報告運行時錯誤UDPNM_E_INVALID_PN_SYNC_SHUTDOWN_REQUEST

如果UdpNmPnSyncShutdownErrorReactionEnabled設置為TRUE,請求傳輸在受影響的UdpNm-Channel的下一個主函數調用中持續的當前PN信息的NM-PDU

如果UdpNmSynchronizedPncShutdownEnabled為TRUE,則接收到的NM-PDU中的PNI bit設置為1,PNSR bit設置為1,UdpNm模塊應根據局部網絡配置(NmPncBitVectorOffset和NmPncBitVectorLength)并通過調用Nm_ForwardSynchronizedPncShutdown轉發PNC位向量

僅當請求同步PNC關閉時,PNSR bit才可能設置為1。應在PN拓撲中處理同步的PNC關閉。因此,假設所有協調器都啟用了同步PNC關閉,或者所有協調器都禁用了同步PNC關閉。兩者的混合會導致PNC不同步關閉,這是必須避免的

NM PDUs的Tx處理

如果UdpNmPnEnabled為TRUE,則UdpNm模塊應將CBV中發送的PNI位的值設置為1

如果使用局部網絡,則必須使用CBV

如果UdpNmPnEnabled為FALSE,則UdpNm模塊應將CBV中發送的PNI位的值始終設置為0

如果UdpNmPnEnabled為TRUE,則NM-PDU未配置為在SoAd中觸發傳輸(SoAdBswModules/SoAdIfTriggerTransmit設置為FALSE),沒有等待同步PNC關閉的請求且必須傳輸NM-PDU,UdpNm模塊應按給定順序執行以下操作:

調用Nm_PncBitVectorTxIndication指示傳輸請求并檢索內部PNC請求

通過考慮相應NM通道的NmPncBitVectorOffset和NmPncBitVectorLength將接收到的用于內部PNC請求的PNC位向量復制到NM-PDU

如果啟用了用戶數據,則獲取可用數據(如果啟用了UdpNmComUserDataSupport,則從Com或從內部存儲中獲取)并復制 NM-PDU的用戶數據范圍中的數據

通過調用SoAd_IfTransmit觸發NM-PDU的傳輸

如果UdpNmSynchronizedPncShutdownEnabled設置為TRUE并且通過UdpNm_RequestSynchronizedPncShutdown指示 UdpNm模塊,UdpNm模塊應將每個給定UdpNm通道(nmChannelHandle)的給定PNC(pncId)存儲為同步PNC關閉的掛起請求

請求同步PNC關閉的所有PNC的聚合和作為PN關閉消息的傳輸(將CBV中的PNSR位設置為1)在相應的UdpNm_Main函數的上下文中異步完成

如果UdpNmSynchronizedPncShutdownEnabled設置為TRUE,則同步PNC關閉請求處于掛起狀態,并且前一個調用沒有傳輸確認(通過UdpNm_TxConfirmation指示)被掛起,則UdpNm模塊應在下一個主函數調用中請求傳輸NM-PDU,如通過調用SoAd_IfTransmit的PN關閉消息。如果NM-PDU未配置為在SoAd中觸發傳輸(SoAdBswModules/SoAdIfTriggerTransmit = FALSE),UdpNm應為此消息在正常數據下額外設置以下數據:

將CBV中的PNSR位設置為1

如果啟用了用戶數據,則獲取可用數據(如果啟用了UdpNmComUserDataSupport,則從Com或從內部存儲中獲取)并復制NM-PDU的用戶數據范圍中的數據

通過將與存儲為同步PNC關閉的掛起請求的PNC ID對應的位設置為1并將所有其他位設置為0,寫入相對于相應NM通道的NmPncBitVectorOffset和NmPncBitVectorLength的PNC位向量

UdpNm模塊必須聚合所有指示用于同步PNC關閉的PNC,并將pncId傳輸到字節數組(PNC位向量)。PNC位向量的每個位(PNC 位)代表一個特定的PNC。PNC比特的PNC比特向量內的byteIndex和bitindex應確定如下:

byteIndex = (PncId div 8) - NmPncBitVectorOffset

bitIndex = (PncId mod 8)

如果配置了UdpNmPnShutdownMessageRetransmissionDuration并且第一次請求傳輸PN關閉消息,則應在所有受影響的NM通道上使用UdpNmPnShutdownMessageRetransmissionDuration啟動PN關閉消息的相應重傳計時器

如果UdpNmSynchronizedPncShutdownEnabled設置為TRUE,則UdpNm模塊已請求傳輸NM-PDU作為PN關閉消息并且調用UdpNm_TxConfirmation,結果為E_OK,UdpNm應將存儲的那些 PNC ID視為同步PNC的掛起請求,完成后關閉相應的NM通道并將其從存儲中刪除。此外,如果配置了UdpNmPnShutdownMessageRetransmissionDuration,則UdpNm將取消受影響NM通道的PN關閉消息的重傳定時器

UdpNm必須確保同步PNC關閉的新請求(通過UdpNm_RequestSynchronizedPncShutdown指示)在PN關閉NM幀的持續傳輸期間不會丟失

如果UdpNmSynchronizedPncShutdownEnabled設置為TRUE,則UdpNmPnShutdownMessageRetransmissionDuration已配置,UdpNm模塊由于同步PNC關閉請求傳輸,UdpNm_SoAdIfTxConfirmation調用結果為E_NOT_OK或此PN關閉消息的傳輸請求未被接受(SoAd_IfTransmit返回E_NOT_OK),則 UdpNm模塊應保存這些PNC ID作為同步PNC關閉的掛起請求,并在下一個主要功能中執行重傳

UdpNm必須在相應的主函數調用的上下文中對PN關閉消息執行重試傳輸處理,如果PN關閉消息的傳輸未得到下層確認(使用E_NOT_OK或UdpNm_SoAdIfTxConfirmation未調用)。重試傳輸 請求應涵蓋錯誤情況,如果下層無法傳輸Nm消息。在最壞的情況下,這與使用UdpNmMsgCycleTime傳輸的延遲NM消息發生沖突。但無論如何,如果在PN重置時間(EIRA)內未恢復傳輸NM消息的能力,則PNC將不同步關閉,這可能會導致應用程序級別的超時錯誤

下層指示的掛起傳輸確認的依賴性應該支持可靠的通信,例如:確保在網絡上傳輸PN關閉消息或避免傳輸過時的PN關閉消息,例如,如果配置了低層中的排隊

如果UdpNmSynchronizedPncShutdownEnabled設置為TRUE,并且UdpNm模塊已將PNC ID存儲為同步PNC關閉的掛起請求,則UdpNm應從存儲中刪除那些外部或內部再次請求的PNC ID:

如果收到外部請求的PNC,UdpNm將檢查NM消息的接收

通過從相應的ComPdu派生的內部PNC請求可用,UdpNm應在每次傳輸PN關閉消息之前進行檢查

如果UdpNmSynchronizedPncShutdownEnabled設置為TRUE,未配置UdpNmPnShutdownMessageRetransmissionDuration,由于同步PNC關閉,UdpNm模塊已請求傳輸,則調用UdpNm_TxConfirmation并返回E_NOT_OK或不接受此PN關閉消息的傳輸請求(SoAdIf_Transmit返回E_NOT_OK),然后UdpNm 應刪除存儲為相應NM通道的同步PNC關閉的掛起請求的PNC ID,并將運行時錯誤UDPNM_E_TRANSMISSION_OF_PN_SHUTDOWN_MESSAGE_FAILED報告給DET

如果UdpNmSynchronizedPncShutdownEnabled設置為TRUE并且PN關閉消息的重傳計時器到期,則UdpNm應從存儲中刪除相應NM通道的同步PNC關閉的掛起請求,并且向DET報告運行時錯誤 UDPNM_E_TRANSMISSION_OF_PN_SHUTDOWN_MESSAGE_FAILED

內部請求的局部網絡集的處理

所有內部PNC請求均由ComM維護。ComM將每個通道的聚合內部PNC請求作為PNC位向量轉發到NmIf。這個PNC位向量攜帶所謂的“內部請求數組”。每次發送NM_PDU時,UdpNm都必須從NmIf檢索最新的IRA。NmIf向UdpNm提供IRA信息并更新PNC重置計時器(每次相關的PNC被發送,PNC復位定時器重新啟動)

對于UdpNmPnEnabled設置為TRUE的所有已配置NM通道,UdpNm將調用Nm_PncBitVectorTxIndication來指示傳輸并檢索當前內部PNC請求作為相對于已配置NmPncBitVectorLength的PNC位向量。UdpNm將收到的內部PNC請求復制到NM-PDU的PNC位向量字節

通過UdpNm_NetworkRequest自發傳輸NM-PDU

如果調用UdpNm_NetworkRequest,UdpNmPnHandleMultipleNetworkRequests設置為TRUE,并且UdpNm處于Ready Sleep狀態、Normal Operation狀態或Repeat Message狀態,則UdpNm將更改為或重新啟動Repeat Message狀態

如果UdpNmPnHandleMultipleNetworkRequests設置為TRUE,則UdpNm功能“立即傳輸”是強制性的

如果PNC位發生變化,PNC控制模塊(例如ComM)負責調用UdpNm_NetworkRequest

來源:汽車通信技術

審核編輯:湯梓紅

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 通信協議
    +關注

    關注

    28

    文章

    857

    瀏覽量

    40254
  • 接口
    +關注

    關注

    33

    文章

    8496

    瀏覽量

    150834
  • TCP
    TCP
    +關注

    關注

    8

    文章

    1349

    瀏覽量

    78985
  • AUTOSAR
    +關注

    關注

    10

    文章

    350

    瀏覽量

    21468
  • UDP
    UDP
    +關注

    關注

    0

    文章

    322

    瀏覽量

    33874

原文標題:【通信協議】AUTOSAR UDP網絡管理-1

文章出處:【微信號:智能汽車電子與軟件,微信公眾號:智能汽車電子與軟件】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    車載Flex Ray網絡管理策略的初步研究

    車載Flex Ray網絡管理策略的初步研究網絡管理的目標是保障網絡可靠、有效地運行。在一般的計算
    發表于 11-26 17:11

    AUTOSAR CAN網絡管理

    一、背景: 在AUTOSAR CAN網絡管理框架下,如果所有的節點都按照狀態機要求,在ReadSleep狀態下停發NM幀,在Prepare Bus-Sleep模式下停發App幀,所有節點可以從
    發表于 07-26 06:47

    AUTOSAR CAN網絡管理狀態機介紹

    AUTOSAR CAN網絡管理狀態機為什么停發應用幀?有什么解決辦法嗎?
    發表于 09-24 07:47

    AUTOSAR_SWS_CAN網絡管理規范標準4.3.1

    AUTOSAR_SWS_CAN網絡管理規范標準4.3.1
    發表于 03-28 17:02 ?13次下載

    CAN網絡管理規范 AUTOSAR CP中文版

    CAN網絡管理規范 AUTOSAR CP中文版免費下載。
    發表于 04-06 16:21 ?0次下載

    CAN網絡管理規范 AUTOSAR CP英文版

    AUTOSAR_SWS_CAN網絡管理規范標準4.3.0英文版免費下載。
    發表于 04-06 16:20 ?0次下載

    AUTOSAR CAN網絡管理協議

    AUTOSAR_SWS_CANNetworkManagement AUTOSAR CAN網絡管理協議,4.4.0版本
    發表于 08-01 11:09 ?16次下載

    AUTOSAR和OSEK網絡管理比較

    AUTOSAR與OSEK二者都是汽車電子軟件的標準。OSEK/VDX是基于ECU開發的操作系統標準,AUTOSAR基于整體汽車電子開發的功能標準。
    發表于 09-16 09:42 ?1670次閱讀

    OSEK與AUTOSAR標準分別是怎么實現網絡管理功能的

    AUTOSAR(Automotive Open System Architecture,即汽車開放系統架構),另一個是OSEK。 AUTOSAR與OSEK的網絡管理方式雖然有區別,但是
    的頭像 發表于 11-11 14:11 ?1660次閱讀

    AutoSAR中CAN通信網絡管理的概述

    AutoSAR中CAN通信的網絡管理主要是根據CANNode接收和發送的NMMessage進行該節點在整個網絡中的活動的,根據NM Message控制整個
    的頭像 發表于 01-18 10:21 ?5650次閱讀
    <b class='flag-5'>AutoSAR</b>中CAN通信<b class='flag-5'>網絡</b><b class='flag-5'>管理</b>的概述

    逐步講解AUTOSAR的Memory原理策略

    很多人都覺得AUTOSAR的Memory很復雜,搞了很久都摸不透里面的原理策略
    的頭像 發表于 03-08 14:11 ?2499次閱讀

    科普系列:AUTOSAR與OSEK網絡管理比較(上)

    AUTOSAR(Automotive Open System Architecture,即汽車開放系統架構),另一個是OSEK。AUTOSAR與OSEK的網絡管理方式的區
    的頭像 發表于 10-26 09:28 ?1052次閱讀
    科普系列:<b class='flag-5'>AUTOSAR</b>與OSEK<b class='flag-5'>網絡</b><b class='flag-5'>管理</b>比較(上)

    科普系列:AUTOSAR與OSEK網絡管理比較(下)

    作者:You小編:吃不飽在上篇中我們分別在狀態機和報文格式方面對OSEK和AUTOSAR網絡管理進行了簡單介紹,感興趣的小伙伴請移步至文章《科普系列:AUTOSAR與OSEK
    的頭像 發表于 11-22 10:17 ?1033次閱讀
    科普系列:<b class='flag-5'>AUTOSAR</b>與OSEK<b class='flag-5'>網絡</b><b class='flag-5'>管理</b>比較(下)

    一文解析AUTOSAR CAN網絡管理

    AUTOSAR CAN 網絡管理是一個獨立于硬件的協議,只能在 CAN 上使用。它的主要目的是協調網絡的正常運行和總線休眠模式之間的轉換。
    的頭像 發表于 09-09 10:32 ?5561次閱讀
    一文解析<b class='flag-5'>AUTOSAR</b> CAN<b class='flag-5'>網絡</b><b class='flag-5'>管理</b>

    解讀AUTOSAR模式管理BswM配置

    模式管理AUTOSAR中的一個難點,也可以說是最龐雜的一塊。因為模式管理貫穿整個CP Autosar流程,幾乎所有模塊都跟BSWM發生著聯系。
    的頭像 發表于 10-26 16:55 ?2286次閱讀
    解讀<b class='flag-5'>AUTOSAR</b>模式<b class='flag-5'>管理</b>BswM配置