本發(fā)明涉及車聯(lián)網(wǎng)
技術領域：
，尤其涉及一種車載遠程通信方法。
背景技術：
：Telematics是遠距離通信的電信（Telecommunications）與信息科學（Informatics）的合成詞，通常指應用了無線通信技術的車載信息系統(tǒng)。Telematics是無線通信技術、衛(wèi)星導航系統(tǒng)、網(wǎng)絡通信技術和車載電腦的綜合產(chǎn)物，可使汽車駕乘者在車內(nèi)隨時隨地與外部后臺、服務資源做雙向的信息傳遞，享受實時化、位置化、個性化的各類應用服務。如圖1所示，Telematics系統(tǒng)通常包括以下裝置：汽車總線網(wǎng)絡CAN：所有汽車的執(zhí)行部件通過汽車網(wǎng)絡進行信息交換；TBOX（Telematics-Box，即Telematics系統(tǒng)的終端）：具有汽車總線接口，通過汽車總線接口與汽車總線網(wǎng)絡中任何一個控制部件進行信息交換及車輛控制；具有移動通信接口，通過移動通信接口，可以和云端服務器進行信息交換；具有串行通信接口，通過串行通信接口，可以和車機進行信息交換；云端服務器：按照用戶要求，提供各種網(wǎng)絡資源服務，可以通過移動通信基站接入/互聯(lián)網(wǎng)接入；車機端：具有串行通信接口，可以通過串行通信接口聯(lián)系到TBOX，間接訪問云端資源/汽車總線資源；手機：主要通過訪問云端服務器去完成與車輛的信息交換，實現(xiàn)汽車資源的訪問及控制；電腦：主要通過訪問云端服務器去完成與車輛的信息交換，實現(xiàn)汽車資源的訪問及控制。為保證車輛與云端服務器的通信安全可靠，不同廠商均定制有各自的通信協(xié)議，規(guī)定雙方的通信規(guī)范、流量控制、應用數(shù)據(jù)格式、安全驗證等機制。但目前還缺乏一種兼顧流量和連接效率的通信方法。技術實現(xiàn)要素：本發(fā)明所要解決的技術問題在于，提供一種節(jié)省移動通信流量，提高連接效率的車載遠程通信方法。為了解決上述技術問題，本發(fā)明提供一種車載遠程通信方法，包括：在車載端或服務器端發(fā)起會話前，檢查是否已有存在的連接，如有則使用該存在的連接，如無則建立新的連接；使用新建立的連接發(fā)起會話前，在車載端和服務器端之間進行身份驗證，身份驗證通過后根據(jù)具體流程發(fā)送消息，身份驗證未通過則流程終止；車載端使用該存在的連接或新建立的連接，每隔一定時間向服務器端發(fā)送一個心跳包，服務器端如果在設定時間內(nèi)沒有檢測到數(shù)據(jù)包，則主動斷開與車載端的連接。其中，服務器端首先檢查是否已有存在的連接，如果有則直接使用已經(jīng)存在的連接，如果沒有則振鈴通知車載端建立連接。其中，車載端每隔10秒向服務器端發(fā)送一個心跳包；服務器端檢測是否有數(shù)據(jù)包傳輸，如果超過10秒沒有數(shù)據(jù)包傳輸，服務器端再嘗試3次檢測，當達到30秒沒有數(shù)據(jù)包傳輸，服務器端將主動斷開與車載端的連接。其中，如果車載端或服務器端在接收的消息的錯誤元素中解析出錯誤值，則不再主動發(fā)送消息，并釋放之前所占用的系統(tǒng)資源。其中，所述車載端和服務器端之間的身份驗證過程包括：車載端通過CRC32算法生成第一AuthToken值，并填入身份驗證消息中；服務器端接收到身份驗證消息后，通過CRC32算法生成第二AuthToken值，并與所述第一AuthToken值進行對比，如果一致則身份認證通過，否則不通過；服務器端向車載端反饋身份驗證結果。其中，車載端發(fā)送身份驗證消息之后開啟定時器，在一定時間內(nèi)如果沒有收到服務器端的回復，則判定屬于超時，根據(jù)定時器超時回調(diào)函數(shù)發(fā)送的超時消息進行數(shù)據(jù)處理或超時處理，并在收到所述超時消息時清零所述定時器。其中，車載端對接收到的數(shù)據(jù)進行分割，按首包和后續(xù)包區(qū)分處理，當接收到完整數(shù)據(jù)的時候，則根據(jù)各應用標識APPID將數(shù)據(jù)分發(fā)到各個應用中。其中，所述車載端為車載智能盒TBOX，所述服務器端為TSP服務器。本發(fā)明實施例汽車遙控鑰匙學習方法所帶來的有益效果包括：通過短連接方法，一方面可以利用已存在的連接，避免頻繁的進行身份驗證，節(jié)約流量，同時提到連接效率；對于新建立的連接則需要身份驗證，同時保證了通信的安全性；另一方面利用心跳機制，如果在設定時間內(nèi)沒有數(shù)據(jù)包傳輸，則服務器端主動斷開與車載端的連接，避免長時間占用服務器資源所造成的服務器資源浪費；通過建立錯誤處理機制，當在消息中存在錯誤元素時，則不再主動發(fā)送消息，及時釋放所占用的系統(tǒng)資源，減少系統(tǒng)開銷。附圖說明為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。圖1是本發(fā)明實施例中Telematics系統(tǒng)組成示意圖。圖2是本發(fā)明實施例車載遠程通信方法的流程示意圖。圖3是本發(fā)明實施例中ACP消息的結構示意圖。圖4是本發(fā)明實施例中身份驗證流程示意圖。圖5是本發(fā)明實施例中服務器端發(fā)起會話時車載端的處理流程示意圖。圖6是本發(fā)明實施例中車載端發(fā)起會話時車載端的處理流程示意圖。具體實施方式以下各實施例的說明是參考附圖，用以示例本發(fā)明可以用以實施的特定實施例。請參照圖1所示，本發(fā)明實施例提供一種車載遠程通信方法，包括：在車載端或服務器端發(fā)起會話前，檢查是否已有存在的連接，如有則使用該存在的連接，如無則建立新的連接；使用新建立的連接發(fā)起會話前，在車載端和服務器端之間進行身份驗證，身份驗證通過后根據(jù)具體流程發(fā)送消息，身份驗證未通過則流程終止；車載端使用該存在的連接或新建立的連接，每隔一定時間向服務器端發(fā)送一個心跳包，服務器端如果在設定時間內(nèi)沒有檢測到數(shù)據(jù)包，則主動斷開與車載端的連接。以下進行具體說明?，F(xiàn)有的車載端與服務器端的通信連接方案一般包括兩種：一種是長連接：即連接一直存在，每輛車占用服務器的一個通道。優(yōu)點是能快速連接上服務器，通信能快速響應；而缺點則是由于長期占有服務器資源，造成服務器資源的浪費；另一種是超短連接：即每次通信均需要身份驗證，每次發(fā)送完信息都需要斷掉連接。優(yōu)點在于能快速釋放服務器資源；而缺點是由于頻繁通信造成移動流量的浪費，為了保證通信安全，需要每次通信均需要進行身份驗證，造成信息發(fā)送及接受效率過低及過慢。本發(fā)明實施例為了兼顧移動通信流量和連接效率，創(chuàng)新設計出一種短連接方案：對于車載端，首先檢查是否已有存在的連接，如果有則直接使用已經(jīng)存在的連接，如果沒有則根據(jù)具體流程建立；對于服務器端，同樣首先檢查是否已有存在的連接，如果有則直接使用已經(jīng)存在的連接，如果沒有則振鈴通知車載端建立連接。服務器端除非出錯，不會主動釋放連接，如果出錯，則將斷開連接。車載端發(fā)起會話一般用于車輛數(shù)據(jù)主動上傳，車輛異動，車輛救援，嚴重故障上傳等應用；服務器端發(fā)起會話一般用于如遠程控制，遠程監(jiān)控，遠程診斷，遠程升級等應用。車載端發(fā)起會話與服務器端發(fā)起會話的區(qū)別為：車載端發(fā)起會話并沒有振鈴的步驟，而服務器端發(fā)起會話需要振鈴的步驟，這樣的設計是針對車載端和服務器端的處理能力而進行合理的區(qū)別對待。由于車載端為車載ECU的一種，滿足一定的條件的時候需要休眠，以降低功耗，這樣則需要服務器端對其振鈴喚醒之后才能繼續(xù)處理命令；而服務器功能強大，能處理大量數(shù)據(jù)請求，并不需要振鈴喚醒過程。通過這種短連接方法，一方面可以利用已存在的連接，避免頻繁的進行身份驗證，節(jié)約流量，同時提到連接效率；對于新建立的連接則需要身份驗證，同時保證了通信的安全性；另一方面利用心跳機制，如果在設定時間內(nèi)沒有數(shù)據(jù)包傳輸，則服務器端認為車載端已經(jīng)掉線，主動斷開與車載端的連接，避免長時間占用服務器資源所造成的服務器資源浪費。作為一種實現(xiàn)方式，本實施例中，車載端為TBOX，即車載智能盒；服務器端為TSP（TelematicsServiceProvider，Telematics服務提供商）服務器。為敘述簡便，以下以TBOX和TSP服務器為例進行說明。心跳機制具體為：為了檢測TBOX是否在線，TBOX建立連接后，每隔10秒向TSP發(fā)送一個心跳包；TSP檢測通道上是否有數(shù)據(jù)包傳輸，如果超過10秒沒有數(shù)據(jù)包傳輸，TSP嘗試3次檢測，當達到30秒沒有數(shù)據(jù)包傳輸，則認為TBOX已經(jīng)掉線，TSP將主動斷開與TBOX的連接。由于每個網(wǎng)絡連接的打開都消耗一定的系統(tǒng)資源（內(nèi)存及進程的占用）及網(wǎng)絡流量，而TSP后臺同時并發(fā)的連接數(shù)量是一定的，為了提高通信效率，節(jié)省網(wǎng)絡流量及提高系統(tǒng)資源利用率，本實施例還設置了錯誤處理機制，即：如果車載端或服務器端在接收的消息的錯誤元素中解析出錯誤值，則不再主動發(fā)送消息，并釋放之前所占用的系統(tǒng)資源。上述錯誤元素為本發(fā)明實施例定義的應用通信協(xié)議ACP（ApplicationCommunicationProtocol）消息的一部分。請參照圖3所示，定義了ACP消息的消息頭和通用元素，其中消息中位順序：0~7代表從字節(jié)的最高位到最低位，由TCP傳輸協(xié)議保證消息的完整性、有效性和報文超時重傳等。ACP消息裝載在TCP協(xié)議中的應用報文中，其中：幀頭（SOF:StartOfFrame）和幀尾（EOF：EndOfFrame）是固定的字符，用于標志一幀完整的數(shù)據(jù)幀；消息頭（ApplicationHeader）為ACP協(xié)議的消息頭，主要包含的信息為整個ACP消息的長度；元素（Element）主要為要傳遞的信息主體。下面介紹重點字段：VehicleDescriptor：用于描述汽車的唯一標號，其中包括汽車的VIN號，TBOX序列號，通信模塊的IMEI、ICCID，這幾個號組合在一起形成VehicleDescriptor。Source：取值范圍為0-255，由TSP服務器端下發(fā)到TBOX，以標志同一流程中不同的會話開始，TBOX后續(xù)回復中必須使用相同的Source值。由TBOX自動發(fā)起的交互中，如果存在Source元素，則設置Source值為0；當一個會話完成后（即整個流程完成后），Source值被重置，下一會話可以再次使用該Source值，例如：當TSP服務器向車機發(fā)送多條異步遠程控制命令時，通過該值區(qū)分返回值為哪一條遠程控制命令所發(fā)起。AuthToken：當TBOX建立連接后，通過TSP服務器驗證身份完畢時，由TSP服務器根據(jù)TBOX身份信息生成唯一的AuthToken值，AuthToken用于標識TBOX身份信息，當TBOX收到AuthToken值時，根據(jù)相同算法計算出該值，與從TSP服務器收到的進行比較，如果相同則驗證通過。ErrorElement：協(xié)議中包含的所有ErrorCode匯總，如果該元素ErrorCode值為非零，則流程結束。如果消息下的元素ErrorElement出現(xiàn)非零錯誤（參見表1），則表示該流程結束。TBOX和TSP收到該錯誤后都不再主動發(fā)送消息，并釋放之前應用占用的系統(tǒng)資源（內(nèi)存，連接），如果需要繼續(xù)之前的服務，則需要重新發(fā)起。表1為錯誤類型列表：表1錯誤類型列表錯誤值含義0無錯誤1AuthToken驗證失敗2車輛認證失敗3TSP身份驗證失?。ê笈_下發(fā)）4ACP協(xié)議解析錯誤5CAN通信錯誤6TBOX系統(tǒng)忙7無效指令8包序號錯誤9CRC驗證失敗10任務執(zhí)行失敗11任務執(zhí)行超時12應答數(shù)據(jù)過長13車輛配置錯誤14任務執(zhí)行條件不滿足15功能禁止16VIN號錯誤17車輛未上電18電壓異常TBOX與TSP服務器交互時，無論是通過TSP服務器通知發(fā)起的流程或是TBOX主動發(fā)起的流程，建立連接后都需要首先發(fā)起身份驗證流程，通過后則根據(jù)具體流程發(fā)送消息，如沒有通過則流程終止?；谏鲜鯝CP消息，在TBOX和TSP服務器之間的身份驗證過程如圖4所示：TBOX通過CRC32（循環(huán)冗余校驗碼）算法生成第一AuthToken值，并填入身份驗證消息中；TSP服務器接收到身份驗證消息后，通過CRC32算法生成第二AuthToken值，并與第一AuthToken值進行對比，如果一致則身份認證通過，否則不通過；TSP服務器向TBOX反饋身份驗證結果。請再參照圖5所示，為TSP服務器主動發(fā)起會話的時候，TBOX的處理流程。其中本實施例建立了超時處理機制，具體流程為：TBOX發(fā)送身份驗證消息之后開啟定時器，在一定時間內(nèi)如果沒有收到TSP服務器的回復，則判定屬于超時，根據(jù)定時器超時回調(diào)函數(shù)發(fā)送的超時消息進行數(shù)據(jù)處理或超時處理，并在收到該超時消息時清零該定時器。由于TSP服務器與TBOX之間的移動通信是串口通信，則涉及到數(shù)據(jù)的分割問題，需要進行首包和后續(xù)包的區(qū)分處理。當接收到完整的數(shù)據(jù)的時候，則會根據(jù)各應用標識（APPID）將數(shù)據(jù)分發(fā)到各個應用中。再如圖6所示，為TBOX主動發(fā)起會話，或TSP服務器請求TBOX數(shù)據(jù)時，TBOX回復數(shù)據(jù)，TBOX的處理流程。各個應用根據(jù)需要進行數(shù)據(jù)的打包，填入幀頭幀尾，計算CRC，根據(jù)身份驗證還是應用報文的不同填入不同的數(shù)據(jù)內(nèi)容，并把發(fā)送是否成功返回給各個應用業(yè)務。綜上所述，本發(fā)明實施例所帶來的有益效果包括：通過短連接方法，一方面可以利用已存在的連接，避免頻繁的進行身份驗證，節(jié)約流量，同時提到連接效率；對于新建立的連接則需要身份驗證，同時保證了通信的安全性；另一方面利用心跳機制，如果在設定時間內(nèi)沒有數(shù)據(jù)包傳輸，則服務器端主動斷開與車載端的連接，避免長時間占用服務器資源所造成的服務器資源浪費；通過建立錯誤處理機制，當在消息中存在錯誤元素時，則不再主動發(fā)送消息，及時釋放所占用的系統(tǒng)資源，減少系統(tǒng)開銷。以上所揭露的僅為本發(fā)明較佳實施例而已，當然不能以此來限定本發(fā)明之權利范圍，因此依本發(fā)明權利要求所作的等同變化，仍屬本發(fā)明所涵蓋的范圍。當前第1頁1 2 3