日本无码免费高清在线|成人日本在线观看高清|A级片免费视频操逼欧美|全裸美女搞黄色大片网站|免费成人a片视频|久久无码福利成人激情久久|国产视频一二国产在线v|av女主播在线观看|五月激情影音先锋|亚洲一区天堂av

  • 手機站
  • 小程序

    汽車測試網(wǎng)

  • 公眾號

    • 汽車測試網(wǎng)

    • 在線課堂

    • 電車測試

軟件定義汽車時代：進(jìn)一步探索開放軟件標(biāo)準(zhǔn)架構(gòu)—AUTOSAR

2019-02-02 19:51:51·  來源：?？W(wǎng)  
　
之前我們?yōu)榇蠹医榻B過AUTOSAR的背景、目的以及會員組織等等內(nèi)容【傳送門：軟件定義汽車時代：初識開放軟件標(biāo)準(zhǔn)架構(gòu)AUTOSAR】，今天我們將更加深入的一起探索AUTO
之前我們?yōu)榇蠹医榻B過AUTOSAR的背景、目的以及會員組織等等內(nèi)容【傳送門：軟件定義汽車時代：初識開放軟件標(biāo)準(zhǔn)架構(gòu)—AUTOSAR】，今天我們將更加深入的一起探索AUTOSAR。
 
本篇文章作為上一篇的后續(xù)，我們將從詳細(xì)介紹AUTOSAR的3個標(biāo)準(zhǔn)化對象。
  • （Software）Architecture
  • Methodology
  • Application Interface
- Software Architecture（軟件架構(gòu)）
上篇文章我們曾介紹過，如今的AUTOSAR平臺“AUTOSAR Classic Platform”的Software Architecture里面，ECU（電子控制單元）的軟件層為Application Layer、Runtime Environment（RTE）、Basic Software（BSW）3個階層（圖1）。我們在這里簡單介紹以下這3個階層的概要。
圖1：“AUTOSAR Classic Platform”中的Software Architecture（軟件結(jié)構(gòu)） 來源：ETAS
 
1）Application Layer：
對可以實現(xiàn)應(yīng)用功能的Software Component（SW-C）進(jìn)行配置的部分。 SW-C有時也記作Application SW（ASW）。除了對傳感器和執(zhí)行器有依賴性的SW-C之外，對ECU硬件和ECU的配置沒有依賴。SW-C之間，或者SW-C與BSW／Complex Device Driver（CDD）之間，通過叫做AUTOSAR Interface的接口來進(jìn)行連接。另外，SW-C的實際處理，是通過Runnable Entity或者略稱為Runnable的要素（相當(dāng)于C語言里面的函數(shù)）來實現(xiàn)的。Runnable除了某些特定的情況以外，都是在OS的任務(wù)層級運作而不是在中斷程序ISR（Interrupt Service Routine）層級。
2）Runtime Environment / Run-Time Environment（RTE）
可以實現(xiàn)SW-C之間，或者SW-C與BSW／CDD之間相互連結(jié)的接口的部分。不管是分配在同一個ECU還是在不同ECU的2個SW-C，都不需要對SW-C本身進(jìn)行任何的變更。換而言之，也可以說是消除了SW-C的ECU配置依存性。必要時，可以利用BSW的幫助（OS及協(xié)議棧等）。此外，還處理BSW周期函數(shù)及Runnable的起動，各種排他控制（Exclusive Area／Critical Section）等。
3）Basic Software（BSW）
擺脫了“面向哪一家汽車制造廠商？由哪一家ECU供應(yīng)商開發(fā)的？或者什么類型的ECU”等條件的限制，實現(xiàn)共通的基本機能的部分。R4.2 Rev. 1里面合計定義了92個（其中9個是程序庫）。
a.微控制器依存部分
OS（Operating System）以及MCAL（Microcontroller Abstraction Layer、各種驅(qū)動群）。此外，MCAL雖然大都是由微控制器供應(yīng)商提供，但并不意味著一定就預(yù)備了所有的種類。
b.微控制器非依存部分
除了微控制器依存部分以外，剩下的全部都是BSW。預(yù)備了通信（Communication）、非易失性存儲器（Memory）、看門狗（Watchdog）、I/O等各種棧（stack）。
4）Complex Driver
有時也記作Complex Device Driver（CDD）。假定了需要利用AUTOSAR標(biāo)準(zhǔn)里面沒有涵蓋的驅(qū)動（例如：利用微控制器固有的硬件機能時），對實時要求較高的應(yīng)用以及需要編入傳統(tǒng)型（non-AUTOSAR）的現(xiàn)有軟件時的部分?？梢灾苯釉L問硬件，也允許利用中斷。還可以介入AUTOSAR Interface與SW-C進(jìn)行連接。此外，根據(jù)不同的BSW，直接連接CDD可能會需要重新準(zhǔn)備專用的接口。
各層通常主要用C語言安裝。因此，不僅是對微控制器，對C語言編譯器也有依賴。這個編譯器依賴性（對編譯器供應(yīng)商及版本，可選項的依賴性），主要由Compiler Abstraction這個結(jié)構(gòu)來吸收。對編譯器依賴性大小關(guān)系如下：
OS＞MCAL＞其他的BSW
RTE及BSW，基本上會生成自動代碼。另外， BSW里面，除了會根據(jù)設(shè)定生成可變的代碼，有時也會有不變的固定代碼部分。這些代碼的提供形態(tài)有源代碼形式和程序庫形式。相對來說后者對編譯器依賴性更高。這里的依賴性很容易被遺漏，需要特別注意。

- Methodology
“Methodology”這個詞很難準(zhǔn)確翻譯過來。常常被翻譯成“方法”，這個翻譯會讓我聯(lián)想到意思不同的“technique”。譯成“方法論”也不太好理解。因此，大部分時候都不直接翻譯，而是解釋成“根據(jù)什么，通過怎樣的操作，得到什么樣的結(jié)果這樣一連串的過程”。
AUTOSAR里面的這個流程，以AUTOSAR TR Methodology這個書面描述來解說，用被稱為SPEM※1）的記述方法的子集來記述。Methodology的概要如圖2所示。
圖2：「AUTOSAR Methodology概要Workflow」 來源：AUTOSAR R4.2 Rev.1 TR Methodology、Figure 2.2相當(dāng)（由AUTOSAR_MMOD_metaModel.eap作成）
根據(jù)AUTOSAR Methodology，開發(fā)中作成的各種設(shè)計信息，必要時需要在不同的工具之間或者不同立場的作業(yè)人員之間進(jìn)行傳遞（數(shù)據(jù)交換）。另外，需要進(jìn)行構(gòu)成管理。因此，這個數(shù)據(jù)形式里面需要有共通的定義。
AUTOSAR里面的數(shù)據(jù)交換，基本上使用XML進(jìn)行。這些數(shù)據(jù)形式被稱為AUTOSAR XML或者ARXML，為了能夠在各種階段和單位進(jìn)行數(shù)據(jù)交換而被細(xì)化，主要由被叫做AUTOSAR TPS（Template）的各種書面語言來定義。其中代表性的如下：
1）ECU Extract
一般用于汽車制造廠商和ECU供應(yīng)商之間傳遞信息,是ECU軟件開發(fā)(RTE/BSW設(shè)定)時必需的起點※2）?！禔UTOSAR TPS System Template》文件中有詳細(xì)釋義。其中包含了諸如：網(wǎng)絡(luò)的E/E系統(tǒng)構(gòu)成（例如：ECU和網(wǎng)絡(luò)的定義）、通訊矩陣的定義（例如：消息的定義）、SW-C針對ECU的分配信息等。另外也可以將其他各種各樣的構(gòu)成要素囊括在內(nèi)，并將其反映到RTE和BSW的設(shè)定中去，所以也有助于簡化ECU供應(yīng)商的設(shè)定工作。但是，一般必須由汽車制造廠商提供ECU Extract的所有構(gòu)成要素，構(gòu)成要素不完整的情況較多，此時須由ECU供應(yīng)商進(jìn)行補充。并且在開發(fā)初期提供的都是不完整版，之后需要多次反復(fù)更新※3）。
2）ECU Configuration Values（EcuC）
也被稱為ECU Configuration Description。其中儲存了RTE和BSW的設(shè)定信息，用于生成其代碼。有時儲存在單一文件夾中，有時也會根據(jù)BSW進(jìn)行細(xì)分。《AUTOSAR TPS ECU Configuration》文件中有詳細(xì)釋義。
3）Software Component Description
儲存了Application Layer中的SW-C相關(guān)的定義信息?！禔UTOSAR TPS Software Component Template》文件中有詳細(xì)釋義。正確來說，雖然其中包含了Atomic、Composition和Service Component等各種Software Component，一般來說，包含這些定義的數(shù)據(jù)總稱為SW-C Description。傳遞數(shù)據(jù)信息時，有時會將SW-C的接口部分的定義（Port Interface）和數(shù)據(jù)類型（Data Type）等信息存放在一個文件夾中，有時會按各項目進(jìn)行細(xì)分。
4）Measurement and Calibration Support Data (McSupportData、MCSD)
存放了支持校準(zhǔn)和測量SW-C和BSW的信息（具體有變量名稱和類型等等）?！禔UTOSAR SWS RTE》文件中有詳細(xì)釋義。此支持?jǐn)?shù)據(jù)會轉(zhuǎn)化到ASAM MCD-2 MC標(biāo)準(zhǔn)（別名：ASAP2）中的A2L文件夾中去，作為校準(zhǔn)/測量/診斷工具（Measurement、Calibration and Diagnostics Tool、MCD Tool）使用。
5）Diagnostic Extract
存放了診斷相關(guān)的定義數(shù)據(jù)?！禔UTOSAR TPS Diagnostic Extract Template》文件中有詳細(xì)釋義。在R4.2 Rev.1中以附加數(shù)據(jù)的形式體現(xiàn)。
6）ECU Resource Description
存放了ECU硬件相關(guān)的定義數(shù)據(jù)?！禔UTOSAR TPS ECU Resource Template》文件中有詳細(xì)釋義?，F(xiàn)節(jié)點，即使在AUTOSAR的最新版本（R4.2 Rev.1）中，Analog IO、Digital IO和Timer等的定義均為：Currently no special attributes are defined，使用頻率極低。

注釋
※1）是指Software＆Systems Process Engineering meta-Model。是根據(jù)Object Management Group（OMG）開發(fā)出來的。http://www.omg.org/spec/SPEM/2.0/
※2）一般很少使用傳統(tǒng)（non-AUTOSAR）的數(shù)據(jù)形式來代替ECU Extract。例如，跟通信相關(guān)的話，DEC、LDF以及FIBEX都是其代表性的數(shù)據(jù)形式。
在AUTOSAR Authoring Tool中，可作為擴充功能應(yīng)對數(shù)據(jù)的讀取。作為其中之一的“ETAS ISOLAR-A”，可以作成DBC、LDF以及FIBEX的讀取命令腳本，所以可以把汽車廠商特有的擴充數(shù)據(jù)（特別是DBC）反映到RTE和BSW的設(shè)定工作中。
※3）因為是ECU軟件開發(fā)的起點，所以在開發(fā)過程中ECU供應(yīng)商向汽車廠商的反饋是很關(guān)鍵的一點。涉及到很多注意點，比如必須區(qū)分“最終可以得出什么樣的結(jié)果”和“實際得出了什么樣的結(jié)果”。

 閑談Methodology：用工具進(jìn)行設(shè)定不是“畫畫”！
AUTOSAR Authoring Tool（AAT）類別中的工具和系統(tǒng)通常會被用來制作AUTOSAR XML。
令人遺憾的是，對于利用這些工具展開的設(shè)定工作，人們不認(rèn)為那是在寫代碼，多戲稱之為是在“瞎玩”、“畫畫”等。
在工具中的輸入操作背景中，存在著”設(shè)計“這樣的概念性作業(yè)，所以決不是單純地“畫畫”。原本在AUTOSAR中，相比較重新安裝而言，在設(shè)定時就必須滿足能夠應(yīng)對各種場景情形的要求（相當(dāng)于除Frakes以外其他分類中的Generative Approach※4））。而且其設(shè)定內(nèi)容已實現(xiàn)形式化，之后也有可能實現(xiàn)自動化。如果想順利導(dǎo)入AUTOSAR并實現(xiàn)軟件的高度再利用化，就必須讓周圍的人理解、認(rèn)可設(shè)定工作的意義和價值。
另外，如果僅以“AUTOSAR XML”或“ARXML”的形式表述，那就基本等同于什么都沒有表達(dá)出來。比如就應(yīng)該像“ECU Extract”這樣表述，重要的是要表達(dá)出其中包含了什么樣的內(nèi)容。
而且Methodology基本上不是一開始就存在并用來分擔(dān)工作的。因為有了實際的開發(fā)流程和工作分工（分界線）的需求，Methodology才應(yīng)運而生，并根據(jù)需求持續(xù)更新。反過來說，作成了這個標(biāo)準(zhǔn)的會員企業(yè)，對此開發(fā)流程也僅僅只是有一個大概的了解。即使自己公司的開發(fā)流程和AUTOSAR Methodology的開發(fā)流程有很大的不同，但說不定從中可以受到改善的啟發(fā)。如果一開始對兩者的差異就采取批判的態(tài)度，那可能就失去了改善的機會，讓人不禁覺得惋惜。

-Application Interface（AI）
不管再怎么利用AUTOSAR Software Architecture，即使不再依賴于SW-C、ECU的配置和硬件，但對于“實現(xiàn)某功能時需要什么樣的數(shù)據(jù)，且以何種形式表現(xiàn)”這樣的信息仍然有一定的依賴性。如果單純地靠線性變換就得以表現(xiàn)的話那還算簡單，但是，如果物理量的維度原本就不同的話，那線性變換也無濟于事。
AUTOSAR Application Interface應(yīng)用于汽車時，在以下各域以及各域之間的典型性接口，皆以AUTOSAR Interface的形式歸總：
  • 車身和舒適功能
  • 動力傳動系統(tǒng)
  • 乘客和行人保護(hù)
  • 多媒體/車聯(lián)網(wǎng)/HMI
另外，使用AUTOSAR Software Architecture，并不意味著一定就會使用Application Interface?，F(xiàn)在很多使用AUTOSAR的汽車制造廠商都并未使用Application Interface。AUTOSAR可根據(jù)相應(yīng)的分類方法細(xì)分之后再導(dǎo)入。
注釋
※4）除Frakes以外的其他工具：Metrics and Models, ACM Computing Surveys, Volume 28, Issue 2, pp. 415-435, 1996.http://dl.acm.org/ft_gateway.cfm?id=234531&type=pdf&CFID=65178775&CFTOKEN=89447410

-最后
筆者雖然接受了1次更新6000字左右的連載工作，但最開始光“復(fù)習(xí)”工作就花費了雙倍的精力。所以，我想在這里強調(diào)的是，這些內(nèi)容才僅僅達(dá)到了很淺顯的概要的層次，自己必須以此為起點繼續(xù)鉆研。?？W(xué)城在11月17日特邀OEM+Tier 1實戰(zhàn)專家，為大家?guī)硪粓鰧崙?zhàn)講解，有興趣的朋友們可以在面授課堂上去更系統(tǒng)的學(xué)習(xí)AUTOSAR，詳情可以點擊以下海報查看：
 
在這過程中不可避免地會接觸到大量的信息和工具。牛喀學(xué)城的講師會為朋友們抽絲剝繭，兩天的課程必將使朋友們滿載而歸。
AUTOSAR是基礎(chǔ)，就像是背后的工作人員，是一個樸素、不起眼的存在。我相信工作一段時間之后，至少現(xiàn)在我可以明確的說：只要用了，將來肯定有所回報。
從下次開始，我會盡我所能地介紹關(guān)于導(dǎo)入AUTOSAR時應(yīng)該跨越的壁壘，以及有助于跨越壁壘的相關(guān)內(nèi)容和值得期待的積極的一面。還請大家耐心等待！
 
 
分享到：
 
反對 0 舉報 0 收藏 0 評論 0
滬ICP備11026917號-25