系列文章目錄

前言

最近看到有朋友提問，“復雜驅(qū)動和Linux驅(qū)動有啥區(qū)別？” 看到幾個回答挺好的，“Linux驅(qū)動是真正的驅(qū)動，復雜驅(qū)動只是在autosar范疇的說法，內(nèi)容不一定是驅(qū)動，可能同時包含底層、算法、應用層等其他東西” 簡而言之，沒辦法統(tǒng)一標準的東西，都放在復雜驅(qū)動了；例如功能安全類似的；

AutoSar CDD開發(fā)必看！不想看英文標準就來看這篇吧！本文基于AutoSar CDD標準，機翻+人工修改；歡迎評論呀！
AutoSar官方推薦的CDD的構(gòu)建思路是：使用標準函數(shù)構(gòu)建基礎的框架，例如ADC實現(xiàn)基本的初始化、開啟通道轉(zhuǎn)換、獲取通道值等功能；然后在框架中添加組件，撰寫算法實現(xiàn)更多需要的功能，例如硬解碼、軟解碼、電壓電流監(jiān)測等等功能；

一、Introduction to CDD

CDD：
CDD是復雜設備驅(qū)動的首字母縮寫
主要為驅(qū)動程序或復雜驅(qū)動程序，但不限于驅(qū)動程序。

復雜驅(qū)動程序是一種未被AUTOSAR標準化的軟件實體，可以通過AUTOSAR接口和/或基本軟件模塊api訪問。

? CDD是位于基礎軟件復雜驅(qū)動層的特定模塊，與標準BSW模塊或Rte交互。

? CDD可能需要與分層軟件體系結(jié)構(gòu)的模塊連接

? 分層軟件架構(gòu)的模塊可能需要連接到CDD

? CDD可能需要通過Rte連接swc

CDD的主要目標是通過使用特定的中斷和/或復雜的微控制器外圍設備、外部設備(通信收發(fā)器)直接訪問微控制器來實現(xiàn)復雜的傳感器評估和執(zhí)行器控制。ASIC…)以滿足特殊的功能和時序要求。

此外，它還可以用于實現(xiàn)增強的服務/協(xié)議或封裝非autosar系統(tǒng)的遺留功能。

CDD的實現(xiàn)可能取決于應用程序、μC和ECU。

最后，CDD可以作為將現(xiàn)有概念或新概念引入AUTOSAR軟件體系結(jié)構(gòu)的遷移機制。

某些語氣詞使用的約定：

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and
“OPTIONAL” in this document are to be interpreted as:

SHALL: 這個詞意味著這個句子是AUTOSAR規(guī)范的絕對要求。因此，設計者應尊重原始AUTOSAR規(guī)范的要求。（意思必須按AutoSar要求來）

SHALL NOT: 這個詞表示這句話絕對禁止使用AUTOSAR規(guī)范。因此，設計者應尊重原始AUTOSAR規(guī)范的要求。（意思必須按AutoSar要求來）

MUST: 這個詞的意思是由于法律問題，這句話是AUTOSAR規(guī)范的絕對要求。因此，設計者應尊重原始AUTOSAR規(guī)范的要求。（意思必須按AutoSar要求來）

MUST NOT: 這句話的意思是，由于法律的限制，這句話是絕對禁止的規(guī)范。因此，設計者應尊重原始AUTOSAR規(guī)范的要求。（意思必須按AutoSar要求來）

SHOULD: 這個詞或形容詞是“推薦”的意思，在特定情況下，可能存在忽視某一特定項目的正當理由，但在選擇不同的路線之前，必須了解并仔細權(quán)衡其全部影響。（意思推薦你這么做，不這么做也行，出了錯自己負責）

SHOULD NOT: 這個短語或短語是“不推薦”的意思，在特定的情況下，當特定的行為是可以接受的，甚至是有用的，可能存在有效的理由，但在實施任何帶有這個標簽的行為之前，應該理解全部的影響，并仔細權(quán)衡情況。（意思推薦你這么做，不這么做也行，出了錯自己負責）

MAY: 這個詞，或者形容詞“OPTIONAL”，意思是一個項目是真正可選的。一個供應商可能會選擇包含該項目，因為一個特定的市場需要它，或者因為供應商覺得它可以增強產(chǎn)品，而另一個供應商可能會省略相同的項目。一個不包含特定選項的實現(xiàn)必須準備好與另一個包含該選項的實現(xiàn)互操作，盡管功能可能會減少。以同樣的方式，一個包含特定選項的實現(xiàn)，
必須準備好與另一個不包含該選項的實現(xiàn)進行互操作(當然，選項提供的特性除外)。
(意思這里你有很多選擇，不做強制要求。自己了解這么選擇會產(chǎn)生哪些影響就好了)

二、CDD設計建議(CDD開發(fā)需要注意的事項）

為了在AUTOSAR體系結(jié)構(gòu)中接口和簡化CDD集成，設計人員應考慮以下幾點

2.1、文檔

用戶手冊（寫完CDD應該寫哪些文檔讓別人理解）

CDD設計者應提供用戶手冊以簡化集成并向客戶提供信息:

? CDD介紹和概述
? 功能操作描述(初始化、正常、關機、故障操作……)
? 描述與其他BSW模塊、SchM和Rte的關系和需求;例如，NvM的內(nèi)存塊，需要配置的臨界區(qū)。
? 文件結(jié)構(gòu)和依賴關系
? 接口(包括服務)的描述:名稱、描述、可重入性、參數(shù)(名稱、類型、范圍、值)、返回值(名稱、類型、范圍、值)、配置類。
? 非功能需求描述:時間和行為需求、資源使用、與其他BSW模塊或SWC的行為……
? 描述Dem錯誤，可選Det錯誤，調(diào)試變量
? 配置參數(shù)(名稱、類型、范圍、值)的描述。
? —內(nèi)存映射需求描述(Flash、RAM)
? 使用限制和開放問題
? 與其他模塊的集成約束和要求
? 例子

執(zhí)行（應該遵守的一些要求）
對于CDD實現(xiàn)，AUTOSAR幾乎沒有什么限制。至少:
? CDD應尊重輸入規(guī)格[3]，[4]，[5]，[6]，[7]，[9]，[10]，[11]
? CDD應保護其關鍵資源，定義可由SchM或OS機制處理的關鍵部分。
? CDD模式可由EcuM和BswM模塊管理。
? CDD可以使用內(nèi)存映射機制來處理它的內(nèi)存段。
? CDD可以使用Det或Dem模塊報告錯誤。

CDD Files （建議你這樣設計文件結(jié)構(gòu)）

本節(jié)只是一個建議，并沒有完全定義模塊文件的結(jié)構(gòu)。
Code file(s) ：
除了[4]AUTOSAR基本軟件模塊通用要求和[5]BSW模塊通用規(guī)范要求外，CDD模塊的代碼文件結(jié)構(gòu)不固定。

? 至少應該提供一個CDD_.c
? 中斷函數(shù)可以放在CDD_Irq.c。
? Callout函數(shù)可以放在CDDCallout.c。
? 根據(jù)需要，在Link time從配置中生成的C對象可以放在CDDLcfg.c文件中。
? 根據(jù)需要，在構(gòu)建后從配置生成的C對象可以放在CDD_PBcfg.c文件中。
? 如果CDD模塊的實現(xiàn)需要額外的代碼文件，則可以自由地包含它們

Header file(s)
下圖包含了CDD模塊定義的AUTOSAR頭文件層次結(jié)構(gòu)

• ? CDD模塊應該提供一個頭文件結(jié)構(gòu)，這樣CDD模塊的用戶只需要包含CDD_.h文件。
• ? 如果某些回調(diào)函數(shù)必須由其他BSW模塊處理，CDD模塊可能會提供CDD__Cbk.h頭文件。
• ? 根據(jù)需要，由配置生成的C對象聲明可以放在CDD_Cfg.h,
  CDDPBcfg.h，CDD < MODULENAME > _Lcfg.h文件。
• ? 如果CDD模塊的實現(xiàn)需要額外的頭文件，則可以自由地包含它們。頭文件是自包含的，這意味著它們將包括它們所需的所有其他頭文件
• ? CDD模塊可能包括Det .h和/或Dem.h頭文件來報告錯誤
• ? 如果必須定義一些內(nèi)存映射區(qū)域，其中是模塊實現(xiàn)前綴，CDD模塊可能包括_MemMap.h頭文件。
• ? 如果配置了與Rte的接口，CDD模塊可能包含Rte_CDD_.h頭文件。

2.2行為和接口描述

一些CDD不僅具有到其他BSW模塊或集群的接口，而且還具有通過Rte從應用程序sw - c訪問的更抽象的接口。（CDD不僅能連RTE，也可以連BSW）

在這種情況下，需要一個SW-C類型的CDD來連接Rte, CDD應遵守文檔[10]BSW模塊規(guī)范的要求。（SWC類型的CDD？還沒理解）

描述模板

這個描述文件應該包含:

• ? CDD服務描述
• ? 類型和端口
• ? 描述內(nèi)部行為和可運行實體
• ? 可運行實體所需觸發(fā)事件的描述
• ? 獨占共享資源保護區(qū)域描述
• ? 內(nèi)存映射

這里需要的更抽象的接口稱為AUTOSAR接口，通過軟件組件模板(SWCT)來描述，它們由端口、端口接口及其進一步的詳細信息組成

用于為CDD描述這些元素的SWCT的根類是ComplexDeviceDriverSwComponentType。

從Rte到這些CDD的函數(shù)調(diào)用應該被建模為也包含在SWCT中的可運行實體。類的根類
用于描述RunnableEntities(以及其他一些東西)的SWCT被調(diào)用SwcInternalBehavior。

提示:CDD可運行程序應該設計成減少Rte開銷，例如:
服務器可運行對象最好是可重入的:可以并發(fā)調(diào)用=TRUE（可重入？意思是可多次調(diào)用？）
可運行簽名為:void或StdReturnType RunnableName(void或參數(shù))

2.3參數(shù)配置

如果必須使用AUTOSAR GCE配置參數(shù)，CDD應遵守文檔[11]ECU配置規(guī)范的要求

至少：
? 模塊的AUTOSAR和軟件版本應由配置文件標識。
? Det不應該包含在生產(chǎn)階段，因此在配置中需要一個參數(shù)來禁用錯誤報告。

三、與其他模塊的接口

介紹基礎軟件與其他模塊的對應關系。

3.1 與Rte和SWC接口

CDD可能需要通過Rte與sw -c連接:
? “應規(guī)定所需的端口和接口，并據(jù)此實現(xiàn)AUTOSAR (AUTOSAR接口)。（意思SWC要預留給CDD的端口）

? 在某些情況下，CDD必須使用Rte定義的一些端口特定參數(shù)

3.2 與庫的接口

CDD可以使用AUTOSAR庫。

例如:CDD可以使用端到端庫機制來傳輸防止數(shù)據(jù)損壞或丟失的通信保護。（就是E2E校驗）

3.3 接口到標準BSW模塊

CDD可能需要連接到分層軟件體系結(jié)構(gòu)中的其他模塊，或者分層軟件體系結(jié)構(gòu)中的模塊可能需要連接到CDD。如果是這種情況，以下建議適用:

從分層軟件體系結(jié)構(gòu)的模塊到CDD的接口:（BSW到CDD需要注意的事項）

CDD應提供通用配置的可接入AUTOSAR模塊的接口（大概是要CDD使用BSW中定義的Autosar標準函數(shù)）

一個典型的例子是PDU路由器:一個CDD可以實現(xiàn)一個新的總線系統(tǒng)的接口模塊。在PDU的配置中已經(jīng)考慮到了這一點。

從CDD到分層軟件體系結(jié)構(gòu)模塊的接口:
只有當分層軟件體系結(jié)構(gòu)的各個模塊提供接口，并準備好供CDD訪問時，才允許這樣做。通常這意味著

CDD應負責接口的可重入性。對于不可重入接口，只有一個調(diào)用者可以訪問該接口。對于有條件的可重入接口，如果多個調(diào)用方使用不同的id，則可以同時訪問該接口。
可重入性：
重入一般可以理解為一個函數(shù)在同時多次調(diào)用，例如操作系統(tǒng)在進程調(diào)度過程中，或者單片機、處理器等的中斷的時候會發(fā)生重入的現(xiàn)象。
可重入的函數(shù)必須滿足以下三個條件：
（1）可以在執(zhí)行的過程中可以被打斷；
（2）被打斷之后，在該函數(shù)一次調(diào)用執(zhí)行完之前，可以再次被調(diào)用（或進入，reentered)。
（3）再次調(diào)用執(zhí)行完之后，被打斷的上次調(diào)用可以繼續(xù)恢復執(zhí)行，并正確執(zhí)行

• 如果使用回調(diào)例程（call back routines），則名稱是可配置的。
• 不存在上層模塊來管理模塊的狀態(tài)(并行訪問會在不被上層模塊發(fā)現(xiàn)的情況下改變狀態(tài))

CDD應提供滿足其他AUTOSAR模塊所需的所有配置參數(shù)，例如，如果Dem被調(diào)用來報告生產(chǎn)錯誤，則Dem錯誤代碼必須在CDD配置中符合Dem錯誤碼定義的配置標準

N多核架構(gòu)的情況，請參考§7.4章節(jié)

一般來說，可以訪問以下模塊:

3.3.1 Interfacing with MCAL modules

CDD可以直接訪問微控制器資源(例如硬件定時器)。如果所需的資源由MCAL模塊管理，并且沒有特定的約束(例如實時需求)，CDD應該使用MCAL。強烈建議這樣做以避免沖突(例如，并行訪問同一組/通道/等)。大多數(shù)情況下是不允許的，因為DIO服務不能重入)。

（CDD沒有實時需求或者其他的，就使用MCAL標準函數(shù)。避免并行訪問硬件。盡量避免重入，像DIO就無法重入）
（解決DIO重入問題的一種想法：使用指針，通過形參傳入地址，使返回值存放在不同的地方？）
在這種情況下，CDD應該使用MCAL模塊的標準API來訪問MCAL模塊

3.3.2 Interfacing with ECU State Manager fixed

EcuM應是狀態(tài)管理的唯一接入點，以防ECU State Manager fixed被使用：

• ? Init和De-Init函數(shù)應該由EcuM單獨調(diào)用。
• ? CDD模式的變更應由EcuM處理
• ? 如果CDD處理喚醒源，則必須遵循文檔[13]ECU State Specification中指定的處理喚醒事件的協(xié)議。
• ? 具有固定狀態(tài)機的管理器。

3.3.3 Interfacing with BSW Mode Manager & ECU State Manager Flexible

如果使用靈活的ECU狀態(tài)管理器，EcuM和BSW模式管理器應該是模式管理的專有訪問點

ECU狀態(tài)管理器應靈活用于:

• ? Init和De-Init函數(shù)應唯一由EcuM和/或BswM模塊調(diào)用。
• ? 如果CDD處理喚醒源，則必須遵循文檔[14]ECU State Manager. Specification中指定的處理喚醒事件的協(xié)議

BSW模式管理器應該用于:

• ? CDD模式改變了管理
• ? BswM(在主核心上)確定ECU應關閉，并將適當?shù)哪Ｊ介_關分配到每個核心。從核上的CDD必須捕獲此模式的開關；適當?shù)厝∠跏蓟⑾駼swM發(fā)送適當?shù)男盘栆灾甘舅鼈儨蕚渚途w。

3.3.4 Interfacing with Memory Stack

直接訪問外部NVRAM管理器是可能的，如果它是專門由CDD管理的。如果CDD使用標準內(nèi)存堆棧，NVRAM管理器是內(nèi)存堆棧的獨占訪問點:CDD應該使用NVM的API來訪問內(nèi)存。

3.3.5 Interfacing with Watchdog Stack

看門狗管理器可以監(jiān)督一個或多個可運行程序的執(zhí)行CDD作為監(jiān)督實體?？撮T狗管理器需要配置，可運行的CDD需要調(diào)用文檔[21]看門狗中描述的看門狗API

看門狗管理器是看門狗堆棧的獨占訪問點。CDD不應該直接與看門狗管理器交互，而是通過Rte定義的端口進行交互。通常，Rte負責傳播檢查點信息CDD中的被監(jiān)督實體到看門狗管理器模塊。監(jiān)督部門Manager模塊使用Runtime Environment的服務將監(jiān)控狀態(tài)的變化通知CDD。

為了控制CDD的狀態(tài)依賴行為，Rte提供了模式端口機制。模式管理器可以在模式端口中定義的不同模式之間切換。連接到模式端口的CDD可以通過兩種方式使用模式信息:
—CDD可通過模式端口查詢當前模式。
CDD可以聲明Rte由于模式變化而啟動或停止的可運行對象。

在失敗的情況下，看門狗管理器可以通過Rte模式機制將監(jiān)督失敗通知CDD被監(jiān)督實體。然后CDD監(jiān)督實體可以采取行動從該失敗中恢復。

3.3.6 Interfacing with Communication Stack

有幾個可能的接入點:

• 可以連接到PDU Router模塊來處理IPDU。
• 可以連接到接口。
• 可以連接到NM模塊。
• 可以連接TcpIp模塊。
• 它可以直接接口到Com模塊，因為它可以有信號接口。

一般不適合混合接入點，即同時使用PduR接入點和Com接入點或接口

處理通信并可能觸發(fā)pdu傳輸?shù)腃DD應該提供一個API來啟用/禁用傳輸。這將使Dcm在相應的診斷請求中禁用整個通信。CDD提供的這些函數(shù)可以在鏈接到該函數(shù)的配置動作列表中調(diào)用。例如，對于這些函數(shù)，請參考通信堆棧中的類似API

3.3.6.1 Interfacing with PDU Router

PduR是IPDU通信棧的獨占總線和協(xié)議獨立訪問點。
CDD通過PduR模塊的標準接口訪問IPDU。
CDD與PduR交互時，每個CDD在PduR內(nèi)配置一個容器。
詳情請參見文檔《[22]PDU路由器規(guī)格》。

3.3.6.2 Interfacing Interfaces modules

接口模塊是通信堆棧的專用總線訪問點。
CDD使用接口模塊的標準api訪問IPDU。
當CDD與接口交互時，CDD使用為接口定義的訪問函數(shù)，并且接口回調(diào)應根據(jù)
CDD的需要。<總線>接口應配置為包括
CDD__Cbk.h頭文件。
詳細信息請參見接口規(guī)范和用戶手冊

3.3.6.3 Interfacing with Com Module

如果CDD處理Com信號，則CDD應使用Com模塊的標準api或Rte定義來訪問信號。
詳細信息請參考文檔[23]Specification of Communication。

3.3.6.4 Interfacing with Com Manager

如果CDD使用Com信號，CDD應使用Com管理器的標準api來請求“通信模式”。

如果CDD處理的不是AUTOSAR標準，狀態(tài)應該由ComM處理以協(xié)調(diào)總線通信堆棧。
詳細信息請參見文檔[24]Specification of Communication Manager

3.3.6.5 Interfacing with Network Management Interface module

如果CDD處理的不是AUTOSAR標準，狀態(tài)應該由Nm_CDD模塊處理。
Nm_CDD應該向Network Manager提供服務進行管理
<總線>。
詳情請參見《[25]網(wǎng)管接口規(guī)范》

3.3.6.6 Interfacing with TcpIp module

TcpIp模塊是通信堆棧的基于套接字的獨占訪問點。
CDD應該使用TcpIp模塊的標準api來訪問套接字。
詳細信息請參考文檔[26]Specification of TCP/IP Stack

3.3.7 Interfacing with XCP module

如果CDD處理的<總線>不是AUTOSAR標準，XCP可以接入<總線>_CDD來轉(zhuǎn)發(fā)數(shù)據(jù)。

XCP模塊提供可供CDD使用的可配置接口:
<Cdd_Transmit>請求通過CDD發(fā)送PDU
<Xcp_CddTxConfirmation> API確認成功傳輸
PDU<Xcp_CddRxIndication> CDD調(diào)用的API服務表示成功接收到LPDU。

XCP模塊應配置為允許CDD功能:
XcpOnCddEnabled參數(shù)將被激活。
如果需要，CDD可以調(diào)用回調(diào)函數(shù)Xcp_RxIndication

3.3.8 Interfacing with Diagnostic Log and Trace

如果CDD處理的<總線>不是AUTOSAR標準，Dlt可以接口
<總線>_CDD轉(zhuǎn)發(fā)數(shù)據(jù)。

Dlt將數(shù)據(jù)轉(zhuǎn)發(fā)到Dcm或使用串行接口的CDD。
Dlt不定義特定的通信接口。Dlt規(guī)范定義了一個到內(nèi)部Dlt通信模塊的API。這取決于實現(xiàn)者，如何實現(xiàn)這個通信模塊，以及它如何與可能的對象通信
CDD(如串行或USB)

3.3.9 Interfacing with Default Error Tracer and Development Error

Manager

CDD應使用文檔[19]中描述的Det, Dem報告錯誤
AUTOSAR標準誤差的描述。
CDD應使用Det和Dem模塊的標準api。
CDD應與任何BSW模塊反應一致。錯誤ID應該在CDD模塊中本地定義。CDD負責啟動內(nèi)部恢復。

3.3.10 Interfacing with OS

通常，只有BSW Scheduler和Rte可以使用OS對象或OS服務。
因此，CDD應該只訪問GetCounterValue和
操作系統(tǒng)的GetElapsedCounterValue服務。
只要使用的OS對象沒有被其他BSW模塊使用，CDD就可以訪問OS，例如CDD可以創(chuàng)建OS告警并使用。

OS可以通過OsRestartTask通知CDD某個OS- application已經(jīng)被終止并重新啟動。CDD將不得不采取適當?shù)那謇硇袆印?br> 詳細信息請參考文檔[15]Specification of Operating System

3.4 CDD in multi-cores system

CDD可用于多核架構(gòu)。
在多核架構(gòu)的情況下，CDD可以駐留在任何核心上，遵循以下規(guī)則:

跨分區(qū)和核心邊界只允許用于模塊內(nèi)部通信，使用主/衛(wèi)星實現(xiàn)。

因此，如果CDD需要訪問的標準化接口BSW，它需要駐留在同一個核心上。

如果CDD位于不同的核心上，它可以使用正常的端口機制來訪問AUTOSAR接口和標準化的AUTOSAR接口。這將調(diào)用Rte, Rte使用操作系統(tǒng)的IOC機制將請求傳輸?shù)搅硪粋€核心。
“但是，如果CDD需要訪問BSW的標準化接口，并且不在同一個核心上，
提供標準化接口的衛(wèi)星可以在CDD所在的核心上運行，并將調(diào)用轉(zhuǎn)發(fā)到另一個核心o，或者CDD的存根部分需要在另一個核心上實現(xiàn)，并且需要使用操作系統(tǒng)的IOC機制(類似于Rte所做的)組織CDD-local通信。

此外，在后一種情況下，CDD的初始化部分也需要駐留在不同核心上的存根部分中

3.5 CDD module of the MCAL

微控制器驅(qū)動程序的CDD可以執(zhí)行，但它不能訪問其他標準模塊，因為它是在下層除Det, Dem, SchM…
一般來說，如果某些限制應用于特定的層，那么它也適用于CDD

總結(jié)

AutoSar CDD開發(fā)必看好吧,因為設計到整個AUtosar，蠻多東西我也還沒搞懂的。后續(xù)慢慢修改吧！文章來源地址http://www.zghlxwxcb.cn/news/detail-437226.html

到了這里，關于【標準解讀】Autosar 復雜驅(qū)動（CDD)開發(fā)--看這一篇就夠了的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！