范工給我發(fā)了兩個視頻，我后來找了一下油管上也有：

1）CANoe for Service-Oriented Architectures (Part 1/2和Part2/2)

2）Mastering Service-Oriented Architecture with CANoe’s Function Bus

我覺得我們做電動汽車的為什么要關(guān)注這個，主要是歐洲汽車產(chǎn)業(yè)在尋找下一輪汽車技術(shù)的驅(qū)動，是從動力系統(tǒng)的各種特性轉(zhuǎn)向軟件方面，看以下MEB的系統(tǒng)，最大的特點不是我們看他的電池和電軸我們有多大的差異，而是它在逐步使用它的體量在硬件上采購壓價，在軟件上分離迭代開發(fā)的趨勢特別明顯。

MEB從用戶體驗出發(fā)設(shè)計整車功能（Feature)，試圖把數(shù)字化生活拓展到車上，使得車輛成為數(shù)字化生活的一部分，并且借鑒Apple模式來開發(fā)整車。Apple有自己的用戶體驗/UX設(shè)計，以及封閉成熟的iOS，性能領(lǐng)先的64位處理芯片。

當(dāng)競爭轉(zhuǎn)向通信架構(gòu)、車載以太網(wǎng)的導(dǎo)入和軟件架構(gòu)、還有“MaaS”的理念的時候，有些事情我們想看看從組織、從分工從技術(shù)管理角度如何。

如果說，之前這張圖有點像是比喻的話，現(xiàn)在的汽車軟件和功能分配已經(jīng)開始有點像從手機(jī)的功能機(jī)往智能機(jī)轉(zhuǎn)化，不再單一從特性上做而是基于功能出發(fā)來迭代。

SOA這塊就是基本的核心訴求，而且是從現(xiàn)有的車載ECU軟件設(shè)計的角度開始變更。為了面對個性化的需求，功能軟件開發(fā)需要更敏捷，而基于此Service oriented Architecture (SOA)是完成這項任務(wù)的關(guān)鍵，它能夠建立動態(tài)的實時網(wǎng)絡(luò)通信關(guān)系，把車內(nèi)各個IP節(jié)點根據(jù)功能要求進(jìn)行應(yīng)用層服務(wù)的數(shù)據(jù)建立交互。

因此從電動汽車上部署這些，困難要比在原有成熟的東西上小很多。而且走完以后向前兼容，把PHEV和之前的架構(gòu)給一并使用，也就是說放開原有最堅固的動力總成的堡壘，放開具備自我循環(huán)迭代能力的供應(yīng)商，而在新的領(lǐng)域里面，著重強調(diào)OEM本身的軟件和技術(shù)整合能力，這點我們現(xiàn)在弄不來

ECU內(nèi)上層應(yīng)用程序可能來自不同的供應(yīng)商，軟件開發(fā)流程以及后期的集成測試驗證也會帶來更大的挑戰(zhàn)，傳統(tǒng)的汽車電子ECU供應(yīng)商與OEM的合作模式已經(jīng)發(fā)生變化，OEM以及第三方軟件供應(yīng)商會更多參與進(jìn)來。作為最終的負(fù)責(zé)方，OEM在系統(tǒng)開發(fā)中會擔(dān)當(dāng)越來越重要的角色，未來的成功將來自于全產(chǎn)業(yè)鏈的核心技術(shù)整合。軟件的開發(fā)計劃與硬件的開發(fā)計劃相互獨立，軟件將會是全生命周期內(nèi)迭代持續(xù)，且軟件可能橫跨更多不同硬件設(shè)備。

小結(jié)：往后看10年，可能整個汽車產(chǎn)業(yè)的秩序有很大的變化，這個變化是基于組織的變革，開發(fā)著重點的變革，還有能不能符合硬件（包含原有的機(jī)械部分）和軟件分離，這是整個價值體系變革的過程，特別是在持續(xù)壓縮成本下硬件創(chuàng)新的難度陡增。傾巢之下沒有完卵，搞不好傳統(tǒng)的我們都要碎了（一個是需要不需要，一個是重要不重要）