您好,歡迎來電子發(fā)燒友網! ,新用戶?[免費注冊]

您的位置:電子發(fā)燒友網>電子百科>汽車電子>車身電子控制系統(tǒng)>

汽車總線設計和測試經典問答總匯(上)

2010年03月19日 10:19 wenjunhu.com 作者:佚名 用戶評論(0

汽車總線設計和測試經典問答總匯(上)

1、作為高校教師,今后也想把汽車總路線作為研究方向,能給一些建議嗎?在這樣的環(huán)境下,構造總線測試平臺把哪一方面作為重點研究好一些呢?

答:車用總線的測試的范圍很寬,大概分為兩個方面的,一個方面是功能測試,一個方面的性能測試.功能主要是測試基本的通信功能,如總線上的節(jié)點能否正常發(fā)送和接收信息.性能主要是指在各種狀態(tài)(不同的電磁環(huán)境,氣候環(huán)境)的通信的各種性能,如實時性,故障處理能力等.更高層次的功能就是性能,功能和性能之間的劃分是沒有確定的界線,隨著技術的不斷進歩,一方面性能方面的要求,不斷轉換為功能性的要求,同時新的性能又在不斷的產生。

從總線測試方面來說,它功能和性能的要求和屬于汽車電子的非電源信號傳輸方式的測試一類,大家可以參考ISO7637-3 ISO11452,GMLAN,I2602,I1939等資料。

由于學校主要是教學(我個人認為),最簡單的方法是購買用于PC機上的CAN/LIN卡(如:Li Gaowei他們的產品),然后自制一些節(jié)點(對于CAN來說,可以用89C51+SIA1000構成)就行了。

由于測式和設計不僅僅是總線問題,它涉及嵌入式系統(tǒng)的軟硬件設計和測試,內容多一言難盡,很多方面還處于探索階段。

2、怎樣解讀國內的汽車can總線研究現(xiàn)狀?是研發(fā)、成本或國內的測試方式、手段制約了CAN產品的出現(xiàn),還是其它的因素?

答:CAN,LIN的應用首先要有MCU,而國內生產的汽車零部件中含MCU的少之有少,這好比從奴隸社會社會一下過渡到社會主義社會一樣,雖然很難,但會成功。

3、目前中國總線的趨勢是什么?而且要設計好總線要注意哪些問題?最后市場上的一些汽車生產商做總線有哪些需求(中國)?

答:目前,國內在總線方面處于開始研發(fā)初始階段。

在某些研究所、或者高校,已經做了一些工作,但是實際涉及到復雜的關鍵性的網絡協(xié)議設計(例如汽車動力總線的設計),還不成熟,用于實際產品的非常少。對于所設計的網絡缺乏測試策略、測試方法及測試評價。

其實國內網絡開發(fā)方面,與國外的差距在于協(xié)議的制定與測試,而引起差距的最重要原因是實踐經驗。國外的CAN網絡設計已經進行了二十年,各公司成熟的網絡協(xié)議都積累得到的,而國內廠商只是處于開始階段,談不上積累。

國內廠商要形成自己的自主網絡協(xié)議,需要加強對車輛等應用背景的理解;參考國外的網絡協(xié)議;實踐和總結。特別是實踐,做出來的東西一定要用,要改進,才能摸索總結出自己完善的規(guī)范、協(xié)議。

另外,還需要有超前的意識,不能只是跟蹤。去年歐洲已經確定將FlexRay作為替代CAN的總線協(xié)議。國內的研究機構也應該從現(xiàn)在開始進行,減小我們與國外技術時間差距。

4、到哪里可以獲得與汽車故障診斷相關的協(xié)議?

答:不知道你說的故障診斷是什么意思,在汽車電子領域里說的Diagnostics不止是為了故障診斷。關于協(xié)議,如果你的診斷是基于K-Line的,就要遵循ISO-14230,也就是“著名的”KWP2000。如果是基于CAN,物理層遵循ISO-11898,數(shù)據(jù)鏈路層、網絡層和應用層遵循ISO-15765。另外還有一份ISO-14229,算是對所有診斷功能的一個整體描述。

5、請教計算機如何通過汽車故障診斷接口獲取汽車實時信號和故障代碼?

答:汽車故障診斷目前主要是通過K線來實現(xiàn),基于K線的診斷協(xié)議為KWP2000(Key Word Protocol 2000)。KWP2000協(xié)議只是一個診斷協(xié)議的框架,其中包含了很多必須由具體的制造商自定義的內容(如故障碼格式等),這些內容各廠家都不相同。汽車廠家在實現(xiàn)它們自己產品的故障診斷功能時必須增加自定義部分才能形成完整的診斷協(xié)議。因此要獲得故障信息,必須知道該廠家的具體協(xié)議內容(有些診斷工具開發(fā)商通過使用工具監(jiān)測通訊信息來分析協(xié)議內容)。KWP2000協(xié)議對于不同的信息設有不同的安全級別。普通的故障信息沒有安全保護,只要知道協(xié)議,即可通過診斷工具讀出。其它方面的信息由ECU生產廠家分為不同的級別限制訪問,需通過安全認證過程才能獲得這些信息。安全認證過程通常通過“種子”,“密匙”進行驗證。

6、如果開發(fā)一套類似與奧迪VAS-5051B功能的軟件,計算機和汽車故障診斷接口之間通訊的原理是什么(就以大眾車系為例),需要怎么樣連接?我在網上看到有人叫賣VAG-COM連接線,能用嗎?

答:從PC到診斷接口的連接需要電平轉換,也就是從K-Line到RS-232電平的轉換,至少需要一塊IC。我不知道你說的連接線是什么結構,有沒有用我不好說。

通訊原理遵循KWP2000。但如果你看了KWP2000,你會發(fā)現(xiàn)其實它只是一個大綱,具體功能需要使用者自己定義,對奧迪來說就是大眾。我相信具體的通訊協(xié)議你是拿不到的。

你所下載的VAS-5051B應該只有很低的安全級別,只能實現(xiàn)很少的功能。高安全級別的通訊有軟加密和硬加密。

順便說一句,汽車的診斷有很多牽扯到整車安全,這也就是為什么大眾要保密。你小心不要費了半天勁做了個非法的東西。

7、CAN總線與MIC總線性能對比!

答1:MIC總線是專門為解決惡劣的軍事環(huán)境(包括核輻射)中電力及數(shù)據(jù)分配和管理問題而開發(fā)的一種簡單的高可靠性時間分割多路傳輸串行現(xiàn)場數(shù)據(jù)總線。CAN總線開始也是為軍事服務,在成本得到認可后,才開始應用于工業(yè)控制和汽車電子。兩者同樣適用于惡劣環(huán)境,但手段不一樣(底層硬件應用協(xié)議),達到的目的也不一樣。MIC時間分割多路傳輸,雙冗余串行通信的方式傳輸數(shù)據(jù),比較適合尖峰脈沖干擾頻繁的場合。CAN可以簡單的理解為差分信號,對浪泳等共模干擾抑制能力很強。當然,如果你不介意數(shù)據(jù)冗余,485,LIN也是不錯的選擇。這個前提是距離不要太遠。

答2: 應用目標是汽車電子設計,這是基礎。在距離來看,車上的線束還沒有超過40米的。在電磁兼容角度來看,要符合ISO7637的要求。好了,標準已經清楚,現(xiàn)在我們開始討論。

1 兩種總線體系結構比較:這里已經說的很明白很具體了,我只補充一點。

a、節(jié)點一般可達110個:其實根據(jù)不同的應用芯片,差別很大的,通過網關的擴展那就沒譜了。在汽車電子應用來看你能用到幾個節(jié)點呢?非常有限的。

b、多主式結構制約了通信的實時性,也會導致數(shù)據(jù)的擁堵:反對!所有的串行通訊都是隊列呀,CAN是硬件底層協(xié)議保證隊列,應用層協(xié)議保證實時性,堵不起來的。

2 性能比較

實時性:CAN總線實時性不如MIC總線。這是隊列和應用層協(xié)議的問題,您的觀點的基礎是MIC有序而CAN無序的前提。結論自然錯誤??煽啃裕簾o論是MIC還是CAN,出故障的模塊都會死掉。而對網絡管理來講,CAN不需要任何處理,MIC在主控死掉的情況,要麻煩一些。如果考慮到接替問題,那就不叫優(yōu)越性了。傳輸特性:其實如果在40米的極限距離來講,討論的有啥意義呢?

3 應用場合比較

如果講坦克、軍用車輛,無語了。為了保障軍車在核爆后的存活率,都是很原始的東西。例如儀表,連數(shù)碼管都不給用。

8、基于CAN總線來對車上的電子設備/ECU等等進行在線測試,是一個大方向,可否詳細介紹一下這方面的測試技術和標準的設計思想?

答:測試標準分為軟件測試和物理層測試:

物理層測試也分為兩個部份,一個部份是細化了J1939對物理層的測試方法,第二個部份是有一定的創(chuàng)造性的它包括信號完整性測試,物理層的時延測試和EMC測試。

軟件測試,軟件測試包括通信的實時性測試和軟件對通信錯誤處理能力的測試。

關于CAN的測試,我前前后花了一年多的時間,現(xiàn)在還沒有完全,而且內容多,不可能一下子公布,有些還涉及到其它方面的問題。

CAN開發(fā)應該分為兩個階段,一個階段是功能開發(fā),另一個階段是性能開發(fā)。

1 CAN的功能開發(fā),就是指能否利用CAN傳輸消息,即CAN調通沒有調通。這個我就不說了,可以說現(xiàn)在大家干的基本上都在這一層次上。

2 CAN的性能開發(fā)。CAN的性能開發(fā)又分為兩個階段,其一是物理層設計,其二是CAN信息的實時性。
2.1 CAN物理層設計,CAN的物理層設計主要涉及兩個方面CAN的傳輸時延和EMC。大家知道CAN的傳輸距離和抗干擾能力主要由信號的傳輸時延決定的,當CAN發(fā)送消息后,在規(guī)定的時間內接收不到ACK就認為傳輸失敗,這和RS485通信是有本質的區(qū)別的。在物理層的實際設計過程中,為了增強CAN的抗干擾能力必定要加光耦,電容,TVS和電感類擬的東西,這些東西的加入無形中要增大信號的時延,本來為了增強CAN的抗干擾能,由于傳輸時延的增加,反而降低了CAN的抗干擾能力,這是我在近十幾年在國內一些同行設計的CAN系統(tǒng)中發(fā)現(xiàn)的問題。目前我設計的CAN系統(tǒng)在500K的通信速率下在J1939的電纜中傳輸100M都不會發(fā)生錯誤;而前幾天國內一家比較有實力的單位設計CAN系統(tǒng)在125K的通信速率下僅能傳輸幾十米。同時我也測試過BOSCH的產品,其性能是非常高的。所以我在863電動汽車重大專項的總線會議上經常強調要設計一個具有競爭力的CAN系統(tǒng),并不是簡單地使用82C250,與82C250相關的每一個電阻,電容,電感和PCB上的每一根線都要認真考慮。對CAN的物理層設計的評估有一套方法,在這套方法的測試下就能分清優(yōu)劣。

我為什么要研究CAN的測試方法,這是因為在前年我參觀專項中一次CAN聯(lián)調,發(fā)現(xiàn)總有一些CAN節(jié)點不能正常通信,而所有的零部件單位都說他們的沒有問題,這時誰也不知道這是誰的問題。為了解決這些問題于是我開始CAN測試方面的工作,沒有想到這一干就是兩年。

2.2 CAN的實時性測試是指CAN的消息是否能準時發(fā)送。由于CAN自身存在優(yōu)先級反轉和軟件開人員水平的限制,特別容易出現(xiàn)消息的周期抖動(jitter),我在測試中發(fā)現(xiàn)一家零部件研發(fā)單位采用POWER PC作為ECU的CPU,其CPU的負載很低,但他發(fā)送一條周期為10ms的消息,有時需要100多ms才發(fā)送出來,有時還不到5ms就發(fā)出來了。如果在CAN系統(tǒng)中出現(xiàn)這樣一條消息,我想CAN的通信功能都實現(xiàn)了,但其控制質量肯定得不到保證。

對于CAN的測試技術是否成熟,我一直認為國外從事發(fā)動機,制動和變速控制的研發(fā)公司都有嚴格而完善的測試方法和標準,但我們得不到(也可能包括在華的合資和獨資企業(yè),因為如果在華的合資和獨資企業(yè)有,我們也可能通過各種方式了解到)。這就需要我們去探索。

實際上CAN的測試設備有的很貴,需要買,但很多可以用現(xiàn)有的通用設備和自制。

9、就目前國內車載網絡總線發(fā)展的狀況而言,CAN應該是主流,接觸CAN的機會比較多,請問CAN網絡的測試規(guī)范和標準該如何制定?

答:各個大汽車公司針對自己的車載CAN網絡制定了各自的測試規(guī)范和標準,歸納起來可以分為:
1、正常的通訊測試
2、電氣穩(wěn)定性測試
3、故障情況下的CAN通訊測試

測試需要覆蓋物理層、數(shù)據(jù)鏈路層、交互層、網絡管理層等內容。

10、CAN系統(tǒng)設計的關鍵點分析

答:我們是一群通信電子行業(yè)的工程師.經過一段時間的觀察和分析,我們發(fā)現(xiàn)CAN網絡的設計和構建并不是十分困難的。關鍵點如下:

1 首先要清楚地認識到,CAN網絡是一個由多個網絡節(jié)點(由各ecu控制)組成的無中心分布式網絡。這種特性決定了整個網絡的行為模式與整車設計關系不大,更多地是由網絡上各部件(如,發(fā)動機,ABS等)的通信接口(API)相關。所以整車廠商一旦選定了部件供應商,網絡的需求和特性就基本確定了。我在論壇里看見整車廠代表和部件廠代表爭吵不休,還經常感嘆各大整車廠商壟斷應用層協(xié)議,頗感不解。粗粗閱讀OSEK/VDX的相關文件,發(fā)覺其中已涵蓋各種應用協(xié)議。只要知道了各部件的特性,就沒有什么秘密可言。

2 CAN網絡對環(huán)境的要求比較高,高低溫,震動和電磁兼容等特性必須過關。如果有比較豐富的電子系統(tǒng)產品設計經驗,這些也是不難搞定的。

3 CAN網絡的基本硬件平臺和底層協(xié)議已有成熟的解決方案,不必花費太大的時間和精力。

4 CAN網絡的網絡管理可能涉及比較大的工作量。因為網絡的容錯糾錯能力,設備的管理能力,網絡冗余度的處理等需要花不少功夫。

綜上所述,CAN網絡的設計和實現(xiàn)并不存在不可逾越的技術障礙。只要投入時間和金錢,還是很有希望在近一兩年內實現(xiàn)。

11、能否描述一下CAN控制器的節(jié)點狀態(tài)處理過程,如節(jié)點的狀態(tài),各狀態(tài)之間是如何轉換的?

答:目前僅有看到OSEK/VDX的NM有規(guī)范敘述到節(jié)點狀態(tài)機制,實際上,規(guī)范內也制定了一些API,而發(fā)展OSEK/VDX實現(xiàn)工具也有支持這些狀態(tài)機制。

網絡狀態(tài)不過也就區(qū)分Direct NM和 Indirect NM,說穿了不過節(jié)點Sleep、Awake,和Suspended之間狀態(tài)機制的互換,那什么時候和條件下,要轉換到相對應的機制上,也很簡單,直接看看OSEK NM可以很快的明白,對了別去看OSEK OS和COM,整套OSEK標準讓我看到很想去死。

實現(xiàn)方面,可以藉由Simulink發(fā)展狀態(tài)機器模型,產生ANSI C Code,移植到所發(fā)展的MCU上。

Actually,未來AutoSAR也會對網絡狀態(tài)進行規(guī)范,并且ThirdParty發(fā)展廠商也會提供相對應的API。如果,你僅是要自行設計小型網絡,套用節(jié)點狀態(tài)機制管理,或許可以參考OSEK的NM去啟發(fā)你設計的Source Code。

目前,OSEK/VDX 實現(xiàn)工具廠商僅有幾家,F(xiàn)reescale OSEKturbo、3Soft,不過都要價不匪。并且,因應AutoSAR的問世,這些工具的Maintance這些廠商也都未再繼續(xù)維護。但是,讀讀OSEK會讓你發(fā)現(xiàn)另外一片新的視野。

12、我們是搞車載娛樂系統(tǒng)的,雖然目前國產車的娛樂系統(tǒng)還很落后、還沒有與總線接口,但隨著CAN等總線應用的不斷普及,娛樂系統(tǒng)與其接口只是時間問題。借助這個平臺想多了解一些CAN總線的知識,例如:CAN總線的主要功能及特點,娛樂系統(tǒng)與其接口的技術規(guī)范,測試方法等。

答: 對于總線的應用,娛樂系統(tǒng)我認為應該分為兩個部分,其一是娛樂控制部分,其二是娛樂數(shù)據(jù)的傳輸。

對于娛樂控制部分,CAN,LIN和VAN在實際中都有應用,方向盤上的開關(娛樂),基本上都是采用總線,從成本控制上來說,LIN都能滿足要求,但具體情況要由主機廠定。

在娛樂數(shù)據(jù)的傳輸部分,按理說應該用MOST與IDB1394之類,雖然早期有個CAN傳輸娛樂數(shù)據(jù)的國際標準,但后來沒有影了。但在實際應用中,就有用CAN傳輸聲音數(shù)據(jù)的。

我個人認為,國內開發(fā)娛樂系統(tǒng)的廠家應該在其新開發(fā)的裝置上有CAN\LIN接口,同時還應考慮CPU的資源。

至于測試,內容大多,一下談不清,有機會我們再交互。至于標準,好像現(xiàn)在還沒有通用的。

節(jié)點式娛樂系統(tǒng)一般是雙uP結構,有個單獨的控制uP。

如果不是很復雜的話,音視頻數(shù)據(jù)一般用傳統(tǒng)電纜實現(xiàn)。

非常好我支持^.^

(3) 100%

不好我反對

(0) 0%

( 發(fā)表人:admin )

      發(fā)表評論

      用戶評論
      評價:好評中評差評

      發(fā)表評論,獲取積分! 請遵守相關規(guī)定!

      ?