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

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

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

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

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

當競爭轉向通信架構、車載以太網的導入和軟件架構、還有“MaaS”的理念的時候，有些事情我們想看看從組織、從分工從技術管理角度如何。

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

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

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

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

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