評職稱或畢業的時候，都會遇到論文的煩惱，為此精選了《OSEK網絡管理論文(精選3篇)》，供需要的小伙伴們查閱，希望能夠幫助到大家。汽車操作系統是用于控制和管理汽車硬件與軟件資源的程序，是保障汽車正常運行和功能、性能的基礎和關鍵，同時也將成為繼智能手機操作系統之后又一競爭高地。在此形勢下，深入剖析全球及我國汽車操作系統發展現狀，以及我國汽車操作系統發展存在問題，研判我國自主汽車操作系統發展的路徑對推動我國自主汽車操作系統發展具有重要意義。
OSEK網絡管理論文 篇1：
汽車CAN節點的低功耗設計及實現
摘要：滿足OSEK NM規范的CAN節點進入休眠后，一方面可以被本地喚醒信號喚醒，另一方面可以被總線上的有效顯性位喚醒，當本地喚醒信號的濾波電路濾除不掉雜波時，本地喚醒信號線上的雜波會喚醒本地CAN節點。當CAN物理層收發器電路濾除不掉總線上的毛刺時，總線毛刺也會喚醒CAN節點。為了防止CAN節點被錯誤喚醒，通過設計臨時喚醒模式和喚醒確認模式，判斷是否存在有效的本地喚醒條件或CAN報文，避免了CAN節點被誤喚醒進而喚醒，整個網絡，從而大大增加整車電流消耗的問題。
關鍵詞.OSEk：C.AN節點；喚醒信號
0 引言
隨著汽車功能和電子電氣系統越來越復雜，常電供電節點也越來越多?，F代汽車CAN網絡大多遵循OSEK直接網絡管理協議實現常電供電CAN節點的休眠和喚醒功能[1]。根據OSEK直接網絡管理協議，所有常電供電CAN節點都滿足休眠條件后，整個CAN網絡協同進入睡眠狀態，當某個CAN節點被本地喚醒條件喚醒后，它將向CAN網絡上發送ALIVE報文喚醒整個CAN網絡[2]，其它CAN節點檢測到CAN網絡上出現有效的顯性位時，CAN物理層收發器向CAN控制器的接收腳輸出一個下拉脈沖，喚醒MCU和CAN節點，然后，被喚醒的CAN節點向總線上發送ALIVE報文，這些節點通過ALIVE報文完成網絡建環。一般情況下，整車靜態電流一般為喚醒狀態下的幾十分之一，甚至幾百分之一。
在一個實現了OSEK直接網絡管理規范的CAN網絡中，當CAN網絡進入休眠狀態后，CAN節點一方面可以被本地喚醒[3]（一般為開關信號），一方面可以被總線喚醒?？偩€物理層收發器及其外圍電路具備濾波功能，當總線上出現比較短的毛刺時，總線物理層收發器會過濾掉該毛刺，但是，由于CAN物理層規范對CAN信號的上升沿和下降沿有一定要求，它能過濾掉的雜波一般都只是微秒級，當總線上出現時間長度比較寬的毛刺時，物理層收發器便會在MCU的CAN控制器的接收引腳上產生一個低有效電平，這樣，該CAN節點便會被喚醒，根據直接網絡管理規范，除了自身被喚醒之外，它還會通過ALIVE報文喚醒其它CAN節點，使得整個CAN網絡退出休眠狀態，使得整車的電流消耗比休眠狀態下的整車靜態電流大幾十倍，甚至上百信，不僅大大增加了整車的電流消耗，還可能會造成蓄電池虧電無法啟動發動機的情形[4]。本地喚醒條件也有類似的誤喚醒問題。
為了保證CAN節點不會被本地喚醒信號或者CAN信號誤喚醒，本文設計了一種方法，只有在確實滿足本地喚醒條件的情況下，或者總線上確實存在有效報文的條件下，節點才會被喚醒[5]。
1 方案設計
為CAN節點設計四種工作模式：喚醒模式、休眠模式、臨時喚醒模式[6]和喚醒確認模式。其中，喚醒模式為正常工作模式，CAN節點電流消耗最大。休眠模式、臨時喚醒模式和喚醒確認模式為低功耗模式，其中，休眠模式下的電流消耗最小。CAN節點的靜態電流是指CAN節點在低功耗模式下的電流消耗[7]，即在休眠模式、臨時喚醒模式和喚醒確認模式下的平均電流消耗。四種工作模式跳轉如圖1所示。汽車電子Automotive Electronics
CAN節點上電后自動進入喚醒模式，并在休眠條件不滿足的情況下保持喚醒模式。CAN節點滿足本地休眠條件且整個CAN網絡協同休眠后，CAN節點禁能CAN收發器和控制器[8]，設置喚醒源，然后進入休眠模式。
為了保證本地喚醒信號線上的雜波不會誤喚醒CAN節點，進入休眠模式時只設置兩個喚醒源——CAN信號和內部定時器。其中，CAN喚醒源能夠保證當CAN總線上出現一個有效的顯性位時，CAN節點會馬上喚醒，內部定時器喚醒源定時值記為Tsleep，能夠保證CAN節點被周期喚醒。
臨時喚醒模式保持時間為Ttempwake，在臨時喚醒模式中輪詢本地喚醒條件，不僅可以避免本地喚醒信號線的雜波喚醒MCU，減少了MCU的喚醒次數，降低了靜態電流，還降低了對MCU喚醒中斷引腳的需求。
Tsleep和Ttempwake。時間根據CAN節點靜態電流約束條件和本地喚醒時間定義，為了保證功能的實時性，出現本地喚醒后，CAN節點要在一定的時間內向CAN網絡上發送ALIVE報文喚醒其它節點，Tsleep越大，本地喚醒時間越長，Tsleep和Ttempwake的比值越大，CAN節點靜態電流越小。
2 喚醒算法設計
為了保證CAN節點不被總線毛刺和本地喚醒信號毛刺誤喚醒，設計了臨時喚醒模式和喚醒確認模式。在臨時喚醒模式下，CAN節點輪詢CAN控制器標志位和本地喚醒信號電平，在喚醒確認模式下，CAN節點查詢CAN報文接收和本地喚醒條件是否有效。喚醒算法流程如圖2所示。
當節點進入休眠后，CAN信號或者內部定時器臨時喚醒節點，進入臨時喚醒模式，臨時喚醒模式保持時間為Ttempwake，在臨時喚醒模式期間輪詢CAN控制器的喚醒狀態位和本地喚醒信號的電平，如果CAN控制器喚醒狀態位和本地喚醒信號電平一直無效，Ttempwake后CAN節點再次進入休眠模式。如果CAN控制器喚醒狀態位有效或者本地喚醒信號電平有效，進入喚醒確認模式。
在喚醒確認模式中，如果CAN控制器喚醒標志位有效，使能CAN物理層收發器和CAN控制器，根據該CAN網絡的波特率，設定一定的濾波時間（記為Tfiter），檢查該段時間以內是否接收到CAN報文，如果接收到，說明這是有效的CAN報文喚醒，CAN節點進入喚醒模式，如果沒有收到，說明CAN節點是被總線上的毛刺喚醒的，這時，節點返回休眠模式。在喚醒確認模式中，如果本地喚醒信號有效，以2 ms為周期，連續檢測三次本地喚醒信號電平，如果均有效，進入喚醒模式。否則，節點返回休眠模式。
Tfiliter根據總線網絡的波特率確定，根據CAN協議，CAN報文數據場的最大長度為8字節，一條數據場長度為8字節的CAN報文包含108個總線位，根據波特率可以計算出報文數據場長度為8字節的CAN報文的時長，Tfiiiter設置為最大CAN報文時長的2倍左右。汽車CAN網絡的波特率有500 kbps、250 kbps、125 kbps三種，具體而言：
波特率為500 kbps時，CAN報文最大時長為0.216ms，Tfiliter設置為0.5 ms；
波特率為250 kbps時，CAN報文最大時長為0.432ms，Tfiliter設置為1 ms；
波特率為125 kbps時，CAN報文最大時長為0.864ms，Tfiliter設置為2 ms。
3 結論
本文設計了一種汽車CAN節點的低功耗方案，通過設置喚醒確認模式，區分有效的CAN報文和總線毛刺，區分有效的本地喚醒條件和信號毛刺，避免了誤喚醒。根據CAN網絡的波特率確定CAN報文濾波時間，避免了無效等待。本方法應用在為某車型設計的PEPS中，具有較強的實用性。
參考文獻：
[1]蔡營，王永峰，岳意娥，等基于OSEK標準的整車CAN網絡管理設計及測試驗證[J]汽車電器，2016，（8）：38-41，49
[2]苗斌，王衛華，趙永勝，等具有OSEK功能汽車儀表的睡眠及喚醒管理研究[J]汽車電器，2014.（2）：15-18
[3]劉文英，鄒洪波，王東，等一種基于CAN總線的低功耗汽車組合開關[J]機電工程，2013，（11）：1406-1409，1429
[4]付國良整車靜態電流設計及驗證[J]汽車電器2015，（11）：17-19
[5]山東省科學院自動化研究所一種汽車CAN節點的低功耗設計方法中國，201710458567.7 [P].2017-6-16
[6]馬建輝，劉源楊，候冬冬，等汽車BCM的低功耗設計及實現[J]電子產品世界，2016，（11）：55-56，30
[7]山東省科學院自動化研究所一種低功耗車身控制器及其控制方法：中國，201510125944.6[P]2015-03-20
[8]初洪超網絡管理在汽車CAN系統的應用[J]汽車實用技術，2016.（5）：114-118
作者：馬建輝 張云 胡代榮 孫常青
OSEK網絡管理論文 篇2：
從國內外雙視角看我國自主汽車操作系統發展
汽車操作系統是用于控制和管理汽車硬件與軟件資源的程序，是保障汽車正常運行和功能、性能的基礎和關鍵，同時也將成為繼智能手機操作系統之后又一競爭高地。在此形勢下，深入剖析全球及我國汽車操作系統發展現狀，以及我國汽車操作系統發展存在問題，研判我國自主汽車操作系統發展的路徑對推動我國自主汽車操作系統發展具有重要意義。
車控操作系統是管理車輛動力、底盤、車身等基礎硬件系統和軟件資源的程序。以歐美為主導，已開展了兩輪標準化工作：OSEK/VDX和AUTOSAR。OSEK/VDX主要對操作系統和網絡管理進行標準化；AUTOSAR從軟件架構、開發方法、開發工具三方面進行標準化。目前，德國Vector、ETAS、dSpace，美國Mentor Graphics和芬蘭EB等企業都擁有符合上述標準的操作系統產品及成熟解決方案，并在汽車中得到了大量應用。
智能車控操作系統指利用人工智能等相關技術，實現對車輛的智能控制，以實現自動駕駛的目標。目前主要的智能車控操作系統大致分為兩類，一類是由機器人開源項目的操作系統進行移植后針對性的研發，如百度的CarOS系統就是由開源ROS系統優化研發而來，另一類是基于開源Linux的，如特斯拉的Autopilot的操作系統。布局智能車控操作系統的公司已有不少：Google、蘋果、特斯拉、Uber、百度等互聯網企業都已參與其中，寶馬、福特、沃爾沃等傳統車企也相繼加入。
智能車載操作系統由最初的車機聯網的需求發展而來，逐步引入互聯網汽車的理念，主要用于支撐人與車、車與車、車與互聯網等的交互，滿足舒適便捷的需求。隨著互聯網汽車熱潮的到來，目前蘋果、谷歌等互聯網企業，以及大眾、福特等傳統車企均紛紛涉足這一領域，市場上主要存在的智能車載操作系統包括微軟的Windows Automotive、谷歌的Android Auto、黑莓的QNX、蘋果的iOS、阿里的YunOS Auto，以及開源的Linux、GENIVI等。
近年來，我國汽車操作系統研發及應用取得了積極進展。在車控操作系統軟件方面，“核高基”重大專項部署支持了實時嵌入式操作系統及開發環境、汽車電子控制器嵌入式軟件開發平臺和國產汽車電子基礎軟件平臺產品。國內軟件平臺廠商參照 OSEK/VDX 和 AUTOSAR 等國際標準，已經研發了面向 ECU 的操作系統產品及解決方案。同時，百度推出了以CarOS智能車控操作系統為核心的自動駕駛平臺Apollo，在自動駕駛領域與國際領先企業展開同臺競爭。在車載操作系統方面，阿里云研發了可用于車載終端的YUNOS Auto操作系統，并且和上汽聯合發布了兩款互聯網汽車——榮威RX5 和i6，此外百度也推出了兼容多系統的車機聯網系統Carlife。
傳統車控操作系統仍是短板。雖然在“核高基”支持下，我國在汽車嵌入式實時操作系統領域取得了一定進展，但由于技術產品基礎薄弱、專業人才不足、生態支撐能力差、市場拓展困難等因素，導致我國在傳統車控操作系統領域話語權仍然不強。
智能車控、車載操作系統仍處于發展初期。我國在智能車控、車載操作系統領域涌現出了百度、阿里等有實力的企業，但我國智能車控、車載操作系統發展仍處于初期階段，在智能車控、車載關鍵核心技術研發、軟硬件兼容適配等方面仍需強化。
生態支撐能力有待加強。我國在車控、車載關鍵核心標準制定、應用軟件，以及配套硬件供給方面與國外仍存在一定差距。企業間、企業與科研機構間的技術合作、資本合作等合作模式有待探索，產學研用協同創新體系尚未形成。此外，在公共服務支撐、人才培養等方面也需加強。
支持一汽、長安、奇瑞等車企依托智能汽車發展戰略，加強與軟件企業、互聯網企業、人工智能企業等協同創新，加快布局智能車控操作系統領域。
支持有實力的企業之間開展深度合作，加強智能車控操作系統關鍵技術研究，研制面向自動駕駛、自主可控的智能車控操作系統平臺。
支持互聯網企業，以及有實力的操作系統企業，加強智能系統安全機制、交互機制的研究，加快研制、完善智能車載操作系統。
支持軟件企業與車企加強合作，繼續加強實時嵌入式操作系統的核心技術攻關，加快形成自主可控、安全可靠的汽車電子實時嵌入式操作系統產品體系。
支持操作系統研發企業參照OSEK/VDX和AUTOSAR等國際標準，與車企聯合研制符合國際標準車控操作系統產品和整體解決方案，加快拓展國際市場。
支持一汽等車企與軟件企業緊密合作，重點突破汽車動力、底盤、安全等相關軟件控制技術，加快關鍵車控應用軟件的研發和產業化。
支持科大訊飛、高德等軟件企業，以及普華、博思、中科博泰、航盛等車載終端系統供應商，繼續加強娛樂、導航等車載應用軟件研發和產業化。
加快推進視覺道路環境感知、自適應巡航、車道偏離預警、控制決策等自動駕駛相關車控、車載應用軟件的研發和產業化。支持傳感器、芯片、零部件廠商加大研發投入力度，加強與汽車操作系統廠商合作， 形成軟硬協同推進的局面。
作者：王宇霞
OSEK網絡管理論文 篇3：
CAN總線通信系統在混合動力汽車的設計和測試
摘 要：混合動力汽車存在弱電設備的電子干擾強、在信號傳遞時對實時性要求比較高以及信息量比較大的特性，為了更好的解決這方面的問題，提高混合動力汽車的性能，人們設計了 CAN總線通信協議。該協議符合SAEJ1939標準，主要內容有物理層協議、網絡管理協議、交互層協議、應用層協議與故障診斷處理的方案等，在該協議中人們提出了具體的網絡通信的性能指標。通過大量的實驗也證明了該協議是能夠滿足混合動力汽車在復雜的電磁環境下的各項需求，并且具有優良的通信性能與對故障的自我診斷能力。
關鍵詞：混合動力汽車；CAN協議；電磁干擾
1 總成控制系統的設計
1.1 控制系統網絡設計。
跟大部分的汽車一樣，混合動力汽車的控制系統不是單獨的存在，它是由諸多控制單元組合而成的車載系統，屬于分布式，結構上屬于拓撲結構，使用適合的終端電阻作為總線的終端，這樣做可以起到對信號反射的阻止作用。而 CAN總線的兩端分布著終端電阻，兩端的端口也是單獨的終端電阻。
1.2 網絡管理協議設計。
網絡管理對于 CAN網絡的正常工作起著至關重要的作用，通過 OSEK與 VDX模型可以看出，網絡管理主要包括直接網絡管理與間接網絡管理兩種模式。擁有專業的網絡管理報文的是直接網絡管理，而通過被檢測各個節點的周期性發送應用報文以對整個網絡節點進行確定的是間接網絡管理。如果在規定的時間之內，網絡管理收不到節點發送的報文，便可以確認在這個網絡上并沒有這個節點?？傮w來說，間接網絡管理可以減少對于總線的負荷。
1.3 CAN總線應用層協議的設計。
相對傳統的汽車，混合動力汽車新增了一些設備以及部件，比如驅動電機，動力電池與動力控制單元。在SAEJ1939協議中已經對這些部件進行了定義，本文在這里對這些部件的 ECU源地址給出定義，綜合信息幀的優先級與數據頁包括ECU的源地址，從而得到所有信息條目的ID。只要信息的更新與接收節點的要求構成了信息的周期，再通過對信息周期進行定義之后，HEV控制系統在CAN總線應用層的協議設計才算完成。
1.4 對故障處理方案的設計。
檢測與處理故障有兩部分的內容，每個控制單元的ECU主要負責記錄每個節點部件的故障檢測與CAN通信錯誤的記錄。而動力總成控制單元處在最上層，主要對整個系統故障進行界定與處理。每個單元在得到節點的故障之后就會經過CAN傳遞到動力控制單元。此時通信使用的報文便是應用層規定的特殊消息，而上層的動力總成控制單元在收到故障之后便會根據不同的故障而使動力系統的工作處在不同的狀態，比如正常與停止。
2 系統部件與實車測試
對混合動力汽車CAN總線的測試，根據測試對象的不同可以分成以下幾部分：單ECU網絡接口的測試，子系統與整車網絡臺架的測試以及實車網絡測試。單獨的ECU網絡接口的測試主要測試的是獨立控制器網絡接口的功能。子系統與整車的網絡臺架測試的則是子網絡與整車網絡總線的物理層性能與總線的錯誤檢查記錄以及處理的機制。實車網絡測試則偏重于子網絡和整車網絡的總線物理層性能以及處理機制、報文的通信參數，對網絡管理進行喚醒與休眠的測試。測試工具主要包括， CANoe，CAN-case硬件，CANStress，程控電源與多極性電源等。
總線電壓測試的主要內容是對物理電平信號的測試。增加共模電感之后總線的共模干擾很小，波形也相當完整，只有信號在上升與下降的過程中出現了一些輕微的震蕩，這點還是需要改進的。對混合動力控制器進行的是位時間的測試，CANScope可以取得76位信號的時間，測試之后就可以通過計算得到在位時間，根據得到的在位時間判斷是否符合設計要求的。而對混合動力控制器的測試主要是對信號的周期與結果的分析。如果信息的發送周期最大的誤差可以保證不會超過0.56102ms就屬于正常的情況，如果統計窗口則說明在總線負載率為百分之九十八的情況下發送周期最大的誤差在0.57995ms，這種情況也是能夠滿足對系統的設計要求的。
3 結語
通過對零部件與實車的綜合測試，已經能夠證明，CAN總線能夠符合混合動力汽車對電磁環境的要求，以及對實時性、大量數據傳輸的要求。隨著國家對新能源汽車開發中的投入不斷的加大，以及人們對新能源汽車的認識的不斷加深，相信CAN總線通信協議技術會得到越來越廣泛的應用，也必將成為新能源汽車在數據傳輸方面應用的首選。
參考文獻：
[1]鄔寬明 .CAN總線原理與應用系統設計[M].北京：北京航空航天大學出版社， 2002：25-30.
[2]陳清泉 .混合動力電動汽車結構、原理與維修 [M].北京：化學工業出版社，2008：6-27.
作者簡介
胡佳璽：工程師，研究生。主要研究方向是汽車總線網絡測試和汽車電器功能測試。
作者：胡佳璽