AUTOSAR CAN接口规范：中文翻译版

需积分: 18 17 浏览量更新于2024-07-16 收藏 3.18MB PDF 举报

"AUTOSAR_SWS_CANInterface.pdf 是一份关于AUTOSAR（AUTomotive Open System ARchitecture）中CAN（Controller Area Network）接口规范的文档，已经进行了部分中文翻译。该文档主要针对AUTOSAR 4.2.2版本，详细阐述了CAN接口的规格和功能。" 在AUTOSAR架构中，CAN接口是关键组件之一，用于汽车电子系统中的通信。此规范主要涵盖了以下几个方面： 1. **CAN Interface 规范**：定义了AUTOSAR系统中CAN接口的接口行为、数据传输和管理机制，确保不同模块之间能够正确地进行CAN通信。 2. **CAN FDS支持**：从4.2.1版本开始，文档增加了对CAN Flexible Data-Rate (CAN FD) 的全面支持，CAN FD允许更高的数据速率和更大的数据长度编码（DLC），提高了通信效率。 3. **全局时间同步**：4.2.2版本中，引入了通过CAN总线实现全局时间同步的功能，这对于实时性和高精度的车载网络至关重要，尤其是涉及到传感器数据同步的应用。 4. **取消传输确认**：在4.2.2版本中移除了CanIf_CancelTxConﬁrmation函数，这可能是为了简化API并优化系统性能。 5. **Wakeup、Buffering和Transmit Variants**：文档澄清了唤醒机制、缓冲策略以及不同传输变体的处理方式，这些对于低功耗和高效能的系统设计至关重要。 6. **ICOM支持**：从4.1.3版本开始，ICOM（Intercomponent Communication，组件间通信）的支持被设为可选，这给予了系统设计者更多的灵活性。 7. **PDU模式**：4.1.2及以后的版本对PDU（Protocol Data Unit，协议数据单元）模式进行了限制和改进，例如PduModesa，以适应不同的通信需求和场景。 8. **去除BSW Exclusive Areas**：4.1.3版本移除了基础软件（BSW）的独占区域，这可能意味着对BSW的组织和资源管理进行了优化。 9. **编辑性改动**：每个版本更新都包含了对文档结构和表述的改进，以提高可读性和理解性。 10. **重型车辆支持**：4.1.1版本添加了对重型车辆标准J1939的支持，这意味着CAN接口可以适应不同类型的汽车应用。总体来说，这个文档详细描述了如何在AUTOSAR环境中有效地利用CAN接口进行汽车电子设备间的通信，涵盖了从基本的CAN到高级的CAN FD，以及相关的同步和管理功能。这些规范对于理解和开发AUTOSAR系统中的CAN通信模块非常重要。

Speciﬁcation of CAN Interface

AUTOSAR Release 4.2.2

4 Constraints and assumptions

4.1 Limitations

The CAN Interface can be used for CAN communication only and is speciﬁcally de-

signed to operate with one or multiple underlying CAN Drivers and CAN Transceiver

Drivers. Several CAN Driver modules covering different CAN Hardware Units are rep-

resented by just one generic interface as speciﬁed in the CAN Driver speciﬁcation [1].

As well in the same manner several CAN Transceiver Driver modules covering different

CAN Transceiver devices are represented by just one generic interface as speciﬁed in

the CAN Transceiver Driver speciﬁcation [2, Speciﬁcation of CAN Transceiver Driver].

Other protocols than CAN (i.e. LIN or FlexRay) are not supported.

Please be aware that an active PnTxFilter ensures that the ﬁrst messages on bus

is CanIfTxPduPnFilterPdu. In case that CanIfTxPduPnFilterPdu is the NM-PDU the

COM-Stack start up takes care that the PduGroups are disabled until successful trans-

mission of that PDU. However, transmit requests for other PDUs (i.e. initially started

PDUs, TP-PDUs, XCP-PDUs) will be rejected until the conﬁgured PDU was sent.

4.2 Applicability to car domains

The CAN Interface can be used for all domain applications when the CAN protocol is

used.

16 of 215

— AUTOSAR CONFIDENTIAL —

Document ID 012: AUTOSAR_SWS_CANInterface

Speciﬁcation of CAN Interface

AUTOSAR Release 4.2.2

5.1 Upper Protocol Layers

Inside the AUTOSAR BSW architecture the upper layers of the CAN Interface module

(Abbr.: CanIf) are represented by the PDU Router module (Abbr.: PduR), CAN Net-

work Management module (Abbr.: CanNm), CAN Transport Layer module (Abbr.: CanTp),

CAN State Manager module (Abbr.: CanSm), ECU State Manager module (Abbr.: EcuM),

Complex Driver modules (Abbr.: CDD), Universal Calibration Protocol module (Abbr.: XCP),

Global Time Synchronization over CAN (Abbr.: CanTSyn), J1939 Transport Layer mod-

ule (Abbr.: J1939Tp) and J1939 Network Management module (Abbr.: J1939Nm).

The AUTOSAR BSW architecture indicates that the application data buffers are lo-

cated in the upper layer, to which they belong. Direct access to these buffers is pro-

hibited. The buffer location is passed by the CanIf from or to the CAN Driver module

(Abbr.: CanDrv) during transmission and reception. During execution of these trans-

mission/reception indication services buffer location is passed. Data integrity is guar-

anteed by use of lock mechanisms each time the buffer has been accessed. See

section 7.17 Data integrity.

The API used by the CanIf consists of notiﬁcation services as basic agents for the

transfer of CAN related data (i.e. CAN DLC) to the target upper layer. The call param-

eters of these services points to the information buffered in the CanDrv or they refer

directly to the CAN Hardware.

5.2 Initialization: Ecu State Manager

The EcuM initializes the CanIf (refer to [3, Speciﬁcation of ECU State Manager]).

5.3 Mode Control: CAN State Manager

The CanSm module is responsible for mode control management of all supported CAN

Controllers and CAN Transceivers.

5.4 Lower layers: CAN Driver

The main lower layer CAN device driver is represented by the CanDrv (see [1, Speciﬁ-

cation of CAN Driver]). The CanIf has a close relation to the CanDrv as a result of its

position in the AUTOSAR Basic Software Architecture.

The CanDrv provides a hardware abstracted access to the CAN Controller only, but

control of operation modes is done in CanSm only.

The CanDrv detects and processes events of the CAN Controllers and notiﬁes those

to the CanIf.

18 of 215

— AUTOSAR CONFIDENTIAL —

Document ID 012: AUTOSAR_SWS_CANInterface

AUTOSAR BSW体系结构表明应用程序数据缓冲区位于它们所属的上层

禁止直接访问这些缓冲区

在执行这些传输/接收指示服务时，本地服务buffer被传递

每次访问缓冲区时都使用锁机制来保证数据完整性。

由于CanIf在AUTOSAR基本软件体系结构中的地位，它与CanDrv有着密切的关系。

CanDrv仅提供对CAN控制器的硬件抽象访问，但操作模式的控制仅在CanSm中完成

CanDrv检测并处理CAN控制器的事件，并将这些事件通知给CanIf。

Speciﬁcation of CAN Interface

AUTOSAR Release 4.2.2

The CanIf passes operation mode requests of the CanSm to the corresponding under-

lying CAN Controllers.

CanDrv provides a normalized L-PDU to ensure hardware independence of CanIf.

The pointer to this normalized L-PDU points either to a temporary buffer (for e.g. data

normalizing) or to the CAN hardware dependent CanDrv. For CanIf the kind of L-PDU

buffer is invisible.

The CanIf provides notiﬁcation services used by the CanDrv in all notiﬁcations scenar-

ios, for example: transmit conﬁrmation (subsection 8.4.2 CanIf_TxConﬁrmation, see

[SWS_CANIF_00007]), receive indication (subsection 8.4.3 CanIf_RxIndication, see

[SWS_CANIF_00006]), transmit cancellation notiﬁcation (subsection 8.4.4 CanIf_ControllerBusOff,

see [SWS_CANIF_00218]) and notiﬁcation of a controller mode change (subsection 8.4.8,

see [SWS_CANIF_00699]).

In case of using multiple CanDrv serving different interrupt vectors these callback ser-

vices mentioned above must be re-entrant, refer to section 7.24 Multiple CAN Driver

support. Reentrancy of callback functions is speciﬁed in section 8.4.

The callback services called by the CanDrv are declared and implemented inside the

CanIf. The callback services called by the CanIf are declared and placed inside the

appropriate upper communication service layer, for example PduR, CanNm, CanTp.

The CanIf structure is speciﬁed in section 5.7 File structure.

The number of conﬁgured CAN Controllers does not necessarily belong to the number

of used CAN Transceivers. In case multiple CAN Controllers of a different types operate

on the same CAN network, one CAN Transceiver and CanTrcv is sufﬁcient, whereas

dependent to the type of the CAN Controller devices one or two different CanDrv are

needed (see section 7.5 Physical channel view).

5.5 Lower layers: CAN Transceiver Driver

The second available lower layer CAN device driver is represented by the CanTrcv (see

[2, Speciﬁcation of CAN Transceiver Driver]).

Each CanTrcv itself does operation mode control of the CAN Transceiver device. The

CanIf just maps all APIs of several underlying CanTrcvs to a unique one, thus CanSm

is able to trigger a transition of the corresponding CAN Transceiver modes. No control

or handling functionality belonging to CanTrcv is done inside the CanIf.

The CanIf maps the following services of all underlying CanTrcvs to one unique inter-

face. These are further described in the CAN Transceiver Driver SWS (see [2, Speciﬁ-

cation of CAN Transceiver Driver]):

• Unique CanTrcv mode request and read services to manage the operation modes

of each underlying CAN Transceiver device.

• Read service for CAN Transceiver wake up reason support.

19 of 215

— AUTOSAR CONFIDENTIAL —

Document ID 012: AUTOSAR_SWS_CANInterface

CanIf将CanSm的操作模式请求传递给相应的底层CAN控制器。

CanDrv提供了一个标准化的L-PDU，以确保CanIf的硬件独立性

指向这个规范化L-PDU的指针要么指向一个临时缓冲区(例如数据规范化)，要么指向依赖于CAN硬件的CanDrv。

对于CanIf, L-PDU缓冲区是不可见的。

CanIf提供通知服务，供CanDrv在所有的通知场景中调用

如果使用多个CanDrv服务于不同的中断向量，这些回调服务必须是可重入的

CanDrv调用的回调服务在CanIf中声明和实现

CanIf调用的回调服务被声明并放置在适当的上层通信服务层中

配置的CAN控制器的数量不一定匹配使用的CAN收发器的数量

如果多个不同类型的CAN控制器在同一个CAN网络上运行，一个CAN收发器和CanTrcv就足够了，而根据CAN控制器设备的

类型，需要一到两个不同的CanDrv

第二个可用的下层CAN设备驱动程序由CanTrcv表示

每个CanTrcv本身对CAN收发器设备进行操作模式控制。CanIf只是将几个底层CanTrcvs的所有api映射到一个惟一的api，因此CanSm能够触发相应CAN收发模式的转换。

CanIf中不执行属于CanTrcv的控制或处理功能。

CanIf将所有底层CanTrcvs的以下服务映射到一个惟一的接口。这些在CAN收发器的SWS中有进一步的描述

独特的CanTrcv模式请求和读取服务来管理每个底层CAN收发设备的操作模式

Speciﬁcation of CAN Interface

AUTOSAR Release 4.2.2

• Mode request service to enable/disable/clear wake up event state of each used

CAN transceiver (CanIf_SetTrcvMode(), see [SWS_CANIF_00287]).

5.6 Conﬁguration

The CanIf design is optimized to manage CAN protocol speciﬁc capabilities and han-

dling of the used underlying CAN Controller.

The CanIf is capable to change the CAN conﬁguration without a re-build. Therefore, the

function CanIf_Init (see [SWS_CANIF_00001]) retrieves the required CAN conﬁg-

uration information from conﬁguration containers and parameters, which are speciﬁed

(linked as references, or additional parameters) in chapter 10, see Figure 10.1.

This section gives a summary of the retrieved information, e.g.:

• Number of CAN Controllers. The number of CAN Controllers is necessary for

dispatching of transmit and receive L-PDUs and for the control of the status of

the available CAN Drivers (see CanIfCanControllerIdRef).

• Number of Hardware Object Handles. To supervise transmit requests the CAN

Interface needs to know the number of HTHs and the assignments between each

HTH and the corresponding CAN Controller (see CANIF_HTH_CAN_CONTROLLER_ID_REF,

ECUC_CanIf_00625; CANIF_HTH_ID_SYMREF, ECUC_CanIf_00627 ).

• Range of received CAN IDs passing hardware acceptance ﬁlter for each hard-

ware object. The CAN Interface uses ﬁxed assignments between HRHs and L-

PDUs to be received in the corresponding hardware object to conduct a search al-

gorithm (see section 7.20 Software receive ﬁlter, see CANIF_SOFTWARE_FILTER_HRH,

CANIF_HRH_CAN_CONTROLLER_ID_REF, CANIF_HRH_ID_SYMREF, ECUC_CanIf_00634)

CanIf needs information about all used upper communication service layers and L-

SDUs to be dispatched. The following information has to be set up at conﬁguration time

for integration of CanIf inside the AUTOSAR COM stack:

• Transmitting upper layer module and transmit I-PDU for each transmit L-SDU.

=> Used for dispatching of transmit conﬁrmation services

(see CANIF_CANTXPDUID, ECUC_CanIf_00247).

• Receiving upper layer module and receive I-PDU for each receive L-SDU.

=> Used for L-SDU dispatching during receive indication

(see CANIF_CANRXPDUID, ECUC_CanIf_00249).

The CanIf needs the description of the controller and the own ECU, which is con-

nected to one or multiple CAN networks. The following information is therefore re-

trieved from the CAN communication matrix, part of the AUTOSAR system conﬁgu-

ration (see containers: CanIfTxPduConﬁg, ECUC_CanIf_00248; CanIfRxPduConﬁg,

ECUC_CanIf_00249):

20 of 215

— AUTOSAR CONFIDENTIAL —

Document ID 012: AUTOSAR_SWS_CANInterface

对CanIf设计进行了优化，以管理CAN协议的特定功能和使用的底层CAN控制器的处理。

CanIf能够在不重新构建的情况下更改CAN配置

CanIf需要控制器和自己的ECU的描述，ECU连接到一个或多个CAN网络。

剩余214页未读，继续阅读

zwmyxfbenet

粉丝: 4
资源: 3

AUTOSAR CAN接口规范：中文翻译版

AUTOSAR_TR_SWCModelingGuide 最新 4.3.1

AUTOSAR_SWS_NVRAMManager 4.3.1

AUTOSAR_SWS_CANInterface

autosar_sws_diagnostics.pdf

autosar_sws_e2elibrary.zip

autosar_sws_cannetworkmanagement_4.3_中文版本.pdf

翻译一下Adaptive AUTOSAR规范文档《AUTOSAR_SWS_Diagnostics.pdf》

autosar_sws_diagnostics.pdf 中文翻译

autosar_sws_timesyncovercan

autosar_sws_someiptransformer.pdf

最新资源