AUTOSAR架構(gòu)開發(fā)的案例
AUTOSAR 架構(gòu)下看門狗的理解
來源 | CSDN博主「ZhouArchie」
本文主要介紹AUTOSAR 架構(gòu)下的WdgDriver WdgIf WdgM 模塊，分析模塊之間的依賴關(guān)系以及運行原理以幫助快速理解。本文以MPC5746R為主控芯片，以FS6500為SBC，DaVinci Configurator 為AUTOSAR工具鏈。
01
模塊架構(gòu)與依賴
1、模塊介紹
AUTOSAR架構(gòu)中的WDG 一共分為三個部分，Wdg Driver Wdg Interface Wdg Manager。其中Wdg Driver分為 External watchdog driver 與 Internal watch driver。其中外部驅(qū)動由SBC提供功能，內(nèi)部驅(qū)動由SWT模塊提供功能。MPC5746R有三個SWT(Soft Watchdog Timer)，SWT0 負(fù)責(zé)CPU0，SWT1負(fù)責(zé)CPU1,SWT2可以由CPU0 與CPU1訪問。
Wdg Driver 提供底層喂狗與設(shè)置看門狗模式的驅(qū)動函數(shù)，由WdgIf抽象成Wdg Device。WdgM獲取WdgIf的抽象數(shù)據(jù)得到底層的配置數(shù)據(jù)與驅(qū)動接口函數(shù)。
WdgM一共支持三種形式的看門狗檢查方式。1.AliveSpuervision 2.DeadlineSupervision 3. LogicalSupervision。
AliveSpuervision提供一般的喂狗服務(wù)，即監(jiān)控周期性程序是否能正常執(zhí)行，保證程序處于Alive狀態(tài)。
DeadlineSupervision提供監(jiān)督軟件在兩個狀態(tài)之間的轉(zhuǎn)換時間。
LogicalSupervision提供監(jiān)督軟件執(zhí)行順序的正確性。
展開 結(jié)合AUTOSAR和DDS實現(xiàn)靈活的車輛架構(gòu)
來源 |
汽車ECU開發(fā)
知圈 |
進(jìn)“電子電氣群”請加微13636581676,備注架構(gòu)
在消費者對自動駕駛和網(wǎng)聯(lián)需求的推動下，以及通信帶寬和原始計算能力的技術(shù)飛躍，汽車行業(yè)正在迅速轉(zhuǎn)型。
這些變化需要汽車設(shè)計的架構(gòu)轉(zhuǎn)變，因為傳統(tǒng)的電氣/電子架構(gòu)無法為運行未來汽車軟件系統(tǒng)互連系統(tǒng)所需的新數(shù)據(jù)中心方法提供必要的可擴展性。
AUTOSAR和DDS是兩個可以適應(yīng)這些新需求的軟件標(biāo)準(zhǔn)。AUTOSAR是為汽車ecu設(shè)計的標(biāo)準(zhǔn)化汽車開放系統(tǒng)架構(gòu)。AUTOSAR的兩個平臺AUTOSAR Classic和AUTOSAR Adaptive為不同的車輛用例提供了分層的軟件體系結(jié)構(gòu)方法。特別是，AUTOSAR Adaptive平臺解決了車內(nèi)高性能計算的設(shè)計挑戰(zhàn)，解決了下一代汽車所需的連接性和持續(xù)軟件更新。它還可以作為來自多個供應(yīng)商的軟件的集成平臺。
數(shù)據(jù)分發(fā)服務(wù) (DDS) 標(biāo)準(zhǔn)是將分布式系統(tǒng)的組件集成在一起的中間件協(xié)議和以數(shù)據(jù)為中心的連接框架。它通過實現(xiàn)低延遲數(shù)據(jù)連接、極高的可靠性和可擴展的靈活架構(gòu)，使數(shù)據(jù)成為未來移動數(shù)字平臺的中心。DDS 促進(jìn)了松散耦合、模塊化和開放式架構(gòu)系統(tǒng)的開發(fā)，從而降低了復(fù)雜性、上市時間和系統(tǒng)成本。
為了滿足互聯(lián)數(shù)字車輛的需求，AUTOSAR 和 DDS 這兩個強大的標(biāo)準(zhǔn)現(xiàn)在可以協(xié)同工作。在 AUTOSAR Adaptive 平臺中，DDS 組件針對端到端數(shù)據(jù)共享進(jìn)行了優(yōu)化，無需自定義集成。AUTOSAR Adaptive 定義了 DDS 網(wǎng)絡(luò)綁定，以支持具有生產(chǎn)就緒通信框架的自治系統(tǒng)，該框架提供復(fù)雜系統(tǒng)所需的可靠性、可擴展性和性能。AUTOSAR 和 DDS 共同為汽車制造商提供了設(shè)計和操作下一代汽車的高性能方法。
展開 AUTOSAR架構(gòu)的 Pdu Router
[2] 基于AUTOSAR標(biāo)準(zhǔn)的汽車通訊及網(wǎng)絡(luò)管理技術(shù)的設(shè)計及實現(xiàn)[M]，楊永亮，山東大學(xué)
DDS與AUTOSAR融合實現(xiàn)汽車架構(gòu)松耦合
變革的主要方法是針對現(xiàn)有的架構(gòu)進(jìn)行改變，鑒于傳統(tǒng)的電氣/電子架構(gòu)無法為新的以數(shù)據(jù)為中心的通信方式提供必要的可伸縮性，未來的汽車將會走向軟件定義汽車的時代。
AUTOSAR?和DDS?是兩個能夠適應(yīng)上述架構(gòu)轉(zhuǎn)變并為其提供可拓展性的標(biāo)準(zhǔn)。AUTOSAR是為汽車ECU設(shè)計的標(biāo)準(zhǔn)化汽車開放系統(tǒng)架構(gòu)。AUTOSAR的AP和CP為不同的的場景提供軟件的相應(yīng)分層架構(gòu)，尤其是AUTOSAR-AP主要為了解決下一代汽車的需要高性能和持續(xù)連接和集成的問題，目前有大量供應(yīng)商采用了AUTOSAR的架構(gòu)。
DDS標(biāo)準(zhǔn)是一種中間件協(xié)議和以數(shù)據(jù)為中心的連接框架，它可以將分布式系統(tǒng)的組件集成在一起.DDS能夠?qū)崿F(xiàn)低延遲、高可靠、高實時性的數(shù)據(jù)融合服務(wù)，能夠從根本上降低軟件的耦合性、復(fù)雜性提高軟件的模塊化特性，融合了DDS的汽車軟件能夠更好的運行在下一代汽車的體系架構(gòu)中，更能降低開發(fā)的成本、縮短研發(fā)的時間，更快的將產(chǎn)品推向市場。
為了解決現(xiàn)在汽車軟件架構(gòu)的問題，DDS和AUTOSAR被越來越多的采用，將兩者融合能夠充分發(fā)揮兩者的優(yōu)勢所在。針對于AUTOSAR的AP平臺，DDS能夠優(yōu)化端到端的數(shù)據(jù)傳輸而無需再進(jìn)行集成，并且為了實現(xiàn)數(shù)據(jù)的生產(chǎn)-準(zhǔn)備對于DDS進(jìn)行了網(wǎng)絡(luò)的綁定，因此對于復(fù)雜的軟件系統(tǒng)，顯著的增加了軟件的可靠性、伸縮性，提高的性能。AUTOSAR和DDS為汽車廠商設(shè)計和運營并提升下一代汽車的性能提供了一種行之有效的方法。
展開 
ECU軟件的AUTOSAR分層架構(gòu)
來源 | 汽車功能安全
知圈 | 進(jìn)“激光雷達(dá)社群”請加微信13636581676，備注激光
主要目錄：概述、應(yīng)用層、VFB與RTE層、基礎(chǔ)軟件（BSW）、示例（前車燈管理系統(tǒng)）、總結(jié)、參考文獻(xiàn)
干貨‖新能源智能汽車EE架構(gòu)--AUTOSAR（AP）SOA特點
干貨‖日產(chǎn)的超越價值工程的技術(shù)降成本方法及案例介紹
干貨‖汽車總裝工藝中的質(zhì)量控制
干貨‖汽車NVH測試技術(shù)183頁技術(shù)資料分享
干貨‖汽車總裝工藝同步工程
干貨‖汽車底盤電子控制系統(tǒng)的安全性設(shè)計及質(zhì)量保障
干貨‖泡沫鋁防撞梁與安全車身結(jié)構(gòu)
干貨‖能量管理性能集成
干貨‖GM 凱迪拉克輕量化設(shè)計規(guī)則探討
干貨‖客戶需求聲音VOC&質(zhì)量屋QFD方法及操作實務(wù)
干貨‖綜合電氣電子架構(gòu)的技術(shù)應(yīng)用
干貨‖整車總布置中的人機工程
干貨‖整車及零部件開發(fā)中的疲勞強度試驗技術(shù)與實踐
干貨‖整車動力總成動力性匹配與優(yōu)化
干貨‖結(jié)構(gòu)優(yōu)化靈敏度分析
干貨‖懸架性能開發(fā)-懸架K&C分析
干貨‖約束系統(tǒng)開發(fā)（正面碰撞）
干貨‖網(wǎng)絡(luò)與通訊系統(tǒng)設(shè)計
干貨‖統(tǒng)計性質(zhì)量控制方法 - SQC 151頁干貨分享
干貨‖汽車耐久性仿真
干貨‖汽車車身涂裝工藝流程和技術(shù)
干貨‖關(guān)鍵零部件及子系統(tǒng)功能匹配
干貨‖動力系統(tǒng)匹配案例分析
干貨‖風(fēng)噪仿真的現(xiàn)狀和挑戰(zhàn)
展開 AutoSar在自動駕駛開發(fā)中應(yīng)用原理
汽車應(yīng)用軟件開發(fā)已成為汽車開發(fā)過程中最復(fù)雜，最關(guān)鍵的活動。AUTOSAR（汽車開放系統(tǒng)架構(gòu)）為汽車電子控制單元（ECU）開發(fā)了標(biāo)準(zhǔn)化的開放軟件體系結(jié)構(gòu)，是主機廠、供應(yīng)商以及工具和半導(dǎo)體供應(yīng)商的合作伙伴。重點是管理汽車電氣/電子（E / E）架構(gòu)開發(fā)中日益增長的復(fù)雜性，旨在實現(xiàn)新技術(shù)并提高開發(fā)效率-而不影響質(zhì)量。Autosar旨在軟件架構(gòu)、開發(fā)方法、應(yīng)用程序界面三個技術(shù)領(lǐng)域中實現(xiàn)標(biāo)準(zhǔn)化。
除此重點外，AUTOSAR的關(guān)鍵成功因素還在于其開發(fā)協(xié)議，該協(xié)議從法律層面控制著合作伙伴與其精益組織之間的關(guān)系，從而區(qū)分了即核心合作伙伴和其他合作伙伴（保費，開發(fā)和合作伙伴），從而參照精益流程以快速做出決策。
為了掌握OEM和供應(yīng)商之間軟件模塊（例如駕駛員輔助系統(tǒng)）的復(fù)雜性，整體來說AutoSar有如下9個目標(biāo)：
1.軟件的可移植性。
OEM和供應(yīng)商應(yīng)能夠在車輛網(wǎng)絡(luò)內(nèi)重用軟件。也可以在不同OEM的不同汽車平臺上使用相同的軟件。
2.對不同車輛和平臺型號的可擴展性。
AUTOSAR應(yīng)提供用于開發(fā)可適用于不同車輛以及車輛平臺和硬件的軟件系統(tǒng)的機制。這意味著AUTOSAR應(yīng)該是可配置的，以便可以集成到不同的車輛中。
3.支持不同的功能域。
AUTOSAR應(yīng)該能夠在盡可能多的功能域中重用軟件組件。這包括與非AUTOSAR系統(tǒng)的數(shù)據(jù)交換，例如與車輛信息娛樂系統(tǒng)的通信。
4.定義開放式體系結(jié)構(gòu)。
AUTOSAR的體系結(jié)構(gòu)應(yīng)該是可維護(hù)的，可適應(yīng)的和可擴展的。因此，錯誤可以不斷修復(fù)。可以實現(xiàn)將來的要求和個性化增強。
5.開發(fā)高度可靠的系統(tǒng)。
AUTOSAR必須實現(xiàn)可用性，可靠性，功能安全性，完整性，維護(hù)性和安全性。通過這種方式，例如可以考慮對功能安全性的要求。
6.自然資源的可持續(xù)利用。
支持使用有效利用自然資源和使用可再生能源的技術(shù)。
展開 基于自適應(yīng)AUTOSAR的HPC開發(fā)
編輯 | 曉靖
出品 | 焉知
在焉知汽車科技、是德科技聯(lián)合組織的“第三屆智能汽車電子電氣架構(gòu)研討會”上，來自車企、科技公司、零部件、測試認(rèn)證公司的專業(yè)人士齊聚一堂，就電子電氣架構(gòu)標(biāo)準(zhǔn)、以太網(wǎng)標(biāo)準(zhǔn)、SOA、TSN、線束開發(fā)、域控制器、AUTOSAR、信息安全、芯片、測試、計算平臺等話題進(jìn)行了深入的交流和探討。研討會上，Elektrobit項目總監(jiān)顧淳以“基于自適應(yīng)AUTOSAR的HP開發(fā)”為主題發(fā)表了精彩演講。
趨勢及挑戰(zhàn)
隨著EB架構(gòu)的進(jìn)化，整個電子電氣架構(gòu)發(fā)生了很大的更新，軟件本身變得日益復(fù)雜。現(xiàn)在的軟件到底有多復(fù)雜？有幾個實例大家可以看一下。
首先是奧迪說目前的軟件開發(fā)工作90%是集成和驗證的工作。寶馬說現(xiàn)在信息娛樂系統(tǒng)開發(fā)復(fù)雜程度日益增加，其中包含了400個軟件的組件，250個交互Interfaces，包含50到60個Million LoC。
Visteon，整個開發(fā)需要100個元年，日本的概念就是50個人要開發(fā)兩年。信息娛樂系統(tǒng)需要500元年，如果要開發(fā)一個L3的自動駕駛可能需要2000個元年，就是500個人要開發(fā)4年。我相信，如果要開發(fā)一個相當(dāng)智能的自動駕駛真的需要500個人投入4年去開發(fā)。
一位大佬說，差不多有15家主機廠目前正在開發(fā)自己的HCC，或叫HPC，都是要開發(fā)自己新的高性能處理器和E/E架構(gòu)。整個新的E/E架構(gòu)的投資全球范圍內(nèi)差不多要達(dá)到7.5億美金。
整個E/E架構(gòu)或者軟件趨勢變得越來越復(fù)雜，軟件復(fù)雜度增加和新的E/E架構(gòu)對于我們都是挑戰(zhàn)。
來自一些專業(yè)咨詢調(diào)研機構(gòu)的數(shù)據(jù)顯示，隨著越來越多高級功能的增加，代碼量及其復(fù)雜度呈指數(shù)級增長。
展開 基于Autosar的SOA軟件開發(fā)設(shè)計詳解
基于Autosar的SOA軟件架構(gòu)設(shè)計方法
除了具備描述汽車行業(yè) E/E 系統(tǒng)的基本能力外，還有許多方面需要實際交換格式的支持，例如可以通過技術(shù)文檔（包括規(guī)范、定義、技術(shù)要求等）、接口需求表等可追溯性來貫穿整個軟件生命周期。這種集成的變體管理允許 OEM 和供應(yīng)商共同深入到基本的 AUTOSAR 產(chǎn)品線，并在必要時與其合作伙伴交換相互的信息，對這些變體的共同理解和一致解釋是聯(lián)合開發(fā)項目成功合作的關(guān)鍵因素。
各種SWC組件接口調(diào)用示意圖
SOA中的應(yīng)用程序接口用于確保應(yīng)用程序模塊與 RTE 進(jìn)行有效鏈接。其中，AP Autosar并未標(biāo)準(zhǔn)化應(yīng)用程序的內(nèi)部功能流程，例如算法，而是將在應(yīng)用程序之間交換的信息。
一方面Autosar使用專用語法將基本接口機制進(jìn)行了標(biāo)準(zhǔn)化。這種標(biāo)準(zhǔn)化接口規(guī)范允許軟件設(shè)計人員和開發(fā)人員獨立于任何特定硬件或 ECU 來開發(fā)軟件模塊，這種軟件模塊可以在包含其使用的數(shù)據(jù)類型、單位和縮放因子下進(jìn)行擴展或重用。另一方面對車輛域主體中應(yīng)用程序接口的語義、內(nèi)涵、舒適性、動力傳動系、底盤以及乘客和行人保護(hù)進(jìn)行了標(biāo)準(zhǔn)化。重點是廣泛引入應(yīng)用程序的接口規(guī)范，以重點突破軟件模塊的重用和交換。最后，標(biāo)準(zhǔn)化應(yīng)用程序接口的使用對于應(yīng)用程序的重用至關(guān)重要。
系統(tǒng)架構(gòu)-虛擬功能總線
為了開發(fā)功能系統(tǒng)架構(gòu)，AUTOSAR 引入了虛擬功能總線的概念——VFB（Virtual Function
Bus）。
為了避免誤解，應(yīng)該明確指出：
AUTOSAR 已經(jīng)指定了 VFB 概念。
這個概念在市場上可用的各種系統(tǒng)架構(gòu)工具中實現(xiàn)。
展開 基于案例解析AP AUTOSAR開發(fā)流程
本文通過一個應(yīng)用案例，將整體使用AP AUTOSAR的流程簡單介紹。同時，讀者將理解AP AUTOSAR的幾個基本平臺組件。基于這個案例，讀者可以了解最基礎(chǔ)的AP AUTOSAR開發(fā)流程。其中，重點介紹了AP AUTOSAR建模。
1
開發(fā)流程
AP AUTOSAR整體開發(fā)流程
AP AUTOSAR開發(fā)流程：
定義服務(wù)：輸出ServiceInterface, 屬于OEM工作范圍。
生成基于Skeleton/Proxy 的Class。使用AUTOSAR供應(yīng)商工具鏈。
實現(xiàn)SWC和使用目標(biāo)軟件平臺工具鏈編譯為可執(zhí)行文件 Executables。
生成Machine Manifest。描述目標(biāo)硬件和軟件平臺環(huán)境。將應(yīng)用映射到進(jìn)程。使用AUTOSAR工具鏈。
2
案例：服務(wù)定義
將車輛功能拆解為服務(wù)的部分在這里就不多講了。我個人認(rèn)為這個跟業(yè)務(wù)邏輯強相關(guān)，跟IT域的方法論沒什么太大區(qū)別。
一個服務(wù)接口需滿足SOME/IP的組成，里面包含3部分：Fields，Events，Methods。技術(shù)細(xì)節(jié)請參看SOME/IP介紹。
本文假設(shè)一個服務(wù)接口RadarFusion。
對于一個SOA服務(wù)接口，肯定至少得有一個Provider和可能多個Consumer。
3
使用工具鏈生成Skeleton/Proxy
Skeleton/Proxy是在CM （Communication Management）選擇的基本設(shè)計模式。這是軟件設(shè)計模式里最常用的幾個設(shè)計模式之一。AP AUTOSAR基本上參考了GENIVI的CommonAPI設(shè)計。
展開 汽車架構(gòu)開發(fā)中的整車熱管理系統(tǒng)開發(fā)方法研究
空調(diào)箱（HVAC）開發(fā)工作量大，開發(fā)周期長，需要考慮架構(gòu)內(nèi)各車型的最大制熱量和最大制冷量，盡量地布局少量規(guī)格不同的空調(diào)箱數(shù)量。空調(diào)壓縮機價格高，架構(gòu)內(nèi)只能選用少量排量規(guī)格（零部件尺寸帶寬）不同的壓縮機。架構(gòu)內(nèi)各車型前端模塊中的核心零部件除了散熱器芯厚（零部件尺寸帶寬）要隨整備質(zhì)量而系列化以外，其它零部件基本不變。熱管理系統(tǒng)回路中其它零部件，如冷卻液水泵、電池冷卻鼓風(fēng)機、制冷劑回路和冷卻液回路控制閥等，除了制冷劑回路和冷卻液回路的管路和支架以外，都保持基本不變。
2.3整車熱管理系統(tǒng)V字形開發(fā)流程
架構(gòu)的整車熱管理系統(tǒng)開發(fā)與單一車型的整車熱管理系統(tǒng)開發(fā)有所不同，需要重點考慮架構(gòu)的整車熱管理系統(tǒng)的共同特征的實現(xiàn)。通過逐步完善圖3所示的V字形開發(fā)流程的各項開發(fā)技術(shù)，提高架構(gòu)內(nèi)各車型的整車熱管理系統(tǒng)的模塊和回路零部件的共用性，降低開發(fā)難度，縮短開發(fā)周期，減少零部件成本和系統(tǒng)開發(fā)成本。
3架構(gòu)樣車整車熱管理系統(tǒng)的試驗驗證
為實現(xiàn)架構(gòu)整車熱管理系統(tǒng)開發(fā)的功能性能目標(biāo)，并考察熱管理系統(tǒng)的模塊化和核心零部件系列化是否可行、共同的工程解決方案是否合理，需要設(shè)計和搭建架構(gòu)樣車，需要進(jìn)行整車熱管理系統(tǒng)性能試驗和發(fā)動機艙的溫場試驗進(jìn)行試驗驗證。
3.1架構(gòu)的代表性樣車的方案設(shè)計
不同于車型開發(fā)中騾子車設(shè)計方案只需對應(yīng)車型開發(fā)性能需求，架構(gòu)樣車代表性樣車方案設(shè)計需要以最少裝車方案數(shù)量來盡可能的覆蓋架構(gòu)性能帶寬最大邊界、并根據(jù)架構(gòu)動力總成配置矩陣（發(fā)動機+變速箱/混動模塊或電機）選擇最具代表性的動力總成搭配組合。
展開 
基于SOA架構(gòu)的開發(fā)策略詳解
從整個SOA的架構(gòu)模型中我們知道服務(wù)需要從通用服務(wù)平臺開始進(jìn)行底層驅(qū)動，然后對上層傳感器執(zhí)行器的控制管理進(jìn)行驅(qū)動。由于AP直接支持服務(wù)接口，可以直接面向上層應(yīng)用層，CP仍然是對常用的底層應(yīng)用服務(wù)的驅(qū)動映射，因此，兩層驅(qū)動分別對應(yīng)著經(jīng)典的CP Autosar中間件調(diào)用和AP Autosar模式。
Step4：通訊協(xié)議設(shè)計
智能網(wǎng)聯(lián)汽車的SOA架構(gòu)設(shè)計需要強大的環(huán)境感知、信息處理、實施決策、控制能力可以把智能交通、地圖、定位、通訊、云、大數(shù)據(jù)等進(jìn)行系統(tǒng)集成，故車端與云端、車輛與車輛之間、車輛內(nèi)部的各個ECU之間通信的速率和數(shù)據(jù)量都比傳統(tǒng)汽車高出幾個數(shù)量級，這些需要由多種復(fù)雜的硬件、軟件和高速通信總線共同實現(xiàn)，并在很大程度上決定智能汽車的功能實現(xiàn)和擴展的可靠性。車載以太網(wǎng)能夠很好的解決大數(shù)據(jù)量的信息交互，整個通信協(xié)議的定義包括虛擬以太網(wǎng)VLAN，以太網(wǎng)交換機Switch，套接字Socket，基于IP的可擴展面向服務(wù)的中間件SOME/IP，SD等。而基于AVB的下一代協(xié)議TSN（時間敏感網(wǎng)絡(luò)）可以提供非常優(yōu)秀的實時性。
以太網(wǎng)通訊設(shè)計過程包含對服務(wù)實例進(jìn)行通訊協(xié)議相關(guān)的信息配置。由于SOA架構(gòu)中包含多個應(yīng)用實體之間的多通路通信過程，且這些通信通常是網(wǎng)狀通信，因此需要在各個實體節(jié)點之間建立中間路由、轉(zhuǎn)化等。區(qū)別于傳統(tǒng)總線（Can/Lin），在軟件架構(gòu)設(shè)計過程中，開發(fā)人員需要設(shè)計具體的服務(wù)類型、服務(wù)ID、服務(wù)數(shù)據(jù)類型、服務(wù)角色等。
SOA架構(gòu)設(shè)計流程
SOA的邏輯架構(gòu)內(nèi)容需要根據(jù)分層架構(gòu)策略分配給一層的多個模塊。
展開 水冷主機產(chǎn)品級開發(fā)架構(gòu)圖
按照四橫五縱進(jìn)行考慮，四橫：產(chǎn)品級、子系統(tǒng)級、組件級、零部件級；九縱：基本要求、外觀、外形尺寸、用戶感知、功能、性能、環(huán)境、可靠性、可生產(chǎn)性）（注意將產(chǎn)品級、子系統(tǒng)級的要求轉(zhuǎn)化為子系統(tǒng)、組件或零部件級的要求，如上水冷主機產(chǎn)品級框架圖，按照產(chǎn)品功能分解成系統(tǒng)、子系統(tǒng)、組件和零件。
汽車電子電氣架構(gòu)開發(fā)咨詢服務(wù)
在新車型E/E 平臺規(guī)劃前期，整車廠就需要開展電子電氣架構(gòu)開發(fā)工作， 從而對電子電氣系統(tǒng)的開發(fā)進(jìn)行有效的管理和控制。
電子電氣架構(gòu)屬于車輛電子電氣系統(tǒng)的頂層設(shè)計，目標(biāo)是在功能需求、法規(guī)和設(shè)計指標(biāo)等特定約束條件下，綜合對功能、性能、成本和裝配等方面的具體分析，得到電子電氣系統(tǒng)技術(shù)方案。伴隨著平臺化、模塊化開發(fā)理念在車輛開發(fā)中的應(yīng)用，電子電氣系統(tǒng)普遍基于平臺化要求進(jìn)行規(guī)劃，即構(gòu)建利于復(fù)用、裁剪、擴展的電子電氣架構(gòu)，用于支撐目標(biāo)市場的不同車型。
服務(wù)內(nèi)容
經(jīng)緯恒潤可以根據(jù)不同客戶的需求，提供如下電子電氣架構(gòu)開發(fā)咨詢服務(wù)：
? 根據(jù)市場和客戶特征定義整車 E/E 功能
? 競品車型電子電氣系統(tǒng)解析
? 定義各個整車功能到具體零部件產(chǎn)品的映射
? 整車各子系統(tǒng)功能邏輯設(shè)計
? 定義各 ECU 功能需求及編制技術(shù)規(guī)范
? 定義車輛能量管理策略
? 整車電氣原理設(shè)計開發(fā)
? 電子電氣架構(gòu)原型設(shè)計開發(fā)的建模及驗證
? 架構(gòu)開發(fā)過程及方法的培訓(xùn)及咨詢
架構(gòu)開發(fā)流程
服務(wù)優(yōu)勢
? 10 年電子電氣架構(gòu)開發(fā)經(jīng)驗
? 20 多個整車廠架構(gòu)開發(fā)服務(wù)案例
? 架構(gòu)開發(fā)工具代理及應(yīng)用經(jīng)驗
? 多款車型對標(biāo)經(jīng)驗
? 豐富的 ECU 配套開發(fā)經(jīng)驗
? 80 多個子系統(tǒng)技術(shù)規(guī)范開發(fā)經(jīng)驗
? 60 多個零部件功能規(guī)范開發(fā)經(jīng)驗
? 30 人專職架構(gòu)開發(fā)團(tuán)隊
經(jīng)緯恒潤
北京市海淀區(qū)知春路7號致真大廈D座6層
郵箱：market_dept@hirain.com
網(wǎng)址：www.hirain.com
展開 面向部件的整車E/E架構(gòu)開發(fā)咨詢服務(wù)
概述
隨著汽車電子電氣系統(tǒng)復(fù)雜度的日益提高，各零部件間的交互影響帶來安全性和穩(wěn)定性的挑戰(zhàn)，傳統(tǒng)的 Tier 提供平臺化零部件、OEM 直接集成應(yīng)用的開發(fā)模式，難以滿足車型產(chǎn)品規(guī)避同質(zhì)化、提高差異化競爭優(yōu)勢的需求。因此，在新車型 E/E 平臺開發(fā)過程中，需要綜合市場需求、法規(guī)要求、競品車型數(shù)據(jù)、供應(yīng)商優(yōu)勢資源、模塊化設(shè)計理念等，從全局統(tǒng)籌電子電氣架構(gòu)的總體設(shè)計。
為適應(yīng)市場用戶需求的快速變化，車型開發(fā)及迭代周期顯著縮短，在有限的開發(fā)周期內(nèi)保持產(chǎn)品設(shè)計競爭力，這對 E/E 架構(gòu)團(tuán)隊產(chǎn)生了前所未有的挑戰(zhàn)。為應(yīng)對這一挑戰(zhàn)，經(jīng)緯恒潤根據(jù)多年的架構(gòu)設(shè)計經(jīng)驗創(chuàng)建了一套短周期 E/E 架構(gòu)開發(fā)解決方案--面向部件的整車 E/E 架構(gòu)開發(fā)解決方案，可根據(jù) OEM 規(guī)劃的 Function list 及車型產(chǎn)品特點，在4～6月時間內(nèi)協(xié)助 OEM E/E 架構(gòu)開發(fā)團(tuán)隊設(shè)計一套涵蓋整車5大功能域的 E/E 架構(gòu)需求規(guī)范。
服務(wù)內(nèi)容
經(jīng)緯恒潤多年來一直致力于為客戶提供先進(jìn)的電子電氣架構(gòu)解決方案，幫助客戶搭建和優(yōu)化車輛電子電氣系統(tǒng)，提升市場競爭力。
展開 