楊光友, 姜 帆
(1 湖北工業大學機械工程學院, 湖北 武漢 430068;2 湖北省農機裝備智能化工程技術研究中心, 湖北 武漢 430068)
為了保障燃料電池汽車在運行時的安全性與可靠性,及時發現車輛的安全隱患,需要對燃料電池汽車的監測系統進行深入研究。加拿大GREEN LIGHT公司開發了燃料電池監測系統,適用于質子交換膜燃料電池與固體氧化燃料電池,能夠對電池的各種參數進行監測[1]。北京理工大學研發的遠程監控系統用來監測電動公交車電動機和電池的運行狀態,能夠發現和處理公交車的故障[2]。上汽集團技術中心等單位共同開發了一套新能源汽車監控系統,實現了監控中心與車載終端的雙向通信[3]。
本文針對燃料電池乘用車(FCV)提出了車載OBD數據采集系統。相比于與傳統內燃機的汽車,燃料電池乘用車各個部件(如燃料電池、蓄電池、DC變換器、電機等)都擁有獨立的控制單元,通過CAN總線相互連接與通信,并利用OBD接口與外界交互,其基于OBD的采集系統可以直接與車輛進行通信,獲取數據并上傳到遠程服務器。
基于OBD系統的燃料電池乘用車(FCV)數據采集系統的功能包括:OBD系統數據采集,加速度、陀螺儀數據采集,GPS數據采集,4G遠程傳輸以及采集數據的本地存儲。
通過OBD系統即車載自診斷系統可獲取各個控制單元的內部參數[4-5],其他(如車輛行駛加速度等)則通過增加慣性傳感器獲取,車輛的經緯度數據來自GPS模塊。這些數據通過串口發送至控制器。
車載采集系統實時采集汽車的運行參數,要求系統穩定可靠、成本低、功耗低。而嵌入式系統是能夠根據用戶的要求對軟硬件進行裁剪的專用計算機,在監控系統中最常用的是ARM處理器。系統總架構圖如圖1所示。

圖1 系統總架構
OBD協議有很多,汽車K線協議在比較老的車型中使用相對廣泛,現在大部分已經被CAN總線取代。基于CAN總線的代表協議在歐洲使用比較廣泛的是ISO 15765[6-7],在美國使用廣泛的是SAEJl939[8]。本系統使用的ISO 15765協議是一種基于CAN總線的車輛診斷協議,該協議是根據 ISO/OSI 的7層參考模型建立而來的。目前ISO 15765協議廣泛應用于轎車等車輛控制單元的故障診斷方面。根據ISO 15765標準協議的定義[9],從網絡層傳送來的數據報文經由數據鏈路層處理后可以在總線上以報文幀的形式傳輸。ISO 15765標準協議指明了CAN總線上傳輸的數據既可以使用 CAN 的標準幀格式,也可以使用 CAN的擴展幀格式進行傳送[10]。
1.2.1控制器系統整體硬件結構如圖2所示。控制器采用了基于NXP的32位Cortex A7的處理器i.MX6ULL作為控制板[11]。該控制板廣泛應用于各種工業控制環境,具有價格低廉、穩定性好等優點,可以運行LINUX系統,對網絡功能有著良好的支持。該控制板具有528 MHz主頻,滿足基本的運算要求,擁有512 MB內存和8 GB EMMC,具有十分豐富的外設資源。

圖2 控制器原理
1.2.2CAN總線通信IMX.6ULL控制板通過CAN總線接收OBD系統的數據。該控制板帶有 CAN 控制器外設,即FlexCAN。FlexCAN 符合 CAN2.0B 協議,完全符合CAN協議,支持標準格式和擴展格式,支持64個消息緩沖。
CAN接口通信原理圖如圖3所示。圖中CAN1_TX和CAN1_RX分別是I.MX6ULL FlexCAN1的發送和接收引腳,對應I.MX6ULL 的 UART3_CTS 和 UART3_RTS 這兩個引腳。TJA1050 是 CAN 收發器,通過 TJA1050向外界提供 CAN_H 和 CAN_L 總線,R10是一個 120 Ω的端接匹配電阻,用來消除在通信電纜中的信號反射。

圖3 CAN總線原理
1.2.34G通信模塊IMX.6ULL控制板通過4G模塊將數據上傳到遠程服務器。該控制板板載了ME3630 4G模組,原理如圖4所示。ME3630是一款全網通 4G 模塊,廣泛用于各種工業監控場合[12]。在LTE模式下可以提供50 Mbps上行速率,以及150 Mbps的下行速率,并支持回退到3G或2G網絡。同時該模組也支持GPS定位功能,完全符合系統功能要求。IMX.6ULL控制板通過MiniPCIE接口與4G模組相連,HUBDP2與HUBDM2是該模塊的通信引腳。

圖4 4G模塊原理
1.2.4SD卡IMX.6ULL控制板通過SD卡接口將數據保存到本地。該控制板板載了一個SD卡接口,其原理圖如圖5所示。該卡采用4位uSDHC方式驅動,非常適合高速存儲。

圖5 SD卡原理
USDHC1_DATA0~DATA3/USDHC1_CLK/USDHC1_CMD分別連接在I.MX6ULL的SD1_DATA0~DATA3/SD1_CLK/SD1_CMD引腳上。USDHC1_CD_B是SD卡檢測引腳,用于檢測SD卡插拔過程,連接到I.MX6U的UART1_RTS引腳上。
系統軟件功能模塊如圖6所示。

圖6 基于OBD的FCV監測系統
根據系統功能需求,控制系統使用Linux4.15嵌入式操作系統,采用多線程編程方式,整個系統軟件通過5個線程實現。根據系統各個功能模塊間的相互關系,線程調度如圖7所示。

圖7 系統調度
OBD指令發送線程通過信號量1控制OBD系統數據接收線程,在接收到信號量1之前,OBD系統數據接收線程處于阻塞狀態。當OBD指令發送線程發出OBD數據請求指令后,該線程將向OBD系統數據接收線程發送信號量1,喚醒OBD系統數據接收線程,接收OBD系統數據。當數據接收結束之后,OBD系統數據接收線程重新進入阻塞狀態,等待下一次OBD指令發送線程的喚醒。
為了防止TCP線程重復發送舊數據,浪費流量,在信號量到來之前,TCP線程受到信號量的控制,整個線程處于阻塞狀態,直到收到GPS數據采集線程、加速度傳感器采集線程、OBD系統數據接收線程的信號量之后才會被喚醒,其后將數據傳送至遠程服務器。數據傳輸完成之后,該線程將重新進入阻塞狀態,等待下一次被喚醒。
OBD指令發送線程主要負責向OBD系統發送數據請求指令,控制器在接收OBD數據之前要向OBD系統發送請求指令,發送請求指令后控制器才能夠接收到OBD系統的數據。程序實現的偽代碼如下:
OBD_Send_Thread()
{
Initialize();
∥初始化
fd = Socket();
∥創建套接字
Ioctrl();
∥指定CAN設備
Bind();
∥綁定CAN設備
Send(fd,cmd);
∥發送讀取數據指令
Sem_post(signal)
∥發送信號量,標記線程完成
}
在LINUX系統中,CAN設備作為網絡設備進行管理,因此在CAN總線應用開發方面, Linux 提供了SocketCAN 接口,使得 CAN 總線通信近似于和以太網的通信,應用程序開發接口更加通用,也更加靈活。
當線程開啟之后,首先利用Socket函數創建SocketCAN套接字,隨后使用Ioctl函數指定Can設備,最后使用bind函數將套接字與CAN設備綁定,完成CAN設備初始化過程。由于線程主要使用CAN設備進行數據接收,系統可以根據預先設置的過濾規則,實現對報文的過濾。
系統使用ISO 15765協議與OBD系統通信,OBD系統的CAN標準幀的ID為0X7DF。這個CANID是OBD系統本身的一個CANID,指令格式為02 01 PIDx 00 00 00 00 00。發送的數據中,02代表數據長度,后面有效字節長度為2。01代表服務號,也叫SID,其中01是動力有關的數據,01服務為用的最多的一個服務。PIDx是參數ID,具體定義可查詢ISO 15031-5協議標準,其中一部分如表1所示。以車速為例,IMX.6ULL控制板通過CAN總線發出HEX字節“02 01 0D 00 00 00 00 00”,OBD系統反饋“04 41 0D 0B 3E 00 00 00”,接收到的數據為行車電腦返回的數據。CAN報文數據為“04”,代表后續有效字節有4個。41為對01服務的一個應答,所有行車電腦返回的數據,都會在請求數據的基礎上加0x40返回(0X01+0X40即0x41)。0D對應請求命令中的0D,代表車速。0B 3E代表車速值,轉換成十進制為km/h。

表1 ISO15031-5協議部分標準
OBD系統數據接收線程的主要任務是負責接收OBD系統傳出的數據。該線程在未收到OBD指令發送線程之前處于阻塞狀態,當收到OBD指令發送線程發出的信號量時被喚醒,開始讀取OBD系統數據。在接收到數據之后將發送信號4,用于標記完成一次數據接收。程序實現的偽代碼如下:
OBD_Read_Thread()
{
Initialize();
∥初始化
fd = Socket();
∥創建套接字
Ioctrl();
∥指定CAN設備
Bind();
∥綁定CAN設備
If(signal)
∥是否收到信號量
Read(fd,data);
∥讀取數據
Sem_post(signal);
∥發送信號量,標記線程完成
else
Sem_wait(signal);
∥等待
}
TCP線程負責將接收到的CAN數據通過TCP透傳發送至服務器。ME3630 4G模組支持AT指令配置,在線程開啟之后,需要通過串口發送AT指令對其進行配置。配置指令見表2,配置方法如下:使用串口發送AT指令“AT+ZSWITCH=L”,用來將模組配置為ECM模式。之后使用 AT 指令+CGDCONT 來設置數據參數,聯通卡的 APN 為 3gnet,電信卡的 APN為 ctnet,移動卡的 APN 為 cmnet。比如用聯通卡,設置 APN 為 3gnet,命令如下:AT+CGDCONT=1,"IP","3gNET"。最后發送AT連接命令“AT+ZECMCALL=1”。

表2 AT指令表
在Linux系統中對網絡之間的進程通信提供了專門的Socket接口,應用層只需要調用Socket接口就可以實現TCP/IP網絡通信。
線程開啟之后,在線程內使用socket()函數用于創建一個socket描述符(socket descriptor),它唯一標識一個socket,后續的操作都有用到它,把它作為參數,通過它來進行一些讀寫操作。之后調用connect()函數,這個函數用于客戶端中,將socket描述符與遠端IP地址、端口號進行綁定,在TCP客戶端中調用這個函數將發生握手過程(會發送一個TCP連接請求),并最終建立一個TCP連接。
建立連接完成之后,線程處于阻塞狀態,直到被信號量喚醒,才可以利用socket描述符與write函數將接收到的數據發送至服務器。當服務器收到系統發送的數據之后,會回復{OK}字符,如果沒收到回復則視為連接中斷,將重新建立與服務器的連接。TCP線程程序實現的偽代碼如下:
TCP_Thread()
{
2016年6月-2018年9月,通過電視等媒體發布黃色預警35次,為山東省各級國土資源相關部門及人員發送預警短信十三萬余條,近三年汛期發生的9起突發性地質災害,均成功預報。由于提前預警、防范措施到位,實現了多次強臺風過境期間人員零傷亡,最大限度避免了人民群眾的生命財產損失,取得了良好的防災減災效果。
Initialize();
∥初始化
fd = Socket();
∥創建套接字
Connect();
∥建立連接
If(signal);
∥是否收到信號量
Sendfd,data);
∥發送采集到的數據
If(answer)
∥是否收到了服務器的應答
Sem_wait(signal);
∥等待
else
∥重新建立連接
else
Sem_wait(signal);
∥等待
}
加速度數據、陀螺儀數據接收線程主要通過串口接收加速度傳感器數據。當線程開啟后,首先初始化串口,隨后通過串口接收加速度數據、陀螺儀數據,將數據解析之后發送信號量3,用來通知TCP線程。其實現的偽代碼如下:
IMU_Thread()
{
Initialize();
∥初始化串口
Read(fd,data);
∥讀取IMU數據
Resolute();
∥解析加速度、陀螺儀數據
Sem_post(signal);
∥發送信號量,標記線程完成
}
位置數據是通過GPS模塊接收GPS數據后解析得到的。GPS數據接收線程負責GPS的數據接收與解析。當線程開啟之后,首先初始化串口,隨后使用串口接收來自傳感器的GPS數據
因為傳感器發出的GPS數據采用NMEA協議格式,輸出為GPRMC幀。GPRMC幀的數據式為:$GPRMC,(1),(2),(3),(4),(5),(6),(7),(8),(9),(10),(11),(12)*hh(CR)(LF),各個數據幀字段意義如表3所示。

表3 NMEA協議格式表
這里需要對NMEA格式的數據進行數據解析才能獲取到經緯度數據。解析方式采取字符串分割的方式進行,將數據按照“,”進行分割之后,將各個字段的數據儲存到對應的二維數組中,最后將解析出來的經緯度數據轉存至全局緩存區,用于TCP線程的發送。其實現的偽代碼如下:
GPS_Thread()
{
Initialize();
∥初始化串口
Read(fd,data);
∥讀取GPS數據
Resolute();
∥解析定位數據
Sem_post(signal);
∥發送信號量,標記線程完成
}
為驗證系統的可行性,將系統裝車進行了初步的測試試驗(圖8)。

圖8 系統裝車試驗
圖9為系統采集的實驗數據上傳至遠程監測系統的界面。

圖9 遠程監測系統界面
實驗結果表明,在服務器端可以實時接收到監測系統通過4G模塊傳遞的各項數據,實現了系統的各項功能。
本文針對燃料電池乘用車(FCV)設計了一套基于OBD的數據采集系統,完成了車載監測終端系統的硬件電路設計、選型與軟件編寫,進行了數據采集與上傳試驗,驗證了系統的可行性。該系統響應速度快,可增加人機交互功能,實時顯示采集系統采集的各項數據,并可進一步結合故障診斷方法對車輛進行實時預警。由于5G技術的迅速發展為車聯網提供了良好的技術支持[13],后續可以考慮使用5G通信技術進行遠程傳輸,以提高傳輸的速率,增強系統的實時性。