挑戰：燃料電池城市客車部件多、信號復雜，某些部件（如燃料電池、鎳氫輔助電池等）還存在運行安全問題，需對各個部件進行實時監測及故障診斷，保證整車的安全性；同時還需記錄試驗數據，分析各個部件的運行特性，為整車控制策略提供依據。傳統的信號采集與信號處理方式已不能勝任，急需一種全新的解決方案。

    應用方案：設計燃料電池城市客車的整車CAN通訊網絡，用NI的CAN卡和LabVIEW搭建一個基于PC的信號監測與故障系統，對整車各個部件進行實時監測和故障診斷，并記錄試驗數據，然后采用NI的DIAdem對試驗數據進行處理，并生成試驗報表。

    使用的產品：LabVIEW6.1, DIAdem9.0， PCMCIA-CAN/2 (Serious2)。

    介紹

    燃料電池城市客車屬于混合動力汽車，其特點是車載電子控制單元多、整車信號煩雜。傳統的信號采集與信號處理方式很難勝任，控制器局域網（CAN）以其拓撲結構簡單、信號傳輸可靠等優點，可滿足整車各個部件的實時監測與故障診斷需求。NI公司推出了基于PCMCIA 接口的CAN卡，并提供了功能完善的API函數，可在LabVIEW環境下很方便的搭建CAN總線信號采集與故障診斷系統。此外，NI公司推出的數據分析軟件DIAdem，可與LabVIEW進行無縫連接，對試驗數據進行分析處理并生成試驗報表。

    整個系統的完成用時不到一個月，可以說，NI為我們提供了一整套高效、可靠的開發工具。

    系統組成

    燃料電池城市客車的系統組成如圖1所示，它包括用于傳輸大電流驅動功率的能量總線和用于傳送監測信號及控制命令的信號總線——CAN總線。各個汽車子部件均包含一個CAN節點，用于向CAN總線發送自身的監測信號并接收整車控制器命令。

    信號監測與故障診斷系統的構成如圖2所示，在Windows平臺上，用LabVIEW開發系統應用程序，通過NI的PCMCIA接口形式的CAN卡采集CAN總線數據，實現對整車的信號監測與故障診斷，同時利用NI的數據分析軟件DIAdem與LabVIEW進行通訊，實現數據的自動存儲、分析，并生成試驗報表。

    CAN總線技術

    控制器局部網（CAN－Controller Area Network）是一種有效支持分布式控制或實時控制的串行通信網絡。多個CAN控制器節點以CAN總線為物理媒介相聯系，每個節點均可在總線空閑期間向總線發送符合CAN通信協議的報文，如果同時有多個節點請求發送報文，即出現總線訪問沖突時，則根據傳送報文標識符ID所定義的優先權進行逐位仲裁，具有最高優先權的節點獲得總線訪問權，其它節點則停止發送數據。目前主要的CAN協議技術規范是1991年9月由Philips Semiconductors制定發布的Version2.0，該技術規范包括A和B兩部分。CAN協議廢除了傳統的站地址編碼，采用數據編碼——由11位（標準通信模式）或29位（擴展通信模式）二進制標識碼對數據塊進行標識，因此可定義211或229個不同的數據塊。這種通信方式具有網絡結構簡單、可擴展性強、靈活性高、抗干擾能力強等優點。此外，它還具有錯誤檢測和錯誤界定功能，可判別暫時錯誤和永久性故障并自動斷開故障節點的功能，容錯性能很好，是非常理想的現場控制和車載系統控制方案。

    NI公司推出的CAN總線技術不僅包括PCI、PCMCIA等各種接口形式的CAN卡（支持2.0A和2.0B協議），還封裝好了對應的API函數，在LabVIEW中只需簡單調用NI-CAN的子VI即可實現與CAN總線的通訊。我們采用的是NI的Serious 2系列CAN卡，它以SJA1000作為CAN控制器，不僅通訊速率高（最高可到1M波特率），還具有CAN網絡診斷功能，可以檢測出CAN總線的各種故障，是非常理想的CAN網絡開發工具。

    系統軟件設計

    圖形化、模塊化是LabVIEW的最大特點，在降低硬件操作難度的同時，它還大大簡化了系統的構建以及代碼的編寫，可以使開發者把主要精力集中在系統的設計上，從而開發出功能完善、可靠性高、界面友好的應用程序。此外，LabVIEW功能強大而簡單易學的特點，也是我們選擇它作為開發工具的主要原因之一。

    信號監測與故障診斷系統主要包括兩個模塊：在線實時監測系統，數據回放及故障再現系統。

    在線實時監測系統主要負責在汽車運行過程中，實時監測各個部件的各種運行參數，并根據這些參數對其進行故障診斷，在發現故障的時候及時報警，避免事故的發生。此外，它還必須將這些實時數據保存到硬盤中，以供離線分析和報表制作所用。實時監測系統又劃分為若干功能模塊，如圖3所示。其中，數據采集、數據轉換、故障診斷和數據存儲是基本功能模塊，這一線程的實時性要求最高；而數據顯示、數據查看和汽車性能試驗模塊主要負責與用戶進行交互，實時性要求不高。因此在程序設計中應給前一個線程付以高優先級。該系統的部分LabVIEW程序框圖如圖4所示，圖中下方的While循環采用了Event結構，用于響應用戶輸入以及顯示數據，由于該線程優先級要求不高，因此設置了100ms的等待延時。

    在線實時監測系統的前面板如圖5所示。從圖中可以看出，系統監測的信號非常多、非常復雜，主要分成以下幾個區域：整車狀態顯示區（左上方）——用于顯示車速、電機轉速、檔位、加速踏板、制動踏板以及各個動力部件的功率消耗等信號；電機狀態顯示區（“Motor”區域）——用于顯示電機控制器電流、控制器溫度、電機溫度等信號；整車控制器狀態顯示區（“Main Controller”區域）——用于顯示整車控制器發出的轉矩需求、對燃料電池的功率需求、對主DC/DC的輸出電壓需求以及各個部件的開關等控制命令；主DC/DC狀態顯示區（“Main DC/DC”區域）——用于顯示主DC/DC的實際輸出電壓、電流以及溫度等信號；燃料電池狀態顯示區（“FC”區域）——用于顯示燃料電池的輸出電壓、電流、冷卻水溫、單體電壓、故障狀態等信號；蓄電池狀態顯示區（“Battery”區域）——用于顯示蓄電池的電壓、充放電電流、單體電壓、電池箱溫度等信號。對于以上各個信號，在燃料電池汽車試驗過程中都必須進行實時監測和故障診斷。

    其中，對于蓄電池來說，由于采用的是鋰離子或鎳氫電池，各個單體的均一性顯得尤為重要，它不僅影響蓄電池的使用性能和壽命，還關系到整車的安全問題，某個單體的過充或過放都可能導致電池箱溫度急劇上升甚至爆炸。因此需要特別關注蓄電池的單體電壓和單體溫度，除了在主界面顯示出來以外（右下方的白色線狀圖）外，還設置了兩個按鈕，用于調出詳細顯示單體信息的子VI，如圖6所示。柱狀圖中的紅色單體表明該單體的電壓或溫度超出了安全極限，予以警示。

    數據回放與故障再現系統的程序結構與前面板與實時監測系統基本一樣，只是將數據采集模塊換成了數據讀取模塊——從硬盤中讀取記錄好的試驗數據和故障信息，在此不做詳細介紹。該系統用于試驗結束后再現試驗過程，可連續回放，也能單步執行，因此可以在發生故障的時間點上詳細顯示當時各個零部件的運行狀態，這對分析故障原因具有非常重要的作用。

完成試驗后，需要對試驗數據進行分析和處理，并撰寫試驗報告。這里我們再一次采用了NI的數據分析軟件——DIAdem，不僅因為它數據處理功能強大、數據量幾乎沒有限制（最長可到10億個數據點），更因為它與LabVIEW的無縫連接——可在LabVIEW中直接調用DIAdem，也可在DIAdem中調用LabVIEW，大大簡化了數據的導入、導出、分類等過程.

    LabVIEW的Web Sever技術

    NI的LabVIEW還集成了Web Sever技術，將復雜的TCP/IP、UDP、Socket等技術封裝在若干子VI中。只需調用這些子VI，即可完成網絡通訊，免去了底層網絡協議的復雜工作。即使開發者沒有網絡協議方面的專業知識，也可以利用LabVIEW進行網絡應用程序的開發。

    這里，我們在燃料電池城市客車上構建無線局域網，用一臺筆記本電腦作為服務器，運行信號監測與故障診斷系統，實時監測整車信號，然后利用LabVIEW的Web Sever技術，將信號監測與故障診斷系統的前面板發布到Internet上。這樣，所有接入Internet、并獲得Web Sever訪問權限的計算機均可通過服務器的IP地址瀏覽該程序的前面板，如圖7所示。如果服務器授予客戶機控制權，客戶機還可以控制前面板上的所有控件，實現真正的遠程監控。

   結論

   利用NI公司的硬件產品和軟件平臺，我們在很短的時間內完成了燃料電池城市客車信號監測與故障診斷系統的搭建。在實車試驗中，汽車運行1小時大約會在CAN總線上傳輸40M左右的數據，在電磁干擾和機械振動比較惡劣的環境下，系統不僅可以完全記錄下這些數據，還可以快速響應用戶的各種操作，其實時性、可靠性均得到了驗證。在LabVIEW Web Sever技術的支持下我們還實現了系統的遠程監控。此外，利用DIAdem還可完成數據處理與分析，快速生成試驗報表。