前言

搞一下新架構(gòu)下的軟件技術(shù)系列會(huì)從高層軟件架構(gòu)出發(fā)，從宏觀的軟件技術(shù)運(yùn)用開始，逐步展開每個(gè)方面的軟件技術(shù)細(xì)節(jié)，為讀者朋友們提供學(xué)習(xí)軟件相關(guān)技術(shù)的平臺(tái)。全系將涵蓋軟件架構(gòu)設(shè)計(jì)，服務(wù)應(yīng)用設(shè)計(jì)，中間件技術(shù)，模型開發(fā)技術(shù)等方面進(jìn)行分享。


全系內(nèi)容可在《搞一下汽車電子》后臺(tái)回復(fù) “系列”，或進(jìn)入菜單欄 “分享平臺(tái)” --> “系列分享”


本系列請(qǐng)點(diǎn)擊：《搞一下新架構(gòu)下的軟件技術(shù)》


所有系列請(qǐng)點(diǎn)擊：《汽車電子系列分享》

汽車ECU發(fā)展

首先回顧汽車ECU的發(fā)展，從這張圖我們可以看到，從1975年第一代電子電噴控制器開始，汽車ECU發(fā)展迅速，ECU的數(shù)量與發(fā)展度也隨之快速增長(zhǎng)。





發(fā)展到1985年，已經(jīng)出現(xiàn)了像變速箱控制器，發(fā)動(dòng)機(jī)控制器等，同時(shí)也出現(xiàn)了第一代車內(nèi)網(wǎng)絡(luò)總線CAN。接近2000年，更復(fù)雜的主動(dòng)安全控制器，車輛穩(wěn)定系統(tǒng)控制器，自適應(yīng)導(dǎo)航控制器等陸續(xù)出現(xiàn)。


伴隨著汽車ECU的發(fā)展，車內(nèi)網(wǎng)路總線的技術(shù)也在不斷發(fā)展，從相對(duì)低速的CAN、LIN總線技術(shù)發(fā)展出更高速的Flexray, 可以到達(dá)10M的通信速率。


最近幾年，車內(nèi)以太網(wǎng)開始應(yīng)用100-baseT1，1000-BaseT1的以太網(wǎng)技術(shù)，從應(yīng)用場(chǎng)景上是為了滿足自動(dòng)駕駛以及車聯(lián)系網(wǎng)所需的高數(shù)據(jù)通信的應(yīng)用需求。


為了滿足復(fù)雜的應(yīng)用功能，相對(duì)比較獨(dú)立的汽車軟件，也慢慢引入了互聯(lián)網(wǎng)的軟件技術(shù)，如在工業(yè)以太網(wǎng)運(yùn)行成熟的實(shí)時(shí)通信技術(shù)，互聯(lián)網(wǎng)服務(wù)架構(gòu)理念，給汽車軟件帶來了創(chuàng)新的靈感。


在這個(gè)背景下，對(duì)汽車ECU的發(fā)展起到了非常大的推動(dòng)作用。另外新能源汽車發(fā)掘出了新穎的功能，更方便的AI人機(jī)交互過程，以及越來越智能的輔助駕駛系統(tǒng)。

獨(dú)立單一功能ECU

接下來講一下汽車ECU軟件的發(fā)展歷程，一開始汽車上出現(xiàn)的ECU主要是解決單體功能，比如以軟件的方式對(duì)電油門噴嘴進(jìn)行更精確的控制，以達(dá)到更好的燃油和動(dòng)力的效率。對(duì)于這類控制器，軟件的架構(gòu)也是相對(duì)簡(jiǎn)單的。





微控制器具備一定的外設(shè)資源，如果Timer, IO, ADC, PWM。另外它具備一個(gè)軟件系統(tǒng)必須的CPU，Program Flash, RAM等。


在這類微控制器系統(tǒng)上可以進(jìn)行一些基本的任務(wù)調(diào)度，通過定期的產(chǎn)生時(shí)間中斷來觸發(fā)周期性的任務(wù)調(diào)度。任務(wù)包括對(duì)信號(hào)的采集，處理，然后輸出相應(yīng)功能的信號(hào)輸出。





在逐步的發(fā)展中，由多個(gè)解決單體功能的ECU，它們之間需要有信號(hào)的交互，由此衍生出來帶網(wǎng)絡(luò)通信，更復(fù)雜的ECU，他們之間通過網(wǎng)絡(luò)的互聯(lián)，將信號(hào)收集到功能域控制器，以實(shí)現(xiàn)更高級(jí)，智能的車輛功能。


比如車身控制器包含了對(duì)車上所有車身相關(guān)的所有功能，包含有大燈，車窗，雨刮，門鎖等。對(duì)于這類ECU，它軟件的復(fù)雜度相對(duì)較高。





它是基于分層的軟件架構(gòu)。與硬件之間相關(guān)的是硬件驅(qū)動(dòng)層，它稱為MCAL層，是對(duì)硬件的適配層。在這之上是抽象層，它的作用將標(biāo)準(zhǔn)軟件模塊與硬件的不同特性進(jìn)行解耦，以實(shí)現(xiàn)標(biāo)準(zhǔn)化軟件模塊設(shè)計(jì)。在這之上就是典型的系統(tǒng)服務(wù)，內(nèi)存服務(wù)，通信服務(wù)，IO服務(wù)等。


該服務(wù)層提供了控制器基礎(chǔ)的底層軟件功能，它們對(duì)于控制器來說，需求是相對(duì)相似的，ECU模塊之間的軟件復(fù)用性很強(qiáng)，很適合做成標(biāo)準(zhǔn)化，可配置的模塊。這也是汽車軟件標(biāo)準(zhǔn)化的前提。


由于軟件模塊的復(fù)雜度的提升，對(duì)操作系統(tǒng)的要求也相應(yīng)提升，對(duì)操作系統(tǒng)的要求就是需要實(shí)時(shí)性強(qiáng)，任務(wù)調(diào)度管理能力強(qiáng)，并且支持高優(yōu)先級(jí)任務(wù)搶占的操作系統(tǒng)能力。

汽車軟件標(biāo)準(zhǔn)化的開端 OSEK/VDX

OSEK是德文的縮寫：“Offene Systeme und deren Schnittstellen für die Elektronikim Kraftfahrzeug”
VDX代表：“Vehicle Distributed eXecutive”


在更多ECU控制器出現(xiàn)的同時(shí)，每家公司都必須掌握ECU軟件的開發(fā)，如果是獨(dú)立的ECU控制器，則不需要關(guān)注和其他ECU通信協(xié)議兼容的問題。


但實(shí)際情況下，大多數(shù)車輛ECU都需要和其他ECU實(shí)現(xiàn)通信，如果是一個(gè)通信速率不高，信號(hào)數(shù)量不大的ECU，可以采用LIN的通信協(xié)議。如果通信的數(shù)量和速率達(dá)到一定程度，就有必要采用CAN通信協(xié)議。


通常一輛整車，它的零部件是由不同供應(yīng)商去提供的，每個(gè)供應(yīng)商開發(fā)的軟件必須對(duì)外實(shí)現(xiàn)相同的通信協(xié)議以及管理的策略。汽車軟件標(biāo)準(zhǔn)化的開端就是OSEK/VDK. OSEK/VDK是德文首字母的縮寫，OSEK含義是汽車電子開放式系統(tǒng)及其接口，VDX則是汽車分布式運(yùn)行系統(tǒng)

OSEK/VDX 目標(biāo)和動(dòng)機(jī)

動(dòng)機(jī)


OSEK/VDX的動(dòng)機(jī)在于解決ECU基礎(chǔ)與通信部分軟件可以在不同的硬件平臺(tái)上重用，快速的移植到新的硬件平臺(tái)。


解決由于協(xié)議和接口不同造成的各供應(yīng)商的控制器之間不兼容，開放式系統(tǒng)及其接口的好處也體現(xiàn)在軟件質(zhì)量的提升和不同供應(yīng)商合作開發(fā)過程中。


目標(biāo)


提高應(yīng)用層軟件的可移植性和可重用性。


制定標(biāo)準(zhǔn)化的實(shí)時(shí)操作系統(tǒng)RTOS，以及處理器之間的通信用到的通信協(xié)議棧，以及相同行為的網(wǎng)絡(luò)管理策略。


在軟件架構(gòu)層面實(shí)現(xiàn)接口抽象化，應(yīng)用與硬件解耦。


對(duì)于操作系統(tǒng)，通信協(xié)議中與網(wǎng)絡(luò)管理，ECU有差異的部分進(jìn)行配置，比如任務(wù)的配置，通信信號(hào)的配置等，而大多數(shù)的軟件實(shí)現(xiàn)都是靜態(tài)固定的代碼，使得軟件的復(fù)用性和可靠性得到大幅度的提升。同時(shí)要求架構(gòu)具有擴(kuò)展性，方便未來增加新的標(biāo)準(zhǔn)軟件模塊。


下圖描述了工具化實(shí)現(xiàn)OSEK標(biāo)準(zhǔn)模塊的過程，開發(fā)者通過接口描述語(yǔ)言描述功能接口， 通常包含應(yīng)用程序接口，網(wǎng)絡(luò)信號(hào)接口等。接口描述語(yǔ)言和具體的編程語(yǔ)言無關(guān)，但它可以作為一個(gè)標(biāo)準(zhǔn)化的語(yǔ)言對(duì)一個(gè)系統(tǒng)進(jìn)行描述。





這些描述文件可以通過工具進(jìn)行識(shí)別，進(jìn)而生成不同ECU的動(dòng)態(tài)代碼部分，也叫做配置文件。除靜態(tài)代碼和動(dòng)態(tài)代碼部分，一款ECU通常還會(huì)有為專用功能開發(fā)的軟件模塊，以及解決集成問題的粘連代碼模塊，它們合在一起就組成了完整的項(xiàng)目工程，將它們進(jìn)行編譯后，即可生成ECU的可執(zhí)行文件。


以這樣的方式開發(fā)出來的軟件具有良好的應(yīng)用層接口，通信行為，以及系統(tǒng)任務(wù)調(diào)度策略。

OSEK/VDX 主要的規(guī)范

OSEK/VDX主要相關(guān)的規(guī)范有：


OSEK OS（操作系統(tǒng)）


OSEK COM（通訊）


OSEK NM（網(wǎng)絡(luò)管理)

實(shí)時(shí)操作系統(tǒng)（RTOS）

在講OSEK操作系統(tǒng)之前，我們先介紹下什么是實(shí)時(shí)操作系統(tǒng)。


如圖所示，在一個(gè)Event事件發(fā)生后，經(jīng)過一定的延遲后，觸發(fā)相應(yīng)的函數(shù)功能。該函數(shù)的執(zhí)行時(shí)間經(jīng)過嚴(yán)格的計(jì)算，保證在期限時(shí)間內(nèi)能運(yùn)行完成。這就是通常對(duì)一個(gè)實(shí)時(shí)操作系統(tǒng)的定義。





對(duì)這樣一個(gè)操作系統(tǒng)，它需要具備一定的調(diào)度能力，即該系統(tǒng)能夠滿足在任何情況下，在限定時(shí)間內(nèi)完成對(duì)任務(wù)的調(diào)度。


第二是響應(yīng)能力，要求系統(tǒng)具備低延遲響應(yīng)，即使在Worst case下依然能保證這個(gè)性能。


第三就是任務(wù)過載時(shí)的穩(wěn)定性，即使在發(fā)生任務(wù)過重而出現(xiàn)過載，無法滿足在限定時(shí)間內(nèi)完成對(duì)所有任務(wù)的調(diào)度的情況下，仍然可以保證高優(yōu)先級(jí)的任務(wù)得到調(diào)度。

OSEK 操作系統(tǒng)

OSEK操作系統(tǒng)規(guī)范就是基于這些要求而制定的，OSEK操作系統(tǒng)最合適運(yùn)行的硬件環(huán)境就是微處理器，在這類系統(tǒng)中，通常需要實(shí)現(xiàn)的是實(shí)時(shí)要求高的應(yīng)用功能，對(duì)外設(shè)的要求需要有總線控制器，如CAN, LIN, 以及對(duì)數(shù)字輸出端口進(jìn)行操作。


OSEK OS首先定義了標(biāo)準(zhǔn)化的接口。即應(yīng)用軟件和操作系統(tǒng)之間的接口由統(tǒng)一化的操作系統(tǒng)服務(wù)定義，這樣對(duì)于不同的處理器，操作系統(tǒng)對(duì)外的系統(tǒng)服務(wù)都是相同的。


第二就是可擴(kuò)展性，OSEK OS定義了多種不同的調(diào)度機(jī)制，不同的RTOS能力分類，使得它適用于各種應(yīng)用程序和硬件。


第三錯(cuò)誤檢查，提供開發(fā)階段和生產(chǎn)階段所需的錯(cuò)誤檢查的處理。第三就是應(yīng)用軟件的可移植性，這就是OSEK的主要目標(biāo)之一

OSEK Conformance Classes

OSEK支持多級(jí)RTOS能力等級(jí)劃分，稱為”Conformance Classes”。


主要由三個(gè)方面去描述RTOS能力等級(jí)，第一個(gè)是任務(wù)的類別，分基礎(chǔ)任務(wù)和擴(kuò)展任務(wù)，它們之間的區(qū)別在于基礎(chǔ)任務(wù)沒有等待狀態(tài)，而擴(kuò)展任務(wù)允許有等待狀態(tài)。
第二個(gè)差別在于多任務(wù)的激活，第三點(diǎn)是具有優(yōu)先級(jí)的多任務(wù)調(diào)度。


從這三個(gè)能力角度，組合成了4種Conformance Classess, BCC1， BCC2, ECC1，還有ECC2。如下圖所示，從RTOS能力上來說，ECC2是具備最高等級(jí)的。

OSEK 相關(guān)術(shù)語(yǔ)

在OSEK OS標(biāo)準(zhǔn)中，有一些常用的術(shù)語(yǔ)：


Tasks
Scheduling
Interrupt
Resources
Alarms&Counters
Event
Hook Routines
System Services


下圖展示的是任務(wù)的狀態(tài)轉(zhuǎn)換示意圖。

OSEK 通信

第二個(gè)主要的OSEK標(biāo)準(zhǔn)是OSEK COM。對(duì)于一個(gè)典型的網(wǎng)絡(luò)，對(duì)照參考模型，可以劃分為7層。


OSEK COM主要實(shí)現(xiàn)了網(wǎng)絡(luò)層，和數(shù)據(jù)鏈路層的標(biāo)準(zhǔn)實(shí)現(xiàn)。OSEK COM在總線通信硬件上設(shè)計(jì)了標(biāo)準(zhǔn)的設(shè)計(jì)驅(qū)動(dòng)接口，網(wǎng)絡(luò)層實(shí)現(xiàn)了標(biāo)準(zhǔn)的總線協(xié)議，同時(shí)對(duì)上層應(yīng)用也提供了標(biāo)準(zhǔn)的應(yīng)用程序接口。這樣設(shè)計(jì)的目的在于為汽車控制器應(yīng)用軟件提供統(tǒng)一的通信環(huán)境，好處是提升了應(yīng)用軟件的可移植性。





從圖中可以看出，OSEK COM和OSEK NM，OSEK OS有著依賴關(guān)系，它們之間需同時(shí)配合，以實(shí)現(xiàn)ECU的通信功能。

OSEK 網(wǎng)絡(luò)管理

對(duì)于一個(gè)帶網(wǎng)絡(luò)通信的ECU，網(wǎng)絡(luò)管理是十分重要的，直接影響到整車的使用體驗(yàn)，網(wǎng)絡(luò)管理如果出現(xiàn)故障，可直接引起車輛無法啟動(dòng)，整車無法休眠等問題。


OSEK網(wǎng)絡(luò)管理能有效的管理參與網(wǎng)絡(luò)的各個(gè)ECU的喚醒和睡眠。該協(xié)議主要定義了網(wǎng)絡(luò)管理報(bào)文，報(bào)文定義了每個(gè)ECU的狀態(tài)，以及睡眠，喚醒意圖的標(biāo)識(shí)位。


在建立通信的過程，相當(dāng)于建立起環(huán)狀的通信鏈路。同時(shí)考慮到某個(gè)ECU點(diǎn)可能會(huì)發(fā)生故障而不能繼續(xù)參與網(wǎng)絡(luò)通信，它也可以識(shí)別出這種異常狀態(tài)，并且由剩余的ECU，重新建立起環(huán)狀的通信鏈路。


網(wǎng)絡(luò)管理的目的和職責(zé)如圖所示，如激活通信硬件，同步網(wǎng)絡(luò)節(jié)點(diǎn)同步轉(zhuǎn)換到睡眠狀態(tài)等，同時(shí)對(duì)網(wǎng)絡(luò)進(jìn)行診斷，網(wǎng)絡(luò)出現(xiàn)錯(cuò)誤后進(jìn)行恢復(fù)等。

汽車開放系統(tǒng)架構(gòu) AUTOSAR

OSEK/VDX是一個(gè)汽車軟件標(biāo)準(zhǔn)化的開端，而進(jìn)一步將汽車軟件標(biāo)準(zhǔn)化的就是AUTOSAR。AUTOSAR已經(jīng)廣泛運(yùn)用在主流的ECU控制器軟件中。


AUTOSAR和OSEK/VDX的關(guān)系相當(dāng)于， AUTOSAR是OSEK/VDX的繼承和發(fā)展，從很多AUTOSAR的標(biāo)準(zhǔn)文檔中，我們可以看到它借鑒了OSEK的協(xié)議標(biāo)準(zhǔn)，比如AUTOSAR OS和OSEK OS很多概念都是一致的。


當(dāng)然AUTOSAR增加了很多新特性，比如Schedule Table, 時(shí)間同步，棧監(jiān)控，內(nèi)存保護(hù)等機(jī)制。AUTOSAR的引入在于OSEK定義的標(biāo)準(zhǔn)模塊，僅包含OS, COM, NM，但一個(gè)完整的ECU軟件組件還包括內(nèi)存的處理，標(biāo)準(zhǔn)的外設(shè)處理等，進(jìn)一步將這些軟件模塊進(jìn)行標(biāo)準(zhǔn)化的詳細(xì)設(shè)計(jì)也是很有必要的。


AUTOSAR除了分層軟件架構(gòu)體系，詳細(xì)模塊組件設(shè)計(jì)之外，另一重要的概念是提供了一整套應(yīng)用程序開發(fā)的方法論。


該方法論從元模型開始，制定了每個(gè)環(huán)節(jié)需要的工作內(nèi)容，輸出文件以及產(chǎn)出文件，中間的交互文件和格式也有具體的定義，例如arxml為載體的交互文件。對(duì)于系統(tǒng)建模工具，需要有專門的編輯工具，ECU的底層功能由配置工具去做相應(yīng)的配置，進(jìn)而生成相應(yīng)的執(zhí)行代碼。


所有的這些工作都是為了實(shí)現(xiàn)這些目標(biāo)：為了應(yīng)對(duì)數(shù)量日益增多且功能復(fù)雜的汽車ECU，同時(shí)要改善每家ECU控制器供應(yīng)商各自開發(fā)軟件而造成的軟件質(zhì)量參差不齊，并且難以有效開展合作的問題。


由于可以購(gòu)買到第三方軟件公司提供的基礎(chǔ)軟件模塊，可以縮短產(chǎn)品研發(fā)時(shí)間，更快的推向市場(chǎng)。而可拓展的分層軟件架構(gòu)可以提供靈活多變的解決方案，適應(yīng)不同控制器的軟件要求。

AUTOSAR 方法論

AUTOSAR的方法論總體設(shè)計(jì)開發(fā)分為三個(gè)步驟，系統(tǒng)配置，ECU設(shè)計(jì)與配置，代碼生成。


首先由整車廠完成整個(gè)功能架構(gòu)，系統(tǒng)架構(gòu)，軟件架構(gòu)，并且定義總線的拓?fù)浣Y(jié)構(gòu)，以及信號(hào)列表。軟件組件框架包含每個(gè)軟件組件之間的交互關(guān)系，運(yùn)行實(shí)體等要素。之后將軟件組件按功能分配給ECU硬件。


在完成這些設(shè)計(jì)后，系統(tǒng)描述文件包含了每一個(gè)ECU軟件框架描述，并且包含了每個(gè)ECU的系統(tǒng)信號(hào)。這些描述文件將分發(fā)給ECU開發(fā)商去完成每個(gè)ECU具體底層功能配置并生成相應(yīng)的BSW代碼，同時(shí)還需開發(fā)應(yīng)用軟件的行為模型及代碼。


RTE是虛擬功能總線在具體ECU上的實(shí)現(xiàn)，它承擔(dān)著在ECU內(nèi)運(yùn)行的應(yīng)用層軟件組件之間互相通信，以及應(yīng)用軟件向通信協(xié)議棧發(fā)送總線信號(hào)的作用。

Classic AUTOSAR 軟件架構(gòu)

這張圖就是大家都很熟悉的CP AUTOSAR的軟件架構(gòu)。包含了微控制器抽象層，ECU抽象層，服務(wù)層，還有復(fù)雜驅(qū)動(dòng)層，RTE將底層軟件和上層應(yīng)用軟件組件分開，提供虛擬總線實(shí)時(shí)運(yùn)行環(huán)境。


例如應(yīng)用程序要向總線上發(fā)送一個(gè)總線信號(hào)，典型的處理過程是首先通過RTE把信號(hào)傳給COM通信模塊, 它屬于通信服務(wù)層。通信硬件抽象層的作用是將不同類型的網(wǎng)絡(luò)通信進(jìn)行抽象，使得上層的處理不需要關(guān)心底下具體是以哪些類型的網(wǎng)絡(luò)發(fā)送數(shù)據(jù)。


通信驅(qū)動(dòng)層的作用是使上層模塊可以更方便的使用硬件設(shè)備，比如用簡(jiǎn)單的API去操作發(fā)送或接受一個(gè)CAN信號(hào)，具體對(duì)硬件的處理操作由驅(qū)動(dòng)去完成。微控制器抽象層的作用就是解決不同微控制器廠商硬件設(shè)計(jì)的差異，使得驅(qū)動(dòng)層可以統(tǒng)一標(biāo)準(zhǔn)化設(shè)計(jì)。

汽車軟件架構(gòu)的發(fā)展趨勢(shì)

對(duì)于汽車軟件架構(gòu)未來的發(fā)展趨勢(shì)，有以下幾個(gè)方面。
第一是面向服務(wù)的軟件架構(gòu)變化，服務(wù)架構(gòu)的轉(zhuǎn)型需要將當(dāng)前基于信號(hào)的軟件設(shè)計(jì)進(jìn)行重構(gòu)，使得功能的調(diào)用更符合服務(wù)化的通信框架。


第二，中央計(jì)算+區(qū)域控制分布式遠(yuǎn)程調(diào)用框架RPC。當(dāng)前適用車內(nèi)使用的RPC就是SOME/IP，它可以在運(yùn)行CP AUTOSAR的實(shí)時(shí)控制器上使用，也可以在運(yùn)行AP AUTOSAR的高性能SOC上使用，是兩個(gè)不同平臺(tái)進(jìn)行通信的紐帶。


第三，高算力SoC軟件架構(gòu)也是重要的發(fā)展方向，傳統(tǒng)功能上移到中央計(jì)算單元，計(jì)算集中化是未來的電子電氣架構(gòu)趨勢(shì)。也對(duì)高算力SoC的軟件架構(gòu)提出更高的要求。


同時(shí)這樣的軟件架構(gòu)還涉及到一個(gè)新的概念，混合關(guān)鍵性軟件系統(tǒng)，即在一個(gè)SoC系統(tǒng)上同時(shí)運(yùn)行不同安全等級(jí)的軟件系統(tǒng)，這對(duì)軟硬件隔離技術(shù)，虛擬化技術(shù)都是新的考驗(yàn)。另外云端，車端，以及基礎(chǔ)設(shè)施的功能協(xié)同等也是發(fā)展的新趨勢(shì)。


對(duì)于前面講的未來的汽車軟件發(fā)展趨勢(shì)，當(dāng)前比較推薦的方案就是AP AUTOSAR。設(shè)計(jì)AP AUTOSAR的初衷就是該平臺(tái)應(yīng)具備一定的實(shí)時(shí)性，高可靠性，同時(shí)適合運(yùn)行高性能軟件算法的應(yīng)用場(chǎng)景。另外該平臺(tái)具備一點(diǎn)的靈活性，可以動(dòng)態(tài)的加載車輛應(yīng)用功能。





AP AUTOSAR的功能組件。其核心組件ARA COM提供了服務(wù)化的通信功能，自適應(yīng)應(yīng)用程序AA之間的通信通過ARA COM來完成。屬于Services類型的模塊包括升級(jí)和配置管理UCM，提供FOTA, SOTA的功能支持。


Security Management提供和信息安全相關(guān)的服務(wù)，Diagnostics則提供和診斷相關(guān)的功能入口。其他API組件，提供了時(shí)間管理，執(zhí)行管理，Persistency，健康管理等，都是必須的平臺(tái)中間件軟件。


AP AUTOSAR的興起源于當(dāng)前對(duì)高性能SoC系統(tǒng)的應(yīng)用需求，在一個(gè)完整的汽車汽車電子電器架構(gòu)中，因?yàn)槊總€(gè)ECU都有其特殊的應(yīng)用需求，所以AP AUTOSAR, CP AUTOSAR, 以及非AUTOSAR的ECU將是同時(shí)存在的，都扮演者重要的角色。


在AP AUTOSAR發(fā)展的同時(shí)，CP AUTOSAR也在繼續(xù)升級(jí)新增新的模塊，以適應(yīng)新的需求。


當(dāng)然，除此之外，未來汽車電子軟件中人工智能技術(shù)也是一大應(yīng)用。汽車電子也會(huì)跟其他行業(yè)會(huì)有更多的交集，也會(huì)引入其他行業(yè)的很多技術(shù)，如IEEE制定的相關(guān)標(biāo)準(zhǔn)；跟OPC UA結(jié)合以解決TSN的問題，機(jī)器領(lǐng)域的ROS，以及已經(jīng)在航空航天中使用的到的光纖通信技術(shù)等。


汽車電子軟件未來發(fā)展如何，讓我們拭目以待吧！

本期分享就到這里，進(jìn)群、工具鏈評(píng)估、培訓(xùn)、集成等其他問題，也可以隨時(shí)與我們聯(lián)系。

聯(lián)系我們

微信：shactiontech
郵箱：support@shactiontech.com

總結(jié)

以上是生活随笔為你收集整理的搞一下新架构下的软件技术 | 12 汽车电子软件的过去与未来的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。