報文的案例
華為Mate Xs 2榮升北斗短報文手機
10月31號，華為終端宣布華為Mate Xs 2將要升級北斗短報文功能。升級后，華為Mate Xs 2將要榮升為北斗短報文手機。不難看出，這款手機早在研發(fā)籌劃階段就提前預(yù)留了北斗衛(wèi)星通訊的硬件基礎(chǔ)，因此才能迅速普及此項備受好評的通信技術(shù)，由此也能看出華為對于北斗短報文手機產(chǎn)品策劃的嚴謹和前瞻性。
歸功于北斗短報文手機的此項功能，當客戶身處荒漠無人區(qū)，或是遭受地震等惡劣環(huán)境時，即可通過手機里的暢連APP，將文字和位置信息往外發(fā)出。值得一提的是，華為Mate Xs 2還支持多條位置生成軌跡地圖，進而大大降低了救援時的難度。
點擊查看更多北斗短報文終端。
當然，這個功能使用起來也十分簡單方便。客戶只需在華為北斗短報文手機Mate Xs 2的暢連APP中找到“北斗短報文”服務(wù)，之后在界面下方點擊“新建消息”按鍵即可編輯內(nèi)容，隨后根據(jù)頁面引導即可完成發(fā)送操作，目前最多能夠群發(fā)4個聯(lián)系人。
除了升級北斗短報文，帶來通訊體驗的進一步提升外，華為北斗短報文手機Mate Xs 2也是折疊手機里的“輕量化”代表。目前，市面上的折疊手機基本都在300g左右，展開狀況下這個重量也許不會對客戶導致太大困擾，但折疊狀況下長期使用就會造成手腕酸痛。而華為北斗短報文手機Mate Xs 2直接做到了255g重量展開后的薄厚只有5.4mm，無限逼近直板旗艦機了，這令用戶的抓握感受變得非常舒適。
而在折疊手機核心的大屏適配上，華為北斗短報文手機Mate Xs 2已經(jīng)對300款常用應(yīng)用實現(xiàn)了100%大屏適配，對2000款常用應(yīng)用實現(xiàn)了90%大屏適配。在此基礎(chǔ)上，華為北斗短報文手機Mate Xs 2首創(chuàng)的自適應(yīng)UI引擎，還能夠根據(jù)應(yīng)用類型自動優(yōu)化布局，把它進行大屏適配。
展開 北斗短報文的大眾領(lǐng)域應(yīng)用
這意味著，中國北斗已走出中國，走向世界，可以為全球用戶提供基本導航、全球北斗短報文通信、國際搜救等服務(wù)。
隨著北斗衛(wèi)星導航系統(tǒng)相關(guān)關(guān)鍵技術(shù)全面突破，北斗衛(wèi)星導航定位在應(yīng)用方面早已走向普通民眾生活。但在全球四大衛(wèi)星導航系統(tǒng)中，中國的北斗衛(wèi)星除了導航定位之外還有個獨門絕技，那就是北斗短報文。
什么是北斗短報文？
看似陌生的 " 北斗短報文 "，形態(tài)其實和我們常用短信一樣，只不過北斗短報文不需要運營商的網(wǎng)絡(luò)就能收發(fā)，就算遭遇自然災(zāi)害也不會有失聯(lián)的擔憂。當身處荒漠無人區(qū)、出海遇險、地震救援等無地面網(wǎng)絡(luò)信號覆蓋環(huán)境下，北斗短報文可通過暢連 APP 將文字和位置信息向外發(fā)出，與外界保持聯(lián)系，并支持多條位置生成軌跡地圖。
北斗短報文的大眾化應(yīng)用
北斗短報文服務(wù)被視為北斗大眾化應(yīng)用的下一個突破口。近期華為發(fā)布了 Mate 50系列手機，該系列是全球首款支持北斗短報文的大眾智能手機，在無地面網(wǎng)絡(luò)信號覆蓋環(huán)境下，仍可通過暢連 App 發(fā)送消息，支持一鍵生成軌跡地圖，時刻與世界暢連，開啟大眾衛(wèi)星通信新時代。
北斗短報文的應(yīng)用范圍
首先是航海和漁業(yè)。之前海上航行一旦出事故主要靠衛(wèi)星電話，但衛(wèi)星電話服務(wù)費高，很多小漁船不舍得用，如今也可以用北斗短報文了，不僅可以通信，還有導航定位服務(wù)。
其次是勘測團隊，如果需要去大漠戈壁、深山老林工作，帶一個能發(fā)短報文的北斗終端，時刻保證通信想必是非常安心的。
最后是搶險救援，其實早在汶川地震時，北斗短報文就已經(jīng)初露鋒芒。當時還只是北斗一號，在震后支離破碎的災(zāi)區(qū)，所有通信設(shè)施遭到毀壞，解放軍官兵攜帶北斗短報文終端 （點擊查看詳情） 進入災(zāi)區(qū)，不僅能導航定位，更利用北斗短報文將災(zāi)區(qū)的信息傳遞出來，為后續(xù)指揮提供了重要支撐。
現(xiàn)如今，北斗與各個行業(yè)都在加快融合。
展開 一文搞懂CAN總線的AUTOSAR網(wǎng)絡(luò)管理
4、CAN總線的AUTOSAR網(wǎng)絡(luò)管理報文（以下簡稱NM報文）長啥樣？
首先要明確一點，NM報文就是CAN報文。NM報文符合CAN報文的格式，由幀起始、仲裁場、控制場、數(shù)據(jù)場、CRC場、應(yīng)答場、幀結(jié)尾組成。
一般廠家在設(shè)計的時候會規(guī)定好NM報文的ID范圍。
舉個例子：規(guī)定標識符在0x500到0x5FF范圍為NM報文。當在CANoe中抓取到此ID范圍內(nèi)的報文，那就是NM報文。
此報文ID=0x502，那么它就是一幀NM報文
NM報文數(shù)據(jù)場
NM報文的重點在于數(shù)據(jù)場8字節(jié)里的內(nèi)容：
NM報文數(shù)據(jù)場內(nèi)容格式
Byte0：
這里填的是ECU的地址，或者叫ECU的ID；
此報文的ID=一個基礎(chǔ)值+ECU的ID，例如廠家規(guī)定基礎(chǔ)值為0x500，那么此報文的ID=0x500+0x8=0x508；
這里要注意區(qū)分報文的ID和ECU ID的概念，很容易混淆；
Byte1：
NM報文數(shù)據(jù)場byte1格式
這里關(guān)注下bit0和bit4：
bit0：當此位置1時強制進入RMS（下面會講到）；
bit4：告訴其他節(jié)點自身是怎么被喚醒的。
展開 AutoSAR之基礎(chǔ)篇CanNM
Passive Mode
在該模式下只接受NM報文，但不發(fā)送任何的NM報文。該模式可以通過配置得到，同時該模式應(yīng)只存在于開發(fā)或者調(diào)試過程中，在正式SOP的軟件中禁止出現(xiàn)此種模式。
報文發(fā)送與接受狀態(tài)
在測試的過程中，需要針對網(wǎng)絡(luò)管理每一個狀態(tài)下的NM報文與APP報文接收與發(fā)送進行測試。如下圖所示，體現(xiàn)了在不同NM子狀態(tài)下的報文發(fā)送與接受狀態(tài)。
Bus-Sleep階段，只接收NM報文喚醒，不發(fā)送任何報文；
Pre-Bus-Sleep階段，同樣僅允許接收NM報文，對于早已在發(fā)送Buffer中的APP報文應(yīng)發(fā)送完畢后立刻停止APP報文；
在Network Mode模式下，除了在Ready Sleep階段不允許發(fā)送NM報文之外，其余階段APP報文與NM報文正常收發(fā)；
圖5 NM過程中報文收發(fā)狀態(tài)
狀態(tài)機時間參數(shù)總結(jié)
鑒于在網(wǎng)絡(luò)管理各子狀態(tài)的切換過程中都依賴于各種計時器，為了便于后續(xù)狀態(tài)機切換的講述以及后續(xù)查表方便，將相關(guān)參數(shù)總結(jié)如下，以供參考。
圖6 NM計時器參數(shù)表
NM狀態(tài)機切換
NM狀態(tài)機是整個網(wǎng)絡(luò)管理的核心。從上述內(nèi)容可知NM管理狀態(tài)機總共分為3種模式：Bus-Sleep、Pre-Bus-Sleep以及Network Mode。
其中Network Mode 又可分為3個子狀態(tài)：Repeat Message State、Normal Operation State以及Ready Sleep State。
展開 
圖文詳細講解弱電VLAN技術(shù)知識，看這一篇就足夠！
Host_1判斷目的IP地址跟自己的IP地址在同一網(wǎng)段，于是發(fā)送ARP廣播請求報文獲取目的主機Host_2的MAC地址，報文目的MAC填寫全F，目的IP為Host_2的IP地址10.1.1.3。
報文到達Router的接口IF_1，發(fā)現(xiàn)是Untagged幀，給報文添加VID=2的Tag（Tag的VID=接口的PVID），然后根據(jù)報文的源MAC地址、VID和報文入接口（1-1-1， 2， IF_1）生成MAC表。
根據(jù)報文目的MAC地址+VID查找Router的MAC表，沒有找到，于是在所有允許VLAN2通過的接口（本例中接口為IF_2）廣播該報文。
Router的接口IF_2在發(fā)出ARP請求報文前，根據(jù)接口配置，剝離VID=2的Tag。
Host_2收到該ARP請求報文，將Host_1的MAC地址和IP地址對應(yīng)關(guān)系記錄ARP表。然后比較目的IP與自己的IP，發(fā)現(xiàn)跟自己的相同，就發(fā)送ARP響應(yīng)報文，報文中封裝自己的MAC地址2-2-2，目的IP為Host_1的IP地址10.1.1.2。
Router的接口IF_2收到ARP響應(yīng)報文后，同樣給報文添加VID=2的Tag。
Router根據(jù)報文的源MAC地址、VID和報文入接口（2-2-2， 2， IF_2）生成MAC表，然后根據(jù)報文的目的MAC地址+VID（1-1-1， 2）查找MAC地址表，由于前面已記錄，查找成功，向出接口IF_1轉(zhuǎn)發(fā)該ARP響應(yīng)報文。
Router向出接口IF_1轉(zhuǎn)發(fā)前，同樣根據(jù)接口配置剝離VID=2的Tag。
展開 gPTP，自動駕駛時間同步里的“有趣靈魂”
當設(shè)備MAC層接收或發(fā)送事件類型報文時，會觸發(fā)對硬件計數(shù)器進行采樣，從而獲得時鐘振蕩周期計數(shù)值，結(jié)合時鐘振蕩頻率及基準時間，可獲得此時的時間戳。而一般類型報文僅用來攜帶信息，不會觸發(fā)內(nèi)部硬件計數(shù)器的采樣操作。
（1）時鐘偏差測量
gPTP定義的五條報文中，Sync和Follow_UP為一組報文，周期發(fā)送，主要用來測量時鐘偏差。Sync由主端口發(fā)送，在報文離開主端口MAC層時，觸發(fā)主端口記錄此時的時間戳t1。從端口MAC層收到Sync報文后會記錄此時的時間戳t2。隨后，主端口將t1值附到Follow_UP報文里發(fā)送給從端口。
如果沒有網(wǎng)絡(luò)傳輸延遲或延遲、可以忽略，則從端口將本地時鐘值加上時鐘偏差（t1-t2的值）就完成時間同步，也就沒有后面的碎碎念了。但是對于μs級時間同步精度的gPTP來說，傳輸延遲顯然無法視若不見。
（2）傳輸延遲測量
gPTP采用P2P（Peer to Peer）的方法來測量傳輸延遲。在P2P方法中，測量的是相鄰設(shè)備間的傳輸延遲，報文不允許跨設(shè)備傳輸，這也就要求gPTP網(wǎng)絡(luò)內(nèi)的所有設(shè)備都需要支持gPTP功能。同時定義一組獨立的報文專門負責傳輸延遲測量，分別為周期發(fā)送的Pdelay_Req、Pdelay_Resp和Pdelay_Resp_Follow_UP。
從端口首先發(fā)送Pdelay_Req報文，標志傳輸延遲測量的開始，在報文離開從端口MAC層時，觸發(fā)從端口記錄此時的時間戳t3。
展開 LIN總線入門.
待考）
2.發(fā)送報文幀頭，包含同步間隔場、同步場和標識符場三個部分。
3.監(jiān)控總線通信，通過校驗和確定數(shù)據(jù)正確性與否。
4.使從機進入喚醒或睡眠狀態(tài)，并響應(yīng)從機的喚醒要求。
B.從機任務(wù)既可運行于主機又可運行于從機，它主要完成以下功能：
1.等待主機任務(wù)發(fā)送的同步間隔，使從機與主機于同步場中獲得同步。
2.分析標識符場，若與自己相關(guān)，則接收或發(fā)送數(shù)據(jù)，若與自己無關(guān)則什么都不做。
3.檢查和發(fā)送校驗和。
4.接受主機任務(wù)的喚醒和睡眠請求。
綜上，主機報文的標識符能觸發(fā)與之對應(yīng)的不同從機之間的通信。
LIN報文的幀結(jié)構(gòu)
LIN 總線上具有“顯性”和“隱性”兩種互補的邏輯電平。其中，顯性電平（參考地電壓）是邏輯 0，隱性電平（電源電壓）是邏輯1。
LIN在總線上以具有固定格式的報文進行傳遞，但是這種報文數(shù)據(jù)段的長度是可以調(diào)整的。LIN網(wǎng)絡(luò)中的所有節(jié)點（包括主機節(jié)點）都具有從機任務(wù)，當接到主機任務(wù)的報文信息時，它們中的某一個要對報文做出響應(yīng)。
報文頭僅可以由主機節(jié)點發(fā)出
LIN總線的一幀主要由兩部分組成，即報文頭（Header）和報文響應(yīng)（Response）。其中，報文頭是由一個主機節(jié)點的主機任務(wù)發(fā)出的，而報文響應(yīng)（以下簡稱響應(yīng)）是由一個主機節(jié)點或從機節(jié)點的從機任務(wù)發(fā)出的。其中報文頭由同步間隔場（最小13個顯性位）、同步場（1個字節(jié)，數(shù)據(jù)不變，0x55）、和PID場（1個字節(jié)）三部分組成；報文響應(yīng)由2/4/8個字節(jié)的數(shù)據(jù)場、校驗和場（1個字節(jié)）所組成。報文頭和響應(yīng)之間有一個幀內(nèi)空間分隔，最小空間為0。
展開 SDN中“軟件”如何定義“網(wǎng)絡(luò)”
Controller通過packet-out報文，封裝LLDP報文進Openflow，分別分發(fā)給每個交換機。此時的packet-out報文中含有動作：分發(fā)LLDP報文從交換機的每個端口發(fā)出去。
此時交換機A根據(jù)Controller的動作指令，將LLDP報文從交換機所有接口發(fā)出去。交換機B和交換機C此時都能收到這個報文。
LLDP報文經(jīng)過交換機之間的互聯(lián)鏈路到達對端SDN交換機。而此時正因為交換機是SDN無腦交換機，他對于報文的處理都是上送Controller而非本地操作。則此時接受到LLDP的對端交換機會將LLDP報文再次封裝，封裝進packet-in，并上送至Controller。
此時Controller收到對端SDN交換機封裝的packet-in報文，報文里包含原本的LLDP報文。此時Controller就已經(jīng)知道所有的拓撲連接關(guān)系了。
SDN控制器對于ARP報文的處理
背景闡述：
網(wǎng)絡(luò)拓撲已發(fā)現(xiàn)
控制器采用ODL（OpenDayLight）
本地主機H1（10.0.0.1）和對端主機H2（10.0.0.2）均連接于SDN交換機下面
整個過程是H1請求H2的ARP，H2響應(yīng)H1
整個解析過程
H1去pingH2，即10.0.0.1去ping10.0.0.2。因為沒有H2的MAC，此時需要做一次ARP解析。此時ARP請求（原本是廣播）被SwitchA通過Openflow形式單播上送給Controller（packet-in報文）
Controller收到H1的ARP請求，記錄H1位于Switch A下游，且記錄相關(guān)的位置信息。
正因為Controller有所有交換機的拓撲及位置信息，此時Controller會給全網(wǎng)中每臺SDN交換機都發(fā)送一個10.0.0.0/8網(wǎng)段的ARP請求消息，來請求10.0.0.2的MAC地址。
展開 36張圖詳解計算機網(wǎng)絡(luò)知識點
建立連接（三次握手）：
第一次：客戶向服務(wù)器發(fā)送連接請求段，建立連接請求控制段（SYN=1），表示傳輸?shù)?em>報文段的第一個數(shù)據(jù)字節(jié)的序列號是x，此序列號代表整個報文段的序號（seq=x）；客戶端進入 SYN_SEND （同步發(fā)送狀態(tài)）；
第二次：服務(wù)器發(fā)回確認報文段，同意建立新連接的確認段（SYN=1），確認序號字段有效（ACK=1），服務(wù)器告訴客戶端報文段序號是y（seq=y），表示服務(wù)器已經(jīng)收到客戶端序號為x的報文段，準備接受客戶端序列號為x+1的報文段（ack_seq=x+1）；服務(wù)器由LISTEN進入SYN_RCVD （同步收到狀態(tài)）;
第三次：客戶對服務(wù)器的同一連接進行確認。確認序號字段有效(ACK=1)，客戶此次的報文段的序列號是x+1(seq=x+1)，客戶期望接受服務(wù)器序列號為y+1的報文段(ack_seq=y+1)；當客戶發(fā)送ack時，客戶端進入ESTABLISHED 狀態(tài)；當服務(wù)收到客戶發(fā)送的ack后，也進入ESTABLISHED狀態(tài)；第三次握手可攜帶數(shù)據(jù)。
展開 車載總線通信數(shù)據(jù)庫開發(fā)工具 — VDE
功能特點
? 支持 SOA 設(shè)計以及基于 SOME/IP 的通信系統(tǒng)設(shè)計
? 支持 CP/AP 平臺的數(shù)據(jù)庫開發(fā)，滿足 AUTOSAR 4.4.0標準
? 支持車型平臺的數(shù)據(jù)庫設(shè)計，多車型共享信號庫
? 根據(jù)信號的周期、收發(fā)節(jié)點等規(guī)則完成報文打包，信號排布
? 支持域控架構(gòu)的網(wǎng)關(guān)路由設(shè)置，可批量操作
? 可配置 DBC、Excel 模板，可配置智能檢查項
? 導出文件兼容Davinci、SWC Designer 和 CANoe 等工具
? 自動對比不同版本變更內(nèi)容，生成變更記錄
產(chǎn)品功能
? 數(shù)據(jù)庫開發(fā)
? 導入整車信號列表，根據(jù)信號與節(jié)點的收發(fā)關(guān)系和周期完成報文自動打包，信號排布
? 支持通信矩陣與DBC、LDF、Arxml文件轉(zhuǎn)換及節(jié)點拆分
? 導出網(wǎng)關(guān)路由表，查看報文路由和信號路由
? 導出報文的ID Map，方便查看ID的占用情況及周期分配
? 導出整車矩陣，方便查看報文路由的所有網(wǎng)段及所有接收端
? 網(wǎng)關(guān)路由設(shè)置
? 可批量設(shè)置源網(wǎng)段到目標網(wǎng)段的報文路由和信號路由
? 路由報文與源報文保持實時同步
? 支持域控制器的復雜架構(gòu)
? 可自動識別網(wǎng)關(guān)功能的收發(fā)和純路由的收發(fā)
? 網(wǎng)絡(luò)拓撲設(shè)計
? 依據(jù)拓撲連接和VLAN配置自動生成Switch的VLAN Membership
? 平臺信號庫
? 車型平臺共用平臺信號庫，便于維護及統(tǒng)一
? 支持 CAN、LIN 共用信號庫及 LIN 的復雜編碼
? Layout 信號排布
? 自由拖拽信號，進行 Start Bit 的調(diào)整
? 信號重疊時，標識出重疊位，并閃爍提示
? 支持 Motorola、
展開 車載以太網(wǎng)之SOME/IP-SD專題篇
Tx Path
正如之前的SOME/IP相關(guān)文章所述，SD模塊無論是發(fā)送還是接收，都需要與一個十分重要的以太網(wǎng)上層抽象模塊SoAd打交道，自然其發(fā)送與接收報文的過程也就會涉及到兩個模塊間的函數(shù)調(diào)用關(guān)系，具體的發(fā)送流程如下：
S1：SD報文已按照SD報文格式組包成功；
S2：如果是單播，則通過調(diào)用SoAd_SetRemoteAddr設(shè)置目標地址；如果是多播，則需要先通過通過調(diào)用函數(shù)SoAd_GetLocalAddr獲得本地地址，然后通過SoAd_SetRemoteAddr函數(shù)設(shè)置目標地址；
S3：最后通過調(diào)用SoAd_IfTransmit將SD報文發(fā)送至總線上；
如下圖10為SD Message的發(fā)送時序圖，便于大家對SD的報文發(fā)送的各個環(huán)節(jié)有個直觀的認識與理解。
圖10 SD報文發(fā)送時序圖
Rx Path
同理，對于SD報文的接收也需要經(jīng)歷以下幾個基本環(huán)節(jié)才能夠獲取到數(shù)據(jù)至SD模塊并得到正確處理。
展開 
康謀技術(shù) | 自動駕駛：揭秘高精度時間同步技術(shù)（一）
同步報文包括：Sync、Follow_Up、Delay_Req和Delay_Resp，時間同步過程如下，如圖3所示：
圖3：PTP時間同步過程
① 主時鐘周期性的發(fā)送 Sync 報文 (預(yù)計時間) → 從時鐘接收 Sync 報文 (時間 t2)；
② 主時鐘發(fā)送 Follow_Up 報文 (實際發(fā)送時間 t1) → 從時鐘接收 Follow_Up 報文；
③ 從時鐘發(fā)送 Delay_Req 報文 (發(fā)送時間 t3) → 主時鐘接收 Delay_Req 報文 (接收時間 t4)；
④ 主時鐘發(fā)送 Delay_Resp 報文 (包含時間 t4) → 從時鐘接收 Delay_Resp 報文；
⑤ 從時鐘根據(jù)網(wǎng)絡(luò)往返延時和時鐘偏差的測量結(jié)果，調(diào)整其本地時鐘。
值得注意的是，t1和t4時間由主時鐘記錄，t2和t3時間由從時鐘記錄。這樣我們就可以計算網(wǎng)絡(luò)延時和時間偏差。其中，網(wǎng)絡(luò)延時是Sync報文和Delay_Resp報文在網(wǎng)絡(luò)中往返傳輸?shù)臅r間，D=[(t2-t1)+(t4-t3)]/2。時間偏差是從時鐘與主時鐘之間的時間差，Δ=(t2?t1)?D。
具體來說，從設(shè)備會根據(jù)網(wǎng)絡(luò)延遲調(diào)整其接收到的同步報文的時間戳，以消除網(wǎng)絡(luò)傳輸帶來的延遲影響。同時，從設(shè)備還會根據(jù)時鐘偏差的測量結(jié)果，調(diào)整其本地時鐘的頻率或相位，使其與主設(shè)備的時鐘保持一致。
3、gPTP
此外，除了PTP時間同步協(xié)議，我們也會在自動駕駛領(lǐng)域時常看見gPTP（Generalized Precision Time Protocol）協(xié)議。gPTP和PTP都是基于IEEE標準的時間同步協(xié)議，其中PTP遵循IEEE 1588標準，而gPTP是IEEE 802.1AS標準。
展開 【新品發(fā)布】CAN(FD)、LIN總線通信和數(shù)據(jù)庫設(shè)計工具-VDE
基本功能
? 支持多個車型、網(wǎng)段、ECU的同時設(shè)計
? 支持CAN、LIN、CANFD的同時設(shè)計
? 支持導入導出網(wǎng)段和單節(jié)點DBC/LDF
? 支持車型、網(wǎng)段、節(jié)點、報文、信號的一致性檢查
? 支持Layout方式顯示信號排布，操作簡單直觀
? 支持網(wǎng)段的負載率及延時仿真分析
便捷功能
? 支持撤銷恢復Undo/Redo功能
? 支持報文、信號的拖拽
? 支持報文、信號等的排序、查找與統(tǒng)計
? 支持自動生成網(wǎng)關(guān)路由表
? 支持DBC/LDF與通信矩陣Excel的轉(zhuǎn)換
? 支持網(wǎng)段對比，生成Excel格式的變更記錄
? 自動記錄操作日志
? 支持豐富的快捷鍵
平臺信號庫
? 平臺車型共用平臺信號庫，信號同步更新
? 支持CAN、LIN、CANFD共用信號庫
? 支持導入信號庫功能
? 支持導入信號類型模板、快速創(chuàng)建信號
? 支持導入信號自動命名模板，規(guī)范化信號名稱
車型復用
? 支持網(wǎng)段鏡像
應(yīng)用場景：同一車系，多個不同子車型之間，PTCAN互相獨立，BDCAN相同時，則可以采用網(wǎng)段鏡像功能。
? 支持節(jié)點繼承
應(yīng)用場景：在新車型開發(fā)過程中，部分ECU直接延用舊車型ECU，此時，可使用節(jié)點繼承功能。
? 支持報文映射
應(yīng)用場景：報文路由時，為保證源報文與路由報文同步，可使用報文映射功能，同時網(wǎng)關(guān)節(jié)點可自動添加該報文的收發(fā)關(guān)系。
展開 自動駕駛時間同步
PTP通過在主從設(shè)備之間交互同步報文，并記錄下報文發(fā)送時間，從而計算網(wǎng)絡(luò)傳輸延遲和主從設(shè)備間時鐘的偏差。PTP定義了四條同步報文：Sync、Follow_Up、Delay_Req、Delay_Resp，精確同步過程如下。
（1）PTP主端口向從端口發(fā)送Sync報文，同步記錄下Sync發(fā)送的時間t1。從端口收到Sync報文后，記錄下收到的時間t2。
（2）緊接著主端口將t1時間放到Follow_Up報文發(fā)送給從端口，從端口收到此報文后就可以解析出t1，并由此得到第一個方程式：t1+網(wǎng)絡(luò)延時+時鐘偏差=t2。
（3）從端口向主端口發(fā)送Delay_Req報文，同步記錄下Delay_Req發(fā)送的時間t3。主端口收到報文后，記錄下收到的時間t4。
（4）緊接著主端口將t4時間放到Delay_Resp報文發(fā)送給從端口，從端口收到此報文后就可以解析出t4，并由此得到第一個方程式：t3+網(wǎng)絡(luò)延時-時鐘偏差=t4。
兩個未知數(shù)，兩個方程組，應(yīng)用初中數(shù)學知識可以解出：
網(wǎng)絡(luò)延時=[(t2-t1)+(t4-t1)]/2，
時鐘偏差=[(t2-t1)-(t4-t3)]/2。
展開 談?wù)凜AN總線對線束設(shè)計的要求及內(nèi)在機理
標準CAN和擴展CAN
CAN通訊協(xié)議是一個載波偵聽、基于報文優(yōu)先級碰撞檢測和仲裁（CSMA/CD+AMP）的多路訪問協(xié)議。CSMA的意思是總線上的每一個節(jié)點在企圖發(fā)送報文前，必須要監(jiān)聽總線，當總線處于空閑時，才可發(fā)送。CD+AMP的意思是通過預(yù)定編程好的報文優(yōu)先級逐位仲裁來解決碰撞，報文優(yōu)先級位于每個報文的標識域。更高級別優(yōu)先級標識的報文總是能獲得總線訪問權(quán)，即：標識符中最后保持邏輯高電平的會繼續(xù)傳輸，因為它具有更高優(yōu)先級。
ISO-11898:2003標準，帶有11位標識符，提供的最高信號速率從125Kbps到1Mbps。更遲一些的修訂標準使用了擴展的29位標識符。標準11位標識符位域參見圖3-1，提供2048個不同的報文標識符，擴展29位標識符位域參見圖3-2，提供537百萬個不同報文標識符。
3.1 標準CAN
標準CAN只有11位標識符，每幀的數(shù)據(jù)長度為51+（0~64）=（51~117）位。注：不計位填充（位填充將在本文第5節(jié)描述）。
圖3-1：標準CAN---11位標識符
SOF - 幀起始，顯性（邏輯0）表示報文的開始，并用于同步總線上的節(jié)點。
標識符 - 標準CAN具有11位標識符，用來確定報文的優(yōu)先級。此域的數(shù)值越小，優(yōu)先級越高。
RTR - 遠程發(fā)送請求位，當需要從另一個節(jié)點請求信息時，此位為顯性（邏輯0）。所有節(jié)點都能接收這個請求，但是幀標識符確定被指定的節(jié)點。響應(yīng)數(shù)據(jù)幀同樣被所有節(jié)點接收，可以被有興趣的節(jié)點使用。
IDE - 標識符擴展位為顯性時表示這是一個標準CAN格式，為隱形表示這是擴展CAN格式。
展開 