黎揚(yáng),何適
(上海北匯信息科技有限公司,上海 201800)
隨著網(wǎng)聯(lián)化逐漸成為汽車的標(biāo)配,而T-Box作為車聯(lián)網(wǎng)的一個(gè)關(guān)鍵環(huán)節(jié),從起初單純的實(shí)現(xiàn)車輛信息采集,已發(fā)展到具有車輛信息監(jiān)測(cè)及信息交互(V2X)、車輛遠(yuǎn)程控制、安全監(jiān)測(cè)和報(bào)警、遠(yuǎn)程診斷、邊緣計(jì)算等多種離線和在線應(yīng)用功能的載體。為保障T-Box功能的正常運(yùn)轉(zhuǎn),對(duì)其進(jìn)行功能測(cè)試尤為重要。由于T-Box與車內(nèi)控制器通過傳統(tǒng)總線或車載以太網(wǎng)進(jìn)行信息交互,與車外TSP(Telematics Service Platform)通過蜂窩基站無線技術(shù)進(jìn)行信息交互,針對(duì)“Input仿真”與“Output監(jiān)測(cè)”閉環(huán)的自動(dòng)化測(cè)試存在一定難度,故基本通過手動(dòng)或半自動(dòng)化的傳統(tǒng)方式進(jìn)行測(cè)試,依靠“人在環(huán)”方式記錄測(cè)試數(shù)據(jù)以及判斷測(cè)試結(jié)果。但該方式測(cè)試效率低且覆蓋度受限,難以滿足研發(fā)的快速迭代和深度驗(yàn)證的要求。
同時(shí)在項(xiàng)目開發(fā)前期,由于T-Box、TSP后臺(tái)、App可能由不同的廠家負(fù)責(zé)開發(fā),每個(gè)產(chǎn)品開發(fā)的進(jìn)度和完整度是不一致的,所以為了更早地對(duì)T-Box的功能進(jìn)行自動(dòng)化測(cè)試和驗(yàn)證,如果T-Box與TSP后臺(tái)的通信使用了MQTT協(xié)議,則可以利用MQTT協(xié)議的特點(diǎn),通過CANoe仿真另外一個(gè)Client,實(shí)現(xiàn)CANoe、Broker和T-Box之間的信息交互。
MQTT(Message Queuing Telemetry Transport,消 息 隊(duì)列遙測(cè)傳輸協(xié)議)是IBM在1999年發(fā)布的一種基于發(fā)布/訂閱(Publish/Subscribe)模式的“輕量級(jí)”通信協(xié)議。該協(xié)議可用極少的代碼和有限的帶寬,為連接遠(yuǎn)程設(shè)備提供實(shí)時(shí)可靠的消息服務(wù)。作為一種低開銷、低帶寬占用的即時(shí)通信協(xié)議,MQTT在物聯(lián)網(wǎng)等領(lǐng)域有很廣泛的應(yīng)用。
MQTT也是一種基于客戶端-服務(wù)器的發(fā)布/訂閱消息協(xié)議,包含發(fā) 布 者(Publisher)、代理(Broker)、訂 閱 者(Subscriber)3個(gè)角色。發(fā)布者和訂閱者之間沒有直接連接,需要通過Broker進(jìn)行消息的存儲(chǔ)和轉(zhuǎn)發(fā),而Broker又通過主題(Topic)進(jìn)行消息的發(fā)送和接收。一個(gè)典型的MQTT消息通信流程如圖1所示。
圖1 MQTT通信模型
1)發(fā)布者(Publisher)連接到Broker。
2)訂閱者(Subscribers)連接到Broker,并訂閱主題“vehiclespeed”。
3)發(fā)布者(Publisher)發(fā)送給Broker一條消息,主題為“vehiclespeed”。
4)Broker收到Publisher的消息后,發(fā)現(xiàn)Subscriber訂閱了“vehiclespeed”主題,然后將消息轉(zhuǎn)發(fā)給Subscriber。
5)訂閱者(Subscribers)從Broker接收發(fā)布者(Publisher)發(fā)送的消息。
CANoe的連接特性服務(wù)(Connectivity Features Service)主要用于物聯(lián)網(wǎng)或工業(yè)領(lǐng)域支持MQTT協(xié)議的設(shè)備,CANoe將這些設(shè)備抽象成分布式對(duì)象(Distributed Objects),通過本地網(wǎng)絡(luò)(Local Network)或云端代理服務(wù)器實(shí)現(xiàn)各客戶端之間的通信。同時(shí)CANoe15.0版本新增了一種新的通信方式,讓代理(Broker)在CANoe中運(yùn)行來實(shí)現(xiàn)通信,從而實(shí)現(xiàn)一些故障注入的測(cè)試。
本文主要以本地網(wǎng)絡(luò)的形式對(duì)MQTT的仿真和測(cè)試進(jìn)行介紹,其中發(fā)布者和訂閱者通過CANoe仿真實(shí)現(xiàn),Broker可使用真實(shí)的服務(wù)器,或者在本地電腦搭建測(cè)試用Broker,將Broker地址(需使用外網(wǎng)的IP或域名)和端口配置到TBox中。
Broker搭建完成后,在CANoe的Options設(shè)置窗口中配置Broker的IP地址和端口(MQTT功能僅在連接CANoelicense時(shí)可用),示例如圖2所示。
圖2 CANoe MQTT配置界面
在 仿 真MQTTClient之 前,需 要 在CANoe的CommunicationSetup環(huán)境中手動(dòng)創(chuàng)建Distributed Objects的接口(Interfaces)和對(duì)象(Objects),或者通過vCDL文件,創(chuàng)建MQTT的數(shù)據(jù)庫。
手動(dòng)創(chuàng)建MQTT數(shù)據(jù)庫流程如下。
1)創(chuàng)建需要的通信接口。
2)選擇Objects,創(chuàng)建需要通信的對(duì)象。
3)為每個(gè)對(duì)象創(chuàng)建對(duì)應(yīng)的數(shù)據(jù)。
4)選擇創(chuàng)建的Data數(shù)據(jù),在右側(cè)MQTT配置窗口中配置其屬性值。
創(chuàng)建vCDL數(shù)據(jù)庫的流程如下。
1)打開“Open vCDL Editor”。
2)創(chuàng)建MQTT的接口、對(duì)象和數(shù)據(jù)。
3)定義MQTT的屬性值。
4)選擇import Data Source導(dǎo)入創(chuàng)建好的vCDL文件。
vCDL導(dǎo)入成功以后,可查看定義屬性及參數(shù),如圖3所示。
圖3 MQTT模型編輯界面
使用vCDL創(chuàng)建MQTT數(shù)據(jù)庫的示例如圖4所示。
圖4 MQTT vCDL數(shù)據(jù)庫開發(fā)界面
通過上面的配置,下面以遠(yuǎn)程解閉鎖控制測(cè)試為例,為大家介紹測(cè)試執(zhí)行過程。
測(cè)試環(huán)境如圖5所示,由于此測(cè)試方案CANoe是調(diào)用測(cè)試電腦的網(wǎng)卡與Broker進(jìn)行通信,所以需要測(cè)試電腦可連接外網(wǎng)。
圖5 T-Box測(cè)試環(huán)境
當(dāng)CANoe運(yùn)行時(shí),會(huì)自動(dòng)連接到Broker。測(cè)試數(shù)據(jù)流如下。
1)CANoe(Publisher)首先仿真TSP發(fā)送遠(yuǎn)程解鎖請(qǐng)求給Broker。
2)Broker根據(jù)Topic,自動(dòng)轉(zhuǎn)發(fā)該請(qǐng)求給T-Box(Subscriber)。T-Box收到該遠(yuǎn)程請(qǐng)求后,通過CAN或Ethernet將遠(yuǎn)程解鎖請(qǐng)求發(fā)送至車內(nèi)節(jié)點(diǎn)。
3)CANoe仿真車內(nèi)節(jié)點(diǎn)反饋遠(yuǎn)程解鎖成功的應(yīng)答。
4)收到遠(yuǎn)程解鎖成功應(yīng)答后,T-Box(Publisher)把遠(yuǎn)程解鎖執(zhí)行結(jié)果上傳至Broker,Broker根據(jù)Topic,自動(dòng)轉(zhuǎn)發(fā)該請(qǐng)求給CANoe(Subscriber)。
測(cè)試交互的數(shù)據(jù)如圖6所示。
圖6 CANoe MQTT數(shù)據(jù)監(jiān)控窗口
本方案利用MQTT協(xié)議的技術(shù)特點(diǎn),無需TSP提供額外的API接口,即可實(shí)現(xiàn)T-Box遠(yuǎn)程功能的自動(dòng)化測(cè)試,可以在項(xiàng)目早期完成對(duì)T-Box的功能驗(yàn)證。根據(jù)不同的技術(shù)特點(diǎn),北匯信息已實(shí)現(xiàn)在線測(cè)試、離線分析等不同的T-Box自動(dòng)化測(cè)試的方案,歡迎大家進(jìn)一步溝通交流。
注:文中部分圖片來源于Vector。