AUTOSAR的軟件架構(gòu)

概述

本文主要內(nèi)容分為兩章節(jié)。第一章節(jié)簡要介紹了AUTOSAR的軟件架構(gòu)，設(shè)計(jì)理念以及方法論，對Classic Platform和Adaptive Platform做了簡單的比較。第二章主要介紹了Adaptive Platform的特性。

第一章 AUTOSAR架構(gòu)介紹

AUTOSAR(AUTomotive Open System ARchitecture)是汽車和軟件行業(yè)領(lǐng)先公司的全球合作聯(lián)盟，為智能移動開發(fā)和建立標(biāo)準(zhǔn)化的軟件框架以及開放的E/E系統(tǒng)架構(gòu)?？紤]到目前和未來市場中不同的汽車E/E架構(gòu)，AUTOSAR聯(lián)盟為汽車軟件架構(gòu)建立了開放的行業(yè)標(biāo)準(zhǔn)。因此AUTOSAR有兩種含義，一是代表AUTOSAR聯(lián)盟，二是代表AUTOSAR軟件架構(gòu)。

AUTOSAR基本原理

相比傳統(tǒng)軟件架構(gòu)，AUTOSAR在上層軟件和底層硬件平臺之間嵌入標(biāo)準(zhǔn)的中間層，實(shí)現(xiàn)了軟硬件的解耦。AUTOSAR的口號是標(biāo)準(zhǔn)上協(xié)作，實(shí)現(xiàn)上競爭。 通過軟硬件解耦，縮短研發(fā)周期和降低研發(fā)成本，同時通過軟件的復(fù)用提供研發(fā)質(zhì)量和效率。由于有統(tǒng)一的標(biāo)準(zhǔn)（軟件接口，文件交換格式，方法論），因此OEM、供應(yīng)商、工具提供商等可以協(xié)同開發(fā)，簡化軟件系統(tǒng)的集成，軟件模塊可以復(fù)用和高效率的衍生，提高了研發(fā)效率，降低整體軟件的研發(fā)成本。

基本的AUTOSAR方法

下圖是簡化版的AUTOSAR開發(fā)工作流。AUTOSAR將應(yīng)用軟件和硬件平臺進(jìn)行解耦，在應(yīng)用軟件和基礎(chǔ)軟件與硬件之間嵌入虛擬功能總線，應(yīng)用之間的通信或者訪問硬件資源等都是通過虛擬功能總線進(jìn)行資源交換。在Classic Platform中虛擬功能總線為RTE層，在Adaptive Platform中虛擬功能總線為ARA層。由于AUTOSAR采用自上而下的方法論，從架構(gòu)設(shè)計(jì)、接口描述，軟件開發(fā)，功能組件集成都是采用模型開發(fā)。因此可以使用代碼生成工具，將SWC描述文件、ECU描述文件、系統(tǒng)約束文件等導(dǎo)入工具后可以生成可執(zhí)行代碼。

未來的汽車產(chǎn)業(yè)挑戰(zhàn)

2003年，汽車行業(yè)的高端玩家們發(fā)起了汽車嵌入式系統(tǒng)軟件架構(gòu)標(biāo)準(zhǔn)化項(xiàng)目——AUTOSAR(汽車開放系統(tǒng)架構(gòu))。2017年，為適應(yīng)汽車的發(fā)展趨勢（智能化，網(wǎng)聯(lián)化等），應(yīng)對汽車E/E系統(tǒng)開發(fā)面臨的新的挑戰(zhàn)（高性能處理器的應(yīng)用，自動駕駛軟件的實(shí)現(xiàn)，高帶寬通信的需求，車與外界的互聯(lián)互通，汽車E/E架構(gòu)的演變等），AUTOSAR組織推出了AUTOSAR Adaptive Platform。

AUTOSAR的愿景和目標(biāo)

AUTOSAR架構(gòu)的特點(diǎn)

AUTOSAR 軟件架構(gòu)

Foundation

Foundation是Classic Platform和Adaptive Platform公共的部分，比如總線協(xié)議，方法論等

Classic Platform

CP平臺是為硬實(shí)時和安全要求嚴(yán)格的嵌入式系統(tǒng)的提出的AUTOSAR解決方案。

Adaptive Platform

AP平臺是為高性能計(jì)算的ECU提出的解決辦法，用于自動駕駛等。

Acceptance Tests

AUTOSAR驗(yàn)收測試是總線級和應(yīng)用程序級的系統(tǒng)測試，用于驗(yàn)證與應(yīng)用軟件組件和通信總線相關(guān)的AUTOSAR堆棧的行為

Acceptance Interface

AUTOSAR根據(jù)語法和語義為以下五個汽車領(lǐng)域標(biāo)準(zhǔn)化了大量的應(yīng)用接口:車身和舒適性、動力總成發(fā)動機(jī)、動力總成傳動系統(tǒng)、底盤控制以及乘員和行人安全。

AUTOSAR Classic Platform架構(gòu)

Classic AUTOSAR將微控制器上的軟件抽象為三個軟件層：應(yīng)用程序、運(yùn)行時環(huán)境(RTE)和基本軟件(BSW)。其中BSW分為三個主要層：服務(wù)層、ECU抽象層和微控制器抽象層。應(yīng)用與應(yīng)用之間，以及應(yīng)用于BSW之間的通信都是經(jīng)過RTE完成數(shù)據(jù)交換，因此做到了應(yīng)用與硬件的完全獨(dú)立。 Classic AUTOSAR是分層軟件體系結(jié)構(gòu)，軟件需求在設(shè)計(jì)時通過每一層的靜態(tài)配置來實(shí)現(xiàn)。因此，對于運(yùn)行時的更改，它的靈活性較低，但是這點(diǎn)還是可以接受的，因?yàn)檫@個平臺通常在車輛的生命周期內(nèi)保持穩(wěn)定，因?yàn)楸豢刂频?a href="http://wenjunhu.com/v/tag/117/" target="_blank">傳感器和執(zhí)行器的應(yīng)用邏輯不會改變，傳感器和執(zhí)行器仍然履行它們本身的功能。關(guān)注公號-車端

VECTOR Classic AUTOSAR架構(gòu)

AUTOSAR Adaptive Platform架構(gòu)

Adaptive AUTOSAR平臺為AUTOSAR應(yīng)用實(shí)現(xiàn)了運(yùn)行環(huán)境ARA。使用兩種接口完成數(shù)據(jù)交換：服務(wù)和API。平臺由功能集群組成，這些集群按服務(wù)和自適應(yīng)AUTOSAR基礎(chǔ)進(jìn)行分組如下。 Adaptive AUTOSAR解決了新一代汽車高性能需求、連接性和持續(xù)軟件無線(OTA)更新帶來的新市場需求，它作為多個供應(yīng)商的軟件集成平臺，解決了Classic AUTOSAR經(jīng)典架構(gòu)的局限性，其為靈活性而設(shè)計(jì)的，以便在運(yùn)行時支持軟件更改。Adaptive AUTOSAR構(gòu)建在POSIX操作系統(tǒng)之上，由不同的功能模塊組成，這些模塊被劃分在服務(wù)模塊和基礎(chǔ)模塊上,它的的通信是面向服務(wù)類型的，會將網(wǎng)絡(luò)綁定到DDS或者SOME/IP使用以太網(wǎng)與其它ECU通信。

Adaptive Platform邏輯視圖

VECTOR Adaptive AUTOSAR架構(gòu)

AP與CP架構(gòu)比較

AUTOSAR CP平臺與AP平臺特性比較

綜上，AUTOSAR包含了Classic Platform和Adaptive Platfrom。Adaptive Platform并不是用來取代Classic Platform或者非AUTOSAR平臺，而是為了相互兼容，協(xié)作并滿足未來的需求。

第二章 Adaptive AUTOSAR特性介紹

技術(shù)范圍和方法

智能ECU

現(xiàn)在的ECU的主要功能實(shí)現(xiàn)都是為了增強(qiáng)或者取代電子機(jī)械系統(tǒng)，所以現(xiàn)在的電子電器架構(gòu)很多都采用線控系統(tǒng)。ECU內(nèi)部的嵌入式軟件根據(jù)輸入的信號或者來自于車載網(wǎng)絡(luò)的其他ECU的信息控制輸出信號。許多軟件是根據(jù)目標(biāo)車輛設(shè)計(jì)和實(shí)現(xiàn)，在車輛的生命周期中不會發(fā)生根本性的變化。 未來的車輛功能，比如高級自動駕駛，會使得軟件變得非常復(fù)雜且需要很高的算力，并且要滿足嚴(yán)格的集成性和安全需要。這些軟件實(shí)現(xiàn)了環(huán)境感知、行為規(guī)劃等功能，并將車輛集成到外部后端和基礎(chǔ)設(shè)施系統(tǒng)中。由于外部系統(tǒng)的發(fā)展或功能的改進(jìn)，在車輛的生命周期中，車輛中的軟件需要更改。正是由于這些需要，現(xiàn)在越來越多的車輛支持OTA功能，OTA功能就像我們使用手機(jī)一樣，可以借助空中升級功能不斷更新軟件功能。功能的更新可能是修復(fù)一個BUG，或是增加一個功能，又或是增強(qiáng)一個性能等等，這種變化使能車輛具有不斷升級的能力，也賦予了用戶與車輛更多的粘性。 由于AUTOSAR Classic Platform(CP)標(biāo)準(zhǔn)不能完全解決以上需求，因此，AUTOSAR組織提出了AP平臺的標(biāo)準(zhǔn)，AP平臺主要提供了高性能的計(jì)算和通信機(jī)制以及靈活的軟件配置，例如支持OTA軟件升級。

技術(shù)驅(qū)動

技術(shù)驅(qū)動主要有兩個方面，一個是以太網(wǎng)，另一個是處理器。 日益增長的車輛網(wǎng)絡(luò)帶寬需求幫助以太網(wǎng)應(yīng)用在汽車網(wǎng)絡(luò)通信中，其提供了更高的帶寬和交換網(wǎng)絡(luò)，相比傳統(tǒng)的車載通信總線，例如CAN總線，其帶來了長消息的有效傳遞和點(diǎn)對點(diǎn)的通信。雖然CP也支持以太網(wǎng)通信，但主要是為傳統(tǒng)通信技術(shù)設(shè)計(jì)和優(yōu)化的，因此也是很難充分利于以太網(wǎng)的通信能力。關(guān)注公號-車端 類似的，隨著汽車功能越來越復(fù)雜，對于處理器的處理能力的需要也是逐年劇增。雖然多核處理器已經(jīng)能夠應(yīng)用在CP平臺，但是有些應(yīng)用需要成百上千的多核處理器，比如GPU，專用加速器等應(yīng)用相比傳統(tǒng)MCU來說能夠提供更高的性能。CP平臺曾經(jīng)是為了單核處理器設(shè)計(jì)，雖然現(xiàn)在也支持多核，但計(jì)算的最佳性能往往需要結(jié)合不同的計(jì)算資源，比如多核，協(xié)處理器，GPU，FPGA和加速器等。這種混合方式被稱為異構(gòu)計(jì)算，其能力遠(yuǎn)遠(yuǎn)超過了CP。

AP特性

AP包含的特性來自于未來的智能ECU和技術(shù)驅(qū)動兩個方面。高性能的計(jì)算滿足了安全的需要同時也需要很高的能耗，因此帶來了許多新的挑戰(zhàn)。為了應(yīng)對這些挑戰(zhàn)，AP采用了很多傳統(tǒng)ECU未充分利用的技術(shù)。有如下幾個方面 C++ Adaptive AUTOSAR平臺的應(yīng)用都將采用C++編程。雖然C語言是嵌入式系統(tǒng)的主要編程語言，具有執(zhí)行速度快、效率高的特點(diǎn)；但是在性能要求非常高的復(fù)雜應(yīng)用和算法開發(fā)上（如機(jī)器學(xué)習(xí)、圖像特征識別等）具有面向?qū)ο筇匦缘腃++顯然比C更具有優(yōu)勢。C++能夠提供算法開發(fā)和性能均衡的軟件。并且方便很快地適配和量產(chǎn)開發(fā)。 SOA 為了支持復(fù)雜的應(yīng)用程序，同時在處理分布和計(jì)算資源分配方面允許最大的靈活性和可伸縮性，AP遵循SOA(service-oriented-architecture)的架構(gòu)。SOA主要基于以下概念：系統(tǒng)由一組服務(wù)構(gòu)成，其中 一個可使用另外一個的服務(wù)，應(yīng)用程序可根據(jù)自己的需要使用一個或者多個服務(wù)；此外服務(wù)可以在應(yīng)用程序運(yùn)行的本地ECU上，也可以運(yùn)行在另一個AP實(shí)例的遠(yuǎn)程ECU上。關(guān)于什么是SOA，目前還沒有明確的結(jié)論。

官網(wǎng)：Scalable service-Oriented MiddlewarE over IP (SOME/IP) (some-ip.com)

? 并行處理能力 分布式計(jì)算本質(zhì)是并行的。先進(jìn)的多核異構(gòu)處理器既具有強(qiáng)大的計(jì)算能力也能為并行計(jì)算提供技術(shù)支持，隨著多核異構(gòu)計(jì)算技術(shù)的發(fā)展，AP具有擴(kuò)展其功能和性能架構(gòu)的能力。事實(shí)上，硬件和接口規(guī)范僅是實(shí)現(xiàn)AP的一部分，在OS等技術(shù)和開發(fā)工具的發(fā)展上對實(shí)現(xiàn)AP的應(yīng)用也至關(guān)重要。 利用現(xiàn)有標(biāo)準(zhǔn) 重新發(fā)明輪子是沒有意義的，尤其在規(guī)范方面。正如已經(jīng)在c++中描述的那樣，AP采取了重用和適應(yīng)現(xiàn)有開放標(biāo)準(zhǔn)的策略，以促進(jìn)AP自身的更快發(fā)展，并從現(xiàn)有標(biāo)準(zhǔn)的生態(tài)系統(tǒng)中受益。因此，開發(fā)AP規(guī)范的一個關(guān)鍵重點(diǎn)是不要隨意引入現(xiàn)有標(biāo)準(zhǔn)已經(jīng)提供的新替代功能。例如，這意味著不會僅僅因?yàn)楝F(xiàn)有標(biāo)準(zhǔn)提供了所需的功能，但接口表面上不容易理解，就隨意引入新的接口。 安全性 AP所針對的系統(tǒng)通常需要某種級別的安全性，可能是最高級別的安全性。新概念和技術(shù)的引入不應(yīng)破壞這些需求，盡管實(shí)現(xiàn)這些需求并非易事。為了應(yīng)對這一挑戰(zhàn)，AP結(jié)合了體系結(jié)構(gòu)、功能和過程方法。該架構(gòu)基于基于SOA的分布式計(jì)算，這使得每個組件更加獨(dú)立，避免了意想不到的干擾，具有專門的功能來幫助實(shí)現(xiàn)安全和保障，以及諸如c++編碼指南之類的指導(dǎo)方針，它促進(jìn)了像c++這樣的復(fù)雜語言的安全使用。 動態(tài)計(jì)劃 AP支持應(yīng)用程序的動態(tài)部署，動態(tài)地管理資源和通信，以減少軟件開發(fā)和集成的工作量，從而縮短迭代周期。在AP架構(gòu)下，不同的應(yīng)用可能由不同的供應(yīng)商提供，因此在產(chǎn)品交付階段，AP允許系統(tǒng)集成商合理限制這種動態(tài)部署的特性以降低不必要的風(fēng)險(xiǎn)和影響。 敏捷 敏捷盡管沒有直接反映在平臺功能中，AP的目標(biāo)是適應(yīng)不同的產(chǎn)品開發(fā)過程，特別是基于敏捷的過程。對于基于敏捷的開發(fā)，至關(guān)重要的是系統(tǒng)的底層架構(gòu)是可增量擴(kuò)展的，在部署后可以更新系統(tǒng)。AP的體系結(jié)構(gòu)應(yīng)該允許這樣做。作為概念的證明，AP規(guī)范本身和演示者(AP的演示實(shí)現(xiàn))都是用Scrum[^1]開發(fā)的。 [^1]: Scrum是迭代式增量軟件開發(fā)過程，通常用于敏捷軟件開發(fā)。Scrum包括了一系列實(shí)踐和預(yù)定義角色的過程骨架。Scrum中的主要角色包括同項(xiàng)目經(jīng)理類似的Scrum主管角色負(fù)責(zé)維護(hù)過程和任務(wù)，產(chǎn)品負(fù)責(zé)人代表利益所有者，開發(fā)團(tuán)隊(duì)包括了所有開發(fā)人員。雖然Scrum是為管理軟件開發(fā)項(xiàng)目而開發(fā)的，它同樣可以用于運(yùn)行軟件維護(hù)團(tuán)隊(duì)，或者作為計(jì)劃管理方法：Scrum of Scrums. [1]

CP、AP和非AUTOSAR ECU的集成

綜合以上的介紹，AP不會替代CP或者非AUTOSAR的平臺。而是與這些平臺以及外部后端系統(tǒng)(如路邊基礎(chǔ)設(shè)施)交互，形成一個完整的系統(tǒng)(圖2-1不同平臺部署示例、圖2-2 AP與CP交互示例)。例如，CP已經(jīng)包含了一些SOME/IP協(xié)議，AP也支持這些協(xié)議。

架構(gòu)

我們將從邏輯視圖，物理視圖以及方法論三個方面了解自適應(yīng)平臺的架構(gòu)。

邏輯視圖

ARA 下圖表示AP的架構(gòu)，其中Adaptive Application(自適應(yīng)應(yīng)用)運(yùn)行在ARA(AUTOSAR自適應(yīng)應(yīng)用的運(yùn)行環(huán)境)之上。ARA是應(yīng)用程序（AP中稱為Adaptive Application）運(yùn)行時的基礎(chǔ)環(huán)境，可以提供多種本地功能供應(yīng)用程序調(diào)用，這些本地功能在AP中統(tǒng)稱為Function Clusters，其分為兩個部分：Foundation Function Clusters和Service Function Clusters。 ? 語言綁定，C++標(biāo)準(zhǔn)庫，以及POSIX接口 這些API的語言基于C++綁定的，C++標(biāo)準(zhǔn)庫也可以作為ARA的一部分使用。關(guān)于OS接口，只有POSIX標(biāo)準(zhǔn)的單進(jìn)程概要文件(PSE51接口)作為ARA的一部分可用。選擇PSE51是為了為現(xiàn)有的POSIX應(yīng)用程序提供可移植性，并實(shí)現(xiàn)應(yīng)用程序之間的自由干擾。 C++標(biāo)準(zhǔn)庫包含許多基于POSIX的接口，也包括多線程接口。 應(yīng)用啟動和關(guān)閉 由Execution Management(EM)管理應(yīng)用的生命周期。應(yīng)用程序的加載/啟動是通過使用EM的功能來管理的，它需要在系統(tǒng)集成時或運(yùn)行時進(jìn)行適當(dāng)?shù)呐渲貌拍軉討?yīng)用程序。下圖說明了不同類型的AP應(yīng)用。 ? 應(yīng)用交互 對于AAs之間的交互，PSE51沒有包含IPC (Inter-Process- Communication)，所以在AAs之間沒有直接的交互接口。通信管理(CM)是唯一的顯式接口。CM還為ECU內(nèi)外部提供面向服務(wù)的通信。CM處理服務(wù)請求/響應(yīng)的路由，而不管服務(wù)和客戶端應(yīng)用程序的拓?fù)洳渴稹? ? 非標(biāo)準(zhǔn)接口 AA和功能集群可以使用任何非標(biāo)準(zhǔn)接口，只要它們不與標(biāo)準(zhǔn)AP功能沖突，并且符合項(xiàng)目的安全性/安全性要求。除非它們是純粹的應(yīng)用程序本地運(yùn)行時庫，否則應(yīng)該注意盡量減少這種使用，因?yàn)檫@將影響軟件對其他AP實(shí)現(xiàn)的可移植性。

物理視圖

OS，處理器，和線程 AP操作系統(tǒng)要提供多進(jìn)程 POSIX OS的兼容性。每一個AA實(shí)現(xiàn)為一個獨(dú)立的進(jìn)程。自適應(yīng)平臺服務(wù)和非平臺服務(wù)也實(shí)現(xiàn)為進(jìn)程。 進(jìn)程可以是一個單線程或多線程進(jìn)程?？梢允褂肙S API根據(jù)進(jìn)程所屬的邏輯層而有所不同。如果它們是運(yùn)行在ARA之上的AAs，那么它們應(yīng)該只使用PSE51。如果一個進(jìn)程是功能集群之一，它可以自由使用任何可用的操作系統(tǒng)接口。 AA進(jìn)程不能直接使用IPC，只能通過ARA進(jìn)行通信。其他進(jìn)程可以通過IPC或任何其他可用的OS功能相互交互。 基于庫或基于服務(wù)的功能集群的實(shí)現(xiàn) 在圖3-1 AP架構(gòu)邏輯視圖中，功能集群可以是自適應(yīng)平臺基礎(chǔ)模塊，也可以是自適應(yīng)平臺服務(wù)。如前所述，這兩個過程通常都有。為了與同樣是進(jìn)程的AAs進(jìn)行交互，它們需要使用IPC。有兩種替代設(shè)計(jì)可以實(shí)現(xiàn)這一點(diǎn)。一種是基于庫的設(shè)計(jì)，由功能集群提供的接口庫鏈接到AA，直接調(diào)用IPC。另一種是基于服務(wù)的設(shè)計(jì)，流程使用通信管理功能，并有一個服務(wù)器代理庫鏈接到AA。代理庫調(diào)用通信管理接口，協(xié)調(diào)AA進(jìn)程和Server進(jìn)程之間的IPC。注意，它是由實(shí)現(xiàn)定義的，AA是否只直接執(zhí)行IPC與通信管理或混合直接IPC與服務(wù)器通過代理庫。為功能集群選擇設(shè)計(jì)的一般原則是，如果它只在AP實(shí)例中本地使用，那么基于庫的設(shè)計(jì)更合適，因?yàn)樗唵?，也更高效。如果它以分布式方式從其他AP實(shí)例中使用，建議采用基于服務(wù)的設(shè)計(jì)，因?yàn)橥ㄐ殴芾硖峁┩该鞯耐ㄐ?，而不考慮客戶端AA和服務(wù)的位置。自適應(yīng)平臺基礎(chǔ)的功能集群是基于庫的，自適應(yīng)平臺服務(wù)的功能集群是基于服務(wù)的。最后，需要注意的是，一個功能集群的實(shí)現(xiàn)可以沒有進(jìn)程，而是以庫的形式實(shí)現(xiàn)，在AA進(jìn)程的上下文中運(yùn)行，只要它滿足功能集群定義的需求規(guī)范和軟件規(guī)范。在這種情況下，AA和功能集群之間的交互將是常規(guī)的過程調(diào)用，而不是像前面描述的那樣基于IPC。 功能集群間的交互 通常，功能集群可以以AP實(shí)現(xiàn)的特定方式相互交互，因?yàn)樗鼈儧]有綁定到ARA接口，比如限制IPC使用的PSE51。它可能確實(shí)使用了其他功能集群的ARA接口，這些接口是公共接口。功能集群之間的一個典型交互模型是使用功能集群的受保護(hù)接口來提供實(shí)現(xiàn)功能集群的特殊功能所需的特權(quán)訪問。 機(jī)器/硬件 AP將其運(yùn)行的硬件視為機(jī)器。背后的基本原理是，硬件可以使用各種與hypervisor相關(guān)的技術(shù)進(jìn)行虛擬化，并實(shí)現(xiàn)一致的平臺視圖。在硬件上，可以有一個或多個機(jī)器，并且在一臺機(jī)器上只能運(yùn)行一個AP實(shí)例。通常假定該硬件包括一個芯片，托管一個或多個機(jī)器。但是，如果AP實(shí)現(xiàn)允許的話，多個芯片也可以組成一個機(jī)器。

方法論和清單

為了支持功能應(yīng)用程序的分布式、獨(dú)立和敏捷開發(fā)，需要在開發(fā)方法上采用標(biāo)準(zhǔn)化的方法。AUTOSAR自適應(yīng)方法涉及到工作產(chǎn)品的標(biāo)準(zhǔn)化，用于描述工件(如服務(wù)、應(yīng)用程序、機(jī)器及其配置);并在各自的任務(wù)中定義了這些工作產(chǎn)品應(yīng)如何交互，以實(shí)現(xiàn)設(shè)計(jì)信息的交換，為自適應(yīng)平臺的產(chǎn)品開發(fā)所需的各種活動。圖4.1說明了自適應(yīng)AUTOSAR的開發(fā)工作流草案，其中涉及的步驟主要包含以下7步，最終將開發(fā)的軟件集成入車輛中。

E/E Architect Define Services

ECU(Machine) Architect/Platform Software Cluster Architect

Software Cluster Architect

Application Developer

Software Cluster Integrator

ECU(Machine) Integrator

Vehicle Integrator

相關(guān)概念介紹： Machine：在AP的概念體系中，Machine代表一種計(jì)算資源，它可以是真實(shí)存在的處理器，也可以是一個虛擬機(jī)，AP軟件則運(yùn)行在某一個特定的Machine上。 Manifest：Manifest是一種AUTOSAR模型的描述文件，主要包含AP軟件部署涉及到的一些配置信息（比如Service Instance Manifest會包括服務(wù)接口的版本信息，SD參數(shù)信息等內(nèi)容）

操作系統(tǒng)

概述

操作系統(tǒng)負(fù)責(zé)運(yùn)行時的資源和時間管理。EM負(fù)責(zé)平臺初始化和應(yīng)用的啟動和停止，與操作系統(tǒng)協(xié)同工作。 AP沒有為高性能的處理器指定操作系統(tǒng)。而是，其定義執(zhí)行上下文和操作系統(tǒng)接口供AP應(yīng)用使用。 OSI(操作系統(tǒng)接口)規(guī)范包含了ARA中部分應(yīng)用接口以及AP應(yīng)用的標(biāo)準(zhǔn)接口。OS本身可以很好地提供其他接口，例如創(chuàng)建進(jìn)程，這是執(zhí)行管理啟動應(yīng)用程序所需要的。然而，提供此類功能的接口，以及其他接口，不能作為ARA的一部分使用，它被定義為依賴于平臺實(shí)現(xiàn)。 OSI同時提供C和c++接口。對于C程序，應(yīng)用程序的主要源代碼業(yè)務(wù)邏輯包括在POSIX標(biāo)準(zhǔn)中定義的C函數(shù)調(diào)用，即在IEEE1003.13[1]中定義的PSE51。在編譯過程中，編譯器決定來自平臺操作系統(tǒng)的哪個C庫提供了這些C函數(shù)，應(yīng)用程序的可執(zhí)行文件應(yīng)該在運(yùn)行時被鏈接。對于c++程序，應(yīng)用軟件組件的源代碼包括在c++標(biāo)準(zhǔn)及其標(biāo)準(zhǔn)c++庫中定義的函數(shù)調(diào)用。

POSIX

市場上有幾種操作系統(tǒng)，例如Linux，提供了POSIX兼容的接口。但是，與平臺服務(wù)和基礎(chǔ)相比，應(yīng)用程序需要對操作系統(tǒng)使用更受限制的API。 一般的假設(shè)是，用戶應(yīng)用程序應(yīng)該使用PSE51作為操作系統(tǒng)接口，而平臺應(yīng)用程序可以使用完整的POSIX。如果在應(yīng)用程序級別需要更多的特性，它們將從POSIX標(biāo)準(zhǔn)中獲取，而不是在任何可能的地方新指定。 自適應(yīng)平臺基礎(chǔ)和自適應(yīng)平臺服務(wù)功能的實(shí)現(xiàn)可能會進(jìn)一步使用POSIX調(diào)用。特定調(diào)用的使用將留給實(shí)現(xiàn)者，而不是標(biāo)準(zhǔn)化的。

調(diào)度

操作系統(tǒng)提供多線程和多進(jìn)程的支持。標(biāo)準(zhǔn)的調(diào)度策略是SCHED_FIFO和SCHED_RR，由POSIX標(biāo)準(zhǔn)定義。其他如SCHED_DEADLINE或者任何其他操作系統(tǒng)規(guī)定的策略也被允許，但有一些限制，即這些策略可能不能跨不同的AP實(shí)現(xiàn)移植。

內(nèi)存管理

支持多進(jìn)程的原因之一是實(shí)現(xiàn)了不同功能集群和AA之間的自由干擾。操作系統(tǒng)對多進(jìn)程的支持迫使每個進(jìn)程處于一個獨(dú)立的地址空間中，與其他進(jìn)程隔離和保護(hù)。同一個可執(zhí)行文件的兩個實(shí)例在不同的地址空間中運(yùn)行，這樣它們在啟動時可能共享相同的入口點(diǎn)地址和代碼以及數(shù)據(jù)值，但是數(shù)據(jù)將在內(nèi)存中的不同物理頁中。

設(shè)備管理

設(shè)備管理將在POSIX的PSE51接口下提供。

執(zhí)行管理

概述

EM負(fù)責(zé)系統(tǒng)執(zhí)行管理的各個方面，包括系統(tǒng)初始化和應(yīng)用的啟停。EM與操作系統(tǒng)協(xié)同工作執(zhí)行應(yīng)用的調(diào)度。

系統(tǒng)啟動

當(dāng)機(jī)器啟動時，操作系統(tǒng)會被首先初始化然后EM作為操作系統(tǒng)一個初始進(jìn)程被啟動。然后EM啟動自適應(yīng)平臺基礎(chǔ)的其他功能集群和平臺級應(yīng)用程序。自適應(yīng)平臺基礎(chǔ)啟動并運(yùn)行后，EM將繼續(xù)啟動自適應(yīng)應(yīng)用程序。平臺級應(yīng)用程序和自適應(yīng)應(yīng)用程序的啟動順序由執(zhí)行管理基于機(jī)器清單和應(yīng)用程序清單信息決定。

EM的職責(zé)

EM負(fù)責(zé)AP平臺和應(yīng)用執(zhí)行管理的各個方面，包括 1、平臺生命周期管理 EM是自適應(yīng)平臺啟動階段的一部分，負(fù)責(zé)自適應(yīng)平臺和部署的應(yīng)用程序的初始化 2、應(yīng)用生命周期管理 EM負(fù)責(zé)已部署的應(yīng)用程序的有序啟動和關(guān)閉。EM根據(jù)機(jī)器清單和應(yīng)用程序清單中的信息確定已部署的應(yīng)用程序集，并根據(jù)聲明的應(yīng)用程序依賴項(xiàng)派生啟動/關(guān)閉順序。根據(jù)機(jī)器狀態(tài)和功能組狀態(tài)，部署的應(yīng)用程序在自適應(yīng)平臺啟動時或之后啟動，然而，并不期望所有的應(yīng)用程序都立即開始活動工作，因?yàn)樵S多應(yīng)用程序?qū)⑾蚱渌麘?yīng)用程序提供服務(wù)，從而等待和偵聽傳入的服務(wù)請求。 執(zhí)行管理不負(fù)責(zé)應(yīng)用程序的運(yùn)行時調(diào)度，因?yàn)檫@是操作系統(tǒng)的責(zé)任。但是，執(zhí)行管理負(fù)責(zé)操作系統(tǒng)的初始化/配置，使其能夠根據(jù)執(zhí)行管理從機(jī)器清單和應(yīng)用程序清單中提取的信息執(zhí)行必要的運(yùn)行時調(diào)度。

狀態(tài)管理

狀態(tài)管理提供了一種機(jī)制來定義自適應(yīng)平臺的操作狀態(tài)。狀態(tài)管理定義了AUTOSAR自適應(yīng)平臺的操作狀態(tài)，由EM執(zhí)行不同狀態(tài)之間的轉(zhuǎn)移。 EM有四種不同的狀態(tài)：

Machine State 該狀態(tài)主要用控制機(jī)器生命周期(Startup/shutdown/restart)，平臺級的進(jìn)程，和其他基礎(chǔ)設(shè)施。在每臺機(jī)器上都必須存在幾個強(qiáng)制性的機(jī)器狀態(tài)。其他特定于機(jī)器的機(jī)器狀態(tài)可以在機(jī)器清單中定義。

Function Group State 該狀態(tài)主要用于單獨(dú)啟動和停止功能一致的用戶級應(yīng)用進(jìn)程組。它們可以在機(jī)器清單中配置。

Process State 該狀態(tài)用于應(yīng)用程序生命周期管理，并由執(zhí)行管理內(nèi)部狀態(tài)機(jī)實(shí)現(xiàn)。

Application State 該狀態(tài)描述了應(yīng)用程序可執(zhí)行程序的任何實(shí)例的內(nèi)部生命周期，即進(jìn)程。每個進(jìn)程必須向執(zhí)行管理報(bào)告應(yīng)用程序狀態(tài)更改。

如下圖，顯示了在狀態(tài)管理請求了不同功能組狀態(tài)之后，不同類型狀態(tài)之間的交互的簡化示例。可以看到功能組的狀態(tài)轉(zhuǎn)移，以及引用此功能組的一個狀態(tài)的流程和執(zhí)行狀態(tài)。

通訊管理

概述

通信管理實(shí)現(xiàn)了自適應(yīng)AUTOSAR應(yīng)用程序之間面向服務(wù)的通信，適用于所有級別的通信，如進(jìn)程內(nèi)、進(jìn)程內(nèi)、機(jī)器間。它由潛在生成的服務(wù)提供者骨架和服務(wù)請求者代理以及可選的用于中央代理和配置的通用通信管理器軟件組成。 通信管理提供了內(nèi)置的安全機(jī)制，即E2E保護(hù)，其可以用于所有級別的對于事件和方法的通信。

面向通信的服務(wù)SOC

服務(wù)的概念意味著提供給應(yīng)用程序的功能超出了基本操作軟件已經(jīng)提供的功能。通信管理軟件提供了一些機(jī)制來提供或使用這些服務(wù)，用于機(jī)器內(nèi)部通信和機(jī)器間通信。 一個服務(wù)包括：

Events

Methods

Fields

通信伙伴之間的通信路徑可以在設(shè)計(jì)時、啟動時或運(yùn)行時建立。該機(jī)制的一個重要組件是充當(dāng)代理實(shí)例的Service Registry，它也是Communication Management軟件的一部分。

? 每個提供服務(wù)的應(yīng)用程序都在服務(wù)注冊中心注冊這些服務(wù)。要使用服務(wù)，消費(fèi)應(yīng)用程序需要通過查詢服務(wù)注冊表來查找所請求的服務(wù)，這個過程稱為服務(wù)發(fā)現(xiàn)。服務(wù)發(fā)現(xiàn)可以發(fā)現(xiàn)所有本地和遠(yuǎn)程的服務(wù)實(shí)例。服務(wù)消費(fèi)由Proxy（P1...P3）表示，應(yīng)用可以選擇使用哪一個服務(wù)實(shí)例。 ?

語言綁定和網(wǎng)絡(luò)綁定

通信管理提供了標(biāo)準(zhǔn)化的方法，即如何將已定義的服務(wù)呈現(xiàn)給應(yīng)用程序?qū)崿F(xiàn)者(上層，語言綁定)，以及服務(wù)數(shù)據(jù)在網(wǎng)絡(luò)上的各自表示(下層，網(wǎng)絡(luò)綁定)。這確保了源代碼的可移植性和編譯服務(wù)在不同平臺實(shí)現(xiàn)之間的兼容性。 語言綁定定義了如何通過使用目標(biāo)編程語言的方便特性將服務(wù)的方法、事件和字段轉(zhuǎn)換為直接可訪問的標(biāo)識符。性能和類型安全(只要目標(biāo)語言支持)是主要目標(biāo)。因此，語言綁定通常是由由服務(wù)接口定義提供的源代碼生成器實(shí)現(xiàn)的。 ? 網(wǎng)絡(luò)綁定定義了如何將已配置服務(wù)的實(shí)際數(shù)據(jù)序列化并綁定到特定的網(wǎng)絡(luò)。它可以根據(jù)Communication Management配置(AUTOSAR元模型的接口定義)來實(shí)現(xiàn)，既可以解釋生成的特定于服務(wù)的配方，也可以直接生成序列化代碼本身。 ? 網(wǎng)絡(luò)綁定的三種方式： ?

SOME/IP網(wǎng)絡(luò)綁定

基于Signal的網(wǎng)絡(luò)綁定

DDS網(wǎng)絡(luò)綁定

本地服務(wù)注冊也是網(wǎng)絡(luò)綁定的一部分。 請注意:語言綁定和網(wǎng)絡(luò)綁定之間的接口被認(rèn)為是通信管理軟件內(nèi)部的私有接口。因此，定義該接口的規(guī)范目前已超出范圍。盡管如此，平臺供應(yīng)商還是被鼓勵獨(dú)立地為他們的軟件定義這樣的接口，以方便實(shí)現(xiàn)其他語言綁定(而不是c++)以及平臺實(shí)現(xiàn)中的其他網(wǎng)絡(luò)綁定。

生成c++語言綁定的代理和框架

c++語言綁定的上層接口提供了在AUTOSAR元模型的接口描述中定義的服務(wù)的面向?qū)ο蟮挠成洹? 作為Communication Management軟件開發(fā)工具的一部分，生成器生成c++類，這些類包含各個服務(wù)的字段、事件和方法的類型安全表示。 在服務(wù)實(shí)現(xiàn)端，這些生成的類被命名為服務(wù)提供者骨架。在客戶端，它們被稱為服務(wù)請求者代理。對于服務(wù)方法，服務(wù)請求者代理提供了同步(阻塞調(diào)用者直到服務(wù)器返回結(jié)果)和異步調(diào)用(被調(diào)用的函數(shù)立即返回)的機(jī)制。調(diào)用者可以同時啟動其他活動，當(dāng)服務(wù)器的返回值通過c++標(biāo)準(zhǔn)模板庫(std::future)的特殊特性可用時，調(diào)用者可以接收結(jié)果。 可以對平臺實(shí)現(xiàn)進(jìn)行配置，使生成器創(chuàng)建模擬類，以便在相應(yīng)的服務(wù)器還不可用時輕松開發(fā)客戶端功能。同樣的機(jī)制也可以用于對客戶機(jī)進(jìn)行單元測試。雖然代理類可以被客戶端直接使用，但c++綁定的服務(wù)提供者骨架只是抽象基類。 服務(wù)實(shí)現(xiàn)應(yīng)該從生成的基類派生并實(shí)現(xiàn)相應(yīng)的功能。ara::com的接口還可以為端到端安全通信提供代理和框架。 這些接口的設(shè)計(jì)保證了應(yīng)用程序的兼容性，無論端到端加密保護(hù)是打開還是關(guān)閉。

靜態(tài)和動態(tài)的配置

通信路徑的配置可以在設(shè)計(jì)時、啟動時或運(yùn)行時進(jìn)行，因此被認(rèn)為是靜態(tài)或動態(tài)的。 完全靜態(tài)配置:根本不需要服務(wù)發(fā)現(xiàn)，因?yàn)榉?wù)器知道所有的客戶端，而客戶端也知道服務(wù)器。 應(yīng)用程序代碼沒有發(fā)現(xiàn):客戶機(jī)知道服務(wù)器，但服務(wù)器不知道客戶機(jī)。事件訂閱是應(yīng)用程序中唯一的動態(tài)通信模式。 應(yīng)用程序中的完整服務(wù)發(fā)現(xiàn):在配置時不知道任何通信路徑。服務(wù)發(fā)現(xiàn)的API允許應(yīng)用程序代碼在運(yùn)行時選擇服務(wù)實(shí)例。

RESTful通信

概述

通信棧ara::com和ara::rest都可以在AP應(yīng)用之間建立通信路徑。ara::rest是一個構(gòu)建RESTful API的框架，以及在RESTful API之上構(gòu)建特定服務(wù)的框架。它沒有定義特定的開箱即用的API來直接構(gòu)造RESTful服務(wù)。這個框架是模塊化的，它允許開發(fā)人員直接訪問RESTful消息事務(wù)中涉及的不同層。相反，ara::com的重點(diǎn)是提供一個傳統(tǒng)的函數(shù)調(diào)用接口，并隱藏超出這一點(diǎn)的事務(wù)的所有細(xì)節(jié)。另一個重要的區(qū)別是ara::rest確保了與非AUTOSAR對等點(diǎn)的互操作性。例如，一個ara::rest服務(wù)可以與一個移動HTTP/JSON客戶端通信，反之亦然。

What's the RESTful？ REST：Represetational State Transfer（表象層狀態(tài)轉(zhuǎn)移） 1.每一個URI代表一種資源；2.客戶端和服務(wù)器之間，傳遞這種資源的某種表現(xiàn)層；3.客戶端通過四個HTTP動詞（get、post、put、delete），對服務(wù)器端資源進(jìn)行操作，實(shí)現(xiàn)”表現(xiàn)層狀態(tài)轉(zhuǎn)化”

架構(gòu)

ara::rest的架構(gòu)是基于模塊化設(shè)計(jì)的，它支持API級別以及服務(wù)級別的設(shè)計(jì)。下圖說明了它的總體設(shè)計(jì)。它描述了一個服務(wù)應(yīng)用程序是如何在ara::rest中組成的。 ? ara::rest的通用REST層只提供了三個基本抽象:一個樹狀結(jié)構(gòu)的消息有效負(fù)載(對象圖)、一個URI和一個請求方法(比如HTTP中的GET或POST)。從這些基本的原語，特定于領(lǐng)域的RESTful api可以被組合起來，通過對象圖、URI和方法定義一個具體的高層交互協(xié)議。它的目的是定義訪問特定領(lǐng)域數(shù)據(jù)模型的規(guī)則，并為應(yīng)用程序提供一個抽象(c++) API。當(dāng)不需要進(jìn)一步的抽象時，自適應(yīng)應(yīng)用也可以直接使用ara::rest，而不是使用這個域API。 ?

組件

ara::reset包含以下組件的集合 ? Object Graph是一個獨(dú)立的協(xié)議綁定的樹形數(shù)據(jù)結(jié)構(gòu)，其是所有ara::reset通信的基礎(chǔ)。它的目的是映射到協(xié)議格式，如JSON和C結(jié)構(gòu)體。這最大限度地提高了與非ARA通信節(jié)點(diǎn)和經(jīng)典AUTOSAR的兼容性。對象圖是以消息的形式傳輸?shù)?，這些消息完全從一個具體的底層協(xié)議綁定中抽象出來。如果需要，它們?nèi)匀辉试S用戶訪問特定于協(xié)議的詳細(xì)信息。 ? 在ara::reset的異步編程模式中，消息封裝了request/replay通信周期的整個上下文。 ? 路由概念提供了一種將請求(包括請求方法和URI)映射到用戶定義的處理程序函數(shù)的方法。路由是將抽象從通用REST提升到特定類型的RESTful API的基礎(chǔ)。 ? Uri是一種符合RFC的通用Uri表示，但它是一種高效的Uri表示。 ? ara::rest為服務(wù)器和客戶端通信提供了所謂的(網(wǎng)絡(luò))端點(diǎn)，兩者都提供了相當(dāng)程度的資源控制。兩者的設(shè)計(jì)都是為了在單核和多核系統(tǒng)上提供快速和高效的通信能力。 ? 整個框架設(shè)計(jì)嚴(yán)格地面向最大限度的資源控制?？梢試?yán)格控制和定制所有計(jì)算和分配，以滿足應(yīng)用程序(部署)的精確需求。 ?

診斷

診斷管理實(shí)現(xiàn)了ISO 14229-5(UDSonIP)，其主要基于ISO 14229-1(UDS)和ISO 13400-2(DoIP)。 診斷管理是使用ara::com的自適應(yīng)平臺服務(wù)。因此，其是語言獨(dú)立的，所以可以使用其他語言，比如在以后可以使用JAVA。配置基于Class Platform的AUTOSAR Diagnostic Extract Template(DEXT)。DEXT目前已經(jīng)得到很多OEMs和Vendor使用。 診斷管理使用的傳輸層是DoIP。未來的自適應(yīng)平臺會支持其他的傳輸層比如CAN。也許還計(jì)劃支持定制的傳輸層，因?yàn)镈oIP通常不用作車載協(xié)議。 此部分的范圍是去從自適應(yīng)應(yīng)用中抽象診斷協(xié)議。這些接口與經(jīng)典平臺(例如SetEventStatus)協(xié)調(diào)一致，允許經(jīng)典平臺開發(fā)者進(jìn)行簡單的更改。

診斷功能子集

診斷功能的子集類似于CP平臺的DCM，實(shí)現(xiàn)了診斷的服務(wù)器。當(dāng)前支持的服務(wù)是有限的，但是 UDS的服務(wù)會在以后進(jìn)行擴(kuò)展。 除了ISO 14229-1的偽并行客戶端處理之外，還擴(kuò)展了診斷管理器(Diagnostic Manager, DM)，以支持對不同診斷客戶端的完全并行處理。這滿足了現(xiàn)代汽車架構(gòu)的需求，包括多個診斷客戶端(測試器)用于數(shù)據(jù)采集、后端訪問、SOTA(軟件空中傳輸)，最后是經(jīng)典的車間和生產(chǎn)用例。

事件記憶子集

事件記憶子集類似于CP平臺的DEM，負(fù)責(zé)DTC管理。 支持的功能和接口和CP平臺類似。監(jiān)測的事件和一個DTC綁定。DTC可以分配為PrimaryMemory(通過19 02/04/06訪問)或者配置UserMemories(經(jīng)過19 17/18/19訪問)。DTC可以存儲快照和擴(kuò)展數(shù)據(jù)。 對老化和就緒計(jì)算有重要影響的操作周期變化需要轉(zhuǎn)發(fā)給DM。 同樣，存儲和啟用條件的變化需要轉(zhuǎn)發(fā)給DM，通過啟用條件可以控制dtc的一般更新。例如禁止在電壓低時禁止所有網(wǎng)絡(luò)的監(jiān)控。根據(jù)存儲條件，DTC不能存儲在DTC Memory。

持久化管理

概述

持久化管理提供應(yīng)用在NVM中存儲信息的機(jī)制。該數(shù)據(jù)可在啟動和點(diǎn)火循環(huán)使用。持久化通常被實(shí)現(xiàn)為一個庫，它運(yùn)行在自適應(yīng)應(yīng)用程序的進(jìn)程中，具有該進(jìn)程的權(quán)限。 持久化管理庫將存儲位置標(biāo)識符作為來自應(yīng)用程序的參數(shù)，以尋址不同的存儲位置。 可用的存儲位置分為兩類：

Key-Value Storage

File-Proxy Storage

每個應(yīng)用可以使用多個存儲類型的組合。 對于一個應(yīng)用，存儲的數(shù)據(jù)總是私有的。使用存儲庫不能在不同應(yīng)用間共享數(shù)據(jù)。這一決定是為了防止在communication Management提供的功能之下出現(xiàn)第二個通信路徑。 持久化管理對于存儲的數(shù)據(jù)提供加密方法，確保敏感數(shù)據(jù)在寫入物理設(shè)備之前進(jìn)行加密。

Key-Value存儲

鍵值存儲提供了從一個存儲位置存儲和恢復(fù)數(shù)據(jù)的機(jī)制。支持的value類型是基礎(chǔ)類型，C++ Plain Code數(shù)據(jù)結(jié)構(gòu)和從這些類型派生的數(shù)組/容器。 每個Key-Value數(shù)據(jù)庫的鍵必須是唯一的字符串，并且由應(yīng)用程序使用存儲庫提供的方法定義。

File存儲

并不是所有持久存儲的數(shù)據(jù)類型都適合Key-Value機(jī)制，因此AP平臺還支持File存儲機(jī)制。 File存儲提供對一組文件的訪問，類似于文件系統(tǒng)的目錄。

健康管理

概述

健康管理為AP應(yīng)用在車輛內(nèi)外提供保護(hù)信息交互的機(jī)制。包括ECU內(nèi)外的通信機(jī)制。出于此目的，提供的機(jī)制允許在發(fā)生任何損壞時進(jìn)行錯誤檢測，沒有保護(hù)數(shù)據(jù)完整性的機(jī)制。健康監(jiān)控是ISO26262(控制流程監(jiān)控、外部監(jiān)控設(shè)施、看門狗、邏輯監(jiān)控、時間監(jiān)控、程序順序監(jiān)控)所要求的。 健康提供監(jiān)控應(yīng)用正確執(zhí)行的機(jī)制。允許對檢測偏差定義處理。 另外，安全對編碼指引提供指導(dǎo)，有利于安全可靠的使用復(fù)雜的語言，比如C++。

信息交換的保護(hù)

最新的AUTOSAR E2E配置支持所有AUTOSAR AP和CP實(shí)例組合之間的安全通信，無論它們是在相同或不同的ecu中。在有用的情況下，將提供使用自適應(yīng)平臺中面向服務(wù)的更多功能的機(jī)制，以允許安全通信。所提供的功能提供了驗(yàn)證從發(fā)布者發(fā)送和由訂閱者接收的信息在傳輸期間沒有更改的可能性。根據(jù)AUTOSAR CP中的E2E機(jī)制，在E2E上下文中不提供傳輸確認(rèn)和傳輸安全。 當(dāng)在發(fā)布者和訂閱者之間的通信中使用端到端保護(hù)時，在發(fā)布者的進(jìn)程中同步調(diào)用端到端保護(hù)。在訂閱者端，在接收訂閱者流程中的數(shù)據(jù)時調(diào)用被選中的端到端。

平臺健康管理

提供健康管理機(jī)制以支持fail-safe應(yīng)用。包含如下方面

Alive supervision

Deadline supervision

Logical supervision

Error handing of supervision errors

Health Monitoring

C++編程指引

AUTOSAR C++ 14編碼指南文檔適用的主要應(yīng)用領(lǐng)域是汽車，但它也可以用于其他在安全相關(guān)和關(guān)鍵環(huán)境中工作的嵌入式應(yīng)用。AUTOSAR C++ 14編碼準(zhǔn)則適用于在32位和64位微控制器上，使用POSIX或類似操作系統(tǒng)，提供高效和完整的c++ 14語言支持的高端嵌入式微控制器。 現(xiàn)有的標(biāo)準(zhǔn)是不完整的，包括舊的c++版本，或者不適用于關(guān)鍵/安全相關(guān)的。特別是，MISRA c++:2008不包括c++ 11/14。多個新的語言特性需要分析它們在提供有效實(shí)現(xiàn)方面的作用，以及使用每個特性會帶來多大的風(fēng)險(xiǎn)。

安全措施(Security)

概述

Security服務(wù)提供AP平臺增強(qiáng)系統(tǒng)的方法，比如安全通信和訪問管理系統(tǒng)。

身份和訪問管理

我們建議AUTOSAR自適應(yīng)平臺采用身份和訪問管理框架，以支持對各個AUTOSAR組件(自適應(yīng)AUTOSAR應(yīng)用程序、服務(wù)和功能集群)進(jìn)行身份驗(yàn)證，并引入角色和權(quán)限管理功能的概念。使用IAM框架，這些應(yīng)用程序可以查詢基于現(xiàn)有策略的訪問控制決策。查詢將通過功能集群處理，因?yàn)閼?yīng)用程序沒有與IAM框架的直接接口。在使用請求時，服務(wù)將能夠利用指定的框架來評估請求者的權(quán)限和權(quán)利，并相應(yīng)地實(shí)施相應(yīng)的策略。 這個框架背后的思想是由日益增長的安全需求驅(qū)動的，因?yàn)锳UTOSAR自適應(yīng)平臺需要與它的應(yīng)用程序建立一個健壯的、定義良好的信任關(guān)系。如果攻擊者破壞了應(yīng)用程序，它不應(yīng)該對自適應(yīng)平臺本身有任何影響，攻擊者的能力應(yīng)該被限制在被破壞的應(yīng)用程序的能力。這就是為什么應(yīng)用程序應(yīng)該只能訪問系統(tǒng)資源或觸發(fā)它們應(yīng)該執(zhí)行的操作。IAM框架管理身份和訪問權(quán)限，可以被視為一種可理解的機(jī)制，將應(yīng)用程序的訪問限制在必要的最低限度。

Crypto和Key管理

AUTOSAR自適應(yīng)平臺支持用于通用密碼操作和安全密鑰管理的API。該API支持在運(yùn)行時動態(tài)生成密鑰和加密作業(yè)，以及對數(shù)據(jù)流進(jìn)行操作。為了減少存儲需求，密鑰可以存儲在加密后端內(nèi)部，也可以存儲在外部，并根據(jù)需要導(dǎo)入。 該API旨在支持在單獨(dú)的組件(如硬件安全模塊(HSM))中封裝安全敏感的操作和決策。通過將密鑰限制到特定的使用(例如，僅解密)，或根據(jù)IAM的報(bào)告，將密鑰的可用性限制到單個應(yīng)用程序，可以提供對密鑰和密鑰使用的額外保護(hù)。 根據(jù)應(yīng)用程序支持的不同，API還可以用于在處理TLS和SecOC等加密協(xié)議時保護(hù)會話密鑰和中間秘密。

安全架構(gòu)

Key管理

更新和配置管理

概述

AP平臺提供一個很重要的能力是通過OTA(over-the-air)升級軟件和配置。為此，AP平臺提供Update and Configuration Manager(UCM)服務(wù)處理軟件升級請求。 UCM負(fù)責(zé)升級，安裝，卸載和記錄AP平臺的軟件。它的角色類似于已知的包管理系統(tǒng)，如Linux中的dpkg或YUM，具有額外的功能，以確保以一種安全的方式更新或修改Adaptive Platform上的軟件。

軟件包處理

除了應(yīng)用程序和配置數(shù)據(jù)，每個軟件包都包含一個清單，提供元數(shù)據(jù)，如包名、版本和處理包所需的其他元信息。 軟件包的數(shù)據(jù)內(nèi)容可以包含一個或多個自適應(yīng)應(yīng)用程序，內(nèi)核或固件更新，或更新的配置和校準(zhǔn)數(shù)據(jù)。 UCM基于提供的元數(shù)據(jù)和Adaptive Platform軟件信息處理軟件包。

軟件信息報(bào)告

UCM提供了服務(wù)接口，該接口公開了檢索Adaptive Platform軟件信息的功能，例如已安裝軟件的名稱和版本。

軟件更新的一致性

UCM確保只安裝具有所有描述的依賴項(xiàng)的驗(yàn)證包。這樣就不會安裝不需要的或不合適的軟件。UCM提供了一個讀取安裝結(jié)果的界面。如果在更新過程中出現(xiàn)故障，UCM將平臺恢復(fù)到一個已知的功能狀態(tài)?？苫謴?fù)故障的一個例子是由于功率損失而中斷的更新過程。

時間同步

概述

當(dāng)需要跨分布式系統(tǒng)的不同事件的相關(guān)性時，不同應(yīng)用程序和/或ECU之間的時間同步(Time Synchronization)是至關(guān)重要的，無論是為了能夠及時跟蹤這些事件，還是為了在準(zhǔn)確的時間點(diǎn)觸發(fā)它們。 ? 由于這個原因，一個時間同步API被提供給應(yīng)用程序，所以它可以檢索與其他實(shí)體/ECU同步的時間信息。 ? 時間同步功能是通過系統(tǒng)中不同的“時間基礎(chǔ)資源”來提供的。 ?

設(shè)計(jì)

對于AP平臺，下面3種不同的技術(shù)應(yīng)用滿足時間同步的需要

CP平臺的StbM模塊

chrono庫 - std::chrono (c++ 11)或boost::chrono

POSIX Time 接口

時間同步模塊提供類似于CP平臺StbM的功能，但帶有一個std::chrono啟發(fā)的API設(shè)計(jì)。 時間同步模塊會考慮以下幾個方面

Startup Behavior

Constructor Behavior(初始化)

Normal Operation

Error Handing

未來會考慮以下幾個方面

Shutdown Behavior

Error Classification

Version Check

架構(gòu)

應(yīng)用程序?qū)⒛軌蛟L問每個時間基礎(chǔ)資源(Time Base Resource)的不同專門化類實(shí)現(xiàn)。TBR以資源的形式提供，就像在ara::com設(shè)計(jì)中提供服務(wù)一樣，因此它采用了以下ara::com的架構(gòu)設(shè)計(jì)模式 代理:類似于ara::com服務(wù)代理骨架模式，TS提供了一個資源代理模式，省略了骨架部分。 查找:類似于ara::com服務(wù)代理查找模式，TS提供了一個資源代理查找模式來提供對tbr的訪問。 代理方法:類似于ara::com代理方法模式，TS使用的方法模式也遵循異步的Future模式。 當(dāng)談到避免延遲時，這種架構(gòu)設(shè)計(jì)顯然將時間同步設(shè)計(jì)置于正面沖突之中，因?yàn)楹笳呤怯蒩ra::com API的設(shè)計(jì)模式的異步行為固有地添加進(jìn)來的。

AUTOSAR利弊

隨著AUTOSAR組織的日益擴(kuò)大和越來越多的汽車行業(yè)開始使用AUTOSAR架構(gòu)，我們有必要思考相比以往的軟件開發(fā)，使用AUTOSAR架構(gòu)有哪些利弊。 利弊在某種條件下是相互轉(zhuǎn)換的，有利就有弊。目前AUTOSAR還是由外國幾個公司主導(dǎo)，占據(jù)市場主要的幾家AUTOSAR服務(wù)（軟件以及工具）提供商有VECTOR、EB、ETAS、MENTOL,國內(nèi)有普華基礎(chǔ)軟件，經(jīng)緯恒潤，東軟睿馳，和華為等幾家，但是市場占有率還是非常低。

AUTOSAR優(yōu)勢

標(biāo)準(zhǔn)化，大家在同一個起點(diǎn)開始競爭

縮短開發(fā)以及測試周期，快速適配不同車型和項(xiàng)目

縮減開發(fā)人員，降低測試要求

開發(fā)人員熟悉工具和簡單理論即可開發(fā)，門檻低

AUTOSAR弊端

軟件架構(gòu)費(fèi)用昂貴

代碼邏輯復(fù)雜，選項(xiàng)眾多，對于存儲資源占用大

軟件開發(fā)容易成為工具人，成就不高

總結(jié)

AUTOSAR Adaptive還在逐步完善豐富，除了以上介紹的功能，最新的AP還擴(kuò)展了Automated Driving Sensor Interfaces(自動駕駛傳感器接口)、Intrusion Detection System Manager(入侵檢測系統(tǒng)管理)等功能。隨著AUTOSAR Adaptive的完善，其帶給汽車系統(tǒng)諸多好處，比如提高所有制造商的開發(fā)效率，提高開發(fā)速度，縮短車輛子系統(tǒng)間接口的開發(fā)時間以及通過標(biāo)準(zhǔn)化提升功能安全，全球所有制造商都使用用一個平臺，這樣可以縮短系統(tǒng)與其他車輛的集成時間，提高系統(tǒng)之間的兼容性以及提升信息安全。

審核編輯：彭靜