中心議題：

• 汽車內部傳感器網絡係統
• 汽車電子控製和調節裝備的變化

解決方案：

• 在傳感器模塊與ECU之間采用數字通信傳輸
• 製定和執行標準化數字接口
• 軟件錯誤檢測時采用臨時診斷DM

如今汽車內的電子元件價值已占到總車的15～20%。未來，隨著車輛中植入更多的安全電子設備、燃油消耗和燃料排放控製係統
、通信和導航係統、信息娛樂係統以及其他提升舒適度的電子係統，該比例可能會高達30～40%。
　　
目前實現上述功能需要20～50個電子控製單元(ECU)
，所用到的傳感器差不多有70～150個。這些傳感器負責測量的環境數據範圍很廣，有壓力


、溫度、流量、速度


、加速度以及角度等。它們將測量值送到ECU進行引擎和環境控製、安全氣囊觸發，從而提升舒適度和安全性。像ABS
、電子穩定程序/控製(ESP/ESC)，以及刹車輔助係統等，都要依賴傳感器輸入。
　　
在這些應用中
，各種電子係統的自診斷能力正變得日益重要。例如，如果有可能直接在傳感元件中檢測到傳感器的缺陷

，ECU就能夠獲得可靠數據從而做出正確決策。對於那些與安全息息相關的係統來說
，係統禁用和應急啟動都相當重要。
                         
                                        圖1：如今汽車內的電子元器件價值已占到總車的15-20%。
                 
                          圖2:在現代車輛中
，常常需要10到20條不同的數據總線將不同的裝配連接到一起。

作為網絡應用的汽車電子
　　
一份有關汽車電子控製係統的分析報告顯示，這些裝配的複雜度呈現指數上升。簡單的電子控製和調節裝備已經被更為複雜的IT係統取代。在這其中，除了實際硬件外，軟件以及ECU間的雙向通信已成為一個新的關注點。
　
例如，可能會通過診斷用CAN總線來訪問每個單獨的ECU、詢問其狀態、讀取錯誤代碼
，甚至刷新程序固件。如今
，出於成本考慮，許多應用中常常會共享傳感器。這意味著一個傳感器模塊的測量值將被幾個ECU處理。
　　
車輛中的大量應用已然轉變成了網絡應用。以往的常見架構(即一個ECU實現一個應用)已經被多個ECU共享的網絡功能所取代。
                    
                                                                        圖3：後備箱蓋功能樹。
　　
圖3是一個後備箱蓋的工作功能樹。在這裏，打開後備箱實際上需要激活兩個ECU裝置。其餘的ECU用來執行顯示和控製等功能。
　　
任何錯誤都會導致係統故障。打開後備箱蓋這個動作可能出現的錯誤模式有6個。應該是某個錯誤使得傳感器故障
，這可能會在ECU的故障存儲器中產生十幾個不同的輸入。從這些錯誤代碼的分布來看，有必要獲取比以往更為詳細的傳感器診斷信息。[page]
　　
汽車傳感器目前所用的通信協議仍然是模擬輸出。這是典型的點對點連接——即一個傳感器與一個ECU連接
，並以電壓作為其輸出信號。盡管已經進行了一些改善，例如提高分辨率，或增加診斷範圍(LDR,UDR，見圖4)，但模擬輸出仍然是90年代至今該技術的核心。
                     

模擬輸出隻允許進行信號範圍內(如10-90%)的傳感器信號傳輸，並通過開關將低診斷範圍(LDR)和高診斷範圍(UDR)轉換為故障狀態。因此
，其無法傳送更詳細的故障信息。
　　
解決這一問題的方法是在傳感器模塊與ECU之間采用數字通信
，來傳輸除傳感器數據之外的狀態信息
、時(shi)間(jian)戳(chuo)以(yi)及(ji)誤(wu)差(cha)代(dai)碼(ma)等(deng)。不(bu)過(guo)遺(yi)憾(han)的(de)是(shi)，向(xiang)數(shu)字(zi)通(tong)信(xin)轉(zhuan)變(bian)所(suo)引(yin)發(fa)的(de)問(wen)題(ti)異(yi)常(chang)複(fu)雜(za)，因(yin)為(wei)傳(chuan)感(gan)器(qi)的(de)種(zhong)類(lei)相(xiang)差(cha)太(tai)大(da)，而(er)且(qie)不(bu)同(tong)的(de)傳(chuan)感(gan)器(qi)供(gong)應(ying)商(shang)所(suo)采(cai)用(yong)的(de)架(jia)構(gou)也(ye)有(you)所(suo)不(bu)同(tong)(見圖5)。
                 
                     圖5：傳感器的種類相差太大，而且不同的傳感器供應商所采用的架構也有所不同。
從模擬角度來看，市場上提供各種針對所有環境變量的傳感器，而且幾乎所有ECU微控製器都有模擬輸入口。因此
，利用市場上現有的元器件，或僅需進行微調的產品開發新應用不會出現大問題或者大風險。

但這樣的情況卻不適合數字通信協議。可用的標準協議必須以特定方式使用。目前可用的數字協議包括：
　　*CAN：總體來說太過複雜，傳感器成本過於昂貴

　　*LIN：僅支持最高為19,200baud的低傳輸率

　　*外部傳感器接口(PAS4，PSI5)：專為安全應用(如氣囊)開發
，要求9V工作電壓，電流消耗大

　　*SENT：隻能支持單向，目前還處於標準化階段中

於是
，在需要數字通信的應用中通常會采用專有方案。這意味著每個電路製造商都有自己的專有協議。支持ZMD31150、ZMD的ZACWire(串行數字接口)提供一個開放標準，能夠提供通信安全，在波特率和行末校準方麵具有靈活性。
　　
未(wei)來(lai)幾(ji)年(nian)的(de)挑(tiao)戰(zhan)，是(shi)製(zhi)定(ding)和(he)執(zhi)行(xing)考(kao)慮(lv)到(dao)傳(chuan)感(gan)器(qi)係(xi)統(tong)和(he)應(ying)用(yong)要(yao)求(qiu)並(bing)具(ju)成(cheng)本(ben)效(xiao)益(yi)的(de)標(biao)準(zhun)化(hua)數(shu)字(zi)接(jie)口(kou)。該(gai)接(jie)口(kou)必(bi)須(xu)滿(man)足(zu)下(xia)麵(mian)三(san)個(ge)多(duo)少(shao)有(you)些(xie)矛(mao)盾(dun)的(de)設(she)計(ji)條(tiao)件(jian)：

*電路測試：為了測試成本最小化
，要求通信速度最大化

*校準：盡可能簡單、靈活

*應用：盡可能快速、安全和兼容
，特別是在超出規範工作電壓、EMC高以及最大RF輻射受限的條件下。
　　
汽qi車che傳chuan感gan器qi在zai安an全quan方fang麵mian的de應ying用yong正zheng日ri益yi增zeng加jia。對dui於yu可ke以yi在zai危wei險xian的de刹sha車che條tiao件jian下xia減jian小xiao刹sha車che距ju離li的de刹sha車che輔fu助zhu係xi統tong來lai說shuo

，需xu要yao一yi個ge傳chuan感gan器qi來lai測ce量liang刹sha車che係xi統tong的de壓ya力li，使shi得deECU能夠檢測出由駕駛員所發出的刹車動作。傳感器是激活ABS的關鍵，故傳感器必須100%準確。要保證這一點，自檢功能必須盡可能的全麵。
　　
如果傳感器信號調節器(SSC)IC發現模組中的傳感器故障(例如傳感器短路)，或者由於外部故障引起了SSC的無效操作，ECU必須能夠確定這些問題。例如，可以利用ZMD31150來說明如何處理上述問題。ZMD31150是一款在汽車應用中進行信號調節的SSC。
　　                         ZMD31150中執行的診斷功能(見圖6)將對傳感器機能以及SSC進行連續監控。
               
                                                               圖6：ZMD31150中執行的診斷功能
　　
一旦檢測到故障，診斷模式(DM)被激活。數字通信消息中將建立一個錯誤標誌，或者將模擬輸出切換到預先編程的診斷範圍LDR或HDR上。
　　
可檢測故障分為兩類，即硬件和軟件錯誤。硬件錯誤是在SSC中檢測到的由硬件問題所引發的故障。本例中，信號調節被終止而DM被激活。
　　
相反
，軟件錯誤的原因就不會總是這麼清楚或連續出現。它們可能由外部原因引起
，如EMC幹擾或者係統板上其他電氣負載進行開關操作。針對軟件錯誤
，這裏使用了一個錯誤計數器
，當錯誤發生時進行“+”運算，而當錯誤不再發生時進行“—”運算。當檢測不到軟件錯誤時，軟件錯誤消息被低通過濾，傳感器返回到正常操作模式。這樣的做法被稱作臨時診斷DM。
　　
ZMD31150中的臨時DM是一個可選項，在錯誤持續出現時提供可靠的錯誤信息。利用附加信息(如冗餘傳感器或進行大量檢查)，ECU將決定當前應用能否繼續可靠工作

，或者根據錯誤消息必須關斷。
　　
如果隨著感性負載(SchaffnerPulse3a或3b)接通，某個故障耦合到了傳感器係統的電源電壓上
，該故障同樣能夠耦合到傳感器上，從而觸發自診斷功能。但是有了臨時DM，這種情況不得不連續出現幾次後才向ECU報告錯誤。由於錯誤計數器過濾了結果
，明顯的錯誤信息和相應的誤導將被避免。
　　
例如，許多駕駛員都體驗過儀表盤上突然顯現一個錯誤信號，或者是“檢查發動機”的(de)指(zhi)示(shi)燈(deng)點(dian)亮(liang)，並(bing)伴(ban)隨(sui)一(yi)條(tiao)請(qing)與(yu)維(wei)修(xiu)廠(chang)聯(lian)係(xi)的(de)信(xin)息(xi)。有(you)時(shi)候(hou)該(gai)消(xiao)息(xi)在(zai)第(di)二(er)天(tian)就(jiu)不(bu)再(zai)出(chu)現(xian)，而(er)檢(jian)修(xiu)人(ren)員(yuan)將(jiang)一(yi)個(ge)模(mo)組(zu)或(huo)傳(chuan)感(gan)器(qi)更(geng)換(huan)下(xia)來(lai)後(hou)發(fa)現(xian)沒(mei)有(you)任(ren)何(he)問(wen)題(ti)。適(shi)當(dang)的(de)軟(ruan)件(jian)過(guo)濾(lv)即(ji)可(ke)消(xiao)除(chu)這(zhe)類(lei)惱(nao)人(ren)的(de)事(shi)情(qing)。
　　
利用傳感器信號調理IC可以大大簡化汽車安全傳感器係統的開發。確保傳感器輸出100%正確的自診斷功能，隻能在信號調整階段實現，鑒於此
，該功能必須是片上實現。
　　
像ZMD傳感器調理IC這類的器件集成了全麵的自診斷功能。通過配置EEPROM，keyiduimougecuowujinxingjingquedingyi，bingqieduixitongruhefanyingjinxingdingyi。duijiancedaodecuowushijianjinxingxiangyingdegeleizhixingchengxu，youzhuyubimianmingxiandexujiacuowuxinxi，congerkeyizengjiazizhenduandekekaoxing。